One thing that surprised me in the aftermath of Shellshock was the concentration on vulnerability management—I was surprised because this was a patch management problem, pure and simple.1
This was a case of, “If your system has BASH, you need to patch it.”
Your affected assets should have been ‘known’ in your asset management system; patch application should have been managed through your patch management system; and third-party black boxes should have been managed by your system acquisition and vendor management processes.
These are all security controls, they exist in the ISO and NIST security frameworks, but they always seem to be overlooked – groups other than security not only have tools, but they know how to use them!
In my last post, I wrote about how these events should be a time for us security professionals to come to the fore but we have to be careful. In operational terms, this was an infrastructure IT-owned issue and, for them, it should have been business as usual. Patch management has to be the most exercised security control in any environment. Whether it is out of band or general patching, the cause is irrelevant – assess, identify, test, apply.
So if this was business as usual, where does vulnerability management come in?
Vulnerability management is the control you use to make sure the other controls are working effectively. It provides assurance of a job well done. It allows you to communicate this fact to your organization, your auditors, your customers and anyone else you have to.
So how does vulnerability management provide this assurance?
- Vulnerability management can actively discover any asset on the network, whereas asset management is dependent on various processes.
- Vulnerability management reflects a reality as up-to-date as your last scan, whereas asset management may or may not reflect reality depending on how well maintained it is.
- Vulnerability management can actively test every machine to see if it is still vulnerable after patching is ‘complete,’ whereas patch management relies on the job output.
- Vulnerability management can identify those third-party black boxes, while vendor management is dependent on its acquisition process.
In short, vulnerability management will find if any of your patch relevant controls are not working.
If vulnerability management can do all that, why am I so down on its role in something like Shellshock?
My point is that vulnerability management should not be leading the charge. By using it in that manner, you are adding additional steps that should be superfluous and breaking what should be a standard operating procedure. Let patch management get on and do its thing while using vulnerability management to make sure it is done well.
Another point is that, although situations like Shellshock need this level of activity to be able to answer the specific questions about whether or not you are vulnerable, vulnerability management is the best candidate of all security controls for continual testing.
It should be continually assessing the effectiveness of your other controls. In this way, you can drive improvements throughout these controls during quieter times so that when you are faced with yet another Shellshock, it truly is business as usual.
1Well not as simple as initially thought! Apparently after this bug had lain dormant for 20 years, vendors were in such a hurry to address it, they ended up having to release not one, not two, but six related patches!
- Security Slice: Bad News BASH
- Shellschock(ed)? How Did Your Security Program Do?
- How to Detect the ShellShock Bash Bug On Your Internal Network
- Shell Shocked: Bash Bug Detection Tools
Check out Tripwire SecureScan™, a free, cloud-based vulnerability management service for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the Heartbleed and Shellshock vulnerability.