Commit 67ac1526 authored by Jeff Burrows's avatar Jeff Burrows 👶

Copied guidance from compliance repo

parent d7ed4b37
Pipeline #81912174 passed with stages
in 28 minutes and 13 seconds
......@@ -35,7 +35,16 @@ Process owner:
## Guidance
This guidance is a two-parter, provide evidence demonstrating:
* Documentation of incident response plan, including:
* Roles and responsibilities
* Specific procedures
* Business recovery and continuity procedures
* Backup processes
* Legal requirements for reporting compromises
* Coverage and responses for all critical systems
* Reference/inclusion of incident response procedures from the payment brands
* Sample of previously reported incidents documentation
## Additional control information and project tracking
......
......@@ -33,7 +33,7 @@ This control applies to all hosted systems (e.g. VM's and GCP compute services)
## 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)
## Additional control information and project tracking
......
......@@ -29,10 +29,6 @@ This control applies to all systems within our production environment.
* Process owner(s):
* Infrastructure Team: `100%`
## Guidance
## 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 [Configuration Checks control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/786).
......
......@@ -31,7 +31,7 @@ This control applies to all production systems.
## Guidance
Usually this can be automated by setting up checks that look for logs from key directories (e.g. /var/log/) or key processes (e.g. auditd) and ensuring these logs are present for all systems within the device inventory
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Tip - add task to runbook(s) to implement password change and/or validate default password has been changed upon review. This may be achievable by a Chef cookbook entry.
## Additional control information and project tracking
......
......@@ -27,10 +27,6 @@ This control applies to the GitLab.com production environment.
TBD
## Guidance
## 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).
......
......@@ -40,10 +40,6 @@ Process owner(s):
* All engineering teams: 50%
## Guidance
## 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 Approval control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/782).
......
......@@ -27,10 +27,6 @@ This control applies to GitLab's ToS.
TBD
## Guidance
## 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 [Terms of Service control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/793).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
TLS 1.2 or higher should be used to encrypt data in transit ([Deprecate support for TLS 1.0 and TLS 1.1](https://gitlab.com/gitlab-com/gl-security/engineering/issues/202)).
## Additional control information and project tracking
......
......@@ -27,10 +27,6 @@ This control applies to red, orange, and yellow data.
TBD
## Guidance
## 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 [Encryption of Data at Rest control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/797).
......
......@@ -29,10 +29,6 @@ This control applies to both electronic and physical (for example, paper printou
* Process owner(s):
* IT Ops: `100%`
## Guidance
## 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).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Provisioning should be based on predetermined roles with business justification and management approval. The process owner should use role-based authentication whenever possible to make this control easier and to segregate out this function from that of other system functions.
## Additional control information and project tracking
......
......@@ -33,10 +33,6 @@ This control applies to any system or service where user accounts can be provisi
* People Ops: `20%`
* Security: `20%`
## Guidance
## 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 De-Provisioning control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/806).
......
......@@ -29,7 +29,7 @@ TBD
## 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.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
An exception to the policy to define the types of services approved for shared accounts and a process for the lifecycle of the access and a mechanism to alert the appropriate teams that authentication credentials must be reset (e.g., email alerts, an issue, calendar event, etc).
## Additional control information and project tracking
......
......@@ -33,7 +33,7 @@ TBD
## Guidance
Review and document required accounts for a given system and disable all unnecessary accounts. Use of shared accounts should not used. If unavoidable, compensating controls should be utilized to add accountability.
## Additional control information and project tracking
......
......@@ -34,7 +34,7 @@ Process owner(s):
## Guidance
The access security user ID is most often the only basis for user authentication and authorization, so it is critical that every user has his or her own unique user ID. No two users should have the same user ID. It is vital that no two users be assigned the same user ID. If the uniqueness of user IDs is not assured, some users may be able to access information that they have not been given permission to access.
## Additional control information and project tracking
......
......@@ -28,10 +28,6 @@ This control applies to any system or service where password protection is appro
* Process owner(s):
* Security: `100%`
## Guidance
## 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 [Password Authentication control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/813).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
As the GitLab system supports the ability to restrict modification without the `Owner` approval, this should be able to demonstrate how access reviews are achieved of the `Maintainer`, `Developer`, and `Owner` roles within GitLab.com.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Identity access management systems should enforce SSH and MFA for connections to production systems and networks.
## Additional control information and project tracking
......
......@@ -27,10 +27,6 @@ This control applies to any and all cryptographic keystores.
TBD
## Guidance
## 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 [Key Repository Access control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/832).
......
......@@ -39,10 +39,6 @@ TBD
TBD
## Guidance
## 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 [Incident Response Plan control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/839).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Security incidents should have a defined process and support the ability to be tracked and managed for resolution.
## Additional control information and project tracking
......
......@@ -37,7 +37,7 @@ TBD
## Guidance
Provide evidence that demonstrates we follow the documented communication of the GitLab incident response plan.
## Additional control information and project tracking
......
......@@ -30,10 +30,6 @@ TBD
TBD
## Guidance
## 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 [Incident Reporting Contact Information control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/843).
......
......@@ -32,7 +32,7 @@ TBD
## Guidance
Provide a copy of external communication from an incident in the past 12 months. If there wasn't an incident, provide evidence that we did not have an incident.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Control should be designed to ensure we don't default to "allow all" traffic and instead put in place reasonable barriers for access to our production network.
## Additional control information and project tracking
......
......@@ -31,7 +31,7 @@ The GitLab Candidate Experience team manages the background process and retains
## Guidance
The scope of the background check performed is at the discretion of the Company. This control merely states that we apply this control to all GitLabbers without a documented reason why a background check can't be performed per local law.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
A process to evaluate the performance of team-members.
## Additional control information and project tracking
......
......@@ -32,10 +32,6 @@ TBD
* Security Compliance: `20%`
* Security: `20%`
## Guidance
## 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 [Risk Assessment control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/866).
......
......@@ -30,10 +30,6 @@ This control applies to all GitLab applications and services.
* Security: `70%`
* Security Compliance:`30%`
## Guidance
## 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 [Service Risk Rating Assignment control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/869).
......
......@@ -31,7 +31,7 @@ Internal audits are performed against all GitLab production systems and all proc
## Guidance
Internal audits should be a process that all GitLabbers feel comfortable being transparent about how the related process is working and what the outcome of that process is. Full transparency in an internal audit can help ensure all processes are effective prior to an external audit.
## Additional control information and project tracking
......
......@@ -30,10 +30,6 @@ This control applies to all risk assessments and their respective risk findings.
* Security: `70%`
* Security Compliance:`30%`
## Guidance
## 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 [Remediation Tracking control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/871).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
The most common form of system documentation is network and data flow diagrams.
## Additional control information and project tracking
......
......@@ -35,7 +35,7 @@ Process Owner:
## Guidance
Create process to have policies and standards reviewed and updated on a recurring, annual basis.
## Additional control information and project tracking
......
......@@ -27,10 +27,6 @@ TBD
GitLab's Director of Security
## Guidance
## 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 [Information Security Program Content control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/877).
......
......@@ -35,7 +35,9 @@ GitLab Security has 100% ownership over this control
## Guidance
1. An enhanced Security Governance is the key to GitLab's security posture. Also per the Federal Information Security Management Act (FISMA) and the National Institute of Standards and Technology (NIST) publication mandates that all employees and contractors fulfilling roles with significant information security responsibilities should understand their role and have the capacity to carry out these responsibilities.
1. Pursuant to this requirement, GitLab security has developed a handbook page defining each role and outlining necessary responsibilities to ensure the confidentiality, integrity, and availability of Gitlab’s information and information systems.
1. This section provides roles and responsibilities for personnel who have IT security or related governance responsibility for protecting the information and information systems they operate, manage and support.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Most of this process is already captured in current GitLab workflow; the difficult part of this process will be 100% coverage of all software changes.
## Additional control information and project tracking
......
......@@ -47,7 +47,7 @@ Process Owners:
## Guidance
Server configuration standards should have logging information enabled for each type of system.
## Additional control information and project tracking
......
......@@ -31,7 +31,7 @@ This control applies to all production systems in the device inventory.
## Guidance
The bulk of this reconciliation can be automated and the unmatched results can be manually reviewed.
## Additional control information and project tracking
......
......@@ -38,10 +38,6 @@ This control is not applicable to GitLab's SaaS product since managed hosting is
* Security: `70%`
* Infrastructure: `30%`
## Guidance
## 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 [Provisioning Physical Access control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/912).
......
......@@ -32,7 +32,7 @@ This control applies to all production systems critical to the delivery of the G
## Guidance
It is up to us as a company to define what criteria we use for this monitoring and how an incident is defined. This control simply holds GitLab accountable for fully monitoring systems and managing resulting incidents.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
This control is not meant to dictate what criteria we use for our availability monitoring; this control only requires us to formally define what our alerting criteria is.
## Additional control information and project tracking
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Tools like Splunk are perfect for automating these types of controls.
## Additional control information and project tracking
......
......@@ -37,7 +37,8 @@ Process Owner:
## Guidance
* The easiest way to satisfy this control is to review all third party provider SOC2 Type 2 reports for appropriate scope and efficacy of controls.
* If a SOC2 Type 2 report is not available, we can send these third party providers a GitLab security questionnaire to gather the necessary information about the security controls they have in place and the approximate state of maturity of that third party provider.
## Additional control information and project tracking
......
......@@ -35,7 +35,7 @@ Process Owner:
## Guidance
The GitLab Data Classification Policy defines the categories of data. This risk assessment process is most easily achieved by reviewing the SOC2 Type 2 audit report for any managed service providers if available. When a SOC2 Type 2 report is not available, a GitLab security questionnaire would serve as a good substitute.
## Additional control information and project tracking
......
......@@ -33,10 +33,6 @@ Process Owner:
* Security Compliance
## Guidance
## 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 [Vendor Compliance Monitoring control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/925).
......
......@@ -35,7 +35,7 @@ Process Owner:
## Guidance
Maintain current copies of non-disclosure agreements between GitLab and vendors for each non-GitLab service used by the company whwere confidential inforamtion is shared with the vendor.
## Additional control information and project tracking
......
......@@ -40,7 +40,7 @@ Process Owner:
## Guidance
From the beginning of the relationship with the service provider, clearly document what service is being provided and what, if any, data is shared. Each service provider should provide an Attestation of Compliance to be included as evidence (AOC) each year (dated within 1 year of provided evidence date)
## Additional control information and project tracking
......
......@@ -30,10 +30,6 @@ This control applies to all GitLab team-members.
* The GitLab compliance team is responsible for validating that every GitLaber has completed training in the last year.
* All GitLab team-members are responsible for completing their security awareness training.
## Guidance
## 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 [General Security Awareness Training control issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/931).
......
......@@ -29,7 +29,7 @@ TBD
## Guidance
Pending additional input, we might be able to use the onboarding issues, which require new Gitlabbers to sign off on having read the GitLab handbook as evidence of this code of conduct training since there is plenty of information about our values and how Gitlabbers are expected to behave.
## Additional control information and projec