Sécuriser un SCADA aux protocoles non authentifiés

Sécuriser un SCADA aux protocoles non authentifiés

Les protocoles industriels historiques transportent souvent des ordres critiques sans authentifier l’émetteur ni protéger l’intégrité des messages. Un système SCADA (Supervisory Control and Data Acquisition) ne devient pas sûr parce que le réseau est « industriel » : un paquet accepté par un automate reste un ordre exécuté, quelle que soit l’intention de son expéditeur.

Explication de la marmotte

Un site industriel utilise parfois des machines qui obéissent à toute personne capable de leur parler dans la bonne langue. C’est pratique pour faire fonctionner l’ensemble rapidement, mais dangereux si quelqu’un entre dans la zone réservée et donne un ordre malveillant, maladroit ou simplement absurde.

→ Lire l’explication complète de la marmotte

Protocoles SCADA sans authentification : le problème réel

Modbus TCP, DNP3 (Distributed Network Protocol version 3) sans extension sécurisée, IEC 60870-5-104 et certains usages historiques d’OPC Classic (Open Platform Communications Classic) reposent sur une hypothèse brutale : le réseau transporte des messages légitimes. Le protocole reconnaît une fonction, une adresse de registre, une valeur et parfois un numéro de séquence. Il ne reconnaît généralement pas l’identité de celui qui parle.

Avec Modbus TCP, écrire une bobine ou un registre ne demande ni mot de passe, ni certificat, ni signature. Une requête Write Single Coil correctement formée suffit. Avec IEC 60870-5-104, les commandes de téléconduite peuvent être injectées ou rejouées si le chemin réseau est accessible et qu’aucune protection complémentaire ne les encadre. Le protocole ne devient pas plus méfiant parce qu’il transporte une commande de disjoncteur plutôt qu’une mesure de température. Les octets n’ont pas de conscience professionnelle.

Le compromis central est net : ces protocoles gagnent en déterminisme, interopérabilité et longévité, mais paient l’absence d’identité cryptographique au niveau applicatif. La recommandation est donc de ne jamais compenser cette absence par un vague « réseau isolé ». Il faut imposer l’identité, l’autorisation et le contrôle des flux à l’architecture environnante, puis réduire drastiquement les chemins capables de produire une commande.

Un protocole non authentifié ne garantit pas :

• l’identité de l’équipement émetteur ;
• l’intégrité d’un ordre sur un réseau compromis ;
• la fraîcheur d’un message capturé puis rejoué ;
• la confidentialité des mesures, consignes et états ;
• l’autorisation métier de l’opération demandée ;
• la traçabilité fiable de l’auteur d’une commande.

Le chiffrement réseau ne remplace pas ces garanties métier. Un tunnel TLS (Transport Layer Security) protège un transport entre deux extrémités identifiées, mais il ne vérifie pas qu’un poste d’ingénierie autorisé doit réellement modifier une consigne donnée. La séparation entre identité technique et autorisation opérationnelle doit rester explicite, comme pour les architectures cyber segmentées.

Surface d’attaque des flux Modbus, DNP3 et IEC 104

La première attaque est l’injection directe. Un poste compromis dans le réseau de technologie opérationnelle, ou OT (Operational Technology), émet des commandes vers un automate programmable, aussi appelé PLC (Programmable Logic Controller). Si le PLC écoute Modbus TCP sur le port 502 et accepte l’écriture depuis tout le sous-réseau, le contrôle d’accès est déjà perdu. L’attaquant n’a pas besoin d’exploiter une vulnérabilité logicielle. Il utilise la fonction prévue par le protocole, ce qui est le genre de détail qui rend les tableaux de bord très calmes jusqu’à l’incident.

La deuxième attaque est le rejeu. Capturer une commande légitime, puis la retransmettre, peut réappliquer une action ancienne dans un état physique différent. Un ordre valide à l’instant T peut devenir dangereux à T+1. Les numéros de séquence de transport ne suffisent pas toujours à empêcher ce rejeu après reconnexion, redémarrage ou interception active. La fraîcheur doit être fournie par une couche sécurisée avec protection anti-rejeu, ou par une logique applicative qui refuse les commandes incohérentes avec l’état du procédé.

La troisième attaque est la falsification de mesure. Modifier une valeur remontée vers l’interface opérateur, ou HMI (Human Machine Interface), permet de masquer une commande malveillante ou de provoquer une réaction humaine erronée. La supervision voit alors une température, une position ou une pression qui n’existe pas. La disponibilité reste intacte, les écrans restent verts, et c’est précisément le problème.

La quatrième attaque vise les stations d’ingénierie. Elles possèdent souvent les outils capables de programmer les PLC, les bibliothèques de projet et parfois les secrets d’accès distants. Les traiter comme de simples postes bureautiques est une erreur d’architecture. Elles doivent être dédiées, durcies, journalisées, sans navigation Internet générale, et placées dans une zone d’administration distincte.

Une capture passive est déjà suffisante pour cartographier les équipements, les identifiants de points et les séquences métier. L’absence de chiffrement transforme le réseau en documentation vivante. Les mécanismes décrits dans les fondations réseau restent pertinents, mais un pare-feu sans règle de flux métier n’est qu’une décoration très chère.

Segmentation OT et filtrage par rôle

La réponse prioritaire est une segmentation en zones, reliées par des conduits explicitement autorisés. Une zone regroupe des actifs ayant un niveau de confiance et une fonction comparables : supervision, stations d’ingénierie, automates, acquisition terrain, accès distant, collecte de journaux. Un conduit est un ensemble de flux limité entre deux zones.

Entre la zone de supervision et celle des automates, autoriser seulement les adresses sources, destinations, ports et sens nécessaires. Pour Modbus TCP, cela signifie généralement autoriser un serveur de supervision déterminé vers une liste fermée de PLC sur le port 502, puis refuser tout autre flux. Autoriser le sous-réseau entier « parce que la maintenance en aura peut-être besoin » transforme une exception future en incident prêt à servir.

Une liste de contrôle d’accès, ou ACL (Access Control List), doit distinguer lecture, écriture et administration lorsque le protocole ou un pare-feu industriel permet cette inspection. Si cette distinction n’est pas disponible de façon fiable, séparer physiquement ou logiquement les chemins de lecture et de programmation. Le filtrage de port seul ne protège pas d’une écriture Modbus : lecture et écriture utilisent le même port. Cette limite doit être documentée, pas recouverte de poudre magique zero trust.

L’accès distant passe par un bastion soumis à authentification multifacteur, enregistrement de session et approbation temporelle. Le bastion ne doit pas devenir une route générale entre le réseau informatique, ou IT (Information Technology), et les automates. Une session ouverte depuis le bastion doit atteindre une station d’ingénierie déterminée, jamais directement chaque PLC.

Quand un équipement supporte IEC 62351, notamment les mécanismes de sécurité applicables à IEC 60870-5-104, son activation est préférable. Quand il ne le supporte pas, encapsuler le flux dans un tunnel authentifié peut réduire l’exposition sur un conduit, à condition de maîtriser les extrémités. Ce tunnel ne résout ni l’autorisation de commande ni la compromission d’une station autorisée.

Exemple de filtrage entre supervision et automates

L’exemple suivant applique une politique nftables sur un pare-feu Linux placé entre une zone de supervision et une zone d’automates. Il autorise uniquement un serveur de supervision vers deux PLC pour Modbus TCP et journalise les tentatives refusées. Tester d’abord les flux de diagnostic nécessaires : certains équipements répondent depuis des ports inattendus, parce que l’industrie sait aussi faire du folklore réseau.

#!/usr/sbin/nft -f

flush ruleset

table inet filtrage_ot {
  chain forward {
    type filter hook forward priority 0;
    policy drop;

    # Autoriser les réponses aux sessions déjà validées.
    ct state established,related accept

    # Serveur SCADA 10.40.10.20 vers deux PLC Modbus TCP, port 502 uniquement.
    ip saddr 10.40.10.20 ip daddr { 10.40.20.11, 10.40.20.12 } \
      tcp dport 502 ct state new accept

    # Collecteur de journaux vers les équipements, Syslog sécurisé interdit ici par défaut.
    # Aucun accès d'administration n'est autorisé par cette règle.

    # Tracer les paquets rejetés sans saturer les journaux.
    limit rate 10/minute log prefix "OT-DROP " level warning
    drop
  }
}

Cette règle ne filtre pas les codes fonction Modbus. Elle empêche un hôte non prévu d’atteindre le port, rien de plus. Si le serveur SCADA est compromis, ses flux restent autorisés. La contre-mesure complémentaire consiste à surveiller les écritures anormales, limiter les droits applicatifs et imposer des interverrouillages physiques ou logiques dans le procédé.

Secrets, certificats et exploitation durable

Les équipements compatibles avec TLS ou IEC 62351 demandent une infrastructure de certificats. Une PKI (Public Key Infrastructure) émet des certificats pour les équipements et vérifie leur chaîne de confiance. La clé privée d’une autorité de certification ne doit pas résider sur une station d’administration ordinaire. Un HSM (Hardware Security Module) est justifié pour cette clé lorsque l’autorité émet des certificats de production ou protège une hiérarchie de confiance durable.

La rotation des certificats doit être testée sur les équipements réels. Certains PLC et passerelles nécessitent un redémarrage, ne supportent qu’une chaîne courte, refusent certains algorithmes ou conservent un certificat chargé jusqu’au prochain cycle applicatif. La révocation d’un certificat ne retire pas un accès déjà établi si la session reste active et si l’équipement ne vérifie pas régulièrement son statut. Ce point casse régulièrement les promesses de révocation instantanée vendues sur des slides très propres.

Prévoir une autorité de certification hors ligne pour les clés racines, une autorité intermédiaire dédiée aux équipements, des sauvegardes chiffrées des configurations et une procédure de restauration testée. Sauvegarder seulement le projet SCADA ne suffit pas : il faut aussi les versions de firmware, fichiers de configuration réseau, certificats publics, clés de tunnel, règles de filtrage et documentation des dépendances physiques.

La supervision doit corréler les événements réseau, systèmes et applicatifs dans un SIEM (Security Information and Event Management). Détecter au minimum : nouvelles adresses parlant Modbus, hausse d’écritures, changements de configuration PLC, sessions distantes hors créneau, échecs de certificat, modification de règle pare-feu et perte de télémétrie. Un IDS (Intrusion Detection System) industriel passif est préférable à une sonde active sur les segments fragiles : scanner un automate en production reste une méthode étonnamment efficace pour découvrir que la disponibilité était un prérequis.

🐝 Ce qui arrive si on s’en passe

Sans zones, conduits filtrés et journalisation des ordres, la question posée après un arrêt de procédé reste sans réponse : rien ne permet de distinguer une manoeuvre d’opérateur, une erreur de configuration et une commande injectée, puisque le protocole n’attache aucune identité à l’écriture. L’analyse post-incident se réduit alors à l’inspection manuelle de chaque automate, avec relecture des programmes et comparaison aux sauvegardes, ce qui allonge la remise en service bien au-delà de la panne elle-même. L’absence de politique de flux prive aussi la détection de référence : sans liste fermée d’émetteurs légitimes, une nouvelle adresse parlant Modbus ne constitue plus un signal exploitable. Enfin, la démonstration de conformité à un découpage en zones et conduits devient impossible, faute de règles écrites et de traces opposables.

🦫 Explication de la marmotte 🍫

Un système de supervision industrielle reçoit des mesures et envoie des ordres à des machines. Certaines règles de communication utilisées par ces machines sont anciennes. Elles savent reconnaître la forme d’un ordre, mais elles ne vérifient pas toujours qui l’a envoyé. Si une personne ou un programme malveillant accède au bon réseau, il peut donc lire des informations, modifier une valeur ou répéter un ordre déjà observé.

La protection commence par séparer les réseaux. Les postes de bureau, les outils de maintenance, les écrans de supervision et les machines de terrain ne doivent pas tous communiquer librement. Un équipement de filtrage autorise seulement les échanges nécessaires entre des appareils précis. Par exemple, l’écran de supervision peut parler à une machine donnée, mais un ordinateur inconnu ne le peut pas.

Quand les équipements le permettent, un mécanisme de chiffrement et de preuve d’identité protège les échanges. Chaque appareil reçoit alors une identité numérique et refuse les interlocuteurs non reconnus. Cette protection peut échouer si les clés sont volées, expirées ou mal installées, donc elles doivent être renouvelées et sauvegardées.

Enfin, il faut surveiller les ordres envoyés, les changements de configuration et les connexions distantes. Si un poste autorisé est piraté, le filtrage réseau ne suffit plus. Les machines doivent aussi disposer de limites propres au procédé, capables de refuser une commande dangereuse même lorsqu’elle arrive par un chemin autorisé.

À lire aussi

• Sécuriser un SCADA d’eau et d’énergieSécurisation des systèmes SCADA d’eau et d’énergie face aux protocoles historiques, aux effets physiques des commandes et aux exigences de NIS2.
• Pourquoi un automate industriel ne se patche pasSécurité OT/ICS : pourquoi le correctif d'un automate industriel exige une stratégie de risque, de validation et de reprise.
• Faire cohabiter équipements industriels anciens et neufsRétrocompatibilité industrielle : faire cohabiter du neuf et du matériel des années 1990 sans étendre la surface d'attaque ni rendre l'exploitation impossible.
• Réseaux spécialisés, sobriété avancée et futurs raisonnablesRegrouper les domaines spécialisés et pistes d’évolution à connaître sans les présenter comme des certitudes : OT, industriel, quantique, participatif, blockchain et réseaux futurs.

Pages voisines

La citent

• Faire cohabiter équipements industriels anciens et neufs
• Pourquoi un automate industriel ne se patche pas
• Sécuriser un SCADA d’eau et d’énergie
• Comprendre pourquoi les systèmes communiquent
• IEC
• Topologies, composants d’interconnexion et LAN sécurisé

Sécuriser un SCADA aux protocoles non authentifiés

Elle cite

• ⇄Lien dans les deux sens :DMZ industrielle pour protéger le réseau de production
• ⇄Lien dans les deux sens :Sécuriser une interface HMI industrielle Windows
• Configurer Suricata sur un segment réseau critique

⇄ : les deux pages se citent l’une l’autre.