Q

Patch management techniques

In this Ask the Expert Q&A, our platform security expert provides techniques to use when testing, installing and deploying a patch to your network.

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?

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
 

This was first published in February 2006

Dig deeper on Security patch management and Windows Patch Tuesday news

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close