Sistemi OT che non si possono aggiornare: compensating controls e risk reduction

La realtà degli impianti italiani

Chi lavora nella sicurezza OT in Italia conosce bene la scena: impianti manifatturieri con decenni di storia, macchinari acquisiti in periodi diversi, sistemi di controllo che hanno funzionato senza problemi per quindici o vent'anni e che nessuno ha mai avuto un motivo urgente di sostituire. Finché la macchina produce, toccarla sembra un rischio inutile.

Il risultato è che in molte linee di produzione italiane convivono PLC programmati nell'epoca pre-smartphone, HMI che girano su versioni di Windows ormai fuori supporto da anni, e server SCADA con software applicativi che il vendor ha smesso di aggiornare. Non è negligenza: è la razionalità economica dell'OT, dove l'investimento in nuovi sistemi si giustifica solo con un guadagno operativo chiaro, non con la sola riduzione del rischio informatico.

Questi sistemi hanno un tratto comune: non si possono patchare. Le ragioni variano.

Vendor che non rilascia aggiornamenti: il sistema è fuori supporto, il vendor ha abbandonato quella linea di prodotto o è stato acquisito. Non esiste una patch da applicare.

Hardware che non supporta versioni aggiornate: la memoria o la potenza di calcolo del PLC non è sufficiente per un firmware aggiornato. Aggiornare significa sostituire l'hardware, con costi e impatti operativi che spesso non vengono approvati.

Contratti di manutenzione che vietano modifiche software: alcune installazioni di impiantistica hanno contratti con il fornitore originale che includono clausole che invalidano la garanzia se il software viene modificato senza autorizzazione del vendor. Applicare una patch autonomamente sarebbe tecnicamente possibile ma giuridicamente problematico.

Procedure di validazione che rendono l'aggiornamento impraticabile: in settori come il farmaceutico o l'alimentare, i sistemi di controllo possono essere soggetti a validazione regolatoria. Un aggiornamento software richiede una nuova validazione, con tempi e costi che possono superare quelli di una sostituzione completa.

Cosa significa gestire il rischio senza patchare

La tentazione, di fronte a un sistema non aggiornabile, è di dichiararlo "rischio accettato" e andare avanti. In alcuni casi, con un'analisi rigorosa, questa può essere la conclusione corretta. Ma "accettare il rischio" non significa ignorarlo: significa documentare consapevolmente la decisione, definire le condizioni che la rendono ancora valida e stabilire cosa farebbe cambiare idea.

La gestione del rischio su sistemi non aggiornabili si articola su tre assi:

Riduzione dell'esposizione: limitare il più possibile la superficie di attacco raggiungibile dal sistema vulnerabile. Se il sistema non può essere patchato, almeno si può ridurre chi può comunicare con lui e come.

Aumento della visibilità: se non si può eliminare la vulnerabilità, occorre essere in grado di rilevare rapidamente se qualcuno la sta sfruttando. La detection precoce compensa parzialmente l'assenza di patch.

Riduzione dell'impatto potenziale: segmentare in modo che un sistema compromesso non diventi automaticamente un punto di accesso all'intera rete OT.

Isolamento di rete: il compensating control più efficace

La segmentazione di rete è il compensating control con il miglior rapporto tra efficacia e fattibilità per i sistemi OT legacy. L'idea è semplice: se un sistema vulnerabile non può essere patchato, almeno si limita chi può raggiungere la vulnerabilità.

In pratica questo significa definire regole di firewall o di ACL sugli switch che consentano solo il traffico strettamente necessario al funzionamento del sistema, bloccando tutto il resto. Per un PLC legacy che usa Modbus TCP per comunicare con un HMI specifico, le regole dovrebbero consentire solo quella comunicazione: niente navigazione internet, niente accesso da segmenti di rete non autorizzati, niente connessioni in entrata non attese.

Questo approccio non richiede di toccare il sistema vulnerabile: si agisce sulla rete attorno a lui. Va eseguito con attenzione, documentando prima di bloccare il traffico quali sono le comunicazioni legittime del sistema, per evitare di interrompere funzionalità operative. Un'analisi preventiva del traffico reale, attraverso il monitoraggio passivo, permette di costruire regole precise invece di regole approssimative che poi richiedono eccezioni continue.

Whitelisting delle comunicazioni

Un concetto collegato alla segmentazione ma più granulare è il whitelisting delle comunicazioni: definire non solo chi può comunicare con il sistema legacy, ma quale traffico specifico è considerato normale.

Per i protocolli OT, questo può significare consentire solo determinati function code Modbus, solo determinate operazioni OPC-UA, solo le letture di registro che il processo normale richiede. Un attaccante che usa lo stesso protocollo per scopi diversi (leggere la configurazione invece dei soli dati di processo, scrivere su registri invece di soli leggere) produce traffico che esula dalla whitelist.

Il monitoraggio del traffico OT permette di rilevare queste anomalie. Rispetto alla segmentazione pura, il whitelisting richiede una conoscenza più approfondita del comportamento normale del sistema, ma offre una visibilità molto più fine su cosa sta succedendo.

Il monitoraggio passivo come layer di detection

Se non posso eliminare la vulnerabilità e non posso interrompere la produzione per indagare ogni anomalia, almeno posso sapere quando qualcosa di insolito succede.

Il monitoraggio passivo del traffico OT, posizionare sensori che ascoltano il traffico senza interagire con i dispositivi, è particolarmente adatto ai sistemi legacy per due ragioni. Prima: non richiede di installare nulla sul sistema vulnerabile, che potrebbe reagire male o che per contratto non può essere modificato. Seconda: il traffico OT industriale su sistemi legacy tende a essere molto ripetitivo e prevedibile, il che facilita enormemente la costruzione di una baseline e il rilevamento delle deviazioni.

Un sistema OT legacy che comunica ogni cinque secondi con un HMI per scambiarsi dati di processo produce un pattern di traffico stabile e riconoscibile. Una connessione di management non prevista, un tentativo di scrivere su un registro, una nuova sessione da un IP sconosciuto: queste anomalie emergono chiaramente rispetto alla baseline.

La detection non risolve la vulnerabilità, ma cambia radicalmente la situazione operativa: da "siamo vulnerabili e non lo sappiamo" a "siamo vulnerabili ma lo sappiamo e sappiamo quando qualcuno ci sta provando". Questa visibilità permette di rispondere invece di subire passivamente.

Procedure operative come compensating control

Un aspetto spesso sottovalutato è che il rischio OT non dipende solo dalla tecnologia: dipende anche dalle procedure e dalle persone. I compensating controls non sono solo tecnici.

Per i sistemi non aggiornabili, alcune misure procedurali hanno impatto concreto:

Accesso fisico controllato: un sistema legacy non raggiungibile via rete è molto meno vulnerabile. Dove possibile, limitare l'accesso fisico alle porte di rete e seriali dei sistemi critici riduce il rischio anche in assenza di patch.

Procedure per gli accessi remoti dei vendor: se un fornitore deve accedere al sistema legacy per manutenzione, l'accesso deve seguire un processo definito: finestra temporale predefinita, supervisione di un operatore interno, disconnessione immediata al termine. Non accessi permanenti o credenziali condivise.

Verifiche periodiche della configurazione: anche senza patchare, verificare che la configurazione del sistema non sia cambiata rispetto alla baseline è un controllo utile. Modifiche non autorizzate alla configurazione, un segnale possibile di compromissione, vanno rilevate il prima possibile.

Change management rigoroso: ogni modifica alla rete attorno a un sistema legacy deve essere documentata e valutata per il suo impatto sulla postura di sicurezza. Aggiungere un nuovo dispositivo che può raggiungere il sistema legacy è una modifica alla sua esposizione, anche se non è una modifica al sistema stesso.

Piano di rientro nel lungo periodo

I compensating controls non sono una soluzione permanente: sono una gestione temporanea del rischio mentre si lavora a una soluzione più strutturale. Il sistema legacy non aggiornabile oggi dovrà essere sostituito o aggiornato in futuro: la domanda è quando e con quale priorità.

Un piano di rientro realistico per i sistemi OT legacy include:

Classificazione per criticità e rischio: non tutti i sistemi legacy hanno lo stesso profilo di rischio. Quelli con vulnerabilità ad alto EPSS, scarsa segmentazione e ruolo critico nel processo produttivo hanno priorità di sostituzione più alta.

Budget pluriennale: la sostituzione di sistemi OT critici non si improvvisa. Richiede pianificazione, test in ambiente di staging, coordinamento con i vendor, finestre di manutenzione estese. Va inserita nel piano di investimento con anni di anticipo.

Valutazione delle alternative di hardening: prima di concludere che un sistema è davvero non aggiornabile, vale la pena esplorare tutte le opzioni. A volte esiste una patch del vendor non pubblicizzata, a volte il fornitore può fornire una versione aggiornata compatibile con l'hardware esistente, a volte un aggiornamento parziale riduce significativamente la superficie di attacco anche senza portare il sistema all'ultima versione.

Il sistema legacy non aggiornabile è una realtà che non sparisce dall'oggi al domani negli impianti italiani. Gestirlo con un approccio strutturato (isolamento, visibilità continua, procedure rigorose, piano di rientro) è più efficace e più onesto intellettualmente del semplice "rischio accettato" senza ulteriori azioni.

L'angolo MON5

Quando la patch non è un'opzione, contano due cose: sapere quali sistemi legacy espongono il rischio maggiore e accorgersi se qualcuno prova a sfruttarli. La fase ANALYZE di MON5 correla le CVE dei sistemi non aggiornabili con score EPSS ed esposizione reale in rete, distinguendo la vulnerabilità teorica da quella che merita un compensating control immediato.

La fase PROTECT fornisce il layer di detection descritto sopra: monitoraggio passivo fuori banda sui protocolli OT nativi, baseline del traffico ripetitivo dei sistemi legacy e anomaly detection ML sulle deviazioni, senza installare nulla sui dispositivi. Per classificare i vostri sistemi legacy per criticità reale, iniziate con un assessment OT.