To ensure a predictable rollout once a patch is deployed across your network, you should test it in a non-production...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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 Security patch management and Windows Patch Tuesday news
Related Q&A from Michael Cobb
Many large enterprises have their own internal public key infrastructure. Expert Michael Cobb explains the considerations organizations should make ...continue reading
Network administrators typically resist policies for separate accounts when performing different tasks. Expert Michael Cobb explains the risk of ...continue reading
Microsoft is banning weak passwords on many of its services with the Smart Password Lockout feature. Expert Michael Cobb explains how it works, and ...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.