ISO/SAE 21434 — Cybersécurité des véhicules routiers

🌐 Contexte et pourquoi cette norme existe

Avant 2021, il n'existait aucun standard international dédié à la cybersécurité automobile. Les véhicules modernes embarquent des dizaines à des centaines d'ECUs (Electronic Control Units), communiquent via des protocoles réseau (CAN, Ethernet, LIN), se connectent à l'internet, se mettent à jour à distance (OTA). La surface d'attaque est donc devenue comparable à celle d'un réseau d'entreprise — mais avec des conséquences potentiellement physiques (prise de contrôle du freinage, des airbags, de la direction).

Plusieurs incidents ont accéléré cette prise de conscience :

• 2015 — Jeep Cherokee hack : des chercheurs (Miller & Valasek) ont pris le contrôle à distance d'une Jeep via son système de divertissement connecté au CAN bus. 1,4 million de véhicules rappelés.
• 2016 — Tesla Model S : Keen Security Lab a compromis à distance le véhicule via le Wi-Fi.
• 2019-2020 : multiplication des attaques sur les systèmes d'information des constructeurs (fournisseurs, réseaux de concessions).

Histoire de la norme

Année	Événement
2016	Lancement des travaux conjoints entre SAE International (États-Unis) et ISO (Genève)
2019	Publication de la version préliminaire (ISO/SAE DIS 21434)
Août 2021	Publication officielle de l'ISO/SAE 21434:2021
2022	Entrée en vigueur de l'UN R155 qui s'appuie dessus pour les nouveaux modèles
2024+	Déploiement généralisé dans toute la supply chain automobile

Qui l'a produit

La norme est co-publiée par :

• ISO (Organisation Internationale de Normalisation)
• SAE International (Society of Automotive Engineers — organisation américaine)

C'est une norme volontaire mais qui est devenue de facto obligatoire pour tout acteur voulant vendre des composants aux constructeurs soumis à l'UN R155.

📐 Périmètre et objectifs

Ce que couvre la norme

ISO/SAE 21434 s'applique à l'ensemble du cycle de vie cybersécurité des systèmes électriques/électroniques embarqués dans les véhicules routiers (voitures, camions, motos, véhicules utilitaires).

Elle couvre :

• Les ECUs (calculateurs électroniques)
• Les bus de communication internes (CAN, LIN, FlexRay, Ethernet embarqué)
• Les interfaces de communication externe (V2X, Wi-Fi, Bluetooth, 4G/5G, USB)
• Les mises à jour logicielles (OTA — Over The Air)
• Les systèmes de gestion de flotte et les backends cloud

Ce qu'elle ne couvre pas

• La cybersécurité des systèmes informatiques de production (usines) — c'est l'IEC 62443
• La sécurité fonctionnelle (safety) — c'est l'ISO 26262 (ASIL)
• Les infrastructures routières et smart cities

À noter : ISO 21434 et ISO 26262 sont complémentaires. La première adresse la cybersécurité (confidentialité, intégrité, disponibilité face aux attaquants), la seconde la sécurité fonctionnelle (comportement en cas de défaillance technique). Un véhicule peut être "safe" mais pas "secure", et vice versa.

Objectifs principaux

1. Établir un cadre commun pour la gestion de la cybersécurité automobile tout au long du cycle de vie produit
2. Faciliter la communication entre OEMs et fournisseurs autour d'un vocabulaire et de processus partagés
3. Définir des exigences pour le développement, la production, l'exploitation et le décommissionnement sécurisés
4. Supporter la conformité aux régulations légales (notamment UN R155)

🏗️ Structure de la norme

La norme compte 15 clauses principales. Voici la structure commentée :

ISO/SAE 21434:2021
│
├── Clauses 1-3   : Domaine d'application, références normatives, termes & définitions
│
├── Clause 4      : Généralités (principes fondamentaux)
│
├── Clause 5      : Gestion de la cybersécurité organisationnelle (CSMS)
│
├── Clause 6      : Gestion de projet cybersécurité
│
├── Clause 7      : Ingénierie cybersécurité distribuée (supply chain)
│
├── Clause 8      : Gestion des risques continus
│
├── Clause 9      : Activités de conception du concept
│                   └── TARA au niveau du concept
│
├── Clause 10     : Développement produit (niveau système)
│
├── Clause 11     : Développement produit (niveau hardware)
│
├── Clause 12     : Développement produit (niveau software)
│
├── Clause 13     : Intégration, vérification et validation cybersécurité
│
├── Clause 14     : Production
│
└── Clause 15     : Opérations & maintenance / Fin de vie

Les clauses 5 à 15 contiennent les exigences réelles. On les regroupe souvent en 4 grandes phases :

Phase	Clauses	Ce qui se passe
Gouvernance	5, 6, 7	CSMS, pilotage projet, gestion fournisseurs
Conception	8, 9	Analyse de risques (TARA), objectifs cybersécurité
Développement	10, 11, 12, 13	Conception sécurisée, tests, validation
Post-production	14, 15	Fabrication sécurisée, opérations, incident response, fin de vie

💡 Concepts fondamentaux

🎯 L'actif (Asset)

Un actif est tout élément qui a de la valeur et qui peut être compromis par une cyberattaque.

En automobile, les actifs sont typiquement :

• Des données (données conducteur, clés cryptographiques, firmware)
• Des fonctions (contrôle du freinage, démarrage du moteur, déverrouillage des portes)
• Des propriétés opérationnelles (disponibilité du système de direction assistée)

🔒 Les propriétés de cybersécurité (CAL)

ISO/SAE 21434 utilise le triptyque classique adapté au contexte automobile :

Propriété	Signification	Exemple automobile
Confidentiality	Les données ne sont accessibles qu'aux entités autorisées	Clés cryptographiques d'une ECU
Integrity	Les données/fonctions ne peuvent être modifiées que par des entités autorisées	Firmware d'un calculateur de freinage
Availability	Le système est disponible quand nécessaire	Système d'airbag actif en permanence

Une quatrième propriété spécifique à l'automobile s'ajoute souvent :

• Authenticity : les communications entre ECUs sont authentifiées (l'ECU du tableau de bord est bien celle qu'elle prétend être)

📊 Le Cybersecurity Assurance Level (CAL)

Le CAL est le niveau d'assurance cybersécurité requis pour un composant, de CAL 1 (faible risque) à CAL 4 (risque critique). Il est analogue à l'ASIL (Automotive Safety Integrity Level) de l'ISO 26262.

Le CAL est déterminé à partir de la TARA (voir section 5) et influence la rigueur des processus de développement et de validation requis.

CAL 4 → Freinage, direction, airbags
CAL 3 → Systèmes ADAS (aide à la conduite)
CAL 2 → Connectivité, portières, toit ouvrant
CAL 1 → Systèmes infotainment isolés, éclairage basique

⚔️ Threat Scenario vs Attack Path

• Threat Scenario : description d'un scénario où un actif est compromis et d'un impact potentiel. Ex : "Un attaquant modifie le firmware de l'ECU de freinage via une interface OBD-II non sécurisée."
• Attack Path : la séquence technique précise permettant de réaliser un Threat Scenario. Ex : connexion OBD → bypass authentification → injection de commandes CAN → désactivation ABS.

🔍 TARA — Threat Analysis and Risk Assessment

La TARA est le cœur analytique de la norme. C'est l'équivalent de l'EBIOS RM dans le monde automobile. Elle est décrite dans la clause 9 et s'effectue en plusieurs étapes successives.

Étape 1 — Définition du périmètre (Item Definition)

On définit l'Item : le système ou composant à analyser (ex : "l'ECU de gestion du moteur", ou "le système de télématique").

On décrit :

• Les fonctions de l'item
• Les interfaces (quels signaux entre, quels signaux sort, vers quels autres systèmes)
• L'environnement opérationnel (le véhicule, le backend cloud, les mises à jour OTA)

Étape 2 — Identification des actifs

Pour chaque fonction/interface, on identifie les actifs et leurs propriétés de cybersécurité (CIA + Authenticity) à protéger.

Ex pour un système de télématique :

• Actif : données GPS de géolocalisation → Confidentiality
• Actif : canal de mise à jour OTA → Integrity + Authenticity
• Actif : disponibilité du service d'urgence eCall → Availability

Étape 3 — Évaluation de l'impact (Impact Rating)

Pour chaque actif, on évalue la sévérité de l'impact si sa propriété est violée, selon 4 catégories :

Catégorie	Description	Exemple
Safety	Impact sur la sécurité physique des personnes	Désactivation des airbags → blessures graves
Financial	Pertes financières directes ou indirectes	Rappel massif de véhicules
Operational	Perturbation des opérations	Immobilisation d'une flotte de camions
Privacy	Atteinte à la vie privée	Fuite des données de géolocalisation

Chaque catégorie est notée sur 4 niveaux : Négligeable / Modéré / Sévère / Critique.

Étape 4 — Identification des Threat Scenarios

On liste tous les scénarios de menace plausibles pour chaque actif. Cela s'appuie souvent sur des catalogues de menaces (STRIDE, catalogues internes constructeur).

STRIDE (méthode Microsoft adaptée à l'automobile) :

• Spoofing — usurpation d'identité d'une ECU
• Tampering — modification non autorisée du firmware
• Repudiation — impossibilité de tracer une action malveillante
• Information Disclosure — fuite de données
• Denial of Service — rendre un système indisponible
• Elevation of Privilege — obtenir des droits non autorisés sur le bus CAN

Étape 5 — Évaluation de la faisabilité d'attaque (Attack Feasibility)

Pour chaque Threat Scenario, on détermine à quel point l'attaque est réalisable en pratique. L'ISO/SAE 21434 propose deux méthodes :

Méthode CVSS-like (Attack Potential) basée sur :

• Temps nécessaire pour réaliser l'attaque
• Expertise requise de l'attaquant
• Connaissance du système cible
• Fenêtre d'opportunité (accès physique nécessaire ?)
• Équipements nécessaires

Résultat : Faisabilité Très basse / Basse / Moyenne / Haute

Étape 6 — Niveau de risque et décision

Niveau de risque = Impact × Faisabilité d'attaque

Pour chaque risque, on choisit un traitement :

Traitement	Description
Éviter	Supprimer la fonctionnalité à risque
Réduire	Mettre en place des contrôles de sécurité (objectifs cybersécurité)
Partager	Transférer le risque à un tiers (assurance, fournisseur)
Accepter	Accepter le risque résiduel si le niveau est jugé tolérable

Étape 7 — Objectifs et exigences cybersécurité

Les risques à réduire génèrent des Cybersecurity Goals (objectifs de haut niveau), qui sont ensuite déclinés en Cybersecurity Requirements (exigences techniques) pour les équipes de développement.

Ex :

• Goal : "L'intégrité du firmware de l'ECU de freinage doit être assurée"
• Requirement : "Tout firmware doit être signé cryptographiquement avec une clé RSA 2048 bits minimum et vérifié avant installation"

⚙️ Le Cybersecurity Management System (CSMS)

Définition

Le CSMS est le système de management organisationnel qui encadre toutes les activités de cybersécurité de l'entreprise tout au long du cycle de vie des produits. Il est décrit dans la clause 5.

C'est l'équivalent du SMSI (Système de Management de la Sécurité de l'Information) de l'ISO 27001, mais orienté produit automobile plutôt qu'IT d'entreprise.

Composantes du CSMS

CSMS
├── Politique cybersécurité
│   └── Engagement de la direction, objectifs, responsabilités
│
├── Gestion des compétences
│   └── Formation, conscience cybersécurité, ressources humaines
│
├── Gestion des risques continus (Clause 8)
│   └── Suivi des risques post-production, veille CVE, monitoring
│
├── Gestion des incidents
│   └── Détection, réponse, forensique, communication
│
├── Gestion des fournisseurs (Clause 7)
│   └── Exigences cybersécurité transmises dans la supply chain
│
└── Amélioration continue
    └── Audits internes, lessons learned, mise à jour des processus

Pourquoi le CSMS est central

Le CSMS est la condition sine qua non pour être conforme à l'UN R155. Les constructeurs doivent démontrer à leur autorité nationale qu'ils ont un CSMS opérationnel avant d'obtenir la réception de type de leurs nouveaux modèles.

Et les équipementiers doivent démontrer à leurs clients constructeurs que leur propre CSMS est solide, via des audits, des certifications ou des questionnaires de conformité.

🔄 Cycle de vie produit et phases

ISO/SAE 21434 couvre l'intégralité du cycle de vie d'un composant automobile, de la conception à la mise à la casse.

Phase 1 — Concept (Clause 9)

• Définition de l'item (périmètre fonctionnel)
• Réalisation de la TARA
• Définition des Cybersecurity Goals
• Décision de poursuivre le développement ou de modifier le concept

Phase 2 — Développement produit (Clauses 10-12)

Le développement s'effectue en cascade depuis le niveau système jusqu'au niveau logiciel :

Niveau Système (Clause 10)
│   → Architecture cybersécurité, interfaces sécurisées, protocoles
│
Niveau Hardware (Clause 11)
│   → Composants physiques : HSM (Hardware Security Module), TPM,
│     protections contre attaques side-channel
│
Niveau Software (Clause 12)
    → Secure coding guidelines, gestion des secrets, crypto,
      boot sécurisé (Secure Boot), gestion des clés

Concepts clés du développement sécurisé :

• Secure Boot : vérification cryptographique de chaque couche logicielle au démarrage de l'ECU
• HSM (Hardware Security Module) : composant matériel dédié au stockage et à l'usage des clés cryptographiques, isolé du reste du système
• SecOC (Secure Onboard Communication) : protocole AUTOSAR qui ajoute un Message Authentication Code (MAC) sur les messages CAN internes pour prévenir l'injection de trames
• Defense in depth : plusieurs couches de protection indépendantes, pas une seule barrière

Phase 3 — Intégration, vérification et validation (Clause 13)

• Tests de pénétration (pentests) ciblés sur les interfaces à risque
• Fuzzing des protocoles embarqués (CAN, UDS, Ethernet)
• Revues de sécurité de l'architecture et du code
• Vérification de la couverture des exigences cybersécurité

Phase 4 — Production (Clause 14)

• Processus sécurisés pour l'injection de clés cryptographiques en ligne de production (Key Provisioning)
• Contrôle d'accès aux outils de programmation des ECUs
• Protection de la propriété intellectuelle des firmwares

Phase 5 — Opérations et maintenance (Clause 15)

C'est la phase la plus longue (durée de vie du véhicule = 15-20 ans) :

• Monitoring des vulnérabilités (veille CVE, bug bounty)
• Gestion des incidents : détection, containment, forensique
• Mises à jour OTA sécurisées (lien avec UN R156)
• Communication avec les parties prenantes (OEMs, propriétaires)
• Fin de vie : désactivation sécurisée, effacement des données, révocation des clés

🔗 Relation avec les autres normes

Carte des normes pertinentes

Sécurité fonctionnelle     ISO 26262 (Safety)
                                   │
                                   │ complémentaires
                                   ▼
Cybersécurité embarquée    ISO/SAE 21434 ──── UNECE UN R155/R156 (régulation légale)
                                   │
                                   │ s'appuie sur
                                   ▼
Sécurité IT classique      ISO/IEC 27001 (SMSI)
                           IEC 62443 (OT/systèmes industriels)
                           NIST CSF

Comparaison ISO 27001 vs ISO/SAE 21434

Critère	ISO 27001	ISO/SAE 21434
Périmètre	SI de l'entreprise (IT)	Composants embarqués (produit)
Cycle de vie	Annuel (revue SMSI)	15-20 ans (vie du véhicule)
Méthode d'analyse de risques	ISO 27005, EBIOS RM...	TARA (obligatoire)
Niveau d'assurance	Non applicable	CAL 1 à 4
Certification	Oui (tierce partie)	En cours de standardisation
Acteurs	RSSI, équipe IT	Ingénieurs système, équipementiers, OEMs

Lien avec EBIOS RM

EBIOS RM (méthode ANSSI) et la TARA de l'ISO/SAE 21434 partagent la même logique fondamentale :

EBIOS RM	TARA ISO/SAE 21434	Concept commun
Atelier 1 : Cadrage	Item Definition	Définir le périmètre
Atelier 2 : Sources de risque	Threat Actors	Identifier qui attaque
Atelier 3 : Scénarios stratégiques	Threat Scenarios	Scénarios de haut niveau
Atelier 4 : Scénarios opérationnels	Attack Paths	Chemins d'attaque techniques
Atelier 5 : Traitement du risque	Risk Treatment	Mesures de sécurité

👥 Rôles et responsabilités dans la supply chain

La chaîne automobile

Tier 2/3 (composants)
    ↓ fournit composants + exigences cybersécurité
Tier 1 (équipementiers)
    ↓ fournit systèmes + documentation cybersécurité (CSMS)
OEM (constructeur : BMW, VW, Toyota...)
    ↓ intègre dans le véhicule, obtient la réception de type
Autorité nationale (homologation)

Responsabilités par niveau

OEM (constructeur) :

• Détient la responsabilité finale de la cybersécurité du véhicule
• Doit avoir un CSMS certifié pour obtenir la réception de type (UN R155)
• Définit les exigences cybersécurité transmises aux Tier 1

Tier 1 :

• Doit démontrer la conformité de ses composants aux exigences du constructeur
• Doit maintenir son propre CSMS
• Doit réaliser des TARAs sur ses composants
• Transmet les risques résiduels et la documentation de sécurité au constructeur

Tier 2/3 :

• Doivent répondre aux exigences cybersécurité transmises par le Tier 1
• De plus en plus sollicités pour démontrer la sécurité de leurs composants

Le concept de "Cybersecurity Interface Agreement"

Quand un équipementier (Tier 1) fournit un composant à un constructeur, un Cybersecurity Interface Agreement est établi. Il documente :

• Les hypothèses de sécurité (ce qu'on suppose de l'environnement dans lequel son composant sera intégré)
• Les responsabilités partagées
• Les risques résiduels dont le constructeur est informé

⚖️ Lien avec les régulations UN R155/R156

UN R155 — Cybersécurité véhicule

Adopté en juin 2020 par l'UNECE (Commission Économique des Nations Unies pour l'Europe), UN R155 est une régulation légalement contraignante qui s'impose aux constructeurs souhaitant vendre dans les 54 pays membres (UE, Japon, Corée, Russie...).

Calendrier d'application :

• Juillet 2022 : obligatoire pour les nouveaux types de véhicules
• Juillet 2024 : obligatoire pour TOUS les véhicules neufs vendus

Ce qu'exige UN R155 :

• Le constructeur doit avoir un CSMS certifié par une autorité d'homologation nationale
• Le véhicule doit être protégé contre une liste de 69 menaces référencées dans l'annexe du règlement
• Le constructeur doit surveiller et répondre aux cybermenaces pendant toute la vie du véhicule

ISO/SAE 21434 n'est pas citée explicitement dans UN R155, mais elle est reconnue comme le moyen de conformité de référence ("accepted means of compliance").

UN R156 — Mises à jour logicielles (OTA)

Companion de R155, UN R156 s'applique spécifiquement aux mises à jour logicielles (Over The Air) :

• Le constructeur doit gérer un Software Update Management System (SUMS)
• Traçabilité des versions, intégrité des paquets de mise à jour, rollback sécurisé

🏭 Ce que ça signifie concrètement

Dans les équipes produit

• Chaque nouveau projet intègre une TARA dès la phase de concept
• Les ingénieurs suivent des Secure Coding Guidelines conformes aux CAL définis
• Chaque interface externe (OBD-II, Bluetooth, 5G, USB) fait l'objet d'une analyse d'attaque
• Les HSMs sont intégrés dans les ECUs à risque élevé (freinage, ADAS)
• Des pentests sont réalisés avant la livraison client

Dans l'équipe GRC / cybersécurité

• Maintien du CSMS : vérifier que les processus sont à jour et appliqués
• Gestion des risques continus (Clause 8) : surveiller les CVEs qui affectent les composants en production et coordonner les correctifs
• Audits internes : préparer et participer aux audits de conformité ISO/SAE 21434
• Gestion de la supply chain : s'assurer que les fournisseurs Tier 2/3 respectent les exigences transmises
• Incident response : avoir des playbooks et les tester pour le volet produit automobile
• Documentation : maintenir les TARAs à jour, les Cybersecurity Cases (dossiers de conformité)

Les filiales d'AUMOVIO dans ce contexte

• PlaxidityX : spécialisée dans les solutions de détection embarquées (IDS) et les services de vSOC — directement alignée sur la Clause 15 (monitoring post-production)
• Elektrobit : fournit les couches OS sécurisées (AUTOSAR Adaptive/Classic, Linux) qui implémentent les exigences de développement sécurisé (Clauses 10-12)