Comment détecter et prévenir les attaques OT courantes sur un réseau industriel ethernet

Sur un réseau industriel Ethernet, la frontière entre l'informatique traditionnelle et les environnements opérationnels (OT) est de plus en plus poreuse. J'ai vu trop de fois des usines exposées par des pratiques de réseau héritées du bureau, ou par des dispositifs connectés sans réflexion sur la sécurité. Dans cet article, je partage des approches concrètes pour détecter et prévenir les attaques OT les plus courantes, basées sur des retours de terrain, des outils que j'ai déployés et des bonnes pratiques que j'applique systématiquement.

Pourquoi la sécurité OT est différente

Les systèmes OT ont des contraintes spécifiques : disponibilité critique, long cycle de vie des équipements, protocoles propriétaires (Modbus, Profinet, EtherNet/IP, OPC UA) et souvent peu de capacité de mise à jour. Ces caractéristiques modifient la manière dont on doit détecter et contrer une attaque. Contrairement à l'IT, où l’on peut souvent patcher et redémarrer, en OT on privilégie des mesures non intrusives, une supervision passive et une segmentation stricte.

Les attaques OT courantes — ce que j'observe sur le terrain

• Scans de réseau et reconnaissance : utilisation de nmap, masscan, ou scripts spécifiques pour cartographier les PLC et HMI.
• Attaques par injection de commandes : exploitation de commandes non sécurisées via Modbus TCP, EtherNet/IP ou API exposées.
• Man-in-the-Middle (MiTM) : ARP spoofing, session hijacking sur réseaux plats.
• Ransomware ciblé : déploiement via stations de travail non segmentées ou serveurs non protégés.
• Attaques des équipements externes : périphériques IoT ou passerelles mal configurées servant de point d'entrée.

Détection : mêler surveillance réseau et supervision OT

La détection efficace repose sur deux piliers complémentaires : la visibilité réseau et l'analyse comportementale des équipements OT.

Visibilité réseau

• Déployer des sondes passives (SPAN/mirroring) pour capturer le trafic sans impacter les équipements sensibles. J'utilise souvent des appliances NetFlow/IPFIX + DPI adaptées OT (ex : Claroty, Nozomi, ou des outils open source complétés par Bro/Zeek).
• Activer la télémétrie des commutateurs et routeurs (sFlow/NetFlow) pour repérer des flux anormaux entre segments.
• Maintenir un inventaire actif des actifs via scans passifs : connaître les adresses MAC, firmwares, modèles de PLC et HMI facilite la détection d'éléments inconnus.

Analyse comportementale

• Construire des profils normaux d'échange (communication whitelisting) par équipement et application. Par exemple, un PLC A ne devrait communiquer qu'avec le SCADA B et le réseau de terrain C.
• Surveiller les commandes de contrôle : une requête Modbus "write" hors des plages horaires ou en dehors d'une application légitime doit alerter.
• Détecter les anomalies de latence, de répétition de requêtes, ou d'ARP cache changes : ces signaux sont souvent les premiers indicateurs d'un MiTM ou d'un scan actif.

Prévention : architecturer le réseau et durcir les endpoints

La prévention passe par des principes simples mais parfois mal appliqués.

• Segmentation stricte : isolez les zones IT, OT, DMZ et accès tiers. J'applique la micro-segmentation pour les systèmes critiques (VLANs + ACL + pare-feu industriel) et je m'assure que seuls les ports/protocoles nécessaires sont autorisés.
• Whitelisting applicatif : limiter les commandes autorisées vers les automates. Beaucoup d'incidents proviennent d'une surface d'attaque trop grande.
• Contrôle des accès : utiliser l'authentification forte (2FA) sur les consoles d'ingénierie, et limiter les droits administratifs aux seules personnes nécessaires.
• Patch management raisonné : établir un plan de mise à jour tenant compte des tests en lab, des fenêtres d'arrêt et de la compatibilité OT. Les correctifs sont essentiels, mais leur déploiement doit être maîtrisé.
• Durcissement des équipements : désactiver services inutiles, changer mots de passe par défaut, appliquer chiffrement lorsque possible (OPC UA avec TLS, SSH plutôt que Telnet).

Outils et méthodes que j'utilise

Sur un site, j'associe souvent plusieurs outils pour une couverture complète :

• Solutions dédiées OT : Nozomi, Claroty, Dragos — pour inventaire, détection d'anomalies et corrélation d'événements spécifiques aux protocoles industriels.
• SIEM/Analyse : centraliser logs et alarms (Splunk, Elastic) pour corrélation entre événements IT et OT.
• Inspection passive : Zeek (ancien Bro) pour extraire métadonnées, Suricata pour signatures réseau, complétés par des parsers Modbus/Profinet.
• Gestion des accès : jump servers bastionisés, PAM (CyberArk, BeyondTrust) pour sessions d'ingénierie.

Cas pratiques : détection et réponse à une attaque MiTM

Lors d'un audit, j'ai observé des ARP broadcasts suspects et des doubles adresses MAC via les sondes. La détection a suivi une logique simple :

• Alertes NetFlow montrant un hachage de trafic inhabituel entre un PC d'ingénierie et plusieurs PLC.
• Analyse DPI révélant des réponses Modbus incohérentes (valeurs modifiées sans commande légitime).
• Vérification physique : découverte d'une machine portable connectée en mode bridge, exécutant un outil de spoofing.

Actions prises :

• Isolation immédiate du segment via ACL sur les commutateurs managés.
• Collecte forensique du trafic sur la période suspecte et sauvegarde des images des équipements.
• Rotation des accès, réinitialisation des comptes impliqués et revue des droits.
• Renforcement des règles de segmentation et déploiement d'une sonde passive dédiée sur ce segment.

Indicateurs de compromission OT à surveiller

Culture et organisation : l'humain au cœur de la prévention

La technologie ne suffit pas : j'insiste toujours pour que les équipes opérationnelles et informatiques travaillent ensemble. Quelques mesures pragmatiques :

• Former les opérateurs aux signes d'anomalie (valeurs incohérentes, écrans HMI inhabituels).
• Répéter des exercices de réponse à incident incluant coupures réseau simulées et scénarios de ransomwares.
• Mettre en place des procédures de changement strictes pour toute intervention sur PLC/HMI.

Sur le terrain, la combinaison d'une visibilité renforcée, d'une segmentation pensée, d'outils spécialisés et d'une gouvernance partagée réduit fortement le risque d'attaque et permet de détecter précocement les comportements malveillants. Si vous souhaitez, je peux partager une checklist opérationnelle adaptée à votre architecture ou vous proposer un modèle de playbook incident OT que j'utilise lors de mes audits.