PCI Blog - Compliance Demystified

PCI 6.5 and the OWASP Top 10

In a recent post by Jeremiah Grossman, he comments on how the PCI DSS Requirement 6.5 mentions the OWASP Top 10 from 2004 when the latest version is from 2007.  Yes, we all know that this to be true, as he notes in his post, but to say that these differences matter is a statement of taxonomical nuance and not one of practical application.

Before I go further I’d like to say that I met with Jeremiah only once (at RSA this year) but from all accounts (Trey Ford) he is a nice guy and technically empowered.  Also, I have a high respect for Andrew van der Stock and the difficult job he has in codifying the OWASP list.  I’ve had conversations with Andrew over the years about the history behind OWASP and PCI and believe I know the reasons things are they way they are.  So let’s go…

To say that the PCI DSS should keep pace with another standard is unjustified.  The PCI DSS requirements have evolved over the years to remove any reference to an outside group or body and genericized its language over things such as file-integrity monitoring and web-application firewalls to accommodate a variety of business processes.  The Council updated the document in 2006 to version 1.1 and virtually eliminated the use of the word “periodically” in place of concrete terms such as quarterly, weekly, or annually.  I understand why this was done as I too thought that periodically meant every 10-20 years (*joke*).

Jeremiah says that due to this usage and reference to prior days we now are in a situation where:

That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF).

Dare I propose that Cross Site Request Forgery (CSRF) (more info here) and Remote File Execution (RFI) are really both simply “Injection Flaws”?  While trying to understand the OWASP list, a friend of mine, Rnast, gave me this bit of wisdom (and humor).  In fact A1, A2, A3, and A5 are all similar in one form or another and exist due to poorly coded web-applications, which in themselves are exploited via the injection flaws that exist in these applications.  Taxonomicaly these are listed as different vulnerabilities due to the initiation of their attack vector and how or what they exploit, but they have many similarities as well.  (Many thanks to Rnast for walking me through some of the more technical parts.)

So, taken literally, even using the 2004 data, which could not have been in the standard (v1.1) due to it being released in 2006 - one would still have to address Injection Flaws, which I would claim is almost 40% of the OWASP Top 10 in 2007!  To make a change, everyone should submit their feedback directly to the Council and propose they make changes for the next version of the standard.