Malgré les efforts des constructeurs, les automates industriels sont loin d’avoir un niveau de sécurité satisfaisant. Trop peu d’entre eux font d’ailleurs l’effort de se lancer dans ce challenge. Si l’on ne peut pas avoir de composants sécurisés, que faire ?

Même chez Siemens, l’un des constructeurs les plus en pointe sur les problématiques de cybersécurité, les chercheurs trouvent encore des failles graves. Parmi les dernières découvertes, il est par exemple possible d’accéder au firmware d’un automate récent en lecture/écriture pendant une fraction de seconde,  une durée suffisante pour injecter du code ou vérifier le firmware en place.

Autre illustration, la découverte d’absence d’authentification de la plateforme d’ingénierie TIA et la faible authentification sur des automates S7, la même clé privée étant utilisée pour tous les modèles d’une même gamme. De nombreuses vulnérabilités sont rendues publiques régulièrement (merci F. Ciutat pour les exemples récents ci-dessous sur S7-1500). Bien sûr, c’est quand on les cherche qu’on les trouve, il n’y a aucun doute que les automates moins sécurisés ont encore plus de failles…

Qu’en conclure ?

Même les automates de constructeurs ayant fait des efforts de sécurisation présentent des vulnérabilités. Ces dernières démontrent qu’implémenter de la sécurité sans aller jusqu’au bout de la logique de sécurisation n’est pas pertinent. Les chercheurs, et donc les pirates, vont toujours trouver les limites du système…

Par ailleurs, ces acteurs ayant une réflexion plus poussée sur la cybersécurité sont l’arbre qui cache la forêt chez les constructeurs. Je n’aborde même pas les variantes « low cost » par exemple CoDeSys(*) chez qui les chercheurs ne font même plus l’effort de trouver des failles. Quand ils s’en donnent la peine, comme l’Université Libre de Berlin ou ceux ayant fait des découvertes estivales, c’est pour livrer des lots complets de vulnérabilités.

Enfin, d’après des retours que j’ai reçus en animation de formation à l’IRA, les bureaux d’études, et a fortiori les intégrateurs, trouvent les exigences de cybersécurité trop élevées. Pour ISA/IEC 62443 par exemple, qui définit 4 niveaux de sécurité, les exigences sont difficiles à respecter dès lors qu’on s’éloigne du niveau de base.   Seul le Security Level 1 est jugé atteignable, mais les exigences sont jugées hors de portée à partir du SL 2 (sur 4 !).

Que faire ?

Monter un système de contrôle-commande cyber-sécurisé est donc très difficile considérant la diversité des fonctionnalités et équipements qui le composent, d’autant plus que chacun d’eux migre technologiquement vers IP en embarquant des serveurs web/telnet, et quelquefois ont des ports activés et non documentés. Il paraît impossible de sélectionner des composants sécurisés pour l’ensemble des fonctions nécessaires à la construction d’une ligne de production. La solution reste donc de travailler sur l’architecture. Une première étape consiste à cloisonner et sécuriser par le haut. On maintiendra cependant un objectif de patcher pour supprimer les vulnérabilités quand c’est possible : l’objectif n’est pas de faciliter la tâche des pirates !

En conclusion, il est vain d’essayer de baser la sécurité de son process sur les équipements, puisque les constructeurs les plus vertueux ne parviennent pas encore à faire des produits sans faille majeure. Concernant les mesures techniques, seules les approches d’architecture (segmentation, filtrage, détection, règle d’accès distant, etc.), supportées par des équipements de sécurité dédiés, permettent d’assurer un niveau de sécurité acceptable face à des hackers motivés et équipés. (edit 19/3) Il convient cependant de rappeler que les mesures techniques représentent une minorité des mesures de sécurité, les mesures organisationnelles (responsabilité, audits etc…) et de formation (sensibilisation…) restent primordiales (fin edit 19/3 – merci Fabien pour le retour via son commentaire que vous trouverez ci-dessous en intégralité).

(*) CoDeSys : il s’agit d’une offre logiciel d’automatisme, consistant en un ensemble de firmware, IHM, serveurs de gestion des alarmes et données, bibliothèques de protocoles et développement logiciel. Son positionnement commercial très agressif fait qu’il est proposé pour de nombreux matériels (Türck, Wago, Festo, Eaton, mais aussi linux pour des soft-PLC – automates en logiciels – et même Arduino et Raspberry Pi…). De très nombreuses vulnérabilités ont été découvertes, sur une variété des composants logiciels. Depuis 2019 CoDeSys communique sur ces vulnérabilités, mais le chantier semble vaste.