Ivan Ristic

PCI Council clarifies Requirement 6.6, ends ambiguities

The PCI Council has just published the clarifications for the Requirement 6.6 of the PCI DSS 1.1 standard. The 8-page document dated April 15th (but not yet released in an electronic form, which is expected to happen tomorrow, on the 18th) significantly expands on the 7 lines of text of the original requirement. [Update (Apr 23): the document is now available for download.]

Overall, the clarification document comes across as very useful and well balanced. It basically lays down the options for the organisations looking for compliance, saying they can choose how to handle 6.6 for as long as they do it properly and stay within the spirit of the requirement.

Here are the highlights:

• Vendors of web vulnerability scanners and source code analysis tools are going to benefit from the clarification, because both are now explicitly mentioned as offering an adequate approach.
• Overall, I think the Council has gone to a great length to discuss how they don't want to see the automated tools (of any sort) used to just tick a few boxes away. Throughout the document they emphasize the importance of doing the job properly, and by qualified personnel. That is very encouraging.
• It is now clear that it is all right for an internal resource to perform a scan and/or a review, for as long it is not within the same organisational unit as those in charge of developing and maintaining the application.
• More than half of the document discusses web application firewalls, but doesn't really say much new, except to those who are not familiar with the technology. Although there is plenty of content—some of which is very useful—there is not enough space to cover everything one needs to know about WAFs. I think a better approach would have been to focus on what is expected of a WAF to do in the PCI role, leaving to other efforts (such as WAFEC, which is referenced in the document) to discuss what WAFs are and what they can do.
• By far the best sentence in the web application firewall section demands proper use of the technology, not mere installation: "Note that compliance is not assured by merely implementing a product with the capabilities described in this paper. Proper positioning, configuration, administration, and monitoring are also key aspects of a compliant solution." Well said. I would write it in the document in big bold letters.
• I also very much liked the mentioning of the fact that there are many products out there advertised as containing application firewall functionality, but that the organisation needs to ensure they are doing what is required from them—actually making sense of the application-layer traffic.

Overall, the document is a significant step forward. It expands what was a brief mention of several very diverse technologies into a solid recommendation how they are to be used to achieve compliance.

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.

Tide is turning for web application firewalls

There is a long-running tradition in the web application firewall space; every year we say: "This year is going to be the one when web application firewalls take off!" So far, every year turned out to be a bit of a disappointment in this respect. This year feels different, and I am not saying this because it's a tradition to do so. Recent months have seen a steady and significant rise in the interest in and the recognition of web application firewalls. But why is it taking so long?

Having been involved with the industry for many years, I come up with many valid theories to explain the apparent slow adoption of web application firewalls. Here are some of them: 

• It's a brand new type of product that requires effort to learn how to use. Articles, books and papers need to be written, conference talks need to be scheduled and best practices need to be established. We need a critical mass of people with access to the technology in order for discussions to take place and for users to start to be comfortable.
• Network security people are the likely ones to be tasked to deal with application security. To deploy a WAF one needs at least a minimal understanding of application security, but to achieve this, in a field where attacks are still evolving at a rapid pace, is not easy.
• Many organisations are yet to assign people to deal with application security full-time, let alone web application firewalls.
• It is often not clear who is supposed to manage the technology. Does it fall under network security or application development? Or should we assign it to the application security team instead (where it exists)? This decision is made more difficult by the fact that some web application firewalls can be deployed inline (e.g. as a bridge or a reverse proxy), where they impact performance (not necessarily in a negative way) and create a point of failure.

Above all, the perception seems to have been that web application firewalls are not something we cannot live without. At the same time, the opposite is true for network firewalls. This has to do with the differences in risk distribution in network security and application security. In the network application space virtually all organisations run off-the-shelf products on their servers. Once vulnerabilities in these products are exposed exploits are written. These exploits are easy to deploy in an automated and indiscriminate manner, and this sort of thing is happening on a massive scale. The likelihood of being hit by such an exploit is very high, although the damage coming from such an attack might not be. When you add to this the fact workstations (whose numbers by far outweigh those of the servers) are also targets, it becomes clear why firewalls are viewed as essential.

In the application security world most attacks are still carried out by hand. One reason for this is that people haven't started automating the attacks yet (but this is changing, as demonstrated by recent automated SQL Injection attacks); the other that most web applications, unlike network security products, are custom-developed and thus require manual exploitation. The net result is that some organisations are hit by application security problems and some others aren't, although most are equally insecure. Lack of mass-scale exploitation is contributing to the feeling there is still more time to act.

This, of course, is an illusion. Organisations without web application firewalls are playing a game not unlike that of Russian roulette, hoping they won't be affected. But in this game you get hit—eventually. It's just a matter of time. We are seeing the increased interest now because people are starting to get fed up with web application security issues appearing left and right. Every new day sees a new type of problem discovered. Every day we hear of a new massive attack with damages running into millions. (The Web Hacking Incidents Database project is particularly good at documenting these.) People are waking up to the fact that addressing their problems before attacks take place is going to be much less painful (and far less costly) than doing the same afterwards.

In other words, and to simplify greatly, we haven't seen mass adoption of web application firewalls so far because that market was too young. The time was not right. But it will be right this year. I think.