Costruire un SOC per gli ambienti OT: requisiti, strumenti e metriche operative

Perché il SOC IT non vede l'OT

Un SOC IT ben equipaggiato ha visibilità su email, endpoint, reti, applicazioni web, autenticazioni, comportamento utente. Ha strumenti per correlare eventi da fonti diverse, analisti addestrati a riconoscere pattern di attacco, playbook per le tipologie di incidente più comuni.

Ma questo SOC è cieco agli ambienti OT. Non perché gli analisti siano incompetenti: perché la visibilità semplicemente non c'è. I dispositivi OT non inviano log al SIEM centralizzato. Il traffico Modbus non viene monitorato. Le modifiche alla logica di un PLC non generano alert. Un attaccante che si muove nella rete OT è completamente invisibile al SOC IT.

Il gap non è tecnico in senso stretto: è architetturale. Le reti OT non sono state progettate per generare telemetria di sicurezza. I dispositivi di campo non hanno agenti endpoint. I protocolli industriali non hanno log applicativi nativi. Costruire visibilità OT richiede un approccio diverso da quello usato per l'IT.

Requisiti tecnici: sensori, collector, integrazione SIEM

La visibilità OT si costruisce principalmente attraverso il monitoraggio passivo del traffico di rete: posizionare sensori (tap di rete o SPAN port) nelle zone chiave della rete OT e catturare tutto il traffico per analisi.

I sensori di rete OT specializzati hanno capacità che i sensori IT generici non hanno:

• Decodifica dei protocolli industriali: comprendere il contenuto di una sessione Modbus, OPC-UA, DNP3, PROFINET, EtherNet/IP, non solo le connessioni TCP sottostanti.
• Identificazione passiva degli asset: riconoscere i dispositivi OT dai loro pattern di traffico, ricavare versioni software e firmware senza interrogare attivamente i dispositivi (il che potrebbe disturbare i processi).
• Baseline comportamentale: stabilire il profilo normale di comunicazione per ogni dispositivo e rilevare le deviazioni.
• Correlazione con CVE OT: associare dispositivi identificati con vulnerabilità note dal database ICS-CERT e CISA.

I dati raccolti dai sensori OT devono essere normalizzati e inviati al SIEM (o a una piattaforma di monitoraggio OT dedicata integrata con il SIEM) per la correlazione con gli eventi IT. Un attaccante che inizia in IT e si sposta verso OT lascia tracce in entrambe le reti; solo la visibilità integrata permette di ricostruire la catena.

Competenze: la persona giusta per il SOC OT

Il SOC OT richiede un profilo di analista diverso da quello del SOC IT. Non è sufficiente prendere un analista IT e fargli seguire un corso OT: la mentalità deve cambiare.

Le competenze fondamentali per un analista SOC OT:

Conoscenza dei sistemi di controllo industriale: capire cos'è un PLC, come funziona un sistema SCADA, cosa fa una RTU, come funziona una rete di campo. Senza questa base, gli alert OT sono incomprensibili.

Comprensione dei processi industriali: sapere che un alert "scrittura anomala a registro PLC" su un sistema di dosaggio chimico è potenzialmente critico, mentre la stessa tipologia di alert su un sistema di illuminazione ha priorità diversa. Il contesto operativo è tutto.

Conoscenza dei protocolli OT: riconoscere il traffico Modbus normale vs. anomalo, capire cosa significa un cambio di Security Policy in OPC-UA, interpretare i function code DNP3.

Tolleranza all'incertezza: nell'OT, molti alert hanno cause benigne (operazioni di manutenzione normale, comportamento legacy di sistemi datati). L'analista OT deve saper distinguere il segnale dal rumore senza alzare troppi falsi positivi che saturano l'attenzione.

La soluzione più comune nelle organizzazioni di medie dimensioni è il SOC ibrido: analisti IT tradizionali che gestiscono la triage primaria, con escalation verso specialisti OT per gli alert che richiedono contesto industriale specifico.

Playbook specifici: alert OT vs. alert IT

I playbook di risposta agli alert OT non possono essere copie di quelli IT. Le azioni appropriate sono diverse e, come già discusso nell'articolo sull'incident response OT, spesso il "isola e spegni" IT diventa "monitora e coordina con operations" nell'OT.

Alcuni esempi di playbook OT specifici:

Alert: modifica alla logica PLC fuori dalle finestre di manutenzione

1. Verificare se è in corso un intervento di manutenzione non schedulato (chiamare il responsabile operations)
2. Se non c'è giustificazione operativa: isolare il sistema dall'accesso remoto e allertare il team di incident response
3. Preservare il log delle modifiche e la configurazione pre-modifica
4. Non riavviare o ripristinare senza analisi forense preliminare

Alert: nuovo dispositivo apparso sulla rete OT

1. Identificare il dispositivo: è il risultato di manutenzione pianificata? È un dispositivo temporaneo di un vendor?
2. Se non autorizzato: bloccare le comunicazioni verso/dal dispositivo a livello firewall
3. Investigare il punto di connessione fisico

Alert: comunicazione verso IP esterno da dispositivo OT

1. Verificare se è un canale di telemetria legittimo del vendor
2. Analizzare il contenuto del traffico
3. Se non giustificato: bloccare la destinazione a livello firewall e avviare investigazione

Metriche: come misurare l'efficacia del SOC industriale

Il SOC OT deve essere misurato, ma le metriche IT standard non sono tutte applicabili. Il numero di alert gestiti al giorno non è significativo se la maggior parte sono falsi positivi.

Metriche rilevanti per un SOC OT:

Time to detect (TTD): quanto tempo passa dal momento in cui un comportamento anomalo inizia a essere rilevabile a quando un analista lo esamina. Nell'OT, dove gli APT si muovono lentamente, rilevare la loro presenza nelle prime ore ha impatto enorme.

False positive rate: la percentuale di alert che dopo triage risultano non malevoli. Un tasso alto indica baseline mal calibrate o regole di detection non adattate all'ambiente specifico.

Coverage degli asset critici: quale percentuale degli asset OT critici è coperta dal monitoraggio? Gli asset critici senza visibilità sono punti ciechi noti.

Tempo di aggiornamento delle regole: quanto velocemente vengono create regole di detection per nuove minacce specifiche OT (nuovi CVE, nuove campagne APT verso l'industriale)?

Esercitazioni di rilevamento: con quale frequenza vengono condotte esercitazioni in cui il SOC OT deve rilevare comportamenti simulati di attacco? Questo è l'unico modo per verificare che le capacità di detection funzionino davvero prima che servano.

Un SOC OT maturo non si costruisce in pochi mesi: richiede tempo per calibrare le baseline, per costruire la knowledge base specifica dell'ambiente, per addestrare il personale. Ma ogni passo nella direzione della visibilità OT è un miglioramento della postura di sicurezza rispetto allo stato di cecità totale che caratterizza ancora molte organizzazioni industriali.

L'angolo MON5

Un SOC cieco sull'OT non si corregge chiedendo più log a dispositivi che non li producono: serve generare la telemetria che manca. La fase PROTECT di MON5 lo fa con NDR passivo fuori banda sui protocolli OT nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP), con baseline comportamentali e anomaly detection ML, senza agenti sui dispositivi di campo.

I dati arrivano normalizzati e pronti per la correlazione con gli eventi IT, così gli analisti lavorano su alert con contesto industriale invece che su pacchetti grezzi. Il percorso è modulare e parte dalla visibilità: il primo passo è un assessment OT che fotografa asset e traffico del tuo impianto.