# A risk decomposition walkthrough

## 1. Create a scenario.

This walkthrough will use the following scenario:

We disclose ≥1 incidents with ≥\$10M damages in 2021.

What future outcome are you looking to investigate? Be confident about your definitions. This example mentions damages and an incident: What damages count? What is an incident, specifically? Disclose where, or to who? Who judges whether the event occurred at all?

## 2. Forecast whether it will happen or not.

Set the odds. You’re the oddsmaker! If people were betting on this event, what odds are fair? Here’s an example: A 14% chance that this scenario will take place in 2020.

## 3. Consider: How did it happen?

Brainstorm! What categorical areas might cause the incident? A disclosable incidents could happen in a variety of ways. How would you categorize the possibilities?

• IT compromises
• Product security failures
• Infrastructure failures
• Vendors
• Other gives us a catch-all for errors: incidents that weren’t considered or difficult to classify. Do your best to pick categories that are unlikely to intermingle in an incident. This can be difficult. But, in the event that something is too difficult to classify — it’s Other.

## 4. Forecast… (again)!

If this incident were to occur, what odds would you set on the incident being classified (or judged) as belonging to one of these categories? The sum of all categories must equal `100%`. Here, our example has some forecasts dropped in. It looks like IT Compromise is the front-runner for causing an incident.

## 5. Consider, and forecast (AGAIN!)

This can be iterated and depth can be added repeatedly, but you might run out of time or energy. One level deep for each category is doable in a reasonable amount of time with a group.

## 6. Find the hotspots.

The above diagrams are helpful for learning this method. However, we would actually be calculating all of this in a spreadsheet. A simple sheet can quickly figure out how much risk each category holds by decomposing `Yes 🔥 (14%)` by its potential causes.

1. Employee ATO: Perhaps, an employee’s single factor credentials being leaked and exploited.
2. Cloud IaaS Misconfigured (S3 / DB / Backups): Maybe an S3 bucket being exposed after a configuration change.
3. Credential reuse in our product / Endpoint breach / Vendor (three way tie): How is a single vendor as risky as a whole other category? Maybe worth discussing.

## BENEFITS ✅

This is a useful planning method. It is especially strong at capturing a very wide space of risk in a complex system, and prioritizing it. It allows us to get ankle deep into some lower risks, and deeper if we can delegate / collaborate.

• Why do you think `X` is so likely? It’s not even possible.
• I’m really surprised you expect `Y` to happen more than `Z`.
• I thought we fixed `A` and `B`, shouldn’t it be lower?

## PROBLEMS ❌

There are many! First, this is a risk modeling method. It does not solve for risk, despite the fact that numbers are used. All models are wrong. This, instead, forces the operator to confront their beliefs and expose them to scrutiny.

--

--

## More from Ryan McGeehan

Writing about risk, security, and startups.

Love podcasts or audiobooks? Learn on the go with our new app.

## Ryan McGeehan

2.5K Followers

Writing about risk, security, and startups.