John Kindervag, prominent analyst from Forrester, released a report this week entitled PCI Unleashed, where he talks history, dispels myths, and gives practical tips for companies trying to get a handle on PCI DSS.  John doesn’t waste any time getting started, and throws out a couple of points to shock the reader.  In fact, I’m kind of shocked they are in there, but it’s refreshing to see an organization of Forrester’s stature putting them into writing.

While many agree that PCI DSS should be blamed on the payment brands, John asserts that it should not.  While I agree that the result (the standard itself) should not necessarily be blamed on the payment brands, its evolution is a direct result of their global success of electronic payments and the fast paced growth of technology.  We live in a world where RSA-768 has been factored.  Theoretical attacks are becoming possible, even practical, with clustered computing.  While much of the original payment system was designed on computers with limited (even precious) resources, systems today don’t have the same constraints.

Unleashed, by Mr. Littlehand

John asserts that PCI DSS is necessary to the progression of information security, and companies that suffer the most burden from PCI DSS did the poorest job implementing basic information security processes as they grew.  If nothing, PCI DSS was arguably the first “regulation” to force the issue, and is still the only one that has proactive teeth in the form of fines that motivate companies to comply.  The rest of the regulations (at least here in the US) are put in place to allow for recourse after an event happens.  PCI DSS tries to help companies prevent a breach instead of providing a vehicle for litigators to go after the boardroom.

The second point is one that I’m surprised showed up in print, even though it is one of the popular theories on how PCI DSS came to fruition—a risk transfer.  I’m only surprised because this is a rather unpopular position among the payment brands.  Just try asking a rep from a payment brand if this is why PCI DSS was started, and you might learn a new way to answer a question without actually answering it.

Next, John throws down three specific myths, all relevant and accurate.  So relevant and accurate, that they are in our PCI Compliance book as well!  If you go back to Anton’s slide deck from a presentation he gave last year, John’s Myth 1 corresponds to Anton’s Myth 3 and John’s Myth 3 corresponds with Anton’s Myth 4.  John’s Myth 2 is a theme that Anton talks about throughout his myth presentation, but is not specifically called out.

John talks about enforcement, and when you read that part you need to take into account what he is trying to convey here.  Payment brands do enforce PCI DSS, and in fact are the only enforcement arm ((See here for more info on roles.)).  The Council does not enforce PCI DSS, approve compensating controls, make exceptions to the rules for companies that plead and beg the most, or review ROCs for compliance.  Any enforcement action comes from the payment brand and rolls down to the Acquirer.  What he is trying to say is that the payment brands don’t actively review ROCs from merchants (unless they suffer a breach).  The payment brands hold Acquirers accountable for any Merchant’s action, and if an Acquirer tells the brand that a given merchant is compliant, the brand accepts it at face value (see the point following this one).

Another area John comments on is making PCI DSS your underlying security framework.  That one liner is very dangerous by itself, and should an executive read this you will most likely fall into a compliance vs. security argument.  He does say that PCI is the “open source of compliance,” which really is to say that it is freely available and widely discussed.  I argue that you are better off taking lessons from ISO 27002 and building your framework around that, and then you don’t have to worry about things like PCI, HIPAA (HITRUST or HITECH), GLBA, Mass Law, or whatever else is being thrown at you.  Use PCI DSS to force the issue internally, but make a case for an over-arching framework to build your security program around.

Finally, take a look at the PCI Unleashed framework.  It’s another phased approach type document, and worth a read as you figure out what your next steps will be in your program.  As with most elements of information security, you will likely adapt anything “standard” out there to better fit with your specific business.

This post originally appeared on

Possibly Related Posts: