|
To ensure a predictable rollout once a patch is deployed across your network, you should test it in a non-production 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.
|
