Patch management could be called pain management.
Securing computer networks by applying the latest software patches, especially in light of the devastation wrought by network worms such as Blaster and SQL Slammer, has become one of the more painful and tedious tasks for information technology departments. With the shortening of incubation periods -- or the time between when vulnerabilities are announced and when they are used by attackers -- enterprises are scrambling to develop cohesive strategies for deploying and managing critical patches across their networks.
Experts caution that, as good as technology is, there's no substitute for planning and analysis, especially on the server side.
"You've got to know what's on your network or, at the minimum, inventory the [critical] systems you want to include in your patch management process," says Felicia Nicastro, a New York City-based senior network systems consultant for International Network Services (INS).
Using a standard build for your desktop computers is advisable, since doing so can provide a quick glimpse into vulnerabilities that extend beyond the server level.
"That way, you can baseline what patch level your users are at today, and where they ought to be going forward," Nicastro says.
As with other facets of IT, every company needs a champion of patch management -- someone, preferably someone with networking or security competence, who will monitor newly discovered vulnerabilities and
"Let's say there is a critical update against Internet Explorer, SQL Server, the operating system -- whatever the technical silo happens to be," says Mark Nicolette, an analyst with Stamford, Conn.-based Gartner Inc. "Get those people involved right away, since it's an update to their area of responsibility. They're the ones to second the evaluation and add more value about the general scope of vulnerabilities."
Not every update should be treated the same way, though. When new code is unleashed into your network, unintended consequences often follow. Changes made to one piece of code may cause other brittle code to break, creating new problems. Ideally, you'd want to perform quality assurance (QA) tests before installing new patches, but that's not always possible.
If that's not possible, Nicolette suggests phasing in patch updates to selected systems at scheduled intervals. That gives you time to see how the new code behaves and what conflicts arise with applications and hardware. Some patches require you to reboot systems for the patch to take effect; others are packaged to avoid reboots.
Experts say you should focus on the most critical updates first. "You'll need to know what assets are used, in the context of criticality," says Eric Hemmendinger, an analyst with Boston-based Aberdeen Group. "If you have a system that needs to be up and running 24/7 for revenue purposes the last three weeks of a quarter, I don't know if you [want to] risk bringing it down, no matter what the security issue is."
QA testing and scheduling are manual tasks, but other aspects of the process can be run by special software. Automated patch analysis often is tightly coupled with the process that creates service packs for distribution across the enterprise. Once a service pack is distributed to all users, IT departments need to make sure the patches have been installed, Nicastro says.
Doug Howard, vice president of strategy and product development with Counterpane Internet Security Inc., in Mountain View, Calif., urges IT directors not to forget human intelligence.
"You want users to be part of the feedback mechanism of your QA testing, telling you if a patch works or not," he says. "That's the part that typically breaks down."
Patch management is not a panacea, Nicastro says. Rather, she says, patch management needs to be considered in the context of an overall enterprise security approach, one that includes vulnerability assessments, configuration management, release management and network management.