Bridging the Patch Gap

It takes about two days, sometimes less, for attackers to develop exploits that take advantage of a newly-announced vulnerability.

On average, it takes an IT department about a week, sometimes more, to deploy the software patches required to eradicate that new vulnerability.

Is your enterprise at risk? You do the math.

The situation is simple, experts say: Black hats are getting better -- and faster -- at writing viable exploits. IT security people, on the other hand, are faced with an increasing number of patches to deploy, yet they are hamstrung by a shortage of skills, people, and financial resources. And the time gap between the introduction of an exploit and the deployment of the "cure" is, in at least some cases, getting wider.

"Even with automated patch management tools such as ours in place, we find that it takes users about a week to roll out a new patch," says Don Leatham, director of solutions and strategy at Patchlink. Across the industry, the average time to patch is still around 30 days, he says.

Contrast those estimates with the speed of security researcher HD Moore, who last week saw Microsoft's critical MS06-040 vulnerability on Tuesday afternoon and published a verified denial of service exploit by Thursday. (See Exploits Emerge for Microsoft Vulnerability.)

"The interval between patch release and patch deployment is the attacker's best window of opportunity, and even though there are some pretty good tools out there, it's not closing," says Scott Crawford, senior analyst at Enterprise Management Associates, a management and security consulting firm.

For years, vendors and analysts have told enterprises that the best way to handle a new vulnerability was to deploy the patch as swiftly and efficiently as possible. That's still the goal, but it's time for IT and corporate management to concede that there will frequently be a time lag between the emergence of an exploit and the deployment of a patch, and enterprises need to have a strategy for managing security during this interim period, observers say.

"There are a lot of enterprises out there that have strict policies that say all critical patches have to be deployed within 24 to 48 hours," notes Leatham. "But particularly in distributed organizations, that's just not realistic, and security people are forced to come up with their own policies because the corporate policy doesn't work."

While there are some highly centralized, well-connected organizations that can deploy an emergency security patch in a matter of hours, most enterprises take longer, experts agree.

"Each patch must be tested to make sure that it is working properly and does not conflict with other existing applications in the system," says Hasan Cavusoglu, assistant professor at the Sauder School of Business at the University of British Columbia. Along with two other professors at another university, Cavusoglu authored a paper called "The Economics of Security Patch Management" last year.

This testing process, along with the time required to analyze the threat and physically install and validate the patch software, virtually guarantees that the patching process will take at least a few days, if not longer, experts say. In the case of non-critical patches, many organizations put together a bundle of patches and do the testing all at once, often on a monthly basis, Cavusoglu notes.

The takeaway: While patch deployment and management technology continues to improve, there will always be a time gap between the exposure of a vulnerability, the development of a patch, and the deployment of the software update. While vendors frequently say the "solution" to a vulnerability is to deploy a patch as quickly as possible, they generally offer no help in protecting the network during the patch testing/deployment process.

So what can enterprises do while they lay exposed, waiting for the patches to be deployed? An intrusion detection or prevention system can help, Leatham says. An IDS can sometimes protect the network against a known exploit, even if it hasn't been patched, he observes.

In extreme cases, an enterprise may choose to simply shut down the vulnerable services, experts say. "The MS06-040 vulnerability, for example, affects ports 139 and 445, so you may choose to shut off those ports or restrict them until the patches are in place. But that's going to affect your business, so it's a radical step," Leatham concedes.

Down the road, enterprises may be able to integrate security systems and configuration management systems, so if a vulnerability remains unpatched, the IT department can change the network's configuration to reduce the exposure, Crawford says. A few companies, such as Blue Lane, are already experimenting with this concept of "security virtualization," he notes.

— Tim Wilson, Site Editor, Dark Reading