Commit e864372d authored by Luka Trbojevic's avatar Luka Trbojevic
Browse files

Update BU1.02, CFG1.01, IAM1.04, SYS2.07 controls

parent 825af599
Pipeline #82538257 passed with stages
in 31 minutes and 56 seconds
......@@ -21,17 +21,13 @@ By validating system backups/recovery operations in the event of an actual disas
 
## Scope
 
TBD
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 Team
Process owner:
* Infrastructure Team
* Control Owner: `Infrastructure Team`
* Process owner(s):
* Infrastructure Team
 
## Guidance
 
......@@ -50,6 +46,11 @@ This guidance is a two-parter, provide evidence demonstrating:
 
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 [Resilience Testing control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/779).
 
Examples of evidence an auditor might request to satisfy this control:
* A copy of GitLab's backup, disaster recovery, and incident response processes
* Documentation showing the testing of backup and disaster recovery procedure happens, at minimum, on a quarterly basis
## Framework Mapping
 
* ISO
......
......@@ -21,24 +21,29 @@ Baseline hardening standards make it clear how systems should be hardened and co
 
## Scope
 
This control applies to all hosted systems (e.g. VM's and GCP compute services) as well as end user workstations (e.g. GitLab team-members' MacBooks).
This control applies to all systems within our production environment and team member laptops. 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: `Security`
* Process owner(s):
* Security: `50%`
* IT Ops: `25%`
* Infrastructure: `25%`
* Infrastructure
* IT Ops
* Security
## Guidance
 
We do not have to reinvent the wheel with these, whenever possible we should be referencing industry standards for system configurations (e.g. NIST guidelines)
We don't have to reinvent the wheel with these. Whenever possible we should be referencing industry standards for system configurations (e.g., NIST guidelines).
 
## 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 [Baseline Configuration Standard control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/784).
 
Examples of evidence an auditor might request to satisfy this control:
* Configuration standards, guides, Chef cookbooks, and Terraform configs.
* Documentations showing the configuration standards are consistently applied.
## Framework Mapping
 
* ISO
......
......@@ -21,20 +21,25 @@ Access review is often viewed as a pain, but it's among the easiest ways to secu
 
## Scope
 
This control applies to all individuals and groups with access to the GitLab production environment. This can include access to any systems which in turn have any interaction with GitLab's production environment.
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
 
TBD
* Control Owner: `Security Operations`
* Process owner(s):
* Security Operations
* Internal Audit
 
## Guidance
 
Quarterly access reviews should be established using automation to preserve the validity of the user access list.The bulk of these reviews can be automated and only the outliers will need to be manually reviewed. The process owner should use role-based authentication whenever possible to make this control easier.
Quarterly access reviews should be established using automation to preserve the validity of the user access list. The bulk of these reviews can be automated and only the outliers will need to be manually reviewed. The process owner should use role-based authentication whenever possible to make this control easier.
 
## 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 [Logical Access Review control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/808).
 
Examples of evidence an auditor might request to satisfy this control:
## Framework Mapping
 
* ISO
......
......@@ -21,14 +21,14 @@ Having standards for security configurations and performance is useless without
 
## Scope
 
This control applies to all production systems critical to the delivery of the GitLab SaaS product.
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: `Security`
* Control Owner: `Security Operations`
* Process owner(s):
* Security: `50%`
* Infrastructure: `50%`
* Security Operations
* Infrastructure
 
## Guidance
 
......@@ -38,6 +38,13 @@ It is up to us as a company to define what criteria we use for this monitoring a
 
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 [System Security Monitoring control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/918).
 
Examples of evidence an auditor might request to satisfy this control:
* Documentation describing the monitoring of GitLab.com.
* Evidence, such as configuration files or playbooks, showing the monitoring is for predefined security criteria.
* Evidence that when alerts are trigged based on predefined security criteria, the alerts are sent to the Security team.
* Samples of issues tracking alerted security incidents through completion.
## Framework Mapping
 
* ISO
......
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