The Patch Management Race Is On

It’s hell week for many IT security professionals: Not only did Microsoft issue its usual raft of “Patch Tuesday” security updates, one of which involved a critical flaw to the Windows Media player, but Adobe Software also issued several updates as part of an ongoing process to address fundamental security issues.

While it’s commendable that both Microsoft and Adobe take security seriously, usually there's a gap in time when these security updates are provided and when IT organizations deploy them. That means, of course, Microsoft and Adobe have disclosed flaws in their software that hackers can exploit until IT gets around to deploying the patches.

What a lot of IT organizations need to limit this security exposure is a more structured approach to patch management. In an ideal world there would be not only a centralized tool for managing all software patches, but also an automated set of tools that would deploy those patches. That, of course, is the rub inside many organizations -- before a patch is deployed, most IT organizations want to make sure the cure isn’t worse than the disease, which is to say that the patch doesn’t wind up breaking some application that is dependent on the software being fixed. That requires time to test the patch -- a commodity generally in short supply within most IT organizations.

There’s no substitute for testing. But the other option is to automatically deploy at least critical patches on the assumption that there is a patch management system in place that could roll back the patch in the event of a problem. That approach would narrow the window of exposure considerably, while giving the IT organization the ability to remediate any problem quickly.

When it comes to security just about every IT organization is in a race against time to minimize risks, which makes having an effective patch management strategy in place one of the more critical processes every IT organization needs to have in place.