I’ve waited longer than usual to write about my feelings on the newly released PCI DSS and PA-DSS v2.0 standards by the PCI Security Standards Council. I’ll give my own impression and then do a round-up of the various other blog posts and reactions to the update.
Don’t panic! This too shall pass. (It’s true.)
Since v2.0 was released October 28, 2010, the big question is when do I have to start using it and how long as I used v1.2.1?
- PCI v1.2.1: Can be used through the end of 2011. Organizations that are working under v1.2.1 must submit final reports no later than December 31, 2011.
- PCI v2.0: Reports using v2.0 will not be accepted prior to January 1, 2011. Any assessment started after January 1, 2011 should begin to use v2.0. Any assessment started after December 31, 2011 is required to use v2.0.
The PCI Council moved from a two (2) year to a three (3) year standards cycle meaning the standards will stay static until 2013. Tastes great vs Less filling? People will say this is bad because it does not change, but as Bob Russo stated [26:30] in his podcast with Martin McKeay, “as the landscape changes there is an errata process that involved in the standards. So ee have the ability to issue errata anytime we need to, and if there is something that affects the standard and we have to address it immediately we are able to do that.” In addition, there are the various Special Interest Groups (SIGs) creating content and clarification in areas such as: scoping, encryption, tokenization, virtualization, Chip and PIN, wireless, etc.
The actual changes to the standards were more evolutionary than revolutionary. This means they were clarifications and consolidations rather than major changes.
The #1 change to impact the industry is not the release of v2.0 of the standard, but release of the PCI Scoping Guidance documentation (still to be released) from the PCI SSC Special Interest Group (SIG) on Scoping. (Full disclosure, I participate on the Scoping SIG.) The scoping SIG is lead by Gene Kim, founder of Tripwire, and include participation from QSAs and merchants alike. This guidance documentation has the potential to clarify the way we look at the application of every control. I believe it will bring standardization to the scope of assessments.
Check out Gene Kim’s presentation: 2010 07 BSidesLV Mobilizing The PCI Resistance 1c
For details on changes to the standard, ‘I recommend reading the following two summaries:
- Qualys tech has a nice writeup of the key changes
- Davi Ottenheimer has a good writeup on the Flying Penguin
The key changes I want to highlight:
- Virtualization: Yes, PCI DSS Requirement 2.2.1 is updated to use the word “virtualization” and it’s included in the overall scoping documentation as well. I’ll defer to Chris Hoff’s writeup for details. Remember that compliance standards should be “technology agnostic”, as such any new technology can [theoretically] be used to comply with the standards as long as they are properly secured.
- Risk Management: The emphasis for risk management increases. It started with PCI DSS Requirement 12.1.2 which notes an “annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.” Now, PCI DSS 6.2 expands this to risk ranking vulnerabilities with, “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” Though this is a recommendation until June 30, 2012 when it becomes mandatory, I don’t understand why anyone would NOT want to take a risk based approach.
- Secure SDLC: The PCI DSS Requirement 6.5, formerly applicable only to “web applications”, now applies to all developed applications. It is no longer tied to OWASP but now recommends best practices such as the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.