UNECE WP.29, une réglementation pour la cybersécurité dans le monde automobile

MISC

n°

116

juillet 2021

Par

Amokrane Ahmed

Vottier Sylvie

Sécurité organisationnelle

Tag(s)

automobile

règlementation

norme ISO

Dans cet article, nous présentons la réglementation de l’UNECE WP.29 qui ambitionne, en s’appuyant sur des standards de cybersécurité existants et d’autres à venir, de traiter le sujet de la cybersécurité dans l’écosystème automobile et tout au long du cycle de vie des véhicules. Cette réglementation porte sur les exigences organisationnelles et techniques de cybersécurité couvrant les véhicules, les moyens de production et la Supply Chain. Nous présentons également les impacts de la réglementation pour les acteurs du secteur automobile et du monde de la cybersécurité.

Introduction

Les voitures sont passées d’engins mécaniques à de véritables ordinateurs sur roues. Les véhicules comptent aujourd’hui plus de 150 ECU (Electronic Control Units) et environ 100 millions de lignes de code, un nombre qui atteindra les 300 millions en 2030 [1]. À ces composants matériels et logiciels s’ajoutent les flots de données, en partie diffusées à l’extérieur du véhicule (plateformes cloud), nécessaires au maintien en condition opérationnelle des composants, des systèmes et du véhicule. Ces véhicules connectés font partie d’un écosystème qui ne cesse de s’élargir et les usagers s’inquiètent de plus en plus des risques de piratage des véhicules. Selon une étude publiée en 2019 [2], 56% des usagers étaient inquiets d’un éventuel piratage de leur voiture, et ce chiffre montait à 73% si la même question était posée à horizon 5 ans. Ces véhicules utilisent des technologies hétérogènes allant des ports physiques de diagnostic dans la voiture (port OBD-II) aux serveurs backend chez les constructeurs ou dans le cloud, en passant par les réseaux de communication sans fil, les ports multimédias, les applications mobiles et bien d’autres interfaces. La surface d’attaque devient donc très large et les points d’entrée pour un attaquant à proximité ou à distance se multiplient.

Dans ce contexte de véhicules hyperconnectés, intelligents, voire autonomes, le risque de cyberattaques est en pleine augmentation. Des efforts sont menés dans le monde entier pour définir des réglementations et des standards permettant d’introduire la cybersécurité dans le cycle de vie des véhicules. Pour n’en citer que quelques-unes, il y a des propositions au Congrès américain, la loi sur la cybersécurité (Cybersecurity Act) et le GSR dans l'UE, le Programme ICV en Chine et les nouvelles directives de JASPAR au Japon. La dernière en date est la nouvelle réglementation de l’UNECE WP.29 qui entrera en vigueur, en Europe, en juillet 2022. Cette règlementation porte sur les exigences de cybersécurité à la fois organisationnelles et techniques pour l’écosystème automobile, incluant les véhicules, les moyens de production et la Supply Chain. Elle s’appuie sur des standards parmi lesquels l’ISO/SAE DIS 21434 (autour de l’ingénierie de la cybersécurité) et l’ISO/AWI 24089 (spécifique au Système de Management de la mise à jour des logiciels).

Dans cet article, nous présentons cette réglementation et les standards associés. Nous présentons également les challenges et impacts qu’elle aura sur l’ensemble de l’écosystème automobile dont les constructeurs automobiles, les acteurs sur l’ensemble de la chaîne d’approvisionnement, les fournisseurs de solutions cybersécurité et les fournisseurs de service cybersécurité.

1. Des attaques démontrées sur les véhicules et leur écosystème

Plusieurs vulnérabilités ont déjà été identifiées par le passé, qui ont même permis la prise en main du véhicule à distance, entraînant ainsi un risque d’atteinte à l’intégrité des personnes. Ces vulnérabilités ont touché les systèmes embarqués, les ports physiques du véhicule, les réseaux CAN internes, les canaux de communication avec l’extérieur, les serveurs de backend, les fournisseurs tiers de la chaîne d’approvisionnement, et d’autres vulnérabilités liées à la sensibilisation des collaborateurs aux risques de cybersécurité.

Parmi les exemples notoires, on peut citer le SUV que les chercheurs américains ont réussi à faire sortir de la route en 2015 [12]. Ils sont passés par le système multimédia de la voiture qui leur a permis d’interagir directement avec le réseau CAN interne, exploitant ainsi le manque de cloisonnement entre ces réseaux qui n’ont pas le même niveau de criticité.

En 2016, un chercheur britannique a fait une démonstration portant sur une vulnérabilité dans l’API hébergée sur le serveur de backend d’un constructeur automobile [3]. La vulnérabilité permettait, entre autres, de connaître les trajets effectués par la voiture et de contrôler le chauffage à distance sans authentification, en se basant uniquement sur le numéro de série du véhicule, qui se trouve sur le pare-brise, et le pays. En 2017, des chercheurs ont identifié une vulnérabilité dans l’application mobile d’un constructeur qui envoyait des données en HTTP vers le serveur. Ces données étaient chiffrées, mais avec une clé symétrique codée en dur dans l’application, rendant possibles l’interception et le déchiffrement des données, dont des commandes de déverrouillage du véhicule, et d’allumage/extinction de la climatisation [4].

Plus récemment, des chercheurs britanniques ont découvert des vulnérabilités sur des modèles de deux constructeurs dont certaines peuvent permettre d’accéder à des réseaux sensibles du véhicule (contrôle de traction des roues) depuis l’équipement multimédia [5]. Ces mêmes chercheurs ont pu extraire et analyser des parties du code source embarqué, et d’identifier un mot de passe Wi-Fi (celui du réseau Wi-Fi d’une usine). À cela s’ajoute la mine d’informations que le véhicule collectait sur son usager et qu’ils ont pu récupérer (trajets, position, alarmes, etc.).

Des vulnérabilités dans les systèmes de fournisseurs tiers pourraient également nuire à la sécurité des véhicules, avec un impact sur plusieurs constructeurs. En 2018, une erreur de configuration et un défaut de contrôle d’accès sur le serveur backend d’un fournisseur ont rendu possible l’accès en lecture et écriture aux données d’un serveur [6]. Ces données, remontées par les véhicules (localisation, etc.), étaient accessibles par simple modification d’un paramètre (ID) dans l’URL d’accès.

Au-delà des failles techniques, les vulnérabilités dans la gouvernance et l’organisation peuvent avoir des conséquences graves. Dernier exemple : la tentative par un attaquant de recruter un « insider » pour diffuser un malware dans le SI d’un constructeur, faute de pouvoir trouver un moyen technique de le faire à distance [7].

Notons que les vulnérabilités techniques ainsi découvertes peuvent nécessiter le rappel des véhicules pour appliquer les correctifs (un constructeur a dû rappeler 1,8 million de véhicules). Elles pourraient aussi causer un inconfort, voire porter atteinte à l’intégrité physique des usagers.

2. La réglementation UNECE WP.29

2.1 Une réglementation pas comme les autres dans le secteur automobile

Les réglementations liées à la cybersécurité sont nouvelles dans le secteur automobile. La réglementation UNECE WP.29 porte sur la cybersécurité, à la fois des véhicules, des systèmes de production et d’informations connexes, dont ceux des fournisseurs et prestataires. Cette réglementation, issue du groupe de travail WP.29 de l’UNECE (Commission Économique pour l’Europe des Nations Unies), sera applicable dans les 54 pays signataires de l’accord de l’UNECE de 1958, mais aussi dans tous les pays de l’UE via le règlement européen GSR (General Safety Regulation) édicté en 2019.

La réglementation s’appliquera aux véhicules des catégories L6 et L7 à quatre roues ainsi qu’aux catégories M et N des véhicules de transport de passagers et de marchandises, et enfin de catégorie O concernant les remorques et semi-remorques, à partir du moment où ils contiennent au moins un ECU. Les non-conformités pourront avoir pour conséquence un refus de délivrance de certificat par type de véhicule à partir du 6 juillet 2022, voire une interdiction d’immatriculation à partir du 7 juillet 2024.

La réglementation stipule que les constructeurs/sous-traitants doivent mettre en place un Cyber Security Management System (CSMS) couvrant le cycle de vie du véhicule et le cycle de production industrielle. Les constructeurs feront aussi homologuer chaque type de véhicule et prouveront à l’organisme certificateur qu’ils ont pris en compte la cybersécurité, comme illustré dans la Figure 1. La réglementation impose également la mise en place d’un Système de Management des Mises à jour des Softwares (SUMS) présents dans le véhicule.

Fig. 1 : Périmètre et composantes de la réglementation UNECE.

2.2 Zoom sur le contenu de la réglementation UNECE WP.29

Les principaux axes de la réglementation portent sur le CSMS et la certification du type de véhicule, ainsi que sur le SUMS.

A. CSMS - Le système de management de la cybersécurité doit inclure des processus pour :

Gérer la cybersécurité au niveau organisationnel et technique ;
Identifier les risques ;
Évaluer, classer et traiter les risques identifiés ;
Vérifier que les risques identifiés sont gérés de manière appropriée ;
Tester la cybersécurité d’un type de véhicule ;
Surveiller, détecter et répondre aux cyberattaques, menaces et vulnérabilités ;
Évaluer l'efficacité des mesures mises en œuvre ;
Gérer les dépendances aux tiers et assurer le respect des exigences du CSMS par ces tiers.

Le CSMS doit être audité et homologué, pour chaque type de véhicule, par les autorités compétentes du pays pour assurer leur mise en œuvre effective. Cette homologation assurera que le CSMS couvre l’ensemble des phases de développement, production et post-production des véhicules.

B. SUMS - Le Système de Management des Mises à jour des logiciels présents dans le véhicule assure la mise en place de processus permettant de :

Identifier les composants logiciels et matériels ;
Vérifier la compatibilité d’une version logicielle avec un système/véhicule cible ;
Évaluer l’impact sur la sûreté des occupants d’une mise jour logicielle ;
Assurer l’intégrité et l’authenticité des mises à jour ;
Assurer la possibilité de revenir à une version antérieure si une mise à jour ne s’est pas faite correctement.

Les textes de la réglementation (« UN R155 » et « UN R156 ») fournissent des éléments intéressants pour les analyses de risques. Ils listent notamment des sources de menaces (internes, externes, malveillantes ou pas) et des classes de vulnérabilités à considérer sur le véhicule et ses composants, les réseaux de communication et les systèmes en back-end.

2.3 Modalité de mise en conformité et homologation

2.3.1 Certification de CSMS

La certification est délivrée par une autorité d’approbation pour un CSMS mis en place par le constructeur. Cette certification est valable 3 ans, mais elle peut être retirée par l’autorité si le constructeur ne respecte plus les exigences.

2.3.2 Demande d'homologation d'un type de véhicule

L’homologation d’un type de véhicule passe par les étapes suivantes :

Documentation fournie par le constructeur à l’autorité d’approbation :
- Caractéristiques du véhicule ;
- Résultats des analyses des risques ;
- Identification des éléments critiques du véhicule et de son environnement ;
- Dispositifs de sécurité en place pour réduire les risques ;
- Résultats des tests ;
- Éléments de sécurisation de la Supply Chain ;
- Numéro du certificat de conformité pour le CSMS.
Vérification de ces éléments par l’autorité d’approbation.
Tests du véhicule par l’autorité d’approbation.
Contrôle sur site possible par l’autorité d’approbation.

3. Relation avec les autres standards de cybersécurité

Au-delà de la mise en place d’un CSMS, des mesures techniques doivent être mises en place pour assurer la sécurité de l’information et des systèmes à bord contre une utilisation non autorisée telle que stipulée par le règlement européen GSR [11]. La réglementation UNECE WP.29 préconise l’application des réglementations et standards dès leur entrée en vigueur dont lSO/SAE 21434 [8], ISO/AWI 24089 [9] et la série ISO 27K comme montré dans la Figure 2.

Fig. 2 : Relation entre la réglementation UNECE et les autres standards de sécurité.

3.1 L’ISO/SAE DIS 21434 comme premier point d’entrée

La norme ISO/SAE 21434, applicable aux systèmes électriques et électroniques des véhicules, est un excellent point d’entrée pour mettre en œuvre un CSMS. Cette norme préconise une approche axée sur les risques pour établir les exigences cybersécurité, déterminer les priorités des actions en fonction des risques et définir les activités de Management de la cybersécurité. La publication définitive est prévue au cours de 2021. Elle ne couvre cependant pas totalement les exigences de l’UNECE WP.29 et d’autres standards comme l’ISO 27001 et ISO 9001 sont un bon complément.

La norme ISO/SAE 21434 préconise la prise en compte de la sécurité depuis la conception jusqu’au décommissionnement du véhicule comme illustré dans la Figure 3. Son objectif est d’assurer un niveau de sécurité des composants et des véhicules qui soit acceptable dans un contexte où les sources de menace évoluent et où les risques de cybersécurité peuvent engendrer directement ou indirectement des risques de sûreté.

Fig. 3 : Vue générale des chapitres de la norme ISO/SAE 21434.

La norme couvre à la fois les sujets liés à l’organisation et les sujets liés à l’opérationnel à travers différents chapitres :

Chapitre 5 : définition des fondations de la sécurité au niveau de l’organisation à travers la définition de politiques, de règles et de processus assurant la sécurité au sein de l’organisation, qui doivent être audités par un tiers indépendant. Ces politiques, règles et processus doivent couvrir l’ensemble de la chaîne d’approvisionnement, le cycle de vie du véhicule (de la conception au décommissionnement) ainsi que la gestion des incidents, des vulnérabilités et des risques cybersécurité.
Chapitre 6 : définition des responsabilités liées à la cybersécurité dans l’organisation et dans les projets, et planification des activités de cybersécurité dans les projets, notamment ceux liés au développement ou à l’adaptation de composants/logiciels existants (librairies, etc.). Les activités de cybersécurité doivent permettre d’assurer un niveau de sécurité suffisant, et des tests indépendants sont effectués sur les composants/systèmes pour les certifier en vue de leur mise en production.
Chapitre 7 : mise en place des activités de sécurité à travers le suivi continu, l’analyse des évènements de cybersécurité, le traitement des incidents, la détection et le traitement des vulnérabilités, pour assurer une sécurité en continu tout au long du cycle de vie de la voiture. Ce suivi peut aller jusqu’à l’analyse des messages internes et les logs des ECU pour détecter des comportements suspects. La détection des vulnérabilités peut se matérialiser sous forme de scans réguliers des ports et des vulnérabilités sur les interfaces accessibles du véhicule et les backends.
Chapitre 8 : définition de la méthode d’analyse permettant d’identifier les risques qui peuvent peser sur un véhicule et ses occupants. La méthode d’analyse de risques doit permettre d’identifier les assets (biens) qui peuvent être des composants ou une donnée (vitesse de la voiture, messages de commande de la direction, etc.), les scénarios de menace pouvant porter atteinte à l’une des propriétés de sécurité (disponibilité, intégrité ou confidentialité), la quantification des impacts sur la sûreté des occupants de la voiture, l’identification des chemins d’attaque en lien avec les scénarios de menace, la quantification des vraisemblances des chemins d’attaque, et enfin la quantification des risques en combinant la vraisemblance du scénario d’attaque et l’impact, comme on le ferait dans une analyse de risques EBIOS. Cette phase débouche sur un plan de traitement des risques.
Chapitre 9 : définition des composants (items) et des cibles de sécurité pour chaque item en se basant sur l’analyse de risques (chapitre 8).
Chapitre 10 : prise en compte de règles de sécurité dans les différentes phases du développement des composants logiciels et matériels, en incluant la conception de l’architecture, les développements logiciels et matériels, la phase d’intégration des différents composants et la phase de vérification. Les spécifications de sécurité définies pour les composants/l’architecture sont revues et mises en œuvre pendant ces phases en déclinant les spécifications de sécurité (règles, politiques, etc.) en mesures techniques. Le standard définit par exemple un ensemble de recommandations sur les langages de programmation pour limiter les vulnérabilités comme l’utilisation de langages fortement typés pour éviter les buffer overflows, et, si ce n’est pas possible, la mise en place de mesures compensatoires (e.g. vérification des paramètres en entrée des API).
Chapitre 11 : validation des mesures de sécurité mises en œuvre au niveau du véhicule, après intégration de tous les composants dans des conditions similaires à son utilisation finale. Parmi les exemples de vérifications : les tests d’intrusion pour vérifier l’absence de vulnérabilités techniques sur la surface d’attaque du véhicule.
Chapitre 12 : sécurisation des environnements de production des composants et d’intégration du véhicule, afin de s’assurer qu’aucune altération n’est possible pendant ce processus. Il s’agit notamment de sécuriser les environnements OT/IIoT de production, dont la prise de contrôle par des attaquants pourrait causer l’altération des composants et des véhicules (e.g. implantation de code malveillant, altération de l’usinage de composants, etc.).
Chapitre 13 : supervision des véhicules/composants après la mise en opération, réponse aux incidents de sécurité et maintenance régulière par le biais de mises à jour logicielles utilisant des moyens sécurisés.
Chapitre 14 : prise en compte de la sécurité lors du décommissionnement des véhicules et de leurs composants pour, entre autres, protéger les données qu’ils contenaient pendant leur phase d’opération.
Chapitre 15 : prise en compte de la sécurité des fournisseurs tiers, avec définition claire des responsabilités de chacun.

Les implications de la norme ISO/SAE 21434 d’un point de vue technique intègrent notamment la mise en place de tests de sécurité systématiques des composants matériels et logiciels avant leur validation.

L’ISO/SAE 21434 exige de formaliser des politiques et de nombreux autres documents de procédures et de maintenir ce corpus documentaire durant tout le cycle de vie des véhicules, selon une démarche qualité. Pour assurer cette démarche qualité, l’ISO 9001 est la référence par excellence.

3.2 L’ISO/AWI 24089 comme second point d’entrée

Cette norme servira de guide à la mise en place d’un système de gestion des mises à jour des logiciels embarqués dans les véhicules. Ce système sera certifié par une autorité. Le certificat sera valide 3 ans. Des règles concernant la nature, le degré et les niveaux de changement sont en cours de définition et attendus début 2022.

3.3 La suite ISO pour la Supply Chain automobile

Dans l’industrie automobile, où la Supply Chain est primordiale, il est nécessaire d’identifier les mesures techniques et organisationnelles qui relèvent de la série de normes ISO 27001 pour protéger la donnée présente à tous les niveaux, du cœur du véhicule au véhicule étendu jusqu’au backend. S’ajoute à cela la définition des plans de continuité et de reprise d’activité, qui contribuent à la résilience en cas d’incidents sur la chaîne.

4. Des challenges à relever pour le régulateur et les acteurs de l’automobile

Pour le régulateur, il faudra mettre l’accent sur la protection des données collectées par les véhicules. Selon une étude KPMG [2], 41% des usagers pensent qu’ils sont propriétaires des données collectées contre 20% qui disent plutôt que ce sont les constructeurs qui en ont la propriété. La CNIL s’est déjà intéressée au sujet en 2017 [10]. Le sujet restera donc à clarifier et à réguler pour assurer une protection et un usage limité dans le respect des libertés et de la vie privée des personnes à l’origine de la génération des données.

Côté constructeurs, avant la finalisation de l’ensemble de ces standards, il leur est difficile de définir une démarche claire et outillée pour la mise en place et l’homologation d’un CSMS et l’homologation des types de véhicules. Ce paysage de standards et d’annexes de la réglementation rend les choses complexes. Néanmoins, les grandes lignes sont claires et il faudrait s’y préparer et relever les défis.

L’autre problématique à adresser et la prise en compte de la réglementation dans la supply chain. La réglementation demande à ce que le constructeur collecte et vérifie les informations liées aux exigences de la réglementation auprès de tous les acteurs dans sa supply chain, et s’assurer que les risques sont identifiés et maîtrisés chez ces acteurs. En pratique, ceci n’est pas une mince affaire d’autant plus qu’il est difficile de définir pour chacun des composants des cahiers des charges clairs sur les contrôles de sécurité à intégrer et assurer un suivi du respect des exigences par l’ensemble des acteurs dans la chaîne.

Le passage des différents standards à une implémentation pratique n’est pas une chose aisée. Même si les standards mentionnent un cadre bien défini, la mise en pratique, comme tous les standards, passera par des chantiers significatifs et coûteux en temps et en ressources. Ces standards sont en effet nouveaux, la 21434 notamment, ce qui nécessite une montée en compétence de l’ensemble des parties prenantes dans l’homologation d’un CSMS. Ces standards couvrent aussi un périmètre très large, ce qui nécessite une coordination d’équipes de diverses compétences et mondes (OT, embarqué, SI traditionnel, etc.).

Pour les acteurs de l’écosystème, les défis à relever sont l’outillage et les compétences techniques pour assurer une production sécurisée (logicielle et matérielle), des tests de sécurité de qualité (pentest, revue de code, etc.), un maintien en condition de sécurité une fois le véhicule en circulation, et une détection et traitement des incidents d’une nature différente que ceux traités par les SOC aujourd’hui. Il va falloir en effet des compétences et des outils supplémentaires pour protéger, surveiller, tester des technologies liées aux véhicules. Pour les tests à réaliser par exemple, il faut être capable de couvrir en même temps des applications web, des applications embarquées et des bus CAN internes.

Enfin, il est aussi important de considérer l’urgence de la mise en œuvre des exigences de la réglementation. Même si la date de l’effet est pour juillet 2022, le développement d’un nouveau modèle organisationnel et opérationnel met entre 3 et 5 années, ce qui se traduit par un besoin immédiat d’entamer les chantiers de mise en conformité.

Conclusion

La réglementation UNECE et les standards de sécurité applicables aux véhicules et aux systèmes d’information et de production constituent une opportunité de sécurisation, mais aussi de positionnement de valeur sur la qualité et la protection des usagers et de leurs données. Cette évolution, qui viendra avec ses défis, contribuera à une meilleure maîtrise de la sécurité, couvrant l’ensemble des systèmes de production, en bénéficiant ainsi des investissements faits dans la mise en conformité à la nouvelle réglementation.

L’application de la réglementation permettra sans doute de faire avancer l’écosystème d’un point de vue sécurité et développera les bonnes pratiques chez les constructeurs et l’ensemble des acteurs de la chaîne de valeur, dont les fournisseurs, les start-ups, les développeurs et les professionnels de l’IT et de la cybersécurité. Cet élan engendrera l’émergence de nouveaux services tels que des SOC spécialisés pour les véhicules, avec tous les outils nécessaires à la collecte et à l’analyse d’événements. Il permettra aussi une systématisation des tests d’intrusion sur les voitures et les systèmes de l’écosystème.