MZ Automation lib60870 affronta un avviso di cybersicurezza CISA per una vulnerabilità di crash remoto

MZ Automation è oggetto di un avviso di cybersicurezza CISA dopo che i ricercatori hanno scoperto che un singolo messaggio malformato può mandare in crash i processi di parsing vulnerabili di lib60870. La vulnerabilità interessa lib60870 fino alla versione 2.4.0 inclusa ed è identificata come CVE-2026-16002. La versione 2.4.1 contiene la correzione.

Il bug risiede nel software utilizzato per elaborare comunicazioni IEC 60870-5 negli ambienti di controllo industriale. Queste comunicazioni possono collegare centri di controllo, sottostazioni, unità terminali remote e altri sistemi di tecnologia operativa. Per questo, un errore del parser ha implicazioni diverse rispetto al crash di una normale applicazione.

Il contrasto centrale è tra un codice circoscritto e conseguenze operative estese. Il decoder difettoso gestisce un solo tipo di messaggio specializzato, ma la libreria interessata supporta comunicazioni utilizzate nelle infrastrutture energetiche, chimiche, idriche e di trattamento delle acque reflue. CISA descrive il prodotto come distribuito a livello mondiale.

Non si tratta di una compromissione dimostrata di apparecchiature industriali. I ricercatori hanno osservato una lettura fuori dai limiti e un esito di denial-of-service, non l'esecuzione di codice arbitrario. Tuttavia, un attaccante raggiungibile via rete non necessita di account né di interazione dell'utente una volta che un frame appositamente predisposto raggiunge un parser esposto.

La risposta immediata è chiara: individuare le distribuzioni di lib60870, stabilire se elaborano il tipo di messaggio interessato e aggiornare alla versione 2.4.1 o successiva. Il compito più difficile consiste nel trovare ogni copia incorporata e modificare in sicurezza sistemi operativi che non possono tollerare tempi di inattività non pianificati.

Cosa ha cambiato l'avviso di cybersicurezza CISA

CISA ha trasformato un difetto del parser in una scadenza concreta per la gestione degli asset nelle organizzazioni che utilizzano lib60870 in ambienti operativi.

Il CISA cybersecurity advisory identifica una lettura fuori dai limiti in MZ Automation lib60870. Questo errore di sicurezza della memoria consente al software di leggere oltre il limite previsto di un buffer di dati.

Lo sfruttamento riuscito può mandare in crash il processo di parsing e causare un denial of service. CISA indica come interessate le versioni di lib60870 fino alla 2.4.0 e identifica la 2.4.1 come versione corretta.

L'avviso associa il problema a CVE-2026-16002 e CWE-125, la classificazione standard per le letture fuori dai limiti. Descrive inoltre una distribuzione mondiale nelle attività chimiche, energetiche, idriche e di trattamento delle acque reflue.

L'elenco dei settori non dimostra che ogni organizzazione in tali industrie utilizzi il codice vulnerabile. Mostra perché CISA considera la libreria software per sistemi di controllo industriale, con conseguenze che vanno oltre una convenzionale applicazione server.

Il dettagliato record di sicurezza del fornitore restringe i componenti interessati al master CS101 e al client CS104. Questi componenti ricevono e analizzano messaggi da altri dispositivi, collocando il codice vulnerabile su un percorso di comunicazione in ingresso.

La versione vulnerabile testata era la 2.4.0, associata al commit sorgente 083dc8e. Anche il ramo di sviluppo era interessato prima del commit correttivo 182ed30. MZ Automation ha pubblicato la versione 2.4.1 come release corretta.

Le date aiutano a spiegare l'urgenza. MZ Automation ha annunciato la versione 2.4.1 il 16 luglio 2026 e ha pubblicato il proprio avviso di sicurezza GitHub il 17 luglio. CISA ha successivamente inserito il problema nel proprio processo di avvisi industriali.

Nei record pubblici compaiono ora due valori di gravità. Il materiale CISA assegna un punteggio CVSS v3 di 8,2, mentre l'avviso GitHub del fornitore mostra 5,3 con un'etichetta di gravità moderata.

Il punteggio inferiore del fornitore usa un vettore che descrive un attacco via rete a bassa complessità, senza privilegi né interazione dell'utente. Attribuisce un basso impatto sulla disponibilità e nessun impatto confermato su riservatezza o integrità.

Le organizzazioni non dovrebbero interpretare questa differenza di punteggio come prova che uno dei due record sia necessariamente errato. I risultati CVSS possono variare quando i valutatori adottano ipotesi diverse sull'impatto o sul contesto di distribuzione. Gli operatori industriali dovrebbero basare la priorità sull'effettiva raggiungibilità, sulla criticità del processo, sulla ridondanza e sul comportamento di ripristino.

Un parser che si riavvia automaticamente su un sistema di test ridondante ha un effetto operativo diverso da uno che supporta un singolo percorso di telemetria in produzione. Il difetto sorgente può essere identico, mentre il rischio operativo cambia in modo sostanziale.

Il nuovo obbligo non consiste quindi semplicemente nell'“installare una patch”. I team devono collegare un identificatore software a dispositivi reali, gateway, sistemi di ingegneria e applicazioni. Questo passaggio di inventario spesso determina se una correzione pubblicata raggiunge i sistemi che ne hanno bisogno.

Un frame malformato può oltrepassare il buffer

La vulnerabilità esiste perché il decoder convalida meno dati di quanti ne consumi successivamente.

Il codice interessato elabora IEC 60870-5 ASDU TypeID 41, chiamato anche S_IT_TC_1. Un ASDU, ovvero Application Service Data Unit, trasporta informazioni operative strutturate tra endpoint IEC 60870.

S_IT_TC_1 rappresenta totali integrati per statistiche di sicurezza con un timestamp. Il difetto compare nel percorso di decodifica IntegratedTotalsForSecurityStatistics all'interno di cs101_information_objects.c.

Secondo il vendor security advisory, il controllo della lunghezza del parser verifica solo una parte di ciascun elemento previsto. Il decoder legge poi una struttura più ampia contenente informazioni sul contatore e un timestamp.

L'elemento completo richiede circa 14 byte. Include un valore AID di due byte, una lettura di contatore binario di cinque byte e un timestamp CP56Time2a di sette byte. La logica di convalida vulnerabile considera solo cinque byte nel suo controllo dimensionale principale.

Questa discrepanza diventa pericolosa quando un messaggio dichiara più elementi di quanti ne contenga fisicamente il payload. Il decoder si fida del conteggio dichiarato abbastanza a lungo da oltrepassare la fine del buffer fornito.

I ricercatori hanno dimostrato il comportamento con un frame ridotto di circa 201 byte. Il suo Variable Structure Qualifier dichiarava 93 elementi, mentre il frame ne conteneva fisicamente circa 11.

Il parser ha raggiunto l'offset 201 tentando di elaborare l'elemento successivo. Una pagina di guardia contrassegnata come inaccessibile ha causato un errore deterministico quando il decoder ha attraversato il limite del buffer.

Questo percorso tecnico è rilevante perché lo sfruttamento non richiede uno scambio prolungato né una sequenza di operazioni attentamente sincronizzate. L'avviso afferma che un singolo ASDU TypeID 41 malformato può attivare la lettura.

IEC 60870-5-104 trasporta comunemente i propri messaggi sulla porta TCP 2404. Il protocollo sottostante non offre autenticazione integrata, anche se le distribuzioni possono aggiungere controlli di sicurezza del trasporto e dell'applicazione.

Un attaccante deve comunque far arrivare il messaggio predisposto al parser. In generale, ciò richiede raggiungibilità di rete, accesso a un percorso di comunicazione intermedio o un altro modo per iniettare traffico nel collegamento pertinente.

Una volta soddisfatta questa condizione, il vettore pubblicato non richiede privilegi né interazione dell'utente. Un operatore non deve aprire un file, approvare una richiesta o accedere a un'interfaccia.

Il percorso interessato è più specifico di quanto suggerisca l'espressione “tutte le comunicazioni lib60870”. Il fornitore afferma che sono esposte al crash dimostrato le applicazioni che gestiscono l'oggetto contatore di sicurezza S_IT_TC_1.

Questo dettaglio dovrebbe guidare i test, ma non dovrebbe diventare un pretesto per ignorare una versione vulnerabile identificata. Le organizzazioni potrebbero non avere visibilità completa su ogni tipo di messaggio abilitato da un integratore, un'applicazione downstream o una configurazione futura.

La correzione amplia la convalida affinché copra tutti i dati consumati da ciascun elemento prima che il decoder li legga. Si tratta di una riparazione diretta della discrepanza nei limiti, non di una soluzione alternativa a livello di rete.

MZ Automation ha incluso la correzione in un più ampio aggiornamento alla versione 2.4.1. La release affronta anche i controlli sulla lunghezza dei messaggi, la convalida dei certificati, le comunicazioni del server e altri problemi di stabilità.

Questa portata più ampia della release aumenta la necessità di test di regressione. In ogni caso, un operatore non sta applicando una modifica isolata al codice sorgente. Potrebbe passare a un pacchetto che contiene diverse correzioni di sicurezza e di comportamento.

Un piccolo bug del decoder mette sotto pressione grandi sistemi industriali

Il rischio principale non è la quantità di memoria corrotta, ma il ruolo operativo del processo che si interrompe.

Lib60870 implementa le comunicazioni IEC 60870-5-101 e IEC 60870-5-104 in codice C portabile. Il primo supporta collegamenti di telecontrollo seriali, mentre il secondo trasporta comunicazioni correlate su reti TCP/IP.

L'official repository elenca supporto master e slave, funzioni client e server CS104, gruppi di ridondanza e servizi file. Supporta inoltre funzionalità TLS quando compilato con la dipendenza richiesta.

Queste capacità collocano la libreria all'interno di applicazioni che scambiano informazioni di telemetria e controllo. L'architettura esatta del prodotto varia perché lib60870 è un componente software, non un singolo apparato industriale fisso.

Un'azienda di servizi pubblici potrebbe utilizzarla in un client del centro di controllo che riceve dati dalle stazioni remote. Un fornitore di apparecchiature potrebbe incorporarla in un gateway. Un integratore potrebbe compilarla in un'applicazione di monitoraggio specializzata.

Questa varietà crea il primo punto di pressione pratico. I team di sicurezza potrebbero riconoscere il nome di un dispositivo, ma non sapere quale libreria di comunicazione sia presente nel suo firmware o pacchetto software.

Gli utenti del codice sorgente possono ispezionare i record delle dipendenze, i manifest di build e le cronologie dei commit. I clienti commerciali potrebbero necessitare di documentazione del fornitore, di una distinta dei materiali software o di una conferma diretta dai fornitori.

Il secondo punto di pressione è il tempo di attività. Le comunicazioni industriali spesso supportano visibilità continua, gestione degli allarmi e operazioni remote. Riavviare un processo può essere tecnicamente semplice, ma operativamente problematico.

L'impatto dimostrato è un crash, non un danno fisico di per sé. Tuttavia, un'interruzione delle comunicazioni può oscurare le misurazioni correnti, interrompere la raccolta di dati storici, ritardare gli allarmi o costringere gli operatori a ricorrere a procedure di backup.

Le conseguenze effettive dipendono dalla progettazione del sistema. Client ridondanti, supervisori di processo, segmentazione di rete e controlli autonomi locali possono limitare l'effetto. Reti piatte e singoli percorsi di comunicazione possono amplificarlo.

Il terzo punto di pressione è il controllo delle modifiche. I team di tecnologia operativa testano comunemente gli aggiornamenti delle librerie di protocollo rispetto al comportamento dei dispositivi, alla temporizzazione, ai certificati e alle estensioni specifiche del fornitore prima della distribuzione in produzione.

Questa cautela tutela la disponibilità, ma può anche prolungare l'esposizione. Le organizzazioni devono bilanciare il rischio del noto crash causato da frame malformati con il rischio di introdurre un aggiornamento della libreria testato in modo insufficiente.

L'elenco dei settori interessati di CISA rende questo compromesso più visibile. Gli operatori energetici e idrici non possono presumere che una strategia di manutenzione progettata per il normale software d'ufficio sia adatta a un sistema di telemetria.

Il problema si estende anche oltre l'esposizione a Internet. Un dispositivo può essere protetto dall'Internet pubblico e rimanere raggiungibile da una workstation compromessa, un servizio di accesso remoto, una connessione del fornitore o una rete operativa adiacente.

Per questo, cercare soltanto endpoint pubblici TCP sulla porta 2404 è inadeguato. L'esposizione esterna è una via, non l'intera superficie d'attacco.

Una revisione degli asset dovrebbe tracciare il percorso completo dei dati. I team devono identificare quali sistemi ricevono messaggi IEC 60870, quali processi li analizzano e quali fonti a monte possono inviare traffico TypeID 41.

Dovrebbero inoltre determinare cosa accade dopo un arresto anomalo. Un processo supervisionato può riavviarsi immediatamente, mentre un altro servizio può rimanere indisponibile fino a un intervento manuale.

Frame dannosi ripetuti potrebbero vanificare il ripristino automatico se lo stesso traffico raggiunge il processo riavviato. Il filtraggio di rete e la supervisione dei processi integrano quindi la patch, ma non la sostituiscono.

Un utile test operativo chiede se la perdita del client interessato modifica la capacità di controllo, solo il monitoraggio, o entrambi. Tale distinzione orienta la gravità dell'incidente, la pianificazione della manutenzione e i controlli compensativi temporanei.

Il vero compromesso è tra patch rapide e cambiamenti sicuri

La versione 2.4.1 colma la lacuna di decodifica nota, ma gli operatori industriali necessitano comunque di una distribuzione controllata e di misure di contenimento stratificate.

La correzione più chiara consiste nell'aggiornare le applicazioni interessate a lib60870 2.4.1 o versioni successive. MZ Automation raccomanda specificamente questo passaggio per le applicazioni che utilizzano l'oggetto informativo S_IT_TC_1.

Le organizzazioni dovrebbero innanzitutto creare un inventario dei sistemi che contengono lib60870. Le prove utili includono file di lock delle sorgenti, registri di build, manifest del firmware, attestazioni dei fornitori, metadati dei pacchetti e analisi binaria, ove consentito dai contratti.

I team dovrebbero registrare sia la versione della libreria sia il ruolo dell'applicazione. Un client CS104 vulnerabile che riceve messaggi presenta un percorso di rischio diverso rispetto a un software che include la libreria ma non richiama mai il componente interessato.

Dovrebbero quindi mappare la raggiungibilità. Le domande rilevanti includono se l'endpoint accetta traffico da reti non attendibili, segmenti aziendali instradati, laptop di manutenzione, jump host o servizi remoti di terze parti.

La correzione dovrebbe passare attraverso un ambiente di test rappresentativo prima della produzione. I test dovrebbero coprire la telemetria normale, la gestione di input malformati, il failover, il comportamento di riconnessione, la convalida dei certificati e le combinazioni di messaggi specifiche del fornitore.

La versione 2.4.1 include diverse modifiche oltre a CVE-2026-16002. MZ Automation afferma che aggiunge la convalida della lunghezza dei messaggi e corregge altri difetti di sicurezza e stabilità. Queste modifiche rafforzano la motivazione per l'aggiornamento, ma ampliano anche la superficie dei test di regressione.

Laddove la distribuzione immediata sia impossibile, i controlli di rete possono ridurre l'esposizione. Gli operatori possono limitare l'accesso agli endpoint comunicanti noti e bloccare percorsi non necessari verso segmenti IEC 60870.

Una rete privata virtuale può proteggere l'accesso remoto, ma non rende sicuro ogni dispositivo all'interno del percorso attendibile. Credenziali rubate o un host autorizzato compromesso possono comunque fornire raggiungibilità di rete.

Il monitoraggio consapevole del protocollo può aiutare a identificare traffico TypeID 41 anomalo, conteggi di elementi incoerenti, errori di connessione ripetuti e riavvii dei processi. Gli operatori dovrebbero verificare che i dispositivi di monitoraggio analizzino correttamente la variante di protocollo pertinente.

La supervisione degli endpoint può abbreviare le interruzioni riavviando i servizi arrestati. Tuttavia, può anche nascondere uno sfruttamento ripetuto, a meno che gli eventi di riavvio non generino avvisi e conservino log utili.

Il filtraggio temporaneo dei messaggi S_IT_TC_1 richiede un'attenta revisione ingegneristica. Bloccare un oggetto legittimo di contatore di sicurezza può modificare il comportamento di monitoraggio previsto e non dovrebbe essere adottato alla cieca.

La risposta di cybersecurity CISA dovrebbe inoltre preservare le prove. I record rilevanti includono acquisizioni di pacchetti, dump dei crash di processo, log di riavvio, messaggi dell'applicazione e modifiche di configurazione intorno all'endpoint interessato.

Tali artefatti possono distinguere lo sfruttamento da un peer difettoso, traffico corrotto o un guasto applicativo non correlato. La stessa struttura malformata può essere prodotta deliberatamente o accidentalmente.

Il disaccordo sulla gravità merita una gestione attenta durante la definizione delle priorità. La valutazione 8.2 di CISA segnala una forte preoccupazione, mentre il calcolo 5.3 del fornitore riflette il limitato impatto di sicurezza dimostrato.

Nessuno dei due numeri descrive da solo uno specifico impianto o centro di controllo. Una valutazione locale del rischio dovrebbe considerare esposizione, dipendenza operativa, comportamento al riavvio, ridondanza e conseguenze sulla sicurezza della perdita di visibilità.

I team dovrebbero inoltre evitare di sovrastimare il risultato. L'avviso pubblico riporta una lettura fuori dai limiti, non una scrittura. I ricercatori non hanno dimostrato l'esecuzione di codice arbitrario.

Il fornitore osserva che dati heap adiacenti potrebbero essere esposti in determinate condizioni, a seconda del layout della memoria e del fatto che i valori decodificati vengano restituiti a un peer. Questa possibilità non è stata stabilita come exploit funzionante di divulgazione.

Allo stesso modo, la proof of concept pubblica non è disponibile. L'avviso descrive il trigger e i risultati sperimentali, ma le organizzazioni non dovrebbero presumere uno sfruttamento attivo diffuso senza prove separate.

Una risposta disciplinata si colloca quindi tra minimizzazione e allarme. Applicare la patch al difetto confermato, ridurre la raggiungibilità durante la distribuzione e monitorare il modello di errore descritto.

Cosa rivela questa scoperta sui test del software industriale

CVE-2026-16002 mostra come il fuzzing moderno possa individuare difetti di memoria circoscritti all'interno di implementazioni di protocolli industriali di lunga data.

L'avviso del fornitore afferma che uno strumento open source assistito da LLM chiamato Eldprov ha individuato il problema utilizzando AFL++ o libFuzzer con AddressSanitizer. Il fuzzing invia input insoliti al software per esporre crash e supposizioni errate.

Automation ha identificato il potenziale errore, ma un essere umano lo ha poi riprodotto e verificato. I ricercatori hanno utilizzato un harness con guard page e hanno esaminato il percorso sorgente pertinente prima di segnalare il risultato.

Questa sequenza è importante perché i report automatici sulle vulnerabilità possono contenere falsi positivi o crash caratterizzati in modo insufficiente. In questo caso, il record pubblico descrive una riproduzione deterministica e uno specifico errore nel controllo dei limiti.

La scoperta offre anche un utile confronto con le precedenti ricerche sulla sicurezza industriale. Avvisi precedenti relativi a lib60870 hanno coinvolto l'elaborazione dei messaggi e condizioni di denial-of-service, dimostrando che la resilienza dei parser resta una preoccupazione costante.

Le librerie di protocollo affrontano uno spazio di input difficile. Un frame può essere valido a un livello pur trasportando conteggi, lunghezze, flag e tipi di oggetto contraddittori a un altro.

Testare le normali comunicazioni dei dispositivi raramente coprirà ogni combinazione malformata. Il fuzzing può esplorare tali combinazioni più rapidamente, soprattutto se abbinato a sanitizer che rilevano accessi alla memoria non validi.

Il ruolo umano resta centrale. Un crash deve essere ridotto, tracciato, riprodotto e collegato a un'esposizione realistica prima che gli operatori possano intervenire.

La scoperta separa anche la sicurezza del protocollo dalla sicurezza dell'implementazione. Crittografia, autenticazione e segmentazione possono limitare chi invia traffico, ma il parser ricevente deve comunque gestire in sicurezza i dati malformati.

MZ Automation ha pubblicato linee guida che descrivono IEC 60870-5-101 e IEC 60870-5-104 come protocolli creati senza crittografia, autenticazione o protezione dell'integrità native. La sua panoramica sulla sicurezza IEC tratta le protezioni TLS e IEC 62351 che possono essere stratificate sulle distribuzioni.

Questi controlli riducono l'accesso non autorizzato se implementati correttamente. Non esonerano un decoder dal convalidare ogni campo prima di leggere la memoria.

Viceversa, un parser corretto non risolve una fiducia di rete debole. La versione 2.4.1 impedisce questo percorso di lettura noto, ma non trasforma un protocollo legacy in un confine di sicurezza completo.

Questo è il compromesso centrale dietro l'incidente. Gli operatori industriali necessitano sia di codice più sicuro sia di percorsi di comunicazione più ristretti, mantenendo al contempo la compatibilità con apparecchiature che potrebbero rimanere distribuite per anni.

I fornitori possono migliorare questo equilibrio pubblicando informazioni sulle dipendenze leggibili dalle macchine, percorsi di aggiornamento supportati e descrizioni chiare dei componenti interessati. Gli operatori possono quindi identificare l'esposizione senza effettuare reverse engineering di ogni binario distribuito.

Il mirror open source della libreria aiuta i ricercatori a esaminare il codice e consente agli utenti delle sorgenti di confrontare i commit. Tuttavia, i prodotti commerciali che incorporano la libreria richiedono comunque il coordinamento con il fornitore quando i clienti non possono ricompilarli direttamente.

La prossima domanda sui test è se controlli di lunghezza parziale simili esistano in altri decoder ASDU. La versione 2.4.1 aggiunge una convalida più ampia della lunghezza dei messaggi, suggerendo che la release affronti più di una sola riga isolata.

Ciò non stabilisce l'esistenza di ulteriori vulnerabilità sfruttabili. Giustifica una revisione mirata dei percorsi di decodifica che combinano conteggi variabili, indirizzi opzionali, contatori e timestamp.

I team di sicurezza dovrebbero inoltre monitorare se i fornitori downstream pubblicano i propri avvisi. Una correzione della libreria non raggiunge i prodotti embedded finché i manutentori non ricompilano, testano e distribuiscono software aggiornato.

Tre segnali mostreranno se il rischio è contenuto

La prossima fase dipende dall'adozione della patch, dalla divulgazione downstream e dalle prove di sfruttamento nel mondo reale.

Il primo segnale è la comparsa della versione 2.4.1 nei prodotti operativi effettivi. Una release della libreria avvia il processo di correzione, ma non prova che gli integratori abbiano distribuito applicazioni o firmware corretti.

Gli operatori dovrebbero chiedere ai fornitori se i loro prodotti includono lib60870-C, quale versione utilizzano e se il decoder interessato è raggiungibile. Le risposte dovrebbero identificare una release corretta e una procedura di distribuzione supportata.

Una forte ondata di avvisi downstream confermerebbe che i fornitori hanno tracciato la dipendenza nei loro portafogli. Il silenzio potrebbe significare che i prodotti non sono interessati, ma potrebbe anche riflettere un inventario incompleto.

Il secondo segnale è l'evidenza operativa derivante dall'aggiornamento. Le organizzazioni dovrebbero monitorare problemi di interoperabilità, cambiamenti nel comportamento dei certificati, problemi di riconnessione e gestione inattesa di ASDUs non comuni dopo il passaggio alla 2.4.1.

Distribuzioni senza problemi sosterrebbero una rapida adozione in flotte più ampie. Regressioni significative rallenterebbero l'applicazione delle patch e aumenterebbero il ricorso a segmentazione, allowlist e monitoraggio.

Il terzo segnale è qualsiasi prova che gli aggressori stiano utilizzando CVE-2026-16002 al di fuori di test controllati. Codice exploit pubblico, rapporti sugli incidenti, traffico TypeID 41 malformato ripetuto o un'escalation nel catalogo aumenterebbero l'urgenza.

In base ai dettagli dell'avviso pubblicato, il risultato dimostrato è un crash del parser in condizioni di laboratorio. Il record pubblico non stabilisce l'esecuzione di codice arbitrario né uno sfruttamento diffuso.

Le organizzazioni dovrebbero monitorare gli aggiornamenti CISA, gli avvisi dei fornitori e la propria telemetria operativa anziché attendere un titolo. Guasti di processo ripetuti sui client IEC 60870 meritano un'indagine anche quando i dispositivi perimetrali non mostrano alcuna esposizione pubblica.

L'azione immediata più utile è una revisione mirata dell'inventario. Individuate ogni sistema che riceve messaggi IEC 60870-5, determinatene la versione di lib60870 e documentate chi può raggiungerne il parser.

Quindi testate la versione 2.4.1 con traffico e scenari di errore rappresentativi. Dove un aggiornamento rapido non sia possibile, limitate i percorsi di comunicazione e generate avvisi sui riavvii del parser o sui messaggi TypeID 41 malformati.

Questo approccio corrisponde alle prove senza esagerarle. L'avviso di cybersecurity CISA descrive una condizione di denial-of-service confermata e raggiungibile da remoto nelle configurazioni interessate.

La questione irrisolta non è se esista il controllo dei limiti difettoso. È quanti sistemi di produzione lo contengano, quanto tali sistemi siano raggiungibili e con quale rapidità i loro proprietari possano distribuire la correzione in sicurezza.