Ivan Ristić

The key to successful WAF deployment is getting the ownership right

While pruning my bookmarks, I stumbled across this fantastic post to the Secure Coding mailing list, from almost two years ago:

• Re: [SC-L] darkreading: PCI, web app firewalls, and software security

The first part of the email gives a great insight into PCI. The second part of the email is about web application firewalls, and it's equally interesting, exciting even. This sort of email is extremely important to help understand why web application firewalls aren't nowhere near the popularity as of network-level controls. The main issue is ownership, and almost everyone struggles with it.

Anonymous application security practitioner writes:

7) Web Application Firewalls (WAF) are alluded to in requirement 6.6 of
 PCI DSS v1.1 as an "application layer firewall":

 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.

 Notice that WAF is not required per se, but the alternative of inspecting
 all application code by an organization that specialized in application
 security is very seldom feasible. In fact, InfoSec first approached our
 team to do code inspections, but when we heard that there were more than
 1M LOC, we told them that this was impossible given our current team size.

 Code inspection *might* work for some small company who exclusively uses
 some custom code using CC info with something like a small, custom
 a shopping cart application, but it is not going to be economical for
 most medium to large companies.

 I also think that there is going to be significant push-back by
 companies where PCI audits are required. I wouldn't be surprised if that
 date gets pushed out to Jan, 2009. On the positive side at least, the
 PCI auditor who was interacting with our company said that we could
 configure an Apache proxy together with Ivan Ristic's "mod_security"
 and that would qualify as a legitimate WAF to satisfy section 6.6.
 So at least we can experiment on-the-cheap. (Of course YMMV at other
 companies; check with your assigned PCI auditor to see what WAF is
 right for you! ;-)

8) I personally have mixed feelings about WAF. Specifically, I have some
 anxiety about that app dev teams will start relying on the WAF to
 filter out the PCI auditors pen testing attempts rather than on
 correcting it within the application itself. I don't have too much of a
 problem of using a WAF to address DoS type attacks (6.5.9). (IMO, DoS
 attacks are often very difficult to handle within the application itself,
 especially when the app itself is using some J2EE container; addressing
 DoS at the app level almost always requires some significant amount
 of redesign which only complicates the app, making it more likely to
 be vulnerable to other vulnerabilities.) However, inevitably some
 clever 0-day is going to get past most WAFs, especially if they are
 solely signature based. (Those which are also anomaly-based *might* have a
 prayer.)

9) The dirty little secret that no one is talking about are the operational
 issues with WAF. Our company discussed possible use with WAF/XML firewalls
 years before PCI DSS made it "popular".

 We never got much beyond initial discussions because we couldn't
 identify any existing personnel within our company who had all the
 required skills to troubleshoot it AND would be willing to do so.
 (Think additional "pager duty".) We talked with stakeholders from
 InfoSec, our company's network engineering team who manages our border
 firewalls and routers, some *nix and Windows OS system administration
 teams, and amongst our team. I think there might be only 2, possibly
 3, people who have sufficient skills to operate and troubleshoot a
 WAF, and all of those people are smart enough to know that it would be
 a thankless job and they aren't really looking for additional opportunities
 to carry pagers. Chances are, we would have to probably hire a few people
 fully dedicated to this, but even then, there is the question where would
 they fit organizationally? One possible option not explored--because we had
 no stakeholders represented who could finance such a thing--would be to
 outsource the management of WAF to some managed security company such
 as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that
 isn't going to go away.

 At first, intuition would suggest at first that usual FW teams would be best
 suited (and that indeed is what most WAF vendors suggest), but for the most
 part, the usual FW teams' understanding of attacks at layer 7 is often
 very limited.

 If you or anyone you know ever comes up with a solution on how to address
 this particular issue, please let me know. I think it is a show stopper.

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.