Is PCI 6.6 good for web application firewalls?

PCI requirement 6.6, which endorses web application firewalls, raises the profile of this technology but leaves a lot to be desired. Requirement 6.6 is a part of Section 6, which deals with development and maintenance of systems and applications. Sections 6.1 through 6.5 are all sound, dealing with issues such as patching, change control and secure development practices. At a glance, Requirement 6.6 seems sound too:

"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. "

One issue with the text is that it puts two very different techniques against each other. Organisations are going to choose only one technique to achieve compliance, where, in reality, they should be using both. Looking past that, the wording works very well for web application firewalls, in the sense that most organisations are likely to choose to deploy a WAF rather than go through a very long and very expensive process of code review.

And that is exactly what causes me to worry: organisations looking for PCI certification are going to choose web application firewalls because they are the less ugly choice. Not because of the merits, of which there are many.

As someone making a living from web application firewalls, I should probably be more optimistic about the whole affair. After all, there is no doubt the level of interest in web application firewalls is rising, in no small part due to the PCI standard. The sales are increasing too. And I am sure many organisations will attempt to use the products they've purchased; some of them will like them. PCI 6.6 may actually lead to a wide adoption of web application firewalls. But it still troubles me that many of the purchases of this remarkable technology are going to be made for the wrong reasons.

At the moment the addition of web application firewalls to the PCI standard looks like an afterthought. There is a slight danger that the products will be bought and installed, but not actively used. The PCI standards needs to give WAFs at least the same treatment it currently gives to intrusion detection systems: prescribe not only the installation, but a continuous use, including various options such as blocking, detection-only deployment, virtual patching and the use of WAFs for traffic logging and monitoring.

Comments

[Vishal Garg]

Hi Ivan,

First of all I want to say that it was nice talking to you last week and also having some discussion about the issue at hand. I completely agree with you. Although I am not against PCI but I think that through this requirement PCI has unintentionally mixed two different concepts. They have created a case for either/or for these two methods to meet PCI requirement 6.6, while I would assume that these are complementory to each other and we cannot ignore one for the other. I had also discussed the same issue in my blog post few days ago. The link for the post is at: http://webappsecurityinfo.blogspot.com/2008/01/pci-compliance-web-application-firewall.html

Cheers
Vishal

[lyalc]

Being a PCI QSA, I have a slightly different take on the debate between code review and WAFs.

PCI is first and foremost concerned with protecting card data from misuse/unauthorised disclosure. PCI is not a perfect security environment, just better than the average (even today) protection of card number confidentiality.

In the light of PCI, code review and WAFs provide essentially the same outcome - the application is either expected to have much fewer security bugs thus having better protection of CC data, or the site can more rapidly react to stop flaws in the application from being exploited (long before the typical bug fix cycle of investigation, code, test, deploy etc can do ), thus having better protection of CC data.

The other method of complementing WAF solutions is PABP/PA DSS. PA DSS ensures that third party payment processing code meets certain benchmarks for protecting CC security, with annual review cycles built in. So PA-DSS and WAFs provide, in theory at least, for stronger protection for CC data.

The rest of the company's data and systems - well, PCI doesn't care about them from the compliance angle - but adopting PCI-aligned processes, especially in PCI section 6, helps improve the security posture across all sites I've seen so far.

lyalc

[Joe User]

The PCI DSS and all the associated hype around it is nonsense and taken beyond its original intent, just as SOX reporting has degenerated into the egregious waste of time it has become today. Your purported insight reminds me of a Big-4 consultant discussing his misguided value-add advice about Sarbanes Oxley.

[xbar]

This topic is sort of a bait and switch. I don't really see much of a discussion about whether or not PCI is good for WAFs.

The PCI requirement will drive the adoption of ModSecurity because it is free. It will drive the adoption of other WAFs because vendors will create additional value beyond ModSecurity.

3rd party code reviews will have lower adoption because they are more expensive, more difficult to prove completeness, and they include additional risks: code theft, loss of trade secrets.

If it's "good" for WAFs to be more widely deployed, then PCI will be good for them. But some apps will gain absolutely nothing from them except a checkbox on a PCI report.

[Scott Sattler]

The PCI requirement has enabled Information Assurance groups within corporations to acquire the budget necessary to implement these types of controls. In that respect is has helped immensely. Almost every customers is suffering from poor software development efforts leading to systems that can be easily compromised. They are not likely to invest in source code review tools, such as Ouncelabs or run time assessement tools like SPI or watchfire. These application firewalls have enabled security groups to remediate software development problems without causing shochwaves within the application development groups.

Scott.