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.

Comments

[anonymouse]

So, does mod_security live up to those requirements?

[Ivan Ristić]

What I took from the PCI 6.6 clarification is that it is not the tool that matters, but the way you use it. The tool needs to enable you to do certain things, but it's not going to run itself. ModSecurity meets all the technical demands required by the clarification document. But to achieve compliance one also needs to understand his web application firewall of choice and use it properly.

[anonymouse]

I asked this question because I am researching mod_security, which led me to an F5 blog (http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/23/3477.aspx), which led me to this blog. As the author involved with mod_security, I figured you'd be aware of any issues between the PCI spec and mod_security.

Aside from that, I more than completely agree that any WAF tool chosen (whether an Apache module, or an appliance) does not make the whole solution. In fact, I refer to WAFs as partly a band-aid, at least in common perception, in that it is something that you put on and forget for a while, till it comes off. Like any powerful tool, it needs to be maintained properly and tuned to the specific needs.

PS: I just noticed you stumbled across that blog also. I suspected it was wrong, but thanks for finding your way there and disabusing us both! :)

PPS: How did you get to that blog hit piece anyways?

[Ivan Ristić]

I have a Google Alert configured to notify me of any mention of ModSecurity, that's all :)