Les produits SCADAPack x70 de Schneider Electric font l’objet d’un avertissement sur les identifiants, toutes versions confondues
Schneider Electric a révélé une vulnérabilité liée aux identifiants affectant sept familles SCADAPack dans toutes leurs versions, alors même que Secure Lock est conçu pour protéger les fonctions RTU sensibles. Cet avertissement place les produits SCADAPack x70 de Schneider Electric sous surveillance, car les opérateurs ne peuvent pas résoudre le problème à l’aide d’un correctif de firmware classique.
CVE-2026-81861 concerne Secure Lock, un mécanisme de mot de passe hérité utilisé pour restreindre l’accès aux fonctions des unités terminales distantes. Schneider recommande de remplacer ce mécanisme par un contrôle d’accès basé sur les rôles lorsque cela est pris en charge. Les modèles plus anciens nécessitent plutôt des protections réseau.
Cette différence est importante. Le problème central ne consiste pas simplement à savoir si un opérateur a installé la version la plus récente. Il s’agit de déterminer si un contrôleur déployé dépend encore d’une méthode de protection dont les identifiants peuvent être exposés.
Les équipements concernés fonctionnent dans des environnements industriels distribués, notamment dans l’énergie, la fabrication, l’eau et les sites d’infrastructures distantes. Ces contrôleurs restent souvent en service pendant des années, ce qui rend une migration du contrôle d’accès plus complexe qu’une mise à jour d’un logiciel métier ordinaire.
Les produits SCADAPack x70 de Schneider Electric sont affectés dans toutes les versions
Cette portée exceptionnellement large transforme une vulnérabilité produit en problème de découverte des actifs et de configuration.
CISA a publié son avis SCADAPack le 15 septembre 2026. Il identifie CVE-2026-81861 comme une vulnérabilité d’identifiants insuffisamment protégés affectant les unités terminales distantes SCADAPack de Schneider Electric.
Les produits répertoriés sont :
SCADAPack 47x, toutes versions
SCADAPack 47xi, toutes versions
SCADAPack 47xd, toutes versions
SCADAPack 470R, toutes versions
SCADAPack 57x, toutes versions
SCADAPack 3xx, toutes versions
SCADAPack 32, toutes versions
Une unité terminale distante, ou RTU, relie les équipements de terrain aux systèmes qui surveillent et contrôlent des opérations géographiquement distribuées. Une RTU peut collecter des mesures, transmettre des alarmes, exécuter une logique configurée et recevoir des commandes d’une plateforme de supervision.
Schneider a publié sa première notification de sécurité le 8 septembre. L’entreprise a indiqué que l’absence d’application de ses mesures d’atténuation augmente le risque d’accès non autorisé via Secure Lock, pouvant exposer des informations confidentielles de configuration RTU.
L’enregistrement CVE classe le problème comme CWE-522, soit des identifiants insuffisamment protégés. Cette catégorie couvre les informations d’authentification qu’un système stocke ou transmet sans protection adéquate contre leur récupération ou leur utilisation abusive.
La vulnérabilité a reçu un score de base CVSS 4.0 de 5,9, classé de gravité moyenne. Le vecteur décrit une attaque réseau de faible complexité, sans privilèges préalables, avec interaction active de l’utilisateur et exigences d’attaque supplémentaires. Son impact technique évalué correspond à une perte élevée de confidentialité, sans impact direct sur l’intégrité ou la disponibilité dans le score de base.
L’avis de CISA présente un score CVSS v3 de 6,5. Ces chiffres utilisent des versions de notation différentes ; les lecteurs ne doivent donc pas considérer cet écart comme une contradiction. Les deux évaluations décrivent un problème significatif d’exposition d’identifiants plutôt qu’une faille d’exécution de code à distance non authentifiée.
La vulnérabilité ne figurait pas dans le catalogue Known Exploited Vulnerabilities de CISA lors de la publication de l’avis. Les données de décision associées de CISA indiquaient également qu’aucune exploitation n’était connue et classaient l’attaque comme difficilement automatisable.
Ces éléments réduisent l’alarme immédiate, mais n’éliminent pas le risque opérationnel. Un score de base moyen ne tient pas compte de l’architecture de chaque déploiement, de la connectivité distante, de la criticité des processus ou des limites de récupération.
La désignation « toutes versions » exige également une interprétation prudente. Elle signifie que l’enregistrement des produits affectés du fournisseur n’identifie aucune version sûre au sein de ces familles de produits. Elle ne signifie pas que chaque contrôleur installé présente une exposition identique.
L’exposition réelle dépend du mode de contrôle d’accès, du chemin réseau, du modèle d’appareil et des contrôles compensatoires disponibles. Un contrôleur isolé utilisant des contrôles par rôles plus solides présente un risque différent d’un appareil géré à distance utilisant encore Secure Lock.
Cette distinction doit orienter le triage. Les opérateurs doivent identifier les modèles qu’ils possèdent, la méthode de contrôle d’accès utilisée par chaque unité et les systèmes susceptibles d’observer ou d’atteindre son trafic de gestion.
Cela dépasse le simple résultat d’un scanner. Les scanners de vulnérabilités peuvent reconnaître une famille de produits ou une version de firmware, mais ils ne déterminent pas nécessairement si Secure Lock reste actif ou si la RTU se trouve derrière une segmentation efficace.
Secure Lock protégeait le message, mais pas le secret
La faille remet en cause le modèle de confiance de Secure Lock plutôt que les algorithmes cryptographiques cités dans sa conception.
Le chercheur indépendant Abhinav Agarwal a signalé que l’implémentation testée protège les messages Secure Lock à l’aide d’un encapsulage de clés AES-128 et d’un code d’authentification de message HMAC-SHA256. L’encapsulage de clés AES protège le matériel cryptographique, tandis que HMAC vérifie qu’un message n’a pas été modifié sans connaissance d’un secret.
Selon l’analyse technique du chercheur, l’implémentation dérive ces deux protections de constantes intégrées au composant de configuration Windows et au firmware de la RTU. Ses tests ont montré que les clés résultantes étaient identiques entre ces deux composants.
La conséquence est plus précise qu’un contournement d’authentification sans mot de passe. Un attaquant qui capture un échange Secure Lock pertinent peut, selon les informations publiées, récupérer le mot de passe hors ligne. Une récupération hors ligne signifie que l’attaquant analyse le trafic enregistré sans interroger de manière répétée l’appareil cible.
Le chercheur a testé les messages de définition, de modification et de déverrouillage de mot de passe. Il a indiqué que l’échange protégé ne comportait pas d’entrée propre à l’appareil ou à la session, laissant les installations testées dépendantes d’un matériel cryptographique partagé.
Une valeur propre à l’appareil rendrait la clé dérivée d’une unité différente de celle d’une autre unité. Une valeur propre à la session rendrait le matériel capturé moins réutilisable entre des échanges distincts. Le chercheur n’a trouvé aucune de ces deux propriétés dans le chemin testé.
Le mécanisme divulgué crée donc un renversement inconfortable. Secure Lock chiffre et authentifie ses messages, mais la confiance accordée à des secrets partagés intégrés affaiblit ces protections.
Des algorithmes robustes ne peuvent pas compenser une clé qui est, dans les faits, commune à plusieurs installations. Si un adversaire peut dériver les mêmes clés d’encapsulage et d’authentification, l’enveloppe cryptographique ne fournit plus la séparation attendue.
Le mot de passe testé contrôle des fonctions importantes. Selon le chercheur, ces fonctions incluent les écritures de configuration, l’exécution de commandes, les mises à niveau de firmware, les modifications de sécurité et l’accès à certains services de transfert de fichiers ou de terminal.
Toutefois, récupérer un mot de passe n’équivaut pas à contrôler immédiatement une RTU. Un attaquant a encore besoin d’un échange Secure Lock admissible à observer et d’un chemin réseau permettant un accès ultérieur.
Le vecteur CVSS divulgué reflète ces conditions par les mentions « exigences d’attaque présentes » et « interaction utilisateur active ». Un administrateur légitime doit effectuer une action concernée, telle que définir ou utiliser le mot de passe, avant qu’un observateur passif puisse obtenir du trafic exploitable.
L’attaquant doit également avoir une visibilité sur cet échange. Cette visibilité peut découler d’une intrusion réseau préalable, d’un accès à un chemin de communication incorrectement segmenté ou d’une surveillance depuis une autre position au sein du réseau opérationnel.
Le chercheur a explicitement testé une voie présumée de déverrouillage sans mot de passe et a indiqué qu’elle ne fonctionnait pas. Ce résultat limite l’affirmation. CVE-2026-81861 concerne l’exposition d’identifiants et leur utilisation non autorisée ultérieure, et non un contournement universel en un seul paquet.
Ses tests publics couvraient également des artefacts logiciels et de firmware spécifiques. Il a identifié SCADAPack x70 Device DTM version 2.0.18103.4 de RemoteConnect R3.5.5 et une image de firmware 47x particulière.
Un gestionnaire de type d’appareil, ou DTM, est un composant logiciel qui permet à un outil d’ingénierie de configurer un appareil industriel donné et de communiquer avec lui. Dans ce cas, le DTM testé participe au workflow Secure Lock.
La déclaration de produits affectés de Schneider est plus large que les tests directs du chercheur. Le fournisseur répertorie sept familles de produits et toutes les versions, y compris les anciens appareils SCADAPack 3xx et 32.
Cette portée plus large fait autorité pour la planification des mesures correctives, mais la différence doit rester visible. Le chercheur a établi le mécanisme dans des artefacts de test définis, tandis que Schneider a étendu le statut affecté à l’ensemble de son portefeuille de produits.
Les opérateurs doivent donc éviter deux erreurs opposées. Ils ne doivent pas limiter les mesures correctives à la version exacte testée, mais ils ne doivent pas non plus affirmer que chaque appareil a été démontré indépendamment dans toutes les configurations possibles.
La migration vers le RBAC remplace le correctif de firmware manquant
La réponse principale de Schneider modifie l’architecture du contrôle d’accès au lieu de corriger Secure Lock sur place.
Pour les appareils SCADAPack 47x et 470R pris en charge, Schneider recommande de mettre en œuvre un contrôle d’accès basé sur les rôles, ou RBAC. Le RBAC attribue des autorisations à des rôles et utilisateurs définis plutôt que de s’appuyer sur un mot de passe de verrouillage partagé par l’appareil.
L’entreprise renvoie les administrateurs vers sa documentation de sécurité, notamment les sections consacrées aux recommandations pour administrateurs et au fonctionnement du RBAC. Son guide de cybersécurité plus général décrit la gestion des comptes, le zonage réseau, les pare-feu, les communications sécurisées et les pratiques d’audit pour les déploiements SCADAPack.
Schneider décrit Secure Lock comme une fonctionnalité héritée conservée pour la rétrocompatibilité. L’entreprise recommande le RBAC comme mécanisme de contrôle d’accès privilégié pour les produits compatibles.
Cette recommandation signifie que la réponse immédiate n’est pas « installer la version X ». Schneider n’a pas identifié de version de firmware corrigée qui conserverait Secure Lock tout en éliminant CVE-2026-81861.
Pour les contrôleurs récents pris en charge, la migration exige davantage que le choix d’un mot de passe plus robuste. Les administrateurs doivent passer d’un workflow de verrouillage partagé à des utilisateurs nommés, des rôles attribués et des autorisations gérées.
Cette transition peut améliorer la responsabilisation. Un mot de passe partagé indique à un opérateur si quelqu’un connaissait le secret, mais n’identifie pas de manière fiable la personne ayant effectué une action. Les comptes nommés et les rôles peuvent restreindre les privilèges et renforcer l’audit.
La migration introduit également du travail. Les opérateurs doivent définir les rôles administratifs, provisionner les comptes, tester l’accès depuis les outils d’ingénierie, mettre à jour les procédures et confirmer que la maintenance d’urgence reste possible.
Les organisations utilisant des annuaires centralisés peuvent devoir valider les dépendances entre l’environnement RTU et l’infrastructure d’identité. Elles doivent également tenir compte du comportement des sites distants lorsque les services d’annuaire ou les connexions longue distance sont indisponibles.
Les modifications des systèmes de contrôle industriel exigent des tests minutieux, car une erreur d’authentification peut bloquer l’accès d’ingénierie autorisé. Une migration précipitée pourrait créer un problème opérationnel tout en réduisant le risque cyber.
Pour cette raison, les opérateurs doivent documenter les chemins d’accès actuels avant de les modifier. Le relevé doit inclure les postes de travail d’ingénierie, les connexions de support à distance, les comptes de service, les procédures de récupération locales et les options d’accès physique.
Les anciennes familles SCADAPack 57x, 3xx et 32 constituent un cas plus difficile. Les recommandations d’atténuation de Schneider mettent l’accent sur la segmentation réseau et le pare-feu RTU, car ces équipements ne disposent pas de la même voie de migration vers le RBAC.
La segmentation réseau sépare les systèmes en zones contrôlées et restreint les communications entre elles. Un pare-feu RTU applique des règles qui limitent les hôtes, protocoles ou services pouvant atteindre le contrôleur.
Ces contrôles ne corrigent pas le mécanisme de protection des identifiants. Ils réduisent le nombre de systèmes capables d’observer un échange Secure Lock ou de réutiliser des identifiants exposés.
Les opérateurs doivent limiter le trafic d’administration aux stations d’ingénierie approuvées et aux chemins d’administration de confiance. Ils doivent également supprimer toute exposition directe à Internet et empêcher les postes ordinaires du réseau d’entreprise d’atteindre les services de gestion des RTU.
Les recommandations de CISA sur la réduction de l’exposition préconisent d’identifier les actifs industriels accessibles depuis Internet, de supprimer les expositions inutiles, d’utiliser des hôtes de rebond surveillés et d’ajouter une authentification multifacteur lorsque cela est possible.
Un hôte de rebond est un intermédiaire contrôlé que les administrateurs doivent utiliser avant d’atteindre des équipements sensibles. Il peut centraliser la journalisation, l’authentification et les restrictions d’accès à un endroit où les anciens équipements de terrain ne disposent pas de ces capacités.
Les réseaux privés virtuels peuvent protéger le trafic traversant une infrastructure non fiable. Toutefois, un VPN ne doit pas créer un accès sans restriction depuis un ordinateur portable distant vers l’ensemble d’un réseau de contrôle.
Une approche plus restrictive est préférable. Les utilisateurs distants doivent s’authentifier auprès d’un service d’accès surveillé, n’atteindre que les actifs nécessaires et ne recevoir que les autorisations requises pour une tâche définie.
La surveillance du trafic compte également, car l’exposition des identifiants dépend de l’observation d’un échange. Les opérateurs doivent enquêter sur tout trafic DNP3 Virtual Terminal inattendu, toute activité de déverrouillage inhabituelle, tout accès répété à la configuration ou toute nouvelle communication entre les zones d’ingénierie et les sites distants.
DNP3 est un protocole largement utilisé pour les communications entre les centres de contrôle et les équipements de terrain. Sa fonction Virtual Terminal fournit un canal que les applications peuvent utiliser pour des interactions orientées équipement, notamment les messages Secure Lock décrits par le chercheur.
Modifier uniquement un mot de passe Secure Lock ne constitue pas une réponse durable. Si le mot de passe de remplacement transite ensuite par le même mécanisme vulnérable, un observateur compétent peut récupérer le nouveau secret à partir d’un autre échange capturé.
L’objectif pratique consiste à cesser de s’appuyer sur le flux de travail concerné. Lorsqu’une migration est impossible, les opérateurs doivent rendre l’observation et la réutilisation nettement plus difficiles grâce à des contrôles réseau superposés.
Un score moyen peut masquer une remédiation OT complexe
L’impact direct limité de la vulnérabilité ne mesure pas les efforts nécessaires pour sécuriser des déploiements de terrain à longue durée de vie.
CVE-2026-81861 ne présente pas le profil d’une compromission immédiate d’un système de sécurité. Son vecteur de base n’attribue aucun impact direct sur l’intégrité ou la disponibilité, et aucune preuve publique ne faisait état d’une exploitation active au moment de la divulgation.
Ces limites sont importantes. Les équipes de sécurité ne doivent pas décrire ce problème comme une manipulation avérée des processus, une perturbation automatique de l’usine ou une exécution de code non authentifiée.
L’impact identifié est une perte de confidentialité impliquant des informations d’authentification. Un accès non autorisé au RTU peut en découler, mais l’exploitation dépend toujours des conditions réseau et de l’activité des administrateurs.
Dans le même temps, une étiquette de sévérité moyenne peut sous-estimer la complexité opérationnelle. Les produits Schneider Electric SCADAPack x70 sont conçus pour la surveillance et le contrôle à distance, souvent sur des sites disposant de peu de personnel local.
Une application d’entreprise peut souvent être corrigée de manière centralisée. Les contrôleurs de terrain peuvent nécessiter un accès planifié, une approbation opérationnelle, des tests spécialisés et une coordination avec les équipes responsables des processus physiques.
La liste des équipements concernés couvre également du matériel actuel et ancien. Certaines unités peuvent adopter le RBAC. D’autres doivent s’appuyer sur la segmentation, le filtrage et une architecture d’accès distant sécurisée.
Cela divise le programme de remédiation en différentes filières. Un seul ticket de vulnérabilité ne peut pas représenter fidèlement le travail requis pour chaque modèle et chaque site.
La première filière couvre les déploiements 47x et 470R compatibles. Les équipes doivent confirmer l’utilisation de Secure Lock, concevoir les rôles RBAC, tester les flux de travail administratifs et retirer le mode historique.
La seconde couvre les déploiements 57x, 3xx et 32. Les équipes doivent valider les règles de pare-feu, réduire les services accessibles, isoler les chemins de gestion et surveiller le trafic, car le remplacement privilégié du contrôle d’accès n’est pas disponible.
Une troisième filière peut s’avérer nécessaire pour les équipements qui ne peuvent pas respecter le seuil de risque résiduel de l’organisation. Ces unités peuvent exiger une planification de remplacement, notamment lorsque leur position sur le réseau ne peut pas être suffisamment restreinte.
La qualité de l’inventaire des actifs devient déterminante. Une organisation ne peut ni migrer ni isoler des contrôleurs qu’elle n’a pas identifiés, et les libellés produits dans les dossiers de maintenance peuvent ne pas correspondre à la nomenclature utilisée dans l’avis.
Les équipes doivent rapprocher les bases de données d’ingénierie, les observations réseau, les dossiers d’approvisionnement et la documentation des sites. Elles doivent consigner le modèle exact, le firmware, le mode d’accès configuré, le chemin de communication et le responsable désigné.
La configuration compte autant que la version. Puisque toutes les versions répertoriées sont concernées, un scanner ne tenant compte que des versions peut produire un vaste ensemble de résultats sans identifier les systèmes qui utilisent réellement Secure Lock.
Cela ne rend pas l’analyse inutile. Cela signifie que les résultats du scanner doivent déclencher une enquête plutôt que la conclure.
La preuve de concept publique mérite également un traitement équilibré. Le chercheur a publié un vérificateur expurgé qui démontre la dérivation de clés sans divulguer les secrets complets récupérés.
Cette retenue réduit le risque d’utilisation abusive immédiate, mais les détails techniques publics modifient néanmoins le calendrier défensif. D’autres chercheurs ou attaquants peuvent examiner la méthode et tenter de la reproduire indépendamment.
Le statut « aucune exploitation connue » de CISA est un instantané, non une prédiction. Les défenseurs doivent surveiller les modifications du dossier CVE, du catalogue de CISA, de la notification de Schneider et des renseignements sur les menaces concernant les réseaux industriels.
L’absence de correctif modifie également la notion de clôture. Une plateforme de gestion des vulnérabilités peut continuer à signaler toutes les versions concernées même après qu’un opérateur a mis en œuvre le RBAC ou une segmentation efficace.
Les organisations ont besoin d’exceptions étayées par des preuves ou de registres de contrôles compensatoires. Sans cela, les tableaux de bord de sécurité peuvent afficher des constats non résolus sans distinguer les déploiements Secure Lock exposés des systèmes migrés.
Ces registres ne doivent pas devenir des substituts administratifs permanents. Chaque exception nécessite un responsable de contrôle défini, une méthode de validation, une date de révision et un déclencheur de remplacement.
Ce problème illustre aussi pourquoi le CVSS ne peut pas être la seule méthode de priorisation en technologie opérationnelle. Le CVSS mesure la sévérité intrinsèque d’une vulnérabilité, tandis que les opérateurs doivent ajouter la criticité du processus, l’exposition réseau, la capacité de reprise et les conséquences physiques potentielles.
Une vulnérabilité moyenne sur un contrôleur de test isolé peut être classée sous une faille critique d’une application métier. La même vulnérabilité sur un RTU administré à distance avec une segmentation faible peut exiger une action plus rapide.
Les équipes de gestion des risques doivent donc combiner le score publié avec des preuves propres au site. Parmi les questions utiles : le trafic d’administration traverse-t-il des réseaux partagés, une capture de paquets est-elle plausible et l’équipement contrôle-t-il un processus critique ?
Elles doivent également déterminer si un attaquant ayant récupéré le mot de passe pourrait atteindre l’interface de déverrouillage normale. La divulgation d’identifiants ne crée de valeur que lorsque ceux-ci peuvent être utilisés.
Trois signaux indiqueront si le risque est maîtrisé
La phase suivante dépendra des preuves de migration, des mises à jour du fournisseur et des signes indiquant que les attaquants passent de la recherche à l’usage opérationnel.
Le premier signal est le rythme auquel les opérateurs identifient et abandonnent Secure Lock. Les organisations concernées doivent pouvoir indiquer combien d’équipements utilisent le RBAC, combien dépendent du verrouillage historique et combien d’unités anciennes s’appuient sur des contrôles compensatoires.
Une hausse du taux de migration vers le RBAC conforterait la stratégie d’atténuation de Schneider. Une incertitude persistante concernant les modes d’accès déployés affaiblirait la confiance, même en l’absence d’attaques publiques.
L’indicateur opérationnel le plus utile n’est pas simplement le nombre d’actifs concernés. Il s’agit du pourcentage disposant d’un état de contrôle d’accès vérifié et d’une remédiation testée.
Pour les équipements compatibles RBAC, la vérification doit confirmer que Secure Lock ne constitue plus la frontière de sécurité effective. Elle doit également montrer que les rôles administratifs fonctionnent correctement et que les procédures d’urgence restent disponibles.
Pour les unités anciennes, la vérification doit tester les chemins réseau autorisés. Une politique de segmentation écrite a une valeur limitée si un poste de travail ordinaire peut encore se connecter aux services de gestion du RTU.
Le deuxième signal est l’émission par Schneider de recommandations révisées, de détails techniques supplémentaires ou d’une mise à jour produit. La réponse initiale repose sur une atténuation architecturale plutôt que sur une implémentation Secure Lock corrigée.
Une modification ultérieure du firmware ou des outils changerait le tableau de la remédiation. Elle pourrait fournir une aide à la migration, supprimer le comportement vulnérable, améliorer la journalisation ou réduire les configurations concernées.
À l’inverse, le maintien de la dépendance aux contrôles compensatoires confirmerait que les opérateurs doivent traiter ce problème comme un enjeu architectural à long terme. Cela accentuerait la pression en faveur du remplacement des équipements anciens ne pouvant pas prendre en charge des contrôles d’accès plus robustes.
Les équipes de sécurité doivent surveiller la notification du fournisseur plutôt que de se fier uniquement aux résumés d’avis recopiés. Les avis produits peuvent évoluer à mesure que les tests s’étendent ou que les mesures d’atténuation deviennent plus précises.
Le troisième signal est l’apparition de preuves d’exploitation ou de reproduction plus large. Au moment de la divulgation, CISA n’avait signalé aucune exploitation connue, et CVE-2026-81861 était absente du catalogue Known Exploited Vulnerabilities.
Cette situation changerait sensiblement si les défenseurs détectaient une activité de récupération d’identifiants, des tentatives de déverrouillage non autorisées ou des outils automatisant l’analyse du trafic. Son ajout au catalogue constituerait un autre signal fort d’escalade.
Une reproduction publique ne prouverait pas à elle seule des attaques contre des installations en exploitation. Elle réduirait néanmoins l’incertitude technique à laquelle fait face un adversaire et augmenterait la valeur du trafic Secure Lock capturé.
Les opérateurs doivent dès maintenant conserver les journaux et la télémétrie réseau pertinents. Attendre un rapport d’exploitation pourrait laisser les enquêteurs sans les données historiques nécessaires pour déterminer si des échanges sensibles ont déjà été observés.
La surveillance doit se concentrer sur l’activité d’administration, et pas seulement sur les alarmes de processus. Les accès à la configuration, les changements de mots de passe, les opérations de déverrouillage, les nouveaux hôtes d’ingénierie et les sessions distantes inhabituelles peuvent révéler un problème de contrôle d’accès avant toute modification des opérations physiques.
Les produits Schneider Electric SCADAPack x70 restent des plateformes de terrain utiles, et l’avis n’établit pas que des sites déployés ont été compromis. Il établit toutefois que chaque version répertoriée exige un examen au niveau de la configuration.
La question immédiate pour les propriétaires d’actifs est concrète : l’organisation peut-elle prouver quels contrôleurs utilisent encore Secure Lock, qui peut observer leur trafic de gestion et quel contrôle se trouve désormais entre un mot de passe exposé et l’accès au RTU ?
Commencez par cet inventaire, puis migrez les équipements compatibles vers le RBAC. Isolez les modèles qui ne peuvent pas migrer, testez leurs règles de pare-feu et surveillez chaque chemin d’administration approuvé. La vulnérabilité ne peut pas être gérée par une simple vérification des versions.
