Patch management techniques
Do you recommend testing and installing all patches as they are released, or prioritizing them and saving functional patches for a later batch or process?

    Requires Free Membership to View

    Login

    SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!

    Michael S. Mimoso, Editorial Director

    By submitting your registration information to SearchSecurity.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSecurity.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The goal of patch testing is to ensure a predictable rollout when a patch (or patches) is deployed across your 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.

More information

  • Use this guide to learn how to deploy a successful patch.
  • Visit our patch management resource center for news, tips and expert advice.

    • This was first published in February 2006