Sécurité OPC-UA et Modbus : protection des protocoles industriels grâce à l’isolation en ligne

Pourquoi OPC-UA et Modbus sont-ils vulnérables aux cyberattaques ?

Modbus n’a pas d’authentification ou de cryptage natif. Chaque commande est transmise en clair et n’importe quel appareil du réseau peut envoyer des instructions à n’importe quel automate. OPC-UA offre des fonctions de sécurité telles que l’authentification par certificat et le cryptage des messages, mais celles-ci sont rarement mises en œuvre correctement dans les environnements de production. Les deux protocoles fonctionnent sur des équipements qui ne peuvent pas installer d’agents de sécurité, ce qui fait de l’isolation en ligne la méthode la plus pratique pour les protéger.

Chaque usine qui connecte des automates, des IHM ou des systèmes SCADA à un réseau d’entreprise ouvre une voie que les attaquants peuvent suivre depuis un courriel d’hameçonnage jusqu’à une chaîne de production. OPC-UA et Modbus sont les deux protocoles industriels les plus utilisés, et tous deux ont été conçus à une époque où la cybersécurité n’était pas une préoccupation. Les appareils qui utilisent ces protocoles fonctionnent pendant des décennies, ne peuvent pas être corrigés facilement et se trouvent sur des réseaux qui sont de plus en plus connectés à l’infrastructure informatique. Ce guide explique les lacunes de chaque protocole, la manière dont les attaquants exploitent le fossé entre les technologies de l’information et les technologies de l’information, et comment l’isolation en ligne protège la production sans nécessiter l’installation d’un logiciel sur un appareil industriel.

Ce qu’est l’OPC-UA et les lacunes de sa sécurité

OPC-UA (Open Platform Communications Unified Architecture) est la norme d’interopérabilité dans le domaine de l’automatisation industrielle. Il remplace l’ancien OPC Classic, dépendant de Windows, par un cadre indépendant de la plate-forme qui modélise les données comme des objets dans un espace d’adressage. Deux modèles de communication dominent : le modèle client-serveur, dans lequel une interface homme-machine se connecte à un automate pour lire ou écrire des données, et le modèle publication-souscription (PubSub), dans lequel un éditeur transmet des données à plusieurs abonnés simultanément.

Le protocole a été conçu avec une sécurité intégrée. L’authentification au niveau de l’application utilise des certificats X.509. La sécurité au niveau du transport signe et chiffre les messages à l’aide d’AES et de RSA. L’authentification des utilisateurs prend en charge les jetons, Kerberos et les certificats. Les listes de contrôle d’accès déterminent les actions qu’un utilisateur peut effectuer sur des nœuds spécifiques.

Cela semble solide sur le papier. Dans la pratique, trois problèmes viennent l’ébranler.

Tout d’abord, la spécification s’étend sur 14 parties et est extraordinairement complexe. Elle est mise en œuvre différemment selon les fournisseurs et les incohérences entre les mises en œuvre créent des failles exploitables. L’Office fédéral allemand pour la sécurité de l’information (BSI) a analysé la version 1.04 d’OPC-UA et a constaté que le paramètre « SecurityPolicy : None », prévu pour les tests, est souvent laissé actif en production pour éviter les problèmes de compatibilité ou les surcoûts de performance.

Deuxièmement, la spécification n’impose pas la force du mot de passe. Les attaques brutales contre les comptes d’utilisateurs restent viables dans les environnements où les informations d’identification par défaut ou faibles persistent.

Troisièmement, la complexité de la pile elle-même génère des vulnérabilités. Entre 2022 et 2026, les équipes de recherche de Claroty et Kaspersky ont documenté des failles critiques dans les implémentations OPC-UA des principaux fournisseurs. Il s’agit notamment d’attaques par déni de service au moyen de chaînes de certificats mal formées et de l’inondation de morceaux, de la corruption de la mémoire au moyen d’un traitement UTF-8 mal formé et de l’épuisement des ressources dû à un nombre excessif de demandes de canaux sécurisés. Chaque vulnérabilité renforce la même conclusion : la sécurité native ne fonctionne que lorsque l’implémentation est parfaite et la configuration stricte. Dans une usine dotée d’un micrologiciel hérité et d’une expertise limitée en matière de sécurité informatique, cette hypothèse est rarement valable.

Pourquoi Modbus n’a jamais été conçu pour être sécurisé

Modbus est le protocole industriel le plus ancien et le plus largement déployé. Sa popularité tient à sa simplicité : le protocole lit et écrit des registres (valeurs de 16 bits) et des bobines (valeurs de 1 bit). Rien de plus. Cette simplicité est également sa plus grande faiblesse.

Le protocole existe en trois variantes principales. Modbus RTU communique sur des connexions série (RS-485 ou RS-232) en utilisant des ID d’esclaves. Modbus ASCII est une variante série moins efficace qui utilise des caractères lisibles. Modbus TCP/IP enveloppe les trames Modbus dans des paquets TCP sur le port 502 et est la variante la plus couramment exposée aux attaques basées sur le réseau.

Aucune de ces variantes n’inclut une quelconque forme de sécurité. Aucune authentification ne permet de vérifier si une commande provient d’un système SCADA autorisé ou de l’ordinateur portable d’un pirate. Aucun cryptage ne protège les données en transit, de sorte que les valeurs de processus et les commandes de contrôle voyagent en clair. Les pirates peuvent abuser des codes de fonction standard pour écrire des registres, modifier des points de consigne, arrêter des moteurs ou ouvrir des vannes. Et comme Modbus n’a pas de suivi de session ou d’horodatage, les commandes légitimes peuvent être enregistrées et rejouées à volonté.

En 2018, l’Organisation Modbus a introduit Modbus/TCP Security, qui enveloppe le trafic dans un tunnel TLS pour une authentification et un cryptage mutuels. L’adoption en 2026 reste minime. De nombreux PLC et RTU fonctionnent sur des microcontrôleurs 8 bits avec des kilo-octets de mémoire, physiquement incapables de gérer les opérations cryptographiques TLS. Le temps de latence ajouté par TLS est inacceptable dans les processus en temps réel où les millisecondes comptent. Et la gestion de milliers de certificats numériques dans une usine sans connectivité internet fiable est un défi logistique que la plupart des équipes d’OT ne sont pas en mesure de relever.

Résultat : Les appareils Modbus vendus aujourd’hui utilisent toujours par défaut la variante non cryptée pour des raisons de rétrocompatibilité.

Comment les attaquants exploitent le pont IT-OT

Le cheminement de l’attaque est cohérent d’un incident à l’autre. Elle commence dans le réseau informatique, pas dans l’usine.

Un attaquant obtient un accès initial par le biais de l’hameçonnage, du vol d’informations d’identification ou d’un système public vulnérable. Ensuite, il se déplace latéralement dans l’environnement informatique jusqu’à ce qu’il atteigne un système qui fait le lien entre l’informatique et les technologies de l’information. Il peut s’agir d’un poste de travail d’ingénieur avec deux connexions réseau, d’un pare-feu mal configuré ou d’un VPN de fournisseur qui accorde un large accès au réseau de production. Une fois dans le segment OT, l’absence d’authentification dans Modbus et la mauvaise configuration fréquente d’OPC-UA facilitent la manipulation du protocole.

Les données de l’industrie confirment cette tendance. Dragos a indiqué que plus de 75 % des incidents liés aux technologies de l’information trouvent leur origine dans le réseau informatique, le déplacement latéral étant la principale technique utilisée. Le temps de séjour moyen dans les environnements OT, c’est-à-dire la période pendant laquelle un attaquant n’est pas détecté, est d’environ 42 jours. Cela donne aux adversaires des semaines pour cartographier les processus, identifier les contrôleurs critiques et planifier leur attaque.

L’Europe est devenue une cible privilégiée pour les attaques à motivation opérationnelle. Des groupes comme ELECTRUM ont mené des opérations destructrices contre des infrastructures énergétiques en Ukraine et en Pologne, ciblant des systèmes de chauffage et d’énergie renouvelable. Les compagnies des eaux de plusieurs pays européens ont signalé des intrusions par le biais d’interfaces homme-machine exposées à l’internet et utilisant des identifiants par défaut ou des exploits Modbus connus. Le passage de l’espionnage à la perturbation active signifie que les conséquences d’une intrusion dans le secteur des technologies de l’information ne se limitent plus au vol de données. Elles s’étendent aux dommages physiques, aux pertes de production et à la sécurité publique.

Pour comprendre comment ces attaques fonctionnent dans la pratique, consultez notre guide sur la convergence IT-OT, qui présente trois scénarios spécifiques et les contrôles qui permettent d’arrêter chacun d’entre eux.

Les approches actuelles et leurs lacunes

La plupart des organisations s’appuient sur une ou plusieurs de ces méthodes pour protéger les réseaux industriels. Chacune d’entre elles s’attaque à une partie du problème.

La lacune est évidente. La segmentation VLAN et les pare-feu fonctionnent au niveau du réseau, mais ne peuvent pas mettre en œuvre des politiques par appareil. Les outils de surveillance OT offrent une visibilité mais pas de prévention. Les diodes de données sont trop restrictives pour les environnements qui nécessitent une communication bidirectionnelle. Les serveurs de saut concentrent les risques au lieu de distribuer le contrôle.

Ce qui manque, c’est une approche qui combine la prévention avec une granularité par appareil, qui fonctionne sans agents sur le point final et qui s’intègre dans une architecture de sécurité plus large plutôt que d’être isolée. Pour comprendre pourquoi la segmentation du réseau ne suffira pas en 2026, le guide en lien couvre l’évolution des VLAN vers l’isolation basée sur l’identité.

Comment l’isolation en ligne protège sans agents

L’isolation en ligne adopte une approche fondamentalement différente. Au lieu d’essayer d’identifier le trafic malveillant dans un flux de communications autorisées, elle part d’une confiance nulle : rien ne passe à moins d’être explicitement autorisé.

Le matériel NIAC (Network Isolation Access Controller) de Jimber se situe physiquement entre l’appareil OT et le commutateur réseau. Il ne nécessite aucun logiciel sur l’automate, l’IHM ou le capteur. L’appareil inspecte et contrôle tout le trafic qui le traverse sur la base de règles d’autorisation explicites. Un automate qui doit communiquer avec un serveur MES spécifique bénéficie d’une politique autorisant exactement ce chemin. Toutes les autres communications sont bloquées par défaut.

Imaginez un système d’écluses sur un canal. Le trafic ne passe que par des canaux définis, dans des directions définies, vers des destinations définies. Tout le reste se heurte à une porte fermée.

Le NIAC identifie les dispositifs grâce à l’empreinte du trafic basée sur l’adresse MAC, les modèles de communication et les signatures d’inspection approfondie des paquets. Il apprend le comportement normal en mode surveillance avant de passer à l’application. Cette approche progressive signifie que la production n’est jamais interrompue pendant le déploiement. Un atelier de production typique d’un marché intermédiaire comprenant 20 à 50 appareils critiques peut être entièrement couvert en quelques jours, et non en quelques mois.

Comme NIAC fait partie de la plateforme SASE unifiée de Jimber, la même console qui gère le ZTNA pour les employés de bureau et les politiques SWG pour le trafic web, gère également les politiques d’isolation pour les appareils de l’usine. La sécurité informatique et la sécurité opérationnelle sont réunies en un seul endroit. Il ne s’agit pas d’un produit de sécurité OT autonome, mais d’une extension de l’architecture Zero Trust qui protège déjà votre environnement informatique.

Pour les environnements de fabrication en particulier, le guide associé couvre en détail les modèles de déploiement pour les API, les IHM et les lignes de production.

IEC 62443 et NIS2 : les attentes en matière de conformité

Deux cadres réglementaires déterminent la manière dont les fabricants européens doivent aborder la sécurité des protocoles industriels.

La norme CEI 62443 définit un modèle de zone et de conduit pour la sécurité de l’automatisation industrielle. Les actifs sont regroupés en zones de sécurité et toutes les communications entre les zones passent par des conduits contrôlés. Bien qu’il ne soit pas légalement obligatoire en Belgique, le cadre CyberFundamentals (CyFun) fait référence aux principes de la norme IEC 62443, et les fabricants de secteurs réglementés tels que l’industrie pharmaceutique, l’industrie alimentaire et l’industrie énergétique l’utilisent couramment comme référence.

Le NIS2 est juridiquement contraignant. La transposition belge exige des entités essentielles qu’elles mettent en œuvre des mesures techniques proportionnées pour la gestion des risques, qu’elles signalent les incidents importants à la BCC dans les 24 heures et qu’elles acceptent la responsabilité du conseil d’administration en cas de non-conformité. Le cadre CyFun traduit ces obligations en contrôles concrets.

Plusieurs commandes CyFun sont directement liées à la protection offerte par l’isolation en ligne :

Les entités essentielles doivent soumettre leur première auto-évaluation CyFun au niveau Basique ou Important d’ici avril 2026. Pour de nombreuses sociétés de production, le déploiement d’un pont IT-OT est le moyen le plus rapide de répondre aux exigences de segmentation et de contrôle d’accès sans repenser le réseau existant. Le guide des vérifications de la posture des appareils couvre la manière dont la vérification de la posture s’articule avec les contrôles CyFun supplémentaires pour les terminaux gérés.

L’enregistrement centralisé de Jimber couvre la piste d’audit NIS2 pour l’accès OT. Chaque tentative de connexion, chaque décision politique, chaque communication bloquée est enregistrée dans la même console que celle qui gère les événements de sécurité informatique. Lorsque les auditeurs demandent des preuves que vos contrôles de microsegmentation s’étendent aux appareils industriels, vous pouvez le démontrer à partir d’une seule interface.

Questions fréquemment posées

Pouvez-vous sécuriser Modbus sans remplacer les automates ?

Oui, l’isolation en ligne fonctionne au niveau du réseau, entre l’automate et le commutateur. L’automate n’a pas besoin d’un nouveau firmware, d’un nouveau logiciel ou d’une quelconque modification. L’appliance NIAC applique les règles de communication de manière externe, de sorte que l’automate continue à fonctionner exactement comme avant. Seul le trafic qu’il peut envoyer et recevoir change.

L’isolation en ligne ajoute-t-elle un temps de latence au trafic de production ?

Le temps de latence ajouté par le matériel NIAC se mesure en microsecondes et non en millisecondes. Pour la grande majorité des processus industriels, y compris ceux qui utilisent Modbus RTU/TCP et OPC-UA, cette latence est indétectable. Les processus en temps réel dont les exigences sont inférieures à la milliseconde doivent être testés au cours de la phase de surveillance avant que l’application ne soit activée.

En quoi l’isolation en ligne diffère-t-elle d’un pare-feu ?

Un pare-feu inspecte le trafic qui le traverse et tente d’identifier les schémas malveillants. Il nécessite des ensembles de règles complexes, introduit un temps de latence mesurable lors de l’inspection approfondie des paquets et échoue à l’ouverture ou à la fermeture en fonction de la configuration. L’isolation en ligne part d’une position d’interdiction par défaut. Aucun trafic ne passe à moins qu’une règle d’autorisation spécifique n’existe. Il fonctionne par appareil plutôt que par segment, et ne nécessite pas d’ensembles de règles qui s’étoffent avec chaque nouvelle application ou protocole.

Quels sont les protocoles industriels pris en charge par l’isolation en ligne ?

NIAC fonctionne au niveau du réseau et son modèle d’application est agnostique en termes de protocole. Il contrôle quels appareils peuvent communiquer avec quelles destinations, que le trafic utilise Modbus TCP, OPC-UA, BACnet, PROFINET, EtherNet/IP ou des protocoles propriétaires. Les politiques spécifiques aux protocoles peuvent être superposées à l’isolation au niveau du réseau.

Ai-je besoin d’une surveillance OT ET d’une isolation en ligne ?

Ils ont des objectifs différents. Les outils de surveillance OT tels que Claroty, Nozomi ou Dragos permettent de voir ce qui se passe sur le réseau et de détecter les anomalies. L’isolation en ligne empêche les communications non autorisées de se produire. La surveillance vous indique que quelque chose d’inhabituel s’est produit. L’isolation garantit qu’elle ne peut pas atteindre un appareil critique. La posture la plus forte combine les deux : la prévention par l’isolation, la détection par la surveillance.

Comment cela s’intègre-t-il dans une architecture SASE plus large ?

NIAC est un composant de la plateforme SASE de Jimber. La même console de gestion qui gère ZTNA, SWG, FWaaS et SD-WAN gère également les politiques NIAC. Cela signifie que les équipes informatiques n’ont pas besoin d’un outil séparé, d’une formation séparée ou d’un rapport séparé pour la sécurité OT. Les appareils d’usine apparaissent aux côtés des appareils de bureau dans un seul moteur de politique, avec une journalisation unifiée pour la conformité.

Vous êtes prêt à étendre la confiance zéro à l’usine sans agents, sans temps d’arrêt et sans reconfiguration du réseau ? Réservez une démonstration et découvrez comment NIAC s’adapte à votre environnement de production.