KANBrief 3/23
Les composants de sécurité fonctionnelle protègent la vie et la santé des personnes, par exemple en empêchant l’accès aux zones dangereuses des machines et installations. Il est également important que les manipulations extérieures n’impactent pas la sécurité. Il est essentiel pour cela que l’état de l’art soit systématiquement mis en œuvre et que les fabricants et exploitants réagissent de manière appropriée à toute faille de sécurité.
Pour que les fonctions de sécurité d’un système de commande puissent fonctionner fiablement, il faut que ce système soit lui-même sûr, et donc protégé contre les pannes et manipulations. On ne peut qu’être effrayé face au nombre croissant de catastrophes relatées dans le domaine de la sécurité informatique industrielle. Mais il y a tout lieu d’être optimiste, l’état de la technique permettant de fait d’éviter très facilement la quasi-totalité des failles de sécurité, comme le montre l’exemple caractéristique suivant :
Dès 1883, Auguste Kerckhoffs énonçait six règles fondamentales à respecter pour assurer la confidentialité d’une communication (Auguste Kerckhoffs 1883 : « La cryptographie militaire »). La deuxième était la suivante : « Il faut que le système n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi. » De toute évidence, Guglielmo Marconi ne connaissait pas ce texte. Pour garantir une communication confidentielle, sa télégraphie exigeait que personne n’entre en possession de l’un des appareils ou en construise un identique et le règle sur la même fréquence. En 1903, Nevil Maskelyne mettait le doigt sur le problème en transmettant en morse des messages injurieux, parasitant une démonstration de Marconi. Il est considéré depuis comme étant l’un des premiers hackers de l’histoire. Bien que le chiffrement sécurisé à l’aide de méthodes cryptographiques soit connu depuis longtemps, ce même défaut de conception apparaît encore aujourd’hui, par exemple dans les commandes radio de feux de circulation1 ou de grues industrielles2.
À ce jour, le navigateur de l’Université de Brême dédié aux normes relatives à la sécurité informatique (en allemand) a saisi dans une base de données quelque 800 normes et plus de 2000 résultats pertinents concernant la législation. Le problème est que les documents utilisent des termes différents et ne les définissent pas toujours clairement. Alors que certains documents traitent largement de la « security » ou de la « sécurité informatique », d’autres inventent de nouveaux termes, sous forme de mots-valises composés de « cyber » et d’un autre mot. Ces mots nouvellement créés doivent être définis exactement dans le document, car ils n’ont en soi aucune signification univoque. Le terme « cybersécurité » désigne tantôt une activité, tantôt une mesure prise contre les attaques venues du web, tantôt un état dans lequel le produit est protégé contre les attaques par radio.
Plutôt que de créer de nouveaux mots, il est préférable de travailler avec les termes sans équivoque que sont la sécurité informatique, ou le terme anglais security. S’il s’agit de restreindre la signification, par exemple aux attaques par radio, cette restriction devra alors être clairement précisée. Le Règlement européen sur les machines a opté pour une autre solution très élégante, en exigeant, à l’Annexe III 1.1.9, une « protection contre la corruption », en étant plus clair sur ce point que l’ancienne directive Machines. Se concentrant sur l’objectif de protection selon lequel aucune situation dangereuse ne doit survenir, provoquée notamment par un dispositif distant, le règlement ne précise pas en détail ce qui peut être à l’origine de la corruption.
Une communication rapide et efficace est la clé d’une réaction adéquate aux failles de sécurité. Les déficiences dans ce domaine ont toutefois été mises en évidence en décembre 2021, lorsqu’une faille de sécurité dans la bibliothèque logicielle Log4J a fait les grands titres de l’actualité. Cette bibliothèque fait en effet partie intégrante non seulement de nombreux services de serveur, mais aussi d’une quantité de composants industriels. Alors que, d’un côté, des voix se sont fait entendre, dénonçant une mauvaise utilisation de la bibliothèque, et affirmant qu’on aurait pu éviter les problèmes de sécurité en lisant la documentation, de nombreux fabricants se sont en même temps demandé s’ils étaient victimes des failles de sécurité. Il n’a pas été rare que plusieurs mois s’écoulent avant que les fabricants sachent si leurs produits étaient impactés.
Ce qui a fait défaut, en résumé :
Pour pallier le manque d’informations et d’interfaces uniformes, il existe un ensemble de spécifications ouvertes élaboré par divers groupements d’entreprises, d’autorités et d’organisations, et que chaque entreprise peut mettre en œuvre dès à présent (voir tableau). Un contact d‘urgence selon la spécification RFC 9116 de l‘IETF est consigné sur le site web dans un simple fichier security.txt, dans lequel un fabricant peut aussi renvoyer à sa liste de recommandations d’action (CSAF)3. Chaque produit matériel ou logiciel reçoit un identifiant unique au niveau mondial (CPE), ce qui permet aux messages d’alerte internationaux (CVE) d’être automatiquement et précisément attribués aux produits et versions en question. La criticité de la vulnérabilité est évaluée, aussi que faire se peut, par un système de notation international standardisé (CVSS). La spécification ouverte SPDX selon ISO/IEC 5962:2021 permet de documenter, pour chaque projet et sous un format lisible par machine, quelles bibliothèques ont été utilisées. Côté exploitant, un programme peut alors interroger régulièrement tous les produits pour identifier toute alerte de sécurité et afficher les recommandations d’action.
Certaines grandes entreprises ont déjà recours à ces spécifications. Il est maintenant essentiel que toutes les autres entreprises suivent rapidement cet exemple, afin que l’information sur les problèmes de sécurité se fasse rapidement et à moindres frais.
La première mesure à prendre par les entreprises consisterait tout au moins à veiller à être joignables en cas d’incident de sécurité informatique, et d’indiquer qui contacter en cas d’urgence. En suivant les instructions données sous cert.dguv.de (en anglais) cette mesure peut être mise en place en quelques minutes.
Jonas Stein
Responsable du laboratoire de sécurité informatique industrielle et du groupe de travail Security de la DGUV
Jonas.Stein@dguv.de
1 Reportage TV (chaîne ARD) « Quand les feux de circulation passent au vert par piratage informatique » 2021 (en allemand)
2 Andersen et al, 2019 « A Security Analysis of Radio Remote Controllers for Industrial Applications » (en anglais)
3 csaf-v2.0, Common Security Advisory Framework Version 2.0. Edited by Langley Rock, Stefan Hagen, and Thomas Schmidt. 18 November 2022. OASIS Standard.