Lo SCADA historian come vettore di attacco laterale dall'IT all'OT

Il ruolo dello historian nella rete industriale

Lo SCADA historian, chiamato anche process historian o data historian, è un componente presente in quasi tutti gli impianti industriali di media e grande dimensione. Il suo ruolo è raccogliere e archiviare in modo continuo i dati di processo provenienti dai sistemi di controllo: valori di temperatura, pressione, portata, stato delle macchine, allarmi, eventi operativi. Tutto quello che succede nell'impianto finisce nello historian, campionato a intervalli che possono andare dai secondi ai decimi di secondo per le variabili più critiche.

I prodotti più diffusi in ambito europeo includono PI System di OSIsoft (ora AVEVA), AVEVA Process Historian (ex Wonderware), e altri sistemi sviluppati da vendor di automazione come Siemens e Rockwell. Ogni sistema ha le proprie specificità tecniche, ma la funzione è la stessa: essere il repository centralizzato della memoria storica del processo industriale.

Questa funzione rende lo historian indispensabile: serve al reparto operations per analizzare le performance di processo, al reparto manutenzione per correlare anomalie meccaniche con i dati storici, alla qualità per le analisi di conformità, alla direzione per i KPI produttivi. Lo historian non è un sistema di nicchia: è l'infrastruttura dati su cui si appoggiano decisioni operative quotidiane.

Il problema architetturale: un piede in due reti

Per fare quello che deve fare, lo historian deve comunicare con entrambi i mondi: raccoglie dati dalla rete OT (dove vivono i PLC, i sistemi di controllo, i sensori) e li espone alla rete IT (dove vivono i sistemi di business, i client di reportistica, le dashboard per la direzione).

Questa posizione a cavallo tra le due reti è la ragione della sua utilità e, allo stesso tempo, la fonte del suo rischio dal punto di vista della sicurezza. In architetture progettate bene, lo historian si trova in una DMZ industriale, una zona separata che permette la comunicazione controllata tra OT e IT senza connettività diretta tra le due reti. In architetture meno curate, che sono più comuni di quanto si vorrebbe, lo historian ha interfacce attive sia nella rete OT sia nella rete IT senza una separazione significativa.

Anche nella versione DMZ, lo historian è comunque un sistema che ha visibilità sulla rete OT. Ha connessioni aperte verso i server OPC (che aggregano i dati dai PLC), verso i gateway di campo, talvolta verso i PLC stessi. Se un attaccante riesce a compromettere lo historian, ha automaticamente accesso a queste connessioni.

Il percorso di attacco: da IT a OT attraverso lo historian

Il movimento laterale dall'IT all'OT attraverso lo historian è un vettore documentato, non speculativo. La catena di attacco segue passi logici e relativamente semplici per chi ha competenze offensive.

Passo 1: compromissione di un sistema IT

Il punto di ingresso iniziale è tipicamente nella rete IT: un'email di phishing che installa un ransomware o un RAT su un computer dell'ufficio, la compromissione di un account VPN attraverso credenziali rubate, lo sfruttamento di una vulnerabilità su un sistema esposto. L'attaccante ottiene un foothold nella rete IT aziendale.

Passo 2: ricognizione e identificazione dello historian

Una volta nella rete IT, l'attaccante esegue ricognizione: scansione della rete per identificare host, servizi, connessioni. Lo historian si identifica facilmente: porta TCP 5450 per PI System, la presenza di servizi OPC o DCOM specifici, il nome dell'host che spesso include varianti di "historian", "pi-server", "scada-server". Non è difficile trovarlo.

Passo 3: sfruttamento dello historian

Qui entrano in gioco diversi vettori possibili. Lo historian gira spesso su Windows Server e può avere vulnerabilità del sistema operativo non patchate, configurazioni deboli dei servizi, o credenziali di accesso deboli all'interfaccia applicativa. Alcuni sistemi historian hanno avuto CVE specifiche nel corso degli anni, alcune con exploit pubblici disponibili.

Alternativa più semplice: se lo historian usa credenziali di default o credenziali condivise con altri sistemi già compromessi, l'accesso non richiede nemmeno uno sfruttamento tecnico complesso.

Passo 4: accesso alla rete OT

Una volta compromesso lo historian, l'attaccante eredita tutte le sue connessioni. Può raggiungere i server OPC a cui lo historian è connesso, e attraverso di essi, se la segmentazione non è rigorosa, i PLC e i dispositivi di campo. Può leggere i dati di processo in tempo reale, identificare i sistemi di controllo presenti, studiare il layout del processo industriale.

Passo 5: potenziale manipolazione

Nella fase più avanzata, un attaccante con accesso ai server OPC può non limitarsi a leggere: alcune configurazioni permettono di scrivere valori, modificare setpoint, inviare comandi ai dispositivi di campo attraverso gli stessi canali che il sistema di controllo usa normalmente. Questa capacità dipende dalla configurazione specifica dell'installazione (non tutte le installazioni hanno scrittura abilitata) ma è una possibilità reale in ambienti dove la separazione dei ruoli e le autorizzazioni non sono configurate con attenzione.

Perché questo vettore è sottovalutato

Lo historian tende a essere gestito dal reparto IT o da un reparto operativo specializzato, non dal team OT. È percepito come un sistema IT, gira su Windows, si gestisce come un server, e quindi viene incluso nei processi di patching e backup IT. Ma le sue connessioni verso la rete OT e le sue interazioni con i protocolli di campo lo rendono un sistema ibrido, con implicazioni di sicurezza che né il team IT né il team OT tipicamente gestisce completamente.

Il team IT non sa esattamente a cosa si connette lo historian nella rete OT, e non ha gli strumenti per monitorare quelle connessioni. Il team OT sa che lo historian raccoglie i dati ma lo considera un sistema "del lato IT" e non lo include nel suo perimetro di monitoraggio. Il risultato è un sistema critico che cade in uno spazio grigio di responsabilità e visibilità.

Cosa monitorare: i segnali nel traffico

Il monitoraggio del traffico verso e dallo historian è uno dei controlli con il miglior rapporto costo/beneficio per le reti industriali che hanno questo componente.

Connessioni verso lo historian da host non previsti

Il traffico normale verso un historian ha origini prevedibili: i client di reportistica, le dashboard, i sistemi di business intelligence, i processi di backup. Una connessione da un host che non fa parte di questo insieme (un laptop, un server IT con una funzione diversa, un sistema che normalmente non si connette allo historian) è un segnale da investigare.

Query insolite o volume anomalo di lettura

Lo historian risponde a query per recuperare serie storiche di dati. Un attaccante che sta facendo ricognizione per capire la struttura dell'impianto tende a fare query esplorative: chiedere l'elenco dei tag disponibili, recuperare dati di periodo per molte variabili diverse, interrogare metadati sulla configurazione. Questo pattern è diverso dalle query operative normali, che tendono a essere ripetitive e concentrate su un insieme limitato di variabili.

Export di grandi volumi di dati fuori orario

Una trasmissione di dati di processo verso una destinazione esterna o verso un host interno non previsto, soprattutto in orari fuori dalla normale attività operativa, è un indicatore di possibile esfiltrazione. Un attaccante che vuole capire il processo industriale prima di agire ha interesse a raccogliere serie storiche lunghe.

Connessioni originate dallo historian verso la rete OT fuori dalla baseline

Normalmente lo historian si connette a un insieme definito di server OPC e gateway di campo. Una nuova connessione verso un PLC o un segmento OT non previsto, soprattutto se originata in orari insoliti, indica che qualcuno sta usando lo historian come ponte per esplorare la rete OT.

Tentativi di autenticazione falliti all'interfaccia dello historian

Come per qualsiasi sistema con interfaccia di autenticazione, i tentativi falliti multipli, specialmente da sorgenti non abituali, sono il segnale di un tentativo di bruteforce o di uso di credenziali rubate non ancora corrette.

Misure architetturali per ridurre il rischio

Oltre al monitoraggio, alcune misure architetturali riducono strutturalmente il rischio legato allo historian.

DMZ industriale con unidirezionalità: in un'architettura robusta, lo historian si trova in una DMZ che riceve dati dalla rete OT ma non può initiare connessioni verso di essa. I dati fluiscono solo in uscita dalla rete OT. Questo si ottiene con firewall configurati per permettere solo le connessioni stabilite dalla parte OT, o con dispositivi di data diode hardware. Non elimina il rischio sulla DMZ, ma limita significativamente cosa un attaccante che ha compromesso lo historian può fare verso la rete OT.

Separazione degli account di lettura e scrittura: se l'architettura non consente la completa unidirezionalità, almeno gli account usati per la raccolta dati (lettura) devono essere separati da eventuali account con privilegi di scrittura. L'account con cui lo historian legge i dati dai PLC non deve avere permessi di scrittura.

Hardening del sistema operativo e del software historian: lo historian gira su Windows Server e deve essere incluso nei processi di patching IT. Non basta trattarlo come un server qualsiasi: le porte e i servizi specifici del software historian vanno configurati con attenzione, rimuovendo tutto il superfluo.

Revisione periodica delle connessioni attive: documentare e verificare periodicamente quali connessioni lo historian ha aperte verso la rete OT. Le connessioni legacy verso sistemi dismessi o verso indirizzi che non corrispondono più a nulla di noto vanno rimosse.

Lo historian è un esempio emblematico di come l'architettura di rete nelle industrie italiane si sia spesso evoluta per rispondere a esigenze operative senza un'analisi sistematica delle implicazioni di sicurezza. Non è un problema di progettazione malintenzionata: è il risultato di anni di decisioni ragionevoli prese in isolamento, che nel complesso creano un vettore di rischio significativo. Capirlo è il primo passo per gestirlo.

L'angolo MON5

Monitorare lo historian significa conoscere le sue connessioni legittime e accorgersi quando ne compaiono di nuove: esattamente il tipo di controllo che MON5 esegue con il NDR passivo fuori banda. La piattaforma osserva il traffico tra historian, server OPC e rete di controllo sui protocolli OT nativi, costruisce la baseline delle comunicazioni e segnala con l'anomaly detection ML le connessioni fuori pattern, le query esplorative e gli export anomali.

Il primo passo, però, è mappare davvero quel ponte tra IT e OT: quante connessioni ha lo historian, verso cosa, da quando. Un assessment OT lo chiarisce senza toccare i sistemi in produzione.