Sécurité des véhicules connectés : le Royaume-Uni pose les règles du jeu

Gestion du cycle de vie des logiciels, encadrement des échanges de données, coopération entre les maillons de l’industrie… En collaboration avec le Centre pour la protection des infrastructures nationales, le ministère britannique des Transports édicte une série de « bonnes pratiques » à destination des acteurs impliqués dans le secteur du véhicule connecté.

Ces derniers sont d’abord invités à établir, en leur sein, une « culture de la sécurité » qui permette à chaque collaborateur de saisir son rôle et ses responsabilités en la matière. Le tout en intégrant cet enjeu sur l’ensemble du processus de développement des produits et services.

Concernant la gestion des risques, les organisations devront exiger de leurs ingénieurs une connaissance et une compréhension des menaces actuelles, ainsi que des pratiques pour les juguler. Elles collaboreront par ailleurs avec les tiers appropriés pour améliorer la réponse auxdites menaces.

Toujours sur ce volet, des procédures d’évaluation des risques seront mises en place, y compris pour identifier ceux spécifiques à – ou qui englobent – la supply chain, des sous-traitants aux fournisseurs.

Il est également recommandé aux intéressés de pouvoir assurer la sécurité de leurs systèmes sur toute leur durée de vie, en proposant les services d’assistance après-vente nécessaires, mais aussi en disposant d’un programme d’identification des vulnérabilités critiques et en s’assurant que leurs systèmes puissent permettre, en cas d’incident, la récupération de données identifiables.

Méthodes « agiles »

Qu’en est-il en matière de coopération ? Selon le ministère des Transports, il devra, d’une part, être possible de valider l’authenticité et l’origine de tous les composants circulant dans la chaîne d’approvisionnement ; et de l’autre, de justifier de la qualité des moyens mis en place pour l’interaction entre les différents maillons de l’écosystème.

Les acteurs de l’industrie s’assureront par ailleurs que l’ensemble de leurs implémentations puissent « être modifiées rapidement » si besoin, non sans exploiter des briques complémentaires (dispositifs d’alerte, fermeture de ports, couches de sécurité…) pour renforcer la protection de leurs systèmes, y compris distants.

Dans le même esprit, chacun devra pouvoir attester à tout moment de l’état de n’importe quel composant logiciel (configuration, version, etc.) et le mettre à jour de façon sécurisée – ou le réparer s’il est corrompu. Autant que possible, on adoptera des pratiques de développement ouvertes, fondées entre autres sur le partage de code source.

Pour ce qui est des données, il faudra s’assurer qu’elles soient suffisamment protégées, aussi bien lorsqu’elles sont stockées que lorsqu’elles sont transmises, tout particulièrement pour celles qui peuvent permettre d’identifier des individus. Quant aux informations entrantes, elles devront être traitées comme non sécurisées jusqu’à avoir été vérifiées.

Les systèmes qui traitent ces données devront quant à eux pouvoir rester opérationnels s’ils reçoivent des éléments corrompus, invalides ou malveillants… mais aussi si des composantes critiques sont compromises ou cessent de fonctionner.