The Increasing Irrelevance of PCI

Submitted by Mike Rothman on Mon, 2009-01-26 09:20.
Today's Daily Incite

January 26, 2009 - Volume 4, #9

Good Morning:
Quick intro today, since I spent most of my allocated TDI time ranting about PCI. It's got a major problem of relevance, given the second (that we know of) massive data breach on a PCI "compliant" organization. So what will they do? Let's just say I have some ideas about what they should do... 

PS: Last call for the Pragmatic CSO Forum I'm launching with the Business of Security folks. We start the Forum sessions tomorrow, so this is the last opportunity you'll have to learn the methodology. We're running a promotion now for anyone that signs up for the Forum will get a PDF of the book included.

Have a great day.

Technorati: , , ,

The Pragmatic CSO

The Pragmatic CSO:
Available Now!

Read the Intro and Get
"5 Tips to be a Better CSO"

The Increasing Irrelevance of PCI

This is a hard post for me to write. I've been a big fan of PCI, pretty much since it's inception. It was a lot more specific than previous regulations. I may not agree with all of the requirements (like the AV mandate), but at least there were a list of things that merchants could do to start on the road to security.

I'm a pretty Pragmatic guy, so I knew that most folks would look at the 12 requirements and figure that's all they needed to do. That once the PCI Assessor delivered the report, that they'd be secure and their credit card data would be safe. Of course, they would be wrong - but I figured we needed to start somewhere and PCI was a good start.

PCI = FailAnd it was for a little while, but it's like sending your playbook to the opponent before the big game. Your adversaries know exactly how you plan to defend against them. It's not too hard to devise a new attack to circumvent those lowest common denominators. Which is exactly what the attackers that successfully compromised both Hannaford and most recently, Heartland did. 

I wrote on the eIQ blog about how I think we can add incremental defenses to protect against these new attacks, but that still doesn't answer the crisis of confidence facing PCI right now. Sure the 12 requirements are a good start, but clearly they are not enough and the general consensus-based process of updating the requirements means PCI is always solving the attacks of 2 years ago. For instance, the mandate to eliminate WEP from wireless networks is only going into effect this year. WEP has been severely broken for over 2 years.

So I believe the PCI Security Standards Council has some serious soul searching to do. The Council needs to act quickly and decisively to stem the rising tide of irrelevance. Or else they'll need to acknowledge that PCI is the next HIPAA and organizations will continue to due the bare minimum to comply, while secretly snickering at the ridiculous hoops they have to jump through to little benefit.

The first step is to announce they are going to do a 45 day review of the current set of requirements to determine if they are still relevant and to pinpoint gaps, maybe even publish some new guidance and clarification on the weakest requirements (or the one's that just aren't working). The first step is always the hardest, and thus far the public stance from the Council has been one of "not my problem." They only set the rules, they don't enforce them. That's the wrong answer, but it's the predictable one.

In terms of the massive change needed, as you would expect, I have some ideas about how the requirements should evolve. The reality is that security is not binary. No one set of guidelines is reasonable for every organization out there. Larger organizations (with more to lose) should spend more than a mom and pop shop. The current process of requiring a real assessment for Tier 1 merchants (as opposed to a self-assessment) tries to factor this in, but everyone is working off the same set of requirements and that's wrong. 

I would define a set (probably 3) of different security levels. The lowest level would be today's bar. We know it's not sufficient, but again it's a start. Then they add at least two more levels beyond that, including maybe a full monitoring level and perhaps an end to end encryption level, depending on the merchant's threshold for risk, their size and their willingness to invest in security.

The sad truth is that it's probably not cost effective for every retailer to get to the highest level. Even if they do suffer a breach, the cost of doing whatever the highest level may be (especially if it involves widespread use of encryption) may outweigh the cost of cleaning up the mess. Not for everyone, but for enough that requiring the highest level of security doesn't make sense for them.

Saving Private PCIBut how is this different? So what if there are three levels of security (that merchants can market to), where is the catalyst to get anyone to the highest level of security? Drum roll please.... the answer is TRANSACTION FEES. Merchants live and die on transaction fees. It's a huge part of their cost model and if they can reduce those fees, then investments can easily be justified.

I believe the only way to get retailers to adopt higher levels of security is to make it a good business decision. They need to be able to make a reasonable return on their investment, and then it will happen. That's the way free market economies work. Thus, we set different levels of transaction fees, depending on what level of security the organization achieves.

By the way, this makes sense for the upstream side of the equation as well. Given the potential risk of having a low level of security and the associated fraud costs that accrue to the system, issuing banks and credit card brands can also make money by reducing the transaction fees - for an increased level of security.

I've spent two decades paying attention to the drivers of what makes businesses do things. I've spent a lot of other people's money proving that you cannot make a market. Latent demand needs to be there based on a good business decision for the customer. They need to be able to either save money or make money by deploying technology. It's a simple as that. So it's just simple economics that drives me to believe the only thing that will get organizations to invest in security is to help them reduce their costs. If they can't see a clear cost savings, they'll do the least amount possible. Not many organizations do security because it's the right thing to do.

It's Monday and I guess I'm being a bit idealistic, eh? The likelihood this will happen is very small. There are a lot of folks within the council that can't afford to rock the boat too much, and the occasional black eye isn't enough to truly agitate for longer term change. So with each data breach PCI becomes weaker and weaker until it ends up similar to HIPAA. Unless something changes organizations will continue to pay lip service to it, customers won't trust it (to the degree they even know about it), and it becomes just another report that is generated out of the security reporting system, which is my definition of irrelevance.

Photo credit: “Fail (19/08/07 137)” originally uploaded by The Happy Robot

Submitted by Bob (not verified) on Mon, 2009-01-26 15:12.

Using transaction fees as a driver to get merchants and banks to adopt the Secure Electronic Transaction standard (SET) was suggested repeatedly 5-10 years ago, but the entrenched interests never went for it.  Since there was no financial incentive to adopt SET, no one spent the money to do so.

 I agree that it would work for security levels as well, but after living thru the SET debacle I'm not going to be holding my breath on this one.



Submitted by Mike Rothman on Mon, 2009-01-26 16:34.
No kidding Bob. I know there are a number of folks with their hands in the cookie jar and that will make it hard to get consensus on any kind of reduced transaction fees. But short of that, I think PCI will become less relevant and we'll continue to have to deal with periodic massive breaches of "compliant" companies.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.