The Failure Of PCI?

Wednesday, June 13, 2012

PCI Guru

Fc152e73692bc3c934d248f639d9e963

Steve Sommers of Shift4 has posted an interesting take on the PCI DSS and its value to merchants and service providers, particularly in the wake of the Global Payments breach. 

Steve has asked me to comment on his post and here is my take.

This quote speaks to the frustration a lot of merchants and service providers feel.

“The only thing PCI did was round up a bunch of existing security best practices, compile them into lists, and publish these lists as “guidance” documents.”

No doubt about it, the PCI DSS is an amalgam of various security “best practices” bundled together and published by the PCI SSC.  I remember back in 2003 when the PCI DSS was the Visa CISP, fresh off the presses as an Excel spreadsheet, still embedded with the review comments from Visa and the consultants that created the CISP.

But what are the card brands to do?  Breaches are occurring all over the place when they start down this road.  The media reports that so many Visa or MasterCard accounts are breached and then they talk about the merchant or service provider involved. 

Visa and MasterCard are trying to protect their brand names because studies show that the public remembers the card brand names, but quickly forget the names of the merchants or service providers breached.  As a result, they feel the need to develop guidelines to protect cardholder data to minimize the number and sizes of breaches.

Was life better when Visa, MasterCard, American Express, Discover and JCB all had their own individual standards?  You all complain now about one ROC or SAQ, how would you like to be filling out a different form for each card brand every year?  I would guess your answer is a huge ‘No’.

But the bigger question is, if not the PCI DSS, then what standard?  ISO 27002?  FISMA?  FFIEC?  HIPAA HITECH?  I have yet to find a security standard that everyone can agree on, let alone agree to follow.  People complain about every one of the information security standards.  And then there is that ugly mantra of “compliance is not security,” but I have already covered that ground.  So see my posts on why I think that saying is just a dodge.

All security standards are just a starting point or ante into the game.  A number of friends of mine have all remarked that their security programs only have to be a little bit better than everyone else’s to keep them off the target list. 

However, that is the key; you need to be better than the other guy.  But will the other guy tell you what he is doing when he has the same strategy?  Standards like the PCI DSS give you that benchmark to start from so you know where you need to be better than the rest.

But the biggest problem with standards all comes down to the fact that humans are really averse to being measured or assessed against a standard.  Why?  It makes people responsible and accountable for what they do and few people want that sort of accountability – we all much prefer “wiggle room” in how our jobs are assessed.

“Then the card brands attached fines and penalties to punish merchants if they failed to comply with PCI “guidance” 100% of the time.”

“To me, the issue is this: PCI SSC promotes their work as “best practices” or ”guidance”,  and then the card brands turn around and flog merchants for not following them when they are breached.”

Steve is right on the mark with these statements.  As he stated earlier in his post and what I frequently state here, security is not perfect.  All security does is reduce the risk of a breach but does not remove that risk in its entirety.  As a result, even with PCI DSS compliance, breaches will still occur, but the goal is to make them much less frequent and a number of orders of magnitude smaller in the amount of data released.

This brings us to the heavy handedness in how the card brands handle breaches.  All I can say is that some of my friends in the forensics field are telling me that there are a number of breaches that they have investigated that were not the result of PCI non-compliance. 

So Visa and PCI SSC GM Russo need to back off on their statement that “No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach.”  According to my sources, this is patently not true anymore and the card brands are not happy about that fact.

The card brands, in particular Visa, seem to refuse the premise that security is not perfect and keep pushing that the PCI DSS, if followed to the letter, is the solution to breaches. 

None of this is the truth and security professionals know those facts.  As a result, we end up with media quotes from the card brands, PCI SSC representatives and security professionals that are at times out and out asinine. 

Until we can all come to grips with these facts, we will continue to be playing a game of spin.  And spin get us nowhere.

“I personally believe that PCI is written in such a way – and interpretations among QSAs vary so much – as to make it impossible for anyone to be 100% compliant 100% of the time.”

The flexibility in the PCI DSS is there because security professionals and their employers would not have it any other way.  Would you prefer a dictatorial standard that specifically calls out solutions and vendors?  What would people be saying if only Cisco and Juniper firewalls, routers and switches were allowed? 

What would Microsoft say if Windows was not allowed?  What would other vendors say if only MICROS POS solutions were approved?  What if only VLANs with specific ACLs were the only allowed method of network segmentation?  Can you say lawsuits?

The bigger problem that the PCI SSC needs to address is the QSA/ISA training.  A lot of QSAs are great technologists, but would not know a good or bad control environment if it bit them in the posterior.  Fewer QSAs and most ISAs know controls, but would not know a proper firewall or router configuration to save their lives. 

And finally, there are a very, very few QSAs and some ISAs that know the technology and controls.  Unfortunately, the PCI SSC has not found the way to winnow out the QSAs and ISAs so that only the ones that know both technology and controls remain.

But even in such a perfect world, each QSAC has its own tolerance of risk.  As a result, what is PCI DSS compliant to one QSAC is not necessarily going to be acceptable to another QSAC because of the risk they are being asked to accept. 

Firms like mine are fairly risk averse, so we are going to be more demanding when it comes to what is PCI compliant than other QSACs.  But by the same token, I do not believe we are unreasonable in what we demand for PCI compliance.

At the end of the day, while the PCI DSS is not perfect, it does provide the following benefits to merchants and service providers.

  • It provides a way to help everyone learn from the other guy’s mistakes.  As attack tactics change, so do the PCI standards to address tactics that might not be covered.
  • It gives everyone the baseline of what they need to execute 24x7x365 if they even think they have a better than average chance at security.

Prior to the PCI DSS, Visa CISP and the other standards, it was a crap shoot as to whether or not an organization’s security was going to be up to snuff.  I do not think that is where anyone wants to go.

Steve, I understand your frustration and the frustration and pain of merchants and service providers.  But if what I have stated here is not a net positive, I do not know what is.  Is it perfect? 

Nothing in the world is perfect.  But there are some changes that would improve the program and make it seem much less painful and frustrating.  We just need to continue to work on the PCI SSC and the card brands to see the light and make the necessary changes.

Cross-posted from PCI Guru

Possibly Related Articles:
14889
PCI DSS
Information Security
breaches PCI DSS Compliance Best Practices Regulation QSA Standards Merchants Global Payments
Post Rating I Like this!
Ad5130e786d13531cc0f2cde32dacd0f
Andrew Weidenhamer Great post and especially agree with the below point in which you made:

“The bigger problem that the PCI SSC needs to address is the QSA/ISA training.”

I specifically point this out in my latest blog post (http://www.infosecisland.com/blogview/21567-PCIs-Money-Making-Cash-Cow-Not-So-Good-for-the-Industry.html).

I think the bigger question is who says the PCI SSC council wants to address this issue? QSA and ISA training generate a lot of money for the SSC and by making certification more difficult and potentially even a lab based test, many will simply decertify or simply not take it. Although this is good for the industry, it's not necessarily good for the SSC. It's like putting a GPS tracking device in golf balls. Sure, that would be great for golfers, but certainly not for golf ball makers.

Let's be honest, QSA's and QSAC's are looked at as a commodity now and often times companies are using 1) either QSAC with the lowest price or 2) QSAC that can be easily influenced. You rarely ever see QSA's, and far fewer ISA's, that are true security practitioners. You don't need to be able to have an in-depth knowledge of a certain technology to be a good QSA/ISA. You simply need to know someone that does that can help out or bounce questions off when needed.

One thing that might help is to start holding QSA's and ISA's personally responsible if willful neglect can be proved in the event of a breach. I know this might not be the most popular solution amongst my peers, but I think it would help. There would be a lot less people willing to become certified if they could be civilly sued in the event of a breach. This would add some needed credibility to the certification. I honestly believe that every time I perform a RoC that I am the best QSA on this planet (rightfully or wrongfully), and would definitely be willing to put myself on the hook in the event of a breach situation. Obviously, having this sort of target would come with a higher paycheck 

Just my 2 cents…

- Andrew (@aweidenhamer)
1339617127
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.