Develop a Patch Management Strategy

It's more critical than ever to test patches. Unfortunately, most IT organizations are forced to simply slap on fixes.

September 9, 2005

2 Min Read
NetworkComputing logo in a gray background | NetworkComputing

A week or so earlier, after issuing patches for three critical Internet Explorer vulnerabilities, Microsoft scrambled to correct a glitch that blocked customers from pulling the patches from its Download Center--effectively patching the system that distributes its patches. One can only assume that Microsoft tested the patch-distribution system patch before patching the system.

An Epidemic

Windows, of course, isn't the only software with more patches than a 14-year-old soccer player. Among operating systems, everything from Sun's Solaris to Cisco's IOS to open-source Linux is subject to regular fixes. Then there are the myriad office suites, messaging platforms, enterprise apps, Web browsers, network- and content-management systems, databases, and graphics tools that run the patch gauntlet.

Adding to the complexity is the fact that most IT infrastructures are networks of interdependencies: You're not just patching one system; you're tampering with a fragile ecosystem. Will the patches screw up custom apps and cobbled-together systems? Will they degrade performance? No doubt it's more critical than ever to test patches, but with the narrowing time frame between exposed vulnerability and exploit, IT organizations are pressured to just slap on the fixes.

There are no comprehensive solutions. Microsoft lets U.S. government agencies and other select customers test its patches before they're generally available, but you get no head start if you're smaller fry. And though patch automation may appeal to staff-strapped IT shops, it's not the silver bullet vendors are making it out to be, because of the need for manual testing. Automated patch deployment should be considered only for systems where information confidentiality is more important than availability (as with stored customer data that doesn't need to be accessed regularly), or where the risk of an attack is deemed to outweigh the risk of downtime, according to a recent Gartner report.So it's incumbent on IT organizations not only to prioritize the software that must be patched, but also to identify the systems whose patches must be tested. Meantime, they can reduce the exposure of their unpatched systems by implementing tiered security: firewalls, intrusion-prevention systems, updated antivirus software and the like. Even the most basic desktop defenses should have been enough to stop Zotob and its ilk.

For the more insidious threats, however, none of this "defense in depth" will get much easier. Gartner predicts that system prioritization and patch testing/deployment will remain largely manual tasks "well beyond 2007." And while security is being integrated into network infrastructure and packaged into all-in-one desktop suites, the attackers are getting more sophisticated as well.

Perhaps no other profession spends so much time fixing and defending flawed products purchased at considerable expense from reputable vendors. Regardless, if you don't have a patching strategy, develop one as part of a more comprehensive effort to understand your remaining security risks.

Rob Preston is editor in chief of Network Computing. Write to him at [email protected].

Read more about:

2005
SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights