PCI DSS Version 4.0 – What We Know So Far

From September 23 - November 13, 2020, stakeholders can participate in the Request for Comments (RFC) on the draft of PCI Data Security Standard (DSS) version 4.0. This is the second RFC for the PCI DSS v4.0 draft—the first RFC was in late 2019 and that feedback was incorporated into the draft.

Feedback plays a critical role in the ongoing maintenance and development of new and existing PCI security standards. The feedback cycles show how committed the community is to bringing stakeholders together to ensure the new standard is fit for purpose well into the future.

Now is a good time to revisit the objectives the PCI SSC set for the standard last year.

• Ensure the standard continues to meet the security needs of the payments industry
• Add flexibility and support of additional methodologies to achieve security
• Promote security as a continuous process
• Enhance validation methods and procedures

The good news is that the PCI SSC has committed to not requiring major changes to the current standard, which should go a long way in easing adoption of the updated standard. Most organizations should experience only a minor shift from their PCI DSS v3.2.1 program to v4.0.

One area that has often caused confusion among assessors who are not familiar with the card brand rules is guidance associated with sensitive authentication data fields. The updated standard is expected to clarify that this applies to pre-authorization data in the case of sensitive authentication data fields.

As PCI Forensics Investigators (PFI), we know that feedback plays an important role during cardholder data compromise investigations. While this feedback is not typically shared or discussed openly due to its sensitive nature, the PFI community gets together during the PCI Community Meetings to discuss trends and issues that may affect the various implementation approaches to the PCI DSS standard.

Plug in to PCI DSS v4.0 for increased flexibility

In the past, the PCI SSC evolved the standards to become more flexible and v4.0 is no exception. The Point-to-Point Encryption (P2PE) solutions have become a nice plug-in for merchants looking to simplify the scope of their compliance obligations while focusing on a solution to protect payment data in transit. Three-Domain Secure (3DS) has emerged as a point solution for protecting authentication of e-commerce credentials and is a good indicator of the way future standards may develop. It shows a clear reference to the use of other standards and is designed around security objectives, providing more flexibility than ever before.

The PCI Software Security Framework (SSF) and the Secure Software Lifecycle (SSLC) are the new industry standards for secure software implementation, which we expect to be a plug-in for PCI DSS Requirement 6 that addresses application security. For larger enterprises, this could be a significant source of efficiency because SSLC certifications are good for three years, much like P2PE solutions.

Much of the talk about PCI DSS v4.0 has been around the replacement of compensating controls with a new, customized approach. As the adoption of the PCI DSS increased and more organizations began to rely on it as a common standard for security controls, compensating controls were often seen in a negative light. We have heard insurers and third parties state that there should be no compensating controls, even though it is possible for a compensating control to be entirely appropriate in a PCI DSS v3.2.1 implementation. The new customized approach neutralizes that issue and would require organizations that rely on PCI DSS-compliant status to do a thorough review of what has or has not been implemented. I think this will be positive because, for a long time, there has been passive reliance on PCI DSS compliance by organizations not fully understanding the nuances of scope.

One challenge around the use of the customized approach is that for many organizations that have adopted the PCI DSS as their sole security standard or sole framework, it is more of an objective-focused approach. Working towards specific objectives can cause organizations to ask: “But how do I meet that objective?” Fortunately, the standard will have the specific control expectations in place so that PCI DSS v4.0 blends the prescriptive with the more flexible objective approach.

For enterprises that have many compliance obligations and are accustomed to assessing against multiple frameworks simultaneously, the customized approach will be music to their ears. They can align the objectives with other security objectives being implemented—such as COBIT or the trust principles typically associated with SOC audits and even the ISO 27000 series—to allow a Qualified Security Assessor (QSA) to be seamlessly integrated into those other assessment programs. I anticipate that the first year of the customized approach may require a heavy lift in terms of documenting all the customized approaches and their validation procedures. But if aligned with other frameworks, this exercise may help generate assessment and audit efficiencies.

Overall, I think the PCI DSS v4.0 is shaping up nicely thanks to the over 150 organizations that have contributed feedback so far in the RFC process. The updates made to v4.0, based on RFC (round 1) feedback and comments, continue to underscore and demonstrate the key objectives identified for the next PCI DSS release expected by the middle of next year.