Merge pull request #14 from DFE-Digital/vuln-management-policy

Vuln management policy

docs/policies/vulnerability_management_policy.md

@@ -0,0 +1,247 @@
+---
+title: "Vulnerability management policy"
+summary: The secure by design policy for managing vulnerabilities, include responsibilities, exceptions, how vulnerabilities should be discovered, SLAs and how they are assessed and remediated.
+authors:
+    - Sam Pritchard
+date: 2024-11-20
+---
+
+# Vulnerability management policy
+
+## Terminology
+
+| Term       | Meaning / Application                                               |
+| ---------- | ------------------------------------------------------------------- |
+| Must       | This term is used to state a mandatory requirement of this policy   |
+| Should     | This term is used to state a recommended requirement of this policy |
+| May        | This term is used to state an optional requirement of this policy   |
+
+
+## Purpose
+The purpose of this policy is to identify, prioritise and mitigate vulnerabilities within DfE (Department for Education) digital services, infrastructure and software to preserve the confidentiality, integrity, and availability of DfE data.
+
+## Responsibility
+The digital service teams and portfolios are responsible for ensuring they mitigate vulnerabilities within their software and infrastructure.
+
+### Responsibile Accountable Consulted Informed (RACI) matrix
+
+| Tasks                               | Developers/DevOps | Service Owners | Vulnerability Management team |
+| ----------------------------------- | ----------------- | -------------- | ------- |
+| Patching Azure servers              | R                 | A              | C       |
+| Patching software dependencies      | R                 | A              | C       |
+| Patching container images           | R                 | A              | C       |
+| Fixing SAST vulnerabilities         | R                 | A              | C       |
+| Fixing DAST vulnerabilities         | R                 | A              | C       |
+| Fixing VDP reported vulnerabilities | R                 | A              | I       |
+
+## Other responsible owners
+
+## Exceptions
+Exceptions to this policy are likely to occur. Request for exceptions may include additional time to remediate vulnerabilities, or to let certain systems function normally with vulnerabilities in place. 
+
+Exception requests must be made in writing to the Vulnerability Management team mailbox (vulnerability.management@education.gov.uk) and must contain: 
+
+* the reason for the request
+* risk to the department of not following the policy
+* specific mitigations that will not be implemented
+* technical and other difficulties in applying patches
+* date of review 
+
+The VM team should also try and obtain confirmation from the Senior Responsible Officer (SRO) and Service Owner that the vulnerability has been approved and has been added to the Services Risk Register (where maintained). Each service is responsible for maintaining an appropriate risk register for their service.
+
+## Policy
+
+### Service level agreements (SLAs)
+The service level agreement outlines how quickly vulnerabilities should be fixed based on their risk level. These timescales are shown in the table below:
+
+| Type                  | Critical   | High        | Medium  | Low     | 
+| --------------------- | ---------- | ----------- | ------- | ------- |
+| Virtual machines      | 14 days    | 14 days     | 30 days | 60 days |
+| Container images      | 14 days    | 14 days     | 30 days | 60 days |
+| Software dependencies | 14 days    | 14 days     | 30 days | 60 days |
+| SAST vulnerabilities  | 14 days    | 14 days     | 30 days | 60 days |
+| DAST vulnerabilities  | 14 days    | 14 days     | 30 days | 60 days |
+| Pen test results      | 14 days    | 14 days     | 30 days | 60 days |
+| Threat model results  | 14 days    | 14 days     | 30 days | 60 days |
+
+### Virtual machines
+Development teams are responsible for patching virtual machines they deploy into Azure. 
+
+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)
+* 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
+
+
+### Containers
+Development teams are responsible for patching container images that they:
+
+* use for development
+* deploy to AKS or other Azure container services
+* use for deployments in CI/CD pipelines
+
+Your vulnerability management process for container images:
+
+* must be documented and approved by an ISO and the Vulnerability Management Lead
+* 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)
+* should include reviewing the Continuous Assurance Platform for a single pane of glass review 
+
+#### Upstream base image vulnerabilities
+It is a known issue that some common base images have vulnerabilities that can only be fixed by the upstream maintainers. 
+
+??? warning "It is not considered an appropriate exception to not patch vulnerabilities in container images because of upstream problems."
+    Please work with CISD and your architects to ensure secure base images are used, either by finding appropriate secure base images, by building your own images or other means such as muiti-stage docker builds
+
+To ensure that vulnerabilities in container images are patched within appropriate timescales teams must either:
+
+* produce a new base image themselves with up to date patching
+* fix the missing patches using [multi-stage docker builds](https://technology.blog.gov.uk/2020/06/29/using-multi-stage-docker-builds-to-patch-vulnerable-containers/)
+
+
+### Software dependencies 
+Development teams are responsible for patching software dependencies/libraries.
+
+Your vulnerability management process for software dependencies/libraries:
+
+* must be documented and approved by an ISO and the vulnerability management lead
+* 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)
+* should include reviewing the Continuous Assurance Platform for a single pane of glass review 
+
+
+### Static analysis software testing (SAST)
+Development teams are responsible for assessing and fixing [*confirmed* vulnerabilities](#appendix-a-glossary) raised by SAST scans.
+
+Your vulnerability fixing process for SAST scans:
+
+* must be documented and approved by an ISO and the vulnerability management lead
+* must include daily monitoring of SAST scan results
+* must be integrated into CI/CD pipelines and repository monitoring to ensure SAST vulnerabilities found in code are not pushed to production
+* should use [a SAST product that can post results to GitHub Advanced Security and the Continuous Assurance Platform](https://secure-by-design.security.education.gov.uk/SbD%20Activities/discovering_vulnerabilities/#sast-static-analysis-software-testing)
+* 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 
+
+
+### Dynamic analysis software testing (DAST)
+Development teams are responsible for assessing and fixing [*confirmed* vulnerabilities](#appendix-a-glossary) raised by DAST scans.
+
+Your vulnerability management process for DAST scans:
+
+* must be documented and approved by an ISO and the vulnerability management lead
+* must include daily monitoring of DAST scan results
+* must be integrated into CI/CD pipelines and repository monitoring to ensure DAST vulnerabilities found in code are not pushed to production 
+* should run scans in CI/CD pipelines against Dev/Test environments before production deployments
+* should include running authenticated scans to ensure the full application is tested
+* 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 
+
+
+### Pen testing
+Development teams are responsible for assessing and fixing [*confirmed* vulnerabilities](#appendix-a-glossary) raised by penetration tests.
+
+A vulnerability management process for penetration tests must be documented and approved by an ISO and the vulnerability management lead. Penetration tests must be conducted at least once per year or whenever there are significant changes to the application and/or infrastructure.
+
+Output from the penetration tests must include a remediation plan that highlights all of the potential vulnerabilities that have been discovered.
+
+The digital service teams must review the output and triage any issues following DfE approved vulnerability management triage processes.
+
+
+### Threat modelling
+Development teams are responsible for producing threat models and mitigating the threats raised by them.
+
+A vulnerability management process for threat modelling must be documented and approved by an ISO and the vulnerability management lead. Threat modelling must be conducted as part of the planning phase of all new feature developments.
+
+Output from the threat models must include a remediation plan that highlights all of the potential threats that have been discovered.
+
+The digital service teams must review the threats and triage any issues following DfE approved vulnerability management triage processes.
+
+
+### Assess
+Development teams and Service Owners are responsible for assessing the vulnerabilities, threats and risks associated with a service. 
+
+The vulnerability management team are reponsible for escalating vulnerabilities to development teams and their SRO and/or service owner. This could include vulnerabilities that have passed SLA and require immediate attention or vulnerabilities that have been discovered and reported to DfE via the VDP.
+
+The development team must follow a standardised vulnerability triage process. 
+
+A risk assessment should be conducted if it's:
+
+* unclear on how to remediate the vulnerability
+* unclear how long it will take to fix the vulnerability
+* unclear if it will be possible to fix at this time
+
+A new risk must be added to the development team risk register should the issue be assessed. Risks raised on the risk register must be reported to the vulnerability management team and the ISO assigned to the team.
+
+
+### 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 that can be fixed via automated means (such as automated pull requests) should be fixed as daily tasks.
+
+
+### Remediate
+The development teams are responsible for remediating vulnerabilities in their applications and infrastructure. 
+
+Remediation processes:
+
+* should be automated wherever possible
+* must include risk assessments [where necessary](#59-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)
+
+
+### Monitor
+The development teams are responsible for monitoring vulnerabilities, threats, and risks that impact their application.
+
+Development teams:
+
+* should monitor their automated tests for security issues to make sure they fix vulnerabilities in a timely manner
+* should use the DfE continuous assurance platform (CAP) to monitor for issues raised by SCA, SAST, Azure Defender Alerts, GitHub Secret Scans
+* must produce a vulnerability register should they choose not to use CAP
+
+The vulnerability management team:
+
+* should subscribe to a threat information service to receive notifications of recently released patches and other software updates
+* must notify the Digital Data Technology (DDT) Senior Management team if vulnerabilities are not mitigated in a timely manner
+* must create a monthly report containing the status of all known vulnerabilities within the department
+* must triage vulnerabilities from the vulnerability disclosure programme to development teams that ensures the teams can fix vulnerabilities within SLAs
+
+
+## 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 |
+| -------- | ------------------- | ------ | ---- |
+| Critial and high risk issue SLAs are 14 days | This aligns with the Cyber Essentials guidelines approved by NCSC | Andy Hoy (Vulnerability Management Lead) | 2024-03-07 |
+
+# Appendix A: Glossary
+
+| Term                    | Meaning in this context |
+| ----------------------- | ----------------------- |
+| Confirmed vulnerability | The vulnerability has been triaged following DfE approved triage processes, has been confirmed as a real vulnerability and therefore is not a false positive issue. |
+
+# Appendix B: Centre for Internet Security (CIS) safeguards mapping
+
+
+

includes/glossary.md

@@ -21,4 +21,8 @@
 *[GHAST]: GitHub Advanced Security Tab
 *[CAP]: Continuous Assurance Platform
 *[SLA]: Service Level Agreement
-*[ISO]: Information Security Officer
+*[SLAs]: Service Level Agreements
+*[ISO]: Information Security Officer
+*[SRO]: Senior Responsible Officer
+*[RACI]: Responsible Accountable Consulted Informed (matrix)
+*[CIS]: Centre for Internet Security