Commit 1ac0fbc6 authored by Jeff Burrows's avatar Jeff Burrows 👶

jburrows001 Started adding guidance documentation to handbook 2019-03-11

parent daaf856a
Pipeline #51330598 passed with stages
in 15 minutes and 11 seconds
# WIP - AM.1.01 - Inventory Management
## Control Statement
GitLab maintains an inventory of system devices, which is reconciled quarterly.
## Context
The purpose of this control is to ensure we are monitoring the systems in use by GitLab. We can't prove we are protecting all GitLab systems if we don't have an up-to-date inventory of those systems.
## Scope
This control applies to all GitLab endpoint workstations as well as virtual assets within our hosting providers.
## Ownership
The GitLab IT and Infrastructure teams are the primary owners of this control.
## 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/AM.1.01_inventory_management.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/AM.1.01_inventory_management.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/AM.1.01_inventory_management.md).
## Framework Mapping
* ISO
* A.8.1.1
* PCI
* 9.6.1
* 9.7
* 9.7.1
# WIP - BC.1.01 - Business Continuity Plan
## Control Statement
GitLab's business contingency plan is reviewed, approved by management and communicated to relevant team members biannually.
## Context
The review cycle for business continuity plans are designed to ensure all information in the plan is as up-to-date as possible. A business continuity plan is only effective if users can trust the accuracy of the information in the plan. The business continuity plan is meant to be a comprehensive runbook that can walk all GitLabbers through exactly what their individual responsibilities are in the event of a disruption to GitLab operations. This triggering event can be anything from a malicious breach of our systems to a global datacenter disruption.
## Scope
The business continuity plan is comprehensive by nature and will impact all GitLab stakeholders.
## 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/BC.1.01_business_continuity_plan.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/BC.1.01_business_continuity_plan.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/BC.1.01_business_continuity_plan.md).
## Framework Mapping
* ISO
* A.17.1.1
* A.17.1.2
* SOC2 CC
* CC7.5
* CC9.1
* SOC2 Availability
* A1.2
* PCI
* 12.10.1
# WIP - BC.1.03 - Continuity Testing
## Control Statement
GitLab performs business contingency and disaster recovery tests quarterly and ensures the following:
* Tests are executed with relevant contingency teams.
* Test results are documented.
* Corrective actions are taken for exceptions noted.
* Plans are updated based on results.
## 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.
## Scope
All parts of the business continuity plan should be tested. All teams and services that have a documented business continuity plan should have a corresponding documented test.
## 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/BC.1.03_continuity_testing.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/BC.1.03_continuity_testing.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/BC.1.03_continuity_testing.md).
## Framework Mapping
* ISO
* A.17.1.2
* A.17.1.3
* SOC2 CC
* CC7.5
* CC9.1
* SOC2 Availability
* A1.3
# WIP - BC.1.04 - Business Impact Analysis
## Control Statement
GitLab identifies the business impact of relevant threats to assets, infrastructure, and resources that support critical business functions. Recovery objectives are established for critical business functions.
## Context
* Business impact analysis (BIA) is a component of both business continuity planning but also of risk management.
* In the context of business continuity, BIAs help establish a priority for teams and services.
* Additionally, BIAs help document the risks associated with those teams and functions.
* BIAs help document the role of a team or service within the organization.
* BIAs are not meant to be comprehensive or perfectly reflect the impact that the team or service has on GitLab; BIAs are simply a way to threats and the related impact on business operations.
## Scope
BIAs should exist for all services and teams that have a business continuity plan.
## 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/BC.1.04_business_impact_analysis.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/BC.1.04_business_impact_analysis.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/BC.1.04_business_impact_analysis.md).
## Framework Mapping
* ISO
* A.17.1.1
* A.17.1.2
* SOC2 CC
* CC7.5
# WIP - BU.1.01 - Backup Configuration
## Control Statement
GitLab configures redundant systems and performs data backups routinely as specificied by management to resume system operations in the event of a system failure.
## Context
We need to demonstrate that GitLab can be restored to a prior point in time in the event the data is corrupted, service interruption or other event that disrupts normal service. This helps ensure we have redundancy/backups enabled.
## Scope
TBD
## 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/BU.1.01_backup_configuration.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/BU.1.01_backup_configuration.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/BU.1.01_backup_configuration.md).
## Framework Mapping
* ISO
* A.18.1.3
* SOC
* A1.2
* PCI
* 12.10.1
# WIP - BU.1.02 - Resilience Testing
## Control Statement
GitLab performs backup restoration and/or failover tests quarterly to confirm the reliability and integrity of system backups and/or recovery operations.
## Context
By validating system backups/recovery operations in the event of an actual disaster or other disruption to service; we will have greater proficiency in restoring service to customers.
## Scope
TBD
## 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/BU.1.02_resilience_testing.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/BU.1.02_resilience_testing.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/BU.1.02_resilience_testing.md).
## Framework Mapping
* ISO
* A.12.3.1
* SOC
* A1.2
* PCI
* 12.10.1
# WIP - CM.1.01 - Change Management Workflow
## Control Statement
Change scope, change type, and roles and responsibilities are pre-established and documented in a change control workflow; notification and approval requirements are also pre-established based on risk associated with change scope and type.
## Context
Having a structured workflow and guidance on change management helps reduce the risk of GitLab experiencing platform or application instability by increasing the predictability and reproducibility of the change management process.
## Scope
This control applies to the GitLab.com production environment.
## 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/CM.1.01_change_management_workflow.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/CM.1.01_change_management_workflow.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/CM.1.01_change_management_workflow.md).
## Framework Mapping
* ISO
* A.12.1.2
* A.12.6.2
* A.14.2.1
* A.14.2.2
* A.14.2.4
* SOC2 CC
* CC2.3
* CC8.1
* PCI
* 1.1.1
* 10.4.2
* 6.4
* 6.4.5
* 6.4.5.1
* 6.4.5.2
* 6.4.5.3
* 6.4.5.4
* 6.4.6
# WIP - CM.1.02 - Change Approval
## Control Statement
Prior to introducing changes into the production environment, approval from authorized personnel is required based on the following:
* Change description
* Impact of change
* Test results
* Back-out procedures
## Context
This control aims to ensure important information about the change, its impacts, and ability to revert the change are documented and a part of the approval process. This allows everyone involved to have the information they need to make informed decisions about and execute on a change effectively. It also sets out to ensure all changes which could impact GitLab customers, GitLab team members, and partners are approved by the appropriate person(s).
## Scope
This control applies to any application or infrastructure changes introduced into the GitLab production environment.
## 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/CM.1.02_change_approval.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/CM.1.02_change_approval.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/CM.1.02_change_approval.md).
## Framework Mapping
* ISO
* A.12.5.1
* A.14.2.3
* A.14.2.4
* A.14.2.8
* A.14.2.9
* SOC2 CC
* CC8.1
* PCI
* 1.1.1
* 10.4.2
* 6.3.2
* 6.4
* 6.4.5
* 6.4.5.1
* 6.4.5.2
* 6.4.5.3
* 6.4.5.4
* 6.4.6
# WIP - CON.1.01 - Baseline Configuration Standard
## Control Statement
GitLab ensures security hardening and baseline configuration standards have been established according to industry standards and are reviewed and updated quarterly.
## Context
Baseline hardening standards make it clear how systems should be hardened and configured. To ensure we these standards are always relevant, we need to regularly review these documents and update them as needed. The goal of this control is to remove as much subjectivity as possible from the process of configuring systems. If we create a standard for each system type within GitLab, it will be easier to automate system configuration and ensure that all systems are configured the same. This consistent configuration becomes critical when critical vulnerabilities are discovered and need to be rapidly deployed to all applicable systems.
## Scope
This control applies to all hosted systems (e.g. VM's and GCP compute services) as well as end user workstations (e.g. GitLabbers' MacBooks).
## 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/CON.1.01_baseline_configuration_standard.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/CON.1.01_baseline_configuration_standard.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/CON.1.01_baseline_configuration_standard.md).
## Framework Mapping
* ISO
* A.12.5.1
* SOC2 CC
* CC7.1
* CC7.2
* PCI
* 1.1
* 1.1.4
* 1.1.6
* 1.2
* 1.2.2
* 2.1
* 2.1.1
* 2.2
* 2.2.2
* 2.2.3
* 2.2.4
* 2.2.5
* 5.3
# WIP - CON.1.03 - Configuration Checks
## Control Statement
GitLab uses mechanisms to detect deviations from baseline configurations in production environments.
## Context
This is simply a control that ensures we are monitoring our systems to ensure that configuration standards are actually being applied to all production systems.
## Scope
This control applies to all systems within our production environment.
## 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/CON.1.03_configuration_checks.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/CON.1.03_configuration_checks.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/CON.1.03_configuration_checks.md).
## Framework Mapping
* ISO
* A.9.4.4
* A.12.5.1
* SOC2 CC
* CC6.1
* CC7.1
* CC7.2
* PCI
* 1.2.2
* 10.4.2
* 11.4
* 11.5
* 11.5.1
* 5.3
# WIP - CON.1.04 - Configuration Check Reconciliation: CMDB
## Control Statement
GitLab reconciles the established device inventory against the enterprise log repository quarterly; devices which do not forward security configurations are remediated.
## Context
This control helps to close the loop between device inventory information and production logs. If all production systems are sending the appropriate logs, there should be a parity between the device inventory GitLab collects and the logs generated from those systems. This control is meant to be a check on the "Configuration Check" control. This reconciliation ensures that all systems that should be forwarding security configuration information, are.
## Scope
This control applies to all production systems.
## 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/CON.1.04_configuration_check_reconciliation.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/CON.1.04_configuration_check_reconciliation.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/CON.1.04_configuration_check_reconciliation.md).
## Framework Mapping
* SOC2
* CC6.1
# WIP - CON.1.07 - Default Device Passwords
## Control Statement
Vendor-supplied default passwords are changed according to GitLab standards prior to device installation on the GitLab network or immediately after software or operating system installation.
## Context
Changing the default password will strengthen the baseline configuration and reduce the ability for the system/device to become compromised.
## Scope
This control applies to all hosted systems (e.g. VM's and GCP compute services) as well as end user workstations (e.g. GitLabbers' MacBooks) and all third-party applications utilized by GitLab.
## 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/CON.1.07_default_device_passwords.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/CON.1.07_default_device_passwords.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/CON.1.07_default_device_passwords.md).
## Framework Mapping
* PCI
* 2.1
* 2.1.1
......@@ -11,7 +11,7 @@ title: "GitLab Security Compliance Controls"
# GitLab Control Framework (GCF)
Adobe's [open source compliance framework](https://blogs.adobe.com/security/2017/05/open-source-ccf.html) served as the starting point of GitLab's overarching information security framework. It has been adapted and expanded as needed and the result is the below list of controls grouped by families and sub-families. We are currently working towards providing the following for each control in the below table:
Adobe's [open source compliance framework](https://blogs.adobe.com/security/2017/05/open-source-ccf.html) served as the starting point of GitLab's overarching information security framework. It has been adapted and expanded as needed and the result is the below list of controls grouped by families and sub-families. Click on the links below to access to following information for each control:
* Control statement
* Context
* Scope
......@@ -25,7 +25,7 @@ Adobe's [open source compliance framework](https://blogs.adobe.com/security/2017
## Asset Management
* Device and Media Inventory
* Inventory Management
* [Inventory Management](./guidance/AM.1.01_inventory_management.html)
* Inventory Management: Payment Card Systems
* Inventory Labels
* Device and Media Transportation
......@@ -37,32 +37,32 @@ Adobe's [open source compliance framework](https://blogs.adobe.com/security/2017
## Backup Management
* Backup
* Backup Configuration
* Resilience Testing
* [Backup Configuration](./guidance/BU.1.01_backup_configuration.html)
* [Resilience Testing](./guidance/BU.1.02_resilience_testing.html)
* Alternate Storage
## Business Continuity
* Business Continuity Planning
* Business Continuity Plan
* Continuity Testing
* Business Impact Analysis
* [Business Continuity Plan](./guidance/BC.1.01_business_continuity_plan.html)
* [Continuity Testing](./guidance/BC.1.03_continuity_testing.html)
* [Business Impact Analysis](./guidance/BC.1.04_business_impact_analysis.html)
## Change Management
* Change Management
* Change Management Workflow
* Change Approval
* [Change Management Workflow](./guidance/CM.1.01_change_management_workflow.html)
* [Change Approval](./guidance/CM.1.02_change_approval.html)
* Segregation of Duties
* Segregation of Duties