As with any complex process, myths about the best way to perform patch management have become prevalent within the systems administration community. Most administrators tasked with patch management have not come to administration via any formal process, picking up advice from many and varied sources as they go about their job. Unfortunately, that means that an administrator might be exposed to a bit of advice that seems logical, but turns out to do more harm than good. This article examines some of the myths you might have heard and the arguments against them.
Myth #1: You should always wait a month before applying a new patch.
Perhaps the most common patch management myth is that an organization is better off waiting for a few weeks after vendors release a patch before deploying it internally. The idea is that if you wait a month and don't hear any screaming on security mailing lists, it will be safe to apply the patch.
The problem with this thinking is that you should be using the results of your own testing to decide whether or not a patch is safe. You shouldn't be using anecdotal evidence off the Internet. Sure, the anecdotal evidence might point to some problems, but these are problems that your own testing regimen would have found anyway. So why wait a month to hear what other people say when your own tests, which you should be running regardless of what you hear, would find any faults earlier?
Another thing to consider is that the amount of time between the release of a patch and an exploit appearing is shortening. This doesn't mean that you should rush your testing, but it does mean that you shouldn't be procrastinating when you learn of an update's release.
Myth #2: If a patch doesn't break most of your configurations, it will not break all of your configurations.
You need to apply a newly released patch to all of the desktop computers in your organization. You test the patch on the Windows XP boxes in the IT department without encountering any problems. You test it on the workstation used by the CEO's administrative assistant without encountering any problems. You test it on five computers used by people in the HR department and everything works perfectly. You use your patch management software to deploy the new patch to all of the computers in your company. That's when you find out that the patch causes a problem with an application that is only installed on the accounting department computers.
It may be laborious, but you should test your patches on all of the configurations within your organization before rollout. If you don't, you'll almost always find that a small group of users who have a unique but mission-critical application installed will start having problems. One way of making this a little easier is to lay aside for yourself virtual machines of each unique configuration in the organization. This allows you to quickly test in the lab rather than having to select a guinea pig from each department.
Myth #3: You only have to deploy a patch once.
You deploy a patch to all the computers on your network. A week later, you do a scan to check that all computers have had the update applied. Unfortunately, you still can't assume that every computer in the organization has been patched. In my experience, there is always some computer in some remote branch office that has been switched off for a couple of weeks because it is broken or the person that regularly uses it has gone on leave. Eventually the computer is switched on, but remains unpatched because you've moved on to patching newer vulnerabilities. When checking that the current patch has been successfully applied, spend a little extra time verifying that other patches are also present.
Myth #4: There is a one true method for patch management.
Although there are some basic principles that should be kept in mind when developing a patch management plan, there is no one true method. Each organization is unique. A technique that works for one place (such as rolling out patches each Friday at 5 p.m.) might not work for another. Administrators should tailor their patch management plans to the needs of their unique organizations.
A patch management plan should not be static. You should review it on a regular basis with the goal of ensuring that it continues to meet your organization's needs. Anyone who has worked for a while knows that the structure of very few organizations remains static. And structural changes will influence your existing patch management plan -- WAN links might be up or downgraded or budgets might have changed allowing you to do more (or, more likely, less) with available resources.
If you inherit a patch management plan developed by another person, make sure you analyze it, too, to see if it still meets your organization's needs. Don't blindly follow a protocol that may be flawed. If the protocol fails, it is likely to be your head. Finally, when you are about to move on to greener pastures, ensure that the patch management plan that you've developed is well documented so that the next person can easily pick up from where you left off.
About the author: Orin Thomas works for Windows IT Pro's CertTutor.net training and certification Web site. He holds Microsoft, Cisco and Linux certifications, and the co-author of various Microsoft Press MCSA/MCSE Self-Paced Training Kit books, including: Managing and Maintaining a Microsoft Windows Server 2003 Environment (Exam 70-290) and Implementing and Administering Security in a Microsoft Windows Server 2003 Network (Exam 70-299). He's also co-author of MCSA/MCSE Implementing and Managing Exchange Server 2003 Exam Cram 2 (Exam 70-284).
