Lorsque les systèmes de contrôle industriel se connectent aux réseaux d’entreprise, la sécurité périmétrique traditionnelle s’effondre, explique Stefan Garczynski, architecte sécurité chez Sopra Steria, impliqué dans le programme de défense Blue Jay.
À 3h47 du matin, l’alarme de la salle de contrôle retentit. Un ventilateur essentiel de l’unité de distillation de la raffinerie ne répond plus. Les ingénieurs se précipitent pour diagnostiquer le problème, s’attendant à une défaillance mécanique. Mais la réalité est bien plus préoccupante. Ils découvrent que le ventilateur n’est pas tombé en panne, il a été arrêté à distance via un portail de maintenance fournisseur compromis. Le hacker, entré dans le réseau des semaines plus tôt grâce à des identifiants VPN volés, avait cartographié l’ensemble du système de contrôle industriel, attendant le moment optimal pour agir.
Pour l’exploitant de l’installation, l’arrêt de six heures a coûté des millions en perte de production. Pour l’équipe de sécurité, cela a révélé une vérité fondamentale. Leur périmètre de sécurité IT, conçu pour protéger les réseaux de bureau, avait laissé les systèmes industriels totalement exposés.
Ce scénario crédible illustre pourquoi la sécurité périmétrique traditionnelle échoue lorsque les technologies opérationnelles (OT) et les technologies de l’information (IT) convergent. Ces défis concernent l’ensemble des infrastructures critiques, de l’aérospatial et la fabrication d’armes aux transports et aux services publics.
Lorsque les appareils industriels ne peuvent pas exécuter de logiciels de protection
Le défi fondamental réside dans les limitations des équipements de technologie opérationnelle. « Beaucoup de ces automates programmables industriels qui pilotent les actionneurs industriels sont en réalité des ordinateurs très rudimentaires », explique Stefan Garczynski. « Ce sont des contrôles physiques. Il faut qu’un ingénieur intervienne sur place pour tourner une clé ou ouvrir une vanne. »
Ces systèmes hérités ne disposent pas des ressources informatiques nécessaires pour les outils de sécurité traditionnels. « Ils n’ont pas beaucoup de puissance ni de mémoire vive », précise-t-il. « Certains n’ont même pas d’espace logique : une lumière verte, une lumière rouge. Si plus de quatre transactions arrivent alors que quatre étaient attendues, le serveur s’arrête. »
Cette simplicité crée un paradoxe : des équipements conçus pour être fiables grâce à leur isolement doivent désormais être protégés dans des environnements connectés, sans pour autant pouvoir exécuter les logiciels de sécurité classiques.
Les protections endpoint, les outils de supervision réseau ou les systèmes d’authentification traditionnels ne peuvent tout simplement pas fonctionner sur ces équipements contraints.
De Colonial Pipeline à une réinvention du Zero Trust
L’attaque contre Colonial Pipeline illustre ces vulnérabilités. « Les hackers sont entrés via un compte VPN sans authentification multifactorielle », rappelle Stefan Garczynski. « L’absence de segmentation a contraint à un arrêt complet dans l’environnement OT. »
Les systèmes de gestion des bâtiments présentent des risques similaires. « Les fabricants installent des équipements qui détectent les réseaux Wi-Fi », explique-t-il. « Résultat, des systèmes de chaudières et de chauffage connectés en Wi-Fi, parfois exposés à des réseaux internet publics. L’accès distant des fournisseurs, protégé uniquement par des identifiants VPN statiques, permet aux attaquants de se téléporter dans les réseaux où les fonctions d’ingénierie utilisent des identifiants administrateur génériques », précise-t-il.
Plutôt qu’une transposition directe des technologies, le Zero Trust en OT se concentre sur les points d’intégration réseau. « L’approche Zero Trust vise à contrôler la manière dont le réseau OT s’intègre avec l’IT, en mettant en place un modèle de confiance qui sépare clairement les composants et les environnements », indique Stefan Garczynski.
Il s’appuie sur deux cadres de référence : IEC 62443 (ISA 99) et l’ingénierie informée par la cybersécurité. « C’est comparable à une approche secure by design », affirme-t-il. « De la conception à l’exploitation, vous gérez ce processus de sécurité. Lorsque vous échangez avec les fournisseurs, vous devez comprendre leurs processus, leur architecture et leur politique Zero Trust. »
Cette approche sur l’ensemble du cycle de vie permet aux ingénieurs de comprendre les exigences de sécurité, tandis que les équipes IT saisissent les contraintes opérationnelles. Le résultat : des contrôles de sécurité qui fonctionnent en pratique, et pas seulement en théorie. « Les ingénieurs sont formés à ce que vous apportez, comprennent les complexités liées à la sûreté dans l’environnement OT, et l’IT comprend cela également », explique-t-il.
Construire la sécurité couche par couche : segmentation, identité et vérification continue
La segmentation reste fondamentale. « De nombreux réseaux sont plats, parfois limités à un seul VLAN », explique Stefan Garczynski. « Il faut séparer le contrôle des mouvements et le contrôle des processus afin qu’ils ne communiquent pas entre eux. La ségrégation contribue à renforcer la sécurité. »
L’approche s’inspire du modèle Purdue, qui distingue les couches de processus, d’ingénierie et de management, avec des conduits contrôlés entre elles, à l’image de la segmentation d’applications web entre couches management, application et base de données.
La gestion des identités se révèle tout aussi cruciale. « Il faut commencer par définir ce que chaque personne doit faire et le niveau d’accès nécessaire. Supprimer les comptes par défaut et créer des identités uniques, tant sur le plan technologique que physique, incluant grilles, serrures, portes. »
La séparation des domaines ajoute une couche supplémentaire, explique-t-il. « Utiliser le domaine IT pour gérer des systèmes SCADA est problématique. Il est préférable de créer un domaine distinct. C’est plus complexe à gérer, mais c’est une couche de sécurité valide. »
La vérification continue impose un équilibre entre sécurité et opérations. « Comprendre les implications en matière de sûreté et les exigences IT », poursuit Stefan Garczynski. « Il peut s’agir de maintenance prédictive, par exemple l’IT doit savoir qu’un ventilateur n’a plus que 16 000 tours avant maintenance et que cette pièce met six mois à être remplacée depuis la Pologne. Comment extraire cette information sans compromettre le système ? »
Les pièges : quand la complexité devient l’ennemi de la sécurité
Le principal écueil est l’excès de complexité, estime Stefan Garczynski. « Mettre en place des processus trop contraignants. Trouver la ligne fine : quelles sont les exigences, qui a besoin d’accès, pourquoi, et à quel niveau ? »
Une autre erreur consiste à négliger la dimension humaine. « Les ingénieurs ne travaillent pas naturellement avec l’IT. Leur rôle est de réparer des machines », souligne-t-il. « Si un ingénieur en raffinerie entend que l’IT veut brancher des équipements et tout surveiller, il dira non.” Il faut trouver un équilibre pour que la sécurité fonctionne sans perturber le processus industriel initial de l’IT et des ingénieurs. »
Quatre priorités pour réussir la transition vers le Zero Trust dans les infrastructures critiques
Selon Stefan Garczynski, quatre priorités sont essentielles pour une transition Zero Trust réussie. Premièrement, établir la visibilité grâce à une gouvernance conjointe entre fournisseurs, équipes IT et équipes OT. « Examiner les flux de données, les exigences d’ingénierie, la réduction des temps d’arrêt et la sûreté », explique-t-il.
Deuxièmement, mettre en œuvre une segmentation pragmatique. « Cela ne se fera pas du jour au lendemain. Commencez par les actifs critiques. Ils ont besoin d’une couche de gestion, mais celle-ci ne peut pas communiquer directement avec l’IT ; elle doit passer par des canaux, une zone démilitarisée », précise-t-il.
Troisièmement, se concentrer sur le contrôle de l’identité et des accès, en éliminants les identifiants par défaut et en appliquant le principe du moindre privilège.
Enfin, intégrer les fournisseurs dès le départ. « Le Zero Trust ne fonctionne en OT que si les fournisseurs font partie de ce modèle », conclut Stefan Garczynski. « La Cyber Informed Engineering impose leur implication dès le début. »