Risk Assessment Policy
SOC 2 Criteria: CC3.1, CC1.2, CC2.1, CC3.1, CC3.2, CC3.3, CC3.4, CC4.1, CC4.2, CC5.1, CC5.2, CC5.3
Keywords: Risk assessment, Threat impact, Threat likelihood, Risk score, Risk remediation
Purpose
The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within Bramble, and to define the acceptable level of risk as set by Bramble’s leadership.
This handbook page details the specific Security Operational Risk Management (“StORM”) Methodology that is used at Bramble in order to assess Risk Appetite, Risk Tolerance, as well as scoring risks based on their likelihood, impact as well as explicit inherent vs residual risk levels.
Scope
Risk assessment and risk treatment are applied to the entire scope of Bramble’s information security program, and to all assets which are used within Bramble or which could have an impact on information security within it. This policy applies to all employees of Bramble who take part in risk assessment and risk treatment.
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 Annual 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.
Background
A key element of Bramble’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for Bramble to identify information security risks. The process consists of four parts: identification of Bramble’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
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:
| Role | Responsibility |
|---|---|
| CTO | Executive sponsor of StORM program, performs a final review and approval of the annual risk assessment report |
| Security Officer | Provides senior leadership level oversight of the StORM program, including a review and approval of the annual risk assessment report |
| Security 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 |
Policy
Risk Assessment
- The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
- The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
- The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities.
- For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
- Once risk owners are identified, they must assess:
- Impact for each combination of threats and vulnerabilities for an individual asset if such a risk materializes.
- Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
- Criteria for determining impact and likelihood are defined in the tables below.
- The risk level is calculated by multiplying the impact score and the likelihood score.
Risk Factors and Risk Scoring
A scoring model is used to score each risk and is based on the Likelihood of the risk event occurring and the Impact to Bramble if the event occurred. Likelihood and Impact scores directly determine the overall inherent risk to Bramble.
Determining Likelihood of initiation of a threat event
| Qualitative Score | Risk Level | Scoring Guidelines |
|---|---|---|
| 6 | CRITICAL | Easily initiate a threat event; no expertise required |
| 5 | VERY HIGH | Minimal difficulty to initiate a threat event |
| 4 | HIGH | Some expertise required to initiate a threat event |
| 3 | MODERATE | Difficult to initiate a threat event, even with expertise |
| 2 | LOW | Requires expertise to initiate a threat event |
| 1 | VERY LOW | Theoretically impossible to initiate a threat event. |
Determining the impact of a threat event
| Impact Score | Organizational Output (time, quality, resources) | Brand Reputation | Business Continuity | Customers & Stakeholders | Legal & Regulatory | Financial |
|---|---|---|---|---|---|---|
| VERY LOW (1) | Organizational output is impacted by less than 20% | Limited to reputational damage with no more than one customer within a fiscal period | Outages of non-critical systems that impact Bramble team members | Impact is limited to one customer and/or stakeholder | Breach of company policy occurring once in a fiscal period | Loss up to $999 |
| LOW (2) | Organizational output is impacted by 30% - 40% | Confined to a limited number of parties (e.g. specific customers) and not publicized | Outages which result in the inability of Bramble to continue sales and finance operations longer than 72+ hours | Impact is limited to 2-3 customers and/or stakeholders | Breach of company policy twice within a fiscal period | Loss between $1,000 and $9,999 |
| MODERATE (3) | Organizational output is impacted by 40% - 50% | Public domain publicity but limited to industry channels and not the broader public | Outages that impact Bramble’s ability to do business across 3+ departments | Impact is limited to 4-5 customers and/or stakeholders | Breach of a regulatory and/or contractual obligation | Loss between $10,000 and $499,999 |
| HIGH (4) | Organizational output is impacted by 50% - 75% | Wide-spread publicity but limited parties are impacted | Outages that result in the loss of availability of Bramble for customers for less than 4 hours | Major impact to many customers and/or stakeholders | Regulatory censure and/or action taken against Bramble | Loss between $500,000 and $999,999 |
| VERY HIGH (5) | Organizational output is impacted by 75% or more | Widely publicized | Outages that result in the loss of availability of Bramble for customers for 4+ hours | Major impact to all customers and/or stakeholders | Public regulatory fines and/or major litigation against Bramble | Loss of $1,000,000+ |
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 is calculated in the same manner as inherent risk, but the likilood 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, MODERATE, 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, MODERATE, or HIGH.
| Likelihood Score | Impact Score 1 | Impact Score 2 | Impact Score 3 | Impact Score 4 | Impact Score 5 | |
|---|---|---|---|---|---|---|
| 6 | MODERATE (6) | MODERATE (12) | HIGH (18) | HIGH (24) | HIGH (30) | |
| 5 | MODERATE (5) | MODERATE (10) | MODERATE (15) | HIGH (20) | HIGH (25) | |
| 4 | LOW (4) | MODERATE (8) | MODERATE (12) | MODERATE (16) | HIGH (20) | |
| 3 | LOW (3) | MODERATE (6) | MODERATE (9) | MODERATE (12) | MODERATE (15) | |
| 2 | LOW (2) | LOW (4) | MODERATE (6) | MODERATE (8) | MODERATE (10) | |
| 1 | LOW (1) | LOW (2) | LOW (3) | LOW (4) | MODERATE (5) |
Risk Remediation
- As part of this risk remediation process, the Company shall determine objectives for mitigating or treating risks. All high and critical risks must be treated. For continuous improvement purposes, company managers may also opt to treat medium and/or low risks for company assets.
- Treatment options for risks include the following options:
- Selection or development of security control(s).
- Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
- Avoiding the risk by discontinuing the business activity that causes such risk.
- Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
- After selecting a treatment option, the risk owner should estimate the new impact and likelihood values after the planned controls are implemented.
Regular Reviews of Risk Assessment and Risk Treatment
- The Risk Assessment Report must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year.
Reporting
- The results of risk assessments, and all subsequent reviews, shall be documented in a Risk Assessment Report.
StORM Procedures
Step 1: Risk Appetite and Tolerance
Tone at the Top: Bramble’s StORM methodology uses a defined Risk Appetite and Risk Tolerance as the primary drivers to determine what risks Bramble 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.
Step 2: Risk Identification
In order to effectively identify, manage, and treat operational risks, Bramble 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 Security Risk Team conducts security operational Risk Identification interviews with individuals operating in at least a Manager capacity/level at Bramble 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 Bramble 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.
Step 3: Risk Tracking and Reporting
Risks identified through the Risk Identification phase are formally tracked via an internal risk register.
Step 4: Risk Treatment
For each risk identified above, a formal risk treatment decision is made to determine how Bramble will handle the risk. 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.
Step 5: Annual StORM Reports
Once the annual security operational risk assessment is completed, an executive and detailed report is prepared:
- Executive Report: The executive report is a summary report that is used to share internally and upon request from external parties as applicable. This report is a high level summary that does not expose specific details about risks identified and individuals involved during the annual assessment.
- Detailed Report: The detailed report contains information about the specific high risks identified as part of the annual assessment in additiion to the specific indviduals that contributed to the annual assessment process.
Ad-hoc Risk Identification and 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 quantiative analysis done to determine if it should be escalted to the risk register.
Annual StORM Assessment Schedule
The annual StORM assessment is conducted on a predefined schedule from year to year.
| Timing | Activities |
|---|---|
| March | Risk Appetite Survey is sent out to Senior Leadership to establish Bramble’s Annual Risk Appetite |
| April - May | Annual StORM interviews are kicked off for risk identification. Interviews with team members operating in a Manager capacity or higher (e.g. Staff, Principal, Distinguished, etc.) across the organization will be conducted. Once these interviews are completed, risks will be reviewed with Bramble’s VP of Security and Director of Security Compliance & Risk for approval/agreement of risks identified. Once these approvals are obtained, risk ownership meetings will be held with identified risk owners. Additionally, a re-assessment of Bramble’s Critical Systems is performed. |
| May | The annual StORM reports are prepared, reviewed, and approved |
| June - July | Security Compliance works with Risk Owners on the completion of Risk Treatment Plans. Note that the risk treatment does not need to be completed by the end of July, but the actual risk treatment plan needs to be finalized by the end of July |
| August and onward | Security Compliance will track and follow-up with Risk Owners on the status of risk treatment and update Bramble’s risk register accordingly for remediated/accepted risks. |
Risk Appetite and Tolerance Scoring
On an annual cadence, the Security Risk Team reassesses Brambles’s overall Risk Appetite. This is a key activity that drives risk treatment decisions for risks identified as part of the Annual Risk Assessment. While significant changes to risk appetite are not anticipated, this activity provides a mechanism to ensure Bramble’s appetite and tolerance for risk align with changes to threat sources and events.
Identifying Threat Sources and Events
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 Bramble’s operations.
Risk Factors and Risk Scoring
A scoring model is used to score each risk and is based on the Likelihood of the risk event occurring and the Impact to Bramble if the event occurred. Likelihood and Impact scores directly determine the overall inherent risk to Bramble.
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 is typically not included as part of the StORM program as the Tier 3 risk 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 are opportunities for Tier 3 risks to escalate to Tier 2 risks. This decision to escalate a Tier 3 risk in this manner will be documented within the Risk Details.
Risk Treatment Options
Each risk identified and triaged through the StORM program is required to undergo a risk treatment determination. This is an activity that will be discussed with each individual risk owner for the risks that they own.
Communication of Risks to the Security Risk Team
There are multiple ways the team can be engaged for risk:
- (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
- If the risk is identified within an issue, for example like a Security Incident issue, the following label can be applied: risk::escalation. The Security Risk Team will monitor and triage issues or MRs that have this label applied.
- Team members can also tag the team directly by @ mentioning gitlab-com/security/security-assurance/risk-field-security-team on the issue or MR.
Exceptions:
The only exceptions to this procedure are those Risks that are out of scope (see above - Scope).