Upcoming PCI DSS Changes

It’s getting to be that time of year again; PCI ROC season is right around the corner. Though the new version of PCI DSS (Version 2.0?) is not due out until October, many of my clients are asking what changes they should expect.

Every two years the PCI Security Standards Council (PCI SSC) issues a new version of the Payment Card Industry Data Security Standard (PCI DSS) as part of the lifecycle and feedback review process from a wide range of organizations. No major changes are expected in the upcoming release, just clarifications.

For starters, look for an update to Requirement 6.5 (secure web application development) for changes in the OWASP Top 10. Your will see 2 new Top 10 vulnerabilities including Security Configuration and Unvalidated Redirects and Forwards. Gone are malicious file execution (6.5.3) and Information leakage and improper error handling (6.5.6). Keep in mind that (as per PCI DSS) whenever a new version of the OWASP Top 10 vulnerabilities is released, it’s implied that the current requirements are to be replaced with the latest OWASP updates.

Expect to see Information Supplements that provide guidance and clarification on a range of emerging technologies. One of the first will address the use of Virtualization technologies. The Virtualization Special Interest Group (SIG) has been busy putting together a white paper and a mapping "tool" document that explains where virtualization applies within each requirement of the DSS. You can find more information on the Virtualization SIG here. Other papers to be published are anticipated to address end-to-end encryption, tokenization and even the Eurocard-MasterCard-Visa (EMV) chip-card standard.

In another change, the PCI SSC is expected to clarify what constitutes acceptable network segmentation. Although segmenting cardholder data environments from the rest of non-cardholder data network is not required by the PCI DSS, it is the only cost effective way to address compliance. Without segmentation, your entire network is considered in scope and subject to PCI compliance.

Lastly, there should be clarification on strong one-way hashing of Primary Account Numbers (PAN). Organizations can remove PAN data from PCI scope either by truncation (deleting all but the first 6 and last 4 digits) or using a secure one-way hash that cannot be reversed. This clarification promises to be a welcome step in helping organizations and their QSAs clarify what is and what is not in scope.