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.