OT Français : BRIDGE:BREAK Symptôme Vulnérabilité Réseau

Vingt mille convertisseurs série-IP exposés sur Internet. Vingt-deux failles critiques documentées par Forescout. Et en France, des dizaines d'hôpitaux, de stations de pompage, de sous-stations électriques et d'usines de traitement des eaux qui continuent de tourner derrière des équipements qui n'ont pas vu un firmware depuis cinq ans — parfois dix. BRIDGE:BREAK n'est pas la catastrophe. La catastrophe, c'est qu'on la voyait venir depuis 2019, que le CERT-FR, l'ANSSI et des dizaines de chercheurs ont sonné l'alarme à répétition, et que la réponse opérationnelle sur le terrain est restée, au mieux, anémique. Ce qui s'est passé avec BRIDGE:BREAK est moins un incident de sécurité qu'un révélateur d'un problème structurel profond dans la manière dont la France gère la sécurité de ses infrastructures industrielles. Il est temps de regarder le problème en face.

Les 22 CVE BRIDGE:BREAK : chiffres et réalité de l'exposition française

En mars 2026, les chercheurs de Forescout Research publient leur analyse des convertisseurs série-IP Lantronix et Silex Technology. La conclusion est sans appel : 22 vulnérabilités, dont plusieurs permettant l'exécution de code à distance sans authentification, la récupération de credentials en clair, et dans certains cas la modification permanente du firmware pour implantation d'un implant persistant. Le score CVSS maximum atteint 10.0 sur plusieurs CVE.

Ces équipements sont omniprésents dans les infrastructures industrielles françaises. Les convertisseurs série-IP servent de pont entre les bus de communication industriels historiques — RS-232, RS-485, RS-422 — et les réseaux IP modernes. Ils permettent à des équipements industriels qui n'ont jamais été conçus pour le réseau IP (automates programmables des années 1990, capteurs industriels, contrôleurs de moteurs) de communiquer via Ethernet. En France, selon les estimations de Shodan et les données ANSSI croisées, plusieurs milliers d'équipements Lantronix et Silex sont accessibles directement sur Internet ou via des réseaux VPN d'accès distant insuffisamment segmentés.

Les secteurs concernés en priorité : l'eau (pompage, traitement, distribution), l'énergie (sous-stations de distribution, éolien, photovoltaïque), les transports (signalisation ferroviaire secondaire, éclairage public automatisé), la santé (automatismes hospitaliers, chaînes de stérilisation, laboratoires), et l'industrie manufacturière (SCADA de chaînes de production). Dans chacun de ces secteurs, la compromission d'un convertisseur série-IP peut donner accès à l'automate en aval — et via l'automate, à des processus physiques dont la perturbation a des conséquences directes sur la sécurité des personnes.

Le problème ne vient pas des équipementiers : la vraie cause racine

Quand Forescout publie 22 CVE sur des convertisseurs Lantronix et Silex, la réaction immédiate est d'accabler les constructeurs pour des mots de passe vides par défaut, des clés hardcodées et des protocoles d'administration non chiffrés. C'est facile, et c'est à côté du sujet.

Ces équipements ont été conçus il y a dix ou quinze ans pour un monde radicalement différent. Un convertisseur série-IP Lantronix EDS3000 a été pensé pour faire le pont entre un bus RS-485 d'automate et un réseau industriel isolé, dans une usine où le périmètre physique constituait la principale protection. Il n'a jamais été conçu pour être exposé sur Internet, pour résister à des scans de masse automatisés, ou pour être mis à jour régulièrement via un pipeline de patch management industriel.

Le problème — et c'est là que la responsabilité se situe réellement — c'est que les intégrateurs et les exploitants ont raccordé ces équipements à des VPN d'accès distant, à des passerelles 4G de télémaintenance, à des réseaux d'entreprise avec une route vers Internet "juste pour les mises à jour" ou "juste pour la supervision". Progressivement, sans décision consciente, par accumulation de petites modifications locales qui semblaient toutes innocentes individuellement, l'infrastructure critique française est devenue adressable depuis Varsovie, Shanghai ou Saint-Pétersbourg.

Ce glissement progressif est documenté dans les rapports d'incident de l'ANSSI depuis 2019. Il n'est pas nouveau. Ce qui est nouveau en 2026, c'est que les attaquants ont automatisé la détection et l'exploitation de ces équipements. Les mêmes outils qui scanneraient des serveurs web vulnérables en 2015 scanneraient maintenant des convertisseurs série-IP industriels. Le temps d'exploitation mesuré en laboratoire pour les CVE BRIDGE:BREAK : moins de deux minutes pour un attaquant qui connaît l'équipement.

Ce que BRIDGE:BREAK révèle concrètement du terrain français

Depuis dix-huit mois, les audits industriels font remonter trois constats qui reviennent avec une régularité déprimante dans les rapports finaux.

Constat 1 — Absence quasi-totale d'inventaire OT à jour. La plupart des sites industriels que j'audite ne savent pas, à la référence près, quels convertisseurs, quels automates, quels IHM ils ont en production. L'inventaire existe parfois sur papier — dans des tableurs Excel qui n'ont pas été mis à jour depuis le dernier arrêt technique il y a trois ans. Il n'existe pas sous forme d'une base de données interrogeable en temps réel, pas plus que les équipements réseau IP sont gérés dans une CMDB. Quand le CERT-FR publie une alerte sur un équipement spécifique, les exploitants n'ont souvent pas de moyen rapide de savoir s'ils sont concernés sans faire un tour physique des ateliers ou des locaux techniques.

Constat 2 — Dilution des responsabilités entre automatisme, IT et sous-traitants. Le parc OT est géré par l'automatisme (qui connaît les équipements mais ne pense pas sécurité réseau), la sécurité réseau par la DSI (qui ne connaît pas les équipements industriels), la gestion des accès distants par le sous-traitant de maintenance (qui n'est pas impliqué dans la gouvernance sécurité de l'exploitant). Dans cet entre-deux, personne n'est titulaire du risque. Quand on demande à l'automaticien si les accès distants sont sécurisés, il répond "c'est l'IT". Quand on demande à l'IT, il répond "c'est l'automatisme et le fournisseur". Quand on contacte le fournisseur, il répond que sa responsabilité s'arrête à l'équipement, pas à la configuration réseau.

Constat 3 — Incompréhension structurelle du modèle de menace OT. On pense à la vulnérabilité sur l'automate Siemens S7 critique, on oublie la passerelle poussiéreuse dans l'armoire réseau à côté. On investit dans la sécurisation du protocole Modbus TCP, on oublie le convertisseur série-IP qui traite en clair les communications RS-485 en amont. BRIDGE:BREAK cible précisément cette couche intermédiaire — les équipements de raccordement — qui est systématiquement dans l'angle mort des analyses de risque industrielles.

La moitié des exploitants que j'ai consultés dans les semaines suivant la publication de BRIDGE:BREAK n'avaient pas d'inventaire capable de répondre en moins d'une journée à la question : "Avez-vous des Lantronix EDS3000PS exposés ?" La réponse correcte aurait dû prendre cinq minutes avec un inventaire tenu à jour. Dans la plupart des cas, elle a pris de deux à cinq jours.

La NIS2 n'est pas la réponse suffisante : ce qui manque vraiment

La directive NIS2, transposée en droit français par la loi du [date], a élargi le périmètre des entités concernées et renforcé les obligations de sécurité. Pour les opérateurs de services essentiels et les entités importantes dans les secteurs de l'eau, de l'énergie, des transports et de la santé, les obligations incluent désormais la gestion des risques de la chaîne d'approvisionnement, la déclaration des incidents sous 24 heures, et des mesures de sécurité proportionnées aux risques.

C'est une progression réglementaire bienvenue. Mais transposer NIS2 en "on achète un outil de segmentation réseau et on remplit un registre des risques OT" rate complètement le point. La conformité réglementaire ne remplace pas l'exécution opérationnelle. Ce qui manque dans la grande majorité des environnements industriels français que j'audite, ce n'est pas des textes réglementaires supplémentaires — c'est l'exécution sur trois piliers simples.

Pilier 1 — Un inventaire OT tenu à jour au quotidien. Pas un tableur Excel annuel. Une base de données qui reflète en temps quasi-réel l'état du parc, avec pour chaque équipement : référence exacte, version firmware, localisation physique, réseau(x) de rattachement, accès distants actifs, date du dernier audit de configuration. Les outils existent — Claroty, Dragos, Nozomi Networks, Microsoft Defender for IoT — mais ils nécessitent un investissement initial et un processus de maintien en condition opérationnelle que peu d'exploitants industriels ont structuré.

Pilier 2 — Une gouvernance unique avec un propriétaire du risque identifié par site. Fin de la dilution de responsabilités entre IT, automatisme et sous-traitants. Un poste de RSSI industriel ou de référent cybersécurité OT, avec autorité sur les décisions de sécurité qui concernent le parc industriel, y compris les accès distants des sous-traitants. Ce poste est rare dans les organisations industrielles françaises en dehors des grands comptes. C'est le premier investissement à faire avant même d'acheter des outils.

Pilier 3 — Un processus de patch management OT adapté aux contraintes industrielles. La principale difficulté du patch management OT est que les équipements ne peuvent souvent pas être mis à jour pendant la production — une fenêtre de maintenance de quelques heures par semestre est parfois la seule opportunité. Cette contrainte est réelle et légitime. Elle ne justifie pas l'absence de processus. Elle justifie un processus adapté : inventaire des équipements à patcher, priorisation selon l'exposition et la criticité, planification des fenêtres de maintenance, test en lab avant déploiement. Dans la plupart des sites industriels français, ce processus n'existe pas formellement.

Ce qu'il faut faire cette semaine et ce mois

Pour les RSSI et DSI avec périmètre OT, voici la liste d'actions concrètes immédiatement actionnables.

Cette semaine : lancer un scan passif de votre parc réseau industriel pour identifier les équipements Lantronix et Silex. Un scan Nmap ciblant les ports caractéristiques (2001, 2601, 3001, 10001) sur les VLAN industriels identifie rapidement les instances exposées. Croiser avec votre cartographie réseau pour identifier quels équipements sont joignables depuis des zones non strictement industrielles. Pour les équipements exposés : vérifier si une mise à jour firmware est disponible chez le constructeur, changer immédiatement les credentials par défaut, désactiver les protocoles d'administration non chiffrés (Telnet).

Ce mois : implémenter une règle simple et non négociable — aucun convertisseur série-IP ne doit être joignable depuis une interface ayant un accès Internet direct ou indirect. Si des accès distants de maintenance sont nécessaires, ils doivent passer par un jump server dédié avec MFA, avec logs d'accès conservés au minimum 12 mois. Revoir les contrats de maintenance avec les sous-traitants pour y inclure des exigences de sécurité des accès distants.

Dans les trois mois : lancer un inventaire exhaustif du parc OT avec un outil dédié (ou a minima un processus manuel structuré). Définir un propriétaire du risque OT identifié nominativement. Intégrer les alertes CERT-FR relatives aux systèmes industriels dans un processus de veille avec délai de réponse défini.

Conclusion

BRIDGE:BREAK va générer ses victimes dans les semaines et les mois qui viennent. Les organisations qui passeront au travers ne sont pas celles qui ont les budgets sécurité les plus importants. Ce sont celles qui ont la discipline opérationnelle la plus solide : un inventaire tenu à jour, un propriétaire du risque identifié, des accès distants maîtrisés, et un processus de réponse aux alertes CERT qui ne se mesure pas en jours mais en heures.

Cette discipline se construit maintenant, pas après l'incident. Et elle commence par une décision organisationnelle simple : nommer quelqu'un de responsable de la sécurité OT, lui donner les moyens d'exercer cette responsabilité, et mesurer sa performance sur des indicateurs opérationnels concrets — délai de réponse aux alertes CERT, couverture de l'inventaire OT, taux d'accès distants avec MFA. Rien de cela ne nécessite un budget exceptionnel. Tout cela nécessite une décision.