Test d'intrusion OT sur la supervision d'un réseau d'eau potable
Un exploitant d'eau potable voulait savoir ce qu'un attaquant pouvait réellement atteindre sur sa supervision. Sans interruption de production, sans arrêt d'exploitation.

[ Le contexte ]
L'exploitant assure la production et la distribution d'eau potable pour une agglomération de taille moyenne et plusieurs communes rurales rattachées. Le réseau compte 12 sites télégérés : un champ captant, une station de traitement, quatre réservoirs de tête et de distribution, six postes de relèvement. L'ensemble remonte vers un SCADA centralisé installé au siège technique, doublé d'un report d'alarmes vers des postes d'astreinte joignables 24 heures sur 24. Les fonctions pilotées à distance touchent directement la qualité du service : démarrage et arrêt des pompes, gestion des niveaux de réservoir, régulation de la chloration.
L'installation a été modernisée par vagues successives sur une quinzaine d'années. Les liaisons radio historiques cohabitent avec des routeurs 4G posés plus récemment sur les sites les plus isolés, et l'intégrateur qui maintient les automates dispose d'un accès distant permanent pour les interventions de dépannage. Le service technique avait déjà fait réaliser un audit documentaire de son architecture, mais aucun test offensif n'avait jamais été conduit sur le périmètre. La qualification de l'exploitant comme entité soumise à NIS2 a rendu cette vérification nécessaire, avec une exigence claire posée dès le premier échange : la distribution d'eau ne devait à aucun moment être mise en cause.
La problématique
L'exploitant ne cherchait pas une liste de vulnérabilités théoriques. Il voulait une réponse à une question précise : depuis l'extérieur du réseau technique, jusqu'où peut-on aller, et qu'est-ce qu'on peut atteindre une fois arrivé ? Trois portes d'entrée étaient soupçonnées sans avoir jamais été éprouvées : l'accès distant de l'intégrateur, les liaisons de télégestion vers les sites isolés, et les postes d'astreinte utilisés hors des locaux. La difficulté tenait à la nature de l'installation. Un test d'intrusion classique s'autorise l'écriture, le redémarrage, la saturation. Sur un automate de chloration en service, aucune de ces actions n'est acceptable.
La contrainte a été posée avant la méthode : aucun ordre écrit sur les équipements en production, aucun test de disponibilité sur les automates en service. Tout ce qui relevait de l'action offensive devait être démontré ailleurs.
Compte VPN partagé pour l'accès distant de l'intégrateur
Télégestion radio en clair, sans authentification des trames
Postes d'astreinte connectés au SCADA depuis des sessions bureautiques
L'intervention
Sans interruption de production, sans arrêt d'exploitation : la mission a été construite autour de cette contrainte plutôt qu'autour du scénario offensif. Tout ce qui impliquait une écriture, un redémarrage ou une manipulation d'automate a été rejoué sur un banc de préproduction monté avec le matériel et les firmwares de l'exploitant. Sur l'installation réelle, l'équipe s'est limitée à la progression et à l'observation, pendant des fenêtres nocturnes fixées avec le service d'astreinte. Les équipes d'exploitation ont suivi chaque étape.
Définition écrite du périmètre testable, de la liste des actions interdites et des équipements exclus. Désignation d'un point de contact d'astreinte joignable pendant chaque fenêtre de test, et d'une procédure d'arrêt immédiat activable par l'exploitant sans justification. Validation du calendrier des fenêtres nocturnes en fonction des créneaux de remplissage des réservoirs.
Observation passive du trafic réseau, aucune injection sur le réseau de production. Inventaire des actifs OT : automates, IHM, stations de supervision, équipements réseau, accès distants. Relevé des protocoles de télégestion utilisés site par site, identification des versions de firmware et des services exposés, reconstitution des flux réels entre le SCADA et les 12 sites.
Montage d'un banc reprenant un automate de pompage et un automate de chloration identiques à ceux du parc, mêmes versions de firmware, même configuration réseau. Les tests intrusifs ont été exécutés uniquement sur ce banc : écriture de registres, envoi d'ordres de commande, rejeu de trames de télégestion, tentative d'arrêt de CPU. Chaque effet obtenu a été filmé et documenté.
Test des trois chemins d'accès soupçonnés en conditions d'exploitation réelles : VPN de l'intégrateur, liaison radio d'un réservoir isolé, poste d'astreinte connecté depuis l'extérieur. Progression jusqu'au réseau de supervision et jusqu'aux automates, arrêt systématique à la lecture. Aucun ordre écrit sur les équipements en production, la démonstration de l'effet renvoyant au banc.
Rédaction du rapport avec les chemins d'attaque reproduits étape par étape, les schémas de flux et le segmentation en zones et conduits. Chaque constat porte son niveau de risque, l'effort estimé et le responsable identifié. Plan de remédiation priorisé sur trois horizons : immédiat, 6 mois, 18 mois. Une séance de validation avec les équipes, puis une synthèse de décision.

[ Les résultats ]
Trois chemins d'accès complets démontrés jusqu'à la supervision, dont un depuis un poste d'astreinte hors site.
Cartographie des flux des 12 sites télégérés : mesures et commande désormais distinguées, plus de chemin commun.
Accès intégrateur repris : comptes nominatifs, second facteur, créneaux et journalisation ; poste d'astreinte séparé de la bureautique.
27 constats priorisés en trois horizons ; rapport, schémas et configurations restent exploitables en interne.
Nous voulions savoir ce qui était réellement atteignable sur notre supervision, pas recevoir une liste théorique de plus. Le banc de préproduction a levé notre principale réticence : aucun ordre n'a été envoyé sur les automates en service, et nos agents d'astreinte ont suivi chaque fenêtre de test. Les trois chemins démontrés ont été présentés à notre direction avec l'effort de correction en face, ce qui nous a permis d'arbitrer sans discuter dans le vide.





