PCI 2.0: Is that all there is?

When taking a look at version 2.0 of the PCI DSS Requirements, I am reminded of that famous song by Jazz singer Peggy Lee – “Is That All There Is?”

Commentary - As expected, PCI 2.0 rolls up a number of minor changes, but there really is no Big Bang in this document. A number of people have been disappointed by this since for the past two years expectations have been built up that version 2.0 would ‘cure all ills’.

In addition, many of the changes in PCI 2.0 were billed as clarifications, but it’s a fair and seemingly common view that these clarifications do not add as much or go as far as people hoped. This is true not only in the case of my own sphere of expertise – encryption and key management – but also seems apparent in other areas such as virtualization. Qualified Security Assessors (QSAs) hoping for a more explicit test regime and compliance managers hoping for a PCI playbook are both going to have to wait until the various Validation Requirements documents are released next year.

However, some progress has been made and there is hope that the PCI Council will address more in the near future as they have published a schedule for providing more concrete guidance and requirements for various technology areas (though by no means all) over the coming months. I expect these to contain much more of the information people have been hoping for as more of the detailed work from the Special Interest Groups (SIGs) is considered, along with further inputs from the Council’s own expert technical working groups.

For this version I simply suspect the Council is being very cautious in being seen to make any specific recommendations or endorsements and so is taking more time over things than implementers and vendors would like. Frustrating though this may be for some, it is hard to take back a recommendation so for now we’re seeing the ‘safe’ position.

That notwithstanding, the PCI 2.0 requirements do contain a few interesting and valuable updates which demonstrate that encryption, key management and Hardware Security Modules are important technologies to protect and secure cardholder data and to gain compliance to PCI DSS.

Requirement 3.4 has been updated to highlight the dangers of mixing hashing and truncation. This is a positive indicator for encryption: despite the slightly ironic historic position that encrypted data remains in scope because it is 'reversible', encryption schemes and key management are specifically designed to avoid these kinds of interactions and unintended side?effects. Short?cuts like truncation (and particularly a mish-mash of shortcuts all thrown together) are often not the best route to data security.

Requirement 3.4.1 has been updated to recognize the subtlety of removable media encryption. This is a positive indicator for Enterprise Key Management technology, since disparate media types may hold the same valuable information. We also see requirement 3.6.4 refer to NIST SP800-57 for key lifecycle management, which is a welcome reference to part of the body of existing, mature, independent guidelines and standards for compliance and security to which Hardware Security Modules (HSMs) are validated. Note that a major criticism of point-to-point encryption (also known as end-to-end) has been the immaturity of validation standards for it. A look at the NIST Special Publications and related established standards such as FIPS 140-2 will show that such criticism is at least a little unfair: we in the cryptography game have been doing this for a while, and while it has a new name and does offer new benefits to the market, P2PE does not need to throw away the mature validation framework of NIST SPs and FIPS.

Lastly, and possibly most interesting, are the changes to requirements 3.6.5 and test requirement 3.5.2b which overlap very neatly.

Requirement 3.6.5 has been updated to remind people of the need to retire keys if their plaintext values could have been exposed, with the note: “Retirement or replacement…of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key).” Now, it’s unclear how an organization reaches requirement 3.6.5 and still gives employees clear-text access to keys, but nonetheless this is a good warning and people should always plan for breach remediation. Alongside this new test requirement 3.5.2b says: "Identify key storage locations to verify that keys are stored in the fewest possible locations and forms".

These two changes together are a highly positive indicator for the use of HSMs with encryption: Any software system is fallible and open to accidental or deliberate copying of keys, accidental backups etc. With HSMs you always know exactly where all the keys are, all the time. Employees may use keys without hindrance in the normal course of their legitimate business, but they cannot see or take away the clear-text.

That’s it, small but interesting changes.

biography
Jon Geater is Director of Technical Strategy at Thales, a leader in information systems and communications security.