Microsoft patch management policy

The Windows Patch Management Tutorial is designed to give you a one-stop comprehensive resource for all of your Microsoft patching needs. In the first section of our tutorial, learn about setting patch management policy, prioritizing your patching process, managing a testing budget and the pros and cons of using third-party patch management tools.

Windows patch management policy
Windows patch maintenance and post-patch security
Windows patch management tools

Windows patch management policy

Prioritizing Windows desktop patches

This list covers the major categories of things that can be patched or updated in a typical desktop configuration and the order in which you should apply them whenever possible. Patch your systems in this order and your patch management policy will be stronger than ever.

1. Bios: As with servers, start here. Managing BIOS updates across multiple systems is all the easier when they're of the same make and manufacturer, but it requires "hard" downtime: The computer has to be powered down and rebooted to apply the new BIOS, and the administrator usually has to baby-sit each system individually that will be upgraded. Fortunately, many PC manufacturers now allow centralized updates to BIOSes through a management application -- Altiris, for instance, has a management solution for Dell desktops and notebooks that allows remote BIOS updates.
2. Device BIOSes: These include things like BIOS updates for disk controllers, video cards or other devices. Device BIOS updates go into a separate category from regular BIOS updates for two reasons: One, they are easy to overlook and not often considered for desktops; two, you usually cannot update them en masse. For example: If you're administering a group of graphical workstations that need updates to their video card's BIOSes -- and the only way to do that is via a 16-bit DOS-based updater -- you'll probably have to do that by hand for each computer. However, if you could perform the update through a 32-bit Windows application, you could probably push out your Windows patches as you would any other update.
   
   
3. Device drivers: As with servers, one of the more common hardware device-driver updates published for a desktop computer is for the network controller. Make sure you test the update ahead of time. If you automate patching on a whole slew of machines with such a driver and the end result is that they're all knocked off the network, your only choice might be to either re-image them from scratch or fix each one manually.
4. The OS:
5. Patching Windows OSes is the part almost everyone is directly familiar with and it needs relatively little elaboration here. One thing I'll add is something I also wrote about in the server version of this article: If there are device driver updates, they should be examined separately from other updates in case an OEM-provided version of the driver is more urgently needed.
6. Middleware: This normally includes elements such as ODBC drivers but should also include things like the Microsoft .NET Framework. Note that with the .NET Framework, the 1.1 and 2.0 iterations (and the upcoming 3.0 edition as well) exist side-by-side and don't eclipse each other.
7. Application patches: As with the OS and its attendant patches, you can roll out application patches through the usual automated mechanisms, and it should be done only after everything else has already been applied.

Managing your patch testing budget

The biggest Windows patch management costs related to creating a test lab are hardware and software. Although both are necessities, there are some ways that you can really hold down the costs. Let's talk about the hardware first.

One way you can economize on hardware is to purchase PCs instead of servers. If all you do is test the impact of occasional patches, then you don't need things like multiple processors and RAID arrays. You can save an absolute fortune just by using a basic PC with plenty of disk space and memory for testing purposes.

Another cost-saving technique is to use virtual machines. Products such as Microsoft's Virtual Server 2005 and VMware from VMware Inc. allow you to simultaneously run multiple virtual computers on a single physical computer.

Reduce cost of Microsoft patch management software

Try using Windows patch evaluation software in your lab. Microsoft offers 120-day evaluation copies of most of their products for free. Therefore, if you are testing an entire patch management configuration, a single patch, an upgrade or whatever for less than 120 days, you could just download some evaluation software and not have to worry about the cost.

If you are going to be testing for an extended amount of time, one option is to get an MSDN subscription. A subscription to MSDN Universal costs about $2,000. That sounds like a lot of money but, along with the subscription, you receive multiple licenses for almost all of Microsoft's products. I don't know what Microsoft's official policy is regarding using MSDN software in testing labs, but because MSDN is intended for developers, I'm pretty sure that using MSDN software in a test lab would be allowed by the license agreement.

Using third-party patches

Most of us have been there before. It's the beginning of the month, Patch Tuesday is about ten days away and we hear about a new exploit that we know we are susceptible to. At such a time, it's frustrating to know we have to wait for the second Tuesday of the month before a software fix arrives. You might think that deploying a third party patch is a good idea. Well, sometimes it is. And sometimes it isn't.

The cons of third-party patches

IT administrators deploying off-cycle patches from third parties, in many instances, will have no idea what the patch contains. So before you consider deploying an off-cycle patch, you should ask yourself how much you trust the company that produced it. Even patches from a company without any malicious intent can inadvertently be infected by malicious code.

In the worst case, if a company producing third-party patches has less than honorable intentions, it potentially could distribute a patch containing spyware or code that makes it easier to exploit the vulnerability that the patch supposedly addresses.

Another potential problem with deploying third-party patches is that these patches might break parts of your system that are currently running just fine. After all, in the case of a Windows patch at least, many of these fixes are actually replacing operating system code. Even the slightest change to code could have catastrophic effects.

The pros of third-party patches

In the opinion of some Windows security experts, the risk of accidentally introducing bugs or malicious code into a system, along with the risk of Microsoft not supporting the system, far outweighs the risk of having to wait for a legitimate Microsoft patch. After all, Microsoft does have a history of expediting patches for more serious security issues. At times, Microsoft even provides detailed instructions on how to protect a system against a newly discovered vulnerability until a patch can be produced.

Essentially then, the debate between using third-party patches and waiting for Microsoft patches comes down to an issue of timing. If you feel you are facing a serious Windows security vulnerability and Patch Tuesday is weeks away, you might want to run the risk that the third-party patch could produce bugs just to protect yourself from greater danger. If the risk is not so great, you might want to just wait for Microsoft to release their own patches.

The four myths of Windows patch management

Myth #1: You should always wait a month before applying a new patch.

Perhaps the most common myth of patch management policy 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?

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.

Myth #3: You only have to deploy a patch once.

You automatically deploy patches 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 policy 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. 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.