Creating a patch management policy: Step-by-step guide (original) (raw)

Nothing in life is perfect, especially when it comes to software. When 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 doesn't have to succumb to 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.

A written patch management policy defines what, why and how patches are applied to various systems. The policy is a framework to help administrators identify and categorize applications, operating systems and hardware on the network, including mobile devices, that require structured and unstructured updates, specify where the necessary patch code can be retrieved and outline a process for determining what devices must be updated, why and by whom. A patch management policy also provides guidance on how to roll back changes in the event of a conflict and document the post-patching process for future reference.

Patch management policies for enterprise environments typically must 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 for one of three reasons:

1. Adding new features and functionality.
2. Fixing code that has inadvertently caused performance and operability problems.
3. Remediating security vulnerabilities that could be exploited through code modification.

A comprehensive patch management policy requires an ongoing series of action items.

A multitude of problems can arise that affect the usability of IT and OT systems without a comprehensive policy that's closely followed by every stakeholder. Additionally, lack of proper patching opens the door to a host of cybersecurity issues, including data theft and loss, as well as denial-of-service attacks on mission-critical services.

Patching 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.

What should a patch management policy include?

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 the components that can and should be patched. Therefore, the policy should include a combination of manual and automated tasks that are used to find systems and applications and categorize them into manageable groups.

Patch information gathering

The collected inventory of IT systems that fall within the patch management policy helps determine when a patch 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 issue for which the patch was designed.

Patch prioritization

Building on the information gathered, software and firmware patches are prioritized and scheduled based on risk-reward factors. 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 formal part of the patching process requires those responsible for implementing the patch to request a maintenance window for when the software update will occur. The request must specify deployment and rollback steps.

Patch testing

To ensure successful deployment, a software patch should be tested in a sandbox or lab environment to assess its potential impact once put into production. Testing will help ensure that the patch produces the desired results and won't have a negative impact on production systems or applications.

Patch deployment

The implementation or deployment section of the patch management policy walks through the software update outlined in the patch request and approval procedure.

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 side effects not discovered in the testing phase that could negatively impact 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 might help to simplify future updates.

Compile a list of key performance indicators to measure the overall success of a corporate patch management policy.

How to create a patch management policy

Take the following actions when formulating a patch management policy:

Click to download template.

1. Outline the procedure for determining how software and devices will be identified and categorized.
2. Identify who's responsible for patching the various categories of software and devices. Include not only in-house IT staff but software and system vendors as well.
3. Document how tools, processes and external resources will be used to find relevant vulnerabilities and bug and feature updates.
4. Formulate a patch change request template along with an approval process and rollback procedures.
5. Create patch lifecycle timelines for various system patches that specify how quickly a patch must be tested and deployed based on relevant business and cybersecurity factors.
6. Detail a process to monitor the effects of a patch and the negative side effects that would merit a rollback.
7. Formulate a patch results documentation template to use after every patch maintenance window.

The downloadable template offers a good start to writing a policy.

Patch management policy best practices

When creating a patch management policy for your IT department, it's important to take steps to ensure that no processes or tasks fall between the cracks. Here is a list of best practices, with guidance on each procedure.

Risk and compliance assessment. The security team should conduct regular vulnerability and compliance assessments and translate them into an assessment report that is easily accessible by IT managers and patch integrators. This will identify any flaws and help to prioritize patching efforts based on the level of risk.

Patch management tools. Taking advantage of software that streamlines the testing and deployment process can save time. IT should conduct a thorough vetting of patch automation tools annually.

Centralized patch repository. To keep software and system patches organized and visible, create a centralized patch catalog where past and future software update packages can be managed and stored.

Patch sandbox. Create a physical or virtual patch testing environment where software updates can be tested without impacting the production environment. In most cases, a virtual sandbox is ideal because it is more cost-effective and can be more easily adjusted to mimic the production environment.

Patch schedule. Creating an organization-wide patch schedule will create visibility into systems and their past and present patch history. The schedule will also indicate the required patch review and deployment frequency for each application or system and when each one should ideally be updated to minimize production downtime.

System patch prioritization. Unless vulnerability or compliance reports say otherwise, a patch prioritization document is the place to indicate the most critical applications and systems on the network and which ones should take priority over the others.

Post-patch monitoring. It's important to create monitoring procedures for each application or system. These documents detail the monitoring and testing procedures used to ensure that a patch was successful and whether there were unexpected side effects.

Patch rollback and recovery procedures. Speed is of the essence when a patch goes wrong. Developing a rollback plan for every software and hardware system helps ensure that patches can be reverted or bypassed to minimize disruption to business operations.

Change management. There should be a change control policy prescribing an overarching set of processes for documenting changes made to production environments, and patching is an important type of change to be covered in such a policy.

Patch results documentation and policy review. Documenting the results of both successful and failed patch attempts can make people aware of typical challenges, their possible solutions and some lessons learned. This stage is also an opportunity to consider adjustments to the overall patch policy.

Benefits of a strong patch management policy

A patch management policy can provide peace of mind to IT stakeholders, decision-makers and patch integrators by specifying processes that, if properly followed, will ensure software and infrastructure are free of bugs and vulnerabilities and deliver optimal value to the enterprise. A step-by-step patching process also supports risk management, eliminates a large amount of security risk, and includes well-documented procedures and results that enable effective historical review and auditing.

Andrew Froehlich is founder of InfraMomentum, an enterprise IT research and analyst firm, and president of West Gate Networks, an IT consulting company. He has been involved in enterprise IT for more than 20 years.