Asset Identification and Impact Rating: Whose Damage Are You Actually Counting?

One Half of the Risk

After the Item Definition, the reflex in most projects is to start collecting threats. The standard puts a different question first: what is worth protecting here, and what does it cost when it breaks.

A risk value in a Threat Analysis and Risk Assessment (TARA) comes from two quantities, the impact and the attack feasibility. This step supplies the first of them, and with it half the distance to the risk. How much the second half can still move depends on the first: in the example risk matrix in Annex H, the “negligible” row carries the same value across all four feasibility levels. Where the damage is negligible, the attack side no longer changes the outcome. In the rows above it, it changes a great deal.

This is part two of my series on the steps of a TARA under ISO/SAE 21434. Part one was the Item Definition, the step that decides what you are analysing. This one is about the step that decides what is at stake.

What the Standard Asks For

The standard requires an analysis based on the Item Definition that includes, among other modules, asset identification in accordance with 15.3 and impact rating in accordance with 15.5.

In the standard’s words, an asset is an object of value whose cybersecurity property can be compromised: confidentiality, integrity, availability. A damage scenario describes what damage a stakeholder suffers when such a property is violated. The two definitions point at each other. Something is an asset because a damage scenario exists for it, and a damage scenario needs an asset to be about.

One thing matters here: an asset is never the element on its own, it is the element together with the property you want to protect. Annex H marks both confidentiality and integrity on the firmware of the body control ECU. To me those are two assets sharing one element, and they have little to do with each other. Break the integrity and manipulated code runs in the vehicle; the damage hits the driver and everyone around them, and it is a safety case. Break the confidentiality and development know-how leaks; the damage hits the manufacturer and has nothing to do with safety. Two properties on one element, two stakeholders, two categories, two risks at the end of it.

Split that pair and carry only the element, and you have set the property to “all three” without noticing.

The circularity in the definitions is not sloppy drafting, it is room to move. Annex H states outright that the modules of a TARA can be worked in any order, and gives two example sequences: assets first and their damage scenarios after, or damage scenarios from a catalogue first and the assets they imply after that. Both are legitimate. Bottom-up from the architecture works, top-down along a list of consequences the company already cares about works just as well.

When Does an Element of the Item Become an Asset?

Every function, component, channel, data flow and data item in the Item Definition is a candidate. None of them is automatically an asset.

My test for it is simple: can I finish this sentence? If the [property] of [element] is violated, then [consequence] happens to [stakeholder]. If the sentence works, I have an asset with a specific property and a damage scenario in one go. If it does not, I have an element of the architecture, and carrying it as an asset only inflates the analysis.

One pattern turns up more than any other: the asset list is really the component list from the Item Definition. Copied across, with a tick under confidentiality, integrity and availability in every row. A tick that appears everywhere says nothing. It still creates work, because each one drags threat scenarios behind it.

The headlamp example in Annex H shows how it is done. On the asset “data communication (lamp request)” only integrity is marked, not confidentiality and not availability, because the damage scenarios given there are about the lamp switching off unintentionally. The property follows the damage scenario, not your caution. Whether the confidentiality of a lamp request interests anyone is open to debate. Annex H skips the debate and leaves the tick out.

What the example picks as an asset in the first place is worth a look too: a data communication and a piece of firmware. Not a single ECU box. In my experience data flows and data end up being assets more often than components anyway, and that is the second reason a component list makes a poor starting point.

Whose Damage Counts?

The definition of a damage scenario names a stakeholder, and that word does more work than it looks like.

The stakeholder the standard aims at is the road user. The impact rating in ISO 21434 measures first and foremost what happens to a person in traffic. Annex H shows this nicely: one of the scenarios it rates has the drivers of oncoming vehicles blinded because the high beam no longer switches back. Those people never bought the car. They are still the yardstick.

Everything beyond that is voluntary. The OEM facing a recall, the fleet operator counting downtime, the supplier, the data subject in a privacy case: the standard requires none of them, and forbids none of them either. My advice would be to rate them from the start anyway.

That takes a tool which carries several stakeholders side by side instead of pinning you to one. In itemis SECURE the stakeholder is an object of its own, and the Impact Level is formed grouped by stakeholder and category: the same damage scenario carries several ratings at once, without you setting up the analysis a second time.

What the tool will not decide for you is which stakeholders you look at. If one analyst rates only the road user and the next also rates downtime at the fleet operator, you have two TARAs on two scales. The Impact Levels in them are no longer comparable, and everything built on top suffers, from the portfolio view to the evidence you put in front of an auditor. The awkward part: nobody will notice. Both analyses look consistent in themselves.

Fixing the set of stakeholders and the impact categories once, at organisation level, and reusing them from there is the least glamorous quality measure in this whole step and probably the one with the highest return.

Four Categories, Four Levels, One Number Security Cannot Set Alone

The damage of each damage scenario is rated in four categories, safety, financial, operational and privacy, on a scale of negligible, moderate, major and severe. One damage scenario can land in several categories at once.

Those four are fixed, but they are not a ceiling. If you want regulatory consequences or reputational damage tracked separately, add a fifth. And what counts as major and what counts as severe in your house is nobody else’s call. You only have to fix it once and then stick to it.

An Impact Level has to come out at the end, an IL. The individual ratings across all categories and stakeholders become one value, and only that value meets the attack feasibility to form the risk. How you aggregate is your decision, the maximum is the usual route.

The safety rating is not yours alone. Annex H rates the front collision as severe and writes S3 next to it, the severity class from functional safety. That puts a number from another discipline in the middle of your analysis.

Tuma and Widman count this among their seven pain points of TARA practice: a HARA only sees what breaks by itself, it cannot model an attacker at all. So safety and security have to coordinate, and that costs meetings.

I would rather fix the scale together before the first collision gets rated. The conversation is tedious. Without it, though, your TARA ends up carrying a safety number that nobody in safety knows about.

The Consistency Problem

Impact rating is, in my view, the most subjective step of the whole method, and I think it is better to say so than to dress it up.

Attack feasibility at least breaks down into factors: time, expertise, knowledge of the item, window of opportunity, equipment. Two people arguing about it find out what they are arguing about. With impact they do not. Somebody is judging consequences in the world, and two people who disagree usually stay that way. Tuma and Widman name exactly this as the reason automated quality checks on TARA results are so hard to build.

On top of that, the damage often cannot be determined locally at all. A manipulated data flow is nothing in itself. It gets interesting through the question of which function hangs off it and who uses that function. Braking assistance or interior lighting, one vehicle or a fleet of ten thousand: the same technical defect, entirely different damage. Pin the damage scenario to the element alone and you do not have that context, so you guess.

This is why modelling functions as assets pays off. The damage scenario then sits where the damage arises, and the data flow underneath inherits it through the dependency instead of having to claim it for itself.

What helps is shared catalogues. If a rating is defined once and every project that hits the same consequence refers to it, the rating gets argued out once instead of again in every TARA. The research Tuma and Widman cite points the same way: people without security expertise, working with catalogues, produced results comparable to those of experts working without them.

How far this can be taken is a question of its own. Catalogues for threats and controls are common, the damage side is thinner ground, and what you can actually use depends on the tool. Reusable catalogues have been part of the itemis argument for model-based TARA since our escar paper in 2022. The idea behind it holds at any level of build-out: what has been decided once should not be decided again in every project.

I would not claim a catalogue makes impact ratings objective. It makes them consistent, which is a different and far more achievable thing. Consistency is what makes ratings comparable across a portfolio.

The Same Step, Other Industries

This order of work is not an automotive quirk either. IEC 62443-3-2 opens its risk assessment with ZCR 2, a first estimate of the worst damage a compromise of the system under consideration could do, before any countermeasure is taken into account. It is described in terms of health and safety, property, information and business interruption, and all of it happens before the detailed per-zone work even starts. The tolerable risk is then held up against that consequence.

The vocabulary differs, the order is the same: work out what is at stake and for whom, then talk about the attack. With the Cyber Resilience Act it comes down to the same thing. The categories look different every time, the step itself cannot be skipped anywhere.

Why Use a Tool for This?

Everything I have described so far can be done in a spreadsheet. That is not a straw man: Tuma and Widman name the parameterised spreadsheet as the most prevalent mechanism for TARAs, and less has changed since then than you might assume. So the question is not whether it works. The question is what gets lost.

Assets hang off elements. When an asset sits on a function, component, channel, data flow or data item of the Item Definition instead of being typed into a row, the completeness check the standard requires turns into a query rather than a reading exercise: which elements carry no asset and why, which assets have no damage scenario, which damage scenarios were never rated. Those same queries are later the raw material for the report somebody has to write anyway.

Impact is computed, and it travels. In the engine I work on, the ratings of all damage scenarios belonging to a Security Objective are aggregated by a configurable formula, the maximum by default, into an Impact Level. And an objective that depends on another passes its impact down: if A depends on B and A has the higher IL, B inherits it. That propagation is the part I have never seen anyone do reliably by hand. A shared bus or a shared power supply inherits the impact of the most critical thing riding on it, and in a spreadsheet somebody has to remember that, every time, in every row.

Several stakeholders, one model. The Impact Level is formed from the individual ratings, grouped by impact category and stakeholder. That sounds like an implementation detail, but it decides whether you can go beyond the road user without overreaching. The standard does not require that step, and accordingly it is not a given in TARA tools. In a spreadsheet you either commit to one perspective or you set the analysis up a second time. The first loses damage, the second doubles the maintenance, and the two copies start drifting apart the day they exist. In a model the same damage scenario carries several ratings side by side, and that same grouping is what you slice and export the results by afterwards.

The vocabulary is configuration, not a constant. Cybersecurity properties and impact categories are objects, not hard-wired columns. Safety, financial, operational and privacy are the four the standard names, not the ceiling: if you want regulatory consequences or reputational damage tracked separately, you add a category instead of renegotiating a spreadsheet template. Same with the properties. Confidentiality, integrity and availability are the usual set, but if you want authenticity standing next to them as a fourth, because in your environment it carries its own class of attack, you add it. In a landscape of spreadsheets that addition means a new column in every existing file, which is why it mostly does not happen.

A lot of this can live at company level and travel into every project: assessment model, terminology, stakeholders, categories, catalogues. That is the substructure for the consistency I wrote about above. It does not come from everyone trying hard, it comes from everyone referring to the same objects.

Assumptions get a place of their own too. The standard lets the analysis assume information the Item Definition does not provide, and charges a price for it: accepting a risk on the basis of such an assumption calls for a documented cybersecurity claim. In a model an assumption is an object carrying a transformation that changes the damage or the effort in exactly the attack paths it applies to. Its effect on the rating stays visible instead of disappearing into a comment field.

Then there is the AI question I touched on in part one. An assistant that proposes damage scenarios for an asset, or checks an analysis for gaps, is only as good as the context it can query. Against a model of typed elements, catalogues and a stored ruleset it can work, and its proposals can be checked against that same ruleset before a person accepts or rejects them. Against a spreadsheet it is left guessing. That matters especially at this step, because a damage scenario is the place where a proposal most easily sounds plausible and is wrong anyway.

The point that matters most to me comes last. A TARA that stops at release is no use to you in the field. New vulnerabilities keep turning up there, and each one asks the same question: does this affect me, and how bad is it?

The first half of the answer comes from the SBOM. It tells you which component runs the affected package. The second half is exactly what this article is about: assets hang off the component, damage scenarios hang off the assets, and the impact hangs off those. With that chain drawn in the model, the tool can pull out the affected damage scenarios itself and compute the impact for them. Somebody still has to decide, but they decide over a list instead of over a hunch.

That is what people mean by a dynamic TARA. In a spreadsheet the chain does not exist. The vulnerability sits on one side, an impact value on the other, and in between sits a person who has to remember.

Conclusion

Asset identification and impact rating sound like bookkeeping and are the opposite. They set the scale every later step works on: which elements the threat analysis has to cover, whose damage the ratings measure, and how high the highest risk in the whole item can even go.

What I would take away: an element becomes an asset when you can name the property, the consequence and the stakeholder in one sentence, and not before. Properties get picked per damage scenario, not ticked across the board out of caution. The set of stakeholders and the impact categories belong to the organisation, not to the project. The safety rating is a shared number with the safety team. And ratings only stay comparable if the damage scenarios behind them are shared objects rather than freshly written prose in every TARA.

If you want to work this way as a model: itemis SECURE implements exactly this approach, from assets on the item model through damage scenario and impact catalogues to the calculated Impact Level that propagates through the analysis. Categories, properties and stakeholders are configuration there, not a frame you have to fit yourself into. If you would like to see what that looks like on a real item, reach me on LinkedIn or through itemis.com.

Part three takes the other half of the risk: identifying threat scenarios, and the completeness argument you can actually defend. And if you want the overview of the whole method before the details, it is in my introductory article What Is a TARA?.

One thing I would genuinely like to know: how do you keep your impact ratings comparable between projects? A shared catalogue, a board that calibrates them, or does every TARA argue severity out from scratch?