Patch Management Policy: Steps, Benefits and a Free Template – eSecurity Planet
Patching and updating devices can be a hassle and can cause business disruption. Yet, unpatched vulnerabilities provide attackers with open opportunities to cause great damage – with studies showing unpatched vulnerabilities estimated to account for 30-60% of all breaches!
A Patch Management Policy formalizes the fundamental IT requirement that all systems and software should be patched and updated in a timely manner with:
This article can help organizations of all sizes start the process with a fundamental overview and a template:
To kick start any Patch Management Policy development, eSecurity Planet has developed a template that can be downloaded and modified. Notes of explanation or how to use the template are enclosed [between brackets] and these sections should be removed from final drafts.
Access the Patch Management Policy Template.
The sample patching policy contains many sections, but not all sections will be required for all organizations and others might require more details. See Common Patch Management Segments below for more details.
Organizations large and small can create a functional Patch Management Policy by following four key steps:
This first step requires the person or team drafting the policy to determine the key rules and steps within the patch management policy. For example some key questions to answer are:
The easiest way to create a first draft is to write down the current practice. Most IT teams have at least an informal process for obtaining and applying updates and patches – even if they are not written down or monitored. This first draft can simply be notes and does not need formal paragraphs.
With the basic rules in place the policy development team will need to verify the rules in two key ways: against external rules and against practical limitations.
To verify against external rules, the rough policy rules can be compared against necessary compliance frameworks (NIST, PCI DSS, etc.) and industry standards to see if they satisfy any applicable requirements. Any rule that does not meet compliance requirements should be adjusted to comply with requirements.
For example, a fire department might apply patches quarterly in practice. However, they might find that their state’s cybersecurity requirements require monthly patching and will therefore need to change their patching frequency to monthly to comply.
To test against practical limitations, the policy team should work with the patching team to test the rules. If the IT team cannot comply with standards and requirements with their current resources, should the organization adjust the rules or adjust the resources?
In the fire department example above, perhaps the volunteer fireman who used to apply the patches in their spare time will need to be replaced or assisted by a patch management tool or service that can meet the monthly regulatory requirements.
After verification of the basic patch management rules, the rules need to be formalized and approved by the organization’s management. At this point, rough notes need to be changed into formal paragraphs, tables, and appendices.
Once the initial draft is composed, it will need to be passed through management and possibly even legal counsel for approvals. The policy can be modified as required and the final draft signed off by the executives of the organization.
Even though the first formal Patch Management Policy may be approved by step three, keep in mind that all policies should be living documents that need to change as the organization changes. The policy should be periodically reviewed to verify the existing rules against new regulations, improving tools, changing IT asset mixes, and changing needs of the organization.
Also read: Patch Management Best Practices & Steps
Required Sections: These core sections should be part of every policy related to Patch Management.
Recommended Sections: These sections help to flesh out the patch management policy with additional rules to protect the organization and to help prepare the IT Department.
Bonus / Nice-to-Have Sections: These sections do not change the core elements of the patch management policy, but can make the policy more usable or comprehensive.
When creating any policy, an organization can pursue many different paths and options and emphasize different concepts. To create practical and useful policies, the following five best practices should be followed.
Patching policies can be long or short, but make the policy no longer than it has to be. Some organizations might even attempt to use a policy of only a few paragraphs.
However, such a short policy may not be as useful for other organizations that need to provide more direction. The eSecurity Planet template seeks to be more comprehensive, and organizations can add or remove content to fit their needs.
Policies must satisfy compliance, but they won’t be successful if they do not work for the team responsible for the policy. Don’t reinvent the wheel or add unnecessary details or instructions.
Tools and processes must fit the true needs of the organization and should not be followed blindly or without thought. For example, some organizations only patch vulnerabilities with a score of 7 or above, yet these ratings only show the risk of the vulnerability and must also be combined with the likelihood of exploit and the value of the asset to the organization.
For example, a data exfiltration bug of 8.0 on the marketing web server that only contains publicly released documents shouldn’t have higher priority than a 6.5 remote code execution vulnerability on the server with the company’s Active Directory (AD) services. The impact to the organization of a fully compromised AD simply would be too great to risk even modest possibilities of exploitation.
Policies work best when they reinforce each other, such when combined with an asset management policy and a risk register or risk management program.
The patch management policy outlines the plan for patching vulnerabilities. The policy also needs to make sure the plan is followed and the vulnerabilities were actually eliminated.
The patch management process should be measurable and testable to prove compliance with the policy and any relevant compliance frameworks. Reports provide metrics for measurement, log files provide evidence, and vulnerability or penetration testing can test that the patching process was completed correctly.
Tools and automation work well and should be used. However, they tend to focus on certain parts of the IT ecosystem such as Operating Systems and common software such as Microsoft Office or Adobe Acrobat.
Tools often lack comprehensive coverage of third-party applications, firmware, internet-of-things (IoT) devices, networking equipment, backup applications, and more. The policy should not rely upon the tools or a patch management service to determine the asset list for the patching policy.
The IT Department must ensure that all resources that need patches are tracked and patched – even when applying the patch is difficult or may require manual patching.
The individual sections of a policy should only cover the broad concepts such as “the policy should cover all assets.” Additional details can be covered in the appendices if required, but many implementation details should be left to the implementation team so allow flexibility that can evolve with the organization’s needs.
Details will change over time as technology evolves and the resources of the organization change. A policy with too many details will require constant change to remain accurate and relevant and will become an unnecessary and unwelcome burden.
All companies deploy security strategies, even if the strategies have not been written down. However, when strategies fail to protect the resources, the organization will be compelled to prove that the IT and security teams executed the appropriate cybersecurity and IT policies.
Written policies provide written instructions that can be used to show the intended strategy of the organization. Policies do not directly improve security, but a lack of policy can be seen as negligence.
Many compliance frameworks, such as the U.S. National Institute of Standards and Technology (NIST), consider policies to be a fundamental requirement for even the lowest levels of cybersecurity maturity. Policies help to show compliance with relevant compliance frameworks.
For example, NIST developed the Framework for Improving Critical Infrastructure Cybersecurity and within this framework, a patch management policy would fall under: Information Protection Processes and Procedures (PR.IP) Section 12 which requires that “a vulnerability management plan is developed and implemented.”
An auditor can easily use the policy as a starting point to understand how a company does, or does not, comply with a framework. Of course, the organization will then need to back up the written policy with evidence of action.
Reports and log files can provide evidence of action as well as a metric for the company to measure success. For example, if reports show that the patching of critical updates takes longer than desired, the management can consider adding more resources or outsourcing. Some organizations even switch from locally installed software or even appliances to Software-as-a-Service (SaaS) implementations to eliminate the need for patching and updating.
Also read:
Many organizations feel that their undocumented patch management processes will not be affected or improved by taking the time to put them into writing. However, this attitude overlooks five key benefits to an effective patch management policy.
An effective patch management process updates systems and seals off cybersecurity vulnerabilities. An effective patch management policy formalizes the process and can help the organization:
Like surgeons, IT professionals often see written documentation as a form of weakness. Yet even surgeons find that a checklist can reduce deaths by as much as 47%.
IT processes may not share the life-or-death stakes, but the survival of the business still depends upon uptime and protected assets. Formalized documentation of the patch management process as a policy provides an internal checklist to protect assets, maintain uptime, and minimize mistakes.
Happy bosses reduce stress for everyone. The formal reports generated by effective patch management policy requirements help explain the status of assets throughout the organization and deliver peace of mind to business stakeholders and decision-makers.
Even though most executives and board members cannot understand the technical details for the IT infrastructure, a step-by-step patching process outlined in a policy eliminates confusion regarding the objectives and targets of the patch management policy. Policies reduce technical details into numeric reports and easy to understand metrics that make the status of the patch management process understandable and accessible to non-technical executives.
Even a fully-updated and patched IT infrastructure can suffer a breach. An organization that suffers a breach due to an unpatched system faces an uphill battle against charges of negligence in any civil or criminal court cases, regulatory action, insurance claims, or even defending an IT employee against being fired.
Judges, juries, and regulators will concede that IT departments cannot be held to unreasonable expectations of perfection. Organizations that can demonstrate that they were in compliance with a reasonable policy will have an advantage. Internally, and even angry executives cannot complain about employees that fulfilled the requirements ratified by other company executives when they signed off on the policy.
The written policy provides the reasonable standards and executive signatures on the policy confirm their expectations. Of course written policies that do not conform to regulatory guidelines may offer less defense.
AT&T notes various regulatory standards for patching and update frequency, but even with variance, the policy must be close to the expectations. For example, if the U.S. Department of Defense (DoD) requires current patches within 21 days, a DoD vendor with a written policy of quarterly patch updates will likely not be considered to have reasonable standards and will likely be accused of negligence in a breach.
Any compliance framework will establish rules. An organization seeking to comply with the framework must show evidence that they understand the rules and evidence that they comply with them.
Auditors always ask for written policies to help them easily understand the objectives of the organization and the type of evidence they can expect to receive. Fulfilling a written policy that has already conformed to a compliance framework makes it easy for the organization to satisfy the regulatory requirements.
Executing patch management policies can:
However, written policies deliver even more benefits.
First, the written policies help with IT personnel transitions by providing documentation of expectations and reports of past activity. These will combine to save time by helping new IT employees grasp the status and expectations of the organization with less training.
Written policies also help to formalize accountability within the organization and make it more difficult for systems to be overlooked or for business managers to put off updates that might interfere with business operations. The IT Department can point to the executive-approved-policy as a mandate to obtain cooperation.
A good patch management policy can provide a helpful checklist to help create an efficient, and reliable patch management process. The reduced cybersecurity risk from the patching and the improved communication from the reports will improve overall business processes and executive confidence.
However, patching cannot solve all problems. Patch management does not cover whether or not an organization has the correct software in place for their needs or if the software settings are properly configured.
Patch management policies provide a very helpful part of an overall cybersecurity program but need to be combined with other critical policies and strategies to ensure a resilient organization.
Top Products
Related articles
eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.
Advertise with TechnologyAdvice on eSecurity Planet and our other IT-focused platforms.
Property of TechnologyAdvice.
© 2022 TechnologyAdvice. All Rights Reserved
Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.
