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.
