Vulnerability management nell'OT: perché le patch tradizionali non funzionano

Il patching nell'OT: la realtà operativa

Nella sicurezza IT, il patch management è un processo consolidato: le patch vengono rilasciate, testate in un ambiente di staging, e distribuite nei tempi previsti dalla policy aziendale. È un ciclo che si ripete ogni mese, ogni settimana per le patch critiche, in alcune organizzazioni in modo quasi continuo.

Nell'OT, questo modello non funziona. Non è pigrizia o mancanza di consapevolezza: è la natura degli ambienti industriali.

Un responsabile di produzione sa che aggiornare il firmware di un PLC richiede fermare la linea. Fermare la linea ha un costo orario misurabile. Se la finestra di manutenzione successiva è tra tre mesi, la patch aspetta tre mesi. Se quel sistema è in produzione continua 24/7, la finestra di manutenzione potrebbe essere semestrale o annuale.

Questo non è un problema risolvibile con più sensibilizzazione o con policy più stringenti. È un vincolo strutturale degli ambienti industriali che qualsiasi programma di VM efficace deve accettare e gestire, non ignorare.

Perché i cicli di patching IT non si trasferiscono all'OT

I motivi per cui il patching standard non si applica all'OT sono diversi e spesso cumulativi:

Incompatibilità dei sistemi operativi: molti sistemi SCADA e HMI girano su Windows XP, Windows Server 2003, o versioni di OS ancora più datate. Microsoft non rilascia più patch per questi sistemi. Anche volendo, non c'è nulla da applicare.

Validazione e certificazione: in settori come il farmaceutico, il nucleare, l'aerospaziale, i sistemi OT sono validati e/o certificati. Qualsiasi modifica, inclusa l'installazione di una patch, può invalidare la certificazione e richiedere una ri-validazione completa, costosa e lunga. Il beneficio di sicurezza della patch deve essere valutato contro il costo e il rischio della ri-validazione.

Aggiornamenti solo con il vendor: molti sistemi di automazione industriale possono essere aggiornati solo con il supporto diretto del vendor. Il vendor deve qualificare la patch per la versione specifica del software, il cliente deve coordinare un intervento, il personale certificato deve eseguire l'aggiornamento. Il processo richiede settimane.

Test di regressione necessari: un aggiornamento che funziona nell'IT senza problemi può avere comportamenti imprevisti su sistemi di controllo dove la latenza di un millisecondo è critica. I test di regressione su ambienti di produzione OT richiedono tempo e risorse dedicati.

Sistemi fuori supporto del vendor: non è raro trovare sistemi OT con componenti software per cui il vendor non esiste più, è stato acquisito, o ha semplicemente cessato il supporto. Non ci sono patch disponibili perché non c'è nessuno che le produce.

Prioritizzare le vulnerabilità: CVSS non basta, serve contesto OT

Lo strumento standard per la prioritizzazione delle vulnerabilità nell'IT è il CVSS (Common Vulnerability Scoring System): uno score da 0 a 10 che indica la gravità teorica di una vulnerabilità. Una vulnerabilità con CVSS 9.8 viene patchata prima di una con CVSS 5.

Nell'OT, il CVSS da solo è insufficiente. Considera questo: una vulnerabilità CVSS 9.8 su un sistema SCADA completamente isolato dalla rete, accessibile solo fisicamente, in un impianto con guardiania 24/7 ha un rischio reale molto inferiore rispetto a una vulnerabilità CVSS 6.0 su un HMI con connessione di accesso remoto attiva.

Il rischio reale nell'OT è la combinazione di:

• Gravità teorica della vulnerabilità (CVSS)
• Esposizione effettiva del sistema (è raggiungibile dalla rete? Ha accesso remoto? È esposto a Internet?)
• Importanza operativa del sistema (cosa controlla? Qual è l'impatto di un downtime?)
• Esistenza di controlli compensativi (è in una zona isolata? È monitorato?)
• Sfruttabilità reale nell'ambiente specifico (ci sono exploit pubblici? L'attaccante dovrebbe già essere sulla rete OT?)

Questo contesto OT-specifico deve essere aggiunto a qualsiasi framework di prioritizzazione. Strumenti come il CVSS-OT o le metodologie di risk scoring specifiche per ambienti ICS (come quelle di CISA e ICS-CERT) incorporano queste dimensioni.

Controlli compensativi: la difesa in profondità come alternativa

Quando la patch non è applicabile, il programma di VM deve rispondere con controlli compensativi: misure che riducono il rischio della vulnerabilità senza eliminarla.

I controlli compensativi più efficaci per vulnerabilità OT non patchabili:

Isolamento di rete: portare il sistema vulnerabile in una zona di rete separata, con accesso limitato ai soli sistemi che hanno necessità operative di comunicarci. Se la vulnerabilità richiede accesso di rete per essere sfruttata, limitare l'accesso di rete riduce il rischio.

Whitelisting del traffico: invece di permettere tutto il traffico verso un sistema vulnerabile e bloccare solo quello malevolo, invertire la logica: bloccare tutto e permettere solo il traffico specifico necessario. Funzioni code whitelist per i protocolli industriali.

Monitoraggio specifico: configurare regole di detection specifiche per i pattern di attacco noti associati alla vulnerabilità. Se esiste un exploit pubblico, le sue signature di traffico sono note e rilevabili.

Virtual patching: alcuni sistemi di intrusion prevention (IPS) industriali possono bloccare il traffico che cerca di sfruttare vulnerabilità specifiche, anche senza che il sistema vulnerabile sia stato aggiornato. È un "patch virtuale" che agisce sulla rete invece che sul sistema.

Limitazione dell'esposizione: rimuovere o disabilitare i vettori di accesso non necessari al sistema vulnerabile: porte di rete non usate, servizi non necessari, account non utilizzati.

Un programma di VM sostenibile per ambienti industriali

Un programma di vulnerability management OT efficace ha caratteristiche diverse da quello IT:

Inventario continuo come base: non si può gestire ciò che non si conosce. Il VM OT inizia sempre dall'inventario completo e aggiornato degli asset, con le relative versioni software e firmware.

Scoring contestualizzato: ogni vulnerabilità va scorata nel contesto dell'ambiente specifico, non con il CVSS universale.

Tre categorie di azione: per ogni vulnerabilità identificata, una delle tre: applica patch (con timeline realistica), implementa controllo compensativo (documentato e pianificato), accetta il rischio residuo (con approvazione formale e revisione periodica).

Integrazione con il ciclo di manutenzione: il VM OT deve coordinarsi con le finestre di manutenzione programmate. Le patch identificate come prioritarie vengono pianificate nelle finestre disponibili, non aspettate passivamente.

Revisione periodica del rischio accettato: le vulnerabilità per cui è stato accettato il rischio residuo devono essere rivalutate periodicamente. Il contesto cambia: nuovi exploit pubblici, nuove connessioni di rete, cambiamenti di esposizione possono cambiare il profilo di rischio di una vulnerabilità considerata a basso impatto.

Il VM nell'OT non è la ricerca della perfezione: un ambiente OT aggiornato al 100% non esiste. È la gestione sistematica del rischio residuo in un ambiente dove la perfezione tecnica è strutturalmente irraggiungibile.

L'angolo MON5

Prioritizzare le vulnerabilità con il solo CVSS, come visto, non funziona negli ambienti industriali. La fase ANALYZE di MON5 affronta il problema combinando tre dimensioni: inventario asset continuo con versioni software e firmware, correlazione delle CVE con lo score EPSS e, soprattutto, l'esposizione reale di ogni sistema nella rete dell'impianto.

Il risultato è una lista di priorità gestibile, allineata alle finestre di manutenzione disponibili invece che a un ideale di patching irrealizzabile. Il percorso è modulare e inizia dalla fotografia dello stato attuale: richiedi un assessment OT per costruire la base del tuo programma di vulnerability management.