Integrare il monitoring OT con SIEM e SOC esistenti: dati, formati e valore aggiunto

Il SOC che non vede metà dell'azienda

Un'organizzazione manifatturiera di medie dimensioni può avere un SIEM IT ben configurato, magari un SOC gestito da un provider esterno, endpoint detection sulle workstation, email security, log di firewall aggregati. Eppure questo sistema di monitoraggio è cieco a tutto ciò che avviene nella rete OT.

Non è una questione di competenze o di buona volontà: è una questione di dati. Il SIEM aggrega solo ciò che le sorgenti inviano. Se i dispositivi OT non generano eventi in un formato che il SIEM comprende, semplicemente non esistono per il SOC. Un PLC che viene interrogato da un host non autorizzato, un HMI che inizia a comunicare verso un IP esterno, un protocollo industriale su una porta anomala: nessuno di questi eventi raggiunge il SIEM IT.

Il risultato è un'organizzazione che vede bene la metà IT dell'azienda e non vede nulla della metà OT. Per gli attaccanti che seguono la catena IT-OT, questa cecità selettiva è una caratteristica, non un bug del loro approccio.

Formati di output e normalizzazione degli eventi OT

La prima sfida tecnica nell'integrazione OT-SIEM è la normalizzazione. Gli eventi generati da un sistema di monitoring OT descrivono realtà diverse da quelle del mondo IT: un "nuovo dispositivo visto in rete" non è un "login anomalo", ma entrambi sono eventi di sicurezza che meritano attenzione. Il SIEM deve essere in grado di riceverli, indicizzarli e correlarli.

I formati di output più comuni per l'integrazione con SIEM enterprise sono:

CEF (Common Event Format). Sviluppato da ArcSight e oggi supportato da quasi tutti i SIEM maggiori, CEF è uno standard per la trasmissione di eventi di sicurezza via Syslog. La sua struttura a coppie chiave-valore permette di mappare i campi OT specifici (zona di rete, tipo di protocollo industriale, function code Modbus, identificatore PLC) nei campi custom del CEF. Vantaggio: ampia compatibilità; svantaggio: la ricchezza semantica degli eventi OT si perde parzialmente nella compressione verso i campi CEF standard.

LEEF (Log Event Extended Format). Alternativa a CEF sviluppata da IBM per QRadar. Struttura simile, compatibilità prevalentemente nell'ecosistema IBM. Preferibile se il SIEM target è QRadar.

Syslog con payload JSON strutturato. Approccio più moderno: trasportare eventi JSON arbitrariamente ricchi nel payload Syslog. Il SIEM riceve il messaggio Syslog, estrae il JSON e può indicizzare qualsiasi campo. Richiede una pipeline di parsing configurata lato SIEM ma offre la massima flessibilità per preservare la semantica OT degli eventi.

API REST / webhook. Alcuni SIEM moderni (Splunk, Elastic SIEM, Microsoft Sentinel) accettano eventi via API HTTP in formato JSON. Questo approccio evita la frammentazione Syslog e permette batch di eventi con maggiore efficienza. Richiede connettività di rete tra la rete OT (o la DMZ dove risiede il collector OT) e il SIEM.

La scelta del formato dipende dal SIEM in uso e dalla quantità di eventi attesa. Per ambienti OT di medie dimensioni (centinaia di dispositivi, migliaia di eventi al giorno), qualsiasi formato standard è adeguato. Per ambienti più densi, le performance di ingestion diventano un fattore da valutare.

Quali eventi OT portare nel SIEM e quali gestire localmente

Non tutti gli eventi generati dal monitoring OT devono arrivare al SIEM. La selezione è importante per due ragioni: evitare di saturare il SIEM con rumore OT che gli analisti non sanno come gestire, e garantire che gli eventi ad alta priorità abbiano la visibilità che meritano.

Al SIEM vanno gli eventi che richiedono correlazione con l'IT o che hanno impatto sulla sicurezza dell'organizzazione come un tutto:

• Nuovo asset non censito rilevato in rete OT
• Comunicazione verso IP esterni non previsti dalla baseline, originata da dispositivi OT
• Accesso remoto a dispositivi OT fuori dalle finestre autorizzate o senza ticket
• Modifica alla configurazione di PLC o HMI (soprattutto fuori dalla manutenzione pianificata)
• Comportamento di rete anomalo che potrebbe indicare movimento laterale (un dispositivo OT che inizia a comunicare con zone diverse da quelle abituali)
• Tentativi di autenticazione ripetuti verso dispositivi OT (brute force o scansione di credenziali)
• Rilevamento di strumenti di exploitation o scan attivi nella rete OT

Gestione operativa locale (non necessariamente al SIEM):

• Anomalie di performance di processo che non hanno implicazioni di sicurezza immediate
• Alert di disponibilità dei dispositivi OT (un PLC che non risponde: problema operativo, non necessariamente sicurezza)
• Statistiche di traffico e utilizzo di banda (monitoraggio operativo, non detection)
• Variazioni minori della baseline che rientrano nel normale comportamento dell'impianto durante cambi di produzione

La configurazione dei filtri di esportazione verso il SIEM va fatta con il team OT e revisionata periodicamente: un evento che oggi sembra rumore potrebbe diventare rilevante dopo un incidente che ne ha mostrato il significato.

Il valore della correlazione IT-OT

Il caso d'uso più potente dell'integrazione OT-SIEM non è il monitoraggio OT in sé, che può essere fatto localmente. È la correlazione tra eventi IT e OT.

Un esempio concreto: un alert di phishing segnala che un utente dell'ufficio ha aperto un allegato sospetto e ha contattato un dominio di comando e controllo. Questo evento rimane nel dominio IT. Poche ore dopo, un host nella rete IT inizia una scansione verso la rete OT su porte Modbus. Questo secondo evento, da solo, potrebbe sembrare un comportamento benigno di qualche script di monitoring mal configurato. Ma correlato con l'evento di phishing precedente, nello stesso timeframe, sullo stesso subnet di origine, diventa un segnale forte di movimento laterale verso l'OT.

La correlazione richiede che entrambi gli eventi siano nel SIEM nello stesso momento, con timestamp coerenti e con identificatori comuni (almeno l'indirizzo IP sorgente) che permettano al motore di correlazione di legarli. Senza la visibilità OT nel SIEM, il secondo evento non esiste, la catena di attacco rimane invisibile, l'analyst IT non vede niente di anomalo.

Questo scenario non è teorico: la maggior parte degli attacchi significativi agli ambienti industriali negli ultimi anni ha seguito la catena IT-OT, partendo da email, VPN o supply chain per poi muoversi verso i sistemi di controllo. Rilevare questo movimento richiede dati integrati.

Formare gli analisti SOC sull'OT

Portare gli eventi OT nel SIEM è la parte tecnica. La parte organizzativa è garantire che gli analisti SOC sappiano cosa farne.

Un analista SOC IT che vede per la prima volta un alert "function code Modbus 6 (Write Single Register) da host non in whitelist verso PLC zona 3" non ha il contesto per capirne la gravità. Potrebbe chiuderlo come rumore, o escalarlo senza sapere a chi. Il training necessario non è un corso completo di automazione industriale: è una comprensione sufficiente del contesto OT per fare la triage.

Gli elementi fondamentali che un analista SOC dovrebbe avere per gestire gli alert OT:

Mappa delle zone OT e della loro criticità. Quale zona contiene i sistemi più critici per la continuità produttiva? Un alert che coinvolge la zona di supervisione del processo principale ha priorità diversa da uno che coinvolge la rete di uffici tecnici. La mappa deve essere disponibile nel SIEM o in un documento di riferimento accessibile durante la triage.

Lista dei protocolli OT e del loro significato di base. Non serve conoscere il protocollo Modbus in dettaglio, ma capire che una scrittura su registro di controllo su un PLC di produzione è un'azione che può cambiare il comportamento del processo fisico. Questa consapevolezza cambia la priorità dell'alert.

Contatti operativi per l'escalation OT. Quando un analista SOC identifica un alert OT che non riesce a classificare, deve sapere a chi rivolgersi: il responsabile OT, il CISO con background industriale, il vendor dei sistemi di controllo. L'escalation path deve essere documentato nei playbook.

Playbook specifici per le tipologie di alert OT più frequenti. Non i playbook IT generici adattati, ma playbook scritti specificamente per il contesto OT: cosa fare quando appare un nuovo dispositivo non autorizzato, cosa fare quando una sessione di accesso remoto parte fuori orario, cosa fare quando viene rilevato traffico di scansione verso la rete OT.

Le sfide pratiche dell'integrazione

Portare il monitoring OT nel SIEM è tecnicamente fattibile nella maggior parte degli ambienti, ma alcune sfide pratiche meritano attenzione.

Connettività di rete tra OT e SIEM: il collector OT che aggrega gli eventi deve avere connettività verso il SIEM, che spesso è nell'IT o nel cloud. Questa connettività deve passare attraverso la DMZ industriale con regole precise, non aprire una connessione diretta tra OT e IT.

Volume di eventi e costi di licensing SIEM: alcuni SIEM scalano il costo sul volume degli eventi ingestiti. Prima di portare tutto il traffico OT nel SIEM, è necessario stimare il volume e filtrare correttamente per non incorrere in costi imprevisti.

Latenza degli alert: se il SIEM è cloud-hosted e il collector OT è on-premise, il percorso dell'evento (OT collector -> DMZ -> internet -> SIEM cloud -> analista) può introdurre latenza. Per la maggior parte degli alert OT questa latenza è accettabile (si parla di secondi o minuti), ma va verificata che non superi le soglie di SLA definite per gli alert critici.

Retention dei log OT: alcuni requisiti di compliance (NIS2, IEC 62443) richiedono che i log di sicurezza siano conservati per periodi definiti. Il SIEM deve essere configurato con policy di retention adeguate per gli eventi OT, che possono avere volume e struttura diversi dagli eventi IT.

L'integrazione OT-SIEM non è un progetto da completare in un weekend, ma è uno degli investimenti che porta il valore di moltiplicatore rispetto alle capacità già esistenti: un SOC che era parzialmente cieco diventa in grado di vedere l'intera superficie di attacco dell'organizzazione.

L'angolo MON5

Un SOC cieco sulla metà OT dell'azienda ha bisogno prima di tutto di una sorgente dati affidabile. MON5 nasce per questo ruolo: NDR passivo fuori banda che decodifica i protocolli OT nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) e genera eventi già filtrati e contestualizzati, pronti per la correlazione IT-OT nel SIEM esistente.

L'architettura multi-tenant e multi-sito si adatta inoltre ai SOC gestiti da MSSP e ai gruppi industriali con più stabilimenti. Per capire quali eventi OT mancano oggi al tuo SOC, il punto di partenza è un assessment OT.