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.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.