From 76656c087bac653b56603b67c651cf5f1fc81c49 Mon Sep 17 00:00:00 2001 From: Hannah Vesey-Byrne Date: Fri, 13 Dec 2024 11:50:15 +0000 Subject: [PATCH 1/4] Create threat modelling policy v0.5 This is Simon's threat modelling policy markdown text. --- docs/policies/threat modelling policy v0.5 | 121 +++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 docs/policies/threat modelling policy v0.5 diff --git a/docs/policies/threat modelling policy v0.5 b/docs/policies/threat modelling policy v0.5 new file mode 100644 index 0000000..73023ed --- /dev/null +++ b/docs/policies/threat modelling policy v0.5 @@ -0,0 +1,121 @@ +title: "Threat Modelling Policy-V0.5" +summary: A markdown template for SBD policies +authors: + - Simon Bishop +date: 2024-12-21 + +**Policy** + +## Purpose +This policy establishes guidelines for conducting threat modelling to identify, assess, and mitigate security threats within XXX. Adoption of a threat modelling standard for threat identification and an information security controls framework, this policy aims to ensure a systematic and consistent approach to managing security risks through the lifecycle of the service offering. + +## Scope +This policy applies to all new or significant changes to digital service and technology projects either built within departments or procured through suppliers. This policy does not apply to digital services which are currently in operation or routine maintenance. Over time, it is expected that all digital services will either be retired or come into scope for this policy. As part of DfE secure by design implementation strategy, the mission is to work with all services to ensure threat modelling meets the SbD security requirement. + +## Exceptions +Exceptions to this policy are likely to occur. Exception requests shall be made by email to the policy author(s) identified in the revision history and must contain: + +- the reason for the request +- risk to DfE of not following the written policy +- specific mitigations that will not be implemented +- technical and other difficulties +- date of review + +## Policy statements + +- threat modelling should be considered by the senior leadership in accordance with the risk appetite (SRO) sign off for Threat models, risks owners and acceptance process. +- risk owners are accountable for managing cyber security risks for a service throughout its lifecycle. These must be senior stakeholders with the experience, knowledge and authority to lead on security activities. +- threat and risk management activities should be supported by a suitability qualified SME identified in the RACI. +- threat modelling should be appropriately resourced throughout the service lifecycle, be dynamic and frequent to respond to emerging threats +- when threat modelling, make informed risk management decisions and ensure risks have been mitigated to a level that meets your project’s security risk appetite. +- threat models, validation and all identified risks should be reviewed by the SRO within 21 days of (milestone/checkpoint XX). + +## Responsible Accountable Consulted Informed (RACI) +In the table below, the header row shows the role title and the rows indicate the activity and RACI. + +| Role | CISO | SRO | Project / operations security leads | Development / operations teams | +|------------------------------------------|----------------|-----|-------------------------------------|---------------------------------| +| Activity | | | | | +| Define and enable strategy | R | C | I | I | +| Risk appetite | R | C | I | I | +| Ensure teams conduct threat modelling | A | R | R | I | +| Gather threat appropriate intelligence | A | R | R | I | +| Conduct threat assessment | A | R | R | I | +| Lead threat modelling exercise | A | C | R | R | +| Participate in threat modelling workshop | A | C | R | R | +| Design risk treatment strategy | Not applicable | R | R | R | +| Accept risk as a treatment option | C | A | R | C | +| Document and report threat model | A | R | C | I | +| Threat model validation | A | C | R | R | + +## Threat modelling and key dependencies + +### Threat modelling definition +A structured process used to identify, assess, and address potential security threats and vulnerabilities within a system. It helps organisations understand and manage risks by analysing how an attacker might exploit system weaknesses to achieve malicious objectives. This approach is proactive, aiming to integrate security into the design and development phases of IT systems and processes. +Threat modelling should leverage input from the following areas of the business: + +### Risk appetite +Cyber security risk for project should be managed in line with to your organisation’s risk appetite statement. Begin with creating a risk appetite specific to your service/project, talk to the risk management team to understand the organisation’s overall risk acceptance thresholds. For further information review the SbD Risk Appetite advice. + +### Asset management +Projects should identify and categorise all in scope physical and information assets, for criticality, and ownership. + +### Threat assessment +Current and emerging threats relevant to the organisation, the project assets and service should be understood to inform an accurate and up to date threat picture supporting threat modelling. + +### System architecture +Detailed systems architecture documentation should be available, clearly mapping all components, interfaces, and data flows within the system. Specifications included should be for hardware, software, networks, and cloud services. Provide a top-level view of the system, highlighting key functionalities and interconnections. Illustrate dependencies, critical paths, and trust boundaries to support security analysis. + +## Project service lifecycle + +Threat modelling is dynamic and must: + +- respond promptly to changes in the threat environment, including new vulnerabilities or threat actor TTPs +- address significant changes to the service or infrastructure, such as system upgrades, integrations, or decommissioning +- be conducted on a regular, predefined lifecycle basis (for example, annually or as part of scheduled reviews) + +## Threat modelling framework + +The organisation should use a threat modelling methodology as the primary approach to identify and categorise threats across its systems, processes, and assets. + +- MITRE ATT&CK (Opens in a new tab), MITRE D3FEND (Opens in a new tab) and MITRE CAPEC (Opens in a new tab) – used to explore possible vulnerabilities and issues that might apply to your service +- STRIDE (Opens in a new tab) (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) – a model for exploring different threat categories +- attack Trees (Opens in a new tab) – for representing the paths adversaries may use to attack your service so you can design solutions to prevent them +- a threat modelling framework should apply during the design, development, and review phases of systems and applications to identify potential threat events or attack paths. +- identified threats should be mapped to business processes, technical components, and operational activities. +- outputs from threat analysis must be documented in threat modelling reports, which shall inform subsequent risk treatment plans. +- threat models should be reviewed and, updated annually or when significant changes as defined under the Scope section of this document. +- security controls should be identified that mitigate/reduce the likelihood of one or more of the threat events/attack paths + +## Security controls framework +The risk register produced when performing a security risk assessment outlines the risks and their rating prior to implementing any controls. You could reduce the likelihood or the impact of the risks by selecting appropriate controls from your security controls set. + +As part of any project or service the project team should implement security controls from a recognised cyber security control framework. A secure by design control taxonomy is available at the XXXX website. + +- use security controls to harden operating systems, network devices, and cloud configurations. +- regularly assess compliance with the selected security controls through automated tools and manual validation. +- Project security lead should maintain documentation of security controls status for audit and reporting purposes. +- Risk management activities should address gaps identified during assessments with priority given to high-risk areas. + +## Risk identification and management +Risks identified through threat modelling must be documented, prioritised, and managed in alignment with organisational risk management policies and frameworks. + +## Continuous improvement +Lessons learned from previous threat modelling cycles and risk management outcomes must inform updates to asset management practices, threat assessment methodologies, and system architecture design. + +## Data handling and privacy +The following must be considered when using collecting, analysing and sharing threat modelling data: + +- anonymisation or masking of sensitive data before sharing externally +- secure storage of threat modelling data and limited access based on least privilege and need to know +- use of the government classification scheme to protect sensitive data in line with policy. + +## Related policies +The following polices are associated with this policy and should also be read as they directly interact or support the policy: + +- Vulnerability Management Policy +- Incident Management Policy +- Security Monitoring Policy +- Asset Management Policy (TBC) +- Risk Management Policy (TBC) +- Supplier Management Policy (TBC) From 8c8b9731928b8edf306545787c419c390c63befd Mon Sep 17 00:00:00 2001 From: Hannah Vesey-Byrne Date: Fri, 13 Dec 2024 12:15:58 +0000 Subject: [PATCH 2/4] Update threat modelling policy v0.5 Changed table to match policy template example. --- docs/policies/threat modelling policy v0.5 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/policies/threat modelling policy v0.5 b/docs/policies/threat modelling policy v0.5 index 73023ed..42ffa20 100644 --- a/docs/policies/threat modelling policy v0.5 +++ b/docs/policies/threat modelling policy v0.5 @@ -10,9 +10,11 @@ date: 2024-12-21 This policy establishes guidelines for conducting threat modelling to identify, assess, and mitigate security threats within XXX. Adoption of a threat modelling standard for threat identification and an information security controls framework, this policy aims to ensure a systematic and consistent approach to managing security risks through the lifecycle of the service offering. ## Scope + This policy applies to all new or significant changes to digital service and technology projects either built within departments or procured through suppliers. This policy does not apply to digital services which are currently in operation or routine maintenance. Over time, it is expected that all digital services will either be retired or come into scope for this policy. As part of DfE secure by design implementation strategy, the mission is to work with all services to ensure threat modelling meets the SbD security requirement. ## Exceptions + Exceptions to this policy are likely to occur. Exception requests shall be made by email to the policy author(s) identified in the revision history and must contain: - the reason for the request @@ -31,11 +33,9 @@ Exceptions to this policy are likely to occur. Exception requests shall be made - threat models, validation and all identified risks should be reviewed by the SRO within 21 days of (milestone/checkpoint XX). ## Responsible Accountable Consulted Informed (RACI) -In the table below, the header row shows the role title and the rows indicate the activity and RACI. -| Role | CISO | SRO | Project / operations security leads | Development / operations teams | +| Tasks | CISO | SRO | Project / operations security leads | Development / operations teams | |------------------------------------------|----------------|-----|-------------------------------------|---------------------------------| -| Activity | | | | | | Define and enable strategy | R | C | I | I | | Risk appetite | R | C | I | I | | Ensure teams conduct threat modelling | A | R | R | I | From cd604e09a0e928f936904e39c915e42e09816314 Mon Sep 17 00:00:00 2001 From: Hannah Vesey-Byrne Date: Fri, 13 Dec 2024 14:47:10 +0000 Subject: [PATCH 3/4] Update threat modelling policy v0.5 Hi @pritchyspritch - I've added in the links that were missing. In comparison to previous commits, I've removed 'Policy' at the top and I'm not sure we can have 'Policy statements' as a heading, but presume it will be iterated soon. I've also elaborated on the last sentence under 'threat modelling definition' as I don't think we can have a colon followed by a H3. --- docs/policies/threat modelling policy v0.5 | 34 +++++++++------------- 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/docs/policies/threat modelling policy v0.5 b/docs/policies/threat modelling policy v0.5 index 42ffa20..4195d3c 100644 --- a/docs/policies/threat modelling policy v0.5 +++ b/docs/policies/threat modelling policy v0.5 @@ -4,17 +4,13 @@ authors: - Simon Bishop date: 2024-12-21 -**Policy** - ## Purpose This policy establishes guidelines for conducting threat modelling to identify, assess, and mitigate security threats within XXX. Adoption of a threat modelling standard for threat identification and an information security controls framework, this policy aims to ensure a systematic and consistent approach to managing security risks through the lifecycle of the service offering. ## Scope - -This policy applies to all new or significant changes to digital service and technology projects either built within departments or procured through suppliers. This policy does not apply to digital services which are currently in operation or routine maintenance. Over time, it is expected that all digital services will either be retired or come into scope for this policy. As part of DfE secure by design implementation strategy, the mission is to work with all services to ensure threat modelling meets the SbD security requirement. +This policy applies to all new or significant changes to digital service and technology projects either built within departments or procured through suppliers. This policy does not apply to digital services which are currently in operation or routine maintenance. Over time, it is expected that all digital services will either be retired or come into scope for this policy. As part of DfE secure by design implementation strategy, the mission is to work with all services to ensure threat modelling meets the Secure by Design (SbD) security requirement. ## Exceptions - Exceptions to this policy are likely to occur. Exception requests shall be made by email to the policy author(s) identified in the revision history and must contain: - the reason for the request @@ -25,7 +21,7 @@ Exceptions to this policy are likely to occur. Exception requests shall be made ## Policy statements -- threat modelling should be considered by the senior leadership in accordance with the risk appetite (SRO) sign off for Threat models, risks owners and acceptance process. +- threat modelling should be considered by the senior leadership in accordance with the risk appetite (SRO) sign off for threat models, risks owners and acceptance process. - risk owners are accountable for managing cyber security risks for a service throughout its lifecycle. These must be senior stakeholders with the experience, knowledge and authority to lead on security activities. - threat and risk management activities should be supported by a suitability qualified SME identified in the RACI. - threat modelling should be appropriately resourced throughout the service lifecycle, be dynamic and frequent to respond to emerging threats @@ -52,10 +48,10 @@ Exceptions to this policy are likely to occur. Exception requests shall be made ### Threat modelling definition A structured process used to identify, assess, and address potential security threats and vulnerabilities within a system. It helps organisations understand and manage risks by analysing how an attacker might exploit system weaknesses to achieve malicious objectives. This approach is proactive, aiming to integrate security into the design and development phases of IT systems and processes. -Threat modelling should leverage input from the following areas of the business: +Threat modelling should leverage input from the following areas of the business described in the sections below. ### Risk appetite -Cyber security risk for project should be managed in line with to your organisation’s risk appetite statement. Begin with creating a risk appetite specific to your service/project, talk to the risk management team to understand the organisation’s overall risk acceptance thresholds. For further information review the SbD Risk Appetite advice. +Cyber security risk for project should be managed in line with to your organisation’s risk appetite statement. Begin with creating a risk appetite specific to your service/project, talk to the risk management team to understand the organisation’s overall risk acceptance thresholds. For further information review the [SbD Risk Appetite advice](https://www.security.gov.uk/policy-and-guidance/secure-by-design/activities/working-out-the-projects-security-risk-appetite/). ### Asset management Projects should identify and categorise all in scope physical and information assets, for criticality, and ownership. @@ -67,7 +63,6 @@ Current and emerging threats relevant to the organisation, the project assets an Detailed systems architecture documentation should be available, clearly mapping all components, interfaces, and data flows within the system. Specifications included should be for hardware, software, networks, and cloud services. Provide a top-level view of the system, highlighting key functionalities and interconnections. Illustrate dependencies, critical paths, and trust boundaries to support security analysis. ## Project service lifecycle - Threat modelling is dynamic and must: - respond promptly to changes in the threat environment, including new vulnerabilities or threat actor TTPs @@ -75,16 +70,15 @@ Threat modelling is dynamic and must: - be conducted on a regular, predefined lifecycle basis (for example, annually or as part of scheduled reviews) ## Threat modelling framework - The organisation should use a threat modelling methodology as the primary approach to identify and categorise threats across its systems, processes, and assets. -- MITRE ATT&CK (Opens in a new tab), MITRE D3FEND (Opens in a new tab) and MITRE CAPEC (Opens in a new tab) – used to explore possible vulnerabilities and issues that might apply to your service -- STRIDE (Opens in a new tab) (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) – a model for exploring different threat categories -- attack Trees (Opens in a new tab) – for representing the paths adversaries may use to attack your service so you can design solutions to prevent them +- [MITRE ATT&CK](https://attack.mitre.org/), [MITRE D3FEND](https://d3fend.mitre.org/) and [MITRE CAPEC](https://capec.mitre.org/) – used to explore possible vulnerabilities and issues that might apply to your service +- [STRIDE](https://www.gov.uk/government/publications/secure-connected-places-playbook-documents/conducting-a-stride-based-threat-analysis)(Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) – a model for exploring different threat categories +- [attack trees](https://www.ncsc.gov.uk/collection/risk-management/using-attack-trees-to-understand-cyber-security-risk) – for representing the paths adversaries may use to attack your service so you can design solutions to prevent them - a threat modelling framework should apply during the design, development, and review phases of systems and applications to identify potential threat events or attack paths. - identified threats should be mapped to business processes, technical components, and operational activities. -- outputs from threat analysis must be documented in threat modelling reports, which shall inform subsequent risk treatment plans. -- threat models should be reviewed and, updated annually or when significant changes as defined under the Scope section of this document. +- outputs from threat analysis must be documented in threat modelling reports, which shall inform subsequent risk treatment plans +- threat models should be reviewed and, updated annually or when significant changes as defined under the Scope section of this document - security controls should be identified that mitigate/reduce the likelihood of one or more of the threat events/attack paths ## Security controls framework @@ -92,10 +86,10 @@ The risk register produced when performing a security risk assessment outlines t As part of any project or service the project team should implement security controls from a recognised cyber security control framework. A secure by design control taxonomy is available at the XXXX website. -- use security controls to harden operating systems, network devices, and cloud configurations. -- regularly assess compliance with the selected security controls through automated tools and manual validation. -- Project security lead should maintain documentation of security controls status for audit and reporting purposes. -- Risk management activities should address gaps identified during assessments with priority given to high-risk areas. +- use security controls to harden operating systems, network devices, and cloud configurations +- regularly assess compliance with the selected security controls through automated tools and manual validation +- Project security lead should maintain documentation of security controls status for audit and reporting purposes +- Risk management activities should address gaps identified during assessments with priority given to high-risk areas ## Risk identification and management Risks identified through threat modelling must be documented, prioritised, and managed in alignment with organisational risk management policies and frameworks. @@ -108,7 +102,7 @@ The following must be considered when using collecting, analysing and sharing th - anonymisation or masking of sensitive data before sharing externally - secure storage of threat modelling data and limited access based on least privilege and need to know -- use of the government classification scheme to protect sensitive data in line with policy. +- use of the government classification scheme to protect sensitive data in line with policy ## Related policies The following polices are associated with this policy and should also be read as they directly interact or support the policy: From 841d2c291803fd857efc407c3fe537d0c8cf2bcd Mon Sep 17 00:00:00 2001 From: pritchyspritch <47423802+pritchyspritch@users.noreply.github.com> Date: Fri, 13 Dec 2024 15:32:33 +0000 Subject: [PATCH 4/4] Fixes to tm policy and anchor fixes to vm after previous changes --- ...policy v0.5 => threat_modelling_policy.md} | 44 ++++++++++++++++--- .../vulnerability_management_policy.md | 12 ++--- 2 files changed, 45 insertions(+), 11 deletions(-) rename docs/policies/{threat modelling policy v0.5 => threat_modelling_policy.md} (87%) diff --git a/docs/policies/threat modelling policy v0.5 b/docs/policies/threat_modelling_policy.md similarity index 87% rename from docs/policies/threat modelling policy v0.5 rename to docs/policies/threat_modelling_policy.md index 4195d3c..c682335 100644 --- a/docs/policies/threat modelling policy v0.5 +++ b/docs/policies/threat_modelling_policy.md @@ -1,8 +1,12 @@ -title: "Threat Modelling Policy-V0.5" +--- +title: "Secure by Design threat modelling policy" summary: A markdown template for SBD policies authors: - Simon Bishop -date: 2024-12-21 +date: 2024-12-13 +--- + +# Threat modelling policy (Secure by Design) ## Purpose This policy establishes guidelines for conducting threat modelling to identify, assess, and mitigate security threats within XXX. Adoption of a threat modelling standard for threat identification and an information security controls framework, this policy aims to ensure a systematic and consistent approach to managing security risks through the lifecycle of the service offering. @@ -51,7 +55,7 @@ A structured process used to identify, assess, and address potential security th Threat modelling should leverage input from the following areas of the business described in the sections below. ### Risk appetite -Cyber security risk for project should be managed in line with to your organisation’s risk appetite statement. Begin with creating a risk appetite specific to your service/project, talk to the risk management team to understand the organisation’s overall risk acceptance thresholds. For further information review the [SbD Risk Appetite advice](https://www.security.gov.uk/policy-and-guidance/secure-by-design/activities/working-out-the-projects-security-risk-appetite/). +Cyber security risk for project should be managed in line with to your organisation’s risk appetite statement. Begin with creating a risk appetite specific to your service/project, talk to the risk management team to understand the organisation’s overall risk acceptance thresholds. For further information review the [SbD risk appetite advice](https://www.security.gov.uk/policy-and-guidance/secure-by-design/activities/working-out-the-projects-security-risk-appetite/). ### Asset management Projects should identify and categorise all in scope physical and information assets, for criticality, and ownership. @@ -73,7 +77,7 @@ Threat modelling is dynamic and must: The organisation should use a threat modelling methodology as the primary approach to identify and categorise threats across its systems, processes, and assets. - [MITRE ATT&CK](https://attack.mitre.org/), [MITRE D3FEND](https://d3fend.mitre.org/) and [MITRE CAPEC](https://capec.mitre.org/) – used to explore possible vulnerabilities and issues that might apply to your service -- [STRIDE](https://www.gov.uk/government/publications/secure-connected-places-playbook-documents/conducting-a-stride-based-threat-analysis)(Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) – a model for exploring different threat categories +- [STRIDE](https://www.gov.uk/government/publications/secure-connected-places-playbook-documents/conducting-a-stride-based-threat-analysis) (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) – a model for exploring different threat categories - [attack trees](https://www.ncsc.gov.uk/collection/risk-management/using-attack-trees-to-understand-cyber-security-risk) – for representing the paths adversaries may use to attack your service so you can design solutions to prevent them - a threat modelling framework should apply during the design, development, and review phases of systems and applications to identify potential threat events or attack paths. - identified threats should be mapped to business processes, technical components, and operational activities. @@ -107,9 +111,39 @@ The following must be considered when using collecting, analysing and sharing th ## Related policies The following polices are associated with this policy and should also be read as they directly interact or support the policy: -- Vulnerability Management Policy +- [Vulnerability Management Policy](vulnerability_management_policy.md) - Incident Management Policy - Security Monitoring Policy - Asset Management Policy (TBC) - Risk Management Policy (TBC) - Supplier Management Policy (TBC) + +## Revision history + +### Revision table + +| Date of change | Author | Review Date | Version | +| -------------- | ------------------ | -------------------- | ------- | +| YYYY-MM-DD | FULL_NAME | YYYY-MM-DD (+1 year) | v0.1 | + + +### Approved by + +| Name | Title | Date | Version | +| --------------- | --------- | ---------- | ------- | +| FULL_NAME | TITLE | YYYY-MM-DD | v0.1 | + +### Policy updates and decision record + +| Decision | Reason for decision | Author (Job title) | Date | +| -------- | ------------------- | ------------------ | ---------- | +| | | | 2024-03-07 | + +# Appendix A: Glossary + +| Term | Meaning in this context | +| ----------------------- | ----------------------- | +| | | + + +# Appendix B: Centre for Internet Security (CIS) safeguards mapping \ No newline at end of file diff --git a/docs/policies/vulnerability_management_policy.md b/docs/policies/vulnerability_management_policy.md index c9cf959..88a857b 100644 --- a/docs/policies/vulnerability_management_policy.md +++ b/docs/policies/vulnerability_management_policy.md @@ -88,7 +88,7 @@ Your vulnerability management process for virtual machines: * must be documented and approved by an ISO and the vulnerability management lead * must include daily monitoring of operating system and application patches available * should be automated wherever possible -* must ensure that patches are installed within [the appropriate SLAs](#51-service-level-agreements-slas) +* must ensure that patches are installed within [the appropriate SLAs](#service-level-agreements-slas) * should include reviewing the Continuous Assurance Platform for a single pane of glass view of their benchmark compliance and vulnerability management status across Azure and GitHub @@ -105,7 +105,7 @@ Your vulnerability management process for container images: * must include daily monitoring of container images * should be integrated into CI/CD pipelines to ensure vulnerable containers are not pushed to production * should be automated wherever possible -* must ensure that patches are installed within [the appropriate SLAs](#51-service-level-agreements-slas) +* must ensure that patches are installed within [the appropriate SLAs](#service-level-agreements-slas) * should include reviewing the Continuous Assurance Platform for a single pane of glass review #### Upstream base image vulnerabilities @@ -129,7 +129,7 @@ Your vulnerability management process for software dependencies/libraries: * must include daily monitoring of dependencies * must be integrated into CI/CD pipelines and repository monitoring to ensure vulnerable libraries are not pushed to production * should be automated wherever possible (such as with the use of [Dependabot](https://technical-guidance.education.gov.uk/standards/storing-source-code/#dependabot-configuration-options)) or other Software Composition Analysis (SCA) tool -* must ensure that patches are installed within [the appropriate SLAs](#51-service-level-agreements-slas) +* must ensure that patches are installed within [the appropriate SLAs](#service-level-agreements-slas) * should include reviewing the Continuous Assurance Platform for a single pane of glass review @@ -197,7 +197,7 @@ A new risk must be added to the development team risk register should the issue ### Prioritise -Vulnerabilities must be prioritised based on [the SLAs for their risk level](#51-service-level-agreements-slas). The development teams should incorporate vulnerability remediation activities in their regular sprint planning. +Vulnerabilities must be prioritised based on [the SLAs for their risk level](#service-level-agreements-slas). The development teams should incorporate vulnerability remediation activities in their regular sprint planning. Vulnerabilities that can be fixed via automated means (such as automated pull requests) should be fixed as daily tasks. @@ -208,10 +208,10 @@ The development teams are responsible for remediating vulnerabilities in their a Remediation processes: * should be automated wherever possible -* must include risk assessments [where necessary](#59-assess) +* must include risk assessments [where necessary](#assess) * must include testing that remediation was successful * should have clearly communicated outcomes with stakeholders -* must be undertaken within [DfE mandated SLAs](#51-service-level-agreements-slas) +* must be undertaken within [DfE mandated SLAs](#service-level-agreements-slas) ### Monitor