-[Observation management for control failures and Tier 3 (system-level) risks](/handbook/security/security-assurance/observation-management-procedure/)
-[GitLab Production Readiness: Compliance Assessment](/handbook/security/security-assurance/production-readiness-compliance-assessment/)
-[Security Assurance System Intake](/handbook/security/security-assurance/security-compliance/sec-controls.md)
## <i id="biz-tech-icons" class="far fa-newspaper"></i> Core Tools and Systems
The Compliance Production Readiness Assessment is a process designed to make it clear what obligations systems owners have for configuring and hardening a system/tool/service in order for GitLab to meet its compliance and regulatory obligations.
## Scope
This Compliance Production Readiness Assessment process applies to new systems/tools/services or any existing system/tool/service that is processing new data or existing data in a different way that might change the compliance and regulatory obligations.
An example of a scope change would be a system like Calendly that might only be processing Yellow data today but due to a new feature is now processing Orange data. This new type of data being ingested into such a system would change the security control requirements and would required increased support from the system owner to help ensure these controls are operating effectively.
## Process
1. If you have a new system that you're thinking about onboarding or an existing system that will change the type of data being processed or a system that is connecting to a new system, start by [opening a Security Compliance intake issue](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/security-compliance-intake/-/issues/new?issuable_template=intakeform) and include the system name, data types (old and new), and system connection information. This will kick off a triage process by the Security Risk team to gather additional information.
1. Security Risk and Security Compliance will work together to determine what security controls will need to be tested and when. System owners and relevant stakeholders will be notified about these requirements
1. Testing will be scheduled based on capacity and priority and will follow the [GCF Security Control Lifecycle](/handbook/security/security-assurance/security-compliance/security-control-lifecycle/)
1. Testing will result in a system health rating and testing observations/findings (if applicable) which will be communicated out to system owners and relevant stakeholders.
## Questions about this process
Please reach out to the Security Compliance team using the `@sec-compliance-team` tag in the [#sec-assurance slack channel](https://gitlab.slack.com/archives/C0129P7DW75) and we can work with any questions you have about this process.
## FAQ
1. I'm just testing something with production data but don't plan to keep the data here long term. Do I need to engage with the above process?
- Yes. We have contractual obligations to our customers and the scope fo our external security audits change when we store RED data in a new location regardless of how long the data will exist there.
1. I have a system processing RED data, but I have never had to engage with the above process. Do I need to do anything?
- Yes. This might be an indication that the Security Compliance teams aren't aware of this new environment which means we will need to test the system as soon as possible.
1. I am working on a demo of a tool and we are going to use actual data, but I haven't signed a contract yet. What do I need to do?
- Open an issue according to the above process. Our processes are based on the type of data being used on not whether or not we're paying for a service.
1. I have a new system that will be processing [RED data](/handbook/security/policies_and_standards/data-classification-standard/) or an existing system that will now be processing RED data. What requirements are there for me as a system owner?
- Open an issue according to the above process and work with Security Compliance to provide evidence and system context so we can understand the compliance or regulatory requirements.
1. Same as above for ORANGE Data
- Same requirements as RED data to start the intake process.
1. Same as above for YELLOW Data
- Same requirements as RED data to start the intake process.
1. Same as above for GREEN Data
- Same requirements as RED data to start the intake process
@@ -27,7 +27,7 @@ GitLab's user access review is an important control activity required for intern
Security Compliance performs Access Reviews for in-scope systems based on a subset of factors. Including:
1. Orgin: External certification impact, Red Data System
1. Origin: External certification impact, Red Data System
2. Criticality: Mission Critical
3. Business Critical if Lumos connector available
@@ -41,8 +41,8 @@ Systems that fall outside of the threshold of the above in-scope system factors.
| Role | Responsibility |
| :---: | :---: |
| Security Compliance Team | *Execution of Full Entitlement Review, Privilaged Access, Terminated User Reviews<br><br>* Creation of observations and oversight of remediation activities for any identified findings|
| IT Compliance Team | *Execution of Full Entitlement Review, Privilaged Access, Terminated User Reviews for SOX in-scope systems<br><br>* Creation of observations and oversight of remediation activities for any identified findings|
| Security Compliance Team | *Execution of Full Entitlement Review, Privileged Access, Terminated User Reviews<br><br>* Creation of observations and oversight of remediation activities for any identified findings|
| IT Compliance Team | *Execution of Full Entitlement Review, Privileged Access, Terminated User Reviews for SOX in-scope systems<br><br>* Creation of observations and oversight of remediation activities for any identified findings|
| System Owners | *Validation of privileged entitlements<br><br>* Validation of user entitlements<br><br>*Timely evidence support <br><br>* Execution of remediation plans for identified observations<br><br>* Execution of access removal(s)|
| System Administrators | *Validation of privileged entitlements<br><br>* Validation of user entitlements<br><br>*Timely evidence support <br><br>* Execution of remediation plans for identified observations<br><br>* Execution of access removal(s)|
| Managers | *Support validation of privileged entitlements<br><br>* Support validation of user entitlements|
@@ -59,9 +59,9 @@ Systems that fall outside of the threshold of the above in-scope system factors.
- The current access listings of systems is correlated against a list of active team members derived from Workday (GitLab's source of truth for employment status) using GitLab's User Access Review tool [Lumos](/handbook/security/security-assurance/). If any users are found to have active system access that are not current GitLab team members, open access removal issues to start the access de-provisioning process.
**Entitlement/Privilaged Access**
**Entitlement/Privileged Access**
- Access for systems will be reviewed based on the job roles and departments via GitLab's User Access Review tool, Lumos. Depending on the user base size and scope of users with access, a system owner and/or manager will be involved in reviewing user entitlements. System owners should have detailed knowledge of which roles/deparments should have access to their system. For detailed instructions on how to complete a user access review via Lumos see the [Lumos review handbook page here](../../corporate/systems/lumos/access_reviews/_index.md).
- Access for systems will be reviewed based on the job roles and departments in GitLab's User Access Review tool, Lumos. Depending on the user base size and scope of users with access, a system owner and/or manager will be involved in reviewing user entitlements. System owners should have detailed knowledge of which roles/deparments should have access to their system. For detailed instructions on how to complete a user access review via Lumos see the [Lumos review handbook page here](../../corporate/systems/lumos/access_reviews/_index.md).
### Access Review runbook
@@ -82,7 +82,7 @@ If you have any questions or require assistance with completing an access review
### Access Removals
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](/handbook/security/security-assurance/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. The Security Compliance team is not responsible nor has the ability to remove access. Security Compliaces role and responsiblity is limited to opening access removal issues and assigning those issues out to the appropriate System Owner(s) and/or the IT Operations team. System Owners and/or IT Operations is responsible for execution of access removal or adjustment. Communication of the access removal or adjustment for affected team members is at the discretion of the system owner/reviewer.
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](/handbook/security/security-assurance/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 access to GitLab systems that has not been validated. The Security Compliance team is not responsible nor has the ability to remove access. Security Compliace's role and responsibility is limited to opening access removal issues and assigning those issues out to the appropriate System Owner(s) and/or the IT Operations team. System Owners and/or IT Operations is responsible for execution of access removal or adjustment. Communication of the access removal or adjustment for affected team members is at the discretion of the system owner/reviewer.
## Additional Guidance
@@ -101,22 +101,22 @@ Example scenarios where a lookback may be required:
- A team member was identified as having a role in a system which conflicted with their job responsibilities and their access in other systems allowing them to circumvent established control points and processes, a lookback would be performed to validate the user didn't use their access to circumvent established processes and controls in place.
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.
Engage the appropriate personnel (typically, the 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:
- A person transferred between non-conflicting departments, continued to support their previous role during transition, and the access review is a chance to remove the access now that the transition is complete
- A role is being removed as the access granted by that role is duplicative to access granted as part of another role that will remain
- A user no longer uses the access that they have to a system but the access isn't a risk for the user to have and could be reinstated via an Access Request if a need for the access ever arises again
- A user no longer uses the access that they have to a system but the access isn't a risk for the user to have and could be reinstated by opening an Access Request if a need for the access ever arises again
- A team of 4 users have the same access to a system but usage is minimal. To free up licenses and maintain an environment of least privilege, access for 3 of the users is requested for removal.
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.)
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, including reviews of key transactions or similar reviews.
Evidence of the completed lookback review should be retained and documented within the access review workbook or other associated documentation.
### Validation of Modifications completed
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).
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. This can be demonstrated by screenshot, updated user listing that reflects changes made, or similar evidence.
### Access Review Notification Reminders
@@ -171,4 +171,4 @@ Exceptions to this procedure will be tracked as per the [Information Security Po
@@ -20,7 +20,7 @@ The scope of gap analysis procedures performed by the Security Compliance team a
| Role | Responsibility|
| ---- | ------ |
| Gap Analysis Owner | The individual Security Compliance team member responsible for being the gap analysis DRI through the analysis lifecycle, performing the gap analysis, and mapping/formalizing controls to address the identified gaps. |
| Gap Analysis Requestor | The individual GitLab team member who requests the performance of a gap analysis. Any GitLab team member can request a gap analysis from the Security Compliance team. |
| Gap Analysis Requester | The individual GitLab team member who requests the performance of a gap analysis. Any GitLab team member can request a gap analysis from the Security Compliance team. |
| Gap Analysis Program DRI | Responsible for regular reviews of program health and stakeholder report delivery |
## Gap Analysis Phases Overview
@@ -33,7 +33,7 @@ graph TD;
B --> D[Requested Framework Already Evaluated];
F --> G[Gaps Identified];
F --> H[No Gaps, GitLab Aligns To Standard]
G --> I[Report Findings To Management & Requestor]
G --> I[Report Findings To Management & Requester]
H --> I
```
@@ -43,15 +43,15 @@ The following phases walk through the gap analysis lifecycle.
### Gap Analysis Requested
Gap analysis requests can be submitted to the Security Compliance team by any GitLab team member. In order to submit a gap analysis request, [submit an issue to the Gap Analysis Project](https://gitlab.com/gitlab-com/gl-security/security-assurance/team-commercial-compliance/gap-analysis/-/issues/new?issuable_template=GapAnalysisRequest) utilizing the 'GapAnalysisRequest' Issue Template. The Security Compliance team will review all submitted Gap Analysis requests and begin the process of prioritizing the gap analysis. If the requested framework has already been assessed, the Gap Analysis Owner will notify the Gap Analysis Requestor and provide them the relevant details over the performed gap analysis. Once the gap analysis request has been reviewed and prioritized, the Gap Analysis DRI will notify the requestor in the submitted request issue of their request status in the overall gap analysis queue.
Gap analysis requests can be submitted to the Security Compliance team by any GitLab team member. In order to submit a gap analysis request, [submit an issue to the Gap Analysis Project](https://gitlab.com/gitlab-com/gl-security/security-assurance/team-commercial-compliance/gap-analysis/-/issues/new?issuable_template=GapAnalysisRequest) utilizing the 'GapAnalysisRequest' Issue Template. The Security Compliance team will review all submitted Gap Analysis requests and begin the process of prioritizing the gap analysis. If the requested framework has already been assessed, the Gap Analysis Owner will notify the Gap Analysis Requester and provide them the relevant details over the performed gap analysis. Once the gap analysis request has been reviewed and prioritized, the Gap Analysis DRI will notify the requester in the submitted request issue of their request status in the overall gap analysis queue.
### Performing The Gap Analysis
Once the gap analysis request has been received, a member of the Security Compliance team will use GAS to manage/perform the gap analysis which involves identifying control gaps, mapping existing controls to the requested frameworks requirements, and evaluating the mapped/created controls for their design and operating effectiveness via the [Control Assessment Guide](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/gcf/-/blob/main/runbooks/assessment_testing_manual.md). Refer to this [Gap Analysis Runbook](https://gitlab.com/gitlab-com/gl-security/security-assurance/team-commercial-compliance/gap-analysis/-/blob/main/runbooks/Gap_Assessment_Manual.md) for further details over how the Security Compliance team performs a gap analysis.
Once the gap analysis request has been received, a member of the Security Compliance team will use GAS to manage/perform the gap analysis which involves identifying control gaps, mapping existing controls to the requested frameworks requirements, and evaluating the mapped/created controls for their design and operating effectiveness using the [Control Assessment Guide](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/gcf/-/blob/main/runbooks/assessment_testing_manual.md). Refer to this [Gap Analysis Runbook](https://gitlab.com/gitlab-com/gl-security/security-assurance/team-commercial-compliance/gap-analysis/-/blob/main/runbooks/Gap_Assessment_Manual.md) for further details over how the Security Compliance team performs a gap analysis.
### Reporting Gap Analysis Results
Once the gap analysis has been completed and all relevant gaps identified, the Gap Analysis Owner will create a [Gap Analysis Audit Report](https://docs.google.com/presentation/d/1XB8cVvE7weZZuXSaXuX-dlcsyd0bRnI10pG1m7WJEJY/edit#slide=id.p1) outlining the results of the analysis, the identified gaps/observations, and the recommendations for observation closing and new policy/procedure/control formalization. Once the Gap Analysis Audit Report has been reviewed and approved by the Security Compliance Manager and Director of Security Assurance, the Gap Analysis Owner will begin the process of assigning the identified observations in existing controls that map to the assessed framework to relevant stakeholders for remediation via the [Observation Intake and Management](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/observation-management/-/blob/master/runbooks/1_Observation%20Intake%20and%20Management.md) procedure as well as begin the process of formalizing any new policies/procedures/controls that close the identified gaps. Additionally, it is possible that during the performance of the gap analysis, it is determined that GitLab is already aligned with the standard/framework that is being assessed. In such cases, this will be reported in the [Gap Analysis Audit Report](https://docs.google.com/presentation/d/1XB8cVvE7weZZuXSaXuX-dlcsyd0bRnI10pG1m7WJEJY/edit#slide=id.p1) which will be made available to management and the gap analysis requestor.
Once the gap analysis has been completed and all relevant gaps identified, the Gap Analysis Owner will create a [Gap Analysis Audit Report](https://docs.google.com/presentation/d/1XB8cVvE7weZZuXSaXuX-dlcsyd0bRnI10pG1m7WJEJY/edit#slide=id.p1) outlining the results of the analysis, the identified gaps/observations, and the recommendations for observation closing and new policy/procedure/control formalization. Once the Gap Analysis Audit Report has been reviewed and approved by the Security Compliance Manager and Director of Security Assurance, the Gap Analysis Owner will begin the process of assigning the identified observations in existing controls that map to the assessed framework to relevant stakeholders for remediation following the [Observation Intake and Management](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/observation-management/-/blob/master/runbooks/1_Observation%20Intake%20and%20Management.md) procedure as well as begin the process of formalizing any new policies/procedures/controls that close the identified gaps. Additionally, it is possible that during the performance of the gap analysis, it is determined that GitLab is already aligned with the standard/framework that is being assessed. In such cases, this will be reported in the [Gap Analysis Audit Report](https://docs.google.com/presentation/d/1XB8cVvE7weZZuXSaXuX-dlcsyd0bRnI10pG1m7WJEJY/edit#slide=id.p1) which will be made available to management and the gap analysis requester.
## SLA/Prioritization
@@ -66,11 +66,11 @@ Gap analysis requests will be prioritized by the Gap Analysis Program DRI with a
If you have any questions or feedback about the security compliance gap analysis process please [contact the GitLab security compliance team](_index.md).
<ahref="/handbook/security/security-assurance/"class="btn bg-primary text-white btn-lg">Return to the Field Security Homepage</a>
<ahref="/handbook/security/security-assurance/"class="btn bg-primary text-white btn-lg">Return to the Security Assurance Homepage</a>
