Neil MacDonald

A member of the Gartner Blog Network

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Coverage Areas:

Link Web Application Firewalls to Dynamic Application SecurityTesting Tools

by Neil MacDonald  |  January 9, 2012  |  6 Comments

I called this a “security no brainer” years ago and the advice is absolutely still relevant today.

In Gartner’s latest Magic Quadrant for Dynamic Application Security Testing (DAST) solutions for clients, one of the evaluation criteria we looked at was whether or not the vulnerability knowledge of the DAST solution could be exported and used by a web application firewall (WAF – for example Imperva, F5, Citrix, Barracuda, DenyAll, ModSecurity, Bee Ware, etc ) to protect the vulnerability application from attacks (note that this is conceptually identical to using network or host-based IPSs to shield from attacks on endpoints until patches can be applied)

Before I start a firestorm of comments, let me be clear: we believe the vulnerable application should be fixed if possible (just like vulnerable endpoints should ultimately be patched). WAFs should be viewed as a way to shield vulnerable web applications until they can be fixed/patched. However, this isn’t always possible in a timely manner. Sometimes the backlog of applications in development prevents a timely fix. Sometimes the organization doesn’t have the expertise to fix the application because the person that wrote it has left (or the development was outsourced/contracted). In other cases, there may be limited access to the source code. Regardless, what if we’ve got a vulnerable web application that we can’t fix in a timely manner?

That’s where DAST/WAF integration comes in. Most DAST solution providers will link directly to WAF providers to provide specific protection from a vulnerability. The DAST tool discovers the vulnerability and the WAF helps to shield from attacks on that vulnerability. Makes sense doesn’t it?

Here’s a couple of things to keep in mind:

  • Look for explicit WAF support. Some DAST solution providers will talk about exporting vulnerability knowledge in XML and how this could be consumed by a WAF… leaving out the part where you have to perform the translation from a generic XML-based representation of the vulnerability into the native WAF rule syntax. Make sure both your WAF provider and DAST solution provider state explicit out of the box support for this integration.
  • Even with explicit integration, don’t expect DAST vulnerability information to flow to a WAF without requiring human intervention and testing.
  • Favor DAST solutions that allow you to quickly and easily retest/replay a specific vulnerability with the WAF in place to confirm that the protection is working as expected.
  • To check for false positives, use testing scripts or recorded sessions to exercise the web application with the WAF rule in place. Favor WAF solutions that can place new rules in a “monitor only” mode for a period of time before being placed into blocking mode.

If you haven’t evaluated DAST solutions recently, it is time to take another look. The market continues to evolve rapidly. If a vulnerable web application can’t be fixed in a timely manner, don’t leave yourself exposed. Look for explicit, out of the box support for WAF rule generation in your next DAST or WAF solution evaluation.

6 Comments »

Category: Application Security Security Intelligence     Tags: , , ,

6 responses so far ↓

  • 1 Geraldo Fonseca   January 9, 2012 at 11:51 am

    I couldn’t agree more, but it sounds contradictory that neither IBM nor HP (which are the leaders in this MQ) have explict WAF integration.

  • 2 Arian Evans   January 9, 2012 at 12:58 pm

    Great points.

    The integrations IBM and HP have built (and Qualys, and probably most others) work only by blacklisting the explicit string-values their scanner uses to test. So basically they only block one attack-vector, or unique attack-string, at a time. They do not try to block the vulnerability as a pattern, or as a whole. Because of this it is relatively easy to bypass these limited “rules”, and you can wind up needing a lot of these limited rules to protect one simple vulnerability. You wind up with > 40 unique XSS signatures generating > 40 rules to protect one HTML attribute that really only needs one “” escaping rule. Too many rules and the WAF or IDS cannot scale.

    What I see end up happening is that WAF users wind up blocking only a few strings…enough to block their scanner and give them a false sense of confidence. Then their pen-testers get past these limited rules with ease, which is why WAFs used this way get such a bad reputation with pen testers. It isn’t so much a failure of the WAF, as it is a limitation of the integration. The integrations are focused on implementation-level syntax, and not the tactical level of the overall pattern to be protected. Integrations that mature to focus on the latter will require less human intervention, and be more secure. F5 and Imperva are the only two I see trying to step things up on the WAF side. However – the noisier the scanner, the harder this will be for them to accomplish from the data.

  • 3 Rafal Los   January 9, 2012 at 2:31 pm

    Geraldo – that’s actually not true. I work at HP and we absolutely have integration like that with our TippingPoint platform, announced recently (http://www.hp.com/hpinfo/newsroom/press_kits/2011/risk2011/NA_Transform_TippingPoint.pdf) and I advise you to take a look at the offering. It is not a generic integration with WAFs per-se, but it works great for the masses of HP TippingPoint and Fortify customers (or at least having one or the other).

  • 4 Geraldo Fonseca   January 9, 2012 at 3:41 pm

    Rafal,

    I failed to interpret “out-of-the-box vulnerability shielding protection via integration with TippingPoint” as “WAF integration”, which is the term Gartner used for all other vendors (whether they offer it or not). Sorry for the misunderstanding.

    Which reminds me that I haven’t seen a WAF MQ yet, although I think there was one planned for 2011.

  • 5 Neil MacDonald   January 9, 2012 at 5:00 pm

    Right, I was talking about WAFs in this blog post.

    However, it is true that intrusion prevention systems such as HP TP, IBM ISS, Sourcefire and others have WAF-like capabilities. They provide applicaiton layer decodes of http/html streams and can be programmed to provide protection much like a WAF. “WAF-like” is a good way to describe this and this could be used to shield a vulnerable application in much the same way as a WAF – with the same limitations on rules/signatures described by Arian above.

    For example, in our evaluation of DAST solutions, several of the vendors provided explicit exports for Snort.

    Not sure on the WAF MQ – I’ll ask Greg Young.

    Neil

  • 6 Neeraj Khandelwal   January 18, 2012 at 7:58 am

    Geraldo,

    Actually, IBM has had integration with Barracuda WAF for a while.

    Disclaimer: I work for Barracuda.