Tech Insight: Taking The Right Steps In Vulnerability Management

A Special Analysis For Dark Reading

The Black Hat and Defcon conferences have come and gone once again, leaving behind a wake of hungover security pros and scared systems administrators. With so many zero-day threats and vulnerabilities revealed in recent weeks, IT and security departments are left with the question: What do we do now?

The key to managing emerging threats is to build a vulnerability management policy that includes three central components: the ability to stay abreast of vulnerability announcements, the development of a comprehensive configuration management database (CMDB), and the implementation of an effective patch management process.

While these steps may sound simple enough, it takes serious effort to be successful in dealing with vulnerabilities as they arise. That first, seemingly simple step -- keeping track of new security advisories and vulnerability announcements -- often leads to information overload. Unfortunately, too much information is the nature of the IT security industry.

To keep up, you either need to subscribe to every vendor's update list or rely on services from third parties -- such as Secunia and iDefense -- to vet and deliver advisories that are pertinent to your environment. Free alternatives, like SANS Internet Storm Center (ISC) and Arbor Networks' Atlas Dashboard, supplement vendor update lists by providing pertinent information on current threats and attacks.

But just knowing about the latest threats and vulnerabilities is not enough. You need to have a full inventory of all of your systems and applications stored in a CMDB so you'll know where any vulnerable applications are running and can quickly create an accurate risk profile. You need to be able to swiftly answer some critical questions: How many systems are affected? Are they Internet-facing? Could mission-critical servers be impacted? Is there sensitive data stored on any of those systems?

Your answers to these questions will guide the prioritization of your threat response. They will help you determine which systems need to be protected immediately. For example, if the attack can be carried out remotely and affects Web servers, then protection of the Web servers takes priority over desktops. The reverse is also true: If the vulnerability is in Adobe Flash or Microsoft Word, then you need to develop workarounds or place content filters on the network to protect desktops; servers would need little to no attention, because they aren't running any desktop software. Further prioritization should be based on the sensitivity of the data stored or processed on the affected systems.

However, as much as we focus on what to protect, there are still two major issues to deal with. The first is that we don't necessarily know the likelihood of an attack, which means we don't always know how quickly we need to respond. Even though vendors historically have been fairly successful at working with researchers to keep quiet until a fix is in place, many proof-of-concept attacks and zero-day exploits are released every week. The potential to weaponize code varies, so keep an eye on sites like ISC and milw0rm to get an idea of what's to come.

The second problem we face with vulnerabilities such as those announced at Black Hat and Defcon is the very fact that they are zero-days threats -- vulnerabilties that haven't been seen in the wild before and do not have an associated fix. With zero-days, you need to monitoring vendor lists, blogs, and other security "news" sites even more closely. They can help you brace for impact if attacks are inevitable, as they often are.

When there are threats for which no patch is immediately available, it's important to make sure your current controls will be effective in mitigating an attack. If they aren't, then you must move quickly to implement new controls or workarounds that will prevent (or at least minimize) the damage from an attack. Controls could mean temporarily removing a vulnerable DLL from affected systems (which might hinder functionality), implementing new firewall rules to temporarily block certain types of traffic, or modifying the Windows Registry via Active Directory to turn off vulnerable ActiveX controls.

Keep in mind, however, that these workarounds are usually just temporary fixes until a real patch is produced by the vendor. At that point, the patch management process should kick in. First you must identify all of the systems that need a patch, and then you must test to ensure the patch will have no adverse effects on the affected systems. After you've done the testing, deploy the patches first to critical servers, then to other servers, and then to desktops and laptops throughout the enterprise.

Patch management is an important complement to vulnerability management because without it there is no effective or efficient way to deploy patches across the enterprise. If you don't have a well-developed patching process, Securosis has a research project, Project Quant, dedicated to the patching topic. The company already has published a report that serves as an excellent starting point. It's definitely worth a look.

Remember that failure is inevitable; you won't be able to prevent every threat or vulnerability from affecting your systems. But by streamlining your vulnerability management practices, you can ensure you've addressed all of your critical systems, implemented any workarounds available, and patched your systems as quickly as possible after a patch is made available. Until then, batten down the hatches -- and monitor your network heavily.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.