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.