Cybersécurité automobile : 21434, R155, R156
Guide, cybersécurité automobile
La cybersécurité des véhicules routiers repose sur deux piliers distincts mais imbriqués : une norme d'ingénierie, ISO/SAE 21434, qui structure la maîtrise du risque cyber sur tout le cycle de vie, et deux règlements d'homologation des Nations unies, UNECE R155 (gestion de la cybersécurité) et UNECE R156 (gestion des mises à jour logicielles). Cette page expose la genèse de ce cadre, le contenu de la norme (définition d'item, TARA, niveaux CAL, cycle de vie), le fonctionnement des règlements R155 et R156, leur articulation avec la sécurité fonctionnelle ISO 26262, le calendrier d'application en homologation de type, et les pièges récurrents observés en conception.
Un cadre à deux étages : norme et règlement
Section intitulée « Un cadre à deux étages : norme et règlement »La cybersécurité automobile se lit à deux niveaux qu'il ne faut pas confondre. Le premier est normatif et volontaire : ISO/SAE 21434, publiée conjointement par l'ISO et la SAE en août 2021, décrit l'état de l'art de l'ingénierie de cybersécurité pour les systèmes électriques et électroniques des véhicules routiers. Le second est réglementaire et obligatoire : les règlements UNECE R155 et UNECE R156, adoptés par le Forum mondial pour l'harmonisation des règlements concernant les véhicules (WP.29) en juin 2020, conditionnent l'homologation de type d'un véhicule.
La distinction est essentielle. Une autorité d'homologation ne vérifie pas la conformité à ISO/SAE 21434 : elle vérifie que le constructeur dispose d'un système de gestion conforme à R155 et R156, et que les véhicules présentés en sont issus. La norme n'est pas exigée de manière normative par le règlement. Mais dans les faits, appliquer ISO/SAE 21434 est la voie la plus directe pour produire les preuves attendues par l'auditeur R155, car les deux textes partagent le même vocabulaire et la même logique de gestion du risque.
| Dimension | ISO/SAE 21434 | UNECE R155 / R156 |
|---|---|---|
| Nature | Norme d'ingénierie (volontaire) | Règlement d'homologation (obligatoire) |
| Émetteur | ISO et SAE | WP.29 (sous l'égide de l'UNECE) |
| Objet | Comment faire de la cybersécurité | Preuve que l'organisation sait en faire |
| Unité contrôlée | Item, composant, projet | CSMS, SUMS, type de véhicule |
| Preuve | Cybersecurity Case, livrables | Certificat de conformité, audit |
| Portée géographique | Internationale | Parties contractantes à l'Accord de 1958 |
Le rôle de WP.29 et de l'Accord de 1958
Section intitulée « Le rôle de WP.29 et de l'Accord de 1958 »WP.29 n'est pas un organisme de normalisation au sens d'ISO ou de l'IEC : c'est un forum intergouvernemental hébergé par la Commission économique des Nations unies pour l'Europe (UNECE). Il élabore des règlements techniques (les UN Regulations) que les Parties contractantes à l'Accord de 1958 transposent dans leur droit d'homologation. L'Union européenne, le Japon, la Corée, le Royaume-Uni et de nombreux autres États appliquent ces règlements ; les États-Unis, qui ne sont pas Partie à l'Accord de 1958, suivent un cadre d'auto-certification distinct.
ISO/SAE 21434 : structure et concepts clés
Section intitulée « ISO/SAE 21434 : structure et concepts clés »ISO/SAE 21434 est organisée autour d'un cycle de vie de cybersécurité couvrant la conception, la production, l'exploitation et la fin de vie. Elle définit des rôles, des livrables et un raisonnement par le risque dont les briques essentielles sont la définition d'item, la TARA et le Cybersecurity Case.
Définition d'item et périmètre
Section intitulée « Définition d'item et périmètre »Comme dans ISO 26262, le point de départ est la définition d'item : la délimitation précise du système analysé, de ses fonctions, de ses interfaces et de son environnement. La définition d'item conditionne l'identification des biens (assets) à protéger, leurs propriétés de cybersécurité (confidentialité, intégrité, disponibilité) et les frontières de l'analyse. Une définition d'item imprécise est la première cause de TARA incomplète.
La TARA en sept étapes
Section intitulée « La TARA en sept étapes »La clause 15 décrit la Threat Analysis and Risk Assessment (TARA) comme une suite d'analyses qui peuvent être menées indépendamment mais s'enchaînent logiquement.
- Identification des biens (asset identification) : recensement des biens et de leurs propriétés de cybersécurité à partir de la définition d'item.
- Analyse des scénarios de menace (threat scenario identification) : description des atteintes possibles aux propriétés des biens.
- Évaluation de l'impact (impact rating) : cotation des conséquences selon quatre catégories, sécurité des personnes (Safety), finance, opération, vie privée (privacy).
- Analyse des chemins d'attaque (attack path analysis) : décomposition des manières de réaliser un scénario de menace.
- Évaluation de la faisabilité (attack feasibility rating) : estimation de l'effort d'attaque, par exemple via une approche fondée sur le potentiel d'attaque.
- Détermination du risque (
risk value determination) : combinaison de l'impact et de la faisabilité. - Décision de traitement (
risk treatment decision) : réduction, partage, conservation ou évitement du risque, conduisant aux objectifs de cybersécurité (cybersecurity goals).
Les niveaux d'assurance CAL
Section intitulée « Les niveaux d'assurance CAL »Le CAL (Cybersecurity Assurance Level) gradue, sur quatre niveaux CAL 1 à CAL 4, l'intensité des activités d'assurance associées à un objectif de cybersécurité. Contrairement à une idée répandue, le CAL ne mesure pas le risque résiduel et n'est pas un équivalent strict de l'ASIL : c'est un facteur d'échelle des activités (degré d'indépendance des revues, profondeur de la vérification, rigueur documentaire). La méthode de dérivation du CAL est décrite en annexe E, à titre informatif, ce qui laisse une marge d'adaptation par organisation.
| Aspect | ASIL (ISO 26262) | CAL (ISO/SAE 21434) |
|---|---|---|
| Domaine | Sécurité fonctionnelle | Cybersécurité |
| Échelle | A, B, C, D (plus QM) | CAL 1, 2, 3, 4 |
| Dérivation | Normative (S, E, C en HARA) | Informative (annexe E) |
| Ce qu'il gradue | Rigueur face aux défaillances | Rigueur des activités d'assurance |
| Mesure du risque ? | Indirecte | Non, facteur d'effort |
Le Cybersecurity Case et le management distribué
Section intitulée « Le Cybersecurity Case et le management distribué »L'argumentaire global, le Cybersecurity Case, rassemble les preuves que les objectifs de cybersécurité sont atteints. La norme formalise aussi la chaîne d'approvisionnement par le Cybersecurity Interface Agreement (CIA), équivalent cyber du Development Interface Agreement d'ISO 26262, qui répartit les responsabilités entre OEM, Tier 1 et Tier 2. La phase post-production est traitée par la surveillance continue (cybersecurity monitoring), la gestion des vulnérabilités et la réponse aux incidents sur la flotte en service.
UNECE R155 : le CSMS et l'homologation cyber
Section intitulée « UNECE R155 : le CSMS et l'homologation cyber »Le règlement R155 impose deux choses imbriquées. D'abord, le constructeur doit obtenir un certificat de conformité de son CSMS (Cyber Security Management System), c'est-à-dire faire auditer par l'autorité d'homologation l'organisation, les processus et les ressources avec lesquels il gère le risque cyber. Ensuite, chaque type de véhicule présenté à l'homologation doit démontrer que sa cybersécurité est gouvernée par ce CSMS.
Les trois phases couvertes par le CSMS
Section intitulée « Les trois phases couvertes par le CSMS »| Phase | Exigences principales R155 |
|---|---|
| Développement | Identification et gestion des risques, conception de mesures, vérification et validation, gestion de la chaîne d'approvisionnement |
| Production | Cohérence entre conception et fabrication, protection des configurations, gestion des clés et secrets |
| Post-production | Surveillance des menaces et vulnérabilités, capacité de détection et de réponse aux incidents, mises à jour de sécurité sur la flotte en service |
Le certificat de CSMS est valable trois ans et conditionne toute homologation de véhicule au titre de R155. L'annexe 5 du règlement liste un catalogue de menaces et de mesures d'atténuation servant de référence à l'auditeur : un constructeur doit montrer qu'il a considéré ces menaces ou justifié leur non-pertinence.
Articulation avec le droit de l'Union européenne
Section intitulée « Articulation avec le droit de l'Union européenne »Dans l'Union européenne, le règlement (UE) 2018/858 sur la réception et la surveillance du marché des véhicules à moteur rend exigibles les règlements UNECE pertinents pour l'homologation. Le règlement (UE) 2019/2144, dit General Safety Regulation (GSR), renforce le cadre des dispositifs de sécurité des véhicules. La cybersécurité (R155) et la gestion des mises à jour (R156) y deviennent des conditions d'homologation des véhicules des catégories visées (notamment M et N, et certains O).
UNECE R156 : le SUMS et les mises à jour logicielles
Section intitulée « UNECE R156 : le SUMS et les mises à jour logicielles »R156 traite un sujet distinct mais lié : la maîtrise des mises à jour logicielles, en particulier les mises à jour par voie aérienne (OTA, Over-The-Air). Le constructeur doit obtenir un certificat de conformité de son SUMS (Software Update Management System), également valable trois ans.
Ce que le SUMS doit garantir
Section intitulée « Ce que le SUMS doit garantir »- Traçabilité : enregistrer quelle version logicielle est ou a été en service sur quel véhicule.
- Identification réglementaire : gérer le ou les RxSWIN (
Regulation X Software Identification Number) rattachés aux fonctions couvertes par un règlement. - Évaluation d'impact : déterminer si une mise à jour affecte une fonction réglementée, la sécurité ou l'homologation.
- Intégrité et authenticité : empêcher l'installation d'un logiciel non autorisé ou altéré.
- Information du conducteur : pour une mise à jour OTA susceptible d'affecter l'usage, informer et, le cas échéant, obtenir une action de l'utilisateur.
- Réversibilité et sécurité d'exécution : garantir que le véhicule reste sûr ou inutilisable de manière sûre pendant la mise à jour.
Le RxSWIN, pivot de la conformité logicielle
Section intitulée « Le RxSWIN, pivot de la conformité logicielle »Le RxSWIN identifie la configuration logicielle associée à un périmètre réglementaire donné. Lorsqu'une mise à jour modifie une fonction réglementée, le RxSWIN correspondant change et le constructeur doit vérifier que l'homologation reste valide, voire la mettre à jour. Ce mécanisme fait du logiciel un objet d'homologation à part entière, au même titre qu'un composant mécanique.
Articulation avec la sécurité fonctionnelle et le cadre cyber élargi
Section intitulée « Articulation avec la sécurité fonctionnelle et le cadre cyber élargi »Cybersécurité et sécurité fonctionnelle se traitent en parallèle, jamais l'une à la place de l'autre. ISO 26262 couvre les dysfonctionnements (défaillances aléatoires, erreurs systématiques) ; ISO/SAE 21434 couvre les attaques intentionnelles. Le point de jonction est la catégorie d'impact Safety de la TARA : une menace cyber dont la conséquence est une atteinte aux personnes rejoint le périmètre d'un Safety Goal d'ISO 26262. Les deux équipes partagent idéalement la définition d'item et confrontent leurs analyses.
| Norme ou texte | Domaine | Nature |
|---|---|---|
| ISO 26262 | Sécurité fonctionnelle véhicule | Norme |
| ISO/SAE 21434 | Cybersécurité véhicule | Norme |
| UNECE R155 | Gestion cybersécurité (CSMS) | Règlement |
| UNECE R156 | Gestion mises à jour (SUMS) | Règlement |
Au-delà du seul véhicule, le cadre cyber européen plus large interfère : le futur Cyber Resilience Act vise les produits comportant des éléments numériques, tandis que la norme IEC 62443 structure la cybersécurité des systèmes d'automatisation industrielle, dont peuvent relever les bornes de recharge ou les chaînes de production. Pour le véhicule lui-même, R155 et R156 restent la référence d'homologation.
Calendrier d'application en homologation de type
Section intitulée « Calendrier d'application en homologation de type »Pour les Parties contractantes appliquant les règlements, le déploiement s'est fait en deux temps.
| Échéance | Périmètre |
|---|---|
| Juillet 2022 | Nouveaux types de véhicules : un type homologué à partir de cette date doit être couvert par un CSMS (R155) et un SUMS (R156) valides |
| Juillet 2024 | Tous les véhicules neufs : même les types homologués avant 2022 doivent être conformes pour pouvoir continuer à être produits et immatriculés |
Concrètement, depuis juillet 2024, un véhicule neuf des catégories visées ne peut plus être immatriculé dans l'Union européenne sans CSMS et SUMS valides. Le calendrier explique l'arrêt anticipé de certains modèles dont la mise en conformité logicielle aurait coûté plus cher que le maintien commercial.
Procédure type côté constructeur
Section intitulée « Procédure type côté constructeur »- Mise en place du CSMS et du SUMS : définition des processus, des rôles et des outils de gestion du risque cyber et des mises à jour.
- Audit organisationnel : l'autorité d'homologation (ou son service technique) audite les deux systèmes et délivre les certificats de conformité (validité trois ans).
- Application au type de véhicule : pour chaque type, conduite de la TARA, conception des mesures, constitution du Cybersecurity Case et déclaration des RxSWIN.
- Homologation de type : présentation des preuves rattachées au CSMS et au SUMS ; le type reçoit son homologation.
- Maintien en service : surveillance des vulnérabilités, gestion des incidents, déploiement des mises à jour OTA selon le SUMS, réévaluation de l'homologation si un RxSWIN change.
Pièges récurrents
Section intitulée « Pièges récurrents »| Piège | Conséquence | Bonne pratique |
|---|---|---|
| Confondre ISO/SAE 21434 et R155 | Croire la conformité réglementaire acquise par la seule norme | Distinguer la preuve d'ingénierie (norme) et le certificat d'homologation (règlement) |
| Définition d'item floue | TARA incomplète, biens oubliés | Figer et revoir la définition d'item avant la TARA, la partager avec l'équipe FuSa |
| Traiter le CAL comme un ASIL | Sur-dimensionnement ou justification incohérente | Utiliser le CAL comme facteur d'effort d'assurance, justifier la méthode de dérivation |
| Négliger la post-production | Non-conformité R155 sur la flotte en service | Outiller la surveillance, la gestion des vulnérabilités et la réponse aux incidents dès le départ |
| OTA sans gestion RxSWIN | Mise à jour invalidant l'homologation | Lier chaque fonction réglementée à un RxSWIN et évaluer l'impact de chaque mise à jour |
| Silos FuSa / cyber | Menace à conséquence Safety non coordonnée | Partager définition d'item et analyses entre les équipes ISO 26262 et ISO/SAE 21434 |
| Certificats expirés | Suspension d'homologation | Suivre la validité de trois ans des certificats CSMS et SUMS et planifier les réaudits |
Pour aller plus loin
Section intitulée « Pour aller plus loin »- ISO 26262 : sécurité fonctionnelle automobile : la norme sœur de sécurité fonctionnelle, appliquée en parallèle d'ISO/SAE 21434.
- IEC 62443 et ISA-99 : cybersécurité industrielle : le cadre cyber des systèmes d'automatisation, pertinent pour les infrastructures liées au véhicule.
- Cyber Resilience Act (CRA) : le règlement européen horizontal sur les produits comportant des éléments numériques.
- IATF 16949 : qualité automobile : le référentiel qualité dans lequel s'inscrivent les processus de production cyber.
- Recharge VE : IEC 61851, ISO 15118, OCPP : l'écosystème de recharge, où se croisent cyber véhicule et cyber industrielle.
- Glossaire : définitions de CSMS, SUMS, TARA, CAL, RxSWIN, OTA et item.
Sources et références
Section intitulée « Sources et références »Sources & références
- ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering , ISO www.iso.org/standard/70918.html
- UN Regulation No. 155, Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system , UNECE unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security
- UN Regulation No. 156, Uniform provisions concerning the approval of vehicles with regards to software update and software update management system , UNECE unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
- ISO 26262:2018, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
- Règlement (UE) 2018/858 relatif à la réception et à la surveillance du marché des véhicules , EUR-Lex eur-lex.europa.eu/eli/reg/2018/858/oj
- Règlement (UE) 2019/2144 (General Safety Regulation, GSR) , EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
- UNECE WP.29, World Forum for Harmonization of Vehicle Regulations , UNECE unece.org/transport/vehicle-regulations