PCI 2.0: Major Step Forward, If You Value Vagueness
Written by Evan SchumanAs PCI officially moves next month from 1.2.1 to 2.0, a series of small changes are opening the door to more QSA-to-QSA conflicts. For some, that move is good as it will allow for more flexibility. For others, the move will aggravate long-held concerns about interpretability, where a retailer may be ordered to do diametrically different things with a simple change from one QSA to another.
According to the draft of the PCI changes the PCI Council has been circulating for comment, there are indeed no major changes in next month’s updated standard. But as they say in Purchase, the CVV devil is in the details.
For example, consider changes involving how encryption keys should be handled. The current rule requires the keys to be changed “at least annually.” The concern about that rule had been that it didn’t make sense in many instances, where the keys needed to be changed far more often than annually.
But instead of shortening the timeframe for those changes, the new rule will require the time periods to reflect how the keys are being used. So far, so good. Says the new rule: “Verify that key-management procedures are implemented to require periodic key changes at the end of the defined cryptoperiod,” which it describes as “after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key.” That’s certainly reasonable.
The next line, though, expands the ways that duration could be determined, as in “as defined by the associated application vendor or key owner, and based on industry best practices and guidelines: for example, NIST Special Publication 800-57.” Which industry best practices and guidelines? NIST was offered solely as an example. What if standards are in conflict? This is a classic area where equally experienced QSAs could go in different directions.
“It introduces more ambiguity to the larger PCI world,” said Jonathan Lampe, a CISSP and the product management VP at Ipswitch. “It’s bordering on the circular when they talk about industry best practices, because they are the industry’s best practices. That’s an ambiguity that would have been better to avoid.”
Or consider PCI’s new risk-based guidance, which simply concedes that not all risks are equally dangerous and that applying something akin to medical triage is wise. Note, from the new version: “The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.” Here again, the Council’s intent is good and the change is most welcome.
-Marc
September 30th, 2010 at 10:27 am
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 other wise protected data lies not in the age of the encryption key, but rather lies 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 it matters little the frequency at which you rotate keys, even if changed daily.
But is the 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 the cryptographic cycle should be five years. How has this met the standard? By the arbitrary judgement 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? (i.e.: how do we know that the QSA did not fudge some “voodoo” numbers to support their “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.