Security

Guide to Patch and Vulnerability Management

Patch and vulnerability management: how it works

by Ellen Messmer and John Fontana

Most patch and vulnerability management tools follow similar workflow patterns. 

1) The organization's security policy is the starting point for patch management procedures. The policies must define which IT assets are critical, how quickly critical patches are to be applied, how quickly other patches are to be applied and so on.

2) Based on the ability to identify network assets, the initial step involves gathering information on vulnerabilities. This will use a scanning process, whether agent-based or agentless.

3) A workflow method is necessary to prioritize and assign patch-management tasks, and to report on how and when this is carried out.

4) The remediation process of applying the software update is sometimes automated but more often it is scheduled so that it won't interfere with the production environment.

5) For scheduled remediation, a testing phase is usually completed to verify that the patch will not disrupt other applications.

6) The tool will have some method of dealing with a failed deployment. This may include suggestions on how to modify configurations to make a deployment successful.

By now the names are familiar. Nachi, Klez, Lovsan, SoBig, BugBear, Swen, Blaster and Yaha, these represent only a sample of worms and viruses that slithered into corporate networks. But they all have one thing in common: Patches were readily available before most damage had been done.

So why do these intruders continue to wreak such havoc?

Because patch management is tough.

It's tough because there are too many patches and not enough time, and because exploits to announced vulnerabilities are materializing faster. It's tough because clients are becoming the attack targets as much as servers, fueling faster propagation and the threat of re-infection from mobile workers reconnecting to the network. 

And it's not just Microsoft vulnerabilities. Although Windows seems to get the bulk of the exploits and end-user animosity, the list of targets includes routers, switches, firewalls; Unix and Linux, too.

Patching chores likely will never go away, experts say, but there are ways to address the task proactively to minimize exposure.

"Patching is the physical process," says James Williams, information delivery manager for RBC Centura Bank in Rocky Mount, N.C. "But you have to manage that process, and to do that you need some structure."

Centura has an 11-person staff as part of a computer security incident response team that maintains what Williams calls a "very systematic and very organized" patch management process. That process utilizes inventory, change-control practices and automated deployment supported by tools from Ecora, IBM/Tivoli and others.

"I might not have enough staff, but I have processes and organization that help me cover that issue," he says.

How to patch

Felicia Nicastro, senior network systems consultant for International Network Services, says the biggest mistake companies make is leaving out diligent monitoring for new patches. This should be in addition to detailed evaluation, testing, deployment and validation that a team or individual manages.

"This typically isn't a task for one person. It has to involve the security group, the operations group and the developers," she says. "So what also makes patching tough is a lack of resources." 

Nicastro says companies need to have several pieces in place before a patch-management process and its accompanying tool or tools can be installed: network inventory, change management, configuration management, asset management, formalized record keeping, an understanding of costs, prioritization guidelines, and maintenance and communications plans.

Inventory, or documenting what machines run what software, is the first step, and it might be your biggest cost because it takes time. Some patch management tools attempt to do autodiscovery, as do some configuration management tools. But human follow up is still necessary because one buggy, overlooked server is all it takes for a worm to take hold. 

Inventory ties into asset, change and configuration management. "If you track configuration then you know what's changed, and that can help with future patching," she says.

The process then naturally moves into monitoring for new vulnerabilities and available patches for everything in inventory. Once a vulnerability is identified and determined to be a threat, teams of IT, data and operations managers must work together to usher a patch through the established rollout process. A course of action and a timetable for execution, including lab testing, should be established.

"Many times companies don't have the money to support a lab or duplicate environment, but at a minimum you should try to duplicate business-critical systems, say a Web server with a database back end," Nicastro says.

After testing, distribution of the patch, implementation, exception handling, tracking and reporting need to be done.

Nicastro says in times when patching becomes a fire-fighting exercise, companies should quarantine the worm or virus on network segments and patch using their documented processes.

Subscribe to the Security Watch Newsletter

Comments