There is a copious amount of information available today from various sources on how to do patching right, which patch management systems to use, best practices for issuing patches to your network, and so on. But for some reverse psychology works best. This month I'll point out three things not to do when patching your systems.
Don't be too loose
The last thing you want to do is unleash patches onto your network without at least some time spent vetting the quality of the patch. You need to be sure the cure isn't worse than the sickness. Spend some time checking that patches to Windows operating systems won't break legacy applications that use older communications methods (like Remote Procedure Call (RPC) or NetBIOS), and make sure hotfixes to Microsoft Office and other applications don't interfere with functionality that your users need.
Don't be too rigid
On the flip side there's such a thing as excessive caution. One example of this happened during the days of the Blaster worm, which exploited a security vulnerability related to RPC in Windows 2000 and XP. So many administrators were wary about issuing the Blaster patch to their machines (and so many others lacked good patch management tools) that the worm was able to spread to unpatched machines at an alarmingly fast rate. Another worm, considered a "white-hat" worm, was released to prevent further Blaster damage: It spread itself and patched Windows machines, protecting them from the DCOM vulnerability; it ended up being the saving grace for many businesses.
The moral of this story? Weigh the risks of the vulnerability and the urgency of getting a patch installed on your network against the administrative cost of troubleshooting whatever breaks as a result of that emergency patch. Find that elusive happy medium.
Don't have multiple patching sources
Recall the old adage, "Too many cooks trying to make the soup." You don't want some workstations getting fixes from Windows Update while others ping your Software Update Services (SUS) server while still others fail to receive any automatic updates at all and need manual attention. Get together with management and your fellow administrators and decide on a single, unified patch management strategy. Then follow through with it and be consistent. Otherwise you might as well have no system at all.
Looking for more prescriptive guidance? Check out my newly released book, Learning Windows Server 2003, which is full of good advice about patch management, Windows security and remote-access hardening.
Do you have war stories? Let's hear what you've learned not to do when patching systems. E-mail us today.
About the author
Jonathan Hassell is author of Hardening Windows, published by Apress. He is a systems administrator and IT consultant residing in Raleigh, NC, with extensive experience in networking technologies and Internet connectivity. He currently runs his own Web-hosting business, Enable Hosting, based out of both Raleigh and Charlotte, NC. Jonathan's previous published work includes RADIUS, published by O'Reilly and Associates, which serves as a detailed guide to the RADIUS authentication protocol and offers suggestions for implementing RADIUS and overall network security. You can e-mail Jonathan at jhassell@gmail.com.
More from Jonathan Hassell on SearchWindowsSecurity.com
