Cybersecurity
Come si conduce un assessment OT: fasi, metodi e cosa si trova davvero
Un assessment della rete OT non è una scansione di vulnerabilità eseguita sull'IT aziendale. Metodologia diversa, rischi diversi, e risultati spesso sorprendenti: ecco cosa aspettarsi da un assessment condotto correttamente su un ambiente industriale.

Perché l'assessment OT non è uguale a quello IT
Quando un responsabile della sicurezza IT pianifica un vulnerability assessment sulla propria infrastruttura, si aspetta un processo consolidato: uno scanner che interroga i sistemi, raccoglie le risposte, incrocia i dati con i database di vulnerabilità, e produce un report. I sistemi vengono interrogati attivamente, rispondono, e il processo si conclude in poche ore o giorni.
Lo stesso approccio in un ambiente OT può causare incidenti. I dispositivi di controllo industriale (PLC, RTU, controller di sicurezza, strumenti di campo con interfacce di rete) non sono stati progettati per gestire il volume di traffico che uno scanner di vulnerabilità genera. Alcuni modelli di PLC rispondo a richieste di rete anomale con comportamenti imprevedibili: timeout, reset della comunicazione, o nei casi peggiori, crash del processo in esecuzione.
Questo non è un problema raro o teorico. Esistono casi documentati in cui scansioni di vulnerabilità condotte senza le dovute cautele su reti OT hanno causato interruzioni di produzione. In ambienti di processo continuo (chimica, farmaceutica, alimentare) un'interruzione improvvisa può avere conseguenze che vanno ben oltre il fermo produzione.
L'assessment OT richiede quindi una metodologia diversa, centrata sulla raccolta passiva delle informazioni e sulla prioritizzazione della non-interruzione dei processi operativi in ogni fase.
Fase 1: preparazione e raccolta di contesto
Un assessment OT ben condotto inizia prima di connettere qualsiasi sensore alla rete. La fase di preparazione serve a raccogliere il contesto necessario per interpretare correttamente i dati che verranno raccolti e per pianificare l'intervento in modo da minimizzare i rischi.
Le informazioni da raccogliere in questa fase:
Inventario documentato degli asset (se esiste): schemi elettrici, documentazione delle macchine, liste dei dispositivi fornite dai vendor. Anche se incomplete o datate, queste informazioni forniscono un punto di partenza per verificare cosa ci si aspetta di trovare.
Topologia di rete: schemi di rete, configurazioni degli switch, documentazione delle VLAN. Anche qui, la realtà spesso differisce dalla documentazione.
Calendario operativo: quali sono i periodi di produzione normale, le fermate pianificate, i turni di manutenzione. Alcune fasi dell'assessment, in particolare l'installazione dei sensori, vanno pianificate per coincidere con finestre dove l'impatto operativo è minimo.
Persone chiave: chi conosce la rete OT meglio di chiunque altro. Questo interlocutore è indispensabile per interpretare correttamente i dati raccolti: è lui che saprà spiegare perché un certo dispositivo comunica in modo insolito, o che potrà confermare se un certo comportamento è normale o anomalo per quell'impianto.
Perimetro dell'assessment: quali zone, quali linee, quali sistemi sono inclusi. In ambienti grandi, un assessment completo può essere suddiviso in fasi successive per zone.
Fase 2: raccolta passiva e profilazione dispositivi
Il cuore dell'assessment OT è la raccolta passiva del traffico di rete. I sensori vengono posizionati nei punti strategici della rete (confini tra zone, uplink degli switch principali, connessioni verso sistemi SCADA) e iniziano ad ascoltare il traffico senza inviare nulla.
La durata della fase di raccolta è un parametro critico. Il traffico OT ha pattern temporali specifici: ci sono comunicazioni che avvengono ogni secondo, e comunicazioni che avvengono solo durante certi cicli produttivi o durante certe operazioni di manutenzione. Un periodo di raccolta troppo breve produrrà un inventario incompleto: verranno visti solo i dispositivi che hanno comunicato durante quel periodo. In ambienti OT tipici, una raccolta di due o tre settimane permette di intercettare la grande maggioranza dei dispositivi attivi, inclusi quelli che comunicano raramente.
Dalla raccolta passiva si estraggono:
Inventario dei dispositivi: ogni dispositivo che emette traffico sulla rete viene identificato dall'indirizzo MAC, classificato per tipo (PLC, HMI, switch, workstation), e dove possibile identificato per produttore e modello dalla firma del traffico.
Mappa delle comunicazioni: quale dispositivo parla con quale, su quali protocolli, con quale frequenza. Questa mappa è spesso la prima rappresentazione accurata delle dipendenze operative che l'organizzazione ha mai avuto.
Versioni firmware e software: molti dispositivi OT trasmettono informazioni sulla propria versione firmware durante le normali sessioni di comunicazione. Queste informazioni vengono estratte passivamente senza interrogare i dispositivi.
Protocolli presenti: quali protocolli industriali circolano sulla rete (Modbus, EtherNet/IP, PROFINET, OPC-UA, DNP3, S7) e quali protocolli IT coesistono con loro.
Fase 3: analisi delle vulnerabilità e correlazione CVE
Con l'inventario dei dispositivi e le versioni firmware disponibili, è possibile procedere alla fase di analisi delle vulnerabilità. Questa fase è quasi interamente offline: le informazioni raccolte passivamente vengono incrociate con i database di vulnerabilità (NVD, ICS-CERT, database specifici dei vendor) per identificare le vulnerabilità note applicabili ai dispositivi presenti.
L'assenza di scansione attiva significa che questa fase è completamente priva di rischi operativi. L'analisi avviene su dati già raccolti, non richiedendo nessuna ulteriore interazione con i sistemi.
Il risultato è una lista di vulnerabilità associate ai dispositivi specifici presenti nell'ambiente: non una lista generica basata sulle versioni dichiarate in un inventario manuale, ma una lista derivata da ciò che i dispositivi hanno effettivamente comunicato sulla rete. La differenza è significativa, perché gli inventari manuali spesso contengono versioni firmware non aggiornate che nascondono l'effettiva esposizione.
Per le vulnerabilità identificate, il punteggio EPSS (Exploit Prediction Scoring System), che stima la probabilità che una vulnerabilità venga sfruttata attivamente entro 30 giorni, è più utile del solo CVSS per prioritizzare gli interventi. Una vulnerabilità con CVSS 9.8 ma EPSS basso (pochi exploit disponibili, target poco appetibile) ha priorità diversa da una vulnerabilità con CVSS 7.5 ma EPSS alto (exploit pubblici, campagne attive documentate).
Fase 4: comportamenti anomali preesistenti
Una delle scoperte più frequenti, e più sorprendenti per le organizzazioni che commissionano un assessment, è la presenza di comportamenti anomali nella rete OT che preesistono all'assessment stesso.
Alcune delle anomalie più comuni trovate durante assessment su PMI manifatturiere:
Comunicazioni verso indirizzi IP non documentati: un dispositivo OT che invia traffico verso un indirizzo IP che nessuno sa spiegare. Può essere un canale di telemetria legittimo del vendor non documentato, ma va verificato.
Dispositivi non presenti in nessun inventario: sistemi che comunicano sulla rete ma che nessuno ricorda di aver installato. Spesso si tratta di hardware legacy dimenticato, ma devono essere investigati.
Traffico su protocolli non previsti: protocolli IT su segmenti che dovrebbero contenere solo traffico OT. VNC o RDP verso PLC che non dovrebbero avere accesso remoto. SMB verso controller di campo.
Accessi remoti attivi e non monitorati: sessioni VPN o connessioni di teleassistenza attive in modo persistente, spesso configurate anni prima e mai rimosse.
Pattern di comunicazione anomali: un HMI che normalmente invia comandi di lettura a un PLC che inizia a inviare comandi di scrittura, o lo fa in orari insoliti.
Queste anomalie, nella grande maggioranza dei casi, hanno spiegazioni benigne: eredità di configurazioni passate, comportamento di vendor non documentato, processi operativi non conosciuti dal team IT. Ma ogni anomalia deve essere investigata per escludere cause malevole, e questo processo di investigazione produce conoscenza dell'ambiente che è utile indipendentemente dall'esito.
Fase 5: report e gestione dei risultati senza creare panico
Il report di un assessment OT deve essere calibrato per il proprio pubblico e per la propria finalità. Un documento che elenca centinaia di vulnerabilità senza prioritizzazione è spesso controproducente: produce panico senza indirizzo, e porta a decisioni reattive non ponderate.
Un report efficace distingue chiaramente:
Rischi critici immediati: vulnerabilità altamente esploitabili su sistemi critici, accessi non autorizzati attivi, anomalie comportamentali che richiedono investigazione urgente. Questi richiedono azione nel breve termine.
Rischi significativi pianificabili: vulnerabilità con fix disponibile che possono essere corrette nell'ambito dei cicli di manutenzione ordinari, senza richiedere fermate straordinarie.
Rischi da accettare o mitigare con controlli compensativi: vulnerabilità per cui non esiste patch (sistemi legacy, fine-vita), dove la mitigazione è la segmentazione di rete o altri controlli compensativi.
Aree di miglioramento architetturale: gap strutturali come la mancanza di segmentazione, l'assenza di inventario, la mancanza di logging, che richiedono progetti di medio termine.
La presentazione dei risultati all'organizzazione dovrebbe sempre includere il team operativo, non solo il team IT. Chi gestisce gli impianti ha il contesto per valutare correttamente la priorità dei rischi e per pianificare gli interventi compatibilmente con i vincoli produttivi. Un assessment OT che ignora il contesto operativo nella fase di presentazione dei risultati spreca metà del suo valore.
L'angolo MON5
Le fasi descritte in questo articolo riflettono il modo in cui MON5 conduce i propri assessment: raccolta passiva o ibrida del traffico, profilazione dei dispositivi e topologia di rete, correlazione delle vulnerabilità con score EPSS ed esposizione reale, il tutto senza fermare la produzione. È la fase DISCOVER della metodologia: prima si osserva, poi si interpreta insieme a chi conosce l'impianto.
L'output non è una proposta commerciale travestita da report, ma un piano di azioni prioritizzate che l'organizzazione può eseguire con le risorse che preferisce. Se vuoi vedere come funziona sul tuo impianto, richiedi un assessment OT.
Articoli correlati

Cybersecurity
CVE e EPSS negli ambienti OT: quali vulnerabilità correggere quando non puoi patchare tutto
Patchare tutto in un ambiente OT è impossibile. CVSS da solo non basta per decidere le priorità. EPSS aggiunge la dimensione che mancava: la probabilità che una vulnerabilità venga sfruttata attivamente, oggi.

Cybersecurity
Cybersecurity OT nella logistica e nei magazzini automatizzati: sistemi eterogenei e alta rotazione
I magazzini automatizzati moderni hanno una rete OT complessa: WMS connesso agli automatismi, PLC eterogenei di vendor diversi, AGV, protocolli misti. Alta rotazione del personale, frequenti interventi vendor e integrazione con ERP rompono la segmentazione. Un fermo ha impatto immediato sulla supply chain.

Cybersecurity
Modello di maturità per la sicurezza OT: da zero visibilità a detection avanzata
Un framework pratico in quattro livelli per valutare la maturità della sicurezza OT e costruire una roadmap concreta. Ogni livello ha prerequisiti chiari, obiettivi misurabili e un passo successivo definito.
Hai la visibilità sulla tua rete OT?
MON5 mappa asset, vulnerabilità e anomalie in tempo reale — senza fermare la produzione.