Risk Scoring Basics

April 30, 2021

• Cybersecurity leaders often face risk fatigue, as newly identified risks seem more significant compared to risks that have been present longer. 
• This can result in priorities that aren’t aligned to the organization’s true risk.
• A risk registry is a straightforward way to limit the impact of risk fatigue.

We’re all familiar with olfactory fatigue – when we’re exposed to an odor long enough, we can’t smell it anymore. Then someone else comes into the room, and wow, that’s a strong scent. 

Risk fatigue is similar. When we’ve faced a certain risk long enough, we no longer “feel” its true importance. Cybersecurity leaders often face risk fatigue, as newly identified risks seem more significant compared to risks that have been present for a longer period of time. This can result in priorities that aren’t aligned to the organization’s true risk: budgets aren’t properly allocated, and resources are focused on risks that don’t represent the greatest threat to the organization. 

If we’re able to consistently measure, we can identify our real risk and areas of risk fatigue. In its simplest form, risk is scored as a product of impact x likelihood. In cybersecurity we often talk about risk in terms of threats and vulnerabilities and how easily they can be exploited. This isn’t the totality of risk, but rather is one part of the overall equation. An easily exploited vulnerability may create a high probability of exploitation, but we must also consider the potential impact. For example, if an easily exploitable vulnerability that would put customers’ private information at risk is present on a critical business system, then we have a high impact and a high likelihood, resulting in a high-risk rating. If the vulnerability is on a standalone system that feeds the daily cafeteria menu, we have a much lower impact and lower risk.

Real-world quantitative cybersecurity risk analysis is incredibly complex, requiring significant data inputs such as system valuation, data, and process mapping, along with financial impact analysis associated with every workstream in the organization. Even for organizations that have done a full business impact analysis, it can be difficult to quantitatively assess impacts, and because of the adversarial nature of cybersecurity, it’s virtually impossible to quantify probabilities. For both calculations, expert analysis is as important as the data required to make the case. The good news is if we’re applying our risk analysis consistently, we get what we need from our risk scoring: the ability to rank risks against each other from high to low. 

Once we can score our risks, we can take the next step and rank them from high to low. While this process is often called a risk registry, it’s technically more of a risk log (fortunately most compliance audits will accept this as a form of registry). The next risk registry step is to assign risk treatment options. We call it treatment rather than remediation because remediation is only one of the options available for treating risk: we can remediate, avoid, share or retain (accept) the risk, and each option has its place in our risk log. 

Image

• Remediate: This term sounds like we’re eliminating the risk, and that’s seldom the case. “Mitigate” is more accurate because there will usually be some residual risk after the plan has been implemented. Mitigations would include things like patches, configuration changes, new protective technologies/processes and compensating controls.
• Avoid: Completely avoiding a situation (i.e. convincing executives not to move forward with a new business plan) is extremely difficult, but can often be implemented in part to reduce overall risk. For example, consider a highly critical data set where a group of users have a minimal business need for access. By limiting access to only users with a critical need, we can reduce the overall risk (reducing the probability side of the equation).
• Share: Sharing – sometimes referred to as “transferring the risk” – is the practice of obtaining insurance against possible losses due to a defined risk. Another way to share the risk is to hire a service provider or cloud provider to assume some the of responsibility and risk (i.e. outsourcing credit card payment services).
• Retain: Retain – often referred to as “accept the risk” – is straightforward: the organization decides not to do anything about the risk. Most often this strategy is employed for risks that are highly unlikely and/or low impact. Security should never approve the acceptance of higher risks. Risk acceptance is a business decision and should be approved by organizational leadership.

 

Two more items should go into the risk registry: you/your team’s expert recommendations for the risk treatment and a residual risk rating or score. Your registry should have a defined plan for each of the risk treatment options above, and now you select which ones to propose to organizational leaders for approval. Once these steps are completed, we will consider residual risk.

 

Additional items that may be useful to add to your risk registry include specific lines of business that could be impacted, technical or procedural risks, date of entry into the log, categorization of items against a compliance standard or security framework and resource requirements/level of difficulty to enact the risk treatment plans. 

 

Now that you have a functional risk registry, it needs to be managed on an ongoing basis.

 

• New risks should be added and ranked, with risk treatment defined.
• Existing risks should be reevaluated periodically to ensure the scoring hasn’t changed.
• Consider adding the risk registry review to your team status meetings to ensure information is kept up to date. 
• Review risk items and treatment plans against your organizational strategic objectives to show executive leadership how risks can impact objectives and how the treatment plans are supportive of them. 
• From a management perspective, consider pulling some metrics from your risk registry. Measurements such as total number of items, number by severity and age of open items can all be signs that something is amiss in your operations. It’s always good to include metrics around how your program first identified a risk and how effective it has been in reducing risk within the environment.  The metrics you provide should be factual and relevant, as well as telling a story regarding the effectiveness of your program.

 

As you begin building your robust cybersecurity risk management program, implementing a risk registry is an upfront solution to reducing the impact of risk fatigue.