Author: Adam Bush, PCI Technical Lead
PCI 3.0 Is Almost Here!
The three year life cycle of version 2.0 has come to an end, and the new 3.0 standard will be published in October, shortly after the community meetings. In fashion akin to a Nick Fury appearance at the end of a Marvel movie, the PCI Security Standards Council has teased us with the adventures to come by providing the community with a ‘Highlight of Changes’ for the soon-to-be released 3.0 version of the Data Security Standards (DSS). Let’s clarify that the details of the changes are still unknown, but before panic sets in, it appears that all things will continue to be ‘business-as-usual’.
Below are excerpts (with my key takeaways) from the release.
Note: As an accredited QSA firm and as of this date, Schellman has received a copy of the actual PCI DSS version 3.0. Until the document is released publicly we are prohibited from making any specific statements about the DSS other than to say that the observations below from the press release are generally in alignment with what was actually published.
Nature of the Changes
"…the changes will provide increased stringency for validating that (…) controls have been implemented properly, with more rigorous and specific testing procedures that clarify the level of validation the assessor is expected to perform."
"…enhanced testing procedures to clarify the level of validation expected for each requirement."
Rather than a significant update to the DSS, I interpret this to be more of a revision to the ROC Reporting Instructions and guidelines released by the Council in September of 2011. It was a game changer then because it provided a script for how QSAs should document (and test) that a control is operating effectively -- as opposed to rewriting or clarifying the actual requirements and testing procedures. It also goes after PCI’s second greatest weakness, consistency among assessors. (The greatest being the lack of independence requirements prohibiting QSA companies from assessing environments where they designed and/or implemented the controls.) Unfortunately, the reporting instructions often seemed out of sync with the original requirements. Hopefully these updates will clean up the relationship between the DSS and the Reporting Instructions.
Drivers for change include:
- Lack of education and awareness
- Weak passwords, authentication
- Third-party security challenges
- Slow self-detection, malware
- Inconsistency in assessments
Every member of the infosec community knows that the quality of security is delimited by the weakest user. The presence of security awareness training and education is so standard in every control framework that the subject is often chalked up as the lip-service of those seeking ‘security evangelist’ status. The fact is that all previous versions of the DSS have included requirements about security training, and any updates on the matter will likely only impact how assesses continue to demonstrate their diligence on the task. I have similar expectations about points 2 – 4.
The 5th point, ‘Inconsistency in assessments’ is surely based upon feedback from the merchants and service providers, and it is great to know that the complaints are not falling upon deaf ears. This is also complemented by the point above regarding testing procedures. In addition for 3.0, I expect additional narratives or language around scoping and segmentation, as those topics seem to be the most hotly disputed amongst QSA companies.
Penetration Testing for Scoping Verification
Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective.
Schellman has advocated this for some time, and reiterates that we can expect greater guidance on how scope should be validated with more thorough testing of segmentation.
Securing Authentication Methods
Security considerations for authentication mechanisms such as physical security tokens, smart cards, and certificates.
This is a great example of the standards maturing. Two-factor authentication is nothing new to the industry, but up to this point, the physical security of that second factor has been overlooked. In 3.0, look for some sort of physical security controls to be added, for example: maintaining inventories of physical tokens and an additional policy requirement that states they should not be left laying out, unattended, or otherwise shared.
Added guidance for implementing security into business-as-usual (BAU) activities and best practices for maintaining on-going PCI DSS compliance.
The official nominees are in for buzzword of the year, and ‘business-as-usual’ is leading the pack with four references in the change highlights document. If the above reference to maintaining on-going compliance (as opposed to demonstrating compliance at a point in time) seems familiar, it should. Other assessments like SOC 1 and SOC 2 examinations test controls over a review period and document their deviations. While it would be nice to see disclosures of exceptions and subsequent remediation, rather than the final outcome, more likely it will look for additional evidence of continuous monitoring controls, aside from just scanning.
In summary, flexibility around newer technologies and approaches while more diligence in testing and validation of scope seem to be the themes. This can only provide more credibility and acceptance of what is now, in relative terms, a very mature security standard. Rest assured that once the actual update comes up, we will follow-up with additional information to guide clients, just as we did with the 1.2.1 to 2.0 migration. In the meantime, we also recommend you read the Council’s release.