MSP Business
How to Create a Patch Management Policy
In any given week, Microsoft typically releases one hundred or more patches. Couple that figure with the numerous other patches released on a regular basis by other vendors, and the sheer volume can feel overwhelming.
How do you know which patches affect your systems? If you're unable to install all the patches at once, how can you determine which ones to prioritize? How do you ensure you didn't miss any critical patches? How do you make sure all of your admins follow the same processes when working with patches?
A patch management policy helps answer questions like these. By formalizing your team's approach to patches, patch management policies add consistency and regularity to the process of finding, installing, verifying and monitoring patches.
What Is a Patch Management Policy and Why Is It Important?
A patch management policy is a set of processes and guidelines that an organization uses to manage patches. It often focuses on security patches in particular, since they are usually the most critical category of patch, but it can apply to other types of patches (like those that address software performance issues) as well.
Patch management policies also make it simple to update patching procedures, which may be necessary if you adopt a new type of system that has unique patching requirements, for example. And because documentation of patching operations is part of a patch management policy, having such a policy in place ensures that you maintain a record of what was patched, in case you need that information at a later date.
Components of a Patch Management Policy
A comprehensive patch management policy should define several specific procedures and guidelines.
Asset Tracking
Your policy should specify how you keep track of the assets in your IT environment. Where do you store lists of assets, and how are those lists updated as the environment changes? This information is critical for ensuring that you know which systems you are managing and which patches apply to them.
Beyond merely listing assets, break them down into categories (like operating systems, applications and networking hardware). You can also sort them according to their level of importance to the business. A test/dev server may not require the same level of priority as a production system, for instance.
Teams and Responsibilities
A patch management policy should identify who participates in patching operations and what their roles are. Be sure, as well, to define the notification and reporting processes for each team member.
Risk Assessment and Classification
While you can't anticipate every attack scenario ahead of time, you can plan in advance for many common threats.
Include in your policy a list of all potential vulnerabilities and risks of which you are aware, and classify them by severity level, based on the threat they pose to the business. You should also align vulnerabilities with endpoints on your network, so that you know which systems you should patch first.
Further reading Guide to Endpoint Security Monitoring
Risk assessments should also include evaluation of the potential consequences of leaving a system unpatched, and the procedure you would follow if an exploit took place on an unpatched system.
Patch Classification Guidelines
In order to ensure the smoothest process for installing patches, define categories ahead for sorting patches:
- Critical patches: These are patches that fix critical security or performance issues, and should be installed immediately.
- Routine patches: Patches that fix non-critical issues can typically be tested first, and can be installed at the most opportune time (such as overnight, when systems are idle).
- Missed and failed patches: Keep track of patches that you didn't install for whatever reason, or that failed to install.
- Incompatible patches: Record, as well, patches that don't apply to your systems. It may be important after the fact to confirm that a patch wasn't installed because it was not relevant, rather than because it was overlooked.
Patch Testing
In cases where patches aren't critical enough to require immediate installation, it's wise to install the patch in a test environment before applying it to production systems. That way, you can catch issues like patch conflicts with other applications before you introduce the patches to business-critical systems.
Include guidelines in your patch management policy for when and how you will perform patch testing, as well as how you will make a decision about whether a patch is ready to install based on the outcome of your testing.
Patch Release
Develop guidelines that specify how you will go about applying patches, based on the classification categories you created. You should also determine which patch installations will be automated, which will be performed manually and who will be responsible for manual installation.
Decide, as well, when patches will be installed; it's preferable to apply them after hours in order to minimize disruptions to end users, except in the case of critical patches.
Further reading Handling Updates and Patches
Monitoring and Assessment
The final component of a patch management policy is how you will monitor patch installation. Set guidelines for checking for and rerunning failed patches, as well as keeping track of which patches were installed and whether they achieved their intended results. You should document this information, so that you'll have it on hand if it becomes necessary.
Conclusion
Establishing a patch management policy is a key step toward ensuring that you manage patches in an efficient and reliable way. The policies you adopt help all team members stick to the same rules, while also minimizing the risk that you'll overlook patches or fail to categorize them properly.
Safeguard the integrity of IT environments with best practices for:
- applying patches
- scheduling patches
- managing patching activity
