PCI Compliance gets clarified and neutered (further)

PCI Compliance gets clarified and neutered (further)

Summary: At one point, I thought that PCI certification was a great thing.  Now I realize that it's not really about security at all...

SHARE:
16

At one point, I thought that PCI certification was a great thing.  Now I realize that it's not really about security at all... it's about money and responsibility and transferring ownership of risk.

The PCI certification just got a clarification:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

  • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
  • Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement. "

I originally saw this clarification on Ivan Ristic's blog, where he comments on the impact of this for Web Application Firewall companies and Web Application Security Scanning tool companies.  I want to make a point that I feel like the committee is completely missing... they state that their goal is to ensure that all web facing applications are "protected against known attacks"; however, this approach DOES NOT ACCOMPLISH THIS!!!!

Web Application Firewalls are designed to catch signature based attacks, which is outstanding as a lot of the attacks are signature like.  WAFs are capable of detecting attacks like SQL Injection and Cross-Site Scripting, which is fortunate as those are two of the most prominent "known attacks"; however, they currently struggle at this.  There's so many different ways of accomplishing these attacks and WAFs suffer when conditions exist like DOM-based cross-site scripting attacks.

Further, and most importantly, WAFs actually provide NO PROTECTION AT ALL against certain types of "known attacks"!  Consider the following:

  1. Authentication and Authorization Issues - There's no way that a WAF can protect a web application from flawed authentication and authorization models, which is definitely something a deep source code review of a web application would uncover.  Think about the Google Docs flaws that Billy recently pulled off.  That's a SERIOUS attack vector, but there's no way a WAF could protect you from this.
  2. Flawed Business Logic - Take this generic example, which I've actually seen in a live application... you've got a web application that allows you to purchase products from the site; however, when you go to make your purchase of a TV, you notice that the POST request actually includes a "price" parameter that is set to $10,000.00.  You decide that's just way to much to pay for a TV, and so you change it to $1.00.  The TV gets shipped, you are charged $1.00 and no one is the wiser.  Now you get gready and purchase another TV at -$10,000.00 and not only get another TV, but get a nice credit back on your credit card for the purchased TV.
  3. Vertical and Horizontal Privilege Escalation - Imagine you are using a lending site and request a loan for $100,000.00 eventhough you have terrible credit.  Now, imagine performing a vertical privilege escalation to the user role of a loan approver on the site and you decide to go ahead and approve your own loan.  Imagine another situation where you manage your 401K and you can horizontally privilege escalate to gain the rights to view/modify the data for another user of the site.  What's a WAF going to do to protect you from that???
  4. How about native code calls in languages like Java?  You think your WAF is going to be able to detect a buffer overflow attack?   How about a format string flaw?  Heck, having a WAF probably opens up the possibility to get hit with one of these attacks even more.
  5. Cross-Site Request Forgery - I could be wrong here, but I see no way at all that a WAF could prevent you from cross-site request forgery.  Jeromiah Grossman has had a huge amount of interesting discussions about this attack, so go check his stuff out.
  6. Taking Ownership of Content - When you allow a user to upload arbitrary files to your server (think gmail, hotmail, Yahoo, YouTube, MySpace, etc.) you put yourself at all kinds of risk (see my future BH Vegas talk (hopefully) with Billy Rios, Rob Carter, and John Heasman).  See some of Rios's latest stuff.
  7. Web Services - I'm not sure how effective a WAF can be at protecting a Web Service, or if they even have current provisions for that.
  8. AJAX - Again, I don't see how it could be easy for a WAF to prevent these types of attacks (think DOM based XSS like I mentioned before).
  9. Encraption - Home grown encryption and obfuscation can become an issue, what's your WAF going to do about that?
  10. etc.

Am I completely off base, or has the PCI group just neutered its standard?  I mean, I have tons of certifications, like my CISSP.  That doesn't make me a bad ass.  Does having a PCI certification mean you are secure???  I think not.

-Nate

Topics: Security, Browser, Hardware

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

16 comments
Log in or register to join the discussion
  • Straw man argument

    I think you are missing something, namely the first part of the section that you just quoted: [i]Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security[/i]

    I'll be the first to acknowledge that I know very little about PCI, but the section you quoted in your article seems to clearly indicate that the soon-to-be-required WAF is [i]not[/i] the end-all, be-all of application security! It's merely a [i]single[/i] part of what I'm sure is a huge list of other requirements. Your entire article is a straw man argument: "This one piece isn't enough, therefore the whole thing is bogus!"

    There may very well be serious flaws in the PCI requirements, and as I've said I don't know anything about them, but your article doesn't address anything other than "WAFs are insufficient, therefore PCI compliance is worthless". If there are other problems, your article would be much better served by at least an overview of them.
    Kromey
    • Try again, Straw Man

      Read the article again. It clearly states:

      "6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:"

      EITHER OF the following methods. So web application assessments, or WAFs. What do you think a company will do? Clearly they will chose the cheapest and the easiest, which is the WAF... unfortunately, it misses so much.

      To that point, I don't believe I said PCI was worthless (but I will re-read on that), I said it was neutered. Having a WAF is great, but it is not the end all be all of security, far from it in fact.

      To many people are after the magic blue pill that will keep your company secure by just buying something and employing it... it just doesn't work that way.

      By the way, PCI is a complex certification, you are correct; however, I contend that this section is the single most important piece of the PCI certification. Whether PCI people will agree or not is another story. However, that is why I say PCI is far from where it needs to be.

      -Nate
      nmcfeters
      • Ah, touche

        Should have read closer before tearing at your argument. You are right, and now that you've highlighted that point for my sleep-deprived brain I think I'm inclined to agree with you.

        Note to self: Read, then re-read, then ensure that enough sleep has been had beforehand before arguing with Nate!
        Kromey
  • RE: PCI Compliance gets clarified and neutered (further)

    test
    ivanristic
  • You are missing the point: it's about what can be done

    I am sorry to say but, yes, you are completely off-base. The PCI standard is not about what a particular approach (tool, technique, etc) cannot do. Quite the opposite: it's about what it can do. It is about taking a range measures to deal with a complex problem. In fact, when you take a look at the standard and, especially, the most recent clarification, you see that their advice is to follow secure development practices throughout, taking great care to emphasize that tools are only as good as the people using them.
    ivanristic
    • You are missing the point: it's about what COULD'VE been done

      Ivan,

      Much respect to you, I enjoy your blog, but I disagree with you. From my perspective, it's about what could've been done, and in my opinnion, companies will now read the guideance as if putting a WAF in place is all they need to do... why? It's all they need to do to prove compliance and that is all a company will do.

      Right now, security is driven by compiance, not vice versa. Don't get me wrong, I'm happy the certification says at LEAST they need a WAF, but it should've created recommendations based on the risk of an application, and thus also pushed a greater effort at securing the code.
      nmcfeters
      • Our security problems are complex and dirty, and so is the PCI standard

        The reality of our situation is that we are not going to be secure no matter what we do. There is only one real solution to the security problem, and that is to bring our software development and deployment practices to the level where they make everything we develop 100% secure. Since that is not going to happen any time soon, we are left with no options but to do whatever helps. There's a range of techniques we can apply, with each technique appropriate in certain circumstances, and no single one appropriate for every situation.

        The PCI council is doing exactly what you are asking it to do: telling everyone to adopt secure practices as part of the development lifecycle. But they are also recognising that there is a range of measures one could use to further increase security, and so they are telling the people to go for it.

        Web application firewalls have an important role in the overall scheme of things: they provide instant protection and instant visibility (often neglected, but hugely important), irrespective of the size and complexity of your web applications. You should continue to strive to perfect the code and make it free of security problems, but you are going to fail, and when you do, web application firewalls are going to be there to help ease the fall.
        ivanristic
        • Our security problems are complex and dirty, that's why WAFs don't work

          Ivan, you state:

          "The PCI council is doing exactly what you are asking it to do: telling everyone to adopt secure practices as part of the development lifecycle."

          Actually, and let's be very clear on this, I'm not sure anyone DID ask the PCI council for this. PCI was established by the credit card companies and someone is making a hell of a lot of money off of it. Have you seen how much it costs to get certified? Did you know that if you fail the tests, it get's progressively more expensive to retake the test... that is until you've failed too many times at which point they'll give you the answers... if you pay more money. On top of this all, PCI is truly NOT about security. It's about shifting responsibility. Companies like it because the auditors themselves have 100% liability if a certified site gets hacked.

          Further you state:

          "But they are also recognising that there is a range of measures one could use to further increase security, and so they are telling the people to go for it.

          Web application firewalls have an important role in the overall scheme of things: they provide instant protection... irrespective of the size and complexity of your web applications."

          Nope, sorry try again. State it how it truly is. They provide instant protection (and even that protection is dodgy in my experience) against the low-hanging fruit attacks, SQL Injection and Cross-Site Scripting. In my personal opinion, WAFs are not battle tested and still have many issues at even preventing XSS and SQLi, but that's besides the point... they most certainly do not provide, as you say:

          "instant security... irrespective of the size and complexity of your web applications"

          I'm not trying to just bash WAFs here, so don't get the wrong impression. I think they are a good tool that companies should add to their arsenal of protections and they can be a good stop gap while trying to fix underlying issues with low-hanging fruit types of attacks, but I need to make it clear that for complex applications, WAFs do NOT cut it, for all of the reasons I mentioned in my original post. There's just too many things they can't catch.

          Finally, the biggest problem with PCI is that no matter what it achieves with the rest of the process, Section 6.6 gives companies an easy out... putting in a WAF. They missed the mark so badly on what should've been required here that it really has neutered the certification.

          -Nate
          nmcfeters
          • The clarifications document is now available for download

            Nate,

            Since we can't seem to agree in full, I guess we should let the people read the supplement and decide for themselves. The file is now available for download:

            https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf
            ivanristic
  • Whose Flaw Is It Anyway?

    Point 2 doesn't sound like flawed Business logic. That's flawed Programming logic.
    MichP
    • Semantics

      It's the same thing... we call it flawed business logic, because its the business portion of the code.

      -Nate
      nmcfeters
  • Bull vs. Steer argument

    So there is still value for PCI then. If I understand you correctly, another way to restate your argument is to compare bulls to steer: both can pull heavy loads and make great steaks, but the steer cannot do all the bull can do. PCI would be the steer, for those who are still groggy.
    srobtjones9
    • More like Bull vs. Milking Cow argument

      PCI is just the standard that we are referring to... in your case, the Bull would've been a full blown source code analysis like what the first recommendation of PCI 6.6 says. The Steer would've been putting in a WAF.

      In my opinion, I say that the WAF is more like a milk cow... it's only really good for one thing (signature based prevention). In this case, that's just not enough. What I would've liked to see was two options, a full blown source code analysis or a blackbox (no source code) analysis of the web application. Additionally, the use of a WAF would be recommended.

      That would've done something to really secure the apps out there.

      -Nate
      nmcfeters
      • What about penetration testing?

        If a company has quarterly penetration testing and has a WAF doesn't that cover the bases?

        Ant
        anthonyf1
  • Some Perspective on 6.6

    The Source Code Review vs. WAF debate centered around 6.6 unfortunately usually ends up degrading into holy wars about the "proper" way to address webappsec issues. There is no silver bullet. You highlighted many different areas where WAFs can have trouble (some perform better than others) however source code reviews are not always an option, especially when you consider closed source apps and the costs associated with attempting to retro-actively go back to do code reviews on apps that are already out in the wild. Secure Coding as part of an SDLC process for a new custom code app is absolutely a best practice and 6.6 is not countering that.

    The other main item to consider is that there are two other requirements (outside of 6.6) that say you already have to do code reviews -

    6.3.7 Review of custom code prior to release to
    production or customers in order to identify
    any potential coding vulnerability.

    and

    6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities.

    So, 6.6 would be the 3rd time a code review was listed. 6.6 is attempting to address issues in one of two scenarios -

    - Custom Coded App

    There may be a lack of webappsec coding knowledge internal to an organization so that is why option 1 was created. You either need "bring in the experts" or now you can run a webapp scanner, etc...

    - COTS apps, those that are already deployed or cost issues

    This is where WAFs are very useful. Pandora's box is already opened and you have thousands of bad web apps already deployed. Going back to do code reviews on these apps are difficult (perhaps technically) but the main hurdle is cost.

    The bottom line is that, opposed to the "either" wording of 6.6, code reviews and WAFs are NOT mutually exclusive and even if someone opts for a WAF for 6.6, they will still be doing code reviews or they will fail other PCI requirements (as I stated above).
    rcbarnett
    • Which is why...

      I suggested black box reviews in the first place. Also:

      6.3.7 Review of custom code prior to release to
      production or customers in order to identify
      any potential coding vulnerability.

      and

      6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities.


      Neither of these provide clarification on who or how that review should be done. In my understanding, the guideance provided was in the area of having assessments done by a skilled third-party, depending on the section these other mentions of code review are located it could simply refer to an internal process of reviewing code.

      -Nate
      nmcfeters