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
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
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
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
# 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)
## 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)
# 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) .
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) .
