ISO 21434: Cybersecurity

TL;DR

ISO 21434 is the automotive cybersecurity engineering standard. It answers: “If an attacker compromises this system, what happens?” You start with TARA (Threat Analysis and Risk Assessment), map attack surfaces (OTA, telematics, Bluetooth, USB, OBD-II, WiFi), and implement defense in depth: secure boot, encrypted storage, signed updates, firewalls. Cybersecurity and functional safety (ISO 26262) are linked. A remote exploit that rewrites brake controller firmware is both a security incident and a safety hazard. Critical gotcha: a security vulnerability can become a safety hazard.

ISO 26262 asks what happens when software fails. ISO 21434 asks what happens when software is attacked. On a connected cockpit platform, those questions collide constantly. Your QNX/AAOS/AMSS stack is the battlefield.

TARA: The Cybersecurity Equivalent of HARA

TARA (Threat Analysis and Risk Assessment) is the ISO 21434 entry point. Structurally similar to HARA, but focused on malicious actors instead of random faults.

TARA Step	Question	Example
Asset identification	What must we protect?	VIN, encryption keys, OTA signing certs, brake ECU firmware
Threat scenario	Who attacks, how, why?	Remote attacker via telematics exploits TLS flaw, pushes malicious config
Attack path	What’s the kill chain?	Internet → modem (AMSS) → QNX gateway → CAN injection
Impact rating	Safety, financial, operational, privacy?	Safety: unintended braking; Privacy: location leak
Attack feasibility	How hard is it?	Expertise, time, equipment, knowledge of target
Risk treatment	Accept, reduce, transfer, avoid?	Reduce: network segmentation + signed CAN gateway rules
Cybersecurity goal	What must hold?	“Remote entities cannot inject unauthenticated vehicle control messages”

TARA outputs Cybersecurity Goals and Cybersecurity Requirements, the security parallel to ISO 26262’s safety goals and FSRs.

TARA and HARA share the same rhythm but different villains: HARA covers accidental hazards, TARA covers deliberate attackers.

Mental Model

If ISO 26262 is the fire code, ISO 21434 is the burglar alarm and lock policy. Fire codes assume accidents; security assumes someone is trying to get in. A connected car has more doors than a 1990 sedan — every wireless interface is a door that needs a lock, an alarm, and a log of who tried the handle.

Attack Surfaces on Your Platform

Every interface that accepts external input is an attack surface. On a QNX + AAOS + AMSS cockpit, you’re defending all of these simultaneously:

Surface	Entry Point	Typical Threat	Your Stack Touchpoint
OTA	Cloud → modem/AP → update agent	Malicious firmware flash	Signed images, A/B rollback, QNX + AAOS + modem partitions
Telematics	Cellular data session	Remote code execution, data exfiltration	AMSS/QMI path, QNX telematics daemon, firewall rules
Bluetooth	Phone pairing, A2DP, HFP	BlueBorne-class exploits, pairing MITM	AAOS Bluetooth stack, vendor hardening
USB	Media port, debug cable	BadUSB, malformed media parsers	AAOS USB host stack, mount policies
OBD-II	16-pin diagnostic port	Physical attacker with scan tool	DoIP/UDS gateway, security access seeds
WiFi	Hotspot, WiFi Direct	Rogue AP, KRACK-class attacks	AAOS wpa_supplicant, captive portal
CAN/Ethernet	In-vehicle buses (indirect)	Gateway bypass after AP compromise	QNX gateway filtering, MACsec on automotive Ethernet

flowchart LR
    subgraph External["External Attack Surfaces"]
        OTA["OTA Cloud"]
        CELL["Cellular / Telematics"]
        BT["Bluetooth"]
        USB["USB"]
        OBD["OBD-II"]
        WIFI["WiFi"]
    end

    subgraph AP["Application Processor"]
        AMSS["AMSS / MPSS"]
        QNX["QNX — Gateway · OTA agent · Safety VM"]
        AAOS["AAOS — IVI · Apps · BT/USB/WiFi"]
    end

    subgraph Vehicle["In-Vehicle"]
        CAN["CAN / Automotive Ethernet"]
        ECU["Safety ECUs · Actuators"]
    end

    OTA --> AMSS
    OTA --> QNX
    CELL --> AMSS
    AMSS --> QNX
    BT --> AAOS
    USB --> AAOS
    WIFI --> AAOS
    OBD --> QNX
    QNX --> CAN
    CAN --> ECU

Six major cockpit surfaces to defend: OTA, telematics, Bluetooth, USB, OBD, WiFi. If you can’t name the surface, you can’t defend it.

Defense in Depth: No Single Wall

ISO 21434 expects layered controls. If one layer fails, the next still holds. Same philosophy as ASIL decomposition, different adversary.

Layer	Control	What It Stops
Secure boot chain	Verified XBL → UEFI → hypervisor → VM images	Persistent implant at boot
Encrypted storage	LUKS/dm-crypt on userdata, hardware keystore	Offline data theft from stolen head unit
Signed updates	OEM code-signing on OTA packages	Malicious firmware from compromised CDN
Firewall / network segmentation	Modem VLAN, iptables/nftables on QNX, SELinux on AAOS	Lateral movement from IVI to gateway
Least privilege	Process capabilities, no root in production IVI	Post-exploit privilege escalation
Security Access (UDS 0x27)	Seed-key challenge on diagnostic writes	Unauthorized OBD reprogramming
Intrusion detection / logging	Secure log pipeline, anomaly alerts	Silent persistent compromise

Secure boot on Qualcomm platforms (Module 5) is your first line. If the attacker can’t persist at the firmware level, remote exploits become session-only (still bad, but recoverable on reboot).

CSMS vs. Product Cybersecurity

ISO 21434 distinguishes CSMS (Cybersecurity Management System), the organizational process for ongoing security, from product-level TARA and requirements for each item. Your Tier-1 supplier maintains a CSMS; each ECU/domain controller ships with a Cybersecurity Case documenting TARA, controls, and verification. Auditors check both: “Do you have a process?” and “Did you apply it to this product?”

How Cybersecurity Interacts With Safety

This is where Module 9.1 and 9.2 meet. ISO 26262 and ISO 21434 explicitly require coordination:

Scenario	Security Classification	Safety Classification	Joint Response
IVI app crash from bad media file	Security: low (availability)	Safety: none (QM domain)	Standard bug fix
Remote exploit of AAOS Bluetooth stack	Security: critical (RCE)	Safety: potential if gateway reachable	Patch + verify FFI still holds
Attacker reprograms brake ECU via OBD	Security: critical (integrity)	Safety: ASIL D hazard	Recall + gateway hardening + key rotation
Telematics data leak (location history)	Security/privacy: high	Safety: none directly	Privacy notification, encryption fix

The interface between QM (AAOS) and safety (QNX/gateway) is the highest-risk junction. Security analysis must ask: “If AAOS is fully compromised, can the attacker reach the CAN gateway or safety VM?” The answer should be no, enforced by hypervisor memory maps, network rules, and authenticated IPC, with test evidence (penetration test reports, fuzz results).

Common Gotcha

A security vulnerability can become a safety hazard. Remote code execution in AAOS is “just” a security CVE on a phone. In a car, if that RCE reaches the QNX gateway or injects CAN frames, it’s a safety hazard requiring HARA re-evaluation, potential ASIL impact analysis, and coordinated recall planning. Never file security bugs as “low priority cosmetic” without tracing the attack path to vehicle actuators.

Connect the Dots

Module 5’s verified boot chain is a cybersecurity control that also supports safety-of-intended-function. Module 6’s hypervisor FFI is the safety boundary that cybersecurity must not breach. Module 7’s telematics and OTA are primary TARA attack paths. Module 8’s flash procedures must preserve signing and rollback protections. Module 9.4’s UDS SecurityAccess is the diagnostic-layer lock on OBD-II.

The short version

1. TARA maps threats to cybersecurity goals (the HARA of malicious actors).
2. Six major cockpit surfaces: OTA, telematics, Bluetooth, USB, OBD-II, WiFi.
3. Defense in depth: secure boot, encryption, signing, firewalls, least privilege.
4. Security ↔ safety coordination. Exploits that reach actuators are both CVEs and hazards.
5. QM compromise must not imply safety compromise. FFI is a security requirement too.

Where You'll See This

When a security researcher or pen-test report lands on your desk:

1. Trace the attack path: entry surface → AP component → does it cross into QNX/gateway/CAN?
2. Classify dual impact: CVE severity and potential safety hazard if gateway is reachable.
3. Check containment: hypervisor memory map, firewall rules, VHAL input validation still hold?
4. Coordinate fix ownership: AAOS patch (Google/vendor), QNX gateway rule (your team), modem (AMSS update)?

For OTA updates, verify signature check is never bypassed in your release pipeline. A “test key” left in production builds is a career-ending TARA failure. Grep your build configs for SIGN, AVB, and SECURE_BOOT flags before every release candidate.

Check Your Understanding

1. What is TARA in the context of ISO 21434?

A. A diagnostic protocol for reading trouble codes over EthernetB. Threat Analysis and Risk Assessment — identifying assets, threats, attack paths, and risk treatmentC. The ASIL lookup table for severity and exposureD. A Qualcomm modem firmware update mechanism

2. An attacker achieves remote code execution in AAOS via a Bluetooth stack vulnerability. Why must this be evaluated for safety impact, not just security severity?

A. Bluetooth is always ASIL DB. A compromised QM domain may provide an attack path to QNX gateway or vehicle buses, turning a security exploit into a potential safety hazardC. ISO 21434 requires all Bluetooth bugs to trigger vehicle recallD. AAOS is ASIL D certified

3. Which defense-in-depth control directly prevents flashing unsigned firmware during OTA?

A. CAN bus termination resistorsB. Code signing and verified boot — rejecting images without valid OEM signatureC. Disabling Bluetooth pairingD. Running cluster in AAOS for faster updates