Writing a risk scenario
A risk scenario is a fictional but plausible event that could harm your organization. Writing one well improves communication with others about risks. Let’s write a scenario!
Please detail a very bad event that happens in the future.
That’s it! That’s all that’s being asked.
✅ A scenario is a fictional risk event that may occur in the future.
❌ A scenario is not a simple statement about a single control, best practice, law, compliance need, gap, or threat actor stated all by itself.
Experienced professionals struggle to communicate a risk problem as a scenario regularly. Let me show you:
“Hey, we need to enable host firewalls on all of our production systems.” Why? “Because it’s a best practice.” Why? “Because it denies connections that are not otherwise expected.” So? “So then we can whitelist all approved services.” You’re killing me. WHY??? “Well, it’s a compliance thing…”
Why, WHY, WHY!?
Get out of this loop. Explain the scenario: A threat actor from network B (which production trusts) discovers and exploits a vulnerable service in production. A breach, or a vendor insider within that network, could communicate with production, which has known exploitable CVEs.
Expressing a coherent scenario instead of disparate security principles will make the engineers you’re working with very happy. Now the both of you can discuss the plausibility of the scenario and whether host firewalls are the best mitigation. This leads with a scenario when communicating.
An inability to do this well is a prolific soft-skills gap among security practitioners.
Here are good examples
Here are some classic examples that are strategic. They are short and vague. That is okay! Terse scenarios describe broad risk areas that wider security programs concern themselves with.
Strategic scenarios
- An adversary exploited a vulnerability in our app. (Product Security)
- An adversary remotely executed code on a laptop. (Enterprise Security)
- An adversary exfiltrated a database backup. (Infrastructure Security)
- A vendor hosting our data has experienced a breach. (Vendor Security)
Tactical Scenarios
Here are some tactical examples. They are specific, time sensitive, or describe a narrow area of concern. They’re often well described to illustrate how likely (or unlikely) the scenario may be.
- A theoretical exposure of our infrastructure.
An unintentional network configuration exposed port :8888 and made our JupyterLab instance reachable, allowing our data to be exploited by an unknown threat actor who discovered it before we patched it. The instances are unauthenticated and would allow direct adversary access to the data if the network allowed it.
2. A theoretical insider hoarding data.
An engineer who is leaving to form a competing startup is cloning as many repositories as possible onto removable storage before their last day. These repositories host sensitive intellectual property, and we have no centralized logs or visibility into how existing employees access them.
3. A compromised dependency in our product.
A frontend dependency of ours has been compromised by a crypto-stealer, resulting in our client browsers launching various attacks against our customers. We have no process in place that prevents new dependencies from being added or existing ones from being updated without proper consideration.
Here are bad examples
Let’s correct some bad examples.
- We oughta have better network segmentation!
That’s not a scenario. How about: A threat actor residing in network A exploited an exposed service in network B.
2. Incident response plans are really important!
That’s not a scenario. How about: A number (>0) of customers have churned in response to our handling of an incident.
3. We need to be compliant with GDPR.
That’s sort-of a scenario, but it sucks. A regulator has discovered that we failed to disclose a breach within 72 hours. Now, we define more tangibly why GDPR needs to be explored.
You can check if it’s a scenario!
It can only be a scenario if several straightforward conditions are met.
- Threat Source: A threat source should exist in your statement along with a verb.
- A disgruntled employee has accessed…
- An upstream dependency has introduced malicious code into…
- An APT group has exploited…
2. Time Frame: The scenario should still make sense when a timeframe is added.
- …in the next quarter.
- …in the following year.
- …more than once in the next 90 days.
3. Unambiguous: The outcome of the scenario must be unambiguously judged. A threat actor totally clowned our production servers is a bad scenario. Instead, a threat actor’s executable code exfiltrated data on a production server can be forensically assessed or be associated with a declared incident.
4. Gambling: It must be possible to make bets or set odds on the scenario. If the scenario did or did not happen, you could have paid out bets for either side. Not that you should, this is just a test.
5. Tabletops: It is a plausible scenario if you can host a rhetorical discussion on what would take place if the scenario came to be.
Why is this so important?
Scenario development is the most robust form of problem identification that exists in security. A scenario forces communication on a consistent level. Participants can calibrate and agree on a problem when a scenario is the target of discussion.
Compliance conversations are a typical area where scenarios are often lacking. GRC will typically advocate for a specific control to make progress on a compliance problem. In doing so, the actual scenarios they are looking to mitigate are often (famously) unclear.
A discussion about the underlying scenario can unveil if the ask is performative or not, or if a different control can mitigate some real risk.
Otherwise, security teams (especially the large ones) will get caught talking past each other with competing problem definitions. Scenarios cut through the bullshit and align everyone with the same lens.
There’s a time and place to lead with other security concepts, but the most tangible primitive you can operate with in a risk conversation is a scenario.
writes about security on scrty.io
