There’s nothing wrong with the PCI DSS
Alex HuttonApril 6th, 2009
I’ve been reading, with no small amount of interest, about the congressional hearings surrounding the Payment Card Industry Data Standards (PCI DSS) that took place on March 30th. Over the last six months, various incidents and data breaches have renewed discussion about the Payment Card Industry’s Security Standards Council and the value of PCI DSS. It all came to a head on Tuesday in various testimonies given to the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology (or ‘SETCAST’ – see http://www.homeland.house.gov/hearings/index.asp?ID=185). I thought I’d take the opportunity to write my first blog post for Verizon Business to discuss why I think the PCI DSS is just fine.
THERE’S A STATE OF CONFUSION ABOUT PURPOSE
When you read criticisms or apologetics around PCI DSS, you’re basically seeing one mantra repeated commonly: “Certification/Compliance Doesn’t Make You Secure.” As my seven year old son would say – “Duh”.
Nevertheless, it was the crux of most of the “anti-DSS” arguments I read from the Congressional Hearings. At its core, I believe this mantra is the result of two significant misunderstandings about Information Risk Management (IRM).
First, there is no “secure”. There are only shades of “security”. We can be more or less secure, but some risk will always exist. Unfortunately for us, risk increases the more complex our threat, asset, control, and impact landscapes become. And in IRM, we’ve got fairly complex landscapes.
Second, PCI DSS isn’t what I would call an Information Security Management Standard (ISMS). That is, it is not a document that describes a process by which we manage, measure, and make decisions regarding what it means to be “secure” in our organizations. Rather, it is more of an audit standard. PCI DSS is not designed to tell people how to manage their IRM program. It is designed to prescribe certain controls determined (by the PCI council) to be effective at preventing (or detecting) breaches and to help someone (an auditor) find evidence that the organization has these things in place. As audit standards go, I’ve found that the PCI DSS isn’t too bad – really.
Ignoring the differences between security management standards and audit standards and then grouping it all under the umbrella of risk management is confusing at best. This confusion is at least partially responsible for the recent outcry and reevaluation of the effectiveness of PCI DSS. To truly manage risk, you need a Management Standard. And in Information Security, those aren’t easy to come by.
WHAT IS A MANAGEMENT STANDARD?
The modern concept of business management has its roots in F.W. Taylor’s ‘The Principles of Scientific Management’ (1911). Taylor and others were keen on the creation of efficiency and reducing variation in the manufacturing of goods. This included focusing on management by measurement, training and the creation of experience, documenting instructions, and the intelligent division of labor between those who do (the workers who actually perform the tasks) and those who measure (management). Ichiro Ueno is said to have evolved Taylor’s works into quality assurance (what we might call the predecessor of things like The Toyota Way and Six Sigma).
So if the science of industrial production management (which has a rather strong track record) would have us study efficiency and quality, then we might say that an ISM standard should focus on these things as well. I’ve seen quite a few programs that could benefit from greater efficiency in process and the reduction of things that create variation from “secure” (knowing that there is no secure, we should probably replace that term with the phrase ‘management’s risk tolerance’, but that’s another blog post for another day).
It should be obvious by now that PCI DSS is not built for management science. Nor, in the opinion of this commentator, should the PCI strive to implement an Information Security Management Standard anytime soon. The last thing I think our relatively immature industry needs at this point is a monoculture of management standard.
IF WE DON’T REALLY HAVE A MANAGEMENT STANDARD, WHAT DO WE HAVE?
The closest thing I’ve seen is ISM^3 (Full disclosure – yours truly has worked on the risk estimation portions of ISM^3 and so I’m a little biased). ISM^3 discusses metrics and maturity in a way that suggests that they should be used in the management of information risk. Unfortunately, ISM^3 may not be as specific as some readers would like at this point. I believe that’s primarily due to the relative immaturity of our industry. For example, we have no real consensus metrics, so ISM^3 can’t tell you where or how to go get many of the measurements we need. But ISM^3 is a start and might be applicable for the CISO who is hoping to take her organization beyond creating simple annual statements of compliance and running a quarterly vulnerability management program.
Tags: certification, compliance, Information Security, PCI, PCI DSS, risk, risk management
Great point about the difference between a management standard and an audit standard. The latter is a third-party’s idea of how to manage risk generically, as applied across the board to everyone regardless of their own actual risk considerations. It’s a standard that says, “If you won’t or don’t know how to manage your own risk, we’ll do it for you.” A management standard lists what you should use in making your own decisions.
Posted by: shrdlu on April 6th, 2009 at 3:10 pmAlex, I mostly agree with you…we have a fundamental what-was-first-egg-or-chicken disagreement with information security management and information risk management. More on what I think about what you think here:
Posted by: Vicente Aceituno on April 7th, 2009 at 8:42 amhttp://ism3.wordpress.com/2009/04/07/audit-standards-vs-management-standards/
PCI DSS is not fine. It has been sold as a way to “secure” credit card data. An entire industry has been built around it. If you are compliant with all 12 requirements then your credit card data is safe. That is what everyone bought, but like a shiny new flat screen from from Circuit City’s going out of business sale, when you open the box it’s cracked. And guess what, no refunds. If there is no credit card data stored, there is nothing to lose. That is what the industry should be working towards.
Posted by: GW on April 7th, 2009 at 11:11 am@Vicente – I responded to your blog post. Summary: *metrics hard*! Getting actual _meaning_ out of metrics? *much harder* ISM3 gets you off to a great start, but to actually get meaning from those metrics, I think the average IRM program would need to do more work on their own – and that’s what is missing from management standards when compared to how they’re used in other lines of business.
@GW – I can totally respect your frustration. I felt that way since I first started doing Mastercard SDP for retail clients back in the day. However, I think I’d like to encourage us as an industry to get over the “PCI doesn’t magically make me secure” griping and move onto what will actually tangibly, measurably reduce risk – management science with an IRM bent.
This won’t happen until their are maturity models, metrics, and predictive analytics, so let me again encourage you to recognize the PCI DSS for what it is, and do the research & work we need to start building risk reducing models. (BTW – this is what I took away from Adam Shostack’s book: The New School of Security).
Posted by: Alex Hutton on April 7th, 2009 at 1:25 pm@GW – I am wholeheartedly in the “don’t store data unless necessary” camp. However, it isn’t quite right that if you don’t store data, there’s nothing to lose. I think you’ll find our section on malware in the 2009 DBIR an interesting read when it comes out next week .
Posted by: Wade Baker on April 7th, 2009 at 9:32 pm@ GW
“PCI DSS is not fine. It has been sold as a way to “secure” credit card data. An entire industry has been built around it”
I am confused why anyone would get the impression that PCI was sold as a standalone and automated solution. No such thing exists.
Perhaps it would help to think of information security products in the same was as you were sold brakes on your car. The brakes provide a way to secure your car, and you could even argue the entire car is built around them. Proper driving and use of the brakes, as well as maintenance, is a critical component of maintaining safety on the road. In the same way, the PCI sets out controls that need proper maintenance and operation. This is quite different from opening a TV and finding it broken/inoperable.
@ Wade Baker
Correct. Several high-profile attacks, as publicly documented by the FBI and payment card response teams, indicate removal of stored data alone will not avoid the problem of malware designed to quietly sniff the wire, dump, parse and forward card data.
Posted by: Davi Ottenheimer on April 14th, 2009 at 8:30 pmi think the the slogan of “out of the box PCI DSS” is only marketing issue. we need to investigate and understand the protection. now days, my company is checking dotdefender which provides PCI 6.6 protection and protection against other application attacks, such as SQL Injection, XSS. this way we will have also the PCI DSS compliant and web application attacks protection.
Posted by: Moam Kiuv on April 16th, 2009 at 5:27 amThe problem with the PCI program is that it has been allowed to spin completely out of control. When first introduced, it was a best practices recommendation. So far, so good. Requiring significant transaction participants to engage external security auditors to verify compliance with those guidelines was also a perfectly reasonable step.
Unfortunately, what happened next was a virtually feeding frenzy of marketing hype, over-the-top security requirements, and — worst of all — an opportunistic pile-on by the card brands’ lawyers, who apparently realized the PCI presented a chance to pass along to the merchants the risks and costs of breaches. (Note, for instance, how the “Safe Harbor” provisions were removed from the PCI program.)
Today, the PCI program covers more than security: It has become a crazy-quilt of legal agreements between Issuers, card brands, PCI Council, QSAs, software vendors, acquirers and merchants, all designed to create a web of liability that can be exploited to recover fraud losses.
(For an excellent analysis, see “Who is Minding the Legal Risk around PCI?” by David Navetta in the April 2009 issue of the ISSA Journal at http://www.issa.org)
Most of the PCI requirements would be unnecessary if the card brands simply incorporated stronger security into their system architectures. Chip & PIN, for instance, pretty much puts an end to card fraud, yet the card brands have resisted adopting C&P for many years, citing “prohibitive merchant equipment upgrade costs.” Of course, virtually all merchants have had to upgrade their transaction systems for PCI compliance, in addition to costs for security audits, etc., so the “prohibitive merchant costs” argument is obviously nothing but a ruse.
It seems clear that the card brands are not terribly concerned about fraud, but only about how much the fraud will cost them, as opposed to what costs they can recover from everyone else. If they were not able to recover those costs then you can be sure they would implement a more secure architecture. The PCI program is just buying time for the card brands to continue exploiting merchants for the costs of operating an insecure infrastructure.
In Europe and elsewhere, C&P was mandated by law. Apparently, we are going to need that level of regulation in the USA, too, to force the card brands to properly address the inherent vulnerabilities of their woefully obsolete transaction systems.
Posted by: Angry Merchant on April 16th, 2009 at 11:32 pm