Effective Vulnerability Management (Part 2)

In part 1 of my write-up on effective vulnerability management I discussed the need for organizations to move beyond the endless cycle of scan and patch and towards a more reasonable and effective vulnerability management approach that stressed beginning by defining the desired configuration state of environmental assets against a security configuration standard, auditing the environment to identify non-compliant elements and enforcing compliance by remediating non-compliant systems, basically security configuration management. Although not a new concept SCM has not had wide spread adoption due to the disparate nature of security and operations team within most organizations. This disparity is changing as organizations realize that embracing security as a critical discipline within IT and the business is mandatory for success.

In this posting I wanted to focus on effectively responding to new threats and vulnerabilities. I am not talking about incident response, attack analysis, or forensics, as these are disciplines that are instantiated once something actually happens. I am referring to how an organization should respond to critical vulnerabilities; especially those with exploit code or attacks occurring in the wild, prior to an incident actually occurring.

The response to critical vulnerabilities even when there are active exploits has been to try and rapidly patch affected assets. This presents many challenges (see Note 1 below) and can be disruptive, logistically challenging, and in some cases an unavailable option. Organizations must look to incorporate a wide range of mitigating controls to shield the environment from attack prior to removing the root cause of an exploit. Essentially the response should be shield then remove the root cause, which in most cases becomes shield the environment and then patch, upgrade or remove the vulnerability or exposure.

Scan and patch = ineffective

Define policy, audit against policy, enforce policy + shield against emerging threats = effective

The recent vulnerability that Microsoft announced on April 12th (here) highlights the issue. A critical vulnerability, actively exploited and no available patch forces organizations into firefighting mode – in fact most organizations become so accustomed to responding to these events by patching that when a patch is unavailable they become almost paralyzed or turn to mitigating factors that are potentially far more disruptive than doing nothing, such as deploying a 3rd party patch. This recent vulnerability is certainly not the first time an actively exploited critical vulnerability has caused significant organizational angst, in 2006 the WMF vulnerability (here) or creatextrange vulnerability (here) proved to be very difficult for most companies to deal with.

The above examples highlight issues in dealing with rapid patching against a Microsoft environment, an area where most organizations have established fairly mature technologies and process – what if we turn to other areas of the network where neither vulnerability management technology or process exist or are ineffective, such as the networking, database (here) or application environments.

So how does an organization shield against attack? They must incorporate and facilitate coordination of all network and host-based technologies as part of their vulnerability and threat management program. In the case of the recent Microsoft DNS vulnerability there were clear work-around provided that included registry changes and firewall blocking rules to prevent exploit. Of course this level of organizational command and control would require technologies and processes that support rapid modification to environmental variables. But how is that different from delivering a patch quickly you ask, well there are several differences to note. First it requires an organization to coordinate response between multiple groups, which is a good thing since they have traditionally not worked well together, especially in the areas of security, networking, desktop and server support, and database or application administration. Second modifying a firewall, host or network based, to block ingress or egress traffic on a particular port is far easier and timely than trying to deploy a patch, not to mention rolling back the change requires far less effort and environmental disruption than other mitigating factors. Finally and most importantly updating an IPS, modifying a firewall or other networking device, or reconfiguring host-based preventative measures will most likely result in far less disruption while covering a greater attack surface than trying to rapidly patch an entire organizations end-point real-estate.


Note 1 (Patch Management Challenges)
– Organizational challenges faced by security and operations teams driven by different charters, operations driven by availability of services and security driven by confidentiality and integrity.
– Logistical challenges due to the inability for most organizations to distribute patches to mobile, non-managed, non-Microsoft assets. How does one patch an airport Kiosk, embedded medical device, ATM, or other type of equipment that may be running un-patched, insecure versions of Windows quickly?
– Technical challenges due to the heterogeneous computing environment most organizations currently have and the difficulty in gaining visibility into what actually requires a patch, can consume a patch, or has a supported patch management technology or process. How does one patch Cisco IOS? You can’t!
– Reconciliation challenges faced by companies that deploy a patch that adversely affects the computing environment. This happens all the time, NT SP6 became NT SP6a because SP6 negatively impacted the Lotus notes client. My last employer forced a patch to MSIM, which I didn’t even use, which broke Adobe reader – I was unable to open a PDF file until I removed MSIM all together.
– Patches are not always available, such was the case with the createtextrange, WMF, or recent DNS vulnerabilities announced by Microsoft – all of these had active exploit code and no patch, interestingly enough organizations have become so reliant on patch management technologies and processes that when confronted with conditions that do not have a corresponding patch they are often ill-equipped to implement mitigating prevention mechanisms.
– Another problem facing organizations that attempt to patch as the only response, assuming that a patch is available, is that even best of breed IT groups can fall prey to exploit during the patch process

11 thoughts on “Effective Vulnerability Management (Part 2)

  1. Pingback: www.andrewhay.ca » Suggested Blog Reading - Friday April 20th, 2007

  2. Is “scan & patch” truly ineffective? Or would it be more fair to call it “minimally effective”? Or do you consider there to be no distinction between the two?

    I definitely agree that your prescribed treatment is hugely more effective than “scan & patch”, and I know it paints a picture of the real problem of a lack of policy, but sometimes “scan & patch” is the only option.

    Maybe I’m reading too much into it. Another great article, btw. Thank you.

  3. If you look at the evolution of how most organizations adopt new processes or technologies they start with visibility of the problem. Vulnerability assessment provided a tremendous amount of visibility into the poor security state of most networks, this was followed with a movement to improve the security state, however because of the overwhelming information that VA produces and the lack of coordination between most security and operations teams they resorted to scanning the environment to identify which machines to patch and then patching – the use of the tool to truly improve the security posture of an organization became increasingly difficult.

    So scan and patch is not completely ineffective, but there are other more effective methods to improve the security posture of an organization and the foundation should not be built on simply scanning and then patching.

    I hope that answers the question 🙂

  4. It does. I come from mostly small shops where security (fwiw) has been handled by the network crew who, frankly, had more to worry about with infrastructure and availability than they could about security.

    My goal is to try to formalize some sort of legitimate security program in-house. Somewhat thankfully, our new parent co. has a security analyst, but it seems like (too) much of his time is occupied with SOX.

  5. I am legally obligated to not provide direct links to archived Gartner material, but I am the Amrit T. Williams that authored the document you are claiming was cut and pasted from. FWIW – as the original author of the VM papers what was presentd here was not cut and pasted it was a refresh of 2 very important ideas a. that scan and patch is not effective and that b. shielding before patching is an important part of the process. So before you accuse me of something perhaps you should check your facts and stop posting anonymously

  6. If that is indeed the case, then this is indeed my bad. Please accept my sincere apologies on the same.

    Speaking from the heart, I found that particular article from Gartner to be truly enlightening and thought provoking, and was enraged at the idea that someone would simply snarf such material.

  7. Pingback: Moving Security through Visibility to Implementing Operational Controls « Amrit Williams Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s