PCI: Version 2.0 Might Catch Some By Surprise

The release of version 2.0 of the Payment Card Industry Data Security Standard has left some merchants out of compliance. But there is still time. While 2.0 has been released, version 1.2.1 based reporting is still accepted through Dec. 31. [See New PCI Standards Finalized.]

Little actually has changed in the new version, as PCI Security Standards Council General Manager Bob Russo was quick to point out when the council announced the new version release. Assessors are still assessing against the standard. Merchants and service provider validation requirements are the still the same. In fact, if you were compliant in the past, there was nothing terribly new. But if you had once sought shortcuts or attempted granular inferences, 2.0 may indeed prove discomforting.

Clarifications in 2.0

If your organization ever sought to escape the stringency of the DSS by theorizing that it was only applicable to electronic cardholder data, the new guidance should clarify that even you must comply.

Secondly, the standard's use of "system components" was given a more inclusive definition. System components include all virtualization components, such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops and hypervisors. Virtualization was further integrated into requirement 2.2.1's limitation to one primary function per virtual server or device, though whether or not DMZ-based and internal network zone devices could be virtualized within the same physical hardware was not clarified.

Among the 314 other clarifications included in the new version and guidance, several other points are worthy of mention:

• The standard applies to issuers and recognition was given to their need to securely store any retained sensitive authentication data.
• Requirement 3.6 allows the use of cryptoperiods, rather than solely annual key rotation. If the impact of annual rotation has proven burdensome and the risk posed by less frequent key rotation is low, this should be a welcomed change. [See NIST Special Publicaiton 800-57 for more information about the standard cryptoperiod.]
• Requirement 3.6.6 was clarified as requiring split knowledge and dual control for manual clear-text cryptographic key management operations only. For those using dynamic key management appliances, this should already be a native function.
• Requirement 6.2 included the use of risk rankings for identified vulnerabilities as a best practice until June 30, 2012, after which it becomes a requirement. To accomplish this, NIST Special Publication 800-30 are suggested resources. Further, most organizations will likely find that documenting all operating system related critical patches as being "high" risk easier than ranking each individual patch.
• Requirement 12.3.10 added the ability to copy, move or store cardholder data on local hard drives and removable electronic media for authorized individuals; presumably, however, many will be challenged by scope implications.

It may sound counter-intuitive, but 53 testing procedures were added to simplify assessment and compliance management. Most of these are breakouts of the requirement verbiage. For instance, what had been listed as bullets under 4.1.a is now broken out into 4.1.a-4.1.e.

Redundancies also found in v1.2.1, which related to internal and Web-based application requirements 6.3 and 6.5, have been consolidated. Now, 6.5 includes the SANS CWE Top 25 and CERT Secure Coding best practice references.

Nevertheless, many hot button items, such as tokenization, remain open to interpretation. Questions surrounding tokenization, virtualization and physical hardware remain unanswered? For now, and potentially until 2013 when release version 3.0 is expected, we may be left to wonder. In the meantime, for those looking to adopt 2.0, take a look at the PCI Council's tips for understanding the guidance: Navigating PCI DSS: Understanding the Intent of the Requirements.

About the Author: Peter Spier is the manager of professional services at Fortrex Technologies and president of ISACA's Western New York Chapter. Spier holds a master's degree from Syracuse University's School of Information Studies and has more than 12 years of experience. He is a Certified Information Systems Security Professional (CISSP), Certified in Risk and Information Systems Control (CRISC), Certified Information Security Manager (CISM), Project Management Professional (PMP), Qualified Security Assessor (QSA) and Payment Application Qualified Security Assessor (PA-QSA). He also is certified in Information Technology Infrastructure Library (ITIL) Foundation version 3 and holds HITRUST Common Security Framework (CSF) Assessor certifications, among other credentials.