This is the next in a series of blog posts where we will be going through the internals of Vulnerability Manager as well as our future plans. The hope is to explain the approach we have taken as well as solicit thoughts on improvements or different approaches we may want to look into. You can submit bugs and feature requests here.
An advantage of having all of your organization’s application vulnerability information centralized and in a structured and open format is that you can start manipulating this data. One useful thing you can do is to generate real-time protection for you applications that sit behind IDS/IPS or web application firewalls (WAFs).
Most IDS/IPS systems are very focused on network and infrastructure protection so making their rule languages work for web applications can take a little bit of work but it is possible. WAF rule languages tend to have better native constructs for monitoring HTTP traffic so those rules can be a bit easier. But basically, once you have an attack surface location (URL, vulnerability type, possibly a parameter) as well as an idea of what attacks looks like you can create rules to look for that sort of traffic.
When we were originally looking at this functionality I wanted to make it completely automated. You find vulnerabilities, upload them to the system and – WHAM – virtual patches are automatically sent out to your IDS/IPS sensors or WAFs. Once you have the rules you want to deploy this is pretty simple, from a technical standpoint: SCP the rules to a device, send a process a HUP signal and the rules get reloaded. Or some XML-RPC variation on that theme. All the software developers I described this to thought it was totally cool. All the IT Operations and Security Operations folks I described this to looked at me like I was crazy. Apparently most folks aren’t quite ready to take the human totally out of the loop in the virtual patching process. Fair enough.
Based on that feedback the “tech preview” version of the Vulnerability Manager generates the virtual patches as text in the browser so that they can be copied and pasted into a separate file, inspected by a human, and then pushed live on the blocking device. This doesn’t make for as cool of a demo as a fully automated solution, but it ended up being more usable for the way organizations are using these technologies today.
We’ve been talking with some folks who might be more comfortable taking the person out of the loop so down the road when people are more comfortable with the interaction between the different technologies we will look again at making this totally automated.
dan _at_ denimgroup.com