Monday, June 22, 2009

On “PCI Letter”

So, the infamous PCI letter (PDF), an ultimate FunRead (tm) :-), is revealed by Martin. In my analysis below, I hereby promise to remain civilized, even though it would be a trifle too hard at times ;-)

The letter starts on a jarring note, namely, the claim that all merchants “take data security seriously.” This definitely helped me learn a new synonym for the word “ignore” :-) It then follows to mention that despite such HUGE attention to data security, it is hard for them to comply with the PCI standard….


So, item #1 about “incorporating formal review and comment phase on changes to PCI DSS” shows that the writers never looked at “Lifecycle Process for Changes to PCI DSS” (PDF), prominently featured at the PCI Council website. How can one miss it? Beats me. The council document does say that “Changes to the standard follow a defined 24-month lifecycle (!) with five stages, described below. The lifecycle ensures a gradual, phased use of new versions of the standard without invalidating current implementations of PCI DSS or putting any organization out of compliance the moment changes are published.” Specifically, “The second stage allows for market input into evolving PCI DSS through a formal feedback process.” In light of this, I fail to see what the letter writers really mean here.

They also mention ASC X9. Have you ever heard of ASC X9? Yup, my point exactly… The last RSA show had a couple of panels that mentioned X9.111 “X9 Guide to Pentesting,” which probably proves its wide industry adoption.

Item #2 asks for extensions to PCI 1.1 that otherwise “sunsetted” in Dec 2008. I agree that WEP need to be in use for another two years… NOT! Other than that, the differences between 1.1 and 1.2 (detailed here [PDF]) are so minor that needing another year sounds…well… a wee bit disingenuous.

In the next item, #3, they ask for a standard to include “end to end” encryption. Awesomeness ensues ;-) No, really!! It is pretty awesome.

Following that, the item #4 asks for marking “key controls” and for overall “control rationalization.” The former request seems well-served by the recent “Prioritized Approach for DSS 1.2” [PDF], which explains what to do first, second, etc. However, most people agree that more than 224 sub-requirements can use some rationalization. For instance, I am now trying to comb the PCI DSS doc for all the references to vulnerability management; and I am finding that some rationalization would be handy. For example, why does anti-malware belongs in “vulnerability management” theme, and not in “building secure network” theme?


Final #5 firmly treads into bizarre as it rehashes the idea that brands make merchants store card data, while in reality they are begging them to stop doing so (e.g. Visa’s DropTheData site, Mastercard Security Rules, etc)

It ends on a funky note: “today most of the risk and financial burden for operating in compliance with PCI DSS is borne by the merchants.” Funny, they’d mention it, given that most of the financial burden for replacing cards “lost” by the merchants and resulting fraud is borne by the issuing banks.

Here is something else funny: the letter mentions Sarbanes-Oxley act twice as an example of how regulation should be done. No comment here…

In any case, I don’t think this letter is “mostly smoke and mirrors meant to draw attention away from the fact that many merchants don’t want to spend the time and money to become PCI compliant” (as Martin points out), it does contain interesting insight on how many organizations [that we buy from on a daily basis] view data security and regulatory compliance.

There you have it. Thanks to Martin for posting the letter!

UPDATE: PCI Council responds via a podcast at CSO Magazine site.

Possibly related posts:

Dr Anton Chuvakin