Preparing for PCI DSS 4.0

PCI DSS 4.0 is currently in its request for comments (RFC) process, where the industry can provide comments and feedback to help shape the next iteration. This process is initially open to the participating organizations – members that help steer and inform the PCI SSC based on their experiences. The RFC period for PCI DSS 4.0 ends in November 2019, and the council hopes to release PCI DSS 4.0 toward the end of 2020. 

The PCI SSC has highlighted the specific areas below for the industry: 

• Authentication, specifically focused on NIST MFA/password guidance (NIST SP 800-63)
• Broader applicability for encrypting cardholder data on trusted networks
• Monitoring requirements to consider technology advancement 
• Greater testing frequency for critical controls; for example, incorporating some requirements from the DESV (Designated Entities Supplemental Validation) – PCI DSS Appendix A3 – into regular PCI DSS requirements

If we delve more deeply into each of these areas, they show support for some new payments initiatives as well as help the standard evolve to some emerging risks.

Authentication is important, not just as part of the access control processes that we need for logging into systems, but also as an expectation in the payment process. With PCI SSC and EMVco working closely together, I’m sure more will be presented that shows how the new 3DS standard (both PCI and EMVco) can be used as part of a transaction authorization to enable Secure Customer Authentication. The new 3DS standard enables pluggable authentication options – allowing issuers the flexibility to build solutions that can meet a variety of regulatory requirements around the world as well as adapt to changing expectations from cardholders and the devices they use for payment, while still supporting the “in-transaction” risk management that is so common with the EMVco approach.

The PCI 3DS standard is an interesting indicator of the direction the PCI SSC may take with future iterations of the PCI DSS. It’s a much more flexible, “Control Objective”-based standard with fewer of the requirements being prescriptive; rather, it sets a security objective and allows the standards adopter to put controls in place that they feel meet that objective. Theoretically, this will allow the standard to support more seamless cross-over with others such as ISO 27001 and the Trust Principles.

The broader applicability for encryption has been mooted over the years, and with the PCI-P2PE standards getting more traction among the service provider community, it could be an area that becomes more prevalent, perhaps in response to threats that take up residence in a network and harvest cardholder data in transmission.

I can envisage the greater frequency of testing and addition of controls from the DESV standard getting a lukewarm response. DESV is very prescriptive and was originally geared toward entities that had suffered a breach and needed to have both their controls and assessment programs scrutinized. However, a lot of the more robust requirements that have made it into the PCI DSS’ current incarnation started out in the DESV, so it’s not too much of a surprise.

The PCI SSC’s “monitoring of requirements to consider technology advancement” is the biggest indicator that we may see a more risk-based approach take hold in the standard. This may well lead to a shift toward a more pluggable adoption of other PCI standards, such as the Software Security Framework and security objectives that, with guidance, allow for adoption of technology solutions that can move more quickly without being put into a specific control box.