GitLab's compliance management capabilities are designed to integrate compliance into development and deployment processes from the start. As a tenured compliance professional and member of our Security Compliance team here at GitLab, I can tell you from experience it is always easiest to design your processes to be secure and compliant from the start than it is to re-engineer existing processes to be compliant.
Why should you care about your GitLab instance being secure and compliant?
In additon to reducing the risk of a breach and lowering costs, there are regulatory and compliance requirements to consider.
Typically regulatory and compliance audits are unavoidable and can be time-consuming and stressful. However, GitLab has many easy-to-use, built-in features that may help fulfill your organization's compliance requirements and make your environment more secure. Here at GitLab, these are features we use everyday. The best part is, most of the features I'll outline below are included as free features.
Note: I'll add an asterisk (*) next to any feature which is not available on our free tier.
Here's the tl;dr list:
- Enable Multi-Factor Authentication (MFA)
- Review privileged access for critical projects
- Turn on protected branches
- Activate merge request approval settings
- Configure audit events
1. Enable MFA
Enabling MFA is simple and reduces the risk of attacks by making it more difficult to gain access to accounts.
MFA can be enforced for all users in your GitLab instance in the admin center. Alternatively, MFA can be configured for accounts individually.
You can learn how to enable MFA in our GitLab documentation.
Compliance standards and GitLab controls for MFA
MFA relates to the following compliance standards:
- AICPA TSC CC6.1
- ISO 27001 2013 A9.2.3, A9.2.4, A.9.3.1, A9.4.3
- NIST 800-53 IA-5, IA-5(1), IA-2(1), IA-2(2)
Illustrative GitLab controls for MFA:
- IAC-02: GitLab Inc. has implemented mechanisms to uniquely identify and authenticate organizational users and processes acting on behalf of organizational users.
- IAC-06: GitLab Inc. has implemented automated mechanisms to enforce MFA for: remote network access; and/or non-console access to critical systems or systems that store, transmit and/or process sensitive data.
2. Review privileged access for critical projects
Undoubtedly, one of the biggest risks to your environment is logical access. To reduce the risk, we recommend administrators ensure access is restricted based on the principle of least privilege. Access should be monitored continuously as access changes can occur multiple times, daily, in most organizations. In order to appropriately review access in your GitLab instance, it is important to first understand the access security structure within GitLab.
Breaking down the access security structure
Within GitLab, there are six different roles that can be assigned to users - “Guest”, “Reporter”, “Developer”, “Maintainer”, “Owner” and “Administrator”. Privileged access within GitLab is considered to be the “Administrator”, “Owners”, and “Maintainers” roles.
GitLab Administrators receive all permissions
Owners and Maintainers are considered administrative because these roles have permissions to do highly sensitive actions including but not limited to: managing merge settings; enabling or disabling branch protection; managing access to a project; managing access tokens; exporting a project; and deleting issues, merge requests, and projects.
As privileged access is the highest risk to your environment, these roles should be tightly controlled.
Some best practices in regards to ensuring access is restricted based on the principle of least privilege include:
- When privileged access is requested, ensure appropriate approvals are received prior to access being provisioned. Best practice is to obtain approvals from the data owner and the manager of the user who's receiving access.
- When a user changes job responsibilities or leaves the organization, ensure access is deprovisioned timely and any shared passwords or tokens are rotated. Best practice is to do this within 72 hours or less.
- Be sure to review access on a periodic basis to ensure access is still appropriately aligned to a user's job responsibilities. Best practice is to do this on a quarterly basis and have access reviewed by the data owner.
What to do when you identify inappropriate access
When inappropriate access is identified, it is important to take immediate, mitigating actions by checking the user's last login date and checking audit logs as they are available to ensure no inappropriate transactions were performed. These mitigating actions should be conducted upon identification to ensure accessibility of information and to understand potential exposure.
Refer to our GitLab documentation regarding permissions and roles for more information.
Compliance standards and GitLab controls for privileged access
Privileged access relates to the following compliance standards:
- AICPA TSC CC6.1, CC6.2, CC6.3
- ISO 27001 2013 A9.2.1, A9.2.2, A9.2.3, A9.4.4
- NIST 800-53 IA-12(4)
Illustrative GitLab controls for privileged access:
- IAC-07: GitLab Inc. has implemented mechanisms to utilize a formal user registration and de-registration process that governs the assignment of access rights.
- IAC-16: GitLab Inc. has implemented mechanisms to restrict and control privileged access rights for users and services.
- IAC-17: GitLab Inc. has implemented mechanisms to periodically review the privileges assigned to users to validate the need for such privileges; and reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.
3. Turn on protected branches
Within GitLab, role-based access can be used to give access to repositories and branches at the project level. By utilizing protected branches, further restrictions can be configured on certain branches in order to protect them. Protecting your default branch is the most important; this branch is often called "master" or "main".
Some best practice in regards to protection rules include:
- Prevent commits directly into the default branch
- Require a merge request each time there is a commit
- Require approval by a codeowner before merging code
Protected branches should be configured in accordance with your organization's change management policy. Here's an example of how to configure protection rules according to our recommendations:
Example of how to configure branch protection rules
This example shows that anyone with the “developer” and “maintainer” roles are allowed to merge to the default branch and “no one” is allowed to push directly to the default branch without a merge request. Further, codeowner approval must be obtained prior to merging.
Protected branches can be modified by anyone with at least “maintainer” access. In order to monitor if protected branch settings are inappropriately modified, administrators should consider implementing a monitoring control by utilizing audit events.
Refer to our GitLab documentation regarding protected branches for more information.
Compliance standards and GitLab controls for branch protection
Branch protection settings relate to the following compliance standards:
- COSO Principle 9
- AICPA TSC CC3.4, CC8.1
- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9
- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6
Illustrative GitLab controls for branch protection settings include:
- CHG-04: GitLab Inc. has implemented mechanisms to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.
4. Activate merge request approval settings *
Changes to your project repository typically start with a merge request. If your default branch is protected, commits must be done through a merge request. By configuring your merge request settings with approval rules ensures that changes are properly approved prior to deployment to production. Within the merge request approval settings you can specify the number of approvals required and the allowed approvers for specific merge requests.
In addition, there are a number of approval settings that further enforce segregation of duties within change management:
- Prevent approval by author: When enabled, the author cannot also provide one of the required approvals.
- Prevent approvals by users who add commits: When enabled, users who have committed to a merge request cannot also approve it.
- Prevent editing approval rules in merge requests: When enabled, users can’t override the project’s approval rules on merge requests.
- Require user password to approve: When enabled, users must first authenticate with a password prior to submitting approval.
- Remove all approvals when commits are added to the source branch: When enabled, this removes all existing approvals on a merge request when more changes are added to it.
Merge request approval settings should be configured in accordance with your organization's change management policy. An example of how to configure merge requests according to the best practices outlined above is as follows:
Example of how to configure merge requests
In the example above, you can see that at least two approvers are required: to enforce segregation of duties and that the approval settings are enforced.
If your change management policy requires approvals from different groups or departments, such as the business owner and the data owner, those approval groups can be added as additional approval rules. When enabled, these settings provide reasonable assurance that your organization’s GitLab instance enforces segregation of duties and systematically enforces your organizational change management policy.
To ensure all projects under a certain group have the same merge request approval settings, at the top-level group, group approval settings can be configured. These settings cascade to all projects that belong to the group.
Merge request approval settings can be modified by anyone with at least “maintainer” access. In order to monitor if merge request approval settings are inappropriately modified, consider implementing a monitoring control by utilizing audit events.
For more information, refer to our GitLab documentation around merge request approvals and settings.
Compliance standards and GitLab controls for merge approvals
Merge approval settings relate to the following compliance standards:
- COSO Principle 9
- AICPA TSC CC3.4, CC8.1
- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9,
- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6
Illustrative GitLab controls for merge approval settings include:
- CHG-04: GitLab Inc. has implemented mechanisms to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.
5. Configure audit events *
Audit events are a way to view changes made within GitLab and can be leveraged as a detective and monitoring control for continuous monitoring of configured settings. A report can be generated on the audit event, which can then be provided to auditors to evidence your company’s compliance for the audit period for a specific, configured setting.
Audit events can be configured at the group, project and instance level.
It is best practice to monitor the following audit events in your GitLab environment:
- merge approval settings
- protected branch settings
As previously mentioned, merge approval settings and protected branch settings can be modified by anyone with “maintainer” access. By monitoring these critical settings for audit events, it can be determined if the protected branch settings or merge approval settings were modified during the period. If the settings were modified, investigation can occur to understand the potential impact and be an indicator to turn the setting back on.
Here’s an example of what these audit events look like:
Example of audit events
In this example of audit events, we see the following:
- The merge approval settings “require new approvals when new commits are added to an MR” was turned off on the project.
- The number of required approvals was reduced from 2 to 1.
- Merging is now allowed by anyone on the default branch. These changes would alter the protected branch settings and merge approval settings that were previously configured.
Audit events can be streamed to third-party systems. The advantage of this is to integrate into a security information and event management (SIEM) system for centralized monitoring and alerting.
To learn more, check out the GitLab documentation surrounding audit events.
Compliance standards and GitLab controls for audit events
Audit events relate to the following compliance standards:
- COSO Principle 13
- AICPA TSC CC4.1, CC7.2
- ISO 27001 2013 A12.4.1, A12.4.3
- NIST 800-53 AU-2
Illustrative GitLab controls for audit events:
- CHG-07: Audit events are reviewed quarterly to ensure no inappropriate changes to key change management Segregation Of Duties (SOD) settings.
- MON-03: Configure systems to produce audit records that contain sufficient information to, at a minimum: establish what type of event occurred; when (date and time) the event occurred; where the event occurred; the source of the event; the outcome (success or failure) of the event; and the identity of any user/subject associated with the event.
How does GitLab help you maintain your compliance? Have a favorite feature that helps your org maintain its compliance that we missed, let us know in the comments!
Interested in learning more about how your organization can leverage the compliance features offered within GitLab? Connect with a specialist to learn more.
Note: An asterisk (*) denotes a feature which is not available on our free tier.
Cover image by Miguel Á. Padriñán on Pexels
