David Gianna
October 8, 2010
The move to a risk-based approach to PCI-DSS rather than a compliance-based approach would enable the transformation of PCI-DSS from a compliance standard to a security standard. On the other hand, the PCI-SSC avoids conflict with other industry security standards, guidance, and recommended best practices by NOT trying to be a security standard. That much is true up to now.
For example, in the case of annual key rotation requirements in section 3.6, there is little ambiguity in v1.2.1, where an annual key rotation is required. If an entity feels that quarterly or monthly encryption key rotations are appropriate, then they have met and exceeded that standard. If the cryptographic cycle is longer than one year, then that organization has not met the standard.
In most cases, the real risk of compromise to otherwise protected data lies not in the age of the encryption key, but rather in the balance of section 3.6 requirements that are NOT addressed by key rotation – specifically the key generation, storage, distribution, and revocation requirements. Generate weak encryption keys, implement weak cipher strength, get sloppy with storage and distribution and allow anyone to arbitrarily change keys at whim – and the frequency at which you rotate keys matters little, even if you change them daily.
But is a QSA empowered to make risk-based decisions regarding the suitability of a client’s key rotation interval? Version 2.0 suggests this: conceivably a QSA may reject the practice of annual key rotation on the grounds that risk factors suggest a more frequent key rotation schedule, perhaps quarterly. If the organization does not meet the schedule mandated by the QSA, then that organization may fail the audit until such time that it meets the “QSA requirement.” The target organization may in turn argue that it has met the standard of PCI-DSS by implementing (and demonstrating) annual key rotation. They will cite “contempt of QSA” as the reason for their failure to comply with PCI-DSS. Who will referee this dispute? What recourse does either the target organization or the QSA have available to them, and what actions might they take to address the conflict?
Similarly, a QSA may determine that an interval of less than one year is appropriate, and that the cryptographic cycle should be five years. How has this met the standard? By the arbitrary judgment of the same QSA who insisted on quarterly key rotations for that (other) organization? If the QSA can demonstrate the risk-based approach used to determine the cryptographic cycle, would this be acceptable? How can this be demonstrated with a high degree of confidence? That is, how do we know that the QSA did not fudge some “voodoo” numbers to support his or her “risk-based” analysis? How will this be communicated to the Acquirers and/or Card Brands?
The only vehicle currently available to communicate deviations from the standard is the Compensating Control worksheet. In its current form, one can well imagine what such a worksheet would look like. But one would be hard-pressed to imagine that such a Compensating Control would convey a strong and convincing argument supporting a lengthy cryptographic cycle well below the minimums established in the PCI-DSS.