Anomaly detection in OT: costruire la baseline e gestire i falsi positivi

Perché l'OT dovrebbe essere l'ambiente ideale per l'anomaly detection

L'anomaly detection si basa su un principio semplice: stabilire cosa è normale, poi rilevare le deviazioni. Più l'ambiente è prevedibile, più questa tecnica funziona bene: la baseline è stabile, le deviazioni sono nette, e il segnale si distingue facilmente dal rumore.

Da questo punto di vista, gli ambienti OT sembrano un caso ideale. Una linea di produzione che funziona a regime ha pattern di comunicazione estremamente ripetitivi: il PLC A legge i valori dall'I/O ogni 100ms, il server SCADA interroga i PLC ogni 5 secondi, l'historian raccoglie i dati ogni minuto. Questi cicli si ripetono con variazioni minime per settimane, mesi, anni. La matrice di comunicazione (quali dispositivi parlano con quali altri, su quali porte, con quale frequenza) è stabile e documentabile.

Questa prevedibilità è sia il punto di forza dell'anomaly detection in OT sia, come vedremo, la fonte principale delle sue difficoltà. Perché l'ambiente è prevedibile nella modalità operativa normale, ma è soggetto a eventi eccezionali legittimi che da soli bastano a mandare in saturazione un sistema di alerting non correttamente calibrato.

Il problema dei comportamenti legittimi anomali

Ogni impianto produttivo ha eventi ricorrenti che rompono i pattern normali in modo del tutto legittimo. Il fatto che siano legittimi non li rende meno "anomali" dal punto di vista di un sistema di detection che osserva il traffico di rete.

Manutenzioni programmate: durante un fermo di manutenzione, i pattern di comunicazione cambiano radicalmente. Tecnici si connettono a dispositivi con cui non comunicavano. Si caricano nuovi parametri sui PLC. Si eseguono test che generano traffico insolito. Un sistema di anomaly detection non calibrato genererà decine o centinaia di alert durante ogni finestra di manutenzione.

Aggiornamenti di firmware e software: l'aggiornamento del software di un HMI o del firmware di un dispositivo di campo genera traffico che non esiste nella modalità operativa normale. Se l'aggiornamento avviene fuori dalle finestre di manutenzione abituali, per esempio per una patch urgente, il pattern è doppiamente anomalo.

Test e commissioning: quando si aggiunge un nuovo macchinario o si modifica una linea, la fase di commissioning genera traffico completamente diverso dalla baseline. Nuovi dispositivi appaiono in rete, nuove comunicazioni vengono stabilite, i tecnici si muovono sulla rete in modo atipico.

Variazioni stagionali: in alcuni settori manifatturieri, i volumi di produzione variano significativamente durante l'anno. Una variazione nel ritmo produttivo si traduce in variazioni nei pattern di comunicazione: diversi cicli di polling, diversi volumi di dati, diversa frequenza di operazioni.

Operazioni straordinarie: produzioni in urgenza fuori orario, doppi turni, test di processo non standard. Tutti eventi legittimi che rompono i pattern normali.

Ognuno di questi eventi, se il sistema di anomaly detection non ne è a conoscenza, genera alert. Un sistema che genera decine di alert per ogni manutenzione programmata, in un impianto che fa manutenzioni settimanali, smette di essere utile molto rapidamente. Gli analisti imparano a ignorare gli alert durante i fermi di manutenzione, il che crea esattamente la finestra di opportunità che un attaccante potrebbe voler sfruttare.

Come costruire una baseline accurata

Costruire una baseline affidabile per un ambiente OT richiede un approccio metodico che va oltre il semplice "osserva il traffico per due settimane".

Il periodo di osservazione deve essere sufficientemente lungo. Un periodo di due settimane cattura i pattern giornalieri e settimanali, ma non i cicli mensili o stagionali. Per un impianto con cadenze mensili significative (fine mese, chiusura inventari, manutenzioni mensili pianificate) sono necessarie almeno sei-otto settimane di osservazione prima che la baseline sia rappresentativa. Per ambienti con variazioni stagionali marcate, il periodo ottimale è ancora più lungo.

La baseline deve distinguere i profili temporali. Una baseline che tratta allo stesso modo il traffico del lunedi mattina e del sabato notte sarà imprecisa per entrambi. Un modello di baseline sofisticato tiene separati i profili di traffico per fascia oraria e giorno della settimana, costruendo un'immagine del "normale" che rispecchia la struttura temporale reale dell'impianto.

Le eccezioni documentate vanno integrate esplicitamente. Il calendario delle manutenzioni programmate deve essere integrato con il sistema di detection: durante le finestre di manutenzione, alcuni alert vengono soppressi o il loro livello di confidenza viene abbassato. Questo non significa ignorare la manutenzione: significa non generare centinaia di alert per eventi previsti e pianificati.

La baseline deve essere specifica per coppia di host, non generica per rete. Una baseline che tratta l'intera rete OT come un unico blob statistico perde la granularità necessaria per rilevare comportamenti anomali di singoli dispositivi. La baseline significativa risponde a domande come: "il PLC della linea 3 ha mai comunicato direttamente con il server di storico?" oppure "è normale che il pannello HMI in sala controllo si connetta a questa subnet?".

Il tasso di falsi positivi come metrica principale

Nei progetti di anomaly detection OT, il tasso di falsi positivi è la metrica che più spesso determina il successo o il fallimento. Non il numero di veri positivi, che nelle prime settimane di deployment è spesso basso semplicemente perché non si verifica nessun attacco, ma il numero di falsi positivi che gli analisti devono processare ogni giorno.

Un sistema che genera cinquanta alert al giorno, di cui quarantacinque sono falsi positivi, è un sistema disfunzionale. Gli analisti imparano rapidamente che la maggior parte degli alert non vale il tempo di investigarli, sviluppano euristiche informali per decidere cosa ignorare, e nel processo possono perdere i cinque alert reali nel rumore.

Il target realistico per un sistema di anomaly detection OT maturo varia con il contesto, ma in generale un sistema che richiede investigazione manuale di più di dieci-quindici alert al giorno per ogni analista è già vicino al limite di sostenibilità. Sotto quella soglia, ogni alert riceve attenzione adeguata. Sopra, si entra in modalità triage dove la qualità dell'analisi degrada.

Raggiungere un tasso di falsi positivi accettabile richiede tempo: le prime settimane dopo il deployment di un nuovo sistema di anomaly detection sono sempre caratterizzate da volumi alti. Il miglioramento avviene attraverso l'analisi sistematica degli alert (cosa sta scatenando questo alert? è un pattern che doveva essere incluso nella baseline?) e l'affinamento progressivo delle regole e della baseline stessa.

Integrazione con il calendario operativo

L'integrazione tra il sistema di monitoring e il calendario operativo dell'impianto è uno degli accorgimenti pratici con il maggiore impatto sulla qualità della detection.

Il principio è semplice: il sistema di detection deve sapere cosa è pianificato. Se è prevista una manutenzione sabato dalle 6 alle 14, il sistema deve applicare regole diverse durante quella finestra temporale: non ignorare gli alert, ma contestualizzarli diversamente, abbassare la priorità degli alert di classe "nuove comunicazioni" e alzare la priorità degli alert di classe "comunicazioni verso destinazioni esterne" (che durante una manutenzione pianificata non hanno giustificazione).

Questa integrazione richiede un processo: qualcuno deve inserire le finestre di manutenzione nel sistema prima che avvengano, e qualcuno deve verificare che il sistema abbia ricevuto correttamente l'informazione. Non è un'automazione completa, richiede disciplina operativa, ma il beneficio in termini di riduzione dei falsi positivi è significativo.

Un livello più avanzato di integrazione prevede la correlazione con il sistema ERP o di pianificazione della produzione per rilevare automaticamente le variazioni nei turni e nei ritmi produttivi, e adattare di conseguenza le soglie di alerting. Questo riduce ulteriormente il rumore nelle transizioni operative.

Quando un sistema non converge

Alcuni ambienti OT presentano una sfida specifica: sono strutturalmente rumorosi, cioè hanno un livello di variabilità nei pattern di comunicazione che rende difficile stabilire una baseline stabile. Le cause più comuni sono ambienti con frequenti cambi di produzione (multi-prodotto con setup diversi), impianti con molti dispositivi legacy che hanno comportamenti irregolari per design, o reti OT mal segmentate dove traffico di natura diversa si mescola sugli stessi segmenti.

In questi casi, l'anomaly detection pura, basata unicamente sulla deviazione dalla baseline, non è sufficiente da sola. Deve essere integrata con regole di detection basate su firme e comportamenti specifici: non "questo traffico è diverso da ieri" ma "questo dispositivo sta usando function code di scrittura Modbus verso un registro che non ha mai scritto in sei mesi". Le regole signature-based sono meno dipendenti dalla stabilità della baseline e più robuste in ambienti variabili.

La combinazione di anomaly detection e regole di detection firmate è l'approccio più robusto nella maggior parte degli ambienti reali: l'anomaly detection cattura le deviazioni non previste dalle regole, le regole catturano i comportamenti specificamente pericolosi indipendentemente dal contesto di baseline.

L'angolo MON5

La qualità di un sistema di anomaly detection si gioca sulla baseline, ed è qui che si concentra la fase PROTECT di MON5: l'NDR passivo fuori banda osserva i protocolli OT nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) e i modelli di machine learning costruiscono profili di comunicazione per coppia di host, non per rete intera.

Il presupposto, però, è conoscere l'ambiente: la fase DISCOVER raccoglie traffico e topologia senza toccare i dispositivi, fornendo la base su cui calibrare la detection. Se vuoi capire da quale baseline parte il tuo impianto, il primo passo è un assessment OT.