I just got an email from my director who's attending a PCI event in Las Vegas. It seems that the PCI Standards Council has finally released clarification to the often-debated Requirement 6.6 of the PCI SSC. In this section, the standard currently identifies two options: Application Code Review or implementation of Web Application Firewalls. The PCI DSS Information Supplement was completed in February and has a Release Date of April 15, 2008 (yesterday). It is scheduled for publishing online within the next week or so. Here is a snippet from the document:

The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

I think that we'll see a lot of good come out of this... it really broadens the options of what companies can and cannot do to satisfy Requirement 6.6. This doesn't mean that static source code review should be forgotten or discarded, only that there's now a cost effective option between the two previous options. This will benefit a number of companies, giving them an alternative that isn't as expensive as a manual source code review and also doesn't depend on the company's specific configuration of a web application firewall (Chris Eng of Veracode has a great post on why WAFs just don't cut it).

This also seems to be the exact opposite of what Jeremiah Grossman interpreted Bob Russo's recent quote as meaning. Instead of narrowing the definition the PCI Standards Council has broadened the definition. I guess this is the update/clarification that they mentioned in their response to Dennis Hurst last year.

Hats off to Dennis Hurst, Jeremiah Grossman and others in the industry, along with the PCI Security Standards Council. Many of us have been lobbying for clarification to these requirements and this is a perfect example of how things can improve if you have input from industry experts and responsiveness from the standards bodies. I won't get into debating the "responsiveness" side of the equation in this post, but the update has been made so let's move forward.

In the end though, it's up to the company interested in becoming PCI certified to decide which approach is the right one to take. While I'm sure a number of companies will appreciate this new option, many will deploy web application firewalls, and I'm sure many will still want the peace of mind offered by an exhaustive static code review.