Everybody who has any relation to PCI DSS and payment data security has probably already read the “2011 PCI Compliance Report” report.
You have not?!
Well, you have a fine choice then: enjoy my highlights below AND THEN go read the full report; or just go and read the report now.
One of my favorite bits is again that “only 21% of organizations were fully compliant at the time of their Initial Report on Compliance (IROC). This is interesting, since most were validated to be in compliance during their prior assessment.” Read this carefully: this applies to organizations that ALREADY did an assessment (maybe more than one – and some as many as 4, I guess), RoC and all, the year before and were validated to be compliant at that time.
So, let me rephrase it for you for better clarity: “only 21 percent of organizations were fully compliant at the time of their Initial RoC” AFTER getting a compliant RoC the year before! Yet another rephrased version is (with tongue-in-cheek, of course): their PCI DSS (and likely payment security) success happens 1/year, but their FAIL is ongoing 364 days/year. So, please don’t try to approach me with “we were done with PCI DSS compliance in 2006”, since it is very likely that you are NOT done with it even now in 2011.
The report also shows that the organizations missed 22% of controls at the initial assessment – not a small number by any measure (and not the one that can be attributed to “bad compliance luck”or occasional control drift). It means that a large number of PCI DSS controls were not in place a year after the previous assessment. By the way, my research on maintaining PCI DSS compliance in the face of environment and guidance changes will be published within a few weeks – look for it here (if you have a subscription).
Just as last year, the report confirms that “organizations that suffered data breaches were much less likely to be compliant than a normal population of PCI clients”, serving as further – but still indirect! – proof of PCI DSS value for payment security. I am aware of the fact that such proof is indirect and does NOT constitute anything even remotely resembling “get PCI – never suffer an intrusion,” which is absolutely, positively, unambiguously false (as both brands and the Council will be happy to remind you, if you ask). On the other hand, “get PCI – improve your payment security” seems to work pretty well.
Also just as last year, the merchants and service providers “struggled most with the following PCI requirements: 3 (protect stored cardholder data), 10 (track and monitor access), 11 (regularly test systems and processes), and 12 (maintain security policies).” To me, there are no surprises here: “ongoing”, “regular”, “daily” simple spells “t-r-o-u-b-l-e.” Specifically, Req 10 and Req 11 are the bottom two by the rate of compliance. The report has a great explanation for it: “Examining this breakout against Table 1 [compliance rates per Requirement] shows that organizations are still better at Planning and Doing than at Checking [i.e. ongoing controls!] in 2010.” A mild surprise was that Req 10.6 ‘daily log review’ didn’t score as the worst one – “the most challenging sub-control appears to be 10.5.5: Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts.”
This year the report team has performed an interesting additional effort: “before we launch into another set of recommended practices designed to improve the way you attain and maintain compliance, we probably ought to examine how we did last year.” It is hard to summarize here, but pages 27-29 of the report will give you more insight on this than you ever wanted. For example, “Awareness of the DSS”, “Preparedness for assessment”, “Understanding of data flows”, etc do not individually correlate strongly with PCI assessment success, but ALL of the factors together do. In essence, to succeed with PCI DSS and payment security, you have to do several big things right in your organization. As a useful reminder to people who just want to buy the shiny new security tool (top-most and right-most, of course….), “no magic formula exists to guarantee success in all your future PCI DSS assessments and endeavors, nor is there a single method or process to improved security.”
Next I have a list of my favorite quotes:
“An organization may be able to pass validation in order to achieve compliance but then—once the QSA leaves—become lax about maintaining the degree of security the standard is designed to provide over time. As such, the goal of any organization should be to maintain its state of security at all times in adherence with the minimum baseline compliance requirements set by the standard” and “The organization might take notice of PCI while the QSA is on-site, but afterwards allow a significant portion of the necessary practices to erode over time.”
“The forensic investigator plays the opposite role to a QSA in this scenario [i.e. after the breach], as he or she answers the questions based on proving the negative rather than validating a positive” and “since this [post-breach] PCI quasi-assessment is less intense, and more subjective, than a “normal” PCI assessment, there is a possibility that the IR data may actually show an optimistic picture of the breached entities’ compliance by requirement.” [in other words, post-breach assessment is NOT more rigorous than your QSA test, contrary to what some merchants believe]
On a related note, I had a pleasure of attending PCI Community Meeting 2011. It looks like a few changes are coming soon from the Council, including more predictable flow of supplemental guidance, new SIGs to deliver such guidance, as well as other efforts to make PCI DSS work better for securing payment card data. And if you are looking for a truly excellent summary of the Community meeting, look no further than this blog post from my PCI book co-author.