Replace threatmanagement with security-operations in red team's links

  - Identity and Access Management

    - [@gitlab-com/gl-security/identity/infra](https://gitlab.com/gitlab-com/gl-security/identity/infra)

    - [@gitlab-com/gl-security/identity/ops](https://gitlab.com/gitlab-com/gl-security/identity/ops)

  - [@gitlab-com/gl-security/threatmanagement/redteam](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam)

  - [@gitlab-com/gl-security/security-operations/redteam](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam)

  - [@gitlab-com/gl-security/security-research](https://gitlab.com/gitlab-com/gl-security/security-research)

  - [@gitlab-com/gl-security/threatmanagement/vulnerability-management](https://gitlab.com/gitlab-com/gl-security/threatmanagement/vulnerability-management)

### Tooling

Maturity models leverage [Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html) to organise and track progress on the various processes. These issue boards are located in projects under the team GitLab group in [https://gitlab.com/gitlab-com/gl-security/](https://gitlab.com/gitlab-com/gl-security/) (for example: [https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-internal/red-team-maturity-model/](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-internal/red-team-maturity-model/) for the Red Team).

Maturity models leverage [Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html) to organise and track progress on the various processes. These issue boards are located in projects under the team GitLab group in [https://gitlab.com/gitlab-com/gl-security/](https://gitlab.com/gitlab-com/gl-security/) (for example: [https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-internal/red-team-maturity-model/](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-internal/red-team-maturity-model/) for the Red Team).

Each process of the maturity model is presented by an issue with a short title and a longer description.

Every project and relevant artifacts will be documented internally in the  [sec-research](https://gitlab.com/gitlab-com/gl-security/security-research/sec-research/) repository while the project is ongoing. This repository should be the SSOT for any results and will contain the raw artifacts, write-ups and any PoCs if applicable.

Once the project is concluded and any security issues identified are closed, public facing documentation will be published in the [Threat Management tech notes](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-tech-notes) repository. Where applicable, blog posts containing in-depth technical background on the research will be created in collaboration with the External Security Communications team.

Once the project is concluded and any security issues identified are closed, public facing documentation will be published in the [Threat Management tech notes](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-public/red-team-tech-notes) repository. Where applicable, blog posts containing in-depth technical background on the research will be created in collaboration with the External Security Communications team.

#### Metrics

The diagram below shows our basic workflow for planning, executing, and completing an operation. Everyone is welcome to participate actively in all stages, but some stages are owned specifically by one group or another.

Operations will be tracked using [GitLab epics](https://docs.gitlab.com/ee/user/group/epics/). Each of the unique stages has a corresponding [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html) that provides further detail on exactly what needs to be done. These templates are [shared publicly here](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates).

Operations will be tracked using [GitLab epics](https://docs.gitlab.com/ee/user/group/epics/). Each of the unique stages has a corresponding [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html) that provides further detail on exactly what needs to be done. These templates are [shared publicly here](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-public/resources/red-team-issue-templates).

As much as possible, our Purple Team operations should be performed [asynchronously](/handbook/company/culture/all-remote/asynchronous/). However, a few stages work best when done with live participants over a video conference with screen sharing. To include team members in all time zones, these stages can be conducted more than once. This is particularly beneficial when conducting the actual attacks and practicing detection. We will automate this work whenever possible, which makes repeating them easy.

All other systems managed by GitLab are in scope for all types of Red Team operations.

Team members can request that a system be excluded from our scope by [opening an issue here](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-internal/red-team-operations/-/issues/new).

Team members can request that a system be excluded from our scope by [opening an issue here](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-internal/red-team-operations/-/issues/new).

### Company-Issued Laptops