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