Security Operational Risk Management (StORM) Program & Procedures

Purpose

The purpose of the Security Operational Risk Management (“StORM”) program at GitLab is to enable better decision-making by identifying, monitoring, treating, and reporting on 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.

Scope

The scope of the StORM program is limited to operational, technology-agnostic security risks, e.g., inadequate physical security controls. These risks can be identified in many ways including Risk Assessments, reports from team members, or as a result of compliance activities.

Out of Scope Unless they are related to a StORM risk (e.g., security compliance observations that span multiple systems), the following risk-types are not in scope for StORM:

1. Product/GitLab subscription-specific risks (e.g., specific vulnerabilty found within GitLab.com)
2. Operational risks that are not security-related are out of scope (e.g., accounting-related risks)
3. Individual security compliance observations (e.g., inadequate password settings for a specific system)
4. Enterprise Risk Management (ERM) - internal only. Examples of ERM risks can be found on our Mitigating Concerns handbook page.

Roles and Responsibilities

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:

StORM Procedures

Establishing Risk Appetite and Tolerance

Tone at the Top: GitLab’s StORM methodology uses a defined Risk Appetite and Risk Tolerance as primary drivers to determine which risks GitLab are willing to accept/take versus which risks we will need to mitigate. 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. 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.

How GitLab Determines Risk Appetite

GitLab’s security risk appetite is determined based on the total average priority order determined by senior leadership on the following risk strategy statements:

• GitLab should seek solutions to transfer risks to others whenever possible (risk taking vs risk transfer)
• GitLab should balance pursuing opportunities that align with organizational objectives against the associated risks (organizational objectives)
• GitLab should respond to all risks impacting the organization, regardless of the level of impact (risk response approach)
• GitLab should respond to risks based on cost, management priorities, and ROI (risk response drivers)

Each risk strategy statement is ranked in order of priority from Highest priority risk strategy to Lowest priority risk strategy by senior leadership. GitLab utilizes the following risk appetite matrix:

GitLab’s Risk Appetite Matrix was formed through consideration of guidance set forth in NIST’s SP 800-39 and SP 800-30 Rev. 1.

Scoring is performed by individuals operating in at least Senior Leadership capacity within GitLab and spans across multiple departments.

Translating GitLab’s Security Risk Appetite to Risk Tolerance

Our risk appetite is translated to a tolerance which defines a range in which a risk score value is tolerable and does not require remediation or a risk acceptance, i.e., the risk response will be set to “monitor”. Risk scores can range from 1 (lowest) to 30 (highest). The range is defined per Risk Appetite in the table below:

Risk scores above 26 are considered too risky to be considered within tolerance for any risk appetite.

Historical and Current Record of GitLab’s Security Risk Appetite

Risk Identification

Communication of Risks to the Security Risk Team

There are multiple ways the team can be engaged for risk:

1. (Preferred) If the risk was identified outside of a GitLab issue or MR or is extremely sensitive and requires some discretion, team members can do the following:
   • Join the #security-risk-management Slack channel
   • Execute the Risk Escalation workflow by clicking on the blue lightning bolt in the bottom right corner of the message box and selecting Risk Escalation
   • Fill out the form presented in Slack and submit
   • The Security Risk Team will intake and triage the risk and will follow-up if needed
   • Note that Slack will not post the details that are entered into the form to the public channel
2. If the risk is identified within an issue, team members can tag the team directly by @ mentioning @gitlab-com/gl-security/security-assurance/security-risk-team on the issue or MR
3. Submit a Risk Escalation issue on the StORM Repo.

When documenting risks, team members can leverage Observation Description guidance for existing issues/observations or risk drafting guidance.

Risks identified during risk assessments

The Security Risk Team may interview/survey GitLab team members operating in a leadership capacity at GitLab in order to identify security operational risks. 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.

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. The identification of threat sources and events in relation to operational risks includes multiple considerations. These threat sources and events have been identified based on their potential to have an impact on mission critical objectives in relation to GitLab’s operations.

Example Threat Sources and Events Considered

Risk Drafting Guidance

StORM Program considerations include both risks (what might happen) and observations (what has happened/non-compliance). For guidance on writing observations, please refer to Observation Management Procedure Handbook page.

When drafting a risk, start with a risk statement. This will represent the title of the Risk in our GRC system and is an attempt to condense the risk into a single sentence. In the spirit of low-context communication, avoid using single words or short phrases for the risk statement (e.g., Supply Chain). As we largely deal with negative risks (vs. positive risks/opportunities), starting the statement with negative language like “Failure to”, “Inadequate”, “Incomplete”, “Lack of”, etc. is appropriate, but not required. As risks represent what might happen, use “may” before describing the negative effect it may have on the confidentiality, integrity, availability, security, and privacy of GitLab data. Example: Inadequate physical security controls may result in the loss of GitLab/Customer data and physical assets. The risk description should contain details related to the assets/resources at risk, the event that may occur, the source that would trigger the event (root cause), and the consequence (impact/loss) source.

Risk Factors and Risk Scoring

Risk rating/scoring is a favorite topic of risk management/decision support practicioners and thought-leaders. Scores are subjective and can be influenced by unconscious biases of those applying the scores. To help mitigate this risk, we report on risks and request feedback from management to help calibrate and ensure alignment on our highest priorities.

To score each risks, we leverage a formula based on the Likelihood of the risk event occurring and the Impact to GitLab if the event occurred. Likelihood and Impact scores directly determine the overall inherent risk to GitLab.

Determining Likelihood of initiation of a threat event

Determining the impact of a threat event

To arrive at a final impact score, the impact score of all impact categories is averaged.

Determining Inherent Risk vs Residual Risk

• Inherent Risk is the risk before considering any existing mitigations in place, such as existing controls, internal processes/procedures, etc. and is determined by the following formula:

  Inherent Risk = Likelihood x Impact

• Residual risk is calculated in the same manner as inherent risk, but the likelihood and impact is reassessed based on the known existing controls, processes/procedures, etc. that reduce/mitigate the risk.

Determining if a risk is considered Low, Medium, or High

Once the Inherent and Residual risk score is determined, the following table can be used to determine if a risk is considered Low, Medium, or High:

These ratings represent labels for communication purposes rather than what is or is not acceptable. To determine what is an acceptable risk, please refer to risk tolerances.

The Impact of Control Health & Effectiveness Rating (CHER) on Risks

In some cases where controls are identified that mitigate a risk, the Security Risk Team considers the CHER of the control that is established based on continuous monitoring performed by the Security Compliance Team. For details on how the Security Compliance Team rates observations, refer to the Observation Management handbook page.

Given that the scope of the StORM program is limited to Tier 2 Operational Risks, any information system level risks (i.e. Tier 3) identified within the organization are typically not included as part of the StORM program as Tier 3 risks should be addressed by one or more internal controls. However, should a control have a high CHER rating, this may be an indicator of a larger risk. Because of this, there are opportunities for Tier 3 risks to escalate to Tier 2 risks. The decision to escalate a Tier 3 risk in this manner will be documented within the Risk Details.

Ad-hoc Risk Identification and Assessment

There may be times that risks are identified outside of traditional risk assessments - 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.

Risk Response

For each risk identified, a formal risk response decision is made to determine how GitLab will handle the risk. 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 or associated GitLab issue.

The risk object in the GRC application will be updated to reflect the agreed upon risk response. If “Remediate the Risk” is selected, the Risk Owner will execute a Risk Treatment Plan. The documented plan and status of the risk treatment will be captured within the GRC application as well. See below for more information about risk response options.

Monitor (nothing beyond expected iteration)

In the cases where a risk owner has concluded that a risk is within tolerance, no additional action is required besides ensuring that the StORM Program DRI agrees with the treatment option.

Remediate the Risk

When choosing to remediate the risk, a specific path must be selected:

• Remediate by reducing the likelihood that the risk could occur
• Remediate by reducing the impact to GitLab if the risk occurs
• Remediate by sharing or transferring the risk with a third party
• Remediate by avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk

Once a path is selected, the Risk Owner is required to provide a SMART, detailed plan that includes milestones and due dates for working towards risk remediation. The treatment plan must be achievable and address the root cause of the risk event. Additionally and in alignment with our value of Transparency, each treatment plan will include a step for documenting the results/outcome of the remediation within the Handbook. If the result of the remediation is considered not public and cannot be documented within the Handbook, it should be documented within our Internal Handbook or an internal runbook. The Security Risk Team will leverage these risk treatment plans to track the status of risk remediation.

If the risk treatment plan is executed and results in a downgrading of the residual risk level for the risk (e.g., the residual risk level goes from High to Moderate), validation of the remediation will be performed and captured within the associated risk object in ZenGRC. Quality review of the downgrade support documentation will be completed by the Security Risk Manager and captured via comment in the GRC application.

Accept the Risk

In the cases where a risk owner has opted to pursue a risk acceptance, the following approvals will be required based on risk rating that was assigned to the risk undergoing a risk acceptance:

• * If the Risk Owner is a Director/VP, no additional Director/VP level approval is required

By accepting the risk, the Risk Owner and risk acceptance approvers (if separate from Risk Owner), agree to reassess the risk on an annual basis to determine whether risk acceptance is the best response option for the respective risk. If risk acceptance is appropriate based on the annual assessment, approvals will be re-obtained based on the risk and approval requirements noted in the table above. Additionally, the Risk Owner will be on point for remediation in the event the risk is realized or risk acceptance is no longer appropriate.

Risk Tracking and Reporting

Identified risks 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.

Historically, we’ve produced an annual report to summarize our current StORM landscape including new potential risks, updates on our highest risks to support decision-making, and recommendations on actions to take to help mitigate existing risks. Starting in FY24 we will producing a quarterly report in alignment with our values. The template we’ve used can be found here for reference.

StORM Reporting Schedule

The table below outlines planned/completed activities for FY24.

Exceptions

The only exceptions to this procedure are those risks that are out of scope (as defined above).

References

• GitLab Handbook References:
  • GitLab’s Communication Page, Not Public Section
  • ZenGRC Activities
• External References
  • NIST SP 800-30 Rev. 1
  • ISO 31000 Risk Management Methodology