Patch Management Guidance

Purpose and scope

The Treasury Board Directive on Security Management^{Footnote 1}, as part of Appendix B: Mandatory Procedures on IT Security Controls, requires departments to “Implement measures to protect information systems, their components and the information they process and transmit against attacks that leverage vulnerabilities in information systems to affect their integrity and that could have an impact on their availability or confidentiality (for example, malicious code).” This includes implementing corrective actions such as applying patches to address vulnerabilities. In addition, the Canadian Centre for Cyber Security (CCCS)^{Footnote 2} prioritizes patching operating systems and applications as the second most important IT security action an organization can undertake to minimize intrusions and their impacts.

This document provides guidance on establishing an effective patch management strategy and identifies recommended key performance indicators (KPI) to measure in order to facilitate a continuous improvement approach.

The metrics in this guidance are recommended minimums and are provided to inform the evolution of an enterprise approach to patch management.

This guidance aligns with the following government artifacts:

• Policy on Government Security^{Footnote 3}
• Policy on Service and Digital^{Footnote 4}
• Directive on Security Management^{Footnote 1}
• Digital Operations Strategic Plan: 2018–2022^{Footnote 5}
• Government of Canada Cyber Security Event Management Plan (GC CSEMP)^{Footnote 6}

Target audience

This document targets IT service owners, IT service administrators and IT security operators responsible for acquiring, testing, prioritizing, deploying and verifying security patches throughout the federal government.

Patch management dependencies

A patch management process requires proper accountability and ownership, along with good governance and stewardship. Patch management is one of a number of components in a defence‑in‑depth strategy that should also include secure architecture design, integrated risk management, business continuity planning, and security operations functions such as monitoring and incident response.

The patch management process has foundational dependencies with three core operational capabilities, illustrated in Figure 2‑1 Patch management foundational dependencies, which must be in place to ensure its efficiency and effectiveness.

Figure 2‑1 - Text version

Figure 2-1 is a venn diagram that illustrates how the relationship between vulnerability management, configuration and change management, and asset inventory and discovery is a part of the whole patch management process.

Notification

Triggers for the patch management process might include vulnerability notifications from:

• Enterprise patch management software: The software maintains an application inventory and patch definition database, notifying administrators when new updates are published and downloaded from trusted sources.
• Mobile device management: A platform for managing mobile devices such as tablets and smartphones will include notifications and policies for remotely updating device apps.
• CCCS publications: Alerts and advisories from CCCS are available via RSS and listed on their website^{Footnote 8}. CCCS publications are also sent to each GC organization’s generic departmental IT Security Operations mailbox, from which they can be forwarded to team mailboxes or individual operational staff.
• Vendor notification: Individual vendors typically offer a subscription service for notification of patches and updates. 
• Internal operational processes: An organization can trigger the patch management process as a result of internal operational processes, most often those associated with security, such as resulting from an incident, resulting from a VA.
• Other: Media reports, social media, cyber security companies, vulnerability aggregator services, mailing lists, RSS feeds, and so on.

Assessment

The severity rating that the vendor or developer has assigned to a patch is a prime indicator of its importance and of the priority it should be given; however, patch prioritization in the GC is also a risk assessment activity that considers the risk that a vulnerability represents in the context of the operating environment.

CSE’s ITSB‑96 – Security Vulnerabilities and Patches Explained^{Footnote 9} identifies the factors that should be considered by GC departments when determining the priority for a patch, including its potential impact on high‑valued assets, threat profile, exploit complexity and likelihood, and the impact of mitigating controls on its exposure. This CCCS guidance should be consulted and referenced when crafting a departmental assessment framework for patch priority.

Deployment schedule

Once priority has been assessed, a determination on a deployment time frame must be made. While a patch that addresses functionality might have a deployment schedule based solely on a concern with minimizing the impact to business, a security patch, by default, must be set at a higher priority. CCCS’s ITSB‑96^{Footnote 9} also provides guidance regarding deployment time frames for security patches in the GC and their recommendations are summarized in the following table:

Table 3‑1 CCCS suggested deployment schedule

Patch priority	Suggested deployment schedule
Extreme	Emergency: Deploy within 48 hours
High	Deploy within 2 weeks
Medium	Deploy at next major update or within 3 months
Low	Deploy at next major update or within 1 year

CCCS’s deployment schedule only suggests timelines for deployment. In actuality, an organization should take into consideration risk tolerance and exposure to a given vulnerability and associated attack vector(s) as part of a risk‑based approach to patching, while also fully considering their individual threat profile. Patch management tools continue to improve the efficiency of the process and enable organizations to hasten the deployment schedule.

As a general rule, GC organizations should always prioritize critical systems and services in any patching scenario. Critical systems and services are defined by TBS as “those whose compromise in terms of availability or integrity would result in a high degree of injury to the health, safety, security or economic well‑being of Canadians or to the effective functioning of the GC”^{Footnote 3}.

Figure 3‑2 illustrates the steps and rationale for arriving at the correct patch priority and corresponding deployment schedule. When employed, the process must also take into consideration the unique conditions of each situation and the factors listed in the Assessment section, including but not limited to existing workarounds or mitigating controls, threat profiles and vulnerability details, and potential for collateral damage, specifically to critical assets and services.

Figure 3‑2 - Text version

Figure 3-2 presents a flowchart for determining the actions to take in response to a vulnerability notification. The steps are as follows:

• After receipt of a notification, the organization determines whether they have deployed the affected product and version(s), and if the vulnerable components of the software are enabled. If the software is deployed but the vulnerable component(s) are not enabled, a patch may be deployed at the next update or within the year.
• If the vulnerable component(s) are enabled, the organization then determines whether the security impact is low, medium, high, or extreme.
•  A low impact vulnerability may be addressed at the next update or within the year. All other ratings require the organization to continue with the process to determine whether a workaround to mitigate the vulnerability exists and is implemented.
• If the answer is yes, the update can be deployed at the next update or within the year. If a mitigation is not in place, the security impact rating is used to determine the next course of action.
•  For medium and high impact vulnerabilities without a chance of significant collateral damage, deployment of an update may occur within three months.
• For medium or high impact vulnerabilities that could incur significant collateral damage, for example by exposing additional assets to risk of compromise, patch deployment should occur within two weeks.
• If a vulnerability impact is determined to be extreme but without risk of significant collateral damage, the two-week window for patch deployment also applies.
• For extreme impact vulnerabilities that also include a risk of significant collateral damage to other assets, an emergency deployment schedule of patching within 48 hours of notification applies. 

Acquisition

Patches are commonly acquired from the software vendor or other trusted source, for example community software development or standard Linux repositories. Enterprise patch management software can automate the download and verification of patches, typically using verification methods that are based on integrity checksums and digital signatures.

If a patch is obtained via manual download, the source and integrity of the package must be confirmed prior to its deployment.

Testing

Patch testing can be carried out in a test or sandbox network that simulates the production environment. While this is the ideal approach, it is also the most expensive and impractical. Virtualization can be used to minimize hardware costs and capitalize on deploying a wide array of systems in a test environment, but it will not address the overall overhead of maintaining a parallel environment.

The recommended alternative is to leverage a community of users across all business units of the organization as a production test bed for patch deployment. Feedback regarding faults can be used to determine whether there is an operational impact to deploying a patch. That impact must then be measured against the risk of delaying deployment or not patching and resorting to a workaround.

Workarounds are temporary fixes, such as disabling the vulnerable functionality or implementing access controls to limit its exposure. They can be considered if faults are identified and waiting for an operable patch is not a viable option due to heightened risk.

Patches can be tested individually or alternatively bundled to ensure that faults are detected prior to wide‑scale deployment.

Deployment

Enterprise patch management software is the preferred method for distribution of software updates. Patches can be bundled or applied incrementally and should be staggered across the enterprise to ensure that a service outage does not occur if a fault materializes that was not revealed during the testing phase.

Auto‑update is a feature common for many applications but generally not recommended for an enterprise environment given that its use removes patch testing, beyond that performed by the vendor, from the process. That said, there are situations where auto‑update may be the preferred deployment method, for example in the case of web browsers and mobile apps. Other scenarios may apply and GC organizations must perform their own risk management due diligence when deciding whether and where to enable auto‑update functionality.

Note also that enterprise deployment may not be feasible in all instances, such as in the case of GOTS or custom applications, and alternative deployment options such as scripted or manual patch application should be accounted for in an organization’s patch management strategy to address outliers and exceptions.

Validation

An audit of patch deployment success and failure rates should be performed after each deployment to identify outliers, and to trace and correct patch installation failures. The asset inventory and discovery features of an enterprise patch management suite will reflect the status of the deployment and provide the statistics to satisfy KPI and Service Level Agreement requirements defined in the organization’s strategy.

Execution of a rollback process may be required if a patch deployment results in unexpected impacts on production systems. Insights gained from investigation and correction of installation failures should be used to augment the patch management program and minimize the need for similar rollback and corrective activity in the future.

Organizational infrastructure

GC departments and agencies are the authority for their own IT infrastructure and are responsible for implementing tools and processes to meet standard timelines for remediation and for ensuring quick response times for emergency or critical patch deployment^{Footnote 1}. For organizations that operate autonomously, this infrastructure might include servers, network equipment, workstations, applications, and so on. For those under the purview of Shared Service Canada (SSC), it would be a subset of the above.

Shared Services Canada

SSC acts as service provider for GC departments and has developed its own Patch Management Standard which defines the stages and steps, and the roles and responsibilities for effective patch management of SSC infrastructure in enterprise data centres and legacy client networks^{Footnote 10}.

SSC’s responsibilities do not extend to the organizational infrastructure referenced above. As such, the departments serviced by SSC are required to coordinate change and configuration management activities with SSC, including all patch management activities, in order to ensure proper testing, prioritization, deployment and validation.

Cloud service providers and managed service providers

The GC Cloud Adoption Strategy prescribes a “cloud‑first” approach in which cloud is the preferred option for delivering IT services in the GC^{Footnote 11}. Cloud service providers may be leveraged to deliver one or more of the defined cloud service models of Infrastructure as a Service, Platform as a Service and Software as a Service.

GC cloud consumers who leverage a cloud service provider or other value‑add third party, such as a managed service provider, must account for patch management and emergency patch management in their contracts.