Developing a Windows patch methodology

Patch Tuesday doesn't always make the patch process carefree. Jonathan Hassell recommends developing a good patch policy to ease the pain of frequent patching. Read his list of the essential components of a good policy.

Supposedly, Microsoft's Patch Tuesday schedule should lessen the complexity of patch rollouts. But with the looming possibility that Microsoft will release patches out of cycle, it's important to develop a strict policy for how software updates will be handled. Get smart and develop a plan today.

But how? What elements make up a good policy?

Here are some questions to consider when developing the policy:

 Checklist: Developing a Windows patch methodology
What applications are running on your network?
Patching is a comprehensive subject, and it requires you to have an extensive inventory of what software is running anywhere on your network, including operating systems, off-the-shelf third-party applications, software developed in-house, applications running over the Web or on an intranet. Each piece requires consideration.
Do different departments have different security or hardening requirements?
Patching is a comprehensive subject, and it requires you to have an extensive inventory of what software is running anywhere on your network, including operating systems, off-the-shelf third-party applications, software developed in-house, applications running over the Web or on an intranet. Each piece requires consideration.
Do different departments have different security or hardening requirements?
You may have a cluster of client computers in an area handling sensitive information or a group of computers exposed to an environment with a completely different threat model and vulnerability risk. Larger organizations are more likely to need a compartmentalized approach to patching. How can you address increased security needs in one area while balancing time and resources in other areas? These are questions that require answers in a complete updating policy.
Do you have equipment, time and expertise to test patches?
If you are a one-person IT department in a small business with 75 to 100 computers, then you probably don't have a lot of available hours to fully test patches. In that case, you probably need to simply bite the bullet and install patches as they come along -- the risk of killing your applications doesn't outweigh problems a virus or worm outbreak will cause. It's easy enough, in a smaller environment, to roll back patches that begin to cause difficulties.
Have you developed a system for evaluating the severity of patches?
Will you take Microsoft's word for it? Do you have an environment that differs significantly from a normal environment, such that risks are magnified or reduced?
Do you have third-party software protection against certain threats already?
If you have a desktop firewall in place and fully updated AV, perhaps you don't need to deploy every patch immediately as they come out. Perhaps there is already sufficient protection in place that will buy you some time to evaluate the importance of applying an update.
Once you've determined the scope of your policy, think more specifically. Here are some questions to consider that will help you identify which elements to include in your patch policy:
How patches will be approved or declined, or if they will go through such a process.
Who is responsible for the final say on a patch's distribution? What sort of timeframe will you allow for a patch to be considered? Is there a default decision if no one has any comments on the matter? What group is ultimately responsible for obtaining a patch in a form appropriate for distribution? Or do you simply want to bypass the approval process and allow all patches to come down from the respective manufacturers?
The method for patch distribution.
Will you use a Microsoft-provided solution like Windows Server Update Services, or do you already have an investment in management software, like SMS or Altiris products? Are these methods sufficient to comply with your eventual final patch policy, or do you need to adjust your budget to obtain and deploy an additional solution? What sort of client software, if any, is required, and what is the method for deploying that end of the solution?
The frequency and window in which patches will be applied.
What sort of "grace period" does the group with approval responsibility have to act on the patch? What is the ultimate bandwidth and processing requirements for patches, both on the client and server end? Are there scheduled processes that could affect update distribution and possible reboots to finalize the update? Is this a once-a-month ordeal, once weekly, or some other interval?
How you will handle a patch rollback.
If you encounter a problematic patch, how will you address those ramifications? Do you schedule backups for target computers just before patches are applied? What sort of service timeframe will you promise your end users in case their systems are affected by a misapplied patch? Who is responsible for doing a post-mortem on the patch to make sure such an instance can be avoided in the future?
The procedure for patching a problem of unusual severity.
If you have a zero-day exploit that has massive ramifications for your computers, how will you handle its application? Do you bypass the normal procedures? Who pitches in to help? How do you handle service issues regarding this? Who needs to be informed, and how and what kind of notice do those stakeholders need?
When the patch policy itself will be reevaluated.
It's smart to allow for reconsideration of these policies on a regular basis -- perhaps every six months for the initial period the policy is in effect and then less often after you have successfully implemented it.

About the author: Jonathan Hassell is author of Hardening Windows (Apress LP) and is a SearchWindowsSecurity.com site expert. Hassell is a systems administrator and IT consultant residing in Raleigh, N.C., who has extensive experience in networking technologies and Internet connectivity. He runs his own Web-hosting business, Enable Hosting. His previous book, RADIUS (O'Reilly & Associates), is a guide to implementing the RADIUS authentication protocol and overall network security. Ask Hassell a hardening Windows question today.

This was first published in September 2006

Dig deeper on Patches, alerts and critical updates

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchVirtualDesktop

SearchWindowsServer

SearchExchange

Close