Bridging the Gap: Ease into Cyber Risk Quantification with an Existing Risk Register

One common concern I hear from organizations early on during risk quantification program rollout is that they don't want to ‘reinvent the wheel.’ Almost always, a significant amount of work has already been done to identify and assess risk within the organization and, for many reasons, starting from scratch is an untenable endeavor.

Here's some good news... you don't have to start from scratch!

Kevin Gust is a Senior Risk Consultant for RiskLens

Rather than completely throwing out the old, it typically works best to bridge the gap between old methods and your new quantitative risk management program. One of the best examples of this is using an existing cybersecurity risk register to kickstart risk identification and prioritization.

3 Tips to Effectively Use Your Cyber Risk Register to Kickstart Your Quantitative Risk Management Program

1. Use what you have, no matter what you have.

All risk registers are different. Some are very detailed and can be translated into FAIR terms in a straightforward manner. If your organization has previously adopted FAIR or even started using terms like Asset, Threat, and Effect to identify risk, then you are off to a good start.

Some organizations are challenged because their risk register lacks an obvious link to the FAIR™ standard for risk quantification.

However, even using an “immature” risk register (in FAIR terms) as a starting point can help create a link between the original risk register and FAIR-based scenarios which, in turn, can help newcomers understand and adopt your quantitative program more quickly.

An organization I recently worked with provided a risk register without any assets identified. The majority of risk register items included at least some other components of FAIR scenarios - threat, effect, and (sometimes) method - and that was plenty of information to get started.

Below is an example of two original risk register items and how we translated these to FAIR risk scenarios:

Since we did not know the asset(s) of concern at the beginning of the conversation, we used a placeholder and revisited this point later. In the meantime, we built scenario “shells” which contained all the information we needed except for assets.

Translating to Scenario “Shells”:

1. Threat: Internal Malicious Actor / Effect: Confidentiality / Asset: TBD

2. Threat: Internal Actor (Error) / Effect: Confidentiality / Asset: TBD

To identify the assets, we focused first on the type of data they were concerned with losing, then discussed where that data exists within the environment (i.e., which assets); finally, we narrowed the scope of assets to the largest repositories of data and scoped scenarios accordingly.

Learn more: How to Scope a Risk Scenario with FAIR

2. Don't be afraid to consolidate risk register entries.

In the example above, the FAIR-based scenario shells mapped one-to-one to the two risk register items. This was certainly not the case for all 25 line items in the risk register, since we only ended up with five scenario shells from our exercise. The most common theme in the risk register was the Confidentiality of data being targeted by External Malicious Actors.

Threat: External Actor / Effect: Confidentiality / Asset: TBD

This one scenario alone mapped to 10 unique risk register items. A few examples of the risk register themes that linked to this scenario are listed below:

• Breach of data privacy through test environment

• Malware targeting users with excessive administrative privileges

• Malware targeting unpatched servers / devices

• Unauthorized access to network and devices

• Data breach through unencrypted media

• Targeted application attacks

• Brute-force attacks

As you can tell from this list, there are a number of different methods an external threat actor might use to expose Confidentiality of data. Focusing only on the Threat and Effect allowed us to consolidate multiple concerns from the risk register into one FAIR scenario shell. This was sufficient for the purposes of identification and prioritization. Later, when we wanted to focus on detailed scenarios around a particular asset, we chose to focus on the most probable method based on industry research to guide our analysis.

Learn quantitative risk analysis for cyber and technology with FAIR training from RiskLens

Risk themes on a dashboard based on RiskLens analyses

3. Tie it all together.

We walked through the process of scoping FAIR scenarios from risk register statements and how to map multiple risk register items to an individual scenario. Now, you might be wondering how to tie everything together. As I mentioned above, using an existing risk register to bridge the gap can be a great way to garner buy-in from stakeholders. One way to gain that buy-in is by reporting in familiar terms to involved stakeholders.

Using the first example above, if you add all the Insider Threat scenarios into a risk assessment and report on the aggregate Annualized Loss Exposure (ALE) associated with that threat category, that will give stakeholders a picture of the risk associated with familiar risk register items in financial terms.

As FAIR practitioners, we love performing detailed analysis and using our FAIR definitions and terms. To some stakeholders, however, getting into the weeds of FAIR can be confusing and daunting. Reporting on risk themes linked to an existing risk register can help stakeholders see the value of risk quantification in familiar terms.

Learn more: Report to the Board with a Cyber Risk Dashboard

Conclusion:

Sometimes the best way to push your quantitative risk management program forward is to embrace its qualitative past. Rather than completely scrapping old methods, use the work that has already been completed (i.e. building out risk registers) to turn the page to the next chapter in your risk management journey.

See the RiskLens platform -- implementing FAIR risk analysis -- in action: schedule a demo.