Lorsqu’un pare-feu se situe à la frontière entre votre réseau IT et votre environnement OT, vous faites confiance à une politique. Un ensemble de règles, écrites par des humains, maintenues au fil du temps, s’exécutant sur un logiciel qui possède un historique de CVE comme tout le reste.
Cette confiance présente un mode de défaillance. Pas le matériel. Pour comprendre pourquoi, il est utile de prendre du recul et d’examiner comment la cybersécurité industrielle a évolué et pourquoi le paysage des menaces a rendu les choix d’architecture plus déterminants que jamais.
Cet article compare les diodes de données et les pare-feu selon les critères qui comptent réellement pour la sécurité OT : comment chaque technologie applique la protection, où chacune présente des faiblesses, et quelle architecture est pertinente selon ce que vous protégez.
Comment fonctionne réellement un pare-feu
Un pare-feu est un moteur de politique. Il inspecte le trafic réseau et prend des décisions basées sur des règles configurées, l’adresse source, le port de destination, le type de protocole, le contenu des paquets. Le trafic qui correspond à une règle d’autorisation passe. Tout le reste est bloqué.
Les pare-feu de nouvelle génération modernes ajoutent des couches supplémentaires : inspection profonde des paquets, filtrage de la couche applicative, prévention des intrusions, flux de renseignement sur les menaces. Pour les environnements OT, les pare-feu industriels étendent cela avec un filtrage sensible aux protocoles pour Modbus, DNP3, OPC-UA et d’autres communications au niveau terrain.
La garantie de sécurité offerte par un pare-feu est la suivante : « le trafic qui correspond à nos règles de comportement malveillant sera bloqué. »
Cette garantie présente trois faiblesses structurelles.
Les règles peuvent être erronées. Une règle mal configurée laisse une faille. Une règle correcte l’année dernière peut ne plus l’être après une modification du réseau. Les ensembles de règles complexes s’accumulent au fil des ans et deviennent difficiles à auditer.
Le canal de retour existe. Un pare-feu permet une communication bidirectionnelle, contrôlée, filtrée, mais bidirectionnelle. Tant qu’un canal de retour existe au niveau du réseau, un attaquant qui trouve un moyen de passer dispose d’un chemin de retour.
Comment fonctionne réellement une diode de données (unidirectionnelle)
Une diode de données impose une communication unidirectionnelle au niveau de la couche physique à l’aide de composants optiques. Un émetteur à fibre optique envoie de la lumière du réseau OT vers le réseau IT. Du côté de la réception, il n’y a pas d’émetteur, physiquement, et non par configuration.
La lumière voyage dans une seule direction. Il n’y a pas de chemin de retour car il n’y a aucun matériel capable d’en créer un.
Il ne s’agit pas d’une règle logicielle. Ce n’est pas une politique qui peut être mal configurée. Ce n’est pas une version de firmware qui nécessite un correctif. La directionnalité est une conséquence de l’architecture physique et cette architecture n’a pas d’historique de CVE.
Les couches logicielles proxy de chaque côté gèrent l’adaptation des protocoles : le proxy côté OT reçoit les données des API, des historiens et des systèmes SCADA, et les transmet via la liaison optique. Le proxy côté IT les reconstruit pour une utilisation en entreprise. La couche optique entre eux ne présente aucune surface d’attaque.
La comparaison
| Diode de données | Pare-feu | |
| Mécanisme d’application | Matériel / physique | Logiciel / politique |
| Flux de données | Strictement unidirectionnel | Bidirectionnel |
| Canal de retour | Physiquement impossible | Existe, filtré |
| Risque de mauvaise configuration | Aucun | Élevé |
| Surface de vulnérabilité Zero-day | Aucune | Firmware + pile logicielle |
| Besoins en correctifs | Minimaux | Réguliers, continus |
| Support des protocoles | Protocoles OT via logiciel proxy | Natif, avec modèles spécifiques OT |
| Support accès distant | Non | Oui |
| Vérifiabilité de la conformité | Physique, déterministe | Basée sur la politique, nécessite un audit |
| Mode de défaillance | Aucune connexion | Dépend du type de défaillance |
Où les pare-feu échouent dans les environnements OT
Les modes de défaillance documentés des pare-feu dans les contextes OT ne sont pas théoriques.
Zero-days dans le dispositif périmétrique. La campagne ArcaneDoor de 2024, attribuée à un acteur étatique par Cisco Talos, a exploité des vulnérabilités dans les dispositifs Cisco ASA et FTD pour accéder aux réseaux gouvernementaux et d’infrastructures critiques. Le pare-feu censé assurer la frontière était lui-même la vulnérabilité. Fortinet FortiOS (CVE-2024-21762) et Ivanti Connect Secure ont également été exploités lors de campagnes documentées en 2024, toutes répertoriées dans le catalogue des vulnérabilités exploitées connues de la CISA.
Mauvaise configuration à grande échelle. Les ensembles de règles de pare-feu dans les environnements industriels s’accumulent au fil des ans. Des règles sont ajoutées pour des besoins opérationnels spécifiques et rarement supprimées. Le résultat est une politique que personne ne comprend pleinement, avec des failles qui ne deviennent visibles qu’après un incident.
Le problème du canal de retour. Un pare-feu permet un trafic bidirectionnel, filtré, mais bidirectionnel. Le problème de fond est que les réseaux IT et OT fonctionnent sur des hypothèses de sécurité fondamentalement différentes. Un attaquant qui compromet un système du côté IT d’un pare-feu dispose d’un chemin réseau existant vers le segment OT. Le pare-feu décide d’autoriser ou de bloquer chaque tentative de connexion. Les failles zero-day, les règles mal configurées ou les identifiants compromis peuvent chacun déverrouiller ce chemin.
Protocoles OT sans authentification. Modbus, DNP3 et Profibus répondent à toute requête semblant valide sur le segment. Un pare-feu peut filtrer par type de protocole, mais il ne peut pas authentifier l’intention d’une requête qui semble légitime. Un attaquant ayant atteint le côté IT de la frontière peut forger des requêtes conformes au protocole qui passeront l’inspection du pare-feu.
Ce que les diodes de données ne peuvent pas faire
L’honnêteté est ici de mise.
Les véritables diodes de données ne supportent pas la communication bidirectionnelle. Les flux de travail nécessitant des flux IT vers OT ne peuvent pas utiliser une architecture strictement unidirectionnelle sans conception supplémentaire. Une architecture de passerelle unidirectionnelle jumelée, utilisant deux diodes de données matérielles sur des chemins asynchrones séparés, répond à ce besoin pour des flux de travail contrôlés spécifiques. Mais cela ajoute de la complexité.
Les diodes de données ne remplacent pas toutes les fonctions d’un pare-feu. Au sein des segments de réseau IT, entre les zones d’entreprise, ou partout où une communication bidirectionnelle est réellement requise, les pare-feu restent l’outil approprié. L’argument n’est pas que les pare-feu sont inutiles, mais que, seuls, ils deviennent le mauvais outil à la frontière IT/OT pour les infrastructures critiques, là où la conséquence d’une défaillance est physique.
Le déploiement initial nécessite davantage de travail de conception. La configuration du proxy de protocole, l’intégration avec les architectures d’historiens et SCADA existantes, ainsi que la planification des flux de trafic nécessitent un investissement initial. Une fois déployée, la maintenance est minimale, mais la phase de conception est cruciale.
L’architecture qui fait sens
La question n’est pas « diode de données ou pare-feu ». C’est « quel outil à quelle frontière ».
Les pare-feu ont leur place dans les réseaux IT, entre les zones d’entreprise, et partout où la communication bidirectionnelle et l’accès à distance sont de véritables exigences opérationnelles. Ils sont flexibles, largement compris et appropriés pour les environnements où la conséquence d’une brèche est une perte de données plutôt qu’une perturbation physique.
À la frontière IT/OT, pour les infrastructures critiques, le calcul change.
Le réseau OT contient des systèmes qui contrôlent des processus physiques. La conséquence d’une brèche n’est plus seulement une perte de données, c’est un processus incontrôlé, un système de sécurité désactivé, une ligne de production arrêtée. Dans ce contexte, une défense basée sur une politique avec un mode de défaillance connu est la mauvaise architecture.
Une diode de données matérielle déployée à la frontière IT/OT permet les flux de données dont l’entreprise a besoin, l’historien OT (historiens de données de processus tels que AVEVA PI System, AspenTech IP.21 ou Honeywell Uniformance) répliquant vers l’extérieur, les alarmes SCADA transmises au SIEM du SOC, les événements de sécurité atteignant les analyses d’entreprise, tout en rendant physiquement impossible un chemin d’attaque entrant.
Un attaquant ayant le contrôle total du réseau d’entreprise ne peut toujours pas atteindre le DCS, le SIS ou l’historien, car il n’existe aucun canal de retour permettant à un protocole d’établir une session. Pour en savoir plus sur la manière dont cette frontière s’intègre dans l’architecture globale du réseau OT.
Conformité et alignement réglementaire
L’IEC 62443, la norme internationale pour la sécurité des systèmes de contrôle industriel, définit les zones et les conduits comme modèle pour l’architecture des réseaux OT. Ses niveaux de sécurité les plus élevés, SL3 et SL4, reconnaissent les passerelles de sécurité unidirectionnelles comme un contrôle conforme pour imposer la séparation des zones. Les pare-feu satisfont aux niveaux de sécurité inférieurs ; les passerelles unidirectionnelles à application matérielle satisfont aux plus élevés.
La norme NERC CIP, applicable aux opérateurs de réseaux électriques en Amérique du Nord, identifie les passerelles unidirectionnelles comme un mécanisme conforme pour franchir les périmètres de sécurité électronique. La norme reconnaît explicitement la différence entre une protection de frontière logicielle et une protection matérielle.
NIS2, désormais transposée dans le droit national des États membres de l’UE, impose des contrôles techniques appropriés aux risques pour les opérateurs de services essentiels. Pour les environnements OT à haut risque, « approprié au risque » signifie déterministe, et non basé sur une politique.
Les cadres convergent : l’application matérielle satisfait à des niveaux de sécurité plus élevés que les approches basées sur des pare-feu pour ces trois référentiels.
Foire aux questions
Quelle est la principale différence entre une diode de données et un pare-feu ?
Un pare-feu filtre le trafic bidirectionnel sur la base de règles logicielles. Une diode de données impose une communication unidirectionnelle au niveau de la couche physique à l’aide d’un matériel optique. La sécurité d’un pare-feu dépend d’une configuration correcte et d’un logiciel à jour. La sécurité d’une diode de données dépend de la physique.
Une diode de données peut-elle remplacer un pare-feu ?
À la frontière IT/OT dans les environnements OT à haute sécurité, oui, une véritable diode de données unidirectionnelle offre une protection plus forte qu’un pare-feu dans le but spécifique d’empêcher l’accès entrant aux systèmes OT. Dans les réseaux IT et partout où une communication bidirectionnelle est requise, les pare-feu restent appropriés. Les deux outils servent des objectifs différents à des frontières différentes.
Les diodes de données sont-elles vulnérables aux failles zero-day ?
Oui, la couche optique matérielle ne présente aucune surface d’attaque logicielle et aucun historique de CVE. Les couches logicielles proxy de chaque côté peuvent théoriquement présenter des vulnérabilités, mais une exploitation dans le logiciel proxy ne peut pas créer de canal de retour à travers le matériel optique. La contrainte physique perdure quel que soit l’état du logiciel.
Que se passe-t-il si une diode de données tombe en panne ?
Le mode de défaillance d’une diode de données est l’absence de connexion ; la liaison s’interrompt, les données cessent de circuler, mais aucun chemin entrant n’est créé. Le mode de défaillance d’un pare-feu peut aller du blocage de tout le trafic à une ouverture totale, selon la configuration. Pour les environnements OT, un comportement de fermeture en cas de défaillance est le choix par défaut le plus sûr.
Les diodes de données supportent-elles les protocoles OT comme Modbus et OPC-UA ?
Oui, via un logiciel proxy de protocole de chaque côté de la liaison optique. Le proxy reçoit le trafic natif du protocole des systèmes OT, le transmet via la liaison matérielle unidirectionnelle et le reconstruit du côté IT. La couche optique est agnostique au protocole, le support dépend de la couche logicielle proxy, pas du matériel.
Quels cadres de conformité reconnaissent les diodes de données ?
L’IEC 62443 SL3/SL4, NERC CIP et NIS2 reconnaissent tous les passerelles unidirectionnelles à application matérielle comme des contrôles conformes pour la protection des frontières OT à haute sécurité. L’IEC 62443 distingue explicitement les niveaux de sécurité atteignables avec des pare-feu par rapport aux passerelles unidirectionnelles.
