Threat Scenarios and Attack Paths: The What and the How of an Attack

The other half of the risk

Part two of this series delivered one half of the risk: what is at stake, and for whom. This part is about the other half. How does an attacker get to an asset, and how much effort does it cost them?

ISO/SAE 21434:2021 splits this into three modules: threat scenario identification, attack path analysis and attack feasibility rating. I cover all three in one article because the standard itself doesn’t separate them. In its own words, an attack path is the sequence of steps that realizes a threat scenario. The scenario says what happens. The path says how. And what gets rated is not the scenario but the path.

This is part three of my series on the steps of a Threat Analysis and Risk Assessment (TARA). Part one covered the item definition, part two asset identification and impact rating.

What the standard requires

The standard requires an analysis based on the item definition that includes, among other things, threat scenario identification, attack path analysis and attack feasibility rating. The methods for these live in Clause 15.

There, a threat scenario has three parts: the targeted asset, the compromised cybersecurity property, and the cause of the compromise. You know the first two from part two; together they are the asset. The cause is new.

Attack paths describe how a scenario actually plays out. For each scenario you look for its paths, and each path belongs to the scenarios it can realize. What gets rated is the path, not the scenario. Each attack path gets an attack feasibility rating: high, medium, low or very low. The scenario only inherits a value from its paths during risk determination, in the standard’s example simply the maximum.

Behind the maximum sits a simple assumption: the attacker takes the easiest route. Annex H shows it on the headlamp. The scenario “spoofing of the lamp request” has three paths there, via cellular, via Bluetooth and via the OBD connector. Rated by attack vector, they come out high, medium and low. The scenario lands at high, and together with the severe impact from part two, the example matrix gives a risk value of 5, the highest the scale has. That the OBD route is tedious changes nothing.

What a threat scenario is, and what it isn’t

A threat scenario fits in one sentence: through [cause], the [property] of [element] is violated. It’s the sentence from part two, read from the other end. There we went from the violation forward to the damage; here we go back to the cause.

Annex H puts it like this: spoofing of a signal leads to loss of integrity of the “Lamp Request” data communication to the actuator that switches the headlamp, and the light may turn off unintentionally. Cause, property and asset are all named.

Fill in only the first blank and you don’t have a scenario yet. “Spoofing” is a STRIDE category, not a threat scenario. Without an asset and a property it hangs off nothing, and what hangs off nothing never reaches a damage scenario. You can give such an entry a feasibility, but no impact.

Threats and damage aren’t connected one to one. A damage scenario can have several threat scenarios, and a threat scenario can lead to several kinds of damage. For the front collision with the tree, Annex H lists two scenarios: spoofing the lamp request, and tampering with the signal the body control ECU sends. Two causes, one damage.

The order is free again, too. For threat scenario identification, the standard only requires the item definition. Assets and damage scenarios are supporting information there, not prerequisites. Conversely, the standard explicitly allows deriving assets from threat scenarios. If you’d rather think from the attacker’s side, you can.

Catalogue or workshop?

How you arrive at the scenarios is up to you. You can sit down and discuss, play through misuse cases, or work with STRIDE, EVITA, TVRA or PASTA. The standard lists all of these and doesn’t prescribe a catalogue.

I think you need both, for different reasons. The workshop finds what exists only in this item and can’t be in any catalogue. The catalogue delivers something else: a completeness argument you can defend.

A threat analysis is never complete, and nobody seriously asks for that. The standard asks for a verification that the analysis result is correct and complete, specifically with respect to the item definition. “We thought about it for two days” isn’t a reference point. “Every asset was checked against every applicable threat class in the catalogue, and where nothing remained, the reason is recorded” is one. The second statement can be checked. The first can’t.

For automotive, there are usable sources by now. The Auto-ISAC Automotive Threat Matrix arranges 77 attack techniques under 14 tactics, from Initial Access to Affect Vehicle Function, and links the techniques to 24 published attacks on production vehicles, including the 2015 Jeep Cherokee hack. For embedded devices in general, MITRE’s EMB3D ties known threats to device properties. None of these replaces your own catalogue. They do answer a question that comes up in every feasibility discussion: has anyone actually pulled this off?

Whether a team with a catalogue ends up missing less than one without, I can’t prove with numbers of my own. The study Tuma and Widman cite, which I mentioned in part two, points that way: people without a security background, using a catalogue, reached results comparable to experts without one.

From scenario to attack path

A threat scenario says what happens. Whether it can happen, and how hard that is, only the attack path tells you.

The standard allows two directions. Top-down, you break the scenario into the ways it can be realized, for example as an attack tree or attack graph. Bottom-up, you build paths from the vulnerabilities you know. The first direction needs the scenario, the second the vulnerability. I’ll come back to the second at the end.

Two notes in the standard take a lot of pressure off this step. A partial path that doesn’t realize a scenario need not be analysed further. And paths may be incomplete and imprecise early in development, because implementation details aren’t known yet. They get updated as more becomes known, for example after a vulnerability analysis. So the standard doesn’t expect a finished tree in the concept phase. It expects the tree to grow.

Assumptions cut paths off. Annex H excludes every path that needs physical access inside the item, such as to the microcontroller of the body control ECU, and justifies this with an assumption. That’s legitimate. But this is where the assumptions from part one come back: whatever drops out here drops out on the basis of a statement someone has to be able to check later.

Steps repeat across the paths in Annex H. “Attacker compromises the navigation ECU via the cellular interface” appears in a path for the spoofing and in one for the denial of service. “The gateway forwards the malicious signals to the actuator” appears in all five paths. So a path isn’t a story. It’s a sequence of steps, and the same steps belong to several paths at once. Harden the gateway and you change five paths at once.

How much effort does the attack take?

For the rating, the standard recommends three approaches. They differ mostly in how much you need to know.

The attack vector-based approach looks only at the predominant attack vector of the path. Unrestricted network is high, an adjacent access such as Bluetooth medium, a local one such as USB low, physical access very low. The entry point is all you need. That’s why the standard suggests this approach for the concept phase, when specific paths can’t be identified yet.

The attack potential-based approach rates five factors: elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment. Annex G assigns points to each factor, sums them and maps the sum onto the four levels. For this you need the whole path, not just its beginning.

The CVSS-based approach uses the CVSS exploitability metrics: attack vector, complexity, privileges required and user interaction. It needs a concrete vulnerability, or at least a concrete weakness in the concept.

The choice is not a formality. Annex H rates the two denial-of-service paths by attack potential. The path via the cellular interface scores 20 points: multiple experts (8), confidential knowledge of the item (7), specialized equipment (4), up to a week of time (1) and an unlimited window of opportunity (0). That gives low. By the attack vector logic in Annex G, a cellular entry would be high. Same entry point, two methods, two levels apart.

The second path runs through a Bluetooth OBD dongle the attacker plugs into a vehicle parked unlocked, and through the driver’s compromised smartphone. It needs physical access and therefore scores 4 instead of 0 on the window of opportunity. That makes 24 points, low again, one point short of very low.

None of the methods is wrong. They measure different things, with different levels of knowledge. But the method, like the impact categories in part two, belongs to the organization, not to the individual analyst. Rate by attack vector in one TARA and by attack potential in the next, and you have two feasibility scales that share a name.

Two details in Annex G matter more, I think, than they look there. Whether an attack can scale, meaning be easily extended to many vehicles, may feed into the rating. And elapsed time is judged against the state of expert knowledge at the time of rating. So a feasibility rating ages. When an exploit is published, the effort drops without anything about the item having changed.

Same step, other industries

In part 3-2 of IEC 62443, the quantity isn’t called feasibility but likelihood. The detailed risk assessment in ZCR 5 starts, for each zone and conduit, by identifying threats and vulnerabilities. Only then does it estimate the unmitigated likelihood. The terms differ, the order is the same: first work out who gets in and how, then rate how likely that is.

Why a tool for this?

This step works in a spreadsheet too, and for threat scenarios even fairly well: one row per scenario, columns for asset, property and cause. It gets hard at the path. A path is a sequence of steps shared across scenarios, and a row has no room for that structure.

Steps are objects, not a list in a cell. In itemis SECURE, a threat scenario and an attack step are the same kind of object. If it threatens a security objective directly, it’s a threat scenario. If it prepares another one, it’s an attack step. The compromised navigation ECU from Annex H therefore exists exactly once, and every path through it points to it. Rewording or re-rating that step happens in one place. In a spreadsheet it sits as text in several cells, and someone has to update every copy by hand.

Feasibility is calculated along the path. Each step carries its factors, and the engine combines them by two rules. It adds up everything an attacker has to do: the step itself, the steps that prepare it, and the controls they have to overcome. Where the attacker has a choice, it takes the easiest alternative. That’s the same assumption as the maximum over a scenario’s paths, only applied at every level of the tree.

One subtlety here is, for me, the real reason not to do this by hand. At a branch, the engine doesn’t commit to whichever alternative looks easiest there. It carries the factor sets of the alternatives forward separately, because the branch that’s harder locally can, together with the rest of the path, turn out to be the easier one globally. To reproduce that in a spreadsheet, you’d compute every complete path separately and compare at the end. With three paths, that still works.

Method and factors are configuration. How the factors combine is configurable, and the assessment model can live at company level and be referenced by every project. The choice of method from the previous section is then made once, not again in every TARA.

Threats come from catalogues. The model has reusable classes of threats and controls. Our escar paper from 2022 laid out the thinking behind it: a threat catalogue is reference material for feasibility, and if you use it across projects, the same threat gets the same rating. The paper goes further. A catalogue without product- or company-specific data can be shared openly, and an update reaches every TARA that uses it, with no manual rework.

Then there’s the AI question that comes back in every part of this series. An assistant that proposes threat scenarios is especially tempting at this step, because there’s a lot of public material about threats. That’s exactly why its proposals almost always sound plausible. Whether a proposed scenario hangs off a real asset, whether its path runs over channels that exist in the item, and whether it already exists under another name can all be checked against a model with a stored rule set before a human accepts it. Against a spreadsheet, they can’t.

Finally, the point part two also ended on: where does a new CVE land in the TARA? In the attack paths. The standard explicitly names vulnerabilities from Clause 8 monitoring as information for attack path analysis, and it allows building paths outward from a known vulnerability.

The SBOM tells you which component runs the affected package. The attack steps that pass through that component hang off it. The vulnerability becomes a new step in the tree, or it lowers the effort of an existing one. An assistant can propose that entry; the engine does the recalculation: new feasibility for the affected paths, the maximum for each scenario, and from that, together with the impact from part two, the new risk. What you end up with is a list of the risks this one CVE has moved. Someone still has to decide, but over a list instead of a gut feeling.

That’s why every feasibility rating has an expiry date. Annex G rates elapsed time against what is known at the time of rating. Once an exploit is published, the old rating is out of date, even though nothing about the item has changed.

Conclusion

Threat scenario, attack path and attack feasibility are three modules in the standard and one idea in substance: what happens, how it happens, and what it costs the attacker. The route gets rated, not the destination, and the scenario inherits the rating of its easiest route.

What I take from this: a threat scenario needs an asset, a property and a cause. “Spoofing” alone isn’t one yet. You show that your analysis is complete against the item definition and a catalogue, not by how long the workshop ran. Paths share steps and grow with the project. The organization decides how feasibility is rated, not each analyst on their own. And every rating has an expiry date.

If you want to work this way model-based: itemis SECURE implements this approach, from threat scenarios and attack steps as shared objects, through threat catalogues, to feasibility the engine calculates along the paths. If you’d like to see what that looks like on a real item, you can reach me on LinkedIn or via itemis.com.

In part four, the two halves meet: risk determination and risk treatment. It covers the matrix in which impact and feasibility become a risk value, and the decision about what you do with each risk: avoid it, reduce it, share it or retain it. If you want the overview of the whole method first, you’ll find it in my introductory article What Is a TARA?.

How do you handle the concept phase, when you only know the paths roughly? Do you rate by attack vector, estimate attack potential anyway, or hold off on the rating until the architecture is settled?

Cyber Security at itemis — Systematic security engineering for automotive, IoT and Industry 4.0: Cyber Security →