Commit 83842170 authored by Jeff Burrows's avatar Jeff Burrows 👶 Committed by Melissa Farber

Restructure security compliance controls

parent 308409bc
......@@ -25,24 +25,20 @@ This control applies to all GitLab endpoint workstations as well as virtual asse
## Ownership
The GitLab IT Operations and Infrastructure teams are the primary owners of this control.
* IT Operations owns the workstation assets portion of this control
IT Operations owns workstation assets.
Infrastructure owns server/virtual host-based assets.
* Infrastructure owns the system and service portions of this control
## Implementation Guidance
For detailed implementation guidance relevant to GitLab team-members, 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).
The scope of this control is broad by design. Asset inventories are the source of truth for what team-member workstations, systems, and services constitute GitLab as a company. If we want to verify if we are collecting logs on 100% of the systems we are required to collect logs for, this inventory allows us to cross reference the logs we have with all the systems for which these logs should exist.
## 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).
* [Workstation management vendor evaluation](https://gitlab.com/gitlab-com/business-ops/itops/issue-tracker/issues/130)
* [GitLab's architecture overview](https://docs.gitlab.com/ee/development/architecture.html)
* [GitLab's production architecture page](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/)
* [AM.1.01 Gap Analysis Issue](https://gitlab.com/gitlab-private/sec-compliance/gcf-gap-analysis/issues/69)
## Framework Mapping
......
......@@ -9,19 +9,39 @@ title: "GitLab Security Compliance Controls"
- TOC
{:toc}
# 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. Click on the links below to access to following information for each control:
* Control statement
* Context
* Scope
* Ownership
* Implementation guidance
* Reference Links
* Examples of evidence an auditor might request to satisfy this control
* Mapping to all underlying frameworks
There are a number of controls without links to guidance documentation. This is due to the way that GitLab has prioritized the formalization of all of the controls. A control without a link should not be taken to mean that GitLab is not in compliance with a specific control’s requirements, but rather that we are not yet tracking evidence of the operation of that control. Supporting documentation for all controls will be built out as we continue to iterate on our compliance program and pursue additional compliance certifications.
# GitLab's Security Controls
Security controls are a way to state our company's position on a variety of security topics. It's not enough to simply say "We encrypt data" since our customers and teams will naturally want to know "what data do we encrypt?" and "how do we encrypt that data?". When all of our established security controls are operating effectively this creates a security program greater than the sum of its parts that will demonstrate to our stakeholders that GitLab has a mature and comprehensive security program that will provide assurance that data within GitLab is reasonably protected.
## GitLab Control Framework (GCF)
We have tried to take a comprehensive approach to our immediate and future security compliance needs. Older and larger companies tend to treat each security compliance requirement individually which results in independent security compliance teams going out to internal teams with multiple overlapping requests. For example, at such a company you might have one database engineer that is asked to provide evidence of how a particular database is encrypted based on SOC2 requirements, then again for ISO requirements, then again for PCI requirements. This approach can be visualized as follows:
```mermaid
graph TD;
SOC2_Requirement1-->Team1;
SOC2_Requirement1-->Team2;
SOC2_Requirement2-->Team1;
SOC2_Requirement2-->Team2;
PCI_Requirement1-->Team1;
ISO_Requirement1-->Team2;
```
Given our [efficiency value](https://about.gitlab.com/handbook/values/#efficiency) here at GitLab we wanted to create a set of security controls that would address multiple underlying requirements with a single security control which would allow us to make fewer requests of our internal teams and efficiently collect all evidence we would need for a variety of audits at once. This approach can be visualized as follows:
```mermaid
graph TD;
SOC2_Requirement1-->GCF;
SOC2_Requirement2-->GCF;
PCI_Requirement1-->GCF;
ISO_Requirement1-->GCF;
GCF-->Team1;
GCF-->Team2;
```
Adobe's [open source compliance framework](https://blogs.adobe.com/security/2017/05/open-source-ccf.html) served as the starting point for this efficient method of collecting security control evidence. It has been adapted and expanded as needed and the result is the below list of controls grouped by families and sub-families.
Clicking a control below that has a link will take you to a page with a variety of information about that control. There are a number of controls without links due to the way that GitLab has prioritized the documentation of all of these controls. A control without a link should not be taken to mean that GitLab is not in compliance with a specific control’s requirements, but rather that we are not yet tracking evidence of the operation of that control. Supporting documentation for all controls will be built out as we continue to iterate on our compliance program and pursue additional compliance certifications.
## Control Ownership
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment