TARA Methodology - Step by Step - Automotive Cybersecurity

Step 1: Asset Identification

Pythontara_asset_identification.py

#!/usr/bin/env python3
# TARA Step 1: Asset identification per ISO/SAE 21434 Clause 15
# Damage scenario categories: Safety(S), Financial(F), Operational(O), Privacy(P)

tcu_assets = [
    {"id": "A-01", "asset": "ECU Firmware",
     "damage_categories": ["S", "F", "O"],
     "rationale": "Modified firmware could control brakes/steering (S); recall cost (F); loss of vehicle function (O)"},
    {"id": "A-02", "asset": "LTE Credentials (SIM/key)",
     "damage_categories": ["F", "O"],
     "rationale": "Stolen credentials allow fraudulent cellular usage (F); TCU cannot communicate (O)"},
    {"id": "A-03", "asset": "CAN Bus Access (gateway routing)",
     "damage_categories": ["S", "F", "O"],
     "rationale": "Attacker with CAN access can inject engine/brake commands (S)"},
    {"id": "A-04", "asset": "OTA Package Verification Key",
     "damage_categories": ["S", "F", "O"],
     "rationale": "Key compromise enables malicious firmware flash to all vehicles (S, F, O)"},
    {"id": "A-05", "asset": "Stored PII (location history, driver ID)",
     "damage_categories": ["P", "F"],
     "rationale": "GDPR violation risk (F); tracking of individual (P)"},
    {"id": "A-06", "asset": "UDS Diagnostic Session Authorization",
     "damage_categories": ["S", "F", "O"],
     "rationale": "Unauthorised extended session allows ECU reprogramming (S, F)"},
]

print(f"TCU Asset Register: {len(tcu_assets)} assets identified")
for a in tcu_assets:
    cats = "/".join(a["damage_categories"])
    print(f"  [{a['id']}] {a['asset']} — Damage: {cats}")
    print(f"    {a['rationale']}")
    print()

Step 2: Threat Scenario Identification via STRIDE

STRIDE Category	Example for TCU	Damage Scenario
Spoofing	Attacker spoofs V2X CAM message to falsely indicate obstacle → unnecessary AEB	Safety S3: false emergency braking at highway speed
Tampering	Attacker modifies OTA firmware package → malicious code installed	Safety S3: arbitrary vehicle control
Repudiation	Attacker erases UDS diagnostic log to hide evidence of intrusion	Financial F2: evidence destruction frustrates forensics
Information Disclosure	Attacker reads GPS history via Bluetooth GATT service without auth	Privacy P2: tracking of individual's movements
Denial of Service	Attacker floods LTE interface → OTA updates and remote diagnostics unavailable	Operational O3: loss of remote monitoring capability
Elevation of Privilege	Attacker exploits UDS session to reach ECU reprogramming level	Safety S3: reflash brake control ECU

Step 3: Attack Path Analysis

Pythonattack_path_afr_calculator.py

#!/usr/bin/env python3
# ISO/SAE 21434 Annex B: Attack Feasibility Rating (AFR) calculator

# Factor score tables per ISO/SAE 21434 Table B.5
ELAPSED_TIME = {
    "le_1_day": 0, "le_1_week": 1, "le_1_month": 2,
    "le_6_months": 3, "gt_6_months": 4
}
SPECIALIST_EXPERTISE = {
    "layman": 0, "proficient": 2, "expert": 4, "multiple_experts": 6
}
KNOWLEDGE_OF_TARGET = {
    "public": 0, "restricted": 3, "sensitive": 7, "critical": 11
}
WINDOW_OF_OPPORTUNITY = {
    "unlimited": 0, "easy": 1, "moderate": 4, "difficult": 10
}
EQUIPMENT = {
    "standard": 0, "specialized": 4, "bespoke": 7, "multiple_bespoke": 9
}

def calculate_afr(et, se, kt, woo, eq) -> tuple:
    score = (ELAPSED_TIME[et] + SPECIALIST_EXPERTISE[se] +
             KNOWLEDGE_OF_TARGET[kt] + WINDOW_OF_OPPORTUNITY[woo] +
             EQUIPMENT[eq])
    if score <= 13: level = "High"
    elif score <= 19: level = "Medium"
    elif score <= 24: level = "Low"
    else: level = "Very Low"
    return score, level

# TS-09: Remote attacker obtains valid UDS extended session
ap_09a = calculate_afr("le_1_month", "expert", "restricted", "easy", "standard")
print(f"AP-09A (LTE exploit): score={ap_09a[0]}, feasibility={ap_09a[1]}")

ap_09b = calculate_afr("le_1_day", "layman", "restricted", "easy", "standard")
print(f"AP-09B (social engineering + portal): score={ap_09b[0]}, feasibility={ap_09b[1]}")

# TS-04: OTA package tampering
ap_04a = calculate_afr("gt_6_months", "multiple_experts", "critical", "difficult", "bespoke")
print(f"AP-04A (forge OTA signature): score={ap_04a[0]}, feasibility={ap_04a[1]}")

Step 4: Risk Determination and Treatment

Risk Treatment	Condition	Example
Avoid	Remove the feature that creates the risk	Remove UDS remote programming session from production firmware
Reduce	Add countermeasure to lower feasibility or impact	Add mTLS + seed-key: remote session feasibility drops to Very Low
Transfer	Supplier or insurance bears the risk	Supplier contract: supplier liable for vulnerabilities in their component
Accept	Document residual risk with management sign-off	CVSS 3.2 Low risk accepted with monitoring plan and 180-day review

Risk Value Matrix (Impact × Feasibility)

              Very Low    Low    Medium    High
              Feasibility                 Feasibility
  S3/Critical   Low       Medium   High   Unacceptable
  S2/Severe     Low       Low     Medium  High
  S1/Moderate   Neglbl    Low      Low    Medium
  S0/No harm    Neglbl    Neglbl  Neglbl  Low

  Unacceptable: mandatory risk reduction before release
  High: reduce or accept with CISO sign-off
  Medium: reduce or accept with CS Manager sign-off
  Low/Negligible: accept with documented rationale

Summary

TARA is a structured four-step process: identify assets and their damage potential; apply STRIDE to generate threat scenarios; build attack paths and rate feasibility using AFR; compute risk from impact × feasibility and apply treatment. The AFR calculator is objective — factor scores from the ISO/SAE 21434 Annex B tables produce consistent feasibility ratings across teams. Every Unacceptable risk must be reduced to at least High with countermeasures before a vehicle can receive UNECE R155 type approval.

🔬 TARA Full Process — ISO/SAE 21434 Section 15

TARA (Threat Analysis and Risk Assessment) is the cybersecurity equivalent of HARA. It follows a structured process defined in ISO/SAE 21434:

Step 1 — Asset identification: List all items and components with cybersecurity-relevant properties. Assets have one or more of: confidentiality (e.g., private key), integrity (e.g., software image), availability (e.g., braking function), authenticity (e.g., OTA update source).
Step 2 — Threat scenario identification: For each asset, use STRIDE or similar: Spoofing (forge identity), Tampering (modify data), Repudiation (deny action), Information Disclosure, Denial of Service, Elevation of Privilege. Generate structured threat scenarios: "attacker spoofs OEM backend server certificate to inject malicious OTA update".
Step 3 — Impact rating (I): Rate the damage scenario on four dimensions: Safety (S: 0–3), Financial (F: 0–3), Operational (O: 0–3), Privacy (P: 0–3). The highest dimension determines the overall impact: Severe (3) → High (2) → Medium (1) → Negligible (0).
Step 4 — Attack feasibility (AF): Rate using the Attack Potential method (ISO/SAE 21434 Annex B): Elapsed Time, Specialist Knowledge, Window of Opportunity, Equipment. Or use the CVSS-based method for software vulnerabilities. Result: Very High → High → Medium → Low feasibility.
Step 5 — Risk determination: Risk = f(Impact, Attack Feasibility). The 21434 risk matrix maps this to: Critical, High, Medium, Low risk levels. Critical/High risks require cybersecurity goals with defined CAL (Cybersecurity Assurance Level 1–4).

🏭 TARA in Automotive Product Development

TARA scope: Modern OEMs conduct item-level TARA for each ECU function. A connected vehicle with OTA update, remote diagnostics, and V2X communication may have 200+ threat scenarios across 15 items in a single TARA document.
UNECE R155 requirement: Since July 2022 in Europe, new type approvals require a certified Cybersecurity Management System (CSMS) including documented TARA for all connected ECUs. Non-compliance means the vehicle cannot be type-approved for sale in the EU, UK, Japan, or South Korea.
CAL allocation: A threat scenario with CAL 4 (highest) requires the most rigorous cybersecurity requirement verification: code review, penetration testing, fuzzing. CAL 1 may require only design review. Correct CAL assignment directly drives project effort — over-assigning CAL 4 to low-risk items wastes significant engineering resources.

⚠️ TARA Common Mistakes

Asset identified at component level instead of function level: Identifying 'the CAN transceiver' as an asset instead of 'the integrity of brake torque command signals' misses the real damage scenario. Assets should map to damage scenarios, not hardware parts.
Impact rating based on likelihood: Like HARA severity, impact in TARA is the worst-case damage assuming the attack succeeds — not the probability of the attack. Conflating the two leads to under-rating high-impact/low-probability attacks.
Missing attack path through supply chain: A firmware-signed update from a compromised Tier-2 supplier with legitimate OEM certificates is a real attack path. TARA must consider supply chain attacks, not just direct vehicle access.
TARA not updated after design changes: ISO/SAE 21434 requires TARA to be maintained as a living document. Adding a new wireless interface (e.g., adding V2X after initial TARA) without a TARA update is a CSMS non-conformance finding.

📊 Industry Note

The most common TARA audit failure is missing traceability from threat scenario → cybersecurity goal → cybersecurity requirement → technical control. Auditors from TÜV and Bureau Veritas check that every high-risk scenario has a verifiable mitigating control in the design documentation.

🧠 Knowledge Check — Click each question to reveal the answer

❓ How does TARA risk determination differ from HARA ASIL determination?

✅ HARA uses S × E × C (Severity × Exposure × Controllability) mapped to a fixed ASIL table. TARA uses Impact × Attack Feasibility mapped to a risk matrix with results of Critical/High/Medium/Low risk. Key difference: HARA Exposure represents how often a situation occurs; TARA Attack Feasibility represents how difficult the attack is for a skilled attacker — these are fundamentally different axes. Also, TARA considers four damage dimensions (S/F/O/P) vs HARA's single severity.

❓ What is a Damage Scenario and how does it relate to a Threat Scenario in TARA?

✅ A Damage Scenario describes the adverse consequence to the vehicle, its occupants, or third parties if an asset's cybersecurity property is compromised. Example: 'Injury to vehicle occupants due to manipulation of brake control'. A Threat Scenario describes the specific attack that could lead to the damage scenario. Example: 'Attacker injects fake brake control CAN message via OBD port'. The damage scenario defines the Impact rating; the threat scenario defines the Attack Feasibility. One damage scenario may have multiple threat scenarios.

❓ A vehicle ECU has an OTA update interface. List three cybersecurity goals that a TARA would likely produce for this interface.

✅ (1) 'Only authenticated and integrity-verified firmware images shall be installed' — addresses tampering and spoofing of the update source (CAL 3–4). (2) 'The OTA update process shall not prevent the vehicle from entering a safe operational state' — addresses availability/denial-of-service during update (CAL 2–3). (3) 'Confidential vehicle data shall not be exfiltrated through the OTA communication channel' — addresses information disclosure through the update channel (CAL 2).