What is the difference between PCI DSS and PA DSS? What value does the PA DSS have for me?

#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 5.1.6.1 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.