3.3 Détection : IDS OT, SOC, SIEM, monitoring passif

En IT, on peut scanner activement le réseau (Nmap, vulnerability scanner) sans risque majeur. En OT, c'est strictement interdit par défaut : un scan actif peut faire planter un vieil automate ou perturber un cycle critique. La seule méthode acceptable est le monitoring passif.

Mécanisme du monitoring passif :

• Les switches industriels sont configurés avec port mirroring (SPAN, Switched Port Analyzer) — une copie de tout le trafic est envoyée sur un port dédié.
• Pour les liens les plus critiques, on installe un TAP physique : un boîtier passif qui duplique le signal optique ou cuivre sans intervenir sur le flux principal — contrairement au port mirroring, il ne consomme pas de ressources sur le commutateur et ne se désactive pas par une erreur de configuration.
• Le port mirroring / TAP alimente une sonde IDS OT.
• La sonde n'émet jamais de trafic sur le réseau OT — elle ne fait qu'écouter.

Ce qu'apprend la sonde par écoute passive :

• Tous les équipements présents (inventaire automatique).
• Toutes les communications qui ont lieu (qui parle à qui, quand, comment).
• Les protocoles utilisés et les commandes envoyées.
• La baseline comportementale normale du réseau (cycle horaire, jours ouvrés, etc.).
• Les anomalies : nouvelle adresse IP, nouveau protocole, commande inhabituelle, communication transverse non prévue.

Bénéfices :

• Zéro risque pour la production (aucun paquet émis sur le réseau OT).
• Détection des malwares OT spécifiques (Stuxnet, Triton, Industroyer signatures connues).
• Détection des comportements anormaux (anomalies de protocole, communications inattendues).
• Inventaire toujours à jour sans effort manuel.
• Alimente le SIEM et le SOC.

Le marché des sondes de détection industrielle (IDS OT) s'est consolidé depuis 2017-2018 : il compte une poignée d'éditeurs spécialisés, quelques offres intégrées à des plateformes de sécurité généralistes, et des rachats fréquents — un nom cité aujourd'hui peut appartenir à un autre groupe l'an prochain. Le choix ne se fait donc pas sur une liste de marques, mais sur des critères vérifiables en maquette.

Fonctionnalités attendues d'une sonde de détection OT :

• Découverte passive des actifs et cartographie automatique.
• Inspection de protocoles industriels (Modbus, S7, Profinet, EtherNet/IP, DNP3, IEC 60870-5-104, IEC 61850, BACnet, OPC UA, etc.).
• Baseline comportementale avec apprentissage automatique.
• Signatures de menaces OT connues (Stuxnet, Industroyer, Triton, Pipedream / Incontroller — 2022).
• Gestion des vulnérabilités : corrélation avec les bases CVE et les avis des constructeurs présents dans le parc.
• Dashboard et alertes configurables.
• Intégration SIEM (Syslog, CEF, API REST).
• Threat intelligence intégré (souvent payant en option).

Comment trancher : la seule question qui décide vraiment est la couverture réelle des protocoles de votre parc — une sonde qui ne sait pas lire le protocole de vos automates ne verra rien d'autre que des flux inconnus. Cela se vérifie par une maquette de quelques semaines sur un site pilote, avec vos propres équipements, jamais sur une fiche produit. Prévoir ensuite un temps de calibrage significatif : une sonde fraîchement installée génère beaucoup de bruit tant qu'elle n'a pas appris le fonctionnement normal de l'atelier, et une équipe noyée sous les fausses alertes finit par ne plus les lire.

Le budget varie de quelques dizaines de milliers d'euros pour un site unique à plusieurs centaines de milliers pour un groupe multisite. À budget contraint, l'ordre de priorité est constant : inventaire et segmentation d'abord, détection ensuite — détecter dans un réseau plat ne sert qu'à observer la propagation.

Le SIEM (Security Information & Event Management) centralise les journaux de sécurité de toute l'entreprise. Pour un programme NIS2 OT, le SIEM doit ingérer non seulement les sources IT (firewall, EDR, AD, applications), mais aussi les sources OT (IDS OT, firewalls industriels, logs SCADA, événements PLC quand disponibles).

L'offre est large : plateformes commerciales, solutions libres déployables à moindre coût dans une PME, services managés. Le choix relève de la stratégie SI d'ensemble, pas de l'OT. Ce qui est spécifique à l'OT, en revanche, est la capacité à ingérer les sources industrielles (sonde de détection, pare-feu industriels, journaux des postes de supervision, événements d'automates quand ils sont exposés) et à les corréler avec les sources bureautiques.

Cas d'usage de corrélation IT + OT — c'est là que se joue la valeur :

• Phishing IT → tentative d'accès OT : un utilisateur clique sur un lien malveillant, son poste est compromis, et 30 minutes plus tard une nouvelle session admin apparaît sur le jump server OT. Alerte critique.
• Mouvement latéral inhabituel : un compte IT légitime se connecte soudainement à un automate. Sans corrélation, c'est invisible. Avec corrélation IT+OT, c'est immédiat.
• Exfiltration de données via Historian : volume anormal de données copié depuis l'Historian. Corrélation avec activité utilisateur sur le réseau IT.
• Modification de programme automate hors fenêtre d'arrêt planifiée : alerte critique du SIEM, escalade automatique vers le SOC.

Règles de détection : il existe des bases de règles ouvertes et réutilisables (format Sigma notamment), ainsi que des jeux fournis par les éditeurs. Le cadre de référence pour structurer cette couverture est MITRE ATT&CK for ICS, qui cartographie les tactiques et techniques d'attaque propres aux environnements industriels : il permet de dire précisément ce que l'on sait détecter et ce que l'on ne sait pas — un exercice bien plus utile qu'un décompte d'alertes.

Un SOC (Security Operations Center) capable de gérer l'OT n'est pas simplement un SOC IT auquel on ajoute des sondes OT. C'est une équipe avec des compétences mixtes, des procédures spécifiques et des connexions privilégiées avec la production.

Modèles d'opération SOC OT :

• SOC interne dédié OT : équipe internalisée, ~ 5-15 personnes selon la taille. Coût élevé, expertise contrôlée. Plutôt pour les grands groupes.
• SOC interne mixte IT+OT : équipe SOC IT existante formée et étendue à l'OT. Modèle le plus courant pour les ETI.
• Service managé (MSSP) disposant d'une compétence OT : externalisation de la surveillance. Modèle adapté aux PME et ETI sans équipe interne — à condition de vérifier que la compétence OT est réelle et pas un simple argument commercial : demander qui, chez le prestataire, saura dire si une commande d'écriture sur un automate est normale à 3 h du matin.
• SOC hybride : interne 8h-19h + MSSP en heures non ouvrées.

Compétences clés d'un analyste SOC OT :

• Cyber classique (analyse de logs, threat hunting, gestion d'incidents, ATT&CK).
• Connaissance des protocoles industriels et de leur usage normal.
• Compréhension du contexte production : ce qu'on peut/ne peut pas faire en intervention.
• Connaissance de l'architecture Purdue et IEC 62443.
• Notions de sûreté de fonctionnement et de safety industrielle.
• Capacité à collaborer avec les ingénieurs procédés, automaticiens, responsables maintenance.

Playbooks de réponse : un SOC OT mature dispose de playbooks documentés (procédures écrites step-by-step) pour les scénarios fréquents :

• Détection de malware sur HMI / SCADA.
• Détection de scan réseau OT.
• Connexion d'un nouvel appareil au réseau OT.
• Modification non planifiée de programme automate.
• Échec d'authentification répété sur jump server.
• Anomalie de communication entre automates.
• Compromission supposée d'un compte fournisseur.

Frameworks de référence : MITRE ATT&CK for ICS pour cartographier les techniques d'attaque OT et structurer la détection ; NIST SP 800-61 pour la gestion d'incident ; ISO 27035 pour la gouvernance.

Ces profils mixtes sont rares et recherchés : voir la fiche ingénieur cybersécurité industrielle et son niveau de rémunération.