SearchMidmarketSecurity.com reader: I read your article: "What is the best Windows patch management procedure?" I just recently completed a patch management review. One of the issues is understanding the testing on the patches related to the Windows operating system. If I am testing a Windows application like Outlook, I can easily apply the testing factors as you have discussed in your previous article. However, I am not clear on how I am going to apply it to the operating system patches. For example, a patch that applies to the "kernel" of the operating system. How do you test it?
Contributor Tom Chmielarski: Operating system patches are, obviously, much more difficult to test. Changes to the core OS and libraries can result in subtle conflicts that are not easily detected. The most common approach to this that I've seen is the use of an early adopter population to "live-test" the update on a subset of the population.
A reasonable sample population receives the update, possibly without notification to the end users, and is allowed to operate normally. If no complaints are reported within a reasonable amount of time, then the updates are applied to the remaining systems. This allows the administrator to spend
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
a minimal amount of time doing actual testing and yet limit the risk of deploying a
troublesome update to a large number of systems. Although quite common, this approach is also
rather sloppy, usually used simply because many administrators do not have adequate time for system
update testing.
Another common approach is to have a set of test systems that recreate a portion of your production environment. The patches are applied and then a list of critical or common tasks is performed to verify basic functionality remains. An example set of these tasks could be:
- Reboot
- Log on with a local account
- Reboot
- Log on with a domain account
- Start application 1
- Exit application 1
- Start application 2
- Perform application 2 action 1
- Perform application 2 action 2
- Exit application 2
- Repeat list twice
This testing process does not guarantee the operating system patches did not cause a conflict, but it at least establishes that your core functions are still functional. This type of testing is only as good as your thoroughness (and time spent) and the similarity of the test environment to your production environment. It works well for controlled environments, but is less compatible for the random hardware and application platforms that are frequently spread across the enterprise.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
Send Tom your security questions.
Join us on LinkedIn.
This was first published in June 2010