No, sir, PCI DSS is STILL not the devil. However, the devil is in the details ;-) This post attempts to analyze some of the details and is inspired by a really insightful conversation I had with Joshua Corman of 451 Group. In particular, this post is about the devilish nature of some unintended consequences of PCI DSS.
Let’s start from something truly despicable (WARNING: vomit alert!)
the purpose of security measures is to minimize legal damage
after complete loss of all critical data (or after other EPIC security FAIL)
by claiming that “adequate protections were in place”
If this line does not cause you (assuming you work in security) to go into seizures, I am not sure what will (maybe a lightning strike will?) I can barely type it, in fact, it is so disgusting :-) This is the evil side of otherwise benign phenomenon called “diligence.”
What it has to do with PCI DSS and the devil? Let’s explore it.
Security programs built and run ONLY as “a post-hack lawsuit defense” are indeed despicable. And so are compliance programs that are “mistakenly” labeled “security program.” And I’ve long claimed that organizations that “magically” arrive at “all we need to ‘be secure’ is to deceive a QSA” have only themselves to blame for their intrusion losses. Despite that, we all agree that there are plenty of organizations like this; in the past they were just negligent and now they are “fake PCI negligent.”
However, now there is definitely a market for “fake PCI security”, “get compliant and think you are secure”, “free PCI compliancy”, “guaranteed secure web site seals” and other scams. All these shops were not in business a few years ago. In addition, given such market, other security vendors have dedicated efforts to compliance-focused tools – obviously at the expense of thereat-focused tools and functionality. “All we need for web app security is PCI DSS Req 6.6” is one example of it (“only 6.6” is clearly better than no web application security whatsoever, of course!) – and if most customers “only want PCI”, this is what will get built at vendor shops.
And “anti-assessor” features might not work as well against attackers.
As a result, it is hard to find a niche within a security market which is not affected by regulatory compliance. DLP (see discussion here)? DAM? It affects even those technologies which are not even when not mentioned/
That is not PCI’s fault, of course – but this unintended consequence of PCI is quite devilish. PCI certainly plays a huge role in improving security; however, through the above mechanism it does seem to play for the opposite team as well…
Now, some of these compliance-focused efforts are actually quite beneficial for security. If we treat compliance as “validated security” (see discussion after this post away for details), then evidence of security measures being deployed and being effective does not just make the assessor happy. It actually helps you run you security program better – and help prove its value to senior management. For example, PCI push for more logging clearly helped both compliance and security.
As Adrian said in his recent post, “They need to have WAF to comply with PCI, so they bought one, but no one mandated they use it effectively. Security professionals really care about security, but the executive management cares precisely as much as legal and finance tells them to.”
In other words, some of PCI consequences is The Devil – they make people focus on things that might be suboptimal from the security point of view. And they make some think that there are easy solutions for very, very hard problems….
Enjoy!
P.S. This is posted by a bot, all comments will be responded to when I am back.
P.P.S More on this in the future (treat this as Part I of the ongoing debate)
Possibly related posts:
