The Payment Card Industry Security and Standards Council (PCI SSC) held its annual community meeting for North America in Vancouver this year. Amidst many updates to their standards and industry perspective seminars, some details regarding an update to their flagship standard, PCI DSS, were provided. As many may know, the PCI SSC is preparing to issue a draft version of PCI DSS v4.0. In preparation for this effort some general information was outlined in a presentation at the community meeting. It was apparent early in the presentation that the update to the PCI DSS is going to be the largest change to the standard since the release of PCI DSS v3.0 in 2013. The following is an overview of the information provided directly from the council, along with some informed speculation. Additional information will be available in the coming months when draft versions are released.
As the PCI SSC prepared for this upgrade for the standard, they identified four main goals.
Ensure the standard continues to meet the security needs of the payments industry
Ensuring the PCI DSS continues to meet security needs is the ultimate reason the DSS exists. Part of continuous relevance of the standard includes increased flexibility in requirement testing, new requirements, additional guidance and reorganizing the standard in some fashion. The council did indicate that the 12 main requirements will remain the same, but individual testing procedures will likely be renumbered. The PCI SSC also acknowledged the need to align with industry best practices for authentication, which likely means they are acknowledging recent guidance provided by NIST 800-63B regarding password complexity.
Add Flexibility and support of additional methodologies to achieve security
The industry has been requesting additional flexibility within the DSS for several years. From discussions at the community meeting, it appears that the PCI SSC has acted on this feedback from the community. The council indicated that DSS 4.0 will allow for two separate approaches to satisfy each requirement in the standard, Defined and Customized. Defined is the current process for which an organization must fulfill each requirement as stated. The Customized implementation is much more flexible and employs the use of objectives-based testing procedures. It is still unclear exactly how these will work, but the focus is ensuring organizations meet the intent of each requirement. In meeting an objective-based control, an organization will still need to conduct a similar process to developing a compensating control with one key difference: Unlike for compensating controls in the existing PCI DSS, an organization will not need to provide a business or technical constraint when using the customized approach for meeting a requirement. PCI DSS 4.0 will also allow the assessed entity to use a combination of custom and defined approaches for meeting different requirements throughout the standard.
Promote security as a continuous process
The promotion of security as a continues process has been included in the PCI DSS for several years. You can expect to see more periodic or recurring requirements such as requirements to scan on a quarterly basis, review firewall configurations every six months and conducting process reviews on a quarterly basis.
Enhance validation methods and procedures
The SSC did not discuss this goal in very much detail either, but the assumption is that this is a call back to objective-based requirements for organizations looking to use a customized approach. They did take some time to compare the notion of an objective-based requirement to risk-based requirements. From a high-level, an objective-based requirement has similarities to risk-based approaches in that the overall intent of meeting a requirement is to protect payment data, thus an objective-based approach could be seen an reducing the risk of not adhering to a defined requirement. It is important to note though that all PCI DSS standards up to this point have taken a prescriptive approach, for which risk was not a factor. This would suggest that the customized approach will remain more objective-based. Further, the SSC has avoided, thus far, using the language of a risk-based approach, since that phrase has a number of definitions, not all of which support their goals for DSS 4.0.
We can look forward to the addition of some requirements. An exact number was not provided, nor were specific sunrise periods for those new requirements. However, the PCI SSC has provided the following estimated timeline for the release of the standard:
When the next RFC round begins in October 2019, Schellman and other stakeholders will receive a draft version of the standard to review and provide feedback. Feel free to contact us at pci@schellman.com if you have any questions about PCI DSS 4.0. Participation in the RFC process requires elements of nondisclosure. Schellman will provide additional information as soon as it is available for public release.
About the Author
More Content by Matt Crane
