The purpose of the Security Operational Risk Management (“StORM”) program at GitLab is to identify, track, and treat security operational risks in support of GitLab's organization-wide objectives. 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 identified and treated.
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 below. These risk are generally identified during the Anual Risk Assessment or Ad-Hoc reports.
Out of Scope Risks, such as operational risks that don't impact Security, Third Party Vendor risk, and Information System deficiencies, are managed through seperate processes. However, observations noted at the Tier 3 level have the potential to escalate to a Tier 2 Risk based on a Control Health & Effectiveness Rating (CHER).
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 |
|---|---|
| VP of Security | Executive sponsor of StORM program, performs a final review and approval of the annual risk assessment report |
| Director of Security Assurance | Provides senior leadership level oversight of the StORM program, including a review and approval of the annual risk assessment report |
| Manager of Security Risk | 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 |
| Security Risk Team | Coordinates and executes the annual risk assessment |
| Maintains the risk register and tracks risks through treatment | |
| 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 | |
| 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 | |
| Senior Leadership | Sets the tone of the risk appetite across the organization |
| Drives direct reports in their respective business units to comply with the StORM program | |
| Employees and Contractors | Comply with the StORM program policies and procedures |
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 nd 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 conducts security operational Risk Identification interviews with individuals operating in at least a Manager capacity/level 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.
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, is not distributed externally or internally outside of the Security Assurance Team and senior level management groups. 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 treatment decision is made to determine how GitLab will handle the risk. For details of the risk treatment options available, refer to the StORM Methodology page. Note that as part of the risk treatment 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.
Once the annual security operational risk assessment is completed, an executive and detailed report is prepared:
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 quantiative analysis done to determine if it should be escalted to the risk register.
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 Escalationrisk::escalation. The Security Risk Team will monitor and triage issues or MRs that have this label applied.
gitlab-com/gl-security/security-assurance/risk-field-security-team on the issue or MRAs per GitLab's Communication Page, information about risks tracked in GitLab's Risk Register defaults to not public and limited access. Given the nature of risk management, 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 occuring. Given that no risks identified can ever be fully eliminated, but instead are mitiaged 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 Risk that are either out of scope (as defined above).