Table des Matières
- 1.Introduction : convergence OT et IA
- 2.Protocoles industriels (Modbus, OPC-UA, DNP3)
- 3.ML pour l'analyse de trafic OT
- 4.Détection d'anomalies (autoencoders, isolation forest)
- 5.Architecture air-gapped et déploiement
- 6.Solutions : Claroty, Nozomi, Dragos
- 7.Cas pratiques et retours d'expérience
- 8.Conclusion et recommandations
1 Introduction : convergence OT et IA
Les systèmes de contrôle industriel (ICS) et les environnements SCADA (Supervisory Control and Data Acquisition) gèrent les infrastructures les plus critiques de nos sociétés : centrales électriques, réseaux de distribution d'eau, raffineries pétrolières, usines de traitement chimique, réseaux de transport ferroviaire. Historiquement isolés du monde IT par des architectures air-gapped, ces systèmes sont de plus en plus connectés sous la pression de la transformation numérique industrielle (Industrie 4.0, Industrial IoT). Cette convergence IT/OT expose des protocoles de communication conçus dans les années 1970-1990 — sans aucune considération de sécurité — à des menaces cyber d'un niveau de sophistication sans précédent.
Le paysage des menaces OT s'est considérablement assombri en 2025-2026. Les attaques Stuxnet (2010), Industroyer (2016), TRITON/TRISIS (2017) et Industroyer2 (2022) ne sont plus des exceptions mais les jalons d'une tendance croissante. Le groupe Sandworm (GRU russe) a démontré sa capacité à provoquer des coupures de courant à l'échelle nationale en Ukraine via des malwares ciblant les protocoles IEC 104 et OPC-UA des postes de transformation électrique. Le framework PIPEDREAM/INCONTROLLER, découvert en 2022, ciblait spécifiquement les automates Schneider Electric et Omron via les protocoles Modbus et CODESYS. En 2026, le nombre de vulnérabilités CVE affectant les systèmes ICS a dépassé les 2500 entrées, avec une proportion croissante de vulnérabilités critiques permettant l'exécution de code à distance sur des contrôleurs Siemens, Rockwell et ABB.
Face à cette menace, les approches de sécurité traditionnelles (signatures de malwares, règles de pare-feu, listes blanches d'applications) montrent leurs limites dans les environnements OT. Les attaques avancées utilisent des commandes légitimes du protocole industriel pour provoquer des dysfonctionnements physiques — une commande Modbus Write Multiple Registers est syntaxiquement identique qu'elle soit envoyée par un ingénieur de maintenance ou par un attaquant. C'est dans ce contexte que l'intelligence artificielle et le machine learning apportent une capacité de détection révolutionnaire : la détection d'anomalies comportementales sur les protocoles industriels, capable d'identifier des déviations subtiles par rapport au comportement normal du processus physique contrôlé.
Enjeu critique : Les systèmes SCADA/ICS contrôlent des processus physiques. Une cyberattaque réussie ne se traduit pas seulement par une perte de données mais par des conséquences cinétiques : explosions, déversements chimiques, coupures de courant, déraillement de trains. La détection rapide des anomalies sur les protocoles industriels est littéralement une question de sécurité publique.
2 Protocoles industriels : Modbus, OPC-UA, DNP3
La compréhension des protocoles industriels est un prérequis indispensable pour concevoir des systèmes de détection d'anomalies efficaces. Chaque protocole possède sa propre structure, ses propres patterns de communication normaux, et ses propres vecteurs d'attaque spécifiques.
Modbus TCP/RTU : le protocole ubiquitaire
Modbus, créé par Modicon en 1979, reste le protocole le plus déployé dans les environnements industriels mondiaux. Dans sa variante TCP (port 502), il fonctionne en mode maître/esclave avec des function codes normalisés pour la lecture (FC 01-04) et l'écriture (FC 05, 06, 15, 16) de registres et coils. Le protocole ne dispose d'aucune authentification, aucun chiffrement, aucune vérification d'intégrité — tout client TCP capable de se connecter au port 502 peut lire et écrire n'importe quel registre de l'automate. Les attaques typiques sur Modbus incluent : l'écriture de valeurs aberrantes dans des registres de consigne (changer la température cible d'un réacteur), la modification de coils de sécurité (désactiver un arrêt d'urgence), et la lecture systématique de registres pour cartographier le processus physique. Pour la détection par IA, les features pertinentes incluent la fréquence des requêtes, la distribution des function codes, les plages de registres accédés, les valeurs écrites par rapport aux plages opérationnelles normales, et les patterns temporels de communication (un automate SCADA communique avec une régularité de métronome — toute variation est suspecte).
OPC-UA : le successeur sécurisé mais complexe
OPC-UA (Open Platform Communications Unified Architecture) est le successeur moderne d'OPC Classic, conçu dès l'origine avec des mécanismes de sécurité : authentification mutuelle par certificats X.509, chiffrement TLS, signatures numériques, et un modèle de sécurité granulaire par noeud. Malgré ces protections natives, OPC-UA reste vulnérable dans les déploiements réels pour plusieurs raisons : les modes de sécurité sont souvent désactivés par les intégrateurs pour simplifier le déploiement (mode "None" ou "SignAndEncrypt" avec des certificats auto-signés non vérifiés), le protocole est extrêmement complexe (plus de 14 000 pages de spécifications) ce qui crée une large surface d'attaque dans les implémentations, et les attaques via des noeuds OPC-UA légitimes (modification de valeurs de processus via des sessions authentifiées compromises) ne sont pas détectables par les mécanismes de sécurité du protocole. La détection d'anomalies par ML sur OPC-UA se concentre sur les patterns d'accès aux noeuds (quels noeuds sont lus/écrits, à quelle fréquence), les séquences de services (Browse, Read, Write, Subscribe) et les déviations par rapport au comportement applicatif normal.
DNP3 : le standard du secteur énergie
DNP3 (Distributed Network Protocol version 3) est le protocole dominant dans les réseaux électriques et les systèmes de distribution d'eau en Amérique du Nord et en Europe. Il supporte les communications maître/esclave et peer-to-peer, le polling cyclique et les rapports par exception (unsolicited responses), et une couche de transport segmentée pour les messages longs. DNP3 Secure Authentication (SA) a été ajouté comme extension de sécurité mais son déploiement reste marginal dans les installations existantes. Les attaques ciblant DNP3 exploitent notamment les unsolicited responses spoofées (injection de fausses mesures pour tromper l'opérateur SCADA), la manipulation des commandes de contrôle (CROB — Control Relay Output Block) pour déclencher ou inhiber des disjoncteurs, et le DoS par fragmentation. La détection par IA sur DNP3 bénéficie de la régularité extrême du trafic — les polling cycles sont configurés à la milliseconde près, et toute déviation du pattern temporel est un signal d'anomalie fort.
3 ML pour l'analyse de trafic OT
L'application du machine learning à l'analyse de trafic OT diffère fondamentalement de la détection d'intrusion IT traditionnelle. Les environnements industriels présentent des caractéristiques uniques qui sont à la fois un défi et une opportunité pour les algorithmes de ML.
Spécificités du trafic OT pour le ML
Les réseaux OT sont remarquablement déterministes et prévisibles par rapport aux réseaux IT. Un automate programmable (PLC) exécute le même programme cycliquement, communique avec les mêmes stations SCADA aux mêmes intervalles, et les valeurs des registres évoluent selon les lois physiques du processus contrôlé. Cette régularité est une aubaine pour le ML : le comportement normal est facilement modélisable, et toute déviation — même subtile — se distingue clairement du baseline. Les features pertinentes pour le ML en environnement OT incluent : la fréquence de communication (inter-packet timing avec une précision de la milliseconde), la topologie des flux (quel device communique avec quel device — toute nouvelle paire est suspecte), les function codes utilisés (un PLC qui ne reçoit normalement que des reads et qui reçoit soudainement des writes est une anomalie majeure), les valeurs des registres (déviations par rapport aux plages opérationnelles et aux gradients physiquement réalistes), et la taille des payloads (dans Modbus, la taille est directement liée au nombre de registres accédés).
Le défi principal est l'absence de datasets d'attaque représentatifs. Contrairement à l'IT où des millions d'échantillons de malwares sont disponibles, les attaques sur des protocoles industriels sont rares, souvent classifiées, et très spécifiques au processus physique ciblé. C'est pourquoi la détection supervisée (classification normal/attaque) est moins adaptée que la détection non supervisée (apprentissage du comportement normal, alerte sur les déviations). Les datasets publics disponibles — SWaT (Secure Water Treatment), BATADAL, HAI (Hardware-In-the-Loop) — sont des simulations de testbeds académiques qui ne capturent pas la complexité des environnements industriels réels. En pratique, les solutions les plus efficaces utilisent un apprentissage on-site : le modèle apprend le comportement normal pendant une phase de baseline (typiquement 2 à 4 semaines) directement sur le réseau OT du client, puis détecte les déviations en temps réel.
4 Détection d'anomalies : autoencoders et isolation forest
Deux familles d'algorithmes dominent la détection d'anomalies sur les protocoles industriels en 2026 : les autoencoders (réseaux de neurones) et les méthodes d'ensemble (isolation forest, one-class SVM). Chaque approche a ses forces et ses cas d'usage optimaux.
Autoencoders pour la détection d'anomalies OT
Les autoencoders sont particulièrement adaptés à la détection d'anomalies sur les protocoles industriels car ils apprennent à reconstruire le trafic normal. Un autoencoder est entraîné exclusivement sur du trafic légitime (baseline phase) et apprend une représentation compressée du comportement normal du réseau OT. Lorsqu'un trafic anormal est présenté au modèle, la reconstruction error augmente significativement — le modèle ne sait pas reconstruire un pattern qu'il n'a jamais vu. Les variantes les plus efficaces en 2026 sont les LSTM-Autoencoders qui capturent les dépendances temporelles (la séquence de commandes Modbus a une importance critique — une commande d'écriture suivie immédiatement d'une lecture de vérification est normale, mais une série de writes sans reads est suspecte), et les Variational Autoencoders (VAE) qui fournissent des scores de probabilité calibrés facilitant le réglage du seuil de détection. L'avantage principal des autoencoders est leur capacité à détecter des anomalies multimodales — des déviations subtiles impliquant simultanément plusieurs features (timing + function code + valeur de registre) qu'une analyse univariée manquerait.
Isolation Forest et méthodes d'ensemble
L'Isolation Forest est l'algorithme de choix pour les environnements OT à ressources computationnelles limitées. Son principe est élégant : les anomalies, étant rares et différentes, sont plus faciles à isoler que les points normaux dans un arbre de décision aléatoire. L'algorithme construit un ensemble d'arbres de décision et mesure la profondeur moyenne nécessaire pour isoler chaque observation — les anomalies nécessitent moins de coupures et ont donc un score d'anomalie plus élevé. Les avantages de l'Isolation Forest en environnement OT sont multiples : complexité computationnelle linéaire en O(n), absence de besoin de normalisation des features, robustesse aux features de haute dimension, et interprétabilité supérieure aux réseaux de neurones (on peut identifier quelles features contribuent le plus au score d'anomalie). En pratique, les déploiements les plus efficaces combinent Isolation Forest pour la détection rapide en temps réel (temps de prédiction sub-milliseconde compatible avec les contraintes des réseaux industriels) et autoencoders pour l'analyse approfondie hors-ligne des alertes générées, réduisant les faux positifs par une vérification en cascade.
5 Architecture air-gapped et déploiement
Le déploiement de solutions de détection d'anomalies par IA en environnement OT est soumis à des contraintes architecturales drastiques que l'on ne rencontre pas dans le monde IT. Le principe fondamental est que la solution de sécurité ne doit en aucun cas perturber le processus industriel — la disponibilité prime sur tout.
Monitoring passif et architecture de référence
Le déploiement en environnement OT repose sur le monitoring passif via des TAP réseau (Test Access Point) ou des ports SPAN/mirror sur les switchs industriels. Le capteur de la solution ML reçoit une copie du trafic réseau sans aucune interaction avec les flux de production. Cette architecture est non intrusive, invisible pour les automates et stations SCADA, et ne peut en aucun cas provoquer de perturbation du processus industriel. Le capteur ML opère typiquement dans la zone DMZ industrielle (niveau 3.5 du modèle Purdue), avec une diode de données unidirectionnelle pour les installations les plus sensibles (nucléaire, défense) garantissant physiquement l'impossibilité de toute communication depuis le réseau IT vers le réseau OT. Les modèles de ML sont entraînés on-premise, sans aucun envoi de données vers le cloud, et les mises à jour logicielles sont déployées via des supports amovibles vérifiés selon des procédures strictes.
Les contraintes matérielles sont également spécifiques. Les capteurs doivent fonctionner dans des environnements industriels (température étendue -40/+70C, vibrations, poussière, compatibilité électromagnétique) et supporter les débits des réseaux industriels sans perte de paquets. Les modèles de ML doivent s'exécuter sur du hardware embarqué (Intel Atom, ARM industriel) avec des contraintes de mémoire et de calcul significatives. C'est pourquoi les modèles légers (Isolation Forest, arbres de décision optimisés, réseaux de neurones compacts) sont privilégiés par rapport aux architectures deep learning lourdes. La latence de détection est un critère critique : pour être utile, une alerte doit être générée en quelques secondes, pas en quelques minutes — le temps de réaction d'un opérateur face à une anomalie sur un processus chimique se mesure en secondes.
6 Solutions : Claroty, Nozomi, Dragos
Le marché de la sécurité OT assistée par IA est dominé en 2026 par trois acteurs majeurs, chacun avec une approche et un positionnement distincts.
Claroty : visibilité et détection convergée IT/OT
Claroty (racheté par CrowdStrike fin 2025) propose une plateforme de visibilité et de détection couvrant l'ensemble de l'environnement industriel. Sa force réside dans le deep packet inspection (DPI) de plus de 450 protocoles industriels propriétaires (Siemens S7comm, Rockwell CIP/EtherNet/IP, ABB, Schneider, Yokogawa, Honeywell) en plus des protocoles standards (Modbus, OPC-UA, DNP3). Le moteur de détection d'anomalies de Claroty combine des modèles comportementaux (apprentissage du comportement normal de chaque asset et de chaque flux de communication) avec une base de signatures de vulnérabilités ICS constamment mise à jour. L'intégration avec CrowdStrike Falcon permet une corrélation des alertes OT avec la télémétrie IT pour une détection de menaces cross-domain.
Nozomi Networks : IA et threat intelligence OT
Nozomi Networks se distingue par l'avancement de son moteur d'IA et sa capacité de déploiement à grande échelle. La plateforme Guardian utilise des modèles de machine learning non supervisés entraînés directement sur le réseau client pour construire un baseline comportemental de chaque asset, flux de communication et variable de processus. Le service Threat Intelligence de Nozomi agrège des indicateurs de compromission (IoC) spécifiques aux environnements industriels, incluant des signatures de malwares ICS, des IP de C2 associés à des groupes APT ciblant les infrastructures critiques, et des règles de détection pour les tactiques et techniques MITRE ATT&CK for ICS. En 2026, Nozomi a introduit des capacités de détection d'anomalies au niveau du processus physique — en modélisant les relations physiques entre les variables de processus (pression, température, débit, niveau), la plateforme peut détecter des manipulations qui respectent les limites de chaque variable individuelle mais violent les lois physiques qui les lient.
Dragos : focus threat intelligence et réponse à incident
Dragos adopte une approche différenciée centrée sur la threat intelligence opérationnelle et la réponse à incident OT plutôt que sur la détection purement algorithmique. La plateforme Dragos Platform combine la détection comportementale avec les connaissances de l'équipe de threat intelligence de Dragos qui track plus de 20 groupes de menaces spécialisés dans les attaques ICS (ELECTRUM, KAMACITE, XENOTIME, CHERNOVITE). Les détections sont enrichies par le contexte opérationnel : plutôt que de simplement signaler une anomalie statistique, Dragos indique quel groupe de menace utilise cette technique, quel est l'impact potentiel sur le processus physique, et quelles actions de remédiation sont recommandées. Le service Neighborhood Keeper permet un partage anonymisé de télémétrie entre les clients Dragos, créant un réseau de détection collaborative qui améliore la capacité de détection de l'ensemble de la communauté.
7 Cas pratiques et retours d'expérience
Les déploiements réels de solutions de détection d'anomalies par IA en environnement OT fournissent des enseignements opérationnels précieux qui dépassent la théorie académique.
Cas 1 : Détection d'anomalie sur une station de pompage
Un opérateur de réseau d'eau en France a déployé une solution de détection d'anomalies basée sur un LSTM-Autoencoder sur les communications Modbus TCP entre les stations de pompage et le SCADA central. Après une phase de baseline de 3 semaines, le système a détecté une anomalie subtile : une station de pompage émettait des réponses Modbus avec un timing légèrement décalé (écart de 12ms par rapport au pattern normal) et des valeurs de pression qui, bien que dans les plages opérationnelles, présentaient un gradient physiquement improbable (augmentation de pression sans augmentation correspondante du débit). L'investigation a révélé qu'un PLC avait été reprogrammé par un prestataire de maintenance qui avait introduit un bug dans la logique de régulation — pas une attaque, mais un dysfonctionnement potentiellement dangereux que les systèmes de supervision classiques (seuils statiques) n'auraient pas détecté avant la survenue d'un incident hydraulique.
Cas 2 : Red team sur un réseau électrique
Lors d'un exercice de red team commandité par un GRT (Gestionnaire de Réseau de Transport) européen, l'équipe offensive a tenté de manipuler des commandes DNP3 pour déclencher l'ouverture simultanée de disjoncteurs dans un poste source. La solution de détection par Isolation Forest a généré une alerte en moins de 800 millisecondes en identifiant trois anomalies simultanées : un nouveau tuple source/destination dans le trafic DNP3 (l'attaquant opérait depuis un segment réseau compromis), une séquence de commandes CROB (Control Relay Output Block) sans polling préalable des points de données (violation du pattern opérationnel normal), et un timing inter-commande de 50ms (incompatible avec la latence de réponse humaine d'un opérateur légitime). Cet exercice a validé que la détection comportementale par ML complète efficacement les mécanismes d'authentification DNP3-SA déployés en parallèle.
- ▹Phase de baseline critique : 2-4 semaines minimum pour capturer tous les modes opérationnels (journalier, hebdomadaire, maintenance)
- ▹Faux positifs lors de maintenances : les opérations de maintenance génèrent un trafic atypique — un mécanisme de mode maintenance est indispensable
- ▹Détection de défauts : la détection d'anomalies identifie aussi des dysfonctionnements techniques, augmentant le ROI de la solution
- ▹Intégration SIEM : corrélation avec les alertes IT via Syslog/CEF pour une vision unifiée de la posture de sécurité
8 Conclusion et recommandations
La détection d'anomalies par IA sur les protocoles industriels est passée en 2026 du stade de la recherche académique à celui de la maturité opérationnelle. Les solutions basées sur des autoencoders et des forêts d'isolation, déployées passivement via des TAP réseau, démontrent une capacité réelle à détecter des attaques sophistiquées — y compris celles utilisant des commandes légitimes du protocole industriel — avec des taux de faux positifs acceptables après une phase de tuning initial.
Les trois enseignements majeurs des déploiements réels sont : premièrement, la régularité inhérente aux réseaux OT est un atout majeur pour le ML — le ratio signal/bruit est considérablement meilleur que dans le monde IT. Deuxièmement, la combinaison de modèles (Isolation Forest pour la détection temps réel, autoencoders pour l'analyse approfondie, signatures pour les menaces connues) offre la meilleure couverture. Troisièmement, l'intégration humaine reste indispensable — un opérateur SCADA expérimenté comprend le contexte opérationnel (maintenance planifiée, changement de production, conditions météorologiques) que le modèle ML ne peut pas capturer. L'avenir réside dans des systèmes de détection qui combinent l'analyse comportementale par IA avec la connaissance métier des opérateurs industriels.
Recommandations pour les RSSI OT :
- ✓Déployer en mode passif : TAP réseau + monitoring sans aucune interaction avec les flux de production
- ✓Baseline exhaustive : 4 semaines minimum couvrant tous les modes opérationnels avant activation des alertes
- ✓On-premise obligatoire : aucune donnée de trafic OT ne doit transiter vers le cloud
- ✓Mode maintenance : mécanisme de suppression temporaire des alertes pendant les opérations planifiées
- ✓Corrélation IT/OT : intégration avec le SIEM IT pour une détection cross-domain des menaces APT
Besoin d'un accompagnement expert ?
Nos consultants en cybersécurité OT et IA vous accompagnent dans la sécurisation de vos systèmes SCADA/ICS. Devis personnalisé sous 24h.