A SearchMidmarketSecurity.com reader asks our resident security expert Tom Chmielarski, "Should you test all Microsoft patches? Under what circumstances should a patch be deployed immediately?"
Deciding what patches should be tested before deployment and how thorough any such testing should be is tricky; there isn't a one-size-fits-all answer.
Requires Free Membership to View
SearchMidmarketSecurity.com members gain immediate and unlimited access to breaking SMB industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchMidmarketSecurity.com today!
Michael S. Mimoso, Editorial Director
The safe answer is, of course, that every patch should be thoroughly tested against systems identical to those in production, and a back-out plan should be ready to undo any damage that the production rollout may cause. That's not the most economical approach, however, and is often impractical. So how do you know what to do? When it comes to testing, what is the best Windows patch management procedure?
Before discussing what level of effort, if any, should be expended to test a given patch, I'd like to address the patches themselves. Patches can add functionality, correct defective functionality, or address security vulnerabilities that range from low severity to critical. The effective risk is a combination of the likelihood of the vulnerability being exploited, the ease of exploitation, the result of exploitation, and if an exploit is known to exist. A system with no network connection might be highly vulnerable, but is unlikely to be compromised due to its limited exposure. Some vulnerabilities are very difficult to exploit, while others are trivial to take advantage of. The exploitation of a vulnerability can have varied results; some vulnerabilities allow remote access, some give an attacker information, and some may crash a system component or the system itself. Lastly, sometimes attackers use a vulnerability to compromise a system before the patch is available -- that makes the risk higher since it has already been "weaponized."
These Windows patch management procedure considerations are important because the risk posed by a low-severity vulnerability is much less than the risk from a critical-rated vulnerability that has a known exploit (which provides remote access) in the wild. Your patch process should include evaluating the relevance and criticality of each patch to your environment. Since Microsoft patches are released the second Tuesday of every month, it is easy to plan this review into your normal operations schedule.
Your patch-testing plan comes down to evaluating risks and costs: How critical are the systems and how much effort can you allocate to ensuring a patch will not cause functional problems? Is it cheaper to respond to an emergency outage caused by a conflicting patch or to fully test those patches before deployment?
The effort of creating and maintaining a patch testing program is not the only consideration here either; unpatched systems represent a risk to your network, particularly if there is a known or feasible exploit for it. To lessen the risk that a given vulnerability will be exploited, you need to speed up the patch process. The patch process does not need to be the same for all of your systems; you can increase the testing effort for critical systems and skip testing for low-value systems. Adjusting the patch process in accordance with the system value allows you to spend your time where it matters most.
Another Windows patch management approach, either in addition to or in lieu of formal testing, is the use of an early adopter population. By allowing a segment of your population to update before the majority of your systems, you can often reduce the risk that a patch will cause a large disruption. You might have that early adopter population update right away and then update the larger population a week later if the early adopters don't complain.
Patching that super-critical finance/billing/factory/medical server might be deemed risky and undesired, but leaving it unpatched might allow an attacker or worm to compromise the system or crash it. Even worse, someone may be able to break into that system and steal confidential information or tamper with it. I wish I had a dollar for every time I heard "that system is too important to patch!" That thinking is fundamentally flawed; if the system is critical, then it is too important not to patch.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
Send Tom your security questions.
Join us on LinkedIn. This was first published in May 2010