La cyber-déception en OT : Rompre le cycle de l'aveuglement après une attaque

Dans les environnements OT (Opérations Technologiques), la réponse à un incident est souvent paralysée par un vide informationnel critique : l'absence de logs, d'historique et de visibilité. La cyber-déception (Cyber Deception) ne se contente plus de ralentir les attaquants en SI ; elle devient un impératif stratégique pour recréer une empreinte numérique exploitable et piéger les acteurs adverses dans les infrastructures industrielles.

En bref

• Le paradoxe OT : Les systèmes industriels (PLC, DCS, SCADA) sont souvent dépourvus de mécanismes de logging natifs, rendant la détection et la forensique quasi impossibles après coup.
• L'illusion de la sécurité périmétrique : Les pare-feu industriels (DPI) ne suffisent pas ; les attaquants qui pénètrent le réseau OT opèrent souvent "silencieusement" sans laisser de trace.
• La déception active : Déployer des dispositifs de leurre (honeypots, faux HMI, canaux de communication bidirectionnels) permet de générer du trafic anormal détectable et de tracer les mouvements de l'attaquant.
• Réversibilité de l'impact : Contrairement au SI où les données sont clonées, une erreur en OT peut provoquer un arrêt de production ou un danger physique. La déception doit être isolée pour éviter tout impact opérationnel.
• Nouvelle source de données : Les interactions avec les leurres fournissent un historique comportemental qu'il n'existait pas auparavant, transformant l'aveuglement en intelligence.

L'aveuglement structurel des environnements OT

La réalité frustrante d'une attaque OT est souvent celle du "noir total". Contrairement aux environnements IT où les serveurs d'application génèrent des journaux d'accès, des logs d'authentification et des traces de requêtes, les équipements OT sont conçus pour la fiabilité et la disponibilité, non pour la traçabilité.

Un programmable logic controller (PLC) exécutant une boucle de contrôle temps réel n'a pas de concept de "session utilisateur" au sens traditionnel. Il reçoit des signaux, exécute une logique et envoie des sorties. Si un ingénieur malveillant ou un script malveillant se connecte via un protocole industriel (Modbus, DNP3, IEC 104) pour modifier un point d'état, il n'y a souvent aucun log local pour indiquer qui a fait la modification, quand elle a eu lieu, ou depuis quel IP elle est partie.

Cette absence de données crée trois problèmes majeurs pour le consultant IT/OT :

1. Impossibilité de forensique : Après un incident, on ne peut pas reconstruire la chronologie des actions.
2. Détection tardive : L'alerte ne survient souvent qu'après que le processus a été perturbé (anomalie de production, arrêt d'urgence).
3. Absence de contexte : Sans historique, il est difficile de distinguer un incident de sécurité d'une erreur de configuration ou d'un comportement inhabituel mais légitime de l'opérateur.

La cyber-déception propose un changement de paradigme : si nous ne pouvons pas compter sur les systèmes réels pour nous informer, nous créons des systèmes factices qui sont conçus pour le faire.

Stratégie de déception : Créer l'empreinte numérique manquante

L'objectif de la déception en OT n'est pas seulement de "piéger" l'attaquant, mais de générer de la visibilité là où elle n'existe pas. En déployant des dispositifs de leurre, on crée une surface d'attaque contrôlée qui, par définition, ne devrait jamais être touchée par des opérations légitimes. Toute interaction avec ces leurres est donc, par essence, suspecte.

1. Les leurres de communication (Honeypots Protocole)

Plutôt que de déployer de simples faux serveurs web, il faut imiter les protocoles industriels. Un honeypot Modbus ou S7comm peut simuler un PLC ou un HMI.

• Fonctionnement : Le dispositif écoute sur le port 502 (Modbus) ou 102 (S7). Il répond aux requêtes de lecture d'état avec des valeurs plausibles (ex : température à 25°C, pompe active).
• Génération de logs : Chaque requête est journalisée avec précision : timestamp, IP source, ID de transaction, fonction code, adresse registre.
• Valeur ajoutée : Si un attaquant tente d'écrire dans un registre de contrôle (ex : arrêt d'une pompe) sur le leurre, vous obtenez un log complet de l'intention malveillante, y compris les valeurs exactes qu'il essayait d'imposer. C'est une preuve d'intention, pas seulement de présence.

2. Les leurres de processus (Faux HMIs et Dashboards)

Les systèmes SCADA et les HMIs (Human-Machine Interfaces) sont des cibles privilégiées car ils offrent une interface graphique intuitive. Déployer un faux HMI accessible via le réseau OT permet de capturer les interactions de l'attaquant.

• Simulation de logique : Le faux HMI affiche des jauges, des alarmes et des boutons de commande. Il peut simuler des états dynamiques (ex : niveau de réservoir qui baisse lentement) pour semer le réalisme.
• Capture de session : L'attaquant qui clique sur "Arrêt d'urgence" ou "Reset Alarm" génère un événement. Le système peut alors :
  • Enregistrer l'action.
  • Déclencher une alerte immédiate.
  • Isoler le hôte source (via une règle de pare-feu dynamique) pour empêcher la propagation vers les systèmes réels.

3. La déception bidirectionnelle (Active Deception)

Au-delà de la simple écoute, la déception active peut envoyer des données. Par exemple, un faux gateway peut envoyer des trames de diagnostic qui semblent légitimes. Si l'attaquant utilise ces trames comme référence pour calibrer son attaque (ex : ajuster ses paquets pour correspondre au format de réponse), il révèle ses outils et sa méthodologie.

Implémentation technique : Isolation et intégration

L'intégration de la déception en OT est plus complexe qu'en IT en raison des contraintes de temps réel et de la ségrégation de réseau (zone DMZ, zone OT, zone IT).

Architecture de référence

1. Zone de Déception (Decoy Zone) : Un segment de réseau VLAN dédié, isolé des zones de production critique. Il est accessible depuis les zones où les attaquants sont susceptibles de se retrouver (ex : après un pivot depuis l'IT).
2. Passerelle de Déception : Un appliance logicielle ou matérielle qui émule les protocoles. Elle doit être capable de parler Modbus TCP, OPC UA, ou DNP3.
3. Module de Décision (SOP - Security Operations Platform) : Le cœur du système. Il reçoit les logs des leurres, les corrèle avec les flux réseau (via les pare-feu industriels) et déclenche les actions.

Exemple de configuration de règles de pare-feu dynamique

Lorsqu'un leurre détecte une écriture interdite, le système doit immédiatement bloquer la source. Voici un exemple conceptuel de règle dans un pare-feu industriel (comme un FortiGate, Palo Alto ou un module de détection d'intrusion dédié OT) :

# Règle de pare-feu : Bloquer l'IP source après interaction avec le honeypot Modbus
# Déclenchement : Alertes de type "WRITE_REGISTER" sur le honeypot H1

# 1. Identification de l'alerte par le module de déception
alert_id = "OT_DECEPTION_MODBUS_WRITE"
source_ip = "10.50.20.15"  # IP de l'attaquant identifiée

# 2. Action corrective automatique via API du pare-feu
# Création d'une règle de blocage haute priorité
rule_name = "BLOCK_ATTACKEr_FROM_HONEYPOT"
action = "DENY"
src_address = source_ip
dst_address = "ANY"
service = "ANY"
priority = 1  # Plus haute priorité
log = "ENABLED"

# 3. Notification au SOC
send_notification(
    severity="HIGH",
    message=f"Interaction malveillante détectée sur leurre OT. Source {source_ip} bloquée.",
    channel="SOC_ONCALL"
)

Considérations de performance

Les dispositifs de déception ne doivent jamais affecter la latence des systèmes réels. Ils doivent être déployés de manière à ce que leur trafic soit isolé. Dans les environnements à haute criticité, il est recommandé de placer les leurres dans une zone DMZ spécifique qui n'est pas sur le chemin direct des commandes de contrôle, mais accessible via les interfaces de supervision.

Défis spécifiques aux environnements OT

Le risque de "faux positif" opérationnel

En IT, un faux positif peut bloquer un utilisateur légitime. En OT, un faux positif peut arrêter une ligne de production. La déception doit donc être précise.

• Solution : Ne déclencher des actions de blocage que sur des actions interdites (écritures dans des registres de contrôle, tentatives d'escalade de privilèges, accès à des points de données non autorisés). Les lectures simples sont loggées mais ne déclenchent pas de blocage immédiat, sauf si elles proviennent d'une IP déjà suspectée.

La résistance au changement

Les équipes OT sont souvent réticentes à l'idée de "pièges" dans leur réseau. Ils craignent que les leurres ne soient confondus avec des équipements réels par les opérateurs.

• Solution : Les leurres doivent avoir des noms et des adresses IP clairement identifiés comme non productifs dans la documentation réseau, mais pas dans les interfaces qu'ils émulent (pour tromper l'attaquant). La communication avec les équipes OT est cruciale pour expliquer que ces dispositifs ne touchent jamais aux processus réels.

La conformité et les réglementations

Des réglementations comme la NIS2, le Cybersecurity Act ou les normes sectorielles (IEC 62443) exigent une détection et une réponse. La déception fournit des preuves concrètes d'activités malveillantes, ce qui facilite la conformité et les rapports d'incident.

Bonnes pratiques pour consultants IT

1. Commencez petit : Déployez d'abord des leurres de protocole (Modbus/S7) dans une zone DMZ. Évitez les leurres de processus complexes au début.
2. Intégrez au SOC existant : Ne créez pas un nouveau SIEM dédié à la déception. Intégrez les logs des leurres dans votre plateforme de sécurité existante (Splunk, Elastic, QRadar) avec des tags spécifiques (ex : source=OT_Decoy).
3. Testez l'isolation : Vérifiez rigoureusement que le trafic des leurres ne peut pas rebondir vers les systèmes réels. Utilisez des pare-feu en série et des règles de routage strictes.
4. Documentez les scénarios : Pour chaque leurre, documentez les actions qui déclenchent une alerte haute, moyenne ou basse. Cela permet au SOC de prioriser correctement.
5. Analysez les comportements : Ne vous contentez pas de bloquer. Analysez comment l'attaquant interagit avec le leurre. Utilise-t-il des outils automatiques ? Tente-t-il des exploits connus ? Ces données enrichissent votre profil de menace OT.
6. Mettez à jour les règles de pare-feu : Assurez-vous que les règles de blocage dynamique sont nettoyées automatiquement après une période définie (ex : 24h) pour éviter de bloquer des IP légitimes qui auraient changé de contexte (rare en OT, mais possible).

Points clés

La cyber-déception en OT n'est pas une solution miracle, mais un complément indispensable à la surveillance classique. Elle répond directement à la frustration de l'absence de données après une attaque en créant elle-même les données nécessaires à la détection et à la forensique.

En transformant les systèmes OT "silencieux" en sources actives d'information, les consultants IT peuvent passer d'une posture réactive (réagir à la panne) à une posture proactive (identifier l'attaquant avant qu'il n'atteigne les systèmes critiques). L'objectif final n'est pas seulement de piéger l'attaquant, mais de rétablir la visibilité dans un environnement où elle est structurellement absente.

Source : Dark Reading