Share with Your Network
This is the week a great number of security professionals descend on to Las Vegas for the circus that is BlackHat and Defcon. Alas. I’m unable to make it out this year, so rather than drowning my sorrow I thought I’d write up a much belated follow-up to a BlackHat panel I participated in a couple of years ago. I did say it was belated didn’t I? ????
The panel was on the half life of security vulnerabilities and I was lucky enough to have several really great participants with me. Namely Richard Bejtlich along with the CISO from Heartland Payment Systems, the CISO of California and the head of security for a VERY large bank. There were certainly a lot of different views primarily because everyone was dealing with very different problems and cultures. But what really struck me were the questions from the audience and what they seemed to focus on and imply. It became very clear that almost everyone in the room (at least the vocal ones) thought of vulnerability remediation as patch management. While I did voice concern over this at the panel, expressing that pushing out patches was actually the easy stuff, I want to talk about it in a little more detail here.
My experience tells me that vulnerability remediation takes place via a wide variety of activities. There is, of course, the simple use case of pushing out a patch. But that’s just the basics of fixing a defect in off-the-shelf software and operating systems. What about the in-house written code? Your organization is on the hook for that, Microsoft isn’t going to provide a patch for you. Is the vulnerability a technical vulnerability, such as XSS, SQL Injection, CSRF, etc.? Or is it a logic flawthat may require architectural changes? Remediation may include mitigating activities, both temporary and permanent, such as creating a new rule in a web application firewall or turning off a piece of functionality. Of course there’s the actual modification of the source code to fix the root cause of the flaw.
There’s also plenty of mitigation that can occur even with off the shelf vulnerabilities. In addition to patching, organizations often will create new firewall rules, IDS/IPS rules, modify configurations, or even shut down services or infrastructure that are not worth the risk anymore. You may also want to mitigate your exposure through increased monitoring and response. Perhaps the patch will break the service or application and isn’t an option for your business. There are myriad approaches to mitigate these issues (and I haven’t even mentioned virtual patches).
So since there are so many ways you could possibly address a vulnerability, you’re also going to need just as many ways to test your remediation. Running a vulnerability scan against one of these mitigation techniques isn’t going to be a very useful test. How is the vulnerability exploited? Can you test using these methods or tools such as Metasploit or Core Impact? How do you test detection and response? You need to have a complete set of tools at your disposal — the right tool for the job. Oh and by the way, sometimes that tool is as simple as a browser or terminal window and the soft gray matter between your ears.
