Creating a patch management policy: Step-by-step guide
A comprehensive IT patch management policy is insurance against network hardware and software prone to bugs and vulnerabilities that can disrupt critical business processes.
Nothing in life is perfect, especially when it comes to software programs. Once vendors first release their software and firmware to the public, various bugs, security flaws and functional deficiencies are inevitably discovered. With the right policy and structure in place, software programs won't succumb to various performance and security issues.
What is a patch management policy?
A patch management policy is an IT strategy document that outlines the processes and methodology used to ensure hardware and software on a corporate network are regularly maintained. The policy is a framework to help administrators identify and categorize systems and applications on the network that require structured and unstructured updates, find the source of where the patch code can be retrieved and outline the process of determining what devices must be updated, why and by whom. A patch management policy also provides details on how to roll back in the event of a conflict and document the post-patching process for future reference.
Patch management policies within enterprise environments cover a wide range of information and operational technology (IT/OT) assets, systems and applications, including the following:
- device endpoint OSes
- server OSes
- IoT firmware
- operational technologies
- virtualization platforms
- network and device peripherals
- network components
- applications
- databases
- storage platforms
- unified communications systems
- IT management and monitoring tools
Why is a patch management policy important?
Software and firmware must be patched on various IT/OT systems for one of three reasons:
- adding new features and functionality;
- fixing code that has inadvertently caused performance and operability problems; or
- remediating one or more information security vulnerabilities that could be exploited via code modification.
A written patch management policy defines what, why and how patches are applied to various systems. Without a comprehensive policy that's closely followed by all stakeholders, a multitude of problems can arise that affect the usability of IT/OT systems. Additionally, lack of proper patching opens the door to a host of cybersecurity issues, including data theft and loss and DoS attacks on mission-critical services.
What should a patch management policy include?
Patching IT/OT systems is a lifecycle management process whose speed varies depending on the systems in question and the patch's potential impact on the business. The bigger the performance, usability or security impact, the faster a patch must be applied. From a high-level perspective, a patch management policy consists of the following procedures.
System identification
The entire corporate network must be inventoried continuously to identify all technology components that can and should be patched. Included is a combination of manual and automated tasks that are used to find and categorize systems and applications into manageable groups.
Patch information gathering
The collected inventory of IT systems that fall within the patch policy helps determine when a patch update is required and where to find and download the patch. Included are subprocesses and tools, such as the use of security vulnerability scans, scheduled patch management audits, vendor patch notification announcements and a review of the bug, feature or vulnerability impact for which the patch was designed.
Patch prioritization
Building on the information gathered, prioritize and schedule software and firmware patches based on risk/reward factors to the organization. Patches that address critical bug fixes or severe vulnerabilities, for example, will have a higher priority and be applied faster than a patch for noncritical fixes or feature enhancements.
Patch request and approval
This formally written part of the patching process requires those responsible for implementing the patch to request a maintenance window for when the software update will occur. Within this request, information pertaining to specific deployment and rollback steps is necessary.
Patch deployment
Implementation of the patch walks through the software update outlined in the patch request and approval procedure during the specified maintenance window time frame.
Patch results monitoring
No matter how small the patch, the systems and applications updated with new code must be monitored to verify that the patch fixed a specific problem -- or didn't have unintended negative side effects that may hurt business operations. If severe problems arise, rollback steps outlined in the patch request and approval procedure are executed to revert the changes.
Patch results documentation
Successful and unsuccessful patches must be documented with information about the results of the patch installation along with any suggestions or caveats that can be used to simplify future system updates.
How to create a patch management policy
Take the following actions when formulating a patch management policy:
- Outline the procedure for determining how software and devices will be identified and categorized.
- Identify who's responsible for patching the various categories of software and devices.
- Document how tools, processes and external resources will be used to find relevant vulnerabilities and bug and feature updates.
- Formulate a patch change request template along with approval process and rollback procedures.
- Create a patch lifecycle timeline for various system patches that specify how quickly a patch must be deployed based on various business and cybersecurity factors.
- Detail a process to monitor the effects of a patch and what negative side effects would constitute the triggering of a rollback.
- Formulate a patch results documentation template for use after every patch maintenance window.
Benefits of a strong patch management policy
Patch management policies deliver peace of mind to IT stakeholders and decision-makers that, if properly followed, will ensure business software and underlying infrastructure are free of bugs and vulnerabilities and deliver the most value possible to the enterprise. This step-by-step patching process supports risk management, eliminates a large amount of security risk, and includes well-documented procedures and results for historical review and auditing.
