What's new in the standard and what does it mean for the midsized business? For most businesses, the answer is a resounding "not much." If you review the Summary of Changes document released by the Council, you'll discover that the changes are, for the most part, a collection of miscellaneous clarifications and rephrasings that you would expect to see in a new version of the standard.
While there's no substitute for a thorough review of the entire PCI DSS 2.0 standard (which will be released to the world at the end of October), there are two areas that should draw the attention of security professionals at midmarket businesses: the requirements related to virtualization and vulnerability assessments. We'll cover the changes in both areas in this tip.
Virtualization and PCI DSS
It's no surprise that the latest version of the standard tackles virtualization head-on. The summary of changes indicates that we'll see some clarification on what the compliance requirements are for organizations that employ server virtualization. One requirement in particular, section 2.2.1, has been a thorn in the side of virtualization advocates since the initial release of PCI DSS. The current language in that standard requires that organizations "implement only one primary function per server." When read strictly, this language seems to ban the use of virtualization technology in card processing environments.
Expect to see this resolved in PCI DSS 2.0. I'd expect to see virtualization get the official "green light" and Section 2.2.1 to be rewritten to require that each virtual machine implement one primary function, while allowing the virtualization hardware to host as many guest operating systems as desired. This will be major news for those seeking to isolate card-processing functions and place a completely isolated environment within the reach of small and midmarket businesses that couldn't previously justify the large investment in hardware required to have dedicated servers for each function.
Requirement 6.2 of the PCI DSS requires organizations conduct risk assessments to identify new vulnerabilities. While certainly a best practice in the past, industry expert Evan Schuman reports that the standard will be amended to require a risk-based approach to vulnerability management. In fact, he writes that the draft includes the language "risk rankings should be based on industry best practices. For example, criteria for ranking "high-risk" vulnerabilities may include a Common Vulnerability Scoring System (CVSS) base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as critical and/or a vulnerability affecting a critical system component."
This appears to be a move forward that will help smaller enterprises approach PCI DSS from a risk-based standpoint. Operationally, that means SMBs can focus more time on truly significant risks instead of having to diligently seek out and address lesser ones. After all, it only makes sense to spend the majority of your time resolving one or two critical vulnerabilities instead of focusing on a larger number of minor flaws. For organizations that are not already using a risk-rating system in vulnerability assessments, Schuman reports that you'll need to comply with the new approach by June 2012. Fortunately, this should be fairly straightforward, as all commercial vulnerability management systems make use of some rating scale, often adopting the industry standard CVSS.
PA DSS and you
Along with the PCI DSS 2.0 announcement, the SSC also announced changes to the less known Payment Application Data Security Standard (PA DSS). While this standard only applies to those that develop payment applications (normally not done internally in a midsized business), there is a significant change in PA DSS that will make life easier. The Summary of Changes states that PA DSS will be updated to "Add sub-requirements for payment applications to support centralized logging, in alignment with PCI DSS requirement 10.5.3."
This will resolve one long-standing complaint of security professionals tasked with PCI DSS compliance, namely that their payment systems simply don't support the centralized logging that PCI DSS requires. When the new standard goes into effect, all certified payment applications must include this functionality. You are already required to use only certified payment applications. This new rule ensures that those applications will help you meet your compliance requirements.
The PCI DSS 2.0 bottom line is good news for midsized businesses. While many in the field were holding their collective breath, fearful that new requirements would render existing security infrastructure obsolete and/or require significant investment in new technology, initial indications are that the revisions will make the lives of midsized businesses a little easier and resolve some open debates related to the phrasing of the requirements found in PCI DSS. The language changes will settle many of the nitpicking disputes that often take place on PCI DSS message boards. Of course, I'm certain that those disputes will quickly be replaced by other disputes that will be resolved in PCI DSS 3.0! All kidding aside, barring any critical changes in the security landscape, organizations adapting their business processes to comply with PCI DSS 2.0 may feel confident that these requirements won't change again until the October 2012 Community Meeting. Stay tuned for the official release at the end of October!
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity.com, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.
This was first published in October 2010