From 400bd1c010f242071252f435c2a54847df00801e Mon Sep 17 00:00:00 2001 From: Venus B Date: Fri, 3 Jan 2025 11:02:53 +0000 Subject: [PATCH 1/2] Add software dependencies --- .../architecture-decisions.html.md.erb | 2 +- .../software/breaking-down-work.html.md.erb | 46 ------ .../standards/software/docker.html.md.erb | 147 ++++++++++++++++++ .../tracking-dependencies.html.md.erb | 28 ++-- source/partials/_nav-architecture.html.erb | 1 + source/partials/_nav-standards.html.erb | 2 +- 6 files changed, 163 insertions(+), 63 deletions(-) rename source/docs/{standards/software => architecture}/architecture-decisions.html.md.erb (99%) delete mode 100644 source/docs/standards/software/breaking-down-work.html.md.erb create mode 100644 source/docs/standards/software/docker.html.md.erb diff --git a/source/docs/standards/software/architecture-decisions.html.md.erb b/source/docs/architecture/architecture-decisions.html.md.erb similarity index 99% rename from source/docs/standards/software/architecture-decisions.html.md.erb rename to source/docs/architecture/architecture-decisions.html.md.erb index f795c14..fad7687 100644 --- a/source/docs/standards/software/architecture-decisions.html.md.erb +++ b/source/docs/architecture/architecture-decisions.html.md.erb @@ -1,5 +1,5 @@ --- -title: Documenting architecture decisions +title: Architecture decisions last_reviewed_on: 2024-05-10 review_in: 12 months --- diff --git a/source/docs/standards/software/breaking-down-work.html.md.erb b/source/docs/standards/software/breaking-down-work.html.md.erb deleted file mode 100644 index b002f0e..0000000 --- a/source/docs/standards/software/breaking-down-work.html.md.erb +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Breaking down work -last_reviewed_on: 2024-10-10 -review_in: 6 months ---- -# <%= current_page.data.title %> - -Working sustainably in small batches and performing regular releases is considered [industry best practice](https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment#DORA_Four_Key_Metrics). -It reduces the risk of errors being introduced, makes delivery of value more predictable, and enables us to learn faster. - -Our perception of value is not just putting working software and new features into the hands of users. It’s also: - -- Learning about user needs. -- Improving operational resilience. -- Minimising [toil](https://sre.google/sre-book/eliminating-toil/). -- Reducing cost of change. - -We should aim to break down our work into independently releaseable pieces that each deliver their own value. - -## Why break down work? - -There are many reasons why working in smaller batches provides an advantage in software development. - -- It articulates value. If we are able to clearly state where the value is in a piece of work then we are more able to break it down into valuable milestones. -- It reduces waste. Code that is written but not integrated and being used is wasted effort, and we want to minimise that waste. -- It promotes predictable delivery. We often need to know when a feature is likely to be complete and having clear regular milestones facilitates those conversations with evidence rather than estimates. -- It enables fast feedback. We can learn a lot from regularly releasing our code to production environments even if the effects are not visible to users. We also get feedback on our code design because well-written code will be easier to iterate on. -- It boosts team morale. The unit of delivery is the team, and delivering value regularly is much better for morale than working on big-bang releases for months at a time. - -## How do we break down work? - -- [Example mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/). Splitting up a large feature into individual capabilities will demonstrate where the dependencies are, which are the most valuable, and the subsequent ideal ordering. -- Get work live as soon as you can. Deploy changes safely behind feature toggles or limited to lower (non-production) environments to get fast feedback on the thing you've changed. For example, you might integrate your code with a third-party service but discard the result rather than take action; Martin Fowler calls this [dark launching](https://martinfowler.com/bliki/DarkLaunching.html). -- Finish one thing at a time. Having too much work in progress (WIP) reduces the team's ability to react to change and feedback, and it's much better to avoid context switching. If your team has lots of work in flight because there are lots of blockers, then work with your delivery colleagues to establish why this is happening. -- Loosely coupled components and systems. Systems that need to be changed together will block each other, so try to build systems that have well-defined contracts but also operate under the robustness principle (be conservative in what you send, liberal in what you accept). For example, do not rely on ordering for JSON objects and ignore unexpected fields rather than cause an error. -- Failing early and safely. Working in small batches reduces risk of bugs, but when those bugs do happen it's much easier to roll back a small change than a large one. Your team should be aspiring to some form of automated rollback in case of errors in production environments, such as blue-green deployments or canary releases. - -## Further reading - -Find out more about breaking down work: - -- [Why breaking down work is important][breaking down work] - an expanded version of this page -- [Software has diseconomies of scale – not economies of scale][scale] - -[breaking down work]: https://blog.probablyfine.co.uk/2024/09/27/why-breaking-down-work-is-important.html -[scale]: https://www.allankelly.net/archives/472/software-has-diseconomies-of-scale-not/ diff --git a/source/docs/standards/software/docker.html.md.erb b/source/docs/standards/software/docker.html.md.erb new file mode 100644 index 0000000..7ba806c --- /dev/null +++ b/source/docs/standards/software/docker.html.md.erb @@ -0,0 +1,147 @@ +--- +title: Dockerfile guidance +last_reviewed_on: 2024-01-05 +review_in: 6 months +--- + +# <%= current_page.data.title %> + +This style guide: + +* provides some conventions for creating production-ready Dockerfiles +* supplements the official [Dockerfile reference](https://docs.docker.com/engine/reference/builder/) + +## Using tags and digests in FROM instructions + +The `FROM` instruction specifies the starting image for your Docker image build. + +A tag is a short label you can use to reference an image. + +For example: + +``` +FROM alpine:3.9 +``` + +where: + +* `alpine` is the image name +* `3.9` is the tag + +As you cannot rely on the tag pointing to the exact same image over time, you +should instead use a digest, which identifies the image by a hash of its +contents. This makes sure that you are always referencing the image that you +expect. + +For example: + +``` +FROM alpine@sha256:769fddc7cc2f0a1c35abb2f91432e8beecf83916c421420e6a6da9f8975464b6 +``` + +Where `sha256@769fddc7cc2f0a1c35abb2f91432e8beecf83916c421420e6a6da9f8975464b6` +is the unique digest representing the particular variant of the image. + +To get the digest, run `docker pull `. For example: + +``` +$ docker pull alpine:3.9 +3.9: Pulling from library/alpine +Digest: sha256:769fddc7cc2f0a1c35abb2f91432e8beecf83916c421420e6a6da9f8975464b6 +Status: Image is up-to-date for alpine:3.9 +``` + +As [Dependabot](https://dependabot.com) has [support for updating `FROM` lines +which use digests](https://github.com/dependabot/dependabot-core/pull/100), +you can still use Dependabot to keep your images up-to-date. + +## Using multi-stage builds + +Using [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/) enables the drastic +reduction of image sizes, which in turn decreases the time taken to launch the container. There can be many stages +within a Dockerfile. The result is a single layer image which discards the previous unrequired layers that were +used in the compilation steps. + +As an example; + +``` +FROM golang:1.16 AS builder +WORKDIR /go/src/github.com/alphagov/paas-aiven-broker/ +RUN git clone https://github.com/alphagov/paas-aiven-broker.git . +RUN go mod download +RUN go build + +FROM alpine:latest +RUN apk --no-cache add ca-certificates +WORKDIR /root/ +COPY --from=builder /go/src/github.com/alphagov/paas-aiven-broker/paas-aiven-broker . +COPY --from=builder /go/src/github.com/alphagov/paas-aiven-broker/paas-aiven-broker/examples/config.json . +CMD ["./paas-aiven-broker", "-config", "config.json"] +``` + +Building from this Dockerfile requires no changes to the existing build process e.g. `docker build -t myimage:latest .` + +It is also possible to stop the build at a specific stage using a command such as +`docker build --target builder -t myimage:development .` which then enables running the container locally to debug the image. + +## Running programs as process ID (PID) 1 + +The program running as PID 1 inside a container is responsible for: + +* cleaning up orphaned child processes +* handling signals +* returning the exit status from the container + +Most programs are unsuited to running as PID 1 inside a container. For +example: + +* `bash` will not pass signals through to its children; for example, `SIGTERM` will + not lead to the container being shut down +* `java` exits with an exit status of 143 when sent a SIGTERM, even if the application shuts + down cleanly +* `node` does not reap orphaned child processes whose parent has exited + +[Tini](https://github.com/krallin/tini) provides a program suitable for +running as PID 1 inside the container. You can use Tini to avoid the problems +highlighted above. Tini is included by default with the Docker runtime or +Alpine Linux images. + +You can use `tini` by passing the `--init` option to Docker when running your +container or set Tini as the `ENTRYPOINT` for your container. For example: + +``` +ENTRYPOINT ["tini", "--"] +``` + +or for Java programs, to map an exit status of 143 to 0: + +``` +ENTRYPOINT ["tini", "-e", "143", "--"] +``` + +## Subshells + +The instructions `RUN`, `CMD` and `ENTRYPOINT` have 2 forms: + +* freeform text (for example `CMD “run -x”`) +* an array-style (for example `CMD [“run”, “-x”]`) + +You should use the array-style syntax where possible. + +A Linux syscall will directly execute all commands specified using the +array-style syntax, without an enclosing subshell. This process is more +efficient and removes any ambiguity over how the commands will be interpreted. + +In the case of `ENTRYPOINT` or `CMD`, using the freeform text syntax means that +a shell becomes PID 1 and most programs should not run as PID 1, as explained +above. + +For more information about the special role of PID 1: + +* [avoid running NodeJS as PID 1 under Docker images](https://www.elastic.io/nodejs-as-pid-1-under-docker-images/) +* [docker-node best practices - Handling Kernel Signals](https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#handling-kernel-signals) +* [Docker and the PID 1 zombie reaping problem](https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/) + +## Links + + * A smarter [Dockerfile linter](https://github.com/hadolint/hadolint) that helps you build best practice Docker images diff --git a/source/docs/standards/software/tracking-dependencies.html.md.erb b/source/docs/standards/software/tracking-dependencies.html.md.erb index c91f617..586944b 100644 --- a/source/docs/standards/software/tracking-dependencies.html.md.erb +++ b/source/docs/standards/software/tracking-dependencies.html.md.erb @@ -1,26 +1,24 @@ --- title: How to manage third party software dependencies -last_reviewed_on: 2024-06-27 -review_in: 6 months +last_reviewed_on: 2025-01-03 +review_in: 12 months --- # <%= current_page.data.title %> When you develop and operate a service, it’s important to keep any third party dependencies you use up-to-date. By doing this, you can avoid potential security vulnerabilities. -Any automated tools you use to manage third party dependencies should be compatible with [GDS supported programming languages][]. The tools you use should neither slow down your development process nor disclose potential security vulnerabilities to the public. +Any automated tools you use to manage third party dependencies should be compatible with [standard programming languages][]. The chosen tools should not disclose potential security vulnerabilities to the public. You can read more about [managing software dependencies in the Service Manual][], where you will find a list of common dependency management tools. -Our [programming language style guides][] also contain language-specific advice about managing dependencies (for example, [managing Python dependencies][]). - ## Update dependencies frequently Update your dependencies frequently rather than in ‘big bang’ batches. This works well with [continuous delivery][] principles and makes sure the changes introduced are small and can be automatically tested. -There are tools which scan GitHub repositories and raise pull requests (PRs) when they find dependency updates. Teams at GDS are using: +There are tools which scan GitHub repositories and raise pull requests (PRs) when they find dependency updates. Teams at the Cabinet Office are using: -* [Dependabot][] - used by GOV.UK, and GOV.UK Pay. The GOV.UK docs contain [guidance on using Dependabot][] and [how the PRs raised should be reviewed][] +* [Dependabot][] - The GOV.UK docs contain [guidance on using Dependabot][] and [how the PRs raised should be reviewed][] > Note: this is separate from the [security-only updates provided automatically by GitHub Dependabot]. > Note: repos requiring at least one approving review for PRs cannot, and should not, use [Dependabot's auto-approve-and-merge facility]. @@ -29,11 +27,11 @@ There are tools which scan GitHub repositories and raise pull requests (PRs) whe > Note: GOV.UK has implemented [RFC-167][] which allows automatic patching of all dependencies in certain cases. -* [PyUp][] - a Python dependency checker. Used by GOV.UK Notify, PyUp will monitor for updates and vulnerabilities +* [PyUp][] - a Python dependency checker. PyUp will monitor for updates and vulnerabilities All the above tools are free to use on public repositories. -The COD Cyber Security team will review the repositories that do not have dependency management in use and will turn on Dependabot where required. Service teams are free to use a different tool such as [Snyk](https://snyk.io/), but will need to add a `no-dependabot` tag to their repository for monitoring purposes. You can [contact Cyber Security](https://gds.slack.com/archives/CCMPJKFDK) if you have any questions or need help. +The Cyber Security team at Cabinet Office Digital will review the repositories that do not have dependency management in use and will turn on Dependabot where required. Service teams are free to use a different tool such as [Snyk](https://snyk.io/), but will need to add a `no-dependabot` tag to their repository for monitoring purposes. You can [contact Cyber Security](email:cybersecurity@cabinetoffice.gov.uk) if you have any questions or need help. ## Monitor for vulnerabilities @@ -47,13 +45,13 @@ When GitHub discovers or is informed about a vulnerability, it will email an ale ### [Snyk][] -Snyk is capable of detecting vulnerabilities in a variety of languages including all the [GDS supported programming languages][]. You can configure Snyk to raise PRs, email regular reports and alert you when new vulnerabilities are detected. +Snyk is capable of detecting vulnerabilities in a variety of languages including all the [standard programming languages][]. You can configure Snyk to raise PRs, email regular reports and alert you when new vulnerabilities are detected. If you have an old repository that is receiving security alerts but is not being worked on or maintained, you may wish to archive your repository instead. ### Splunk dashboards -The Cyber Security team has created a Splunk dashboard. This gives service teams visibility of vulnerabilities in their repositories. To allow for your repositories to be categorised correctly in the Splunk dashboard, please make sure you tag your repository with the service name. If you would like to access the dashboard, [contact Cyber Security](https://gds.slack.com/archives/CCMPJKFDK). +The Cyber Security team has created a Splunk dashboard. This gives service teams visibility of vulnerabilities in their repositories. To allow for your repositories to be categorised correctly in the Splunk dashboard, please make sure you tag your repository with the service name. If you would like to access the dashboard, [contact Cyber Security](email: cybersecurity@cabinetoffice.gov.uk). ## Managing Docker dependencies @@ -63,8 +61,8 @@ Like dependencies, Docker base images are also frequently updated. If you run co ### Specifying Docker image tags -The GDS Way Dockerfile guidance contains advice on how -to use [Docker image tags](/manuals/programming-languages/docker.html#using-tags-and-digests-in-from-instructions) +The Dockerfile guidance contains advice on how +to use [Docker image tags](./docs/standards/software/docker.html#using-tags-and-digests-in-from-instructions) to specify the exact container image version to use. ### Use official Docker base images @@ -84,9 +82,9 @@ Also consider managed solutions where possible. For example: [Dependabot's auto-approve-and-merge facility]: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/automating-dependabot-with-github-actions [security-only updates provided automatically by GitHub Dependabot]: https://docs.github.com/en/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies -[GDS supported programming languages]: /standards/programming-languages.html#content +[standard programming languages]: /standards/programming-languages.html#content [managing software dependencies in the Service Manual]: https://www.gov.uk/service-manual/technology/managing-software-dependencies -[programming language style guides]: /manuals/programming-languages.html +[programming language style guides]: /docs/standards/software/programming-languages.html [managing Python dependencies]: /manuals/programming-languages/python/python.html#dependencies [Snyk]: https://snyk.io/ [monitor code dependencies]: https://snyk.io/features diff --git a/source/partials/_nav-architecture.html.erb b/source/partials/_nav-architecture.html.erb index bd385d6..978cf8f 100644 --- a/source/partials/_nav-architecture.html.erb +++ b/source/partials/_nav-architecture.html.erb @@ -1,5 +1,6 @@ diff --git a/source/partials/_nav-standards.html.erb b/source/partials/_nav-standards.html.erb index 9fc573e..2f3bcee 100644 --- a/source/partials/_nav-standards.html.erb +++ b/source/partials/_nav-standards.html.erb @@ -10,6 +10,6 @@
  • Anticipate security issues using threat modelling
    • -->
  • Web Application Firewall
    • -
  • Documenting Architecture Decisions
  • Source Code
    • +
  • Manage Software Dependencies
    • From e979b8835d881bb5401220df2d26e9263a04293f Mon Sep 17 00:00:00 2001 From: Venus B Date: Mon, 6 Jan 2025 15:28:42 +0000 Subject: [PATCH 2/2] software dev and operation standards, principle of least access --- ...oftware-development-operations.html.md.erb | 2 +- .../principle-least-access.html.md.erb | 3 +- .../software/storing-credentials.html.md.erb | 54 ---- .../software/threat-modelling.html.md.erb | 272 ------------------ .../software/understanding-risks.html.md.erb | 37 --- .../software/user-support.html.md.erb | 52 ---- .../vulnerability-disclosure.html.md.erb | 6 +- .../software/working-with-git.html.md.erb | 7 +- source/partials/_nav-standards.html.erb | 5 +- 9 files changed, 12 insertions(+), 426 deletions(-) delete mode 100644 source/docs/standards/software/storing-credentials.html.md.erb delete mode 100644 source/docs/standards/software/threat-modelling.html.md.erb delete mode 100644 source/docs/standards/software/understanding-risks.html.md.erb delete mode 100644 source/docs/standards/software/user-support.html.md.erb diff --git a/source/docs/guidance/software-development-operations.html.md.erb b/source/docs/guidance/software-development-operations.html.md.erb index cbb58cc..93d1e25 100644 --- a/source/docs/guidance/software-development-operations.html.md.erb +++ b/source/docs/guidance/software-development-operations.html.md.erb @@ -66,7 +66,7 @@ You should have security measures and monitoring for the application and infrast * Automate [access control tracking](./software/secrets-acl.html#content) and corresponding alerting * set up access and security related configuration change monitoring when appropriate * apply [principle of least privilege](./software/principle-least-access.html) -* perform [threat modelling to anticipate security issues](./software/threat-modelling.html) +* perform [threat modelling to anticipate security issues](https://intranet.cabinetoffice.gov.uk/it-data-and-security/cyber-and-information-security-services/threat-modelling/) * take extra precautions in [storing credentials](./software/storing-credentials.html) * [manage third party software dependencies](./software/tracking-dependencies.html) diff --git a/source/docs/standards/software/principle-least-access.html.md.erb b/source/docs/standards/software/principle-least-access.html.md.erb index bd82c88..10e594e 100644 --- a/source/docs/standards/software/principle-least-access.html.md.erb +++ b/source/docs/standards/software/principle-least-access.html.md.erb @@ -44,7 +44,7 @@ It's important to recognise opportunities for privilege creep / accumulation and For human-readable secrets, such as a username and password, you should set up a separate secret or [password manager](https://www.ncsc.gov.uk/collection/passwords/password-manager-buyers-guide). -If you’re using the gds-users account to log into your AWS accounts, you should assume a read-only role by default. You should only assume an admin role when absolutely necessary for a specific task. You should set up the admin account so that the session timeout is less than 12 hours. You should send the audit trail of admin access to the Cyber Security team. Use the Cyber Security Slack channel ([#cyber-security-help](https://gds.slack.com/archives/CCMPJKFDK)) to set up the audit trail. +If you’re using the gds-users account to log into your AWS accounts, you should assume a read-only role by default. You should only assume an admin role when absolutely necessary for a specific task. You should set up the admin account so that the session timeout is less than 12 hours. You should send the audit trail of admin access to the Cyber Security team. Use the Cyber Security Slack channel ([#cyber-security][] to set up the audit trail. ## Further Guidance @@ -54,3 +54,4 @@ If you’re using the gds-users account to log into your AWS accounts, you shoul - [NIST Special Publication 800-53 - AC-6 least privilege][polp] [polp]: https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search +[#cyber-security]: https://intranet.cabinetoffice.gov.uk/it-data-and-security/cyber-and-information-security-services/ diff --git a/source/docs/standards/software/storing-credentials.html.md.erb b/source/docs/standards/software/storing-credentials.html.md.erb deleted file mode 100644 index 25a3183..0000000 --- a/source/docs/standards/software/storing-credentials.html.md.erb +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: How to store credentials -last_reviewed_on: 2023-11-02 -review_in: 6 months ---- - -# <%= current_page.data.title %> - -Depending on how you [manage your accounts](/standards/accounts-with-third-parties.html), you, your team and the service you run may have credentials or other secrets that you need to store securely. - -## Personal credentials - -Personal credentials belong only to you. They uniquely identify you and grant access to your GitHub, AWS, and GOV.UK Signon accounts. - -[If possible, use the password manager built into your browser](https://lock.cmpxchg8b.com/passmgrs.html#conclusion). This is simpler than setting up an extra account with a third party and avoids the potential issues below. - -If you are unable to use your browser's password manager then you should use a third-party password manager. This could be necessary if your browser has an accessibility issue, or if you work with multiple browsers. - -Third-party password managers used by people at GDS include: - -- [**1Password**](https://1password.com/) -- [**BitWarden**](https://bitwarden.com/) - An open source password manager. -- [**KeePassXC**](https://keepassxc.org/) - An offline password store, which you may want to backup somewhere. -- [**QtPass**](https://qtpass.org/) - Another offline store, integrated with Git and GPG / pass. - -There is a security trade-off involved in using browser extensions to autofill credentials. - -Auto-filling credentials can protect against phishing attacks. Your password manager will refuse to autofill credentials for the wrong site, such as `exxample.com` attempting to impersonate `example.com`. However, it can be [difficult to implement this functionality securely in an extension](https://lock.cmpxchg8b.com/passmgrs.html#interprocess-communication). - -## Team credentials - -Credentials sometimes need to be shared across a team or programme. Software repositories (NPM, RubyGems, Maven Central) and admin portals (Fastly, DockerHub) will often have shared credentials. - -[You should follow the guidance for managing team credentials.](/standards/accounts-with-third-parties.html). - -We have no established best practice for storing shared credentials at GDS. Some teams have a "credentials" GitHub repository and use [pass](https://www.passwordstore.org/) or [blackbox](https://github.com/StackExchange/blackbox) to store credentials encrypted with GPG. - -<%= warning_text('Make sure you configure the repo as internal or ideally private to help prevent accidental disclosure') %> - -Investigate alternatives before adopting GPG-based credential stores for new teams. - -- We cannot revoke access to GPG-based credentials unless we change them. Anyone with access can still decrypt credentials using their local copy of the repo and its commit history. - -- It creates a high barrier to entry as GPG tools are [generally difficult to use](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) and key-servers are unreliable. - -The GOV.UK Design System and Prototype Kit teams have recently set up a [Bitwarden](https://bitwarden.com) organisation as a replacement for their credentials repository. - -## Service credentials - -Deployed services sometimes need sensitive configuration such as API keys and IP block lists. - -Use the secret management feature of your infrastructure or cloud provider e.g. [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/getting-started/), [HashiCorp Vault](https://www.vaultproject.io/). This should make it easy to control and audit access to the credentials. - -Older projects in GDS might have a "secrets" repository and use GPG to encrypt files, which are then decrypted during the deployment process. This approach should not be used unless there is no better option. diff --git a/source/docs/standards/software/threat-modelling.html.md.erb b/source/docs/standards/software/threat-modelling.html.md.erb deleted file mode 100644 index c298618..0000000 --- a/source/docs/standards/software/threat-modelling.html.md.erb +++ /dev/null @@ -1,272 +0,0 @@ ---- -title: Threat Modelling -last_reviewed_on: 2024-10-03 -review_in: 6 months ---- - -# <%= current_page.data.title %> - -## What's a threat? - -A threat is an action that causes denial, alteration or disclosure of your -assets that you are trying to protect. It could be a user database, a deployment -pipeline or the integrity of web form submissions. - -## What's threat modelling? - -Threat modelling aims at identifying, prioritising and mitigating threats to a service. - -Attack Tree workshops will help you: - -* Understand threats that are unique to your service, helping you to adopt security conscious behaviours during its design, development and operation -* Focus mitigation efforts on the threats that matter – that is, threats that pose the greatest risk to the normal operation of your service -* Ensure the right security controls are in place to match the threats your service faces -* Adopt secure by design approach to your service throughout the service's lifecycle - -The best time to perform threat modelling activities is during the design phase; -however, it can be done anytime and should become a continuous process in your -service team. - -Within the Cabinet Office, the Cyber Security Team can [support you with threat modelling your service][COD Threat Modelling], as well as advising you should you decide to carry it out yourself or through a third party. - -Within the Cabinet Office and GDS, we follow the [Threat Modeling Manifesto][]'s -four questions: - -1. What are we working on? -2. What can go wrong? -3. What are we going to do about it? -4. Did we do a good enough job? - -We answer most of the above over three sessions, with time between sessions -allowing for asynchronous input. - -### 1. Threat Discovery - -Threat discovery aims to answer the “What are we working on?” and part of -the “What can go wrong?” question. - -We use an interactive exercise to talk through and explain the system or -architecture. Someone who is comfortable with explaining the system from the -service team will need to lead this part. Try to keep the scope small; it may be -more effective to break a service down and perform multiple threat modelling -activities. - -The group of people involved typically includes the development team, cyber -security and information assurance colleagues; however, working with other -people, such as user researchers and product managers, often provides more -varied perspectives. - -As part of the interactive exercise, we surface hypothetical threats or -vulnerabilities in a service. We use [STRIDE][] to help us look at different -aspects and make sure we get a rounded view of all threats. - -#### 1.1 Interactive Exercise - -The purpose of this exercise is to talk through the service, architecture or the -user journey with the people in the session, allowing for questions and answers. - -Remotely, digital whiteboard software, such as [Jamboard][], [Mural][], -can be used to add virtual post-its on top of the digital diagrams. -Make sure the tools are accessible so all colleagues can participate and ensure -access control is sufficient as the diagrams will likely be at least -OFFICIAL-SENSITIVE when complete. - -Another useful tool you could use is [diagrams.net][] with its [threat -modelling library][diagrams.net threat modelling]. - -In person, which may be more appropriate for some teams and systems, diagrams -are typically drawn up on a whiteboard, followed by questions and post-its of -potential threats stuck at relevant points. - -### 2. Threat Analysis - -Threat analysis aims to finalise the answer to the “What can go wrong?” -question. We use a scoring methodology to determine if a threat is valid and -prioritise threats against each other. - -You should aim to cover all potential [attack vectors][]. - -#### 2.1 Scoring - -After the discovery stage, you can make a copy of the -[Threat Modelling Scoring template][] to use for noting down threats, the most -likely actor, scoring, and tracking mitigation. - -Scoring is useful as it helps prioritise what's valid and what you should look into -first. - -The difficulty is a rating between 0 (very easy) to 5 (hard); it should take -into account how hard it would be to gain access and any costs associated with -performing the attack. - -The reward is a rating between 0 (low) to 5 (high); it’s how valuable the -outcome is to the threat actor. - -The final score equals reward minus difficulty, so a high score is worse than a -low one. - -### 3. Threat Response - -Threat response aims to answer the “What are we going to do about it?” -question. - -It may be helpful to add the outputs to your bug or ticket tracking system. - -There are three typical responses to threats: - -#### 3.1 Mitigate -Implementing a preventive control, such as an architectural change, eliminates -the vulnerability or blocks the threat. - -#### 3.2 Monitor -Monitoring is a reactive control to detect if a threat occurs; it controls a -situation and limits damage or loss by detecting an attack early. - -#### 3.3 Acknowledge the risk -Acknowledging the risk but not planning any immediate action can help with -resourcing any future mitigation or deciding to accept a risk because the cost -of the mitigation outweighs the maximum cost of a threat. - -### 4. Did we do a good enough job? - -After completing the threat modelling activity sessions, you should set aside -some time to review the threat modelling outputs regularly. This is to see -whether you are improving the security and taking the mitigations forward; it’s -also important to consider any new threats. - -A recommendation is to perform this review within your service team every two -months; the time you need may vary depending on the scope of your threat -modelling, but 90 minutes is usually sufficient. - -You should consider running the threat modelling sessions every year or when -there are significant architectural changes planned. - -## Why's it necessary? - -Adam Shostack has produced an informative short video on this: -[Why Threat Model?][] - -Adam explains that we threat model to anticipate problems when it's inexpensive -to deal with them. - -How do you know what a problem is? Information and computer security is -often broken up into three main pillars, known as the CIA triad: - -### Confidentiality -- Information accessible to authorised people - -### Integrity -- Information that's correct - -### Availability -- Information available when needed - -Abuse or neglect of one or more of these pillars could lead to a security -incident. - -The opposite of the CIA triad is sometimes known as the DAD triad: - -- If confidentiality is affected, disclosure occurs. -- If integrity is affected, alteration occurs. -- If availability is affected, denial occurs. - -Here is a fun, alternative look at the -[CIA and DAD triads, explained with Lord of the Rings references][]. - -## STRIDE - -STRIDE is a model of threats developed by Microsoft. - -It's a helpful tool for thinking about different potential attacks or -vulnerabilities. If you're finding it hard coming up with potential -attacks, you can use STRIDE to help stimulate ideas. - -Note that STRIDE is *not* useful as a taxonomy. Some attacks don't -neatly fit into "spoofing" versus "tampering" versus "elevation of -privilege". That doesn't matter: the important thing is to come up -with threats and write them down, not to ensure they are "correctly" -categorised. - - -|Threat|Security Control| -|-|-| -|Spoofing|Authenticity| -|Tampering|Integrity| -|Repudiation|Non-repudiability| -|Information Disclosure|Confidentiality| -|Denial of Service|Availability| -|Elevation of Privilege|Authorisation| - -### Spoofing -Spoofing occurs where malicious actors use another person's user credentials without -their knowledge. - -It also includes attacks where systems mimic or disguise themselves as other systems, such -as IP address spoofing in DNS amplification attacks. - -The desired property is authenticity, meaning an event or action is trustworthy -and genuine. - -### Tampering -Only authorised users should be able to modify a system or the data it uses. - -The desired property is integrity, meaning an event or action is valid and -correct. - -### Repudiation -Repudiation means an action or event cannot be associated with what triggered it, -whether that is a person or another system component. - -The desired property is non-repudiation, which means an action or event is -difficult to deny by a person or system. - -### Information Disclosure -Data such as passwords or personal information is made available to those who -should not have access to it. - -The desired property is confidentiality, where data is only available to those -who are authorised to view or alter it. - -### Denial of Service (DoS) -Data is unavailable for its intended audience. - -The desired property is availability, where data is always available when those -authorised to view or alter it expect it to be. - -Distributed Denial of Service (DDoS) is a form of DoS where multiple entities -are responsible for inappropriate traffic leading to overwhelmed services. - -### Elevation of Privilege -Data is available to unintended or unauthenticated users. - -The desired property is authorisation, where data is only available to those -expected to view or alter it. - -## Examples - -Looking at the GOV.UK Pay service as an example; Pay is likely to attract attention from organised criminal groups and lower-level hackers/script kiddies who have financial motivations. Organised criminal groups are capable of a level of attack sophistication that would mean zero-day exploits, and more advanced techniques like replay attacks, and would be willing to use supply chain attacks as a route for access. State actors are likely to be less interested in Pay, except for disruptive actions to render the service unavailable. - -Applying this threat model, Pay requires a good level of cyber security (in addition to it's PCI-DSS requirements) and regular scanning/penetration testing is necessary to ensure that both basic cyber hygience and more advanced attacks are accounted for. - -This would contrast with a service like GOV.UK, where the threat is likely to be state sponsored or affiliated threats and lower-level hackers/script kiddies using common toolsets/bots with political/reputational motivations. - -## Additional tools and links - -- [OWASP Application Threat Modelling][] -- [Mario Areias - Threat Modelling the Death Star][] YouTube video example - - -[COD Threat Modelling]: https://intranet.cabinetoffice.gov.uk/it-data-and-security/cyber-and-information-security-services/threat-modelling/ -[Why Threat Model?]: https://www.youtube.com/watch?v=YP4mNRXGcks -[attack vectors]: https://searchsecurity.techtarget.com/definition/attack-vector -[Threat Modeling Manifesto]: https://www.threatmodelingmanifesto.org/ -[Threat Modelling Scoring template]: https://docs.google.com/spreadsheets/d/1u22W_bUEPESvbMde-Q4syJLTen1OKIcE4ILk7wyaydM/edit#gid=0 -[STRIDE]: #stride -[Threat modelling Google Slides introduction]: https://docs.google.com/presentation/d/1wwnPaVq9zryJFhHP9DIKEMrMh6Ts37d7_ApHnt5EFpE -[Jamboard]: https://jamboard.google.com/ -[Mural]: https://www.mural.co/ -[diagrams.net]: https://www.diagrams.net/ -[diagrams.net threat modelling]: https://michenriksen.com/blog/drawio-for-threat-modeling/ -[CIA and DAD triads, explained with Lord of the Rings references]: https://squirreltb.wordpress.com/2015/11/17/the-cia-and-dad-triad/ -[OWASP Application Threat Modelling]: https://owasp.org/www-community/Threat_Modeling -[Mario Areias - Threat Modelling the Death Star]: https://www.youtube.com/watch?v=ivmfZ6vGkEs&feature=youtu.be diff --git a/source/docs/standards/software/understanding-risks.html.md.erb b/source/docs/standards/software/understanding-risks.html.md.erb deleted file mode 100644 index 5131f92..0000000 --- a/source/docs/standards/software/understanding-risks.html.md.erb +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Understand the risks to your service -last_reviewed_on: 2024-10-03 -review_in: 6 months ---- - -# <%= current_page.data.title %> - -When you build, maintain or change your service, you must have a clear understanding of any associated risks because they will impact your service design and affect your users. - -You should work with [GDS Information Security IA] to design appropriate solutions for your service's risks. IA may need to obtain risk acceptance from your Senior Risk Owner (SRO). -You can also work with the [COD Cyber Security Team] to get advice on the threats applicable to your service, and how to best mitigate them. - -The Service Manual has some recommendations which can reduce risk to your service, for example, how to: - -* [protect against fraud][] when you design and manage your service -* [secure your information][] if you handle ‘official’ classified data - -The government security hub [security.gov.uk][securityhub] provides links to the policies and standards that we have to follow. - -## Model security threats - -Modelling threats can help you gain a clearer understanding of threats against your service, see [threat modelling][]. - -## Further Reading - -The [National Cyber Security Centre (NCSC)] provides guidance about cyber security. The Service Manual has advice about [securing your information] and [securing your cloud environment]. - -[GDS Information Security IA]: https://sites.google.com/a/digital.cabinet-office.gov.uk/gds/directorates-and-groups/cto-and-ciso-office/information-security -[COD Cyber Security Team]: https://intranet.cabinetoffice.gov.uk/it-data-and-security/cyber-and-information-security-services/ -[protect against fraud]: https://www.gov.uk/service-manual/technology/protecting-your-service-against-fraud -[secure your information]: https://www.gov.uk/service-manual/technology/securing-your-information -[Threat modelling]: ./threat-modelling.html -[National Cyber Security Centre (NCSC)]: https://www.ncsc.gov.uk/ -[securing your information]: https://www.gov.uk/service-manual/technology/securing-your-information -[securing your cloud environment]: https://www.gov.uk/service-manual/technology/securing-your-cloud-environment -[securityhub]: https://www.security.gov.uk/ diff --git a/source/docs/standards/software/user-support.html.md.erb b/source/docs/standards/software/user-support.html.md.erb deleted file mode 100644 index 0c2c813..0000000 --- a/source/docs/standards/software/user-support.html.md.erb +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: How GDS provides user support -last_reviewed_on: 2024-05-14 -review_in: 6 months ---- - -# <%= current_page.data.title %> - -GDS teams follow Service Manual guidance on [setting up and managing user support](https://www.gov.uk/service-manual/helping-people-to-use-your-service/set-up-and-manage-user-support). - -GDS teams operate support models that are aligned to the needs of the users that they are supporting. For example, the [GOV.UK Pay](https://www.payments.service.gov.uk/) team supports users working in government departments that are using GOV.UK Pay or considering doing so. [GOV.UK](https://www.gov.uk/) and [One Login](https://www.sign-in.service.gov.uk/) support both government and non-government users. - -## Support lines for your service - -However the support model varies, teams will have multiple 'lines' of support. - -### 1st line user support - -1st line support provide resolution for basic user enquiries and triage frequent, repeatable incidents. For example, issues signing in. - -The GDS User Support team provides 1st line support for many teams in GDS. Contact the User Support team using the [#user-support Slack channel]. - -### 2nd line technical support - -2nd line support provide direct incident resolution (see [incident management](/standards/incident-management.html)) and triage user requests. For example, when users receive timeout errors or performance issues. - -### 3rd line product teams - -3rd line support are technical specialists associated with an existing product team. Their involvement in incident management is limited to the diagnosis and resolution of more complex incidents, such as a data or security breach, or a complete service outage. - -## Document routes to support - -Document the routes into each support line for your service. For example, users might contact 1st line support using an online form or by email. 2nd line support respond to issues raised through 1st line support and also alerts from failed tests, monitoring and vulnerability scans. - -Understanding your service’s routes into support will make sure support and product teams monitor the relevant channels. It will also make sure your service users and team understand how to reach the level of support they need. - -## Support hours and support rotas - -Document and share your support team’s operating hours. Many GDS teams operate a rota for their 2nd line support and escalation contacts. - -## Zendesk - -Most GDS teams use Zendesk to manage communications with service users. The User Support team work with GDS teams to help manage Zendesk setup and configuration, for example with: - -- adding and removing Zendesk accounts -- choosing agent types, groups and ‘pass-through’ to other government departments -- [General Data Protection Regulation (GDPR)](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/) considerations, such as data disclosure and data retention -- general best practice guidance - -For help using Zendesk in GDS, contact the User Support team using the [#user-support Slack channel] - -[#user-support Slack channel]: https://gds.slack.com/archives/CADFJBDQU diff --git a/source/docs/standards/software/vulnerability-disclosure.html.md.erb b/source/docs/standards/software/vulnerability-disclosure.html.md.erb index 6348619..f699823 100644 --- a/source/docs/standards/software/vulnerability-disclosure.html.md.erb +++ b/source/docs/standards/software/vulnerability-disclosure.html.md.erb @@ -1,6 +1,6 @@ --- title: Vulnerability Disclosure and security.txt -last_reviewed_on: 2023-11-21 +last_reviewed_on: 2025-01-03 review_in: 12 months --- # <%= current_page.data.title %> @@ -9,14 +9,14 @@ review_in: 12 months The [Cabinet Office Cyber Security team] runs a vulnerability disclosure programme with [HackerOne] and [NCC Group] to triage -reports from security researchers. This is not a sign post for security researchers +reports from security researchers. This is not a sign post for security researchers to 'hack' our systems; we advocate secure disclosure so we can find out about issues and fix them before they cause a security incident. The public security policy is here: -GDS services are within scope of this programme and should participate by: +All Cabinet Office digital services are within scope of this programme and should participate by: - publishing a [`security.txt`](#security-txt) - having a plan for how you would respond to a vulnerability notification (triage, escalation, etc.). diff --git a/source/docs/standards/software/working-with-git.html.md.erb b/source/docs/standards/software/working-with-git.html.md.erb index 0a57150..41f0353 100644 --- a/source/docs/standards/software/working-with-git.html.md.erb +++ b/source/docs/standards/software/working-with-git.html.md.erb @@ -1,6 +1,6 @@ --- title: Working with Git -last_reviewed_on: 2024-05-01 +last_reviewed_on: 2025-01-03 review_in: 9 months --- @@ -162,7 +162,7 @@ This applies your local changes on top of the most recent changes to the trunk b Git allows you to [rewrite local changes](https://git-scm.com/book/en/Git-Tools-Rewriting-History) by combining commits, splitting commits apart, changing commit messages and many more operations. You should not rewrite commits that have been merged or pushed to the trunk branch unless there is a compelling reason such as committing personally identifiable information or application secrets. -In this case you should communicate this to affected staff within GDS, so they know to update their local working copy. +In this case you should communicate this to affected staff within the organisation, so they know to update their local working copy. You should use `git merge` with `--no-ff` if you are manually merging a feature branch into your repository's trunk branch rather than GitHub's own merge capability. This option preserves evidence of your feature branch in the repository history by creating a merge commit even if your changes could be simply applied to the trunk branch. @@ -199,5 +199,4 @@ it is the state that we expect, which is that nobody has updated the remote bran ## See also -* [How to store source code](index.html) -* [Working with Git](working-with-git.html) +* [How to store source code](source-code.html) diff --git a/source/partials/_nav-standards.html.erb b/source/partials/_nav-standards.html.erb index 2f3bcee..a034451 100644 --- a/source/partials/_nav-standards.html.erb +++ b/source/partials/_nav-standards.html.erb @@ -1,5 +1,4 @@