I prodotti Schneider Electric SCADAPack x70 affrontano un avviso sulle credenziali valido per tutte le versioni
Schneider Electric ha divulgato una vulnerabilità delle credenziali che interessa sette famiglie SCADAPack in tutte le versioni, nonostante Secure Lock sia progettato per proteggere funzioni RTU sensibili. L'avviso pone i prodotti Schneider Electric SCADAPack x70 sotto esame perché gli operatori non possono risolvere il problema con una tradizionale patch firmware.
CVE-2026-81861 riguarda Secure Lock, un meccanismo di password legacy usato per limitare l'accesso alle funzioni delle unità terminali remote. Schneider raccomanda di sostituire tale meccanismo con il controllo degli accessi basato sui ruoli ove supportato. I modelli meno recenti richiedono invece protezioni di rete.
Questa differenza è importante. Il problema centrale non è semplicemente se un operatore abbia installato la release più recente. È se un controller distribuito dipenda ancora da un metodo di protezione le cui credenziali possono essere esposte.
Le apparecchiature interessate operano in ambienti industriali distribuiti, inclusi siti dell'energia, della produzione, dell'acqua e delle infrastrutture remote. Questi controller rimangono spesso in servizio per anni, rendendo una migrazione del controllo degli accessi più complessa dell'aggiornamento di un normale software aziendale.
I prodotti Schneider Electric SCADAPack x70 sono interessati in tutte le versioni
L'ambito insolitamente ampio trasforma una vulnerabilità di prodotto in un problema di inventario degli asset e configurazione.
CISA ha pubblicato il suo avviso su SCADAPack il 15 settembre 2026. Identifica CVE-2026-81861 come una vulnerabilità dovuta a credenziali protette in modo insufficiente che interessa le unità terminali remote Schneider Electric SCADAPack.
I prodotti elencati sono:
SCADAPack 47x, tutte le versioni
SCADAPack 47xi, tutte le versioni
SCADAPack 47xd, tutte le versioni
SCADAPack 470R, tutte le versioni
SCADAPack 57x, tutte le versioni
SCADAPack 3xx, tutte le versioni
SCADAPack 32, tutte le versioni
Un'unità terminale remota, o RTU, collega le apparecchiature sul campo con i sistemi che monitorano e controllano operazioni distribuite geograficamente. Un RTU può raccogliere misurazioni, inoltrare allarmi, eseguire logiche configurate e ricevere comandi da una piattaforma di supervisione.
Schneider ha pubblicato la sua prima notifica di sicurezza l'8 settembre. L'azienda ha dichiarato che il mancato impiego delle mitigazioni aumenta il rischio di accesso non autorizzato tramite Secure Lock, con una potenziale esposizione di informazioni riservate sulla configurazione RTU.
Il record CVE classifica il problema come CWE-522, ovvero credenziali protette in modo insufficiente. Questa categoria comprende informazioni di autenticazione che un sistema archivia o trasmette senza una protezione adeguata contro il recupero o l'uso improprio.
Alla vulnerabilità è stato assegnato un punteggio base CVSS 4.0 di 5,9, classificato come gravità media. Il vettore descrive un attacco di rete a bassa complessità, senza privilegi precedenti, con interazione attiva dell'utente e requisiti di attacco aggiuntivi. Il suo impatto tecnico stimato è un'elevata perdita di riservatezza, senza impatto diretto su integrità o disponibilità nel punteggio base.
L'avviso di CISA presenta un punteggio CVSS v3 di 6,5. Questi valori utilizzano versioni di punteggio differenti, pertanto i lettori non dovrebbero considerare la differenza una contraddizione. Entrambe le valutazioni descrivono un problema significativo di esposizione delle credenziali, anziché una vulnerabilità di esecuzione remota di codice non autenticata.
La vulnerabilità non era elencata nel catalogo Known Exploited Vulnerabilities di CISA quando è apparso l'avviso. I dati decisionali associati di CISA riportavano inoltre nessuno sfruttamento noto e classificavano l'attacco come non facilmente automatizzabile.
Questi dettagli riducono l'allarme immediato, ma non eliminano il rischio operativo. Un punteggio base medio non tiene conto dell'architettura di ogni distribuzione, della connettività remota, della criticità dei processi o dei limiti di ripristino.
La designazione “tutte le versioni” richiede inoltre un'interpretazione attenta. Significa che il record dei prodotti interessati del fornitore non identifica una release sicura all'interno di queste famiglie di prodotti. Non significa che ogni controller installato presenti un'esposizione identica.
L'esposizione effettiva dipende dalla modalità di controllo degli accessi, dal percorso di rete, dal modello del dispositivo e dai controlli compensativi disponibili. Un controller isolato che usa controlli basati sui ruoli più solidi presenta un rischio diverso rispetto a un dispositivo gestito da remoto che utilizza ancora Secure Lock.
Questa distinzione dovrebbe guidare il triage. Gli operatori devono identificare i modelli di cui dispongono, il metodo di controllo degli accessi usato da ciascuna unità e i sistemi che possono osservare o raggiungere il relativo traffico di gestione.
Si tratta di qualcosa di più ampio di un rilevamento da scanner. Gli scanner di vulnerabilità possono riconoscere una famiglia di prodotti o una versione firmware, ma potrebbero non stabilire se Secure Lock rimanga attivo o se l'RTU si trovi dietro una segmentazione efficace.
Secure Lock proteggeva il messaggio, ma non il segreto
La vulnerabilità mette in discussione il modello di fiducia di Secure Lock, non gli algoritmi crittografici citati nel suo progetto.
Il ricercatore indipendente Abhinav Agarwal ha riferito che l'implementazione testata protegge i messaggi Secure Lock con key wrapping AES-128 e un codice di autenticazione dei messaggi HMAC-SHA256. Il key wrapping AES protegge il materiale crittografico delle chiavi, mentre HMAC verifica che un messaggio non sia stato alterato senza conoscere un segreto.
Secondo l'analisi tecnica del ricercatore, l'implementazione deriva entrambe le protezioni da costanti incorporate nel componente di configurazione Windows e nel firmware RTU. I suoi test hanno rilevato che le chiavi risultanti erano identiche tra questi due componenti.
La conseguenza è più specifica di un bypass dell'autenticazione senza password. Un attaccante che intercetti un rilevante scambio Secure Lock può, secondo quanto riportato, recuperare la password offline. Il recupero offline significa che l'attaccante analizza il traffico registrato senza interrogare ripetutamente il dispositivo bersaglio.
Il ricercatore ha testato messaggi di impostazione della password, modifica della password e sblocco. Ha riferito che lo scambio protetto non disponeva di un input per dispositivo o per sessione, lasciando le installazioni testate dipendenti da materiale crittografico condiviso.
Un valore per dispositivo renderebbe la chiave derivata di un'unità diversa da quella di un'altra unità. Un valore per sessione renderebbe il materiale catturato meno riutilizzabile tra scambi distinti. Il ricercatore non ha rilevato nessuna delle due proprietà nel percorso testato.
Il meccanismo divulgato crea quindi un'inversione scomoda. Secure Lock cifra e autentica i suoi messaggi, ma la fiducia riposta in segreti incorporati e condivisi indebolisce tali protezioni.
Algoritmi solidi non possono compensare una chiave che è di fatto comune a più installazioni. Se un avversario può derivare le stesse chiavi di wrapping e autenticazione, l'involucro crittografico non offre più la separazione prevista.
La password testata controlla funzioni importanti. Il ricercatore afferma che queste funzioni includono scritture di configurazione, esecuzione di comandi, aggiornamenti firmware, modifiche alla sicurezza e accesso a determinati servizi di trasferimento file o terminale.
Tuttavia, recuperare una password non equivale a controllare immediatamente un RTU. Un attaccante necessita comunque di uno scambio Secure Lock idoneo da osservare e di un percorso di rete per l'accesso successivo.
Il vettore CVSS divulgato riflette tali condizioni mediante “requisiti di attacco presenti” e “interazione utente attiva”. Un amministratore legittimo deve compiere un'azione interessata, come impostare o usare la password, prima che un osservatore passivo possa ottenere traffico utile.
L'attaccante necessita inoltre di visibilità su tale scambio. Questa visibilità potrebbe derivare da una precedente intrusione di rete, dall'accesso a un percorso di comunicazione segmentato in modo improprio o dal monitoraggio da un'altra posizione all'interno della rete operativa.
Il ricercatore ha testato esplicitamente un sospetto percorso di sblocco senza password e ha riferito che non funzionava. Questo risultato limita l'affermazione. CVE-2026-81861 riguarda l'esposizione delle credenziali e il successivo uso non autorizzato, non un bypass universale con un singolo pacchetto.
I suoi test pubblici hanno inoltre riguardato specifici artefatti software e firmware. Ha identificato SCADAPack x70 Device DTM versione 2.0.18103.4 da RemoteConnect R3.5.5 e una particolare immagine firmware 47x.
Un device type manager, o DTM, è un componente software che consente a uno strumento di ingegneria di configurare e comunicare con uno specifico dispositivo industriale. In questo caso, il DTM testato partecipa al flusso di lavoro Secure Lock.
La dichiarazione di Schneider sui prodotti interessati è più ampia dei test diretti del ricercatore. Il fornitore elenca sette famiglie di prodotti e tutte le versioni, inclusi i dispositivi SCADAPack 3xx e 32 meno recenti.
Questo ambito più ampio è autorevole per la pianificazione della correzione, ma la differenza dovrebbe rimanere visibile. Il ricercatore ha dimostrato il meccanismo in artefatti di test definiti, mentre Schneider ha esteso lo stato di prodotto interessato a tutto il proprio portafoglio.
Gli operatori dovrebbero quindi evitare due errori opposti. Non dovrebbero restringere la correzione alla build esatta testata, ma non dovrebbero nemmeno affermare che ogni dispositivo sia stato dimostrato indipendentemente in ogni possibile configurazione.
La migrazione a RBAC sostituisce la correzione firmware mancante
La risposta principale di Schneider modifica l'architettura del controllo degli accessi anziché riparare Secure Lock in loco.
Per i dispositivi SCADAPack 47x e 470R supportati, Schneider raccomanda di implementare il controllo degli accessi basato sui ruoli, o RBAC. RBAC assegna autorizzazioni a ruoli e utenti definiti, invece di affidarsi a una password di blocco condivisa del dispositivo.
L'azienda indirizza gli amministratori alla propria documentazione di sicurezza, incluse le sezioni dedicate alla guida per gli amministratori e al funzionamento di RBAC. La sua più ampia guida alla cybersecurity descrive gestione degli account, zonizzazione di rete, firewall, comunicazioni sicure e pratiche di audit per le distribuzioni SCADAPack.
Schneider definisce Secure Lock come funzionalità legacy mantenuta per la compatibilità con le versioni precedenti. Raccomanda RBAC quale meccanismo di controllo degli accessi preferito per i prodotti compatibili.
Questa indicazione significa che la risposta immediata non è “installare la versione X”. Schneider non ha identificato una release firmware corretta che preservi Secure Lock eliminando al contempo CVE-2026-81861.
Per i controller più recenti supportati, la migrazione richiede più della scelta di una password più robusta. Gli amministratori devono passare da un flusso di blocco condiviso a utenti nominativi, ruoli assegnati e autorizzazioni gestite.
Questa transizione può migliorare la responsabilizzazione. Una password condivisa indica a un operatore se qualcuno conosceva il segreto, ma non identifica in modo affidabile chi abbia eseguito un'azione. Account nominativi e ruoli possono restringere i privilegi e rafforzare l'audit.
La migrazione introduce anche lavoro aggiuntivo. Gli operatori devono definire ruoli amministrativi, predisporre gli account, testare l'accesso dagli strumenti di ingegneria, aggiornare le procedure e confermare che la manutenzione di emergenza rimanga possibile.
Le organizzazioni che utilizzano directory centralizzate potrebbero dover convalidare le dipendenze tra l'ambiente RTU e l'infrastruttura delle identità. Devono inoltre considerare il comportamento dei siti remoti quando i servizi di directory o le connessioni geografiche non sono disponibili.
Le modifiche ai sistemi di controllo industriale richiedono test accurati perché un errore di autenticazione può bloccare l'accesso autorizzato per le attività di ingegneria. Una migrazione affrettata potrebbe creare un problema operativo pur riducendo il rischio informatico.
Per questo motivo, gli operatori dovrebbero documentare gli attuali percorsi di accesso prima di modificarli. Il registro dovrebbe includere workstation di ingegneria, connessioni di supporto remoto, account di servizio, procedure di ripristino locali e opzioni di accesso fisico.
Le famiglie meno recenti SCADAPack 57x, 3xx e 32 rappresentano un caso più complesso. Le indicazioni di mitigazione di Schneider enfatizzano la segmentazione della rete e il firewall RTU, poiché questi dispositivi non offrono lo stesso percorso di migrazione a RBAC.
La segmentazione della rete separa i sistemi in zone controllate e limita le comunicazioni tra di esse. Un firewall RTU applica regole che limitano gli host, i protocolli o i servizi che possono raggiungere il controller.
Questi controlli non correggono il meccanismo di protezione delle credenziali. Riducono il numero di sistemi in grado di osservare uno scambio Secure Lock o riutilizzare credenziali esposte.
Gli operatori dovrebbero limitare il traffico di gestione alle stazioni di engineering autorizzate e ai percorsi di amministrazione attendibili. Dovrebbero inoltre eliminare l'esposizione diretta a internet e impedire agli endpoint aziendali ordinari di raggiungere i servizi di gestione RTU.
Le indicazioni di CISA sull'esposizione raccomandano di identificare gli asset industriali accessibili da internet, rimuovere le esposizioni non necessarie, utilizzare jump host monitorati e aggiungere l'autenticazione a più fattori ove possibile.
Un jump host è un intermediario controllato che gli amministratori devono utilizzare prima di raggiungere dispositivi sensibili. Può concentrare registrazione degli eventi, autenticazione e restrizioni di accesso in un punto in cui le apparecchiature di campo meno recenti non dispongono di tali capacità.
Le reti private virtuali possono proteggere il traffico che attraversa infrastrutture non attendibili. Tuttavia, una VPN non dovrebbe creare accesso senza restrizioni da un laptop remoto a un'intera rete di controllo.
L'approccio più circoscritto è preferibile. Gli utenti remoti dovrebbero autenticarsi a un servizio di accesso monitorato, raggiungere solo gli asset necessari e ricevere esclusivamente le autorizzazioni richieste per un'attività definita.
Anche il monitoraggio del traffico è importante, poiché l'esposizione delle credenziali dipende dall'osservazione di uno scambio. Gli operatori dovrebbero indagare sul traffico DNP3 Virtual Terminal inatteso, su insolite attività di sblocco, su accessi ripetuti alla configurazione o su nuove comunicazioni tra zone di engineering e siti remoti.
DNP3 è un protocollo ampiamente utilizzato per la comunicazione tra centri di controllo e dispositivi di campo. La sua funzione Virtual Terminal fornisce un canale che le applicazioni possono usare per interazioni orientate al dispositivo, inclusi i messaggi Secure Lock descritti dal ricercatore.
Cambiare soltanto una password Secure Lock non è una risposta duratura. Se la password sostitutiva transita in seguito attraverso lo stesso meccanismo vulnerabile, un osservatore competente può recuperare il nuovo segreto da un altro scambio acquisito.
L'obiettivo pratico è smettere di fare affidamento sul flusso di lavoro interessato. Dove la migrazione non è disponibile, gli operatori devono rendere l'osservazione e il riutilizzo sensibilmente più difficili attraverso controlli di rete stratificati.
Un punteggio medio può nascondere una difficile correzione OT
Il limitato impatto diretto della vulnerabilità non misura lo sforzo necessario per proteggere implementazioni di campo di lunga durata.
CVE-2026-81861 non presenta il profilo di una compromissione immediata di un sistema di sicurezza. Il suo vettore base non assegna alcun impatto diretto su integrità o disponibilità, e al momento della divulgazione non esistevano prove pubbliche di sfruttamento attivo.
Questi limiti sono importanti. I team di sicurezza non dovrebbero descrivere il problema come una manipolazione comprovata del processo, un'interruzione automatica dell'impianto o l'esecuzione di codice senza autenticazione.
L'impatto identificato è una perdita di riservatezza che riguarda informazioni di autenticazione. Può seguire un accesso RTU non autorizzato, ma lo sfruttamento dipende comunque dalle condizioni di rete e dall'attività degli amministratori.
Al tempo stesso, un'etichetta di gravità media può sottostimare la complessità operativa. Schneider Electric SCADAPack x70 Products è progettato per il monitoraggio e il controllo remoti, spesso in siti con personale locale limitato.
Un'applicazione aziendale può spesso essere corretta centralmente. I controller di campo possono richiedere accesso programmato, approvazione operativa, test specialistici e coordinamento con i team responsabili dei processi fisici.
L'elenco dei prodotti interessati comprende inoltre apparecchiature attuali e legacy. Alcune unità possono adottare RBAC. Altre devono dipendere da segmentazione, filtraggio e un'architettura di accesso remoto sicuro.
Questo divide il programma di correzione in percorsi differenti. Un singolo ticket di vulnerabilità non può rappresentare accuratamente il lavoro necessario per ogni modello e sito.
Il primo percorso riguarda le implementazioni compatibili 47x e 470R. I team devono confermare l'uso di Secure Lock, progettare ruoli RBAC, testare i flussi di lavoro amministrativi e dismettere la modalità legacy.
Il secondo riguarda le implementazioni 57x, 3xx e 32. I team devono convalidare le regole del firewall, ridurre i servizi raggiungibili, isolare i percorsi di gestione e monitorare il traffico perché il sostituto preferito per il controllo degli accessi non è disponibile.
Potrebbe essere necessario un terzo percorso per i dispositivi che non possono soddisfare la soglia di rischio residuo dell'organizzazione. Tali unità potrebbero richiedere una pianificazione della sostituzione, soprattutto quando la loro posizione in rete non può essere limitata a sufficienza.
La qualità dell'inventario degli asset diventa decisiva. Un'organizzazione non può migrare o isolare controller che non ha identificato, e le etichette dei prodotti nei registri di manutenzione potrebbero non corrispondere alla denominazione utilizzata nell'avviso.
I team dovrebbero riconciliare database di engineering, osservazioni di rete, registri di approvvigionamento e documentazione del sito. Dovrebbero registrare il modello esatto, il firmware, la modalità di accesso configurata, il percorso di comunicazione e il proprietario responsabile.
La configurazione conta quanto la versione. Poiché tutte le versioni elencate sono interessate, uno scanner basato esclusivamente sulla versione può produrre un ampio insieme di risultati senza identificare quali sistemi utilizzino effettivamente Secure Lock.
Questo non rende inutile la scansione. Significa che l'output dello scanner dovrebbe avviare un'indagine anziché completarla.
Anche la proof-of-concept pubblica merita un trattamento equilibrato. Il ricercatore ha rilasciato un verificatore sanitizzato che dimostra la derivazione delle chiavi senza pubblicare i segreti completi recuperati.
Questa cautela riduce l'abuso immediato, ma i dettagli tecnici pubblici modificano comunque la tempistica difensiva. Altri ricercatori o aggressori possono esaminare il metodo e tentare una riproduzione indipendente.
Lo stato di CISA “nessuno sfruttamento noto” è un'istantanea, non una previsione. I difensori dovrebbero monitorare le modifiche al record CVE, al catalogo CISA, alla notifica di Schneider e all'intelligence sulle minacce relativa alle reti industriali.
L'assenza di una patch modifica anche il significato della chiusura. Una piattaforma di gestione delle vulnerabilità può continuare a segnalare ogni versione interessata anche dopo che un operatore ha implementato RBAC o una segmentazione efficace.
Le organizzazioni necessitano di eccezioni basate su evidenze o di registri dei controlli compensativi. Altrimenti, i dashboard di sicurezza potrebbero mostrare rilievi irrisolti senza distinguere le implementazioni Secure Lock esposte dai sistemi migrati.
Questi registri non dovrebbero diventare sostituti burocratici permanenti. Ogni eccezione richiede un proprietario del controllo definito, un metodo di convalida, una data di revisione e un criterio di sostituzione.
Il problema illustra inoltre perché CVSS non può essere l'unico metodo di prioritizzazione nella tecnologia operativa. CVSS misura la gravità intrinseca della vulnerabilità, mentre gli operatori devono aggiungere criticità del processo, esposizione della rete, capacità di recupero e potenziali conseguenze fisiche.
Una vulnerabilità di gravità media su un controller di test isolato può avere priorità inferiore rispetto a una falla critica in un'applicazione aziendale. La stessa vulnerabilità su un RTU amministrato da remoto con segmentazione debole può richiedere un'azione più rapida.
I team di gestione del rischio dovrebbero quindi combinare il punteggio pubblicato con evidenze specifiche del sito. Domande utili includono se il traffico di gestione attraversi reti condivise, se l'acquisizione dei pacchetti sia plausibile e se il dispositivo controlli un processo critico.
Dovrebbero inoltre chiedersi se un aggressore che recuperasse la password potrebbe raggiungere la normale interfaccia di sblocco. La divulgazione delle credenziali crea valore soltanto quando tali credenziali possono essere utilizzate.
Tre segnali indicheranno se il rischio è contenuto
La prossima fase dipende dalle evidenze di migrazione, dagli aggiornamenti del fornitore e dai segnali che gli aggressori stanno passando dalla ricerca all'uso operativo.
Il primo segnale è la velocità con cui gli operatori identificano e dismettono Secure Lock. Le organizzazioni interessate dovrebbero poter riferire quanti dispositivi utilizzano RBAC, quanti dipendono dal blocco legacy e quante unità meno recenti fanno affidamento su controlli compensativi.
Un tasso crescente di migrazione a RBAC sosterrebbe la strategia di mitigazione di Schneider. Un'incertezza persistente sulle modalità di accesso implementate indebolirebbe la fiducia, anche se non emergessero pubblicamente attacchi.
La metrica operativa più utile non è semplicemente il numero di asset interessati. È la percentuale con uno stato di controllo degli accessi verificato e una correzione testata.
Per i dispositivi compatibili con RBAC, la verifica dovrebbe confermare che Secure Lock non sia più il confine di sicurezza effettivo. Dovrebbe inoltre dimostrare che i ruoli amministrativi funzionano correttamente e che le procedure di emergenza restano disponibili.
Per le unità legacy, la verifica dovrebbe testare i percorsi di rete consentiti. Una politica di segmentazione scritta ha valore limitato se una normale workstation può ancora connettersi ai servizi di gestione dell'RTU.
Il secondo segnale è se Schneider emetta indicazioni riviste, dettagli tecnici ampliati o un aggiornamento del prodotto. La risposta iniziale si basa su una mitigazione architetturale anziché su un'implementazione Secure Lock corretta.
Un successivo cambiamento di firmware o strumenti modificherebbe il quadro della correzione. Potrebbe fornire un aiuto alla migrazione, rimuovere il comportamento vulnerabile, migliorare la registrazione degli eventi o restringere le configurazioni interessate.
Al contrario, il continuo affidamento a controlli compensativi confermerebbe che gli operatori devono trattare il problema come una questione architetturale a lungo termine. Ciò aumenterebbe la pressione per sostituire i dispositivi legacy che non possono supportare controlli di accesso più robusti.
I team di sicurezza dovrebbero monitorare la notifica del fornitore anziché affidarsi soltanto a riassunti dell'avviso copiati altrove. Gli avvisi sui prodotti possono cambiare con l'espansione dei test o con una maggiore precisione delle misure di mitigazione.
Il terzo segnale è l'evidenza di sfruttamento o di riproduzione più ampia. Al momento della divulgazione, CISA non segnalava alcuno sfruttamento noto e CVE-2026-81861 era assente dal catalogo Known Exploited Vulnerabilities.
Questa situazione cambierebbe sostanzialmente se i difensori rilevassero attività di recupero delle credenziali, tentativi di sblocco non autorizzati o strumenti che automatizzano l'analisi del traffico. L'inclusione nel catalogo fornirebbe un ulteriore forte segnale di escalation.
La sola riproduzione pubblica non dimostrerebbe attacchi contro strutture operative. Ridurrebbe comunque l'incertezza tecnica per un avversario e aumenterebbe il valore del traffico Secure Lock acquisito.
Gli operatori dovrebbero conservare fin da ora i log pertinenti e la telemetria di rete. Attendere un rapporto di sfruttamento potrebbe lasciare gli investigatori senza i dati storici necessari per determinare se scambi sensibili siano stati osservati in precedenza.
Il monitoraggio dovrebbe concentrarsi sull'attività di amministrazione, non solo sugli allarmi di processo. Accessi alla configurazione, modifiche alle password, operazioni di sblocco, nuovi host di engineering e sessioni remote insolite possono rivelare un problema di controllo degli accessi prima che cambino le operazioni fisiche.
Schneider Electric SCADAPack x70 Products restano piattaforme di campo utili e l'avviso non stabilisce che i siti implementati siano stati compromessi. Stabilisce tuttavia che ogni versione elencata richiede una revisione a livello di configurazione.
La domanda immediata per i proprietari degli asset è concreta: l'organizzazione può dimostrare quali controller utilizzano ancora Secure Lock, chi può osservare il loro traffico di gestione e quale controllo si frappone ora tra una password esposta e l'accesso all'RTU?
Partite da quell'inventario, quindi migrate i dispositivi compatibili a RBAC. Isolate i modelli che non possono migrare, testate le loro regole firewall e monitorate ogni percorso di amministrazione autorizzato. La vulnerabilità non può essere gestita soltanto tramite il controllo delle versioni.
