Mark Curphey - SecurityBuddha.com

I was asked by a journalist to comment on the problems with PCI. I have been meaning to summarize my thoughts on it for a while but have been putting it off due the sheer effort involved in rattling off all the problems and the lack of time. As Paul Graham says startups are not an excuse to make a lot more money than you would normally make in a short period, but an excuse to work a lot harder than you would normally work in a short period of time. As the CTO of an early stage start up that will be soon starting the hunt for angel funding, I am suffering from what Paul very accurately describes.

As such this post is far from complete and really a small set of bullet points of the issues. Hopefully it captures some of the big picture and allows readers to understand some of the debate. There are a lot of folks currently questioning the PCI and this post is certainly not highlighting anything new or unique. CSO Online has a recent blog Does the PCI Standards Council Have a Clue? for instance.

I think the problems can be grouped in a few key areas.

- The Business Model

- The Standard Itself

- The Way It is Implemented in the Real World

- The Way it is Enforced

This post covers the first two due to time constraints. A follow up post will cover the latter two.

The Business Model

I think the business model that’s has been created as a result of the PCI DSS is fundamentally flawed.

- The $150 Security Review - There are a huge number of items a qualified scanning vendor needs to check for. In section 1 there are 21 sub-sections alone. Most of the items require humans to look at things or ask questions such as Section 2.2.4 that requires all unnecessary functionality like drivers and scripts (whatever that means) are uninstalled. Some scanning vendors may well have a magic business model but how any security company can check for all of these issues for only hundreds of dollars a quarter is beyond me.  Some do. I posit that in the real world many issues are simply not checked for and these companies are accepting the risk of getting caught OR every scanning vendor is loosing money hand over fist. Rather than talk of fines for companies who were non-compliant, how about spot checks and fines for scanning vendors wo are not checking correctly? I bet if this threat were levied, the vast majority off scanning vendors would withdraw from the market immediately of course.

- Enron Anyone? - The vendor gets to choose who audits them. Of course the PCI folks would have to believe that vendors don’t have freedom of choice; they choose from a list of certified vendors only and so they really control it. But if I wanted to get certified and had things to hide, I would choose the company who will look under no stones and ask no hard questions. I would probably Google for prices and start with the cheapest service offering.

- Everyone’s a Security Expert - We all know that many people are viewing PCI as the next SOX. As such sadly every man and his dog is now claiming to be a security expert and jump on the PCI gravy train. We have seen dedicated blogs, books and PCI compliance technology all spring up; all over something which is clearly confused. Maybe that’s why the market is so hot, people need help interpreting the standards themselves and not in addressing the issues? My current acid test for information security competency is ”are they seriously claiming PCI is an effective and well written standard”?   Quotes like this “PCI is a MINIMUM baseline” make me cringe (and for the record I am not saying those particular guys are incompetent, just that this quote makes me cringe).  If anyone is using PCI as a minimum baseline for their information security program they have seriously big problems! If anyone is recommending it as a minimum baseline then…..

The Standard Itself

The standard itself is just badly written. Many sections are ambiguous at best and misguided at worst.

- WAF versus Code Review - Section 6.6 gives you a choice of a code review or installing a web application firewall or WAF. Ed Adams has it right when he says these things are not comparable if the PCI standards council has a clue. In general a Web Application Firewall can (most have poor performance and don’t but that’s another subject) protect against bugs as SQL Injection or Cross Site Scripting. What they can’t protect against is fundamental design flaws. A real world example I know about was a web site which took credit cards that had an insecure password reset mechanism. It allowed a malicious user to navigate to the password reset page, select the username of his choice AND enter the email address you wanted the password to reset and sent to. Yes that right, the attacker could reset the password of his choice and have it sent to his inbox! While this is an extreme example, at Foundstone we analyzed the types of issues we found during detailed assessments. http://www.slideshare.net/mcurphey/hack-in-the-box-keynote-2006/65. Web application firewalls would be “reasonable” at Data Validation (20.56%) and Configuration Management (13.77%) but far from able to protect from all of these issues. We estimated that they could potentially protect from 50% of the issues people should be concerned about and in reality only about 25% of the issues we found in real world applications. Whoever came up with this boolean was simply misguided. And all of this is before we even get into the fact that there is a code review and a code review. Which one is this? The kind my wife who is an account can do? What should she look for? The coding guidelines which aren’t coding guidelines referenced in the standard above?

- Ambiguity - As an example section 1.1.9 requires configuration standards for routers. My standard looks like this. “Unwrap, plugin and go”. It’s a standard. Do I pass? Security is a complex beast and while I understand the intent to make things simple and palatable, the PCI folks need to develop a set of router and configuration standards or reference some current ones if they are to make statements like this. This statement is reminiscent of what is referred to in the security world as a default accept rule and not a good idea.

- You Can’t Scan for the OWASP Top Ten - PCI references the OWASP Top Ten. It calls them secure coding guidelines which they are clearly not (see above). For a long time it’s been widely accepted in the application security community that even if the scanning tools could find application security issues with a high degree of completeness and accuracy (which they can’t) you can not scan for the OWASP Top Ten.  Let’s take A8 - Insecure Storage as an example which talks about poor choices of algorithms and insecure key storage. It is not possible to do this today with any degree of completeness or accuracy period.

 - The OWASP Top Ten Does Not Describe a Secure Web Site  - The OWASP Top Ten was designed to raise awareness for CSO’s and CIO’s about the issues. It is certainly not a description or prescription for a secure web site. As such it is simply not fit for purpose. I don’t need to elaborate.

That’s it for part one. By way of teasers here are two things that I will discuss among many others in the follow up post. At this point I am not sure when I will find the time but stay tuned.  

- Scanning Vendors Versus Scanners - The PCI are certifying a company and not individuals. What I have heard happens in the real world is the following;  vendors get certified. Some hire 3rd parties to get them through it.  This is wrong for obvious reasons. The folks that do this are essentially taking on the risk that they won’t get caught. Another way to look at it is that PCI are pushing the risk to the scanning vendors. The implementation of the business model means that scanning vendors often use humans and tools to get certified and then only tools to do assessments. The economic models forces this behavior. The vendors themselves are taking the risk but its not a good practice to let it happen. Again certification of individuals and spot checks are needed to clean this practice up.

 - Unclear and Inconsistent Advice from PCI - Jeremiah Grossman has a great post on his blog questioning the advice given to Billy Hoffman at SPI Dynamics. Hes spot on and there is lots more where this came from.  

As a final thought consider this.

The OWASP Top Ten (referenced by the PCI) talks about Broken Access Control. http://www.owasp.org/index.php/Broken_Access_Control and describes some scenarios and how to protect yourself.

“Forced Browsing Past Access Control Checks – many sites require users to pass certain checks before being granted access to certain URLs that are typically ‘deeper’ down in the site. These checks must not be bypassable by a user that simply skips over the page with the security check.”

As if irony itself is in play, at a security conference I was pointed to the fact that you can bypass accepting the EULA when downloading the PCI DSS by navigating straight to the URL. Sure, the site doesn’t do credit card transactions but it does seem a little hypocritical.

Bon Weekend!

Note throughout this post I refer to the PCI and PCI Data Security Standards Council interchangeably.