The problem
Connected EVs expose remote unlock, charging control and over-the-air updates through a telematics unit and cloud services, creating paths for attackers to reach vehicle functions. ISO/SAE 21434 requires a TARA to decide which risks to treat and how. Students rarely apply the method end to end. This project produces a complete, traceable TARA for a realistic connected function set.
Objectives
- Define the item: telematics control unit, gateway, mobile app and backend interfaces.
- Identify assets with their cybersecurity properties and derive damage scenarios.
- Identify threat scenarios with STRIDE and build attack paths.
- Rate impact and attack feasibility and determine risk values.
- Choose risk treatment and write cybersecurity goals and claims.
What you need
Tools and toolboxes
- Spreadsheet (Excel or LibreOffice Calc) — Holds asset, damage, threat, attack path, feasibility and risk tables with traceable IDs.
- Microsoft Threat Modeling Tool or OWASP Threat Dragon — Draws data-flow diagrams and supports STRIDE threat identification.
- A diagramming tool (draw.io or similar) — Draws the item architecture and attack trees.
- Wireshark (optional) — Inspects example protocol traffic such as MQTT or HTTPS handshakes to ground threat descriptions.
Software
- Spreadsheet software
- OWASP Threat Dragon or Microsoft Threat Modeling Tool
- A diagramming tool
Extra parts and data
None beyond the software above.
Key concepts
- Asset and cybersecurity property
- Something of value, such as the remote unlock command or charging schedule, together with the property to protect: confidentiality, integrity or availability.
- Damage scenario
- An adverse consequence for road users or the owner, such as the vehicle being unlocked by a stranger, rated for safety, financial, operational and privacy impact.
- Attack feasibility
- How hard an attack is, rated from factors such as elapsed time, expertise, knowledge of the item, window of opportunity and equipment.
- Cybersecurity goal
- A top-level requirement to protect assets against threat scenarios whose risk is to be reduced.
Step-by-step guide
- 1
Define the item
Describe the functions in scope: remote lock and unlock, remote climate pre-conditioning, charging schedule and status, vehicle location and OTA update notifications. Draw the item boundary with the telematics control unit, central gateway, body and charging ECUs on CAN, the cellular link, the backend and the mobile app. State assumptions such as the backend being out of scope except for its interfaces.
Checkpoint: An item definition with a boundary diagram and listed interfaces and assumptions.
- 2
Draw the data-flow diagram
In Threat Dragon or the Microsoft tool, draw processes (TCU firmware, gateway routing, app), data stores (credentials, logs), data flows (cellular to backend, TCU to gateway over CAN, Bluetooth to phone) and trust boundaries (vehicle versus internet, TCU versus in-vehicle network). Label each flow with its protocol and data. This diagram drives threat identification. Mark which flows cross trust boundaries, since these get the most attention in threat identification.
Checkpoint: A data-flow diagram with every flow labelled and trust boundaries marked.
- 3
Identify assets and damage scenarios
List assets with their properties: remote unlock command (integrity), vehicle location (confidentiality), charging schedule (integrity, availability), TCU firmware (integrity), user credentials (confidentiality). For each, write damage scenarios, such as unauthorised unlock leading to theft, or charging disabled leaving the owner stranded. Rate impact in safety, financial, operational and privacy categories with justifications. Have a second person check the impact ratings for consistency across categories.
Checkpoint: An asset table and damage scenario table with impact ratings and justifications.
- 4
Identify threat scenarios
Apply STRIDE to each element and flow crossing a trust boundary: spoofing the backend to the TCU, tampering with CAN messages from a compromised TCU, repudiation of remote commands, information disclosure of location, denial of service on the cellular link and elevation of privilege from infotainment to the gateway. Link each threat scenario to the damage scenarios it can cause.
Checkpoint: A threat scenario table linked to assets and damage scenarios by ID.
- 5
Build attack paths
For the most serious threat scenarios, build attack trees showing step-by-step paths, for example obtain app credentials by phishing, send unlock through backend; or exploit a TCU service, pivot to CAN, inject an unlock frame. Note preconditions at each step, such as physical access or proximity. Keep each path concrete enough to rate but do not produce exploit details. Note where one step enables several paths, since controlling that step reduces many risks.
Checkpoint: Attack trees for the top threat scenarios with preconditions per step.
- 6
Rate attack feasibility
Rate each attack path using the attack potential approach: elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment, summing to a feasibility level of high, medium, low or very low. Write a justification for each factor. Compare remote paths with paths needing physical access, which usually have lower feasibility because of the window of opportunity. Keep the rating tables in the method sheet so every value can be traced to its factors.
Checkpoint: Feasibility ratings with factor-level justifications for every attack path.
- 7
Determine risk values
Combine impact and feasibility into a risk value using a risk matrix defined in your method sheet, for example values from 1 to 5. Record the risk for each threat scenario using its highest-feasibility path. Review the top risks with the team and check that they match engineering intuition; investigate any surprising result before accepting it. Record the risk matrix and its rationale in the method sheet for reviewers.
Checkpoint: A risk table with values for every threat scenario and a sorted top-risk list.
- 8
Decide risk treatment
For each threat scenario, choose a treatment: reduce, share, avoid or retain, with a reason. For reduced risks, write cybersecurity goals such as the vehicle shall accept remote unlock commands only if they are authenticated and fresh. For retained risks, write cybersecurity claims explaining why the residual risk is acceptable. Keep traceability from goal to threat scenario. Check that every reduced risk has at least one goal and every goal traces back to a threat.
Checkpoint: A treatment table with goals and claims traced to threat scenarios.
- 9
Derive example controls
For the top goals, sketch example controls without full design: mutual TLS between TCU and backend, signed and time-limited commands, SecOC on safety-relevant CAN frames from the gateway, firewall rules in the gateway, secure boot on the TCU and rate limiting. Re-rate feasibility assuming each control is in place to show expected residual risk. Note controls that address several goals, since they give the most value for effort.
Checkpoint: A table of controls per goal with re-rated feasibility and residual risk.
- 10
Report
Present the item, data-flow diagram, assets, damage scenarios, threats, attack paths, feasibility and risk ratings, treatment decisions, goals, claims and example controls. Explain the method choices and rating scales. State limitations: assumed architecture, no penetration testing and student-level knowledge of attacker capability. Note how the TARA would be revisited during development and after vulnerabilities are reported. Add a short executive summary listing the top risks and their treatment.
Checkpoint: A complete, traceable TARA report with method, results and limits.
Testing & validation
- Every flow crossing a trust boundary analysed with STRIDE.
- Every threat scenario linked to assets and damage scenarios.
- Feasibility ratings justified factor by factor.
- Every threat scenario has a treatment decision; reduced risks have goals.
- Residual risk re-rated with example controls.
Expected results
A complete ISO/SAE 21434 TARA for connected EV telematics functions, with traceable threats, rated risks, cybersecurity goals and claims, and residual risk after example controls.
Take it further
- Extend to the charging interface between vehicle and charger.
- Derive cybersecurity requirements for the gateway from the goals.
- Test CAN intrusion detection on the HCRL Car-Hacking dataset for a related threat.
- Compare results with a second rating method and discuss differences.
Viva and review questions
Why are remote attack paths often rated more feasible than physical ones?
They can be attempted at scale from anywhere at any time, while physical attacks need access to a particular vehicle.
What is the difference between a cybersecurity goal and a claim?
A goal requires protection to reduce risk; a claim records why a retained or shared risk is acceptable without further reduction.
Why use a data-flow diagram before STRIDE?
Threats arise on elements and flows, especially across trust boundaries, so the diagram makes sure each is examined systematically.
Is the TARA done once?
No, it is updated as the design changes and when new vulnerabilities or threat information appear during the vehicle's life.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.