Integrating Vulnerability Scanners and Web Application Firewalls

Submitted by Ryan Barnett 6/6/2008

In case you missed it, Breach Security has teamed up with WhiteHat Security so that their Sentinel scanning service will automatically create custom ModSecurity rules for certain classes of vulnerabilities that they find in your web applications. This works with both open source ModSecurity installations and with the commercial M1100 appliance. If your initial reaction to this is not "Wow, that is cool!" then you probably have never been in the operational security position of having to protect public web applications. In order to paint a better picture of why this is a pretty slick integration, let me provide you with some background.

As I mentioned in my previous post - What's the Score of the Game - I feel that one of areas where organizations are failing, with regards to web application security, is that there is a lack of communication between the following three groups: Development teams (who are running source code reviews), InfoSec teams (who are running vulnerability scans) and Operational Security teams (who are running web application firewalls). These three teams each have unique perspectives on the vulnerabilities of the webapps and they should share their data with each other.

Speaking from my own personal experience, I used to lead an operational security team for a federal government customer. I was charged with defending the public web applications and had built some home-grown ModSecurity WAFs to allow me to implement virtual patches for identified vulnerabilities while the development teams tried to address the root causes. Unfortunately, much of my time was spent simply tracking down information about the vulnerability. Either the vulnerability scanning team did not always provide OpSec with the results or the development teams didn't want to provide details about their "Ugly Baby". So, I would get an initial statement that application X has an SQL Injection issue but with no actionable details (what host, url and parameter).

When I did track the technical information down, the next step was to analyze the details to see if it provided enough information for me to create an appropriate filter. This was hit and miss, especially if the vulnerability scans were not tuned or if the secure code review consultant didn't understand how to abstract out and explain how a remote client could exploit the issue. The point is that I spent a fair amount of time in the research phase.

When I did get enough information, I then had to create some ModSecurity rules and run through some testing to ensure that it functioned as expected and did not deny any legitimate traffic. I could then deploy the virtual patch in production in a logging-only mode until we could schedule a re-scan. At that point I could switch it into a blocking mode.

When considering the whole "Time to Fix" concept, the process I was going through was much faster then the actual source code fixing route, however it was still manually intensive and took a fair amount of time. This is where I believe that the real value of the Sentinel + ModSecurity integration shows by automatically creating these custom ModSecurity virtual patches, we are solving two big problems -

1. Shrinking the time to fix - the process is expedited as the WAF analyst does not need to manually research, create and test the virtual patch, and
   
2. Increased confidence in blocking - The virtual patch is a targeted negative security filter that will not block legitimate traffic.

One other added benefit is that many organizations do not necessarily have technical staff with the required skillset to properly create ModSecurity virtual patches. With this integration, you don't have to have a ModSecurity guru on staff to create the rules. It will very interesting as Whitehat Security starts to track the "Time to Fix" metrics of their clients and to see how the customers who have ModSecurity installed fair against those that are using traditional code change processes!