Communiquer, informer, ordonner… dans l’univers industriel, les automates disposent de leur propre langage pour dialoguer et faire fonctionner toute l’infrastructure opérationnelle. On parle alors de protocoles de communication industriels. Un champ lexical qui a posé ses bases sémantiques sur les notions de sûreté, d’efficacité, de productivité et, depuis la cyberattaque Stuxnet, de cybersécurité. Un épisode qui a forcé le monde industriel à prendre conscience des vulnérabilités des systèmes de contrôle industriels. Et de prendre le train cyber en marche.
Il y a dix ans, frappait Stuxnet
Retour en Iran, en 2010 : ce ver informatique visait directement les automates programmables (PLC) qui contrôlaient les centrifugeuses d’enrichissement d'uranium. Il avait alors mis à mal l’infrastructure nucléaire en perturbant le fonctionnement des centrifugeuses, et surtout permis au monde industriel de prendre conscience des vulnérabilités des systèmes de contrôle et de la nécessité d’apposer des solutions de sécurité aux protocoles de communication industriels.
Le secteur se rendait compte du décalage qu’il existait entre ces formats d’échanges de données entre automates, mis au point il y a des décennies, et la réalité d’un monde de plus en plus connecté. La cybersécurité n’étant pas une préoccupation jusqu’alors, peu de protocoles industriels proposaient nativement des mécanismes de sécurité. Et c’est toujours le cas.
Les attaques BlackEnergy et Industroyer, spécifiquement conçues pour perturber le fonctionnement des réseaux électriques en Ukraine, font figure de proue dans ce genre de cyber méthodes. Pollution des eaux, rupture de pipelines, explosions ou encore dommages physiques, les scénarios catastrophes sont multiples. « Les automates industriels sont interconnectés et communiquent entre eux – ainsi qu’avec le poste de supervision – par le biais de protocoles industriels spécifiques à ces environnements, précise Vincent Nicaise, Responsable des partenaires et de l'écosystème industriels chez Stormshield. Cette forme de langage a des impacts majeurs dans le réel, puisqu’elle permet de piloter des systèmes physiques. Par exemple, actionner une vanne de vidange d’une cuve, faire passer un feu de route au vert ou encore piloter la chaufferie d’un bâtiment. Puisque le niveau de criticité de ces communications est très élevé, il est donc primordial d’y apposer une couche de cybersécurité pour s’assurer de la légitimité des échanges ». Mais est-ce si simple ?
Une cybersécurité industrielle qui se heurte à la temporalité de l’OT
Même après l’épisode de Stuxnet, la plupart des protocoles industriels n’intègrent pas de dimension de cybersécurité dans leur fonctionnement. Et ne fournissent aucun mécanisme d’authentification ou de chiffrement. Une situation d’autant plus précaire, que les équipements OT qui y font appel ont un cycle de vie bien supérieur à ceux de l’IT. Le risque cyber est donc démultiplié sur la période… C’est le cas notamment des protocoles les plus connus tels que Modbus, Profinet, BACnet (spécifique à la GTC-GTB), IEC 60870-5-104 ou encore DNP3 (spécifique aux réseaux de distribution électriques). Au cours des dernières années, certaines propositions ont été faites pour améliorer la sécurité de certains de ces protocoles industriels.
« Néanmoins, dans la plupart des cas, aucune de ces solutions ne garantissait un niveau de sécurité acceptable, précise Vincent Nicaise. Principalement parce que les fournisseurs d’équipements d’automatisme les avaient développés sans connaissance ni expérience des risques cyber. Aujourd’hui les protocoles sécurisés se comptent encore sur les doigts d’une main. »
Une méconnaissance des risques qui s’accompagne d’idées reçues tenaces. La principale étant que les industriels s’estiment à l’abri de toute malveillance s’ils utilisent des protocoles et des bases de données propriétaires. Même si les solutions propriétaires peuvent rassurer certains, elles peuvent aussi n’avoir fait l’objet d’aucune analyse de sécurité. Tout dépend ici en réalité de l’attention portée à la sécurité de cette solution par le concepteur, autour de l’audit de code, d’une analyse de sécurité… Dans un secteur historiquement peu sensible à la menace cyber, le doute est au contraire légitime. Par ailleurs, il faut bien avoir en tête que si un protocole n’est pas vulnérable, toute la chaîne sous-jacente du protocole peut l’être en revanche. Prenons par exemple le protocole OPC UA, qui introduit les dimensions de protection par signature et chiffrement. Puisqu’il est lui-même basé sur le protocole de transport TCP, il est vulnérable aux attaques TCP, IP et Ethernet. Entre la protection des réseaux industriels isolés ou bien les contraintes de temps de réponse incompatibles avec les mécanismes de sécurité, bien d’autres mythes relatifs aux systèmes industriels existent ; l’ANSSI en a dressé une liste dans un guide.
De l’importance de connaître son parc
« La plupart des industriels discernent les protocoles auxquels leurs équipements ont recours, pour autant ils n’ont pas une connaissance fine de tous les échanges qui peuvent exister autour : quels sont les automates qui communiquent entre eux, et avec quel actionneur, quel capteur… Il est important de connaître la cartographie physique et logique de son réseau. Enfin, et c’est primordial, il faut pouvoir en assurer le suivi et mettre à jour ces informations régulièrement, car les infrastructures évoluent au fur et à mesure du temps », précise Simon Dansette, Product Manager Stormshield. À ce besoin, peut répondre la sonde réseau : en écoute sur le réseau, elle analyse les protocoles, les flux de communication et permet de faire une cartographie de cette matrice de flux de l’installation. Mais son action est limitée car elle ne possède pas de mécanisme qui pourrait bloquer les flux ou isoler un équipement identifié comme vérolé. « Cette solution n’est utile que pour augmenter la visibilité en complément du pare-feu industriel, puisqu’elle ne permet en aucun cas de sécuriser les flux en bloquant les actions malveillantes », précise Simon Dansette.
En outre, il est primordial de bien comprendre comment fonctionnent les processus industriels. La plupart des formations OT à destination des professionnels de l’IT se limitent malheureusement à la connaissance IHM (interface homme-machine) et la configuration de l'automate. Il est pourtant primordial de savoir quels protocoles industriels sont utilisés pour transporter une commande, ou activer un service et quel type d'anomalies peut survenir sur le réseau. Car les experts cyber en charge de la sécurisation des réseaux OT se retrouvent démunis – en cela qu’ils ne connaissent pas les environnements industriels, leurs fonctionnements ou encore leurs contraintes opérationnelles. Ces lacunes liées à la convergence du monde de l’IT et de l’OT, semble nous ramener à la fracture entre la VOIP (voix sur IP) et la téléphonie traditionnelle qui s'est produite il y a 20 ans. Il y avait alors deux mondes : celui des experts réseaux et celui des experts téléphonie. Chacun ignorait les problèmes des autres. Par rapport à la convergence téléphonique qui s'est produite il y a vingt ans, nous avons désormais un avantage : la virtualisation. À l’heure des jumeaux numériques, il est désormais possible de créer des répliques virtuelles de l’usine pour tester les attaques et les solutions à y apporter.
Les solutions de sécurisation viables
Heureusement, certains protocoles industriels proposent nativement des mécanismes de sécurité. C’est le cas par exemple de DNPSec (version sécurisée de DNP3), OPC UA (signé / chiffré), IEC 62351 ou encore CIP Security (une extension du protocole CIP). Mais le changement des équipements pour supporter ces protocoles est trop long ou coûteux pour les industriels ; la solution à court terme est donc d’apposer une couche de cybersécurité industrielle à leurs protocoles non sécurisés.
Et pour cela, le secteur a recours à deux principales approches actuellement. D’un côté, les sondes de détection pourront détecter un flux illégitime ou une dérive de process. Mais comme évoqué plus haut, elles ne seront pas en mesure de bloquer les flux illégitimes ou d’intervenir sur le système. De l’autre côté, l’autre approche est alors l’utilisation des pare-feux industriels. Généralement basés sur une technologie de détection par signature, ils permettent, à partir d’une base de signatures de malware connus, de connaître en temps réel les tentatives d’intrusion et de les bloquer. Une méthode d’analyse protocolaire qui a également ses limites : si une nouvelle attaque non-connue advient, elle n’est donc pas rattachée à une signature et n’aura aucun mal à passer pour un flux de communication légitime. « En outre, le fait d’apposer une analyse protocolaire par signature, peut ralentir la communication entre automates et déstabiliser le process, affirme Vincent Nicaise. C’est problématique dans un système industriel où chaque information envoyée est attendue à un moment bien précis pour être traitée. » Pour rappel, un système de contrôle-commande industriel intégrant une cinquantaine d’automates va engendrer près de 20 000 requêtes envoyées par seconde. Et autant de réponses : le système dans son ensemble génère donc au total 40 000 paquets par seconde – soit 40 paquets toutes les millisecondes. D’où l’importance de choisir une solution de pare-feu industriel adéquat pour éviter un certain temps de latence. Une alternative est alors l’utilisation d’un plugin IPS (Intrusion Prevention System), qui contextualise les données analysées permettant d’identifier le protocole industriel et ses spécificités. Ainsi, le pare-feu industriel devient capable d’identifier les codes ou fonctions utilisés et de les laisser passer (en fonction de la politique de sécurité définie). De cette manière, les flux légitimes et strictement nécessaires à la conduite du process sont reconnus – et sont les seuls à pouvoir passer, à la manière d’une white-list (ou allow-list). Et pour aller encore plus loin, cette analyse protocolaire peut être couplée à des règles de firewall. Un cas d’usage particulièrement intéressant dans le cadre de la télémaintenance ; où il est possible d’autoriser l’utilisation d’un certain protocole uniquement à une personne authentifiée et/ou uniquement pendant une plage horaire d’intervention.
Face à cette problématique, « il est préférable de choisir un système de prévention d’intrusions qui va contextualiser les communications en fonction du protocole détecté et cibler l’analyse de conformité protocolaire », précise Vincent Nicaise. En effet, ces systèmes limitent les faux-positifs, facilitent la gestion des codes fonctions personnalisés – qui vont souvent de pair avec les protocoles industriels – et assurent une protection contextuelle globales des échanges entre les automates et les postes de contrôle.
Et pour aller encore plus loin, un pare-feu industriel doit pouvoir intégrer des signatures personnalisées (custom patterns), en personnalisant et en précisant certaines fonctionnalités. « Je peux ainsi déterminer que la température de mon four ne doit jamais dépasser les 500 degrés et ce, quelles que soient les informations qui transitent. Le custom pattern, via le firewall, analyse les trames et permet de contrôler précisément certaines variables. Ainsi, si l’information ‘passe le four à 1 000 degrés’ circule, celle-ci sera bloquée et non traitée », explique Khobeib Ben Boubaker, Head of Industrial Security Business Line chez Stormshield. Ces règles personnalisées proposées aux industriels permettent alors de s’adapter pleinement au contexte métier et de maîtriser, encore plus finement, les flux de communication en cas de dépassement de seuil, ou de règles non-établies au préalable. Un pas de plus vers la cybersécurité des systèmes industriels.
