Commit d49260c5 authored by Jeff Burrows's avatar Jeff Burrows 👶

GitLab Security Controls - Revision 2

parent a84e7df9
---
layout: handbook-page-toc
title: "CFG.1.04 - Configuration Check Reconciliation: CMDB Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# CFG.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 systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.
## Ownership
* Control Owner: `IT Ops`
* Process owner(s):
* IT Ops: `100%`
## Guidance
Security configurations for endpoints can be collected using, for example, endpoint management tools such as Fleetsmith.
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/787).
Examples of evidence an auditor might request to satisfy this control:
* Copy of the GitLab device inventory
* Handbook entry for the device inventory process
* Handbook entry for the log reconciliation process
* Sample of remediation issues or other documentation showing remediation of devices not forwarding security configurations
### Policy Reference
## Framework Mapping
* SOC2
* CC6.1
---
layout: handbook-page-toc
title: "CFG.1.07 - Default Device Passwords Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# CFG.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 systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.
## Ownership
* Control Owner: `Infrastructure`
* Process owner(s):
* IT Ops
* Infrastructure
## Guidance
Default, vendor-provided credentials should be changed before connecting an endpoint or application to GitLab's production network. In some cases, the vendor may generate secure, randomized passwords unique to GitLab as part of its offering and underlying automation. However, those can be used as they're unique and randomly generated in response to an action initiated by GitLab. To test for this control, provide vendor documentation showing default credentials are not used or otherwise disabled for CloudVM, OS Login, Kibana, and Grafana. Provide specific configurations showing alternative authentication (such as OAuth) is used for OS Login, Prometheus, and Thanos.
If anyone discovers production systems or tools that have the ability to use default credentials that is not listed above, please reach out to the [security compliance team](/handbook/engineering/security/compliance.html#contact-the-compliance-team) and we will add those systems/tools to this testing.
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Default Device Passwords control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/790).
Examples of evidence an auditor might request to satisfy this control:
* Sample or documentation of the new user account creation process for critical accounts and systems showing no default password can be used and users must set a strong and unique password
* Non-confidential samples of Terraform and Chef configs showing default passwords aren't used for GitLab.com infrastructure
### Policy Reference
## Framework Mapping
* PCI
* 2.1
* 2.1.1
---
layout: handbook-page-toc
title: "CM.1.03 - Change Management Issue Tracker"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# CM.1.03 - Change Management Issue Tracker
---
layout: handbook-page-toc
title: "CM.1.04 - Emergency Changes"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# CM.1.04 - Emergency Changes
---
layout: handbook-page-toc
title: "CM.3.01 - Third-Party Change Management Workflow Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# CM.3.01 - Third-Party Change Management Workflow
## Control Statement
Third-party vendor and service 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 third-party systems that support the business of GitLab.com.
## Ownership
* Control Owner: `Finance`
* Process owner(s):
* Finance
* Business Operations
* System Owners
## Guidance
For third-party change management, there are two types of changes: automated updates from the vendor and customized changes performed by either GitLab or the vendor. Automated updates are categorized under the SaaS's patch management and we can rely on the SOC report and release notes from the vendor. This control is for customized changes.
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Change Management Workflow control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/781).
Examples of evidence an auditor might request to satisfy this control:
* Copy of the GitLab third-party change management workflow
* Sample of issues or other documentation showing the third-party change management workflow is followed
### Policy Reference
## 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
---
layout: handbook-page-toc
title: "DM.1.01 - Data Classification Criteria"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# DM.1.01 - Data Classification Criteria
---
layout: handbook-page-toc
title: "DM.7.01 - Secure Disposal of Media Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# 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, GitLab team-members, and partners we take measures to protect their data even after it's done being used.
## Scope
This control applies to GitLab team member laptops.
## Ownership
* Control Owner: `IT Ops`
* Process owner(s):
* IT Ops: `100%`
## Guidance
Certificates or logs of erasure should be maintained in accordance with the timelines set in the [global record retention schedule](https://docs.google.com/spreadsheets/d/1EbyOSQvjiT4KJGB0_evhJEfKlvp2qKaJJbyzknCEPzA/edit#gid=2111185845).
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Secure Disposal of Media control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/802).
Examples of evidence an auditor might request to satisfy this control:
* Handbook entry of the disposal process
* A shareable copy of media disposal runbook(s)
* Certificate(s) or log(s) of disposal
* Records indicating media is disposed of when appropriate
### Policy Reference
## 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: handbook-page-toc
title: "DM.7.03 - Data Retention and Disposal Policy"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# DM.7.03 - Data Retention and Disposal Policy
---
layout: handbook-page-toc
title: "IAM.1.03 - Terminations: People Resources Notifications Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# IAM.1.03 - Terminations: People Resources Notifications
## Control Statement
The People Operations Management system sends a notification to relevant personnel, or system, in the event of a termination of an information system user. Notification can be manual or automated.
## 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. The People Operations Management system is the source-of-record for the status of GitLab teammembers and therefore, any changes to status need to be communicated to downstream systems in order to ensure proper logical access management. 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.
For the purposes of the Gitlab Control Framework [GCF](https://about.gitlab.com/handbook/engineering/security/sec-controls.html#gitlab-control-framework-gcf), the control activites captured here are incorporated into [IAM.1.02 - Logical Access De-Provisioning](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.02_logical_access_deprovisioning.html) control.
## Scope
This control applies to any system or service where user accounts can be provisioned. As noted above, this control is NA for GitLab as the outlined control activites have been incorporated into [IAM.1.02 - Logical Access De-Provisioning ](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.02_logical_access_deprovisioning.html)
## Ownership
[IAM.1.02 ownership breakdown](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.02_logical_access_deprovisioning.html#ownership)
* Control Owners:
* People Ops
* IT Ops
* Process Owners:
* IT Ops (50%)
* System Owners (50%)
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Terminations: People Resources Notifications control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/807).
### Policy Reference
* [Access Control Policy and Procedures](/handbook/engineering/security/#access-control-policy-and-procedures)
* [GitLab Offboarding Guidelines](https://about.gitlab.com/handbook/offboarding/offboarding_guidelines/)
* [Access Management Process](https://about.gitlab.com/handbook/engineering/security/#access-management-process)
* [Logical Access Deprovisioning](https://about.gitlab.com/handbook/engineering/security/#deprovisioning)
* [Access Reviews](https://about.gitlab.com/handbook/engineering/security/#access-reviews)
## Framework Mapping
* ISO
* A.7.3.1
* A.9.2.1
* A.9.2.2
* A.9.2.3
* A.9.4.1
* A.9.2.6
* A.18.1.3
* SOC2 CC
* CC6.2
* CC6.3
* CC6.6
* CC6.7
* PCI
* 8.1.2
* 8.1.3
* 8.1.4
---
layout: handbook-page-toc
title: "IAM.1.08 - New Access Provisioning"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# IAM.1.08 - New Access Provisioning
---
layout: handbook-page-toc
title: "IAM.1.09 - Access Modifcation"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# IAM.1.09 - Access Modifcation
---
layout: markdown_page
title: "IAM.2.09 - Full Disk Encryption (Not Applicable)"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# IAM.2.09 - Full Disk Encryption (Not Applicable)
## Control Statement
Where full disk encryption is used, logical access must be managed independently of operating system authentication; decryption keys must not be associated with user accounts.
## Context
Separating user accounts from decryption keys decreases the likelihood that an attacker with possession or control of a GitLab system can access any data contained on that system.
## Scope
`N/A`
_Full disc encryption is not applicable to the GitLab environment as we do not process credit card numbers._
Encryption is covered by the following controls:
[DM.4.01 - Encryption of Data in Transit](https://about.gitlab.com/handbook/engineering/security/guidance/DM.4.01_encryption_of_data_in_transit.html)
[DM.4.02 - Encryption of Data at Rest](https://about.gitlab.com/handbook/engineering/security/guidance/DM.4.02_encryption_of_data_at_rest.html)
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Full Disk Encryption issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/820) .
## Framework Mapping
* PCI DSS V3.2.1 - Requirement `3.4.1`
---
layout: handbook-page-toc
title: "IAM.3.05 - Administrator access to Production"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# IAM.3.05 - Administrator access to Production
---
layout: handbook-page-toc
title: "IR.1.04 - Insurance Policy"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# IR.1.04 - Insurance Policy
---
layout: handbook-page-toc
title: "PR.1.03 - Policy and Procedure Review"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# PR.1.03 - Policy and Procedure Review
---
layout: handbook-page-toc
title: "PR.1.04 - Hiring Review by Management"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# PR.1.04 - Hiring Review by Management
---
layout: handbook-page-toc
title: "PR.1.05 - Job Descriptions"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# PR.1.05 - Job Descriptions
---
layout: markdown_page
title: "RM.1.03 - Self-Assessments (Not Applicable)"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# RM.1.03 - Self-Assessments (Not Applicable)
## Control Statement
Quarterly, reviews shall be performed with approved documented specification to confirm personnel are following security policies and operational procedures pertaining to:
* log reviews quarterly
* firewall rule-set reviews
* applying configuration standards to new systems
* responding to security alerts
* change management processes
## Context
Reviews ensure that the process we've designed are operating as intended. The above list represents the common ways attackers can exploit systems to steal, delete, or alter information.
## Scope
**This control has been found to be not applicable (N/A) to GitLab.** The underlying control mappings apply only to PCI Service Providers. GitLab is not a PCI Service Provider, so this control is not applicable.
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Self-Assessments issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/868) .
## Framework Mapping
* PCI DSS V3.2.1
* 12.11
* 12.11.1
---
layout: handbook-page-toc
title: "RM.1.05 - Risk Management Policy"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# RM.1.05 - Risk Management Policy
---
layout: handbook-page-toc
title: "RM.2.01 - Internal Audits Control Guidance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}