The goal of patch testing is to ensure a predictable rollout when a patch (or patches) is deployed across your...
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.
organization. However, this can be a time-consuming process and the sheer number of Microsoft patches, for example, makes it cost-prohibitive to test all of them. Because some patches are not as critical as others, you need to prioritize and schedule updates that must be deployed more urgently than others. I suggest prioritizing patches by putting them into one of two categories: security-related, and everything else. For example, defending against an Internet worm is far more important than a functional issue in Microsoft Outlook. You may only have a few days to test and decide whether to deploy a security-related patch before an exploit is released, so wait to test and deploy other patches until time is available.
Prior to installing any patch, it's important to identify the security issues and software updates that are relevant to your environment, and determine whether the risk of not installing the patch mitigates the cost of installing it. Ideally, you have a complete system inventory that prioritizes all your machines, so you can plan your patch strategy around your critical systems. Developing a business application profile for each application will help to assess system importance, allowable downtime periods and vulnerability risk levels. For example, because an organization can survive if a few PCs go down, but not if the main server does, server updates are more critical than desktop patches. Vendor-reported criticality is another key input for calculating a patch's significance, as is the existence of a known exploit that uses the vulnerability being patched as an attack vector.
Prior to deploying any patch, test them in a non-production environment. Deploying patches to a non-production environment will uncover any potential problems or conflicts with existing configurations unique to the systems in which the patches will be installed. The scope of your testing will directly relate to the criticality of your systems and data. However, it is important to expose the patch to as many system usage scenarios as possible. I would advise against batch testing because if testing produces an unsatisfactory result, you must identify the root cause of the problem before proceeding, which is difficult if you have installed several patches at once. Production rollouts can be considered an additional part of the testing process if done in stages. The initial rollout should be to less critical systems, that way if they perform as expected, you can continue with the rollout until all systems are updated. However, you may have to compromise this practice when the risk of an attack is deemed to outweigh the risk of system downtime.
On a final note, your security policy should define your organization's stance on patch prioritization, testing and deployment in such circumstances.
Dig Deeper on Security patch management and Windows Patch Tuesday news
Related Q&A from Michael Cobb
An old Java vulnerability was discovered to have been ineffectually patched. Expert Michael Cobb explains how this happened and what can be done to ...continue reading
Google's Certificate Transparency tool publicly logs certificates issued by CAs. Expert Michael Cobb explains how the log viewer works to improve ...continue reading
Crowning the most secure web browser is difficult, with research often turning up biased results. Expert Michael Cobb explains how to make a choice ...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.