In un impianto industriale un incidente cyber non coincide sempre con un furto di dati o con un sistema indisponibile. Può tradursi in una linea che rallenta, un PLC che riceve un comando inatteso, una stazione di supervisione che perde visibilità o una manutenzione remota che apre un percorso non previsto. La OT Threat Detection serve a intercettare questi segnali prima che diventino interruzioni, problemi di safety o fermi produzione.
L'urgenza nasce dal fatto che la minaccia non è più confinata al perimetro IT. L'ENISA Threat Landscape 2025, basato su 4.875 incidenti analizzati tra luglio 2024 e giugno 2025, indica che lo sfruttamento di vulnerabilità pesa per il 21,3% dei vettori di accesso iniziale osservati e che il manifatturiero resta tra i settori europei monitorati. Questo scenario mette in evidenza un principio fondamentale: in ambienti in cui sistemi industriali, connessioni remote e infrastrutture IT sono sempre più interconnessi, non è sufficiente conoscere le vulnerabilità presenti. È necessario essere in grado di osservare il comportamento degli asset e rilevare tempestivamente anomalie, deviazioni operative e attività potenzialmente malevole prima che producano un impatto sul processo produttivo.
La sicurezza degli ambienti OT si basa su esigenze e vincoli profondamente diversi da quelli tipici dell'IT e non può essere affrontata semplicemente replicando gli stessi modelli di protezione. Negli impianti industriali la priorità è garantire la continuità operativa, la sicurezza fisica delle persone e degli impianti, la massima disponibilità dei sistemi di produzione e il rispetto di finestre di manutenzione spesso estremamente limitate. A ciò si aggiunge la presenza di tecnologie legacy che, per ragioni operative o di certificazione, non possono essere aggiornate con regolarità né sottoposte a controlli invasivi. Per questo motivo, le soluzioni di sicurezza OT devono essere progettate per adattarsi al contesto industriale, minimizzando l'impatto sui processi produttivi e preservandone affidabilità e stabilità.
Un controllo efficace non può creare più rischio di quello che intende ridurre. Scansioni aggressive, agent installati senza valutazione, patch non testate o segmentazioni introdotte senza conoscere il processo possono disturbare apparati sensibili. Per questo la detection OT privilegia monitoraggio passivo, lettura del traffico, baseline comportamentale e correlazione con il contesto di produzione.
L'infrastruttura OT è costituita da un insieme eterogeneo di componenti interconnessi: PLC, SCADA, HMI, historian, gateway, sensori IIoT, sistemi MES accessi remoti dei fornitori e reti di stabilimento. Ciascuno di questi elementi rappresenta un potenziale punto di esposizione e contribuisce a definire una superficie di attacco ampia e distribuita. In questo contesto, una modifica non autorizzata a una regola firewall, un account di manutenzione lasciato attivo oltre il necessario o un protocollo industriale privo di un'adeguata segmentazione possono consentire a un attaccante di effettuare movimenti laterali fino a raggiungere gli asset più critici dell'impianto.
Per questo motivo, la OT Threat Detection non può limitarsi ad analizzare eventi isolati, ma deve comprendere le relazioni tra dispositivi, utenti e processi industriali. Un messaggio Modbus, Profinet o di un altro protocollo OT non è sospetto per sua natura: assume rilevanza quando proviene da un host non previsto, viene inviato in una fascia oraria inconsueta, richiama funzioni raramente utilizzate oppure si inserisce in una sequenza di comunicazioni che si discosta dal normale comportamento operativo dell'impianto. La capacità di contestualizzare ogni evento rispetto alla baseline produttiva è ciò che consente di distinguere una normale attività di processo da un potenziale comportamento malevolo.
Nelle reti OT gli attacchi non si presentano sempre come eventi rumorosi. Spesso iniziano con ricognizione, accessi impropri, variazioni minime del traffico o comandi che sembrano legittimi se osservati senza contesto.
Un segnale debole può essere un nuovo asset che parla con un PLC, un HMI che avvia richieste fuori sequenza, un protocollo mai visto in precedenza sulla rete, un aumento di query verso l'historian o un tentativo di enumerare dispositivi. Il valore della detection sta nel riconoscere che cosa è normale per quell'impianto, non per una rete industriale astratta.
La matrice MITRE ATT&CK for ICS organizza tecniche specifiche per ambienti industriali, dalla ricognizione al movimento laterale fino all'impatto sui processi. Usarla come riferimento aiuta a non limitare il monitoraggio ai soli indicatori noti di compromissione: serve mappare tattiche e comportamenti possibili.
Molti incidenti OT passano da canali legittimi. VPN di manutenzione, account fornitori, jump server, strumenti di teleassistenza e connessioni temporanee sono necessari, ma introducono rischio quando non sono tracciati, segmentati e revocati correttamente. Un accesso remoto non presidiato può diventare il modo più rapido per raggiungere un asset che non dovrebbe mai essere esposto.
Ogni accesso tecnico deve avere owner, durata, perimetro, autorizzazione e log. Senza questi elementi, la detection vede traffico, ma non riesce a distinguere una manutenzione attesa da una sessione anomala.
Una detection industriale efficace combina visibilità tecnica e conoscenza del processo. Non produce valore se genera centinaia di alert indistinti: deve aiutare a capire priorità, impatto e azione possibile.
Il monitoraggio passivo legge il traffico senza interferire con gli asset. Permette di costruire un inventario, mappare le comunicazioni, riconoscere protocolli industriali, individuare nuovi dispositivi e segnalare variazioni rispetto al comportamento atteso. È una scelta prudente perché riduce il rischio di impatto operativo, soprattutto su apparati legacy o non certificati per agent esterni.
Il valore non sta solo nella visibilità. Sta nella possibilità di collegare evento, asset e funzione: un comando verso un PLC di una linea critica richiede una priorità diversa rispetto a una comunicazione anomala su un segmento secondario.
La baseline deve essere costruita sul comportamento reale dell'impianto: orari di produzione, cicli, cambi formato, manutenzioni, fermate programmate, ruoli degli asset e flussi tra zone. Solo così un alert smette di essere un'anomalia tecnica e diventa un segnale operativo.
La prioritizzazione richiede almeno tre criteri: criticità dell'asset, deviazione dal comportamento atteso e potenziale impatto su continuità o safety. Se manca uno di questi livelli, il rischio è trattare allo stesso modo un falso positivo e un evento che può propagarsi verso la produzione.
La OT Threat Detection non dovrebbe rimanere confinata all'interno dello stabilimento, ma integrarsi con l'intero ecosistema di cybersecurity aziendale. I dati raccolti dagli ambienti industriali devono poter alimentare il Security Operations Center (SOC), integrandosi con piattaforme SIEM, servizi di threat intelligence, processi di vulnerability management e attività di incident response. La terza revisione del NIST Cybersecurity Framework colloca infatti la risposta agli incidenti all'interno di una visione più ampia della gestione del rischio cyber, nella quale una visione unificata degli eventi provenienti dai domini IT e OT consente di individuare attacchi complessi che attraversano entrambi gli ambienti e di coordinare una risposta efficace.
Per l'OT questo collegamento è decisivo: il SOC può correlare segnali IT e OT, ma la risposta deve coinvolgere chi conosce l'impianto. Un isolamento tecnicamente corretto può essere operativo solo se tiene conto di produzione, safety e sequenza di ripristino.
La risposta OT deve essere precisa. L'obiettivo non è reagire più forte, ma intervenire nel punto giusto con il minore impatto possibile.
Il triage deve distinguere tra:
Isolare un segmento, revocare un accesso vendor, bloccare una comunicazione o passare a modalità manuale sono decisioni che richiedono criteri predefiniti. I playbook devono quindi essere scritti insieme da security, IT, responsabili di stabilimento, manutenzione e fornitori critici.
Un buon playbook non si limita a dire che cosa fare. Definisce chi approva, quali asset non interrompere, quali log preservare, quali comunicazioni attivare e quali condizioni permettono il ritorno alla normalità.
La detection OT fallisce quando ogni funzione guarda solo il proprio pezzo. La security vede l'alert, l'IT vede la rete, la produzione vede l'impatto, il manutentore conosce il comportamento reale dell'asset. Serve un linguaggio comune che metta insieme rischio cyber e rischio operativo.
Il segnale di maturità è la capacità di decidere in pochi minuti se un evento è compatibile con una manutenzione, se richiede escalation o se va contenuto subito. Questa capacità non nasce durante l'incidente: si costruisce con inventari aggiornati, esercitazioni e responsabilità chiare.
Per molte organizzazioni industriali, presidiare internamente tutte le competenze OT security è difficile. Servono conoscenza dei protocolli, capacità SOC, threat intelligence, esperienza di incident response e comprensione dei vincoli di impianto. Un modello gestito può avere senso quando porta continuità di monitoraggio, competenze specialistiche e playbook già integrati con le operations.
In Relatech, il ReSOC rappresenta un Security Operations Center evoluto, orientato ai servizi di Managed Detection and Response (MDR), Endpoint Detection and Response (EDR) e alla protezione degli ambienti cyber, inclusi quelli OT. Questo approccio risponde a un'esigenza concreta: integrare capacità di rilevazione, monitoraggio continuo, risposta agli incidenti e competenze industriali, senza richiedere alle organizzazioni di realizzare e gestire autonomamente un presidio di sicurezza completo.
La OT Threat Detection non elimina il rischio industriale, ma riduce il tempo in cui l'organizzazione resta cieca davanti a un comportamento anomalo. In ambienti in cui anche pochi minuti possono incidere su produzione, safety e continuità, questa riduzione dell'ambiguità è già una forma di resilienza