Skip to content

4.3.A Risk sources & feared events ~45 min Module 4 · Risk

Risk sources and feared events

What you'll be able to do in this chapter
  • Define feared events and rate their severity against business values.
  • Identify risk sources and pair them with the objectives they pursue.
  • Use STRIDE and MITRE ATT&CK as vocabularies for what attackers do.

Two questions before any scenario

You have modelled what matters (Chapter 4.2). Before building attack scenarios, the method asks two more questions, which are the work of EBIOS RM's first two workshops. What could happen to the business values that would cause significant harm? (the feared events, Workshop 1). And who would deliberately make it happen, and why? (the risk sources and their objectives, Workshop 2). Naming both turns a vague concern into something that can be analysed and prioritised.

Together, these two questions are EBIOS RM's Workshop 2 · risk origins: what Scaldimet fears losing (the feared events, with their severity) and who would cause it (the risk sources). This is the first slice of the pyramid's apex: the what and who that the scenario workshops turn into attack paths.

Feared events: what you dread

A feared event is an undesirable thing happening to a business value, expressed on one of its security dimensions: confidentiality, integrity, availability or traceability. It is the harm, stated from the business's point of view, before any mention of how it might occur. For Scaldimet:

  • The Beta production line is unavailable for three days (a feared event against the continuity business value).
  • The OEM's design data is disclosed to a competitor (against the confidentiality business value).
  • The manufacturing instructions are altered without detection, so parts are made wrong (against the integrity business value).

Each feared event is then rated for severity: how badly would this hurt, on a scale from negligible to critical? Severity is judged in business terms (safety, the OEM contract, revenue, legal exposure), and it is the same severity that the strategic scenarios will inherit in Chapter 4.4. Note what severity is not: it is not how likely the event is. Likelihood comes later and separately; mixing the two here is a common and costly confusion.

Risk sources: who, and why

A risk source is an actor who could cause a feared event, and EBIOS RM insists you name real adversaries rather than generic "threats". A source is paired with an objective: it is not enough to say "a competitor", you say "a competitor seeking to steal design data for commercial advantage". The source-and-objective pair is what makes the case concrete enough to analyse, because the same actor with a different goal behaves differently.

For Scaldimet, plausible pairs include a competitor seeking design data; a ransomware crew seeking payment by halting the line; a disgruntled insider or contractor seeking to cause damage; and a state-aligned actor seeking to disrupt the automotive supply chain. You do not analyse every conceivable pair; you assess each for relevance (its motivation, resources and activity) and keep only the few that genuinely warrant the deep work. The same principle of proportion applies here: a representative, prioritised set is more useful than an exhaustive list that cannot be assessed effectively.

Technical explainer (read & discuss, don't build): STRIDE and MITRE ATT&CK

Two vocabularies help you reason about what attackers do, and you will hear both named. STRIDE is a threat-classification aid from Microsoft, used at design time: it prompts you to ask, for a given component, could someone Spoof an identity, Tamper with data, Repudiate an action, cause Information disclosure, cause Denial of service, or achieve Elevation of privilege? It is a checklist for kinds of threat against a thing. MITRE ATT&CK is different: it is a large, curated knowledge base of real-world attacker tactics and techniques (how intruders actually gain initial access, move laterally, escalate, exfiltrate and so on), built from observed incidents. It even has a dedicated matrix, ATT&CK for ICS, for industrial control systems like Beta's SCADA. You are not expected to memorise either. You are expected to know that STRIDE helps you enumerate threat types against a component, and ATT&CK gives you a realistic library of attacker behaviours to draw on when you build operational scenarios in Chapter 4.4. They are the raw vocabulary; EBIOS RM provides the structure that arranges it into scenarios.

Application: pair sources with feared events

On paper, write Scaldimet's three or four feared events, rate each for severity in business terms, then list the risk-source-and-objective pairs and draw a line from each pair to the feared event it would most plausibly cause. Draft your page before opening the model.

Model answer (open after you've drafted yours)

Feared events (severity in business terms): French line unavailable for days — Critical (breaches the OEM contract); customer design data disclosed — Critical (contract loss, reputation); compliance not demonstrable at audit — Major (the certificate at risk).

Source → objective pairs, linked to the event each would most plausibly cause:

  • Ransomware crew → payment ⟶ line unavailable (and compliance if evidence systems are hit).

  • Competitor / state actor → obtain design data ⟶ data disclosed.

  • Opportunistic attacker → any foothold ⟶ line unavailable, via the weakest path (Beta OT).

  • Disgruntled contractor or insider → sabotage or theft ⟶ line unavailable or data disclosed.

On one page you now have who would hurt Scaldimet, why, and what it would cost, which is the input the scenario workshops need. A pair that links to no feared event is not worth analysing; a feared event with no plausible source is not yet a risk.

Key takeaway

Before scenarios, name two things. A feared event is the harm to a business value on a security dimension (the line unavailable, the design data disclosed), rated for severity in business terms, and severity is not likelihood. A risk source is a real adversary, always paired with an objective (a competitor seeking design data), and you keep only the relevant, prioritised pairs rather than an exhaustive list. STRIDE (threat types against a component) and MITRE ATT&CK (a knowledge base of real attacker techniques, including ATT&CK for ICS) are the vocabularies for what attackers do; EBIOS RM arranges them into the scenarios of the next chapter.


Next: Chapter 4.4 · Scenario-based assessment →