Scenarios are an underappreciated way to model infosec risk. A scenario is simply a future, consequential event you write to express a risk you’re concerned about. I’ve found that scenarios are flexible, creative, powerful, and rich with neat features. A good risk scenario focuses groups on their work… so writing them well is a craft that makes teams better.
Why risk scenarios?
You are probably knowledgeable about some area of security if you are reading this essay. If that’s the case — try to articulate your knowledge in terms of risk scenarios. These are plausible future events that would somehow invoke your knowledge if they occurred. How would you categorize your domain knowledge in a choice set of scenarios?
For example: “An adversary remotely gains root access to Windows” or “An adversary moves laterally on systems within cloud infrastructure”.
While this may not seem like a huge difference at first, the scenario based approach introduces interesting capabilities. They can go a lot further than just explaining your domain expertise. Scenarios make up a whole language of outcomes. Full teams can rally behind them and contribute to in their own unique ways.
Scenarios are flexible because they can express infinite possibilities involving impacts, controls, threats, and more!
Here are a few:
- Impact: Over 10,000 user records were exposed.
- Controls: A malicious implant was not detected or blocked by our EDR.
- Threats: An insider has exfiltrated intellectual property.
Scenarios can merge into ultra-specific use cases. See, here are all three scenarios at once!
- Impact / Control / Threat: Over 10,000 user records exfiltrated by malware planted by an insider.
Alternatively, here’s one that extremely vague: We disclosed a breach!
Scenarios have infinitely flexible scope. You can time-box them (within this year), narrow them into particular areas of your network (On the vendor VPC), and more.
Scenarios are creative because you can treat them like mad libs. One can’t help but imagine the possibilities when someone suggests a partial scenario. For example:
An attacker exploited an RCE in our _____ network to reach production data.
Immediately, one should begin to wonder what part of your company would most likely suffer this sort of attack originating from an RCE.
By leaving these specifics unspoken in a risk scenario, only uncertainty remains. The uncertainty expressed is an open-ended question and the beginning of our professional efforts. Uncertainty is often what we are trying to communicate. “I wasn’t specific because I truly don’t know!”
Being particular about what goes unsaid in a risk scenario creates the opportunity to extract valuable knowledge from a subject matter expert. Expert opinions on what fills in those blanks are exactly what we look for when studying risk in collaboration. Open-ended scenarios are great for risk interviews.
Scenarios are powerful and feature-rich because they fit into multiple other risk concepts:
- Tabletop Exercises: All tabletops start with some scenario, whether a short lunchtime conversation or a full simulation. Any risk modeling you do is compatible with either of these, should you need to break one out for collaboration.
- Quantification: Scenarios are foundational for all probabilistic approaches,
r = p * i, Monte Carlo modeling, FAIR, forecasting, and more. You don’t need to know anything about quant, but you can still use scenarios as a modeling method until someone wants to quant with them in the future.
- Data Gathering: Scenarios give you a starting point for data gathering historical events that meet your scenario’s criteria. Of course, this can feed into your statistical approaches in quant or act as research without quant getting involved.
- Decomposition: Any scenario can be drilled down into infinite sub-scenarios. You can thoroughly explore a risk using any scenario as a starting point. This is because scenarios can follow probabilistic axioms when properly used.
This all seems obvious.
It may! However, you’ll find that the North Star at many organizations is not based on any mention of risks. Rather, how work is planned, prioritized, and communicated is often based on controls, compliance, or “maturity”. Collaboration on risks is either nonexistent or buried as a governance practice and done out of sight of the organization.
I believe that we’re over-indexed on non-scenario-based approaches. There is an opportunity for us to incorporate scenario-based language more frequently in our work when other methods run out of steam.
How is this all different from a controls-based approach?
A risk scenario leads to controls, and controls mitigate risk scenarios.
For example, You could ask, “Why do we need MFA?” and thought leaders everywhere would wake up in a cold sweat to defend MFA. Those defenses will be in scenario form. “Because an attacker could have obtained and used our passwords!”
A single control can mitigate many scenarios. This is why control-based approaches are often so portable and valuable from company to company. Controls can appear in contracts, are easily auditable, and make explainable security products. That’s why control-based approaches are so popular. When a fundamental control is missing, it is probably a red flag.
Control-based approaches are here to stay but are incomplete. They are less effective around innovative problems. They do not exist for the “First Flight” or “Maiden Voyage” class of risk problems in the areas that matter.
The First Flight problem is when best practices aren’t yet available for something that hasn’t existed until recently. For example, the first time a new vessel embarks into uncharted territory — the first spaceship, submarine, satellite, nuclear, etc. No experience is available to inform mitigations, uncertainty is high, and emergent problems may be catastrophic.
Social media in the early aughts (arguably up to today) have this problem with privacy, at-scale integrity, abuse, and geopolitical issues.
Cryptocurrency has many new paradigms deploying on consensus networks, resulting in billions in losses from concepts we have to learn about in hindsight. AI may be as emergent as it gets.
There are no control-based approaches invented yet when First Flights risks exist.
Generally speaking, tech companies have some crucial areas where playbooks don’t yet exist. These are often in the class of First Flight problems.
When a First Flight problem arises, scenario-based approaches rule. They are only limited by the smartest people available to contribute to an assessment. Only in well-charted territory will you find control-based methods more useful.
Are risk scenarios different from threat models?
I’ve struggled to answer this because “threat modeling” can have an expansive definition. Succinctly, yes, they are different concepts, but they are naturally related and often inclusive of concepts from one another. Here are my thoughts:
- Threat modeling outputs risk scenarios.
- Other things output risk scenarios, too.
- Those other things are hard to describe as threat modeling.
- Threat modeling is an activity, and scenarios are a deliverable.
- A scenario is useful, creative device available in threat modeling.
A distinguishing example of this is the Verizon Data Breach Report. It is full of risk scenarios. They’re produced from observed incidents in-the-wild rather than a threat modeling session, so my view is that these concepts are different.
Scenarios are indeed a natural output of threat modeling. Threat models include many other important things like system diagrams and potential mitigations. By doing the work involved with a threat model, you will naturally output scenarios within whatever documentation you output.
Other activities that produce scenarios:
- A red team can finish an engagement and provide risk scenarios based on successful or unsuccessful intrusion paths they predict.
- A product/appsec team can suggest risk scenarios based on repeat vulnerability disclosures.
- Your detection engineering team can produce risk scenarios based on what they can and cannot detect.
- Your IR team can produce risk scenarios they could, or could not respond to.
- Your lawyers can produce scenarios based on what may cause outlier costs to an organization like yours.
Scenarios are powerful. Clear, well-written scenarios should be a first-class skill for security professionals and a core part of how security teams work together. Taking the time with others to be clear about the scenario you’re concerned about is a matter of keeping everyone moving toward the same goal.
Other Writing on Scenarios
I write a painfully large amount about risk scenarios if you want to keep going down this road.
Malicious Insider Scenarios
Insider threats are often discussed as a broad category. This essay explores the malicious flavor of insider threat and…
A risk decomposition walkthrough
This is a method I’ve used to help frame and model cybersecurity risks over the past few years. It helps organize a lot…
A risk based security project 📢
Driving an awareness project with a risk measurement ethos.
Decomposing security risk into scenarios
How to express risks with well understood tabletop phrasing.
Troubles with quantified risk
Risk quantification can be confusing and derailing to groups and decision makers.
Let's measure some risks!
Helping engineers ramp up their risk intuition and skillset.
Describing Vulnerability Risks
Improving vulnerability communication with quantitative risk forecasts