Purpose
Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Applying patches (security updates, etc.) at the earliest possibility limits exposure to software vulnerabilities.
This document establishes the guidelines for patch management within the Canadian Digital Service (“CDS”).
Scope
This guidance focuses on all CDS-built assets and services and to CDS staff who create, deploy, or support these assets and services.
Responsibilities
Internal Site Reliability Engineering
Site Reliability Engineering (SRE) is responsible for maintaining any tooling that is developed by the SRE Team (e.g. custom GitHub integrations, secret management, CDS-wide load testing tools) which are used by CDS teams.
SRE will also help surface security issues for teams to act upon.
CDS Teams
CDS development leads and their teams are responsible for ensuring that software they manage is maintained through regular software updates and patching.
Where no patch is available for a known vulnerability, CDS teams are responsible for triaging those vulnerabilities and determining other risk mitigation approaches.
CDS teams are responsible for ensuring a complete and accurate inventory of assets.
Platform Core Services Team
The Platform Core Services team is responsible for routinely assessing compliance with the patch management standard and will provide guidance to all the stakeholder groups in relation to issues of security and patch management.
Patching recommendations
- CDS team leads or their delegates are responsible for the assessment and remediation of system components and software under their management or supervision.
- All patches or configuration changes should be deployed to system components and software as set out in the timeframes in the Patching Schedule below.
- Patches with a severity rating of ‘Critical/Very High’ should be installed within seven (7) days.
- Where the deployment of patches rated as ‘Critical/Very High’ is not possible within seven (7) days, either appropriate compensating controls or a temporary means of mitigation should be applied.
- If no remediation is available to address a vulnerability, the relevant Head of should approve any compensating or mitigating controls or, where no fix is available, approve the acceptance of risk.
- Remediation steps should be documented by team leads and a timeframe identified for review and future patching.
- Shorter timeframes for patching may be needed based on the assessed severity and potential/actual impact (e.g. zero-day vulnerabilities).
How
Teams should keep all systems libraries and software up to date by incorporating small incremental changes at a manageable and regular cadence.
Automate patch management
Onboard your project to Renovate.
Teams can enable the Renovate GitHub app on the project’s GitHub repository. This will create the Renovate configuration pull request (PR). Once the configuration is merged, use the Dependency Dashboard to create and merge the pin dependency PR.
Patching schedule
Minor and patch releases
Each sprint should have an item to test and merge the Renovate minor, patch and pin PRs as they are automatically created each week.
Major releases
Major version updates should be evaluated on the Dependency Dashboard and addressed at least once every 2 sprints. Cycles may take longer to update code to accommodate a major release, so this should be incorporated similarly to a small feature addition.
Security Vulnerabilities
Vulnerability PRs should be merged according to our patching timelines which are based on severity and exploit availability.
In order to protect CDS assets and services from known vulnerabilities, security patches should be deployed in a suitable time frame, based on severity and exploit availability, as set out below:
| Severity | Public exploit available | No known exploit |
|---|---|---|
| Critical / Very High | 24 hours | 7 days |
| High | 48 hours | 2 weeks |
| Medium | 7 days | Monthly |
| Low | 2 weeks | Monthly |
When to silence an update
Temporarily
Close the PR containing the update with a comment explaining why it’s not being addressed or merged at this time. This will keep it tracked in the Renovate Dependency Dashboard and allow it to be applied easily in the future.
Permanently
Update the project’s Renovate config directly with an ignoreDeps block for the dependency. Include an explanation for this change in the PR that updates the Renovate config.
GitHub vulnerability alerts
Our project repos will also receive vulnerability alerts from GitHub. These should go through the same vulnerability assessment and patching process as a Renovate PR.
If a vulnerability is found that does not impact the project, it can be dismissed using the Dismiss alert button by providing a reason, along with a comment explaining the dismissal.
Vulnerability assessments
Patch management is prioritized based on the severity of the vulnerability the patch addresses. In most cases, severity ratings are based on the Common Vulnerability Scoring System (CVSS).
In addition to the CVSS severity ratings, there are additional factors that go into determining a tailored severity rating for CDS use of the vulnerability component(s).
| Risk Level | Examples |
|---|---|
| Extreme risk | Vulnerability allows remote code executionCritical business systems and information are affectedExploits exist and are in useSystem is connected to the Internet and doesn’t have mitigation controls in place |
| High risk | Vulnerability allows remote code executionCritical business system information is affectedExploits exist and are in useSystem is in a protected enclave with strong access controls |
| Medium risk | Vulnerability allows attacker to impersonate a legitimate user on a remote access solutionSystem is exposed to unauthenticated usersSystem requires two factor authentication and administrator level remote login is disallowed |
| Low risk | Vulnerability requires authenticated users to perform malicious actions (e.g. SQL injection)Affected system contains non sensitive, publicly available informationExisting mitigation controls make exploitation unlikely or very difficult |
Patching exceptions
There may be instances where risk mitigation may be preferable to patching. Where risk mitigation may be preferable, the risk mitigation alternative selected should be determined through an outage risk to exposure comparison.
There may also be instances where a vulnerability is determined not to impact the project. Where this is the case, the determination regarding impact should be documented and the vulnerability can be dismissed.
Where the deployment of ‘critical’ or ‘very high’ security patches within seven days is not possible, either appropriate compensating controls or a temporary means of mitigation should be applied to reduce the exposure.
Factors to consider when assessing patching timelines and approach include:
- The likelihood of risk and whether exploitation has already been observed
- Exposure of the systems or services – are they internet-accessible or government-wide?
- Consider the context of the vulnerability, including severity rating by the vendor, attack complexity, whether there is protected data on the system, etc.
- Are there workarounds or temporary solutions to help mitigate the risk?
Performance indicators
Monitoring and reporting on the indicators below will allow us to evaluate the effectiveness and efficiency of our patch management approach.
Coverage:
- The percentage of systems and applications within the organization inventoried and covered by automated patch management
Efficiency and effectiveness:
- Critical patches will be applied within seven days
- Number of untriaged vulnerabilities per product, grouped by severity
- How often products are automatically checked for compliance
- The percentage of products patched within 7, 14, 30 days after a vulnerability is identified
- The percentage of products within the organization that have no untriaged vulnerabilities
- Average time elapsed between a patch’s availability and its production deployment per level of severity rating
References
- Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN): 6.2.6 Vulnerability management
- Directive on Security Management: Appendix B: Mandatory Procedures for Information Technology Security Control
- ITSG-33: SI-2 Flaw Remediation
- TBS Patch management guidance
- Top 10 IT security action items: No.2 patch operating systems and applications – ITSM.10.096
- National Cyber Security Centre: Vulnerability management