The Council has just released version 3.2 of the Payment Application Data Security Standard (PA-DSS) used by payment application vendors to ensure their software products will help protect cardholder data from theft. What do payment application vendors and assessors need to know about PA-DSS 3.2? In this blog post with Chief Technology Officer Troy Leach, we look at what’s new in this version of the standard.
You’ve announced today the release of version 3.2 of the Payment Application Data Security Standard. When do these changes need to be adopted?
Troy Leach: We encourage application vendors to review PA-DSS 3.2 and begin incorporating the necessary changes into their payment applications and Implementation Guides (detailed instructions that vendors must include with their payment applications) as soon as possible. Version 3.2 is effective 1 June 2016, and PA-DSS version 3.1 retires on 31 August 2016.
What do Payment Application Qualified Security Assessors (PA-QSA) need to know about handling assessments of applications during the transition from version 3.1 to 3.2?
Troy Leach: As we’ve done with previous version updates, a transition period is provided to support the completion of validations already in progress to PA-DSS v3.1. We’ll be publishing a specific Frequently Asked Question (FAQ) document shortly that will help with the transition to PA-DSS version 3.2. In the meantime, we encourage assessors to review and familiarize themselves with the standard and its support documents, which include the Report on Validation (ROV) Template and Attestation of Validation (AOV).
How does PA-DSS version 3.2 align with version 3.2 of the PCI Data Security Standard (PCI DSS)? What can you tell us about these changes?
Troy Leach: The majority of changes are simply to support those in PCI DSS 3.2. For example, PA-DSS Requirement 12.2 supports PCI DSS Requirement 8.3.1 for using multi-factor authentication (MFA) for non-console administrative access to the cardholder data environment. What this means from the PA-DSS perspective is that the vendor can choose to either include instruction about using MFA in the payment application’s Implementation Guide, or provide MFA functionality within the payment application itself.
We’ve also added to PA-DSS Requirement 3.1 that the Implementation Guide must include identification of all roles and default accounts within the application with administrative access. This addition is intended to support users that need to know which application accounts have administrative access, so they know which accounts they’ll need to implement MFA for by 2018.
Can you talk a little more about the other additions now required for the Implementation Guide in version 3.2?
Troy Leach: Technology is only as good as its implementation, which is what makes the Implementation Guide so important. Time and time again we see security compromised because of improper installation or setup of payment software – something as basic as not changing the vendor-assigned default password that comes with the product, or not enabling security updates and patches. In fact, Verizon’s Data Breach Investigation Report in 2015 found that the vast majority of data breaches were a result of criminals exploiting software bugs that had a fixable patch available for at least a year.
To help address the importance of proper setup and ongoing maintenance of these payment applications, we’ve added details on procedures for secure installation of patches and updates that must be included in the Implementation Guide. This will specifically help integrators and resellers and users of payment software to make sure they are updating it properly.
Additionally, the Implementation Guide must now include instructions that any debugging logs that include PAN (primary account number) data must be protected, disabled as soon as troubleshooting is complete, and securely deleted when no longer needed. Debugging logs are sometimes used to troubleshoot issues with payment processing devices/applications. These logs typically output detailed information, which can include full PAN data. Often, organizations don’t realize these logs contain sensitive data that needs to be protected so they are left unprotected and then exploited during a compromise.
Qualified Integrators and Resellers are responsible for implementing PA-DSS validated applications into merchant environments. Is there anything specific they should be aware of in PA-DSS version 3.2?
Troy Leach: Point-of-sale (POS) vulnerabilities continue to be one of the most common point of attacks for card data theft. That’s why secure installation of payment software is so important. Qualified Integrators and Resellers (QIR) perform a critical role in giving businesses confidence that their payment systems are set up securely to protect against data compromise and to help facilitate PCI DSS compliance.
We encourage QIRs to closely review the new additions to the Implementation Guide content, so they understand how these requirements impact what they do in the field, and are prepared to support their merchant customers and the payment applications that they implement. We also strongly urge integrators and resellers that are not yet qualified as PCI QIRs to consider the QIR program to receive training and instruction on secure payment systems implementation and configuration.
