X
Tech

Security expert discusses a possible future for PCI-DSS... it's grim

Jeremiah Grossman discussed some recent comments about section 6.6 of the PCI standard made by Standards Council General Manager Bob Russo in a recent Information Security magazine article.
Written by Nathan McFeters, Contributor

Jeremiah Grossman discussed some recent comments about section 6.6 of the PCI standard made by Standards Council General Manager Bob Russo in a recent Information Security magazine article.  I found a lot of thoughts I share with Grossman.  Grossman says:

I have a love-hate relationship with PCI-DSS. Love it because it provides IT Security a firm lever to do something about web application security. Hate it because the way the process has been implemented.

Grossman also says (quoting Russo):  

They are going to, “clarify a lot of this stuff”, and the sooner they do better. One can only hope they do a good job because so far there is no authoritative clue to be had that I can find.

Russo, referring to the expensive and time-consuming process of manual code reviews, says in the article:

Personally, I'd love to see everyone go through on OWASP-based source-code review, but certainly, that's not going to happen.

That's pretty interesting... a "source code review" is what section 6.6a refers to?  Most of the companies that I work for seem to believe it simply means a black box review (how a hacker might see the review, no source, just a web application instance).  As Grossman mentions in his blog posting, I don't know that this "OWASP-based testing process" that Russo refers to exists, but I'm assuming he means a source code review that covers all of those findings discussed on OWASP (or at least on the OWASP top 10).

Ruso goes on to say:

So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do.

Ugh... a major step backwards for web application security is on it's way... wonderful.

Grossman mentioned on his blog, "... the council did the math as I have that the source-code review method is simply too cost prohibitive at scale. We're talking potentially billions in cost..."  Alright, that's understandable, this is way expensive; however, the Web Application Firewalls?  Talk about products with a poor track record.  Also let's think about what Web Application Firewalls are good at, signature-based protections.  So, yeah, they'll help with XSS and SQL Injection, although I'll go to the grave saying they don't prevent the issues entirely, but they have absolutely no capability to find a huge number of very serious security flaws, such as (off the top of my head and in no specific order):

  1. Authentication issues
  2. Authorization issues
  3. Arbitrary File Upload/Download
  4. Cross-Site Request Forgery
  5. Improper Error Handling
  6. Flawed Business Logic

Here's my solution, in the hopes that Bob Russo sees this article:

  1. Don't look for the easy way out, i.e. Web Application Firewalls
  2. Don't look for the solution that takes no thought, i.e. classifying all applications to have to go to the same process
  3. Don't cave to vendor pressure, i.e. scanning tools or application firewall vendors would love the counsel if they mandated the use of those tools, think lobbyists
  4. DO pat yourself on the back for trying to implement a standard to protect users of web applications
  5. DO create a strategy that adapts itself based on the sensitivity of the application, i.e. a source-code review SHOULD ABSOLUTELY be required for some applications, but should probably not be required for all applications.  Perhaps in those cases, the use of a black box review, or a Web Application Firewall (uughh...) will be enough.
  6. DO consider an adaptive approach per year, i.e. year one requires a source-code review, but year two and on would only require this for significant changes
  7. DO require that these assessments; however they are done, be performed by third-parties who are NOT the PCI certifiers.  This maintains independence as the company performing the review has no stake in whether the vendor passes the PCI or not.  The PCI assessor should use this third-parties report to verify whether section 6.6a has been met or not.
  8. DO reconsider the unlimited liability for the PCI assessor.  I honestly can't believe anyone would take this risk on to gain this work, it's absurd.  Some liability is fair, but what the hell?  Unlimited liability?  Crazy.

Alright, so I obviously have some strong thoughts on PCI and Web Application Firewalls.  Let's temper this a bit, I'm stoked that someone is trying to create standards that will guide vendors on how to keep their applications secure, but I am extremely concerned about the implications of a weak standard.  I think Web Application Firewalls are a great technology to have, especially when used in conjunction with web application security reviews, but if tomorrow we hear that the only thing a vendor will need to do to "secure" their web applications is use a Web Application Firewall, I'm done with online banking and shopping.

-Nate

Editorial standards