TARA (Threat Analysis and Risk Assessment)

What is TARA?

A TARA (Threat Analysis and Risk Assessment) is the risk analysis method that ISO/SAE 21434 prescribes for a vehicle item or component. It takes an item definition, works out what in it is worth protecting, how an attacker could damage it, how bad that would be and how hard it would be, and turns the answer into a risk value and a treatment decision. The cybersecurity goals and later the cybersecurity requirements are derived from it, so everything an ECU security test checks eventually traces back to a line in the TARA.

Where is it defined?

ISO/SAE 21434:2021 clause 15 defines the methods: asset identification (15.3), threat scenario identification (15.4), impact rating (15.5) in the categories safety, financial, operational and privacy on the scale negligible, moderate, major and severe, attack path analysis (15.6), attack feasibility rating (15.7) using the attack-potential, CVSS-based or attack-vector-based approach, risk value determination (15.8) on a scale from 1 to 5, and risk treatment decision (15.9): avoid, reduce, share or retain. Clause 9 (concept phase) applies these methods to produce the cybersecurity goals, and clause 8 triggers a re-assessment when monitoring or vulnerability analysis finds something new. UN R155 paragraph 7.3 requires a risk assessment for the vehicle type and points to the threat list in its Annex 5 Part A.

What it means in practice

A TARA is a document and a set of tables, usually with a few hundred rows for a complex ECU. The rows that matter for testing are the attack paths and the controls assumed to block them: “diagnostic write to calibration DIDs requires SecurityAccess level 3”, “the programming session is not reachable without an authenticated tester”, “the gateway blocks diagnostic requests from the infotainment network”. Each of those is a claim about ECU behaviour that a bench test can confirm or refute.

When we did the TARA, item definition and cybersecurity concept for an ADAS component at a Tier-1, the most useful moment was reading the first penetration-test results against the attack-feasibility ratings. Several paths rated “high effort” turned out to be low effort because a SecurityAccess seed was constant and the key followed from it with a short constant. The TARA was not wrong; it was untested. The feasibility ratings were corrected, the risk values moved, and two requirements were added.

How AutoST tests it

AutoST does not produce a TARA, but it tests the attack paths a TARA assumes to be closed on the diagnostic and bus side: services reachable in default session, DIDs writable without SecurityAccess, seed/key weaknesses, missing lockout, DoIP routing to ECUs that should be blocked, SOME/IP services without authentication. Each finding carries a severity and a fix, and the Fix Plan has a reference field that links it to the requirement or TARA row it concerns, so the feasibility ratings can be corrected with evidence instead of opinion.

Common misunderstandings

A TARA is not a penetration test and a penetration test is not a TARA. The first is analysis of what could happen; the second is evidence of what does happen. A TARA whose feasibility ratings have never been checked on a real ECU is a list of assumptions, and auditors increasingly ask for the tests behind the ratings.