Les systèmes industriels sont une catégorie de système d’information à part, possédant des codes et propriétés différentes des systèmes IT « classiques ». Il est reconnu que le niveau de maturité du monde industriel en matière de cybersécurité est globalement en retard comparé à ce qui se fait sur des SI classiques. Ce retard peut être expliqué par plusieurs facteurs, l’un d’eux étant l’héritage historique présent sur les systèmes industriels parfois en place depuis plusieurs décennies. Cet article va se concentrer sur l’un de ces aspects historiques que l’on peut retrouver dans bon nombre de réseaux industriels aujourd’hui : les réseaux dit « automates » ou « de terrain ». Nous allons d’abord aborder l’historique qui a abouti à l’existence de ces réseaux, puis étudier sur différentes thématiques les points forts et faibles du modèle vis-à-vis des besoins actuels et futurs de cybersécurité pour répondre à la problématique suivante : les réseaux de terrain sont-ils adaptés aux nouveaux besoins de cybersécurité ?
Historique
Remontons dans le temps : nous n’allons pas parler des différentes révolutions industrielles, mais notre histoire commence à l’entame des années 70. A l’époque, pas de réseau Ethernet, de modèle OSI ou même d’informatique. Les systèmes de production industriels reposent sur des mécanismes physiques à travers l’utilisation de signaux pneumatiques ou électriques. Les années 70 voient l’arrivée des premiers principes d’automatisation, et l’intégration des premiers équipements intelligents : les automates de programmation industrielle. Ces équipements permettent une mutualisation des ressources, un automate pouvant gérer plusieurs entrées et sorties électriques, et donc de centraliser la gestion des processus. Les automates intègrent aussi des modules de communications, et les systèmes industriels voient alors l’apparition des premiers bus réseau, avec l’utilisation de protocoles de communication série.
Ce modèle d’architecture continuera de se développer dans les années 80 avec la multiplication des protocoles industriels, notamment sur le modèle « Controller-Workers » : Un automate principal contient la base de données centralisée et joue le rôle de chef d’orchestre en étant relié aux « Workers », correspondant à d’autres automates, cartes d’entrées/sorties déportées, etc… Cette architecture permet de simplifier la programmation des processus en un point unique, et aussi la communication avec les organes de visualisation type interface homme-machine ou SCADA propriétaire.
Les années 90 voient la démocratisation du modèle TCP/IP et l’intégration de l’informatique « classique » dans les environnements industriels : plus besoin d’équipements propriétaires, un logiciel SCADA peut maintenant s’installer sur des systèmes classiques… encore faut-il que ces ordinateurs puissent communiquer avec les automates ! Des cartes de réseaux séries existent, mais les protocoles industriels commencent à s’adapter pour fonctionner sur du réseau Ethernet classique. Peu à peu, on remplace les automates maîtres afin de leur permettre d’utiliser les protocoles TCP/IP sur le réseau principal, tout en continuant à avoir des cartes réseaux séries pour les équipements de terrain. Et puis ce fut au tour des équipements de terrain de s’adapter à la standardisation de l’utilisation de TCP/IP plus ou moins partout, faisant qu’aujourd’hui l’utilisation de communications séries est minime. Même les entrées/sorties électriques tendent aujourd’hui à être délaissées au profit des liaisons IP sur des capteurs et actionneurs, via par exemple l’utilisation de connectiques « Single Pair Ethernet » assurant une connexion économique et peu encombrante.
Evolution des architectures terrains
On en arrive donc aujourd’hui à pouvoir rencontrer régulièrement l’architecture suivante : Un réseau physique industriel « principal » (en topologie étoile ou en anneau) sur lequel on retrouve tous les équipements de supervision et de communications avec l’extérieur (SCADA, Data Historian, poste opérateur…) ainsi que les automates « controllers », qui chacun possèdent un second port réseau. Ce second port réseau permet de créer sur chaque automate un sous-réseau isolé sur lequel se trouve les équipements au plus proche du processus physique. L’automate controller a alors un rôle de « pivot fonctionnel », échangeant d’un côté avec le SCADA principalement, et de l’autre avec les équipements de terrain via les registres de données de l’automate. Cette architecture peut être déclinée de plusieurs façon, par exemple en remplaçant l’automate pivot par un serveur classique, ou en combinant plusieurs couches de réseaux isolés avec un serveur SCADA possédant deux ports réseau, séparant le réseau industriel principal et le réseau de supervision dans lequel on retrouverait les automates controller sur lesquels se fait une nouvelle séparation avec des réseaux de terrain.
Exemple d’architecture industrielle intégrant des réseaux de terrain
Maintenant l’historique abordé, parlons du présent et notamment des trois évolutions qui nous amènent aujourd’hui à questionner la pertinence de ce modèle d’architecture :
- L’industrie 4.0 qui a changé l’exposition des réseaux industriels, passant d’un modèle isolé vers un modèle ultra-connecté afin de répondre aux enjeux de big data, d’interconnexion avec le Cloud, de jumeau numérique, etc…
- La standardisation des technologies industrielles permettant de se détacher des fournisseurs industriels, via le développement de « Soft PLC » sur Linux ou Windows embarqué ou l’utilisation de protocoles industriels standardisés type OPC-UA.
- L’introduction des solutions de cybersécurité dans le cœur du réseau industriel comme les serveurs de mise à jour, des pare-feux, des antivirus voire EDR ou même des sondes de cartographie, dont la présence prend sens avec la modernisation des infrastructures informatiques et le développement de la cybersécurité en milieu industriel.
Pour étudier la pertinence des réseaux de terrain face à ces nouveaux enjeux, nous allons aborder quatre sujets de sécurité opérationnelle : la sécurité des réseaux, la détection & cartographie, la gestion des mises à jour et les accès distants.
Sécurité réseau
La première question à se poser est simple : Quel est l’avantage des réseaux de terrain d’un point de vue cybersécurité ? Cet avantage se traduit dans le principe même du modèle d’architecture : l’utilisation d’un équipement en pivot offre une isolation physique entre un réseau industriel et un réseau de terrain. Il n’est donc par principe impossible de faire communiquer directement les deux réseaux, la transmission d’informations se faisant à travers une base de données (registres pour les automates, base de données OPC pour un serveur…). Pas besoin de pare-feu ou de diode : aucun flux ne peut aller d’un réseau à un autre, ce qui représente le meilleur moyen de se protéger d’une propagation vers les équipements de terrain.
Mais cette séparation via un équipement physique non-dédié au réseau est-elle vraiment infaillible ? Sur un équipement fonctionnant avec un système « classique » Windows ou Linux standard, la réponse est non. Il existe de multiples exemples d’attaques convertissant ces systèmes en pivot, exploitant les nombreuses possibilités offertes : exploitation de protocole d’accès distant type RDP, VNC ou SSH, RAT, implant C2C… De ce fait, une séparation avec ce type de système ralentira un attaquant mais ne réduit finalement pas fortement les possibilités d’atteindre les réseaux de terrain qui existeraient sur d’autres cartes réseaux.
Pour le cas d’un automate « classique », il s’agit la plupart du temps d’un équipement fonctionnant sur un système d’exploitation propriétaire qui offre peu de fonctionnalités : à minima il permet de faire tourner des programmes industriels et de communiquer avec un ou plusieurs protocoles industriels, et peut optionnellement contenir des serveurs plus classiques type HTTP ou FTP. L’équipement propose donc beaucoup moins de fonctionnalité qu’un ordinateur ou serveur, et n’a pas vocation à permettre des passerelles entre ses différentes cartes réseaux… du moins, c’est ce qu’on a tendance à croire. Il a été cependant prouvé qu’il est possible de créer des passerelles entre les différents ports réseaux d’un automate : via des travaux de recherches comme ceux de Nicolas Delhaye and Flavian Dola présentés lors de la GreHack 2020 (la vidéo ici), mais surtout plus concrètement à travers le malware Pipedream découvert en 2022. Notamment, ce malware permet de créer des routes sur des automates Schneider afin de les transformer en proxy et leur donner la capaciter de router n’importe quel protocole vers les réseaux de terrain.
Illustration du fonctionnement du module Pipedream ciblant les équipements Schneider
Nous avons donc la preuve que même dans le cas d’une séparation par un automate, le modèle n’est pas infaillible, mais il permet tout de même de fortement réduire les risques en n’exposant les réseaux de terrain qu’à des attaques très avancées.
Cartographie et supervision
Suite au paragraphe précédent se pose naturellement la problématique suivante : comment superviser un réseau dont le point fort est d’être isolé ? Premièrement au sujet de la journalisation, le constat actuel est que les automates et équipements industriels sont encore très peu inclus dans les périmètres de supervision de sécurité : pour des raisons techniques, tous les équipements n’étant pas forcément en capacité de remonter des journaux type syslog, mais aussi organisationnel, les SOC manquant encore de maturité pour exploiter correctement les journaux d’évènements de ce genre d’équipement industriel.
Afin de combler ce manque de visibilité, les environnements industriels sont de plus en plus sujet à l’installation d’une sonde réseau, permettant de répondre aux besoins de supervision et de cartographie. Les systèmes qui rentrent dans le périmètre d’application de la Loi de Programmation Militaire sont notamment dans l’obligation d’installer une sonde de détection qualifiée par l’ANSSI. Sur le plan technique, il est possible de faire communiquer des réseaux isolés avec une sonde en utilisant des TAPs réseau, qui ont pour fonction de copier le trafic réseau de manière passive pour permettre l’écoute dudit trafic. Sur le plan stratégique, les réseaux de terrain sont rarement l’endroit à surveiller côté réseau. On privilégiera les points d’interconnexions avec les autres réseaux (entreprise, fournisseur…) ou les équipements critiques pour le pilotage comme le SCADA.
Exemple d’architecture de supervision intégrant les réseaux de terrain
La solution des TAPs n’est cependant pas applicable pour des sondes « actives » qui vont chercher à faire de la cartographie en questionnant les différents équipements sur le réseau. Mais ce type de solution est rarement mis en place dans un contexte industriel afin d’éviter de « stresser » le réseau et les équipements.
Le modèle des réseaux de terrain reste donc compatible en se concentrant sur la supervision du réseau, avec l’installation de sonde pour de la détection, ainsi que de la cartographie passive. La remontée de journaux systèmes des automates et équipements industriels reste encore trop peu pertinente vis-à-vis des capacités d’analyse des SOC.
Mise à jour
Pour pouvoir faire des mises à jour, il est nécessaire d’avoir une interconnexion réseau avec un système permettant la redescente de ces mises à jour, ce qui s’oppose à l’isolement des réseaux de terrain. Le besoin de mise à jour en milieu industriel rend-il le modèle de réseau de terrain obsolète ?
Le maintien en condition de sécurité est un sujet complexe dans le cas des systèmes industriels : besoin de disponibilité fort empêchant toute intervention lourde, systèmes isolés d’internet ne permettant pas le téléchargement des mises à jour par le réseau… Dans le cas de réseaux composés principalement d’automates, les mécanismes de mise à jour ont évolué en prenant en compte ces contraintes, si bien qu’aujourd’hui les parcs automates maintenus à jour sont rares (même sur une base annuelle), et ces mises à jour sont principalement déployées manuellement par la maintenance. L’utilisation de réseaux de terrain pour cloisonner l’architecture n’entrave pas l’application de ces mêmes mécanismes sur les automates.
En revanche, l’intégration des technologies IT change la donne : l’une des premières solutions de sécurité recommandée sur un parc Windows est la mise en place d’un serveur WSUS pour centraliser le déploiement des mises à jour, le même principe étant aussi applicable pour des technologies Linux. Nous arrivons donc ici à une nouvelle contrainte des réseaux de terrain possédant des équipements type Soft-PLC ou PC opérateur dédié : un cloisonnement par double carte réseau empêche la centralisation de la gestion des mises à jour, obligeant la mise en place d’un processus d’application manuelle des patchs qui peut être complexe et chronophage sur un nombre d’équipements important.
Cette contrainte doit tout de même être évaluée par rapport au besoin. L’argument principal en faveur des mises à jour est le fait qu’elles permettent de corriger des vulnérabilités augmentant la surface d’attaque d’un équipement. Le modèle des réseaux terrain isolant fortement les systèmes, leur surface d’attaque est par définition déjà fortement réduite. Il est donc acceptable que ceux-ci ne soient pas constamment à jour, et dans ce cas une mise à jour manuelle et annuelle des équipements répond au besoin.
Ce modèle ne convient cependant pas avec les besoins des antivirus d’être à jour constamment pour garantir une protection optimale. C’est pour cela qu’il est nécessaire dans ce cas de s’appuyer sur le fait d’avoir des systèmes bougeant très peu dans le temps, ce qui facilite l’utilisation dans le temps de solution de filtrage applicatif en liste blanche type AppLocker ou WDAC (voir notre article sur le filtrage applicatif).
Finalement, les pratiques de mises à jour en milieu industriel se sont adaptées au principe même d’isolation réseau permettant de réduire ces besoins. Ces pratiques demandent cependant le durcissement des équipements à leur installation, ainsi que la mise en place de solutions permettant de maintenir le niveau de sécurité des systèmes avec un minimum de maintenance à effectuer.
Accès distant
Après avoir abordé les flux « automatisés » des mises à jour, qu’en est-t-il des flux initiés par un utilisateur pour accéder à un équipement à distance pour des opérations métier ou de maintenance ? Pour des automates, ces accès sont rares : ils n’ont pas besoin d’actions humaines pour effectuer leurs tâches, et dans le cas de maintenance effectuée en interne, elle est souvent réalisée en accédant à l’automate depuis le réseau sur lequel il se trouve (les réseaux dédiés à l’administration pour les automates sont encore très rares). Dans le cas où l’automate est accessible depuis le réseau de production principal, la maintenance peut être centralisée depuis un point de connexion unique. Par contre, les réseaux de terrain étant isolés du réseau de production, les automates s’y trouvant sont accédés en allant brancher l’ordinateur portable de maintenance au “bon” commutateur interconnectant les différents équipements du sous-réseau, voire même directement sur le port USB de l’automate avec une liaison série.
Les limitations apparaissent par contre pour des réseaux de terrain avec des équipements maintenus par un fournisseur ou prestataire de maintenance. En effet, la maintenance à distance est devenue le moyen privilégié, et il est assez rare aujourd’hui d’avoir du personnel tier de maintenance à disposition pour se déplacer physiquement sur site à tout moment. La solution la plus souvent rencontrée pour faire face à cette problématique est l’installation d’une terminaison VPN directement sur un réseau de terrain, avec un tunnel relié au prestataire. Cela répond effectivement à la problématique, mais contourne aussi tout le principe d’isolement des réseaux de terrain, qui sont alors exposés en cas de compromission du prestataire.
On atteint ici la plus grande limite du modèle de réseau terrain, renforcée qui plus est avec la tendance à la centralisation des accès distant et l’installation de solution type bastion qui ne peuvent pas couvrir les accès aux réseaux de terrain du fait de leur isolement.
Conclusion
L’existence des réseaux de terrain est principalement historique, du fait des anciens modèles d’architecture en controller/worker et de la mise en place graduelle du modèle TCP/IP dans les réseaux industriels. Ces modèles d’architecture se sont adaptés au cycle de vie des systèmes : ils sont très peu accédés par des utilisateurs et sont conçus pour fonctionner en autonomie en remontant les données à l’automate controller.
Le cloisonnement est le principal point fort des réseaux de terrain : transformer un automate en rebond sur deux interfaces réseaux différentes est une technique d’attaque très avancée. Afin de détecter de possibles attaques, des solutions existent pour mettre en place de la supervision sur des réseaux isolés, notamment via des TAPs.
L’autre avantage de l’isolement réseau est de réduire les efforts à faire sur le maintien en condition de sécurité. Le besoin de mise à jour d’un équipement isolé n’est forcément pas le même que sur un équipement utilisé par un humain et interagissant avec des réseaux tiers. Les équipements isolés ayant un cycle de vie avec peu de changement, l’effort doit être mis sur le durcissement à la mise en service.
A l’inverse, l’isolation de ces réseaux posent de nombreuses problématiques sur les accès distants : il est possible de les limiter quand la gestion du parc industriel est en interne, mais ils sont essentiels dans le cas où un prestataire doit intervenir à distance. Afin d’éviter les initiatives locales ou les solutions à la main des tiers, il est recommandé de mettre en place une solution d’accès distant maîtrisée (VPN, bastion…), vers les équipements accédés à placer dans un sous-réseau dédié avec un point d’entrée filtré et maîtrisé.
En synthèse, le modèle de réseau terrain est encore aujourd’hui pertinent. Cependant, les tendances récentes, notamment liées à l’industrie 4.0, vont poser de nouvelles problématiques : L’apparition notamment des Industrial IOT, impliquant la mise en place de bus IoT interconnectés avec l’extérieur, remet en question la pertinence d’avoir des réseaux IP isolés cohabitant avec des bus IoT plus exposés.
Sources
Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/
GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE
