Commit 84e0dde7 authored by Jeff Burrows's avatar Jeff Burrows 👶

jburrows001 Added remaining guidance docs to handbook

parent 8adfa491
Pipeline #51505639 passed with stages
in 24 minutes and 21 seconds
# WIP - AM.1.01 - Inventory Management
---
layout: markdown_page
title: "AM.1.01 - Inventory Management Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# AM.1.01 - Inventory Management
## Control Statement
......
# WIP - BC.1.01 - Business Continuity Plan
---
layout: markdown_page
title: "BC.1.01 - Business Continuity Plan Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BC.1.01 - Business Continuity Plan
## Control Statement
......@@ -11,6 +22,15 @@ The review cycle for business continuity plans are designed to ensure all inform
## Scope
The business continuity plan is comprehensive by nature and will impact all GitLab stakeholders.
The scope of a Business Continuity Plan can be categorized into the following seven steps:
Identify the critical business functions
Identify the critical systems & its dependencies
Identify the risks to business
Specify and confirm the data backup and recovery plan are working efficiently.
Clearly document the functions and procedures of the BC plan, who should lead the effort and who are all the players involved
Prepare a detailed communication plan
Test, assess, learn and improve
## Ownership
......
# WIP - BC.1.03 - Continuity Testing
---
layout: markdown_page
title: "BC.1.03 - Continuity Testing Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BC.1.03 - Continuity Testing
## Control Statement
......@@ -11,7 +22,11 @@ GitLab performs business contingency and disaster recovery tests quarterly and e
## Context
The business continuity plan is only useful if it is both maintained and validated. The testing part of this process is meant to be that validation and determines the efficacy of the plan. The purpose of this control is to determine if the business continuity plan would work in the event of a disruption to normal GitLab operations.
The business continuity plan is only useful if it is both maintained and validated. The testing part of this process is meant to be that validation and determines the efficacy of the plan. The purpose of this control is to determine if the business continuity plan would work in the event of a disruption to normal GitLab operations. The BC plan these three main categories:
* Recovery Planning: Ensuring that Recovery processes and procedures are executed and maintained to timely restoration of systems or assets affected by any disruptive event.
* Improvements: Recovery planning and processes are improved by incorporating lessons learned into future activities.
* Communications: Restoration activities are coordinated with internal and external parties, such as coordinating centers, Internet Service Providers, system owners, victims and vendors.
## Scope
......
# WIP - BC.1.04 - Business Impact Analysis
---
layout: markdown_page
title: "BC.1.04 - Business Impact Analysis Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BC.1.04 - Business Impact Analysis
## Control Statement
......
# WIP - BU.1.01 - Backup Configuration
---
layout: markdown_page
title: "BU.1.01 - Backup Configuration Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BU.1.01 - Backup Configuration
## Control Statement
......
# WIP - BU.1.02 - Resilience Testing
---
layout: markdown_page
title: "BU.1.02 - Resilience Testing Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BU.1.02 - Resilience Testing
## Control Statement
......
# WIP - CM.1.01 - Change Management Workflow
---
layout: markdown_page
title: "CM.1.01 - Change Management Workflow Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CM.1.01 - Change Management Workflow
## Control Statement
......
# WIP - CM.1.02 - Change Approval
---
layout: markdown_page
title: "CM.1.02 - Change Approval Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CM.1.02 - Change Approval
## Control Statement
......
# WIP - CON.1.01 - Baseline Configuration Standard
---
layout: markdown_page
title: "CON.1.01 - Baseline Configuration Standard Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CON.1.01 - Baseline Configuration Standard
## Control Statement
......
# WIP - CON.1.03 - Configuration Checks
---
layout: markdown_page
title: "CON.1.03 - Configuration Checks Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CON.1.03 - Configuration Checks
## Control Statement
......
# WIP - CON.1.04 - Configuration Check Reconciliation: CMDB
---
layout: markdown_page
title: "CON.1.04 - Configuration Check Reconciliation: CMDB Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CON.1.04 - Configuration Check Reconciliation: CMDB
## Control Statement
......
# WIP - CON.1.07 - Default Device Passwords
---
layout: markdown_page
title: "CON.1.07 - Default Device Passwords Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# CON.1.07 - Default Device Passwords
## Control Statement
......
---
layout: markdown_page
title: "DM.2.01 - Terms of Service Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# DM.2.01 - Terms of Service
## Control Statement
Consent is obtained for GitLab's Terms of Service (ToS) prior to collecting personal information and when the ToS is updated.
## Context
One of the purposes of a ToS is to provide users specific information about what personal information GitLab collects and alert them when that agreement is changed. This promotes transparency and allows users to make informed choices. The purpose of this control is to ensure the ToS includes information on what personal information is collected and a mechanism to alert users of any changes is in place.
## Scope
This control applies to GitLab's ToS.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.2.01_terms_of_service.md).
## Framework Mapping
* SOC2 CC
* CC2.3
---
layout: markdown_page
title: "DM.4.01 - Encryption of Data in Transit Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# DM.4.01 - Encryption of Data in Transit
## Control Statement
GitLab encrypts red, orange, and yellow data transmitted over public networks.
## Context
Encrypting data transmitted over public networks helps ensure the confidentiality and integrity of that data. Without encryption, data in transit over public networks can easily be intercepted using automated, open source tools and viewed and maliciously modified by malicious actors.
## Scope
Encrypting data in transit over public networks applies to all red, orange, and yellow data.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.01_encryption_of_data_in_transit.md).
## Framework Mapping
* ISO
* A.13.2.3
* A.14.1.2
* A.14.1.3
* A.18.1.4
* A.18.1.5
* SOC2 CC
* CC6.7
* PCI
* 2.3
* 4.1
* 4.1.1
* 8.2.1
---
layout: markdown_page
title: "DM.4.02 - Encryption of Data at Rest Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# DM.4.02 - Encryption of Data at Rest
## Control Statement
Red, orange, and yellow data at rest is encrypted.
## Context
Encrypting data at rest helps ensure the confidentiality and integrity of that data. In the event a production instance, data store, or backup is compromised, without encryption, the data is near certain to be accessed, modified, and/or stolen. Encrypting sensitive data at rest adds another roadblock and layer of complexity for the adversary and helps protect customer, employee, and partner data.
## Scope
This control applies to red, orange, and yellow data.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.4.02_encryption_of_data_at_rest.md).
## Framework Mapping
* ISO
* A.18.1.4
* A.18.1.5
* A.8.2.3
* PCI
* 3.4
* 3.5
* 3.5.3
* 3.6
* 3.6.3
* 8.2.1
---
layout: markdown_page
title: "DM.7.01 - Secure Disposal of Media Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# DM.7.01 - Secure Disposal of Media
## Control Statement
GitLab securely erases media containing decommissioned red and orange data and obtains a certificate or log of erasure; media pending erasure are stored within a secured facility.
## Context
Securely disposing of both electronic and physical media adds a layer of protection from the data being disposed being recovered by unauthorized persons. There are several effective, publicly available tools and techniques to recover data from electronic and physical media, including hard drives and shredded paper. This control aims to reduce the risk of data being recovered by unauthorized persons and shows customers, GitLabbers, and partners we take measures to protect their data even after it's done being used.
## Scope
This control applies to both electronic and physical (for example, paper printouts) media.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/DM.7.01_secure_disposal_of_media.md).
## Framework Mapping
* ISO
* A.11.2.7
* A.8.3.2
* SOC2 CC
* CC6.5
* PCI
* 9.8
* 9.8.1
* 9.8.2
---
layout: markdown_page
title: "IAM.1.01 - Logical Access Provisioning Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# IAM.1.01 - Logical Access Provisioning
## Control Statement
Logical access provisioning to information systems requires approval from appropriate personnel.
## Context
The purpose of this control is to ensure there is a process in place to review and authorize new user account requests. Ensuring only people who require access to a system or service receive access helps improve GitLab's overall security posture by limiting the number of accounts with access and reducing the overall likelihood of an account being compromised.
## Scope
This control applies to any system or service where user accounts can be provisioned.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.01_logical_access_provisioning.md).
## Framework Mapping
* ISO
* A.9.2.1
* A.9.2.2
* A.9.2.3
* A.9.4.1
* A.12.5.1
* A.18.1.3
* SOC2 CC
* CC6.1
* CC6.2
* CC6.3
* CC6.6
* CC6.7
* PCI
* 7.1.4
* 8.1.2
---
layout: markdown_page
title: "IAM.1.02 - Logical Access De-Provisioning Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# IAM.1.02 - Logical Access De-Provisioning
## Control Statement
Logical access that is no longer required in the event of a termination is documented, communicated to management, and revoked.
## Context
The purpose of this control is to ensure there is a process in place to remove access to user accounts that is no longer necessary. This control helps ensure that only authorized and active accounts can be accessed and used to prevent any unauthorized use or access of GitLab customer, GitLab teammember, and partner data.
## Scope
This control applies to any system or service where user accounts can be provisioned.
## Ownership
TBD
## Implementation Guidance
For detailed implementation guidance relevant to GitLabbers, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/IAM.1.02_logical_access_deprovisioning.md).