No big bang in PCI 2.0

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 2 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.

However, progress is 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/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, in addition to 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.

That notwithstanding, the PCI 2.0 requirements do contain a few interesting and valuable updates which demonstrate that the encryption and key management 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.

Also, 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 Thales HSMs are validated.

Finally Requirement 3.6.5 has been updated to remind people of the need to retire keys if their plaintext values could have been exposed, and new test requirement 3.5.2b says: “Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.”.

This is 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 plaintext.

I’m intrigued to read in requirement 3.6.5 the new note: “[-¦] (for example, departure of an employee with knowledge of a clear-text key) [-¦]”. We all know that shouldn’t happen, right?

That’s it, small but interesting changes.