#ThinkAppSec – Top Application Security Questions Answered (Week 7)

We’re coming up on January 1, 2014, the day that the new PCI DSS (Payment Card Industry Data Security Standard) and PA DSS (Payment Application Data Security Statand) 3.0 are active. This week’s questions were inspired by PCI.

1. What is the difference between PCI DSS and PA DSS? 

Short answer: Every organization that handles credit cards needs to comply with PCi DSS, only vendors that make and sell payment applications need to meet PA DSS.

The PCI DSS is a standard that ALL organizations that store, process and/or transmit credit card data must be compliant with.

The PCI Data Security Standard is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. The PCI Data Security Standard is comprised of 12 general requirements designed to:

  • Build and maintain a secure network;
  • Protect cardholder data; Ensure the maintenance of vulnerability management programs;
  • Implement strong access control measures; Regularly monitor and test networks; and
  • Ensure the maintenance of information security policies.

No matter how large or small, if your organization handles credit card data, it must be PCI DSS compliant. However, the number of card transactions that your company handles can impact the compliance validation requirements to PCI DSS. Only your acquiring bank or payment brand (ex: MasterCard) can specify the exact compliance requirements because although PCI DSS is an agreed on standard, each of the five PCI card brands (MasterCard, VISA, Discover, AmEx and JCB) maintains its own program for compliance, validation levels and enforcement.

Entities that have limited scope in their cardholder data environment (ex: retailers that use imprint only or process all card data with an online provider and have no electronic storage of cardholder data at their sites or on their networks) may not be required to submit a Report on Compliance (ROC) and can use the self assessment questionnaires (SAQs) for PCI DSS compliance. If you’re not sure what your compliance requirements are, check with your acquirer or card brand. However, before you speak with them, you can find a lot of useful background information at the PCI Security Standards Council (SSC) site. The SSC Quick Reference Guide provides an excellent overview to help companies get started with their PCI journey.

The PA DSS is the standard for makers/developers and integrators of payment applications that use credit card information for payment authorization and settlement. To require PA DSS compliance these applications must be sold, distributed or licensed to third parties. In other words, if you wrote your own payment application that you use in your organization, it has to be PCI DSS compliant but not PA DSS compliant. If you are a payment vendor that sells your payment application to customers, it has to meet PA DSS. Card brands encourage organizations to use only PCI SSC validated applications. The SSC keeps a current list of validated payment applications.

2. If I’m not a payment application vendor, what value does the PA DSS have for me?

Even though you don’t have to comply with PA DSS, don’t overlook the information in it whether or not you’re developing your own payment applications or buying one form a vendor. Here’s why:

  • PA DSS can be used by your internal assessment team to validate a provider’s or partner’s payment application. Although the SSC keeps a list of validated payment apps, you may find that a partner payment app isn’t on the list. Or you may want to perform your own independent audit of the payment app. In these use cases, the PA DSS is a great audit and assessment guide.
  • PA DSS is a deep dive on developing secure payments apps and can/should be used by your internal development and security teams to ensure that the apps your developing are architected and deployed with card data protection in mind.

The PCI DSS covers the entire cardholder data environment eco-system which addresses security of payment apps but doesn’t go into the detail that PA DSS does. Using the PA DSS as a guide, even for internal apps, gives your dev team additional guidance.

One example is Requirement 5.1.5 of the PA DSS: Secure source-controls practices are implemented to verify integrity of source code during the development process.  Source code control is an important part of a secure SDLC and is called out in standards like NIST 800-64 (A concept of operations document for secure development should be established for the environment and a contingency plan should be in place for the code repository as source code is the predominant work product of software and system development and should be preserved in the event of interruption to the development environment.) and ISO 27002 (12.4.3: Control access to program source code) but it is not mentioned in the PCI DSS.

Another example is Requirement Coding techniques include documentation of how PAN and/or SAD are handled in memory. Again, an important aspect of payment application security, but not explicitly called out in the Requirement 6 (the one that addresses applications) in the PCI DSS.

There are many more examples in the PA DSS – but I hope that these have helped to convince you that even if you’re not developing a payment application for resale, if your developing one at all, the PA DSS is a valuable document for your coding, security and test teams to review and use in secure payment application development.

Previous Weeks

Week 1- What is the importance of software security in supply chain management?

Week 2 – Who Should be Responsible for Application Security Testing?

Week 2 – Can “generated code” be tested?

Week 3 – How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

Week 3 – As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?

Week 4 – Will the legal landscape change if software vendors can be sued without damages or loss being proven?

Week 4 – What is PII – How much can the definition expand?

Week 5 – Which apps are more secure: Android or iOS?

Week 5 – Are mobile application reputation services valuable to enterprises?

Week 6 – Does IoT (Internet of Things) “change everything” for Application Security?

Week 6 – What can I do now to get ready for IoT?

more from Application Security

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory.…

Black Hat 2022 Sneak Peek: How to Build a Threat Hunting Program

You may recall my previous blog post about how our X-Force veteran threat hunter Neil Wyler (a.k.a “Grifter”) discovered nation-state attackers exfiltrating unencrypted, personally identifiable information (PII) from a company’s network, unbeknownst to the security team. The post highlighted why threat hunting should be a baseline activity in any environment. Before you can embark on a threat hunting exercise, however,…