Last updated at Wed, 19 Jul 2017 18:09:51 GMT

Recently I've been diving into some advanced and targeted analysis features. Today I'd like to keep things simple while still addressing a significant use case - Vulnerability Regression. Often times the immediate response to high visibility vulnerabilities does not involve setting up future monitoring, leaving the door open for the same vulnerabilities to show back up time and again.

[RELATED: Vulnerability Regression Monitoring [VIDEO] | Rapid7  ]

The Immediate Response - AKA Fire Drill

Sooner or later, for better or worse, everyone hits a fire drill.  You probably know the situation - late nights, high pressure, and a lot of leadership visibility.  It's a find-fix scramble under a microscope, and it's no fun.  Some slightly dated examples (more on that later) include: Shellshock, Heartbleed, and, for those of you with air-gapped networks, BadUSB.

My question is - what happens when the smoke clears?  Everyone takes a deep breath, some pats on the back, a cold beverage or two, maybe even a day off to recuperate before post-mortem reporting begins.  Unfortunately, when the immediate response ends is often when the real visibility gap begins.

The Regression

Over time these vulnerabilities have a way of reappearing.  Maybe an old system gets booted up when it was supposed to be deprecated, or maybe a new system gets rolled out with some old software installed on it.  One way or another, older, high-visibility vulnerabilities can come creeping back into the network.  I picked these examples intentionally, because I still see them in the field after all this time;  I even see them even in environments where a fire drill was run and considered a complete success.

Regression Monitoring

Without ongoing monitoring for regressions, any immediate response action is inherently a point-in-time fix and not a systematic remediation or root-cause resolution.  The idea of regression testing has been around for quite some time in the development world, and I think there's a huge value to applying that same concept in the security world.  Here's a quick example of how to set up a basic Heartbleed regression check in Nexpose:

Create a Dynamic Asset Group (you'll notice a trend - I use DAGs a lot, they are pretty neat):

Set up a filter for "Heartbleed" based on Vulnerability Title:

Click 'Search' and then 'Create Asset Group' as per usual.  If you create a Dynamic Asset Group the group membership will automatically be updated each time you run a new scan.

Conclusion - More Success!

There you have it - a simple, easy way to set up regression monitoring for high visibility vulnerabilities.  Go on and set up a few of these - you might just be surprised what you find!

For those of you who want something a bit broader than single vulnerability searching, check out my piece on the usage and value of Vulnerability Categories.