To ensure a predictable rollout once a patch is deployed across your network, you should test it in a non-production...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
environment. Tests are likely to detect any conflicts with existing configurations unique to the systems in which the patch will be installed.
First, identify which security issues and software updates are relevant to your environment, and determine whether the risk of not installing the patch mitigates the cost of installing it. Prioritize which patches are urgent, and schedule and deploy them before those less critical. Develop a business application profile. This helps assess system importance, allowable downtime periods and vulnerability risk levels. You should also consider vendor-reported criticality when calculating a patch's significance.
Once you have obtained a patch, verify its source and integrity. A digital signature is typically used to complete validity check. Once a patch has been validated, it is usually placed in a test environment. Ideally, you should create a test system that is identical to your production system. This allows you to verify that applying the patches will not result in unexpected or undesirable system behavior.
Virtualization can be a valuable part of your patch testing strategy because you can replicate various production environments on one computer, preferably using the same hardware. Running several operating systems "virtually" can save you time, money and space. Two leading products within the virtualization market include VMware GSX Server and Microsoft Virtual Server 2005.
It is important to expose the patch to as many scenarios of system usage as possible. Look closely for unanticipated changes within the test environment, such as:
- Program failures
- Changes in permissions
- Newly disabled services
- Newly enabled services
- Disrupted services
- Negatively affected code
- Any other application failures
If testing produces an unsatisfactory result, you must identify the root cause of the problem before going any further.
Production rollouts can be considered an additional part of the testing process if they are done in stages. The initial rollout should be to less critical systems, and if they perform as expected you can continue with the rollout until all systems are updated. The testing process can be considered finished when the full rollout is complete and there are no reported issues within a week.
Even with a thorough testing program, it is wise to have a contingency and back out plan in case something goes wrong during, or as a result of, the application of a patch or update. Change management is vital to every stage of the patch management process and updates must be performed and tracked through the change management system. Your Change Management Policy should describe the processes that will be used to identify and deploy patches, and the ownership of each step in the workflow.
Dig Deeper on Microsoft Patch Tuesday and patch management
Related Q&A from Michael Cobb
A technique known as the GhostHook attack can get around PatchGuard, but Microsoft hasn't patched the flaw. Expert Michael Cobb explains why, as well...continue reading
Software developed by the hacking group Platinum takes advantage of Intel AMT to bypass the built-in Windows firewall. Expert Michael Cobb explains ...continue reading
Tensions between the U.S. and Russia have led to source code reviews on security products, but the process isn't new. Expert Michael Cobb explains ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.