New PCI standard version 2.0 has been finalized

Changes Minor, But Non-Compliant Merchants Won't Get Leniency

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

First and foremost, the new standard clearly spells out that the cardholder data environment includes "people, processes and technology" that touch the payments chain in any way. That means any entity that stores card data, processes or transmits card data, or touches authentication data must comply with the PCI-DSS.

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.

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.