Sécuriser un SCADA d’eau et d’énergie

Sécuriser un SCADA d’eau et d’énergie

Un système SCADA (Supervisory Control and Data Acquisition) pilote des ouvrages dont l’état se traduit dans le monde physique : niveau d’un réservoir, pression d’une conduite, position d’une vanne, ouverture d’un disjoncteur. Ici, une commande falsifiée ne vole pas seulement des données : elle peut arrêter une station, endommager un équipement ou créer un danger immédiat.

Explication de la marmotte

Un système de pilotage d’eau ou d’électricité ressemble à une salle de contrôle qui donne des ordres à des installations réparties sur le terrain. Il sert à voir ce qui se passe et à agir vite lorsqu’un niveau monte, qu’une pompe s’arrête ou qu’une ligne électrique doit être isolée.

→ Lire l’explication complète de la marmotte

SCADA eau et énergie : le compromis disponibilité contre maîtrise

Le compromis central est brutal : maintenir la disponibilité opérationnelle tout en réduisant la capacité d’un tiers à envoyer une commande dangereuse. Dans un réseau bureautique, couper un accès douteux est généralement acceptable. Dans une station de pompage ou un poste électrique, une coupure mal préparée peut masquer une alarme, bloquer une téléconduite ou empêcher une manœuvre de sûreté.

La recommandation est donc de segmenter fortement, d’autoriser peu de flux, et de conserver des modes locaux sûrs même si le système de supervision devient indisponible. Chercher à transposer sans adaptation le modèle informatique classique, avec correctifs rapides et agents de sécurité partout, produit souvent une panne mieux décorée qu’avant. La sécurité ne doit pas devenir le premier équipement à tomber lors d’un incident.

La supervision centralisée doit être séparée du réseau de terrain par une zone démilitarisée, ou DMZ (Demilitarized Zone). Aucun poste bureautique, serveur de messagerie ou accès distant ne doit joindre directement un automate programmable, un relais de protection ou une passerelle de téléconduite. La segmentation réseau constitue ici un contrôle de sécurité et un contrôle de sûreté : elle limite aussi le rayon d’action d’une erreur humaine.

Les flux entre zones doivent être documentés par fonction : supervision vers passerelle, historisation depuis collecteur, maintenance via bastion. Une règle « tout autoriser depuis le SCADA » ne décrit pas une architecture, elle décrit l’abandon de l’architecture avec un masque de sous-réseau.

Les équipements de terrain doivent conserver des logiques locales : arrêt sur surpression, interdiction de marche à sec, seuil thermique, verrouillage électrique et interverrouillage mécanique. Une commande SCADA ne doit jamais être l’unique barrière entre une action numérique et un dommage physique. Cette séparation entre cybersécurité et sûreté fonctionnelle est non négociable.

Modbus, DNP3 et commandes sans identité vérifiable

Modbus et DNP3 (Distributed Network Protocol 3) restent courants dans l’eau et l’énergie parce qu’ils sont interopérables, légers et supportés par des équipements à cycle de vie long. Leur version historique transporte des requêtes qui ne portent ni identité cryptographiquement vérifiable, ni confidentialité, ni protection contre la répétition. Sur Modbus TCP, quiconque atteint le port TCP 502 peut souvent lire ou écrire des registres. La pompe ne demande pas une pièce d’identité avant d’obéir.

Une attaque réaliste ne nécessite donc pas forcément une compromission du serveur de supervision. Un poste de maintenance infecté, une passerelle exposée par erreur, un accès distant mal cloisonné ou un équipement réseau compromis peut suffire à injecter une écriture Modbus. Les effets incluent l’arrêt d’une pompe, la modification d’une consigne, l’ouverture simultanée de vannes incompatibles ou la désactivation d’alarmes.

DNP3 Secure Authentication apporte une authentification des messages pour les implémentations compatibles. Il réduit l’usurpation et certaines relectures, mais ne transforme pas un réseau plat en architecture défendable. Son déploiement dépend des capacités exactes des maîtres, des unités distantes et des relais. Une compatibilité annoncée dans une fiche commerciale doit être validée sur les fonctions réellement utilisées : authentification de commande, gestion des clés, comportement après redémarrage et journalisation des refus.

Pour les protocoles sans sécurité native, la bonne réponse est un confinement de transport : listes de contrôle d’accès, filtrage strict par adresse et port, séparation physique ou logique des segments, et passerelles industrielles placées en frontière de zone. Le chiffrement par tunnel peut protéger un lien intersite, mais ne rend pas Modbus authentifié à l’intérieur d’un segment compromis. Chiffrer un paquet malveillant jusqu’à l’automate reste une livraison express vers le problème.

Les accès de maintenance doivent passer par un bastion administré, avec authentification multifacteur, ou MFA (Multi-Factor Authentication), comptes nominatifs et enregistrement de session lorsque la technologie le permet. Le compte partagé « maintenance », éternel survivant de vingt ans de tableurs, interdit toute attribution fiable des actions. Les principes détaillés dans la gestion des identités s’appliquent, mais les comptes de service et les accès d’urgence doivent être traités comme des exceptions explicites, pas comme des oublis pérennisés.

Exemple de filtrage Modbus sur une passerelle de zone

Le filtrage ne remplace pas l’authentification Modbus. Il réduit néanmoins l’ensemble des machines capables d’envoyer une commande. L’exemple suivant applique une politique restrictive avec nftables sur une passerelle Linux entre une zone de supervision et un segment automate. Il autorise seulement le serveur SCADA 10.42.10.20 à joindre l’automate 10.42.30.15 sur TCP 502.

#!/usr/sbin/nft -f
# Supprime les règles de démonstration existantes : à exécuter uniquement
# sur une passerelle dédiée, après validation de la politique de flux.
flush ruleset

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

    # Autoriser les réponses aux flux TCP déjà établis.
    ct state established,related accept

    # Autoriser Modbus TCP du SCADA vers un automate désigné.
    ip saddr 10.42.10.20 ip daddr 10.42.30.15 tcp dport 502 ct state new accept

    # Journaliser les autres tentatives avant rejet implicite.
    log prefix "SCADA_DROP " flags all counter
  }
}

Cette règle impose que la passerelle soit réellement sur le chemin du trafic. Un pare-feu placé hors chemin ne filtre que son propre désespoir. Il faut aussi interdire le routage latéral entre automates, sauf dépendance opérationnelle documentée, et valider en recette les flux de découverte, de synchronisation horaire et de diagnostic. Les oublier peut dégrader la visibilité ou les horodatages sans déclencher d’alarme immédiate.

Le journal SCADA_DROP doit remonter vers une collecte séparée du réseau de terrain. Une absence d’événement ne prouve pas l’absence d’attaque : elle peut également prouver qu’un équipement a cessé d’envoyer ses journaux, nuance que les tableaux de bord adorent oublier.

Surface d’attaque et conséquences physiques des manœuvres

La surface d’attaque dépasse le protocole industriel. Elle comprend les postes d’ingénierie, les interfaces homme-machine, les serveurs d’historisation, les concentrateurs de téléconduite, les accès fournisseurs, les sauvegardes de configuration et les équipements réseau. Un logiciel d’ingénierie compromis peut modifier la logique d’un automate sans générer une commande anormale côté SCADA.

La détection doit donc combiner plusieurs vues : inventaire passif des actifs, surveillance des flux industriels, journaux d’authentification, alertes sur changement de configuration et mesures physiques indépendantes. Un changement de consigne devient critique lorsqu’il est incohérent avec le niveau, le débit, la pression ou l’état électrique observé. La détection réseau seule voit une écriture ; la télémétrie de procédé indique si cette écriture produit un état dangereux.

Les commandes à effet élevé doivent exiger une validation contextuelle : double action opérateur lorsque l’interface le permet, vérification d’état préalable, limites de consigne côté automate et confirmation du retour terrain. Cette dernière condition compte : une commande acceptée par le réseau ne garantit pas que l’actionneur a bougé. Un capteur défaillant, un mécanisme bloqué ou un câblage incorrect peuvent faire diverger ordre affiché et état réel.

Un arrêt d’urgence, un relais de protection ou un interverrouillage matériel ne doit pas dépendre du réseau de supervision. Le SCADA visualise et coordonne ; il ne remplace pas les protections conçues pour réagir lorsque le logiciel, le réseau ou l’opérateur échoue. Ce mécanisme ne garantit pas non plus l’intégrité des capteurs : une valeur plausible mais falsifiée peut conduire à une décision dangereuse.

NIS2, IEC 62443 et exploitation des secrets

La directive NIS2, directive européenne sur un niveau élevé commun de cybersécurité, renforce les attentes envers les secteurs de l’énergie et de l’eau. Elle impose une démarche de gestion des risques, de continuité, de sécurité de la chaîne d’approvisionnement, de gestion des vulnérabilités et de notification d’incidents selon sa transposition nationale. Elle ne fournit pas une configuration de pare-feu, heureusement : sinon une annexe réglementaire finirait par piloter une vanne.

La série IEC 62443, normes de sécurité des systèmes d’automatisation et de contrôle industriels, offre une grille plus opérationnelle : zones, conduits de communication, niveaux de sécurité, exigences pour les composants et processus de développement. Elle doit guider l’architecture, sans être utilisée comme un tampon « conforme » sur une segmentation inexistante. La page consacrée aux référentiels et organismes aide à situer ces sources sans les confondre avec une recette d’implémentation.

Les certificats, clés de tunnel et comptes d’administration exigent un cycle de vie défini. Une autorité de certification, ou PKI (Public Key Infrastructure), doit délivrer des identités à durée limitée, documenter les responsabilités de renouvellement et conserver les journaux d’émission. La révocation d’un certificat ne coupe pas nécessairement une session déjà établie : les équipements doivent aussi vérifier les statuts à intervalle compatible avec leur disponibilité, ou imposer une reconnexion contrôlée.

Les clés racines et clés de signature doivent être conservées dans un HSM (Hardware Security Module) lorsque l’architecture le justifie, notamment pour une autorité de certification centrale ou une signature de firmware. Un HSM ne sécurise pas un automate vulnérable ; il empêche surtout l’extraction triviale d’une clé, ce qui résiste mieux qu’une promesse marketing imprimée sur fond bleu.

Les sauvegardes doivent inclure configurations d’automates, projets d’ingénierie, images de postes, règles réseau, certificats et procédures de restauration. Elles doivent être chiffrées, testées hors ligne et protégées contre la réécriture par rançongiciel. Restaurer un serveur sans pouvoir recharger la logique validée d’un automate ne constitue pas une reprise : c’est une collection de fichiers qui regardent une usine attendre.

🐝 Ce qui arrive si on s’en passe

Sans cloisonnement ni filtrage, tout hôte qui atteint le port TCP 502 peut aussi interroger l’automate en lecture pure : la fonction Modbus 43 (identification de l’équipement) livre souvent fabricant, modèle et version de firmware, ce qui suffit à choisir une vulnérabilité publiée sans émettre une seule écriture suspecte. La fonction de diagnostic 08, sous-fonction 04 (Force Listen Only Mode), rend un esclave muet sur le lien série : la supervision perd la télémétrie tandis que les sorties restent dans leur dernier état. Sans journaux de flux collectés hors du réseau de terrain, l’exploitant ne peut pas distinguer a posteriori une commande légitime d’une commande injectée ; il ne peut alors pas qualifier l’incident dans les délais de NIS2 (alerte précoce sous 24 heures, notification sous 72 heures).

🦫 Explication de la marmotte 🍫

Un système de supervision reçoit des mesures venant d’installations de terrain : niveau d’eau, pression, température, état d’un interrupteur électrique ou vitesse d’une pompe. Il affiche ces informations aux opérateurs et transmet des ordres, par exemple démarrer une pompe ou ouvrir une vanne.

Le problème est que plusieurs protocoles anciens acceptent des ordres sans vérifier correctement qui les envoie. Si une personne malveillante atteint le bon réseau, elle peut envoyer un ordre qui ressemble à un ordre normal. Le système de terrain peut alors l’exécuter. Une mauvaise commande peut provoquer un débordement, une rupture de service ou endommager un appareil.

La protection commence donc par séparer les réseaux. Seuls les équipements autorisés peuvent communiquer avec les appareils de terrain, selon des règles précises. Les accès de maintenance passent par un point contrôlé, avec une identité personnelle et une seconde preuve de connexion.

Les appareils de terrain doivent aussi garder leurs propres limites de sécurité. Une pompe doit pouvoir s’arrêter si la pression devient dangereuse, même si le serveur de supervision donne un ordre contraire. Les équipes surveillent les changements de configuration, les connexions et les mesures physiques pour repérer une action incohérente. Enfin, elles conservent des copies protégées des programmes et réglages afin de rétablir le fonctionnement après une attaque ou une panne.

À lire aussi

• 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.
• Sécuriser la signalisation ferroviaire connectéeArchitecture de sécurité pour la signalisation et les systèmes de contrôle ferroviaires connectés.

Pages voisines

La citent

• Brouillage et leurrage GNSS, détection, OSNMA et repli du temps
• Bug bounty gouvernemental et immunité pénale
• Le VPN d'entreprise est-il mort ?

Sécuriser un SCADA d’eau et d’énergie

Elle cite

• DMZ industrielle pour protéger le réseau de production
• Sécuriser un SCADA aux protocoles non authentifiés
• Sécuriser une interface HMI industrielle Windows