This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
GitLab's user access review is an important control activity required for internal and external IT audits, helping to minimize threats and provide assurance that the right people have the right access to critical systems and infrastructure. This procedure details process steps and provides control owner guidance for access reviews.
Security Compliance performs Access Reviews for Tier 1 and Tier 2 systems in scope for our compliance and regulatory programs. See the tech stack for the current listing of Tier 1 and Tier 2 systems.
Tier 3 applications as defined in the tech stack are not in scope, however, all system owners are highly encouraged to perform a minimum of an annual terminated access review for their owned systems using this process as a guide.
| Role | Responsibility |
|---|---|
| Security Compliance Team | * Execution of entitlement reviews * Execution of terminated user access reviews * Creation of observations and oversight of remediation activities for any identified findings |
| System Owners | * Validation of privileged entitlements * Validation of user entitlements * Timely evidence support * Execution of remediation plans for identified observations |
| Managers | * Support validation of privileged entitlements * Support validation of user entitlements |
| Security Assurance Management (Code Owners) | Responsible for approving significant changes and exceptions to this procedure |
Authomize is GitLab's User Access Review tool. It is used to facilitate all user access reviews. By default, all team members will receive access to Authomize upon onboarding. To access Authomize, team members can select the Authomize tile in Okta. If you are assigned an access review, please follow the runbook linked below to complete the access review.
Terminated Users
Entitlement
The Authomize review runbook here provides the outline to complete these access reviews, including how to confirm least privilege.
In the event access is identified to no longer be required, open an Access Removal issue for each account that no longer requires access and relate it to the system access review issue.
If you have any questions or require assistance with completing an access review, please contact the GitLab Security Compliance team.
All components of a user access review must be completed within the time period under audit. For example, if a user access review is scheduled for Q2, all components of the review including any required actions for modification/removal and lookbacks must be completed by the end of the quarter. It would not be sufficient to have outstanding requests for modification/removal at the quarter end, regardless of the users being identified for modification/removal prior to quarter end.
The determination and tracking of systems ranked by tiers 1-4 are managed in the GitLab Critical Systems Inventory and is the SSOT of which systems require UARs and should always be referenced when in doubt.
If appropriateness of access cannot be verified as part of the review or a system owner/reviewer flags a user for removal, a validation will take place with the team member’s manager prior to access removal as per the Observation Management Procedure. This validation must take place within 7 calendar days and if access is determined to not be required OR no agreement can be reached within that SLA between the Manager and system owner/reviewer, access will be removed. If the risk associated with unvalidated access is too high, access will be revoked immediately and impacted users will be directed towards the new access request process for re-provisioning. While we want to avoid disruption in access whenever possible, we need to balance the impact of that disruption with the risk of continued and unvalidated access to GitLab systems.
For any accounts that require any removal of access (full removal or individual roles/privileges), a lookback review may be required. A lookback review is a review of activity for the period of time which the access was inappropriate.
Example scenarios where a lookback may be required:
In cases where there is a disagreement between system owner and manager as to whether a lookback is required, it should be completed. Engage the appropriate personnel (i.e system owner) to perform a lookback assessment to validate the account(s) did not use the access inappropriately.
It may not be necessary to perform a lookback in all cases, for example:
The most simple method to perform a lookback for users is to review their last login date/time and validate it was not after the date access was no longer appropriate. If a last login shows the account did authenticate after the access was inappropriate, a full review should be performed to determine any activity from the account during that time to validate no risk. If a last login is not available, other validations should be performed to confirm the account was not used inappropriately after termination (i.e review of key transactions etc.)
Evidence of the completed lookback review should be retained and documented within the access review workbook or other associated documentation.
For any accounts that are requested for modification or removal, validation they were modified as requested should be completed and evidence captured of their successful modification (i.e screenshot, updated user listing that reflects changes made).
Security Compliance managed access reviews required for audit evidence have a deadline of 10 business days from the launch of the review in Authomize. Automated reminders will be used based on number of days out from the due date:
| Days until Due Date | Notification | Who is Notified |
|---|---|---|
| 5 | Authomize "nudge" | Reviewer |
| 3 | Slack ping | Reviewer |
| 2 | Authomize "nudge" & Slack ping the Reviewer |
Reviewer, Reviewer's Manager, and Security Compliance Manager |
| 0 | Escalated to VP of Security | VP of Security |
{-If an access review is not completed within 10 days, identified access will be removed.-}
Based on how the system access is maintained will determine the method of account and related permissions export for access review. This will most likely fall to the business or technical owner identified in the Tech Stack Applications.
The following fields are the most comprehensive to assist in performing a thorough access review: (all are helpful, but all might not be available)
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.
