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
Geofencing technology is increasingly being used as a security tactic, such as to control access to servers with DNS settings. Expert Michael Cobb ...continue reading
After a remote code execution flaw in PHPMailer was patched, the problem persisted, and had to be repatched. Expert Michael Cobb explains how the ...continue reading
The same-origin security feature in Adobe Flash Player was implemented incorrectly, allowing local attackers to spy on users. Expert Michael Cobb ...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.