Anton had an interesting post up yesterday titled "Five Reasons to Dislike PCI DSS – And Why They Are WRONG!". As per usual, it's decent writing, EXCEPT that poor Anton is wrong himself (not to mention that he listed 5 "wrong" things, but then the fifth he says "right" to - a little confused by that!:).
So, the two "wrong" reasons that I take issue with are:
1. PCI DSS is a distraction from “real” risk management and security: WRONG!Anton elaborates on them further (read his post for the full details).
2. PCI is just checklist security: WRONG!
Here's the thing, I why I have to disagree with him... perception is far more important than reality. Just because the PCI Security Council actually intended for a risk-based approach, and just because they did not intend for it to be checklist security, does not mean this is in fact how it is perceived, let alone used. The fatal flaw is that the preamble of PCI in the beginning (v1.0) did not start "the following may appear to be a prescriptive checklist, but it is instead a way to benchmark organizational maturity using a risk-based model." The fact of the matter is that the PCI DSS does not define risk, does not tell you to setup a risk-based model, does not talk about maturity, etc. They tell you prescriptively what you have to do to become compliant. It's really a hideously bad thing, precisely because of Anton's #3 ("We “got compliant” and now we are breached – it’s PCI’s fault: WRONG!").
The folly behind all this is: if you tell people specifically what needs to be done to achieve compliance, they will do that, and only that. It's the path of least resistance. And no matter how much you disclaim that "PCI compliance does not make you hacker proof" people will still think that compliance == security. Is this right? No. Does this make sense? No. Well, sort of. The problem is that people (generically) still do not fully understand information security. The feedback loops simply don't exist in the brain yet for understanding and reacting to infosec.
So, to Anton, and others, I say that the PCI DSS has brought us to this failure scenario precisely because it used the wrong approach in communicating its mission and intent. The goal stated has always been one of compliance, rather than one of risk reduction, risk resiliency, or proper risk management. The reason we know the goal has always been compliance is because it's mandatory to meet all of their prescriptive requirements. This makes PCI DSS checklist security, whether they intended it to be that or not. Why? Because that's the path of least resistance - the easiest way to get that box checked.
Comments (3)
"If you tell people specifically what needs to be done to achieve compliance, they will do that, and only that."
That's true --- for the subset of organizations who wouldn't have even implemented all of the baseline PCI DSS security measures in the first place.
Look, I know the constant refrain that compliance != security, and in some cases, compliance inhibits security, diverts scarce resources away from more effective measures, and can give a "false sense" of security.
However, the entire payment card industry is based on a shared trust model. Acquiring banks, issuers, merchants, and processors all need to handle data with a minimum baseline of security controls. When a single entity fails, many "innocent" partners and individuals take a loss.
We could let each organization determine their own risk profile, assess, and customize a control set that is most effective for their organization and release them from oppressive and ridiculous chains of PCI DSS. However, how would you even start to assess the security of your partners in that trust chain if they all went off and did their own thing?
"Proper" risk management requires understanding the transitive nature of trust and risk with the people you do business with. PCI DSS attempts do to that for a very complex and diverse environment. Compliance-oriented activity and checklists are a critical component, like it or not.
What people continue to forget about PCI DSS is that it is a prescriptive set of security measures for the payment card system ecosystem - not for just a single organization. It is intended to strengthen the weakest links in the chain of trust, not replace your security program.
Posted by Cory Scott | April 10, 2009 11:23 AM
Posted on April 10, 2009 11:23
Thanks for writing this; this totally inspires me to write a follow-up post :-)
Posted by Anton Chuvakin | April 10, 2009 1:08 PM
Posted on April 10, 2009 13:08
@Cory Scott:
"the entire payment card industry is based on a shared trust model"
I think you've hit on a key issue here, and one of my major bones of contention with the PCI DSS. Rather than fix the problem directly through improved technology in the cards themselves, the card brands have instead decided to pass the buck. Rather than add another $5/card in cost, they're asking each merchant (L1 and L2, anyway) to shell out $1m and up PER YEAR for compliance. And then they still get hacked. What problem has been solved here?
Let's talk about one very straightforward solution. All data on the card should be block encrypted and should only be decrypted by, at least the bank, and ideally by the card brands themselves. Merchants can store that encrypted block all they want, it won't harm anything. Then you shift the responsibility for protecting the PAN itself to the bank and/or brands.
I think that doing something like this would then shift the focus to implementing strong auth. But, the good news here, is that you /can/ come up with a one size fits all strong auth solution that is then mandated. Then you can reduce much of the DSS to something straight-forward, sensible, and easily implemented: system security and physical security.
Barring this, I think that PCI DSS needs to mandate a risk mgmt approach, probably related to a maturity model of some sort (SSE-CMM, for example) and that builds off a more standardized security approach (e.g. ISO 27001), but one that is graduated/flexible to better match the needs of the wide range of orgs. PCI should not be so concerned about spelling out in painful details exactly what to implement on your network. They should be concerned that companies have good risk assessment, risk mgmt, and a security program to support it all. Good security == Good security.
Posted by Ben | April 13, 2009 5:59 PM
Posted on April 13, 2009 17:59