Security

Back to basics: A four phase approach to patch management

Alfonso Barreiro addresses one of the most common risk mitigation tools in every organization -- patch management. He presents a four-phase approach that will help you create your own patch management best practices.

Given the growing amount of new and complex information security threats that organizations face every day, it's easy to overlook some of the most basic and useful defenses in the IT security arsenal, such as security patch management.

Patch management is a tool that can help protect your organization, but at the same time presents great challenges. Since patch management is at heart a risk mitigation tool and every organization manages risk differently, there is an absence of industry best practices that has many IT organizations struggling with the decisions of what to patch and when. Here we will examine a basic 4-phase patch management process that can help you get started in creating the best practices that fit your organization.

Before you can use patch management successfully however, you must have the support of senior management. Raising awareness in the upper levels of your organization of the security risks and the need for patches is important to ensure that the appropriate resources will be available and reduce resistance from business units that do not want interruptions in their operations.

Phase 1 - Assessment

An effective patch management process requires knowledge of the hardware and software assets in use in the organization and their respective roles. Ideally you should be able to identify critical assets and roles with the help of business stakeholders, as different roles may present different availability requirements. Organizations with established standard system configurations and end-point lockdown policies reduce the complexity of the patch management process, decreasing the number of patches you have to deploy and keep track of.

In this phase you should also determine what your current patching level is, identifying which patches are installed and which are missing. Systems that cannot be patched or raised to the same level as the rest of the organization (such as those supporting legacy applications) need to be identified as well and be brought to the attention of senior management for evaluation.

Phase 2 - Identification and evaluation

Once you have a handle on what is running in your environment, you can use that information to determine whether or not a particular patch applies to your systems. Most vendors provide alerts when new patches are available, but you can also use information from trusted third-parties (such as the SANS @Risk Newsletter) to identify new vulnerabilities and patches.

When you have identified a patch that may be applicable, you must review all of its associated documentation, including information such as prerequisites, known issues, functionality changes, alternative workarounds, and removal instructions will be important in the evaluation of the patch.

You must assign a severity (or priority) to each patch, so you can determine how quickly a patch must be deployed or what particular systems would need a faster deployment. Questions that you can use to determine whether to raise or lower the priority of a patch include:

  • Are critical business systems impacted?
  • Are there mitigations in place that reduce the threat?
  • Is the vulnerability that the patch addresses being exploited "in the wild"?
  • Would a large number of systems/users be affected in case of an attack that exploits that vulnerability?
  • What information would be at risk if the system was left unpatched?

The following table presents an example of different priorities and their recommended deployment time frames:

Priority Recommended Deployment Time Frame Maximum Deployment Time Frame
1 - Emergency Within 6 to 12 hours Within 12 to 24 hours
2 - Critical Within 1 week Within 2 weeks
3 - Important Within 1 month Within 2 months
4 - Low Within 3 months Within 6 month

The resulting patch evaluation should be reviewed by at least two peers, as it mitigates the risk that critical information might be missed.

Phase 3 - Authorization and testing

Now that the patch has been classified and prioritized, it should be reviewed and authorized. The authorization might be part of your regular IT change management process, but it's important that the business stakeholders be informed and involved in the authorization process.

Many factors might affect the decision of whether or not deploy a patch at a particular time frame, so sometimes a countermeasure or workaround might be preferable in the short term. Note that even if an alternative countermeasure is deployed, the patch must still be scheduled for eventual deployment.

Once authorized, testing the patch should typically begin in a lab environment, built with systems that simulate the current production environment. If a lab is not available, a useful strategy is to deploy to small, controlled groups of machines, testing and certifying your line of business applications and your system configurations. You should also test that your rollback procedures work in case of problems. If during testing, problems or incompatibilities are detected, the established patch priority can help in the decision of what steps to take such as put the patch on hold, employ workarounds, deploy anyway, etc.

Phase 4 - Deployment

When a patch has been successfully certified as ready for deployment you should communicate to end users and administrators the release of a patch and what steps they should follow to install the update or report problems. The specific steps for the deployment will depend on the tool chosen for the task.

If problems are identified during the production deployment, depending on the type of problem, it could be an indication that the lab environment or the test machines need to include additional system configurations or applications.

A post-implementation review should be conducted afterwards to identify issues such as installation problems, process weaknesses and lessons learned. The patch management process should always be open to improvements.

One size does not fit all

Each organization is different and the exact procedures can and will vary, but you can use the basic steps outlined here as a starting point in developing your own strategy that mitigates risk with the lowest possible level of disruption and cost to your organization.

About

I am a technology specialist with over 10 years of experience performing a variety of corporate IT functions, including desktop and server operations, application development, and database administration. My latest role is in information security, fo...

3 comments
Charles Bundy
Charles Bundy

Good overview. With respect to stakeholders and communication I assume that phase 4 is oriented to backend app servers. In one organization where I worked we had resources for a certification lab we had thousands of seats and hundreds of servers. It just wasn't feasible to inform users of each and every patch. Nor was it necessary as they had a supportive help desk for problem reports and we used automated patch management tools for deployment.

blackepyon01
blackepyon01

Most techs say that it is a good idea. Personally, I've had more servers broken by faulty or incorrectly assigned patches. Why it is importiant to make regular backups, I know... I use WSUS to control updates to all my client machines, but I only ever update my servers manually, and during down times. Just in case something goes wrong (which it has). I've more than once come in in the morning only to find out that my server has bluescreened after restarting from an automatic update.

Justin James
Justin James

... here at TechRepublic, we offer a monthly article to help you with the Microsoft Patch Tuesday! J.Ja