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.
The purpose of the Security Operational Risk Management (“StORM”) program at GitLab is to identify, monitor, treat and report upon security operational risks in support of GitLab's strategy. The Security Risk Team utilizes the procedures below to ensure that security risks that may impact GitLab's ability to achieve its customer commitments and operational objectives are effectively managed.
The scope of the StORM program is limited to operational (also referred to as Tier 2) risks as defined in the NIST SP 800-30 Rev. 1 risk management hierarchy. These risks are generally identified during the Annual Risk Assessment(ARA) or Ad-Hoc reports.
Out of Scope Tier 2 risks such as operational risks that are not security-related are out of scope (accounting related risks, for example). Tier 3 Risks identified by teams across the organization are considered by Security Risk when scoring and/or treating their associated Tier 2 risk (where applicable). Security Risk does not directly facilitate the treatment of Tier 3 risks but may effectively do so through the treatment of a Tier 3 risk's associated Tier 2 risk. [Tier 1 risks] or enterprise risks are managed as part of our Enterprise Risk Management Program and examples can be found on our Mitigating Concerns handbook page.
A risk governance structure has been put in place to outline the overall roles and responsibilities of individuals as it relates to StORM. The current governance structure is:
| Role | Responsibility |
|---|---|
| Risk Owners | - Makes decisions for their specific organizations - Provides insight into the day-to-day operational procedures executed by their organization in support of Risk Treatment planning - Responsible for driving risk acceptance and/or implementing remediation activities over the risks identified |
| Security Risk Team | - Coordinates and executes the annual risk assessment - Maintains the risk register to ensure accuracy and currency - Acts in a Program Management capacity to support the tracking of risk treatment activities - Coordinates peer validation testing after all risk remediation activities have been completed - Periodically reports on the status of security operational risks |
| Risk Manager | This role is assigned per risk to a specific Security Risk team member. Expectations include: - Maintains knowledge on the history, current-state, and direction of their risk - Works with the risk owner or owners to ensure the risk and remediation activity is accurately captured - Identifies and monitors associated issues/MRs/epics/working groups that are relevant to their assigned risk - Validates remediation activity |
| Manager of Security Risk Team | Provides management level oversight of the StORM program, including continuing reviews of GitLab's Risk Register and acts as a point of escalation as needed |
| Senior Director of Security Assurance | Provides senior leadership level oversight of the StORM program, including a review and approval of the annual risk assessment report |
| CISO | Executive sponsor of StORM program, performs a final review and approval of the annual risk assessment report |
| Senior Leadership | Sets the tone of the risk appetite across the organization * Leverages information derived from StORM to make strategic decisions |
| Security Assurance Management (Code Owners) | Responsible for approving significant changes and exceptions to this procedure |
Tone at the Top: GitLab's StORM methodology uses a defined Risk Appetite and Risk Tolerance as the primary drivers to determine what risks GitLab are willing to accept versus what risks we will need to treat. These thresholds are defined by Senior Leadership across the organization to ensure the Tone at the Top is aligned with the StORM program. Risk Appetite and Tolerance are reassessed year-to-year during the annual security operational risk assessment process. This is done through an annual Risk Appetite Survey based on the ISO 31000 Risk Management Methodology. The survey is distributed to individuals operating in a Senior Leadership capacity with direct relations to Security Operations. The responses are averaged to arrive at an overall risk appetite and tolerance.
In order to effectively identify, manage, and treat operational risks, GitLab has defined a set of threat source categories alongside specific risk factors and risk scoring definitions. Based on these threat sources, various stakeholders across the organization will be identified to participate in the Risk Identification phase. For details on the identified threat sources and example threat events, refer to the StORM Methodology page.
The Security Risk Team interviews/surveys GitLab team members operating in a leadership capacity at GitLab in order to identify security operational risks within their respective departments. Risks identified will always be framed in terms of threat sources and threat events, and then assessed against the likelihood of occurrence and the impact to GitLab if the risk event occurs. Additionally, these risks will be assessed against the current internal controls in place to determine the overall residual risk remaining.
For details of the scoring methodology used, refer to the StORM Methodology page. For guidance on drafting risk language see the Risk Drafting Guidance. Risks will be quality reviewed by a member of the Security Risk Team.
Risks identified through the Risk Identification phase are formally tracked via an internal risk register. Given the nature of the sensitivity of this information in aggregate, the risk register is not made public, and is not distributed externally. However, a publicly viewable GitLab Risk Register Template is available here for those interested in getting some more insight into the type of information tracked in GitLab's risk register. StORM related risk activities are centralized within GitLab's GRC tool, ZenGRC. Additional information on the various risk related activities carried out of ZenGRC can be found on the ZenGRC Activities handbook page.
For each risk identified above, a formal risk response decision is made to determine how GitLab will handle the risk. For details of the risk response options available, refer to the StORM Methodology page. Note that as part of the risk response procedures, the Risk Owner will make a determination on whether or not to accept a risk or pursue remediation based on our Risk Appetite and Tolerances. Treatment plans will be reviewed by the Security Risk Manager or delegate and approval captured via comment in the GRC application.
Once the annual security operational risk assessment is completed, a detailed report is prepared to provide an overview of the Security Risk landscape and risk-specific information, including the incorporation of information gathered as part of our risk assessment.
There may be times that risks are identified outside of the annual StORM process - such as risks that arise from a security incident, risk identified through regular day-to-day business operations, etc. All security operational risks identified ad-hoc are discussed with the Security Risk Team, an inherent risk score is assigned, and a qualitative analysis done to determine if it should be escalated to the risk register.
To assess newly acquired/developed systems that enable security controls OR are/may be in scope for compliance programs for potential inclusion into our GitLab Control Framework (GCF) and compliance programs (e.g., Security Compliance Program and SOX Program).
Our goal is to identify systems that enable security controls (e.g., access management system) OR systems that are (or may be) subject to regulatory (e.g., SOX) or compliance requirements (SOC2) as early as possible via our Third Party Risk Management (TPRM) Program. As we engage with third parties for new systems, we assess the use of the system and whether or not it meets the criteria described above. Existing systems can also be ingested into the Security Compliance Intake process. Examples of these could include systems whose functionality has expanded to support security controls or instances where our understanding of a security control has improved resulting in the identification of a previously uncredited supporting system.
If the system meets the criteria, we open up a new Security Compliance Intake Issue.
Security Compliance Intake Issue asks the author to include details related to the system including:
Once the Security Compliance Intake issue is populated, Security Risk assigns the issue to the Security Compliance team to complete the following tasks to incorporate the system into our Security Compliance Program:
</details>
There are multiple ways the team can be engaged for risk:
#security-risk-management Slack channelRisk Escalation workflow by clicking on the blue lightning bolt in the bottom right corner of the message box and selecting Risk Escalation@gitlab-com/gl-security/security-assurance/security-risk-team on the issue or MRWhen documenting risks, team members can leverage Observation Description guidance for existing issues/observations or risk drafting guidance.
As per GitLab's Communication Page, information about risks tracked in GitLab's Risk Register defaults to not public and limited access. GitLab will always be susceptible to risks. The goal of implementing risk treatment plans and carrying out risk remediation activities is to reduce the likelihood or impact (or both) of a risk occurring. Given that no risks identified can ever be fully eliminated, but instead are mitigated through reduction of likelihood and/or impact, risks that have been escalated to GitLab's Risk Register will be shared on a need-to-know basis.
The only exceptions to this procedure are those risks that are out of scope (as defined above).