Deflated Debate

Section 6.6 still allows organizations that process cardholder data to choose between different scanning solutions or implementing a WAF, but by placing the testing procedure next to the requirements (it used to be in two separate documents in the version 1.1 era) and changing some of the words, it is now much clearer when scanning should be used.  This change shows that the PCI Council agrees with some of the thoughts that were expressed by Imperva.

This new section will help all Web Application Vendors demonstrate the effectiveness and operational benefits of WAFs over scanning. See the comparison below:


Below you can see a list of the changes:

• The Council makes it clear that public-facing web applications should be protected by web-application firewall (versus "an application layer firewall" in version 1.1).
• The Council makes it clear that applications need to be reviewed after any changes. Previously, this point was not part of the standard and was mentioned only in the testing procedure.
• The Council makes it clear that organizations should verify that all vulnerabilities are corrected. Previously, this point was not part of the standard and was mentioned only in the testing procedure.
• The Council makes it clear that organizations should verify that the application is re-evaluated after the corrections have been made. Previously, this point was not part of the standard and was mentioned only in the testing procedure.

Theoretically, code review provides a strong capability to remove vulnerabilities from an application. However, the reality of applications and deployments significantly reduce the actual effectiveness of code review. The real-world impediments to code review include the following:

• For many applications, the source code is not readily available or understood. This could be either because the application is a third-party application or because the original developers of a legacy application are no longer available to explain what they did. (in other words: without the source or application understanding, one will not be able to fix the identified problem).
• Applications (especially Web applications) change frequently so the focus of code review is a moving target with new vulnerabilities potentially being introduced at any time. In many cases, the application can change before a full review cycle has been completed.
• Attacks (again, especially Web attacks) also change frequently. Prior to three years ago, no code review would have found response splitting problematic. Then a paper describing response splitting attack techniques required developers to send the same code back to review.
• The need to correct the problems by fixing the code conflicts with the need to keep the web applications up and running. If the problems are not fixed, the organization has a liability problem.
  

Some issues can only be corrected in code. The most commonly cited example is logical flaws in the application, meaning that if the application was intentionally built to do something that is not secure, only rewriting the application can fix this issue. This is true to some extent, but a good WAF will provide ongoing monitoring information that helps to identify when logical flaws are being exploited.

With all that being said, organizations will have to use a Web Application Firewall as compensating control while fixing vulnerabilities. Why would anyone wait to implement a WAF and put his applications and customers at risk?

The debate is deflated. WAF it is.