L'automate programmable se blinde contre les cyberattaques

Le constat fait froid dans le dos. « Il faut moins d’une minute à un cyber­attaquant pour venir à bout des défenses d’un automate programmable industriel connecté à internet », alerte Stéphane Mocanu, maître de conférences à l’Institut polytechnique de Grenoble. Un résultat issu des travaux de Katsunari Yoshioka, professeur de cybersécurité industrielle à l’université nationale de Yokohama, présentés le 24 avril lors de la cinquième édition de l’atelier franco-japonais sur la cybersécurité. Au cœur des usines, les automates programmables sont particulièrement exposés. Au début des années 2000, ils ont remplacé la transmission série, sur un réseau local via des protocoles comme Profibus, Modbus ou S7, par une communication utilisant la suite internet (TCP/IP) et le standard ethernet (avec des protocoles tels que Profinet, Modbus-TCP ou S7-TCP). Ils sont ainsi devenus accessibles à distance, alors qu’ils n’intégraient aucun système de cybersécurité. Une vulnérabilité critique étant donné que les automates sont au contact direct des machines de production.

Stuxnet en a fait la démonstration éclatante en 2010. Ce ver informatique a infecté les automates Simatic S7-300 de Siemens, qui contrôlaient les centrifugeuses de l’usine d’enrichissement d’uranium de Natanz, en Iran. Il s’est propagé des serveurs de Behpajooh, un fournisseur de systèmes d’automatisation, à ceux du producteur d’acier Mobarakeh Steel Company, puis à ses partenaires, avant d’atteindre nombre de pays, selon Kaspersky. L’épisode a fait l’effet d’une douche froide pour les constructeurs d’automates. « Nous nous sommes rendu compte que nous n’étions pas prêts à l’époque à nous défendre contre de telles attaques », admet Fabien Miquet, le responsable cybersécurité de Siemens. Même son de cloche chez Yann Bourjault et Pierre Paterni, ses homologues de Schneider Electric et de Rockwell Automation. Les fabricants d’automates programmables industriels (API) sont donc retournés à leur planche à dessin pour améliorer leur conception. Premier défi, garantir l’authenticité du firmware, le logiciel embarqué dans l’automate, afin d’éviter qu’un assaillant installe un logiciel malveillant sous couvert d’une fausse mise à jour – comme avec Stuxnet. Pour cela, il faut s’assurer de la signature du logiciel. « On passe la configuration du firmware à la moulinette cryptographique et on en sort un petit motif (un haché, ou hash), qui permet, en utilisant la même clé de chiffrement, de s’assurer que le firmware n’a pas été modifié », détaille Fabien Miquet. Une telle opération est calculée au moyen d’une puce dédiée embarquée dans l’API. Le dernier modèle de Siemens, le Simatic S7-1500, et celui de Schneider Electric, le Modicon M580, en sont dotés. En revanche, les automates anciens ne possèdent pas les capacités de calcul nécessaires.

Les nouveaux automates fabriqués depuis cinq ou six ans ont la capacité de générer des fichiers de logs, soit un historique des événements relatifs à la cybersécurité, s’enthousiasme Stéphane Mocanu. C’est le cas du S7-1500, confirme Fabien Miquet : « Nous arrivons à journaliser quasiment tout ce qu’il se passe dans nos automates, qui sont capables d’exporter ces logs sur le serveur Syslog, dans le format standard. » La collecte de ces données permet ensuite aux cyber-experts de « chercher à corréler, sur une console de supervision, tous les événements journalisés », pour identifier des signaux faibles, poursuit le spécialiste de Siemens. L’Agence nationale de la sécurité des systèmes d’information (Anssi) impose aux constructeurs d’autres critères, comme la gestion des droits d’accès à l’automate, pour bénéficier de la moindre certification. La version 2.11 du Modicon M580, qui les remplit, a pu décrocher une certification de premier niveau, en 2018. Le Simatic S7-1500, certifié en 2016, dispose d’une qualification (un niveau d’évaluation supérieur), renouvelée en mai.

Reste que l’utilisation historique de protocoles de communication propriétaires, spécifiques à chaque fabricant, freine le développement d’outils de cybersécurité pour les automates. C’est peu dire que Schneider, Siemens et autres Rockwell ne jouent pas la transparence, diffusant au compte-gouttes les informations techniques sur leurs protocoles. « Sans partenariats avec les fournisseurs d’automatisation industrielle, les protocoles sont a priori incompréhensibles par les systèmes de détection », déplore Emanuel Salmona, vice-président chargé des partenariats pour Claroty, un fabricant de sonde de cybersécurité industrielle. En outre, le manque d’interopérabilité – la capacité à communiquer malgré des langages différents – représente « un obstacle majeur » au chiffrement des communications, selon Stéphane Mocanu.

B.a.-ba de la sécurité, le chiffrement des communications entrantes et sortantes des API est inaccessible aux automates anciens. Les nouveaux protocoles TCP/IP implémentés sur les appareils les plus récents, eux, sont chiffrables, soit avec la technique la plus classique, TLS/SSL (transport layer security/secure sockets layer), soit avec des méthodes plus élaborées comme Blowfish, Data encryption standard (DES) ou encore Advandced encryption standard (AES). « Prenez Modbus : pratiquement tous les automates le supportent. En revanche, si vous voulez passer à ModbusTCP chiffré, il faut que tout le monde l’implémente. C’est très compliqué… », insiste Stéphane Mocanu. De quoi relancer l’intérêt pour un standard de communication chiffré. « Aujourd’hui, l’évolution se fait vers OPC UA, un protocole standardisé chiffrable développé par l’OPC Foundation qui remplacerait Modbus, S7, Profinet et autres », indique Frédéric Cuppens, professeur à l’IMT Atlantique et responsable de la chaire « Sécurité des infrastructures critiques » de l’Institut Mines-Télécom.

S’il commence à être utilisé par certains automates, comme les S7-1500, OPC UA ne s’est pas encore imposé en standard universel de communication des systèmes industriels. Rockwell Automation lui préfère CIP, un protocole standardisé par l’ODVA, une organisation américaine des industriels de l’automatisation, et qui existe en version chiffrée, CIP Security. Surtout, OPC UA n’est pas adapté à la communication entre API. « À ce niveau, vous devez garantir un temps de propagation de l’information très court – 3 millisecondes pour les smartgrids, par exemple –, précise Stéphane Mocanu. OPC UA n’est pas un protocole temps réel. » En attendant un hypothétique standard, il existe des solutions pour chiffrer les communications de protocoles non sécurisés entre API. « On ajoute une carte électronique à la sortie d’un automate qui chiffre les données jusqu’à une autre carte électronique qui les déchiffre et les transmet à un autre automate », poursuit le chercheur. Le M580 de Schneider Electric est compatible avec un module IPsec, qui fonctionne ainsi. « Il permet de monter un canal sécurisé au-dessus d’un réseau de moindre confiance », détaille Rachid El Alaoui, consultant chez Amossys, un cabinet de conseil en cybersécurité mandaté par l’Anssi pour évaluer le S7-1500.

La route vers la sécurisation des API est encore longue. En août, des chercheurs israéliens ont exploité une faille d’authentification dans le S7-1500, l’un des plus sécurisés au monde, et ont constaté que Siemens utilisait la même clé de cryptographie pour tous les automates de sa gamme. « Installez la fonctionnalité de protection d’accès interdisant les modifications non autorisées des appareils », a rétorqué le constructeur allemand. Son message est clair : la cybersécurité des automates est aussi l’affaire de ceux qui les achètent.