Analysts typically blame the lag on the sheer number of patches, which are issued with increasing frequency. Indeed, patching remains a dreaded chore in most IT departments, where a lack of resources means many companies have fallen behind.

"Quite simply, patching isn't all that sexy a task to do," Forrester analyst Laura Koetzle told NewsFactor. "There's no real incentive for IT folks to focus on patches. It's sort of an ad hoc effort."

Sheer Volume

Koetzle stressed that companies are too shorthanded in IT to keep up, but she also blamed software vendors for failing to flag software patches and communicate the need to install them.

"Software vendors -- and Microsoft is a big culprit here -- give you a lot of patches, and they issue them frequently," Koetzle said. "It's for you to figure out which ones you need, which ones are important. You also have to test them."

Giga Information Group research director Mike Rasmussen agreed that the sheer quantity of patches is perhaps the biggest challenge to keeping software holes closed.

"Does it behave well with my system?" Rasmussen asked. "You have to check it, then roll it out."

Compatibility Concerns

Patch compatibility with other software and systems -- which presidential cybersecurity adviser Richard Clark blamed for outbreaks like the one created by Nimda -- also presents a difficult challenge in the face of complex software configurations.

Koetzle said that when companies have many patches to deploy on many machines, they can fall behind or pass altogether on patching. "That's when things like Nimda and Code Red happen," she noted.

For the most part, analysts agree that testing patches is a basic requirement prior to installing them. However, it is often difficult to predict how complex legacy and heterogeneous systems will react to a new patch before it is actually installed.

For example, Microsoft had problems this year with updates to Windows XP. The updates misidentified and disrupted networking cards and video drivers.

Patching Business

Rasmussen suggested that companies could wade through the swamp of patches by considering the business impact of servers or systems that might be vulnerable to attack if left unpatched.

"The technical risk is different from the business risk," he said. "You've got to have some business risk involved. It's about prioritizing things based on a business impact."

Rasmussen stressed the need to implement a policy on patches and to clearly assign responsibility for fixes.

"It's just a matter of getting it to be part of [the systems administrators'] function," he said. "You should establish a policy and enforce it. This shouldn't be a guideline. This should be policy."

Plugging the Holes

Koetzle said the call for companies to release higher-quality software -- which, ideally, would not require post-release patching -- is being answered with an increase in the number of quality assurance people per software developer.

Still, she said, it is a good idea for companies to use patch management products, such as those offered by St. Bernard Software or systems management providers like IBM.

"It basically comes down to getting decent patch management software," Koetzle said. "Otherwise, companies are just going to keep having the same problem."