ISO/SAE 21434 TARA: Step-by-Step Implementation Guide

Threat Analysis and Risk Assessment (TARA) is the cornerstone process of ISO/SAE 21434. It systematically identifies cybersecurity threats to vehicle components, evaluates their risk, and determines appropriate security measures. Despite its importance, many engineering teams struggle with practical implementation beyond spreadsheet-based approaches.

This step-by-step guide walks through the complete TARA workflow as defined in ISO/SAE 21434 Clause 15, with real automotive examples at each stage.

TARA in the ISO/SAE 21434 Lifecycle

TARA is not a one-time activity. ISO/SAE 21434 requires TARA during concept phase (Clause 9), product development (Clause 10), and throughout production and operations (Clauses 12–13). Each phase refines the initial analysis as the design matures and new information becomes available.

The most common mistake we see is treating TARA as a document to produce rather than a living process. Teams create a TARA spreadsheet during concept phase and never update it as the architecture evolves through development.

Step 1: Asset Identification

The first step identifies assets that need protection. In ISO/SAE 21434 terminology, these are items whose compromise would impact cybersecurity properties (confidentiality, integrity, availability, authenticity).

What Counts as an Asset?

• Functions: Safety-critical functions (emergency braking, steering assist), security functions (key management), and privacy-sensitive functions (location tracking, driver profiling).
• Data: Cryptographic keys, calibration data, personal data, firmware images, and communication messages.
• Interfaces: Network interfaces (CAN, Ethernet), wireless interfaces (Bluetooth, Wi-Fi, cellular), physical interfaces (OBD-II, USB, debug ports), and cloud APIs.
• Hardware: ECUs, sensors, actuators, gateways, HSMs, and memory devices.

Example: ADAS Camera ECU

For an Advanced Driver Assistance System forward-facing camera ECU, assets include:

• Object detection function (safety-critical)
• Camera calibration parameters (integrity-sensitive)
• Firmware image (integrity and authenticity)
• CAN interface to vehicle bus (availability-critical)
• Ethernet interface for firmware updates (integrity-critical)
• Debug JTAG interface (access control)

Step 2: Threat Identification

For each asset, identify potential threats using STRIDE or another systematic methodology.

STRIDE Applied to ADAS Camera

• Spoofing: Attacker injects false CAN messages mimicking the camera ECU, providing fake detection data to the ADAS controller.
• Tampering: Attacker modifies calibration parameters through the diagnostic interface, causing misaligned object detection.
• Repudiation: Firmware modifications cannot be attributed due to lack of audit logging.
• Information Disclosure: Raw camera images transmitted unencrypted over Ethernet enable extraction of driver monitoring data.
• Denial of Service: CAN bus flooding prevents the camera ECU from transmitting detection results.
• Elevation of Privilege: Attacker gains access through the debug interface and reprograms the ECU.

Step 3: Impact Assessment

Assess impact across four dimensions defined in ISO/SAE 21434:

• Safety: Could the threat lead to physical harm? ADAS camera tampering could cause incorrect braking decisions — potentially life-threatening.
• Financial: Direct costs (recalls, lawsuits, fines) and indirect costs (warranty claims, lost sales). A fleet-wide calibration attack could trigger mass recalls.
• Operational: Impact on vehicle functionality. DoS on the camera bus degrades ADAS but the vehicle remains drivable.
• Privacy: Exposure of personal data. Unauthorized camera access is a direct GDPR violation.

Impact is rated on a scale (Negligible, Moderate, Major, Severe) for each dimension. The overall rating is the highest individual rating.

Step 4: Attack Feasibility Assessment

ISO/SAE 21434 Annex G provides two approaches:

Attack Potential-Based Approach

Rates feasibility based on five factors:

1. Elapsed time: How long does the attack take? (hours to months)
2. Specialist expertise: What knowledge level? (layman to multiple experts)
3. Knowledge of the item: How much design information needed? (public to critical)
4. Window of opportunity: How much access required? (unlimited to difficult)
5. Equipment: What tools needed? (standard to multiple bespoke)

CVSS-Based Approach

Maps CVSS v3.1 base metrics to automotive context. Preferred for teams familiar with IT vulnerability scoring.

Step 5: Risk Determination

Combine impact and feasibility using a risk matrix. A typical 4×4 matrix yields:

• Risk Level 1 (Acceptable): No additional measures required.
• Risk Level 2 (Low): Monitor and consider measures during design refinement.
• Risk Level 3 (Medium): Security measures required with documented treatment decision.
• Risk Level 4 (High): Security measures mandatory, must demonstrate risk reduction.

Step 6: Risk Treatment

For each unacceptable risk, choose a treatment option:

• Avoid: Remove the functionality creating the risk.
• Reduce: Implement security controls to lower impact or feasibility.
• Transfer: Move risk to another party (insurance, supplier contracts).
• Accept: Formally accept residual risk with management sign-off.

Security Controls for ADAS Camera

• SecOC for CAN messages (addresses Spoofing, Tampering)
• Authenticated diagnostic access with certificate-based identity
• Secure boot chain with measured boot
• Encrypted Ethernet communication with TLS
• CAN bus intrusion detection (addresses DoS)
• JTAG disabled in production (addresses EoP)
• Audit logging to secure storage (addresses Repudiation)

Common TARA Pitfalls

• Too generic: Threats like “attacker compromises ECU” are not actionable. Be specific about the attack vector, target, and property violated.
• Inconsistent granularity: Analyzing some components at function level and others at interface level makes risk comparison meaningless.
• Static analysis: TARA must be updated when architecture changes. Tools like ThreatZ ensure new interfaces trigger re-analysis.
• Missing traceability: Every security requirement must trace to a threat, and every control must trace to a requirement.

Key Takeaways

• TARA is a living process, not a one-time document. It must be updated as the architecture evolves.
• Asset identification should cover functions, data, interfaces, and hardware at consistent granularity.
• STRIDE provides a systematic framework for automotive threat identification.
• Impact assessment spans safety, financial, operational, and privacy dimensions.
• Attack feasibility uses attack-potential or CVSS-based scoring.
• Risk treatment must produce traceable security requirements mapping to verifiable controls.