Détection OT : identifier les menaces et les anomalies sur le réseau industriel
Cartographier et isoler, c’est très bien mais ce n’est toujours pas suffisant. Une fois la cartographie initiale réalisée et les actifs vitaux protégés, il reste deux questions ouvertes : comment évolue le réseau dans le temps ? Et comment détecter les attaques, notamment sur les zones non isolées ? Nouveaux équipements, flux inhabituels, comportements anormaux, nouvelles vulnérabilités exploitables : sans surveillance continue, ces signaux restent invisibles. C’est l’objet de cet article, le dernier de notre série sur la mise en pratique de la sécurisation OT : comment détecter les écarts et les menaces sur un réseau industriel, et comment Seclab Xplore y répond.
À retenir
- La contextualisation des alertes est la clé de l’efficacité opérationnelle : une adresse IP sans contexte métier n’a aucune signification pour un analyste SOC qui ne connaît pas l’usine.
- Les environnements industriels ont une caractéristique précieuse pour la détection : leur volonté de stabilité. Tout écart par rapport au comportement habituel devient un signal d’alerte.
- Les alertes doivent pouvoir être routées vers les bonnes personnes selon leur nature : équipes IT, SOC, équipes OT, responsable de production, mainteneur externe.
- L’enregistrement continu des flux en PCAP constitue une base de preuves immédiatement disponible pour la réponse à incident et la levée de doute.
Rappel : la démarche de sécurisation OT en cinq étapes
Face à la montée des menaces sur les environnements OT, les réglementations et les retours terrain convergent vers la même séquence :
- inventorier les actifs et les flux,
- réduire la surface d’attaque en supprimant ce qui est inutile,
- identifier les systèmes vitaux et les isoler physiquement,
- mettre l’infrastructure sous surveillance continue,
- sécuriser les sauvegardes avec une isolation physique.
Les articles précédents de cette série étaient consacrés à la cartographie avec Seclab Xplore et à l’isolation physique avec Seclab Xchange, Seclab Xport et Seclab Xlocker. On aborde ici la quatrième étape : la surveillance et la détection.
Pourquoi la détection OT est un exercice à part entière
Détecter une menace sur un réseau IT est déjà complexe. Sur un réseau OT, c’est un exercice différent. Les protocoles industriels sont spécifiques, souvent propriétaires, parfois temps réel. Et les équipes qui reçoivent les alertes ne sont pas toujours des spécialistes cybersécurité : ce sont des opérateurs, des techniciens process, des responsables de production.
Premier enjeu : surveiller sans perturber. En environnement industriel, toute sonde active peut interférer avec des protocoles temps réel sensibles ou perturber des machines un peu trop chatouilleuses. La détection doit être au maximum passive, capable d’observer l’ensemble des flux sans jamais les toucher ni les ralentir.
Deuxième enjeu : distinguer les signaux pertinents du bruit. Un réseau industriel génère en permanence des flux de communication entre automates, systèmes de supervision, postes de travail. Identifier ce qui est anormal dans cette masse nécessite une connaissance fine de ce qui est normal, c’est-à-dire une baseline précise, segmentée par périmètre métier et non globale.
Le défi de la contextualisation
Une alerte remontée au SOC doit être contextualisée. Une simple adresse IP ou un élément technique isolé n’a aucune signification pour un analyste SOC qui ne connaît pas les spécificités de l’usine. Sans contexte métier, l’analyste ne sait pas :– À quelle zone de production appartient l’équipement concerné
– Quel est son niveau de criticité pour le process
– Qui contacter dans l’usine pour engager la levée de doute
La contextualisation des alertes est donc la clé de l’efficacité opérationnelle. Sans elle, le temps de réponse s’allonge, et l’incident se propage.
Troisième enjeu : adresser les bonnes alertes aux bonnes personnes. Une alerte cyber ne s’adresse pas au même destinataire qu’une alerte opérationnelle. Un comportement réseau anormal sur un automate de sécurité ne concerne pas les mêmes équipes qu’une vulnérabilité CVE détectée sur un poste de supervision. Sans routage précis, les alertes se noient dans des flux d’information non différenciés.
Comment Seclab Xplore adresse ces enjeux : quatre moteurs de détection
Seclab Xplore embarque plusieurs moteurs de règles distincts, chacun couvrant un type de détection différent. Ils fonctionnent en parallèle et s’alimentent mutuellement de la connaissance cartographique construite lors de la phase de découverte.
Moteur 1 : surveillance cartographique (détection comportementale)
Le premier moteur surveille la stabilité de l’environnement cartographique : les liens entre machines, les équipements présents sur le réseau, les flux de communication. Il peut être qualifié de firewall passif : il ne coupe aucun flux, mais il surveille en continu, y compris dans des zones où l’on ne déploierait jamais de firewall, par exemple là où des protocoles temps réel circulent entre automates dans des zones non segmentées.
Les règles sont créées directement depuis l’outil de cartographie. On définit des périmètres considérés comme des baselines, non pas une baseline globale pour toute l’application, mais des sous-ensembles indépendants correspondant à des zones fonctionnelles. La solution surveille ensuite les écarts : apparition de nouveaux équipements, adresses IPv6 inattendues, connexions établies vers des zones Internet. C’est de la détection orientée stabilité, à distinguer de la détection par signature.
Moteur 2 : détection par signature (Sigma et Suricata)
Le deuxième moteur s’appuie sur des règles au format Sigma, un format reconnu dans le monde du système, étendu par Seclab à la partie réseau. Le choix du format Sigma est délibéré : il est lisible, documentable et compréhensible, y compris par des équipes OT non spécialistes de la cybersécurité. Les règles peuvent être décrites, annotées, et leur logique reste accessible sans formation approfondie.
Xplore supporte également le format Suricata via un moteur dédié fonctionnant en parallèle. Les alertes Suricata sont enrichies de la connaissance cartographique avant d’être transmises au SOC : la contextualisation métier est systématiquement ajoutée, pour que l’analyste sache immédiatement à quelle zone et à quel équipement l’alerte se rapporte.
Moteur 3 : AI/machine learning
Le troisième moteur exploite une caractéristique propre aux environnements industriels : leur volonté de stabilité. Les process industriels sont conçus pour se répéter. Les flux de communication entre automates suivent des patterns prévisibles. C’est précisément cette stabilité qui permet d’entraîner un modèle de machine learning sur les comportements habituels et d’identifier tout écart comme un signal d’alerte. Le moteur ne s’applique pas à tous les protocoles, mais sur les périmètres où il est pertinent, il offre une détection d’anomalies qui ne nécessite pas l’écriture de règles explicites.
Moteur 4 : alerting sur les vulnérabilités CVE
Le quatrième moteur croise en continu l’inventaire des actifs avec les bases de vulnérabilités connues. Dès qu’une nouvelle CVE affecte un équipement présent sur le réseau, une alerte est générée. Ces alertes peuvent être routées vers différents destinataires selon leur nature : équipes IT, SOC, équipes OT, responsable de production, mainteneur externe. La précision du routage évite la dilution de l’information dans des flux de notifications non différenciés.
Couverture MITRE ATT&CK et gestion des règles
Toutes les règles, quel que soit leur moteur d’origine, sont rattachées à des tags MITRE ATT&CK. Cela permet d’obtenir une vue synthétique de la couverture de détection en regard de la matrice MITRE, et d’identifier les angles morts éventuels.
L’objectif n’est pas de multiplier les règles pour maximiser un score de couverture. L’approche recommandée est de partir des événements redoutés propres à chaque environnement, de cibler les règles pertinentes sur les bons périmètres, et de maintenir un nombre de règles raisonnable, maîtrisable et suivi dans le temps. Un grand nombre de règles mal suivies est moins efficace qu’un périmètre ciblé, bien documenté et tenu à jour.
Bac d’alertes, réponse à incident et intégration à l’écosystème
La solution embarque son propre bac d’alertes, qui peut fonctionner de manière autonome pour un site isolé, ou être configuré pour forwarder les alertes vers un SIEM externe qui en assure la gestion centralisée. La lecture d’une alerte repose sur deux informations essentielles : les zones impactées, et le nom de l’équipement concerné ainsi que le groupe métier auquel il appartient. Si une alerte concerne un équipement du pôle Énergie, l’analyste sait immédiatement qui contacter dans l’usine pour la levée de doute, sans recherche manuelle préalable.
Pour la réponse à incident, chaque sonde peut être configurée pour enregistrer les flux en continu. Il est ainsi possible de télécharger le PCAP correspondant à n’importe quel événement, avec des réglages fins sur la profondeur temporelle et la profondeur OSI souhaitées. Cet enregistrement continu constitue une base de preuves disponible immédiatement, aussi bien pour les incidents cyber que pour les incidents opérationnels.
Une vue synthétique d’hypervision couvre en temps réel le bac d’alertes et le bac de vulnérabilités, pour une vision consolidée de l’exposition à l’instant T. Toutes ces données sont partageables avec l’ensemble de l’écosystème existant : SIEM, dashboards centralisés, vues consolidées IT/OT. Seclab Xplore se positionne ainsi comme un puit d’informations capable d’alimenter les outils tiers et de s’intégrer pleinement dans les processus de sécurité en place.
Pour découvrir Seclab Xplore, visionnez cet extrait du replay de notre webinar de Juin 2026
Et maintenant ?
Cartographie, isolation, détection : les trois capacités de la plateforme Seclab Xcore forment une architecture de défense en profondeur pensée pour les contraintes réelles des environnements industriels. Chaque brique renforce les autres : la cartographie alimente la détection, la détection contextualise les alertes, l’isolation réduit la surface sur laquelle la détection doit opérer.
La menace sur les environnements OT est réelle, documentée, et en croissance. Les organisations qui ont commencé à structurer leur démarche de sécurisation ont une longueur d’avance. Celles qui n’ont pas encore lancé l’inventaire de leur réseau industriel ont un point de départ évident.
