IA et SCADA/ICS : Détection d'Anomalies sur les Protocoles

La détection d'anomalies SCADA ICS par l'IA s'impose aujourd'hui comme une nécessité opérationnelle, pas comme un luxe technologique. En 2024, le rapport Dragos a recensé 21 groupes APT actifs sur les réseaux industriels, dont VOLTZITE et KAMACITE, spécialisés dans les infrastructures critiques européennes. Pendant ce temps, les équipes OT continuent de surveiller des milliers de trames Modbus, DNP3 ou IEC 60870-5-104 avec des outils conçus pour les réseaux IT des années 2000. Ce décalage est fatal. Les protocoles OT ne parlent pas le même langage que les pare-feux ou les SIEM traditionnels : pas d'authentification, pas de chiffrement natif, des cycles de communication rigides et prévisibles. C'est précisément cette prévisibilité que le machine learning peut exploiter. En modélisant le comportement normal d'un automate Siemens S7 ou d'une RTU Schneider sur réseau DNP3, un modèle d'Isolation Forest détecte en quelques millisecondes une séquence de commandes qui n'aurait jamais dû apparaître. Déployer ces modèles en environnement industriel sans casser la production — voilà le vrai challenge que cet article adresse.

Les protocoles OT : un écosystème fragmenté et résolument hostile à la sécurité

Modbus date de 1979. DNP3 de 1993. IEC 60870-5-104 a été conçu pour des liaisons téléphoniques commutées. Ces protocoles ont été standardisés à une époque où le mot "cybersécurité" n'existait pas dans le lexique industriel — et ça se voit à chaque couche du modèle de communication.

Modbus TCP/RTU est l'exemple parfait de cette insécurité structurelle. Pas d'authentification, pas de contrôle d'intégrité, adressage en clair sur 8 bits. N'importe quel équipement sur le réseau peut envoyer une commande "Write Multiple Registers" (fonction 16) à un automate et modifier ses paramètres de fonctionnement. En environnement isolé, ce n'était pas un problème. Depuis que les réseaux OT se connectent aux SI d'entreprise — et à Internet via les passerelles cloud de monitoring — c'est une catastrophe annoncée.

DNP3 (Distributed Network Protocol) est plus sophistiqué : il supporte l'authentification via DNP3-SA (Secure Authentication v5), mais cette extension reste peu déployée sur le parc installé. Les RTU et IED des années 2000-2010 ne la supportent tout simplement pas, et les remplacer coûte plusieurs millions d'euros pour un réseau de distribution électrique de taille moyenne.

IEC 60870-5-104 est le protocole de supervision des réseaux électriques SCADA sur IP. Massivement déployé dans les substations européennes, il transporte des ASDU (Application Service Data Units) sans aucun mécanisme d'authentification dans sa version de base. L'attaque Industroyer/Crashoverride de 2016 en Ukraine l'a exploité directement pour envoyer de fausses commandes d'ouverture de disjoncteurs — avec des conséquences physiques mesurées en centaines de milliers de foyers privés d'électricité.

PROFINET et OPC-UA sont les protocoles de la nouvelle génération. OPC-UA intègre nativement TLS, des certificats X.509 et des mécanismes d'autorisation par sessions. C'est le protocole recommandé pour tout nouveau déploiement. Mais il coexiste avec les trois précédents dans la quasi-totalité des sites industriels réels — et les remplacer est un projet de plusieurs années, pas de quelques semaines.

Ce zoo protocolaire crée un défi analytique immense : un outil de détection d'anomalies doit comprendre la sémantique de chacun de ces protocoles, pas simplement inspecter des paquets IP génériques.

Pourquoi les SIEM classiques échouent sur les réseaux SCADA ?

La question mérite d'être posée directement, parce que beaucoup d'entreprises font l'erreur de pousser leurs logs SCADA dans Splunk ou Elastic et s'imaginent couverts. Elles ne le sont pas.

Un SIEM classique fonctionne sur des règles de corrélation basées sur des événements discrets : tentative de connexion échouée, modification de règle firewall, accès admin hors horaires. Ces événements sont bien définis, typés, structurés selon des standards comme CEF ou LEEF.

Les protocoles OT ne génèrent pas ces événements. Un flux Modbus normal est un flux continu de lectures/écritures de registres à intervalles réguliers — toutes les 100 ms, toutes les secondes, selon le polling configuré. Une anomalie n'est pas un "événement" au sens SIEM : c'est une déviation statistique par rapport à un comportement baseline. La valeur du registre HR40001 qui devrait osciller entre 850 et 950 rpm et qui lit soudainement 1 240 rpm — ça, un SIEM ne le voit pas. Un modèle Isolation Forest, si.

Deuxième problème : la latence. Un SIEM ingère, parse, normalise et corrèle. Ce pipeline prend généralement plusieurs secondes. Sur un réseau industriel où une ouverture de vanne non désirée peut provoquer une surpression en 800 ms, plusieurs secondes de délai de détection, c'est inutilisable opérationnellement.

Troisième problème : le volume de données. Un réseau SCADA de taille moyenne génère plusieurs milliers de trames par seconde. Ingérer tout ça dans un SIEM, c'est prohibitif en termes de licences et de stockage. Les modèles ML déployés directement sur des sondes réseau analysent ce flux en temps réel, en RAM, sans archivage systématique.

Isolation Forest : le premier rempart ML sur les flux Modbus

Isolation Forest est un algorithme d'apprentissage non supervisé proposé par Liu, Ting et Zhou en 2008. Son principe est contre-intuitif mais redoutablement efficace : au lieu de modéliser ce qui est "normal" pour détecter les anomalies par contraste, il modélise directement ce qui est "isolable". Une anomalie est, par définition, une observation qui peut être isolée par peu de partitions aléatoires dans l'espace des features.

Sur des données Modbus, les features typiques sont :

• La valeur brute du registre (Holding Register, Input Register, Coil)
• Le delta par rapport à la valeur précédente
• Le code fonction (FC01 à FC23 — l'apparition de FC08 "Diagnostics" hors maintenance est souvent suspecte)
• L'adresse esclave et le numéro de registre
• Le timestamp et la fréquence d'interrogation
• La longueur de la PDU (Protocol Data Unit)

L'Isolation Forest s'entraîne en quelques secondes sur quelques heures de trafic normal. Une fois déployé, il score chaque nouvelle trame en moins d'une milliseconde. Son avantage principal pour les environnements OT : il ne nécessite pas de données labellisées (attaques étiquetées), qu'on n'a presque jamais en production industrielle réelle.

Voici une implémentation commentée pour analyser un dump de trafic Modbus au format CSV :

import pandas as pd
import numpy as np
from sklearn.ensemble import IsolationForest
from sklearn.preprocessing import StandardScaler

# --- Chargement du trafic Modbus capturé (ex: via Wireshark + tshark) ---
# Colonnes attendues: timestamp, slave_id, function_code, register_addr, value, pdu_length
df = pd.read_csv('/tmp/modbus_traffic.csv', parse_dates=['timestamp'])

# --- Feature engineering pour contexte temporel ---
df = df.sort_values('timestamp')
df['value_delta'] = df.groupby(['slave_id', 'register_addr'])['value'].diff().fillna(0)
df['time_delta_ms'] = df['timestamp'].diff().dt.total_seconds().fillna(0) * 1000
df['freq_deviation'] = abs(df['time_delta_ms'] - df['time_delta_ms'].median())

# --- Features utilisées pour l'Isolation Forest ---
features = ['function_code', 'register_addr', 'value', 'value_delta',
            'time_delta_ms', 'freq_deviation', 'pdu_length']

X = df[features].fillna(0)

# --- Normalisation (important pour les features à échelles différentes) ---
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

# --- Entraînement sur données de référence (baseline "normal") ---
# contamination=0.02 : on estime 2% d'anomalies dans le dataset d'entraînement
# n_estimators=200 : plus que le défaut (100) pour meilleure précision sur OT
model = IsolationForest(
    n_estimators=200,
    contamination=0.02,
    max_samples='auto',
    random_state=42,
    n_jobs=-1  # Parallélisation sur tous les coeurs disponibles
)
model.fit(X_scaled)

# --- Scoring et détection ---
df['anomaly_score'] = model.score_samples(X_scaled)  # Plus négatif = plus anormal
df['is_anomaly'] = model.predict(X_scaled)           # -1 = anomalie, 1 = normal

# --- Seuil dynamique basé sur percentile ---
threshold = np.percentile(df['anomaly_score'], 2)    # Top 2% des anomalies
anomalies = df[df['anomaly_score'] < threshold].copy()

print(f"Trafic analysé : {len(df)} trames Modbus")
print(f"Anomalies détectées : {len(anomalies)} ({len(anomalies)/len(df)*100:.2f}%)")
print("
Top anomalies par slave_id:")
print(anomalies.groupby('slave_id')['anomaly_score'].min().sort_values().head(10))

# --- Export des alertes pour intégration SIEM/SOC ---
anomalies[['timestamp', 'slave_id', 'function_code', 'register_addr',
           'value', 'anomaly_score']].to_csv('/tmp/modbus_anomalies.csv', index=False)

LSTM et Autoencoder : capturer les anomalies temporelles que l'Isolation Forest rate

L'Isolation Forest a un angle mort majeur : il analyse chaque observation de manière quasi-indépendante. Il peut détecter qu'une valeur de registre est statistiquement aberrante, mais il rate les attaques qui progressent lentement sur des heures ou des jours — ce qu'on appelle les "slow burn attacks" dans le vocabulaire ICS.

Imaginez une attaque qui modifie progressivement le setpoint de pression d'un compresseur : +0,5 bar par heure pendant 12 heures. Chaque mesure individuelle est dans les limites normales. C'est la séquence temporelle qui est anormale. Seul un modèle temporel peut le détecter.

LSTM (Long Short-Term Memory) est un type de réseau de neurones récurrents conçu pour mémoriser des dépendances à long terme. Sur des données OT, on l'utilise en mode prédictif : le modèle apprend à prédire la prochaine valeur de registre à partir des N valeurs précédentes. Si la valeur réelle dévie significativement de la prédiction — erreur de reconstruction supérieure au seuil calibré — c'est une anomalie.

Les Autoencoders convolutifs fonctionnent différemment : ils compriment les données dans un espace latent de faible dimension, puis les reconstruisent. Sur les données normales vues pendant l'entraînement, la reconstruction est fidèle. Sur des données anormales non vues, l'erreur de reconstruction explose. Un Autoencoder convolutif sur des fenêtres de 60 secondes de trafic OPC-UA peut atteindre une AUC-ROC de 0,96 sur le dataset SWaT — contre 0,87 pour l'Isolation Forest seul sur le même jeu de données.

Datasets publics ICS : BATADAL, SWaT et HAI pour entraîner vos modèles

Un des obstacles majeurs au ML sur réseaux OT est le manque de données d'entraînement réelles. Aucune entreprise industrielle ne va partager ses données de supervision en open source. Heureusement, la communauté académique a produit trois datasets de référence qui permettent de prototyper et benchmarker sérieusement.

SWaT (Secure Water Treatment) du iTrust Lab de l'Université de Singapour est le dataset de référence absolu. Il simule une station de traitement d'eau avec 51 capteurs et actionneurs sur 11 jours de fonctionnement normal et 4 jours d'attaques — 36 attaques distinctes documentées. Les données incluent des valeurs de débitmètres, niveaux de réservoirs, états de pompes et mesures de pH. Plus de 800 papiers académiques l'ont utilisé depuis sa publication. Il est disponible sur demande auprès du iTrust Lab.

BATADAL (BATtle of the Attack Detection ALgorithms) est une compétition lancée en 2016 sur un système de distribution d'eau simulé dit "C-Town". Il fournit 7 scénarios d'attaques contre des actionneurs hydrauliques, avec des données horaires sur 2 ans. Sa spécificité : les attaques sont conçues pour être réalistes et difficiles à détecter — contrairement à des anomalies "caricaturales" qui faussent les benchmarks.

HAI (HIL-based Augmented ICS) du KAIST (Corée du Sud) est le plus récent et le plus réaliste des trois. Il couvre une chaîne de production simulée par hardware-in-the-loop avec des équipements physiques réels — Siemens S7-1200, ABB drives. Disponible sur GitHub sous licence ouverte, il est idéal pour benchmarker des modèles sur un environnement proche de la réalité industrielle.

Comment le MITRE ATT&CK for ICS structure-t-il votre approche de détection ?

Le framework MITRE ATT&CK for ICS couvre 81 techniques réparties sur 12 tactiques, de la Reconnaissance initiale (T0840 — Network Connection Enumeration) jusqu'à l'Impact (T0879 — Damage to Property). Chaque modèle ML que vous déployez doit être mappé sur ces techniques — pas pour faire joli dans un rapport, mais parce que ce mapping conditionne la priorité des alertes et la justification budgétaire devant la direction.

Les techniques les plus ciblées par les APT ICS en 2024 selon le rapport Dragos Year in Review :

• T0801 — Monitor Process State : reconnaissance passive du processus industriel. Un Isolation Forest sur le flux de lectures Modbus détecte une augmentation anormale de la fréquence d'interrogation, caractéristique de cette phase de collecte de renseignements.
• T0836 — Modify Parameter : modification de setpoints ou paramètres de contrôle. Un LSTM en mode prédictif détecte les dérives de valeurs de paramètres qui ne correspondent pas au modèle appris sur le comportement historique.
• T0855 — Unauthorized Command Message : injection de commandes non autorisées. L'Isolation Forest sur les codes fonctions Modbus — particulièrement FC06 Write Single Register et FC16 Write Multiple Registers — est particulièrement efficace ici.
• T0816 — Device Restart/Shutdown : redémarrage forcé d'équipements. Détectable par l'absence soudaine de trames polling vers un esclave habituellement actif.

La CISA recommande explicitement d'utiliser ce mapping pour construire des use cases de détection, dans ses advisories ICS-CERT publiés tout au long de 2023-2024. C'est aussi l'approche retenue par la directive NIS 2 pour les opérateurs d'infrastructures critiques soumis à l'obligation de détection.

Comparatif des algorithmes ML pour la détection d'anomalies OT

Intégration Claroty, Dragos et Nozomi Networks : l'état de l'art commercial

Les trois leaders du marché OT Security — Claroty, Dragos et Nozomi Networks — ont tous intégré des capacités ML dans leurs plateformes, mais avec des approches et des philosophies très différentes.

Claroty xDome utilise un moteur de détection comportementale basé sur du profiling réseau : il apprend les communications normales entre chaque paire d'équipements OT et génère des alertes sur les nouvelles connexions ou les modifications de comportement. Son avantage est une intégration native avec les principaux protocoles OT — Modbus, DNP3, IEC 61850, PROFINET, EtherNet/IP. Il expose une API REST permettant d'exporter les données de profiling pour entraîner vos propres modèles externes sur vos données de production réelles.

Dragos Platform est plus orientée threat intelligence : ses modèles ML sont alimentés par les IOCs et TTPs des groupes APT ICS suivis par les équipes de recherche Dragos (VOLTZITE, KAMACITE, ELECTRUM, STIBNITE). Plutôt que de détecter des anomalies statistiques génériques, Dragos cherche des signatures comportementales spécifiques aux groupes connus. Efficace contre les menaces documentées, moins adaptatif face aux zero-days ou aux attaquants non encore catalogués.

Nozomi Networks Guardian combine profiling comportemental et ML pour générer un score de risque par équipement. Il supporte l'intégration de modèles au format ONNX (Open Neural Network Exchange), ce qui permet techniquement d'injecter un LSTM entraîné sur vos données de production directement dans la plateforme. C'est la solution la plus ouverte des trois pour les équipes qui veulent garder la main sur leurs modèles de détection.

Pour une architecture optimale, la combinaison recommandée est : Nozomi ou Claroty pour la visibilité réseau et la collecte de données → pipeline ML custom (Isolation Forest + LSTM) pour la détection fine → SIEM pour la corrélation avec les événements IT → Dragos pour le contexte threat intel APT.

Secteurs eau, énergie, transport : les cas d'usage qui illustrent l'urgence

L'attaque contre la station de traitement d'eau d'Oldsmar (Floride) en février 2021 reste le cas d'école le plus cité dans les formations OT Security. Un attaquant a pris le contrôle du système de supervision via TeamViewer et a tenté d'augmenter la concentration de soude caustique de 111 ppm à 11 100 ppm — soit 100 fois la dose normale. Un opérateur a observé la manipulation en temps réel et l'a annulée manuellement. Sans surveillance humaine constante, l'eau distribuée aurait pu empoisonner des milliers de personnes. Un modèle ML sur le flux Modbus des doseurs chimiques aurait déclenché une alerte en quelques secondes — avant même qu'un opérateur remarque le déplacement du curseur.

Dans le secteur énergétique, l'attaque Industroyer2 contre une infrastructure électrique ukrainienne en 2022 a montré la sophistication croissante des attaquants : le malware comprenait des parsers natifs pour les protocoles IEC 60870-5-104 et IEC 61850, lui permettant d'émettre des commandes légitimes apparaissant normales pour les systèmes de supervision conventionnels. Seul un modèle temporel analysant les séquences de commandes — la combinaison d'ouvertures coordonnées de disjoncteurs dans un ordre temporel inhabituel — aurait pu détecter le pattern.

Dans les transports, les systèmes SCADA de gestion du trafic ferroviaire (ERTMS, Eurobalise) et les PLC de commande des aiguillages représentent des cibles critiques de plus en plus exposées. En 2023, l'ENISA a publié un rapport identifiant 143 incidents cyber sur les infrastructures de transport ferroviaire en Europe sur 5 ans — dont 38% impliquant des systèmes OT SCADA directement.

Quelle architecture ML déployer sans impacter la production OT ?

Le déploiement ML en OT soulève une contrainte absolue que tout architecte doit intégrer dès le départ : le mode passif uniquement. Aucun modèle ne doit jamais envoyer de trafic sur le réseau industriel, même pour des tests. La sonde doit être en mode "écoute seule" via port mirroring ou TAP réseau, physiquement incapable d'écrire sur le bus OT.

L'architecture cible recommandée selon le NIST SP 800-82r3 (Guide to Industrial Control Systems Security, révision 3, 2023) comprend quatre couches :

1. Couche 0-1 (Terrain) : sondes passives sur les segments Modbus/DNP3, collecte via TAP réseau industriel (ex : Garland Technology ProfiShark, SPAN port sur switch manageable)
2. Couche 2 (Supervision) : agrégateur de données OT → pipeline ML (Isolation Forest pour détection temps réel, LSTM pour analyse temporelle asynchrone sur fenêtres de 1 à 60 minutes)
3. DMZ OT/IT : broker de données unidirectionnel — data diode — vers la couche IT. Aucun flux retour possible vers l'OT, physiquement ou logiquement.
4. Couche IT/SOC : ingestion des alertes ML dans le SIEM, enrichissement threat intel via MITRE ATT&CK for ICS, ticketing SOC avec priorité selon la technique mappée

Les modèles ML sont hébergés dans la couche 2 (supervision), pas dans la couche 0-1 (terrain) — les PLCs et RTU n'ont pas les ressources de calcul nécessaires. L'inférence doit se faire sur des serveurs industriels durcis (IPC) avec des latences garanties, pas sur du cloud public dont la disponibilité et la latence réseau ne sont pas compatibles avec les contraintes temps-réel des OT networks.

Pour les architectures d'IA plus complexes impliquant des agents autonomes, consultez notre analyse des agents IA autonomes et leurs frameworks — les agents de détection OT doivent impérativement fonctionner en mode "advisory" uniquement, sans capacité d'action directe sur les équipements.

La corrélation avec des systèmes RAG (Retrieval-Augmented Generation) ouvre des perspectives intéressantes : un système RAG alimenté par les bulletins CISA-ICS-CERT et les publications Dragos peut enrichir automatiquement les alertes ML avec le contexte threat intel pertinent, sans intervention humaine pour chaque alerte.

Pour sécuriser les modèles ML eux-mêmes contre les attaques adversariales, notre guide sur la sécurité des agents LLM couvre les principes d'isolation et de sandboxing applicables aux pipelines ML déployés en environnement sensible.

Le glossaire IA & cybersécurité 2026 réunit les définitions précises de tous les termes de cet article — utile pour aligner les équipes OT et IT sur une terminologie commune lors des revues de sécurité.

Questions fréquentes sur la détection d'anomalies IA en SCADA/ICS

Peut-on déployer un modèle ML sans connaître les protocoles OT utilisés sur le site ?

Techniquement oui — un Isolation Forest sur des métriques réseau génériques (débits, intervalles, tailles de paquets) peut détecter des anomalies sans parser les protocoles spécifiques. Mais les performances sont significativement dégradées. Un modèle qui comprend la sémantique Modbus — codes fonction, plages de registres normales, topologie maître/esclave — atteint une AUC-ROC 15 à 20 points supérieure à un modèle "aveugle" au protocole. L'audit du parc protocolaire est donc un prérequis à tout déploiement ML sérieux.

Combien de temps de données normales faut-il pour entraîner un modèle fiable ?

Pour un Isolation Forest : 48 à 72 heures de trafic couvrant au moins un cycle de production complet — shift matin/soir, cycle hebdomadaire si la production varie selon les jours. Pour un LSTM ou Autoencoder : 2 à 4 semaines minimum pour capturer les variations saisonnières normales et les modes opératoires distincts. Les données d'entraînement doivent être "propres" — collectées pendant une période sans incident connu et sans maintenance planifiée susceptible de générer des comportements atypiques légitimes.

Comment gérer les faux positifs sans noyer le SOC sous les alertes ?

C'est le problème numéro un en déploiement réel. La solution standard est un scoring à deux niveaux : l'alerte ML de niveau technique (haute sensibilité, beaucoup d'alertes) et l'alerte SOC (après validation par un second modèle ou règle métier, volume réduit). Sur Modbus, on peut supprimer les alertes systématiquement pendant les fenêtres de maintenance planifiées via intégration avec le CMMS. Les modèles d'ensemble qui requièrent une détection par Isolation Forest ET LSTM pour déclencher une alerte réduisent les faux positifs de 60 à 70% au prix d'une légère augmentation des faux négatifs.

Les solutions Claroty, Dragos ou Nozomi remplacent-elles un modèle ML custom ?

Non — elles se complètent. Les solutions commerciales offrent une couverture large et immédiate, avec des règles préconfigurées sur des milliers de protocoles OT et un threat intel mis à jour en continu. Un modèle ML custom entraîné sur vos données de production capture les anomalies spécifiques à votre processus industriel — anomalies qu'aucune règle générique ne peut anticiper, parce qu'elles dépendent de votre configuration unique. Le ratio optimal est environ 70% de couverture commerciale, 30% de détection ML custom sur les processus les plus critiques.

Quelles certifications sont requises pour un système de détection ML en environnement ICS ?

Il n'existe pas encore de certification spécifique "ML pour OT". Le cadre normatif applicable est IEC 62443 (Security for Industrial Automation and Control Systems), en particulier IEC 62443-3-3 (System Security Requirements and Security Levels) qui définit les exigences de détection d'anomalies au niveau SR 3.1. La conformité IEC 62443 est de plus en plus exigée par les assureurs cyber pour les sites industriels, et sa vérification par audit tiers va devenir un standard de marché d'ici 2026-2027.

Conclusion

L'IA pour la détection d'anomalies SCADA/ICS n'est plus une promesse académique — c'est une nécessité opérationnelle que les incidents Oldsmar, Industroyer2 et les 21 groupes APT actifs sur les réseaux OT en 2024 rendent incontournable. L'Isolation Forest reste l'entrée en matière la plus rapide à déployer sur flux Modbus et DNP3, le LSTM prend le relais pour les attaques lentes sur séries temporelles, et les Autoencoders convolutifs dominent sur les datasets de référence avec des AUC-ROC dépassant 0,95 sur SWaT.

La vraie difficulté n'est pas algorithmique — les algorithmes existent, sont documentés, et la communauté open source en propose des implémentations matures. Elle est opérationnelle : déployer en mode strictement passif, gérer les faux positifs sans saturer le SOC, intégrer avec les solutions commerciales existantes Claroty/Dragos/Nozomi, et maintenir les modèles à jour quand la production évolue. Ce sont ces défis que les équipes OT et IT doivent adresser ensemble, avec le soutien d'experts qui comprennent les deux mondes — celui des automates industriels et celui du machine learning.