Un ransomware che cifra i server aziendali blocca le email e i file. Un altro ransomware che raggiunge i sistemi di controllo di uno stabilimento produttivo può fermare le linee, danneggiare i macchinari e compromettere la sicurezza fisica degli operatori.
La differenza non è di grado, ma di natura. Ed è questa differenza che rende la OT Security una disciplina che non può essere gestita con gli stessi strumenti, gli stessi processi e la stessa cultura con cui si gestisce la cyber security IT tradizionale.
Eppure, nella maggior parte delle organizzazioni industriali italiane, è esattamente quello che accade, con rischi che il Rapporto Clusit documenta in modo impietoso: il settore manifatturiero è tra i più colpiti e gli attacchi agli impianti produttivi sono in crescita costante.
Indice degli argomenti
Cos’è la OT Security e perché differisce dalla cyber security IT tradizionale
La OT Security (Operational Technology Security) è la disciplina che si occupa della protezione dei sistemi hardware e software che monitorano e controllano i processi fisici nelle infrastrutture industriali e critiche.
Non è un sottoinsieme della cyber security IT, ma un dominio con caratteristiche proprie che derivano dalla natura stessa dei sistemi che protegge.
I sistemi OT non elaborano dati aziendali: controllano processi fisici come la temperatura di un forno, la pressione in un gasdotto, la velocità di una linea di assemblaggio, il flusso in una rete idrica.
Di conseguenza, se un errore nei dati aziendali può causare problemi economici, un errore nel controllo di un processo fisico può causare danni materiali, incidenti ambientali e rischi per la vita umana.
Definizione di Operational Technology e ambiti di applicazione industriale
Con il termine Operational Technology si intende l’insieme di hardware e software dedicato al rilevamento o alla gestione delle apparecchiature, degli asset e dei processi nelle infrastrutture produttive e critiche.
In questo perimetro rientrano i sistemi SCADA (Supervisory Control and Data Acquisition), i PLC (Programmable Logic Controller), i DCS (Distributed Control Systems), i sistemi HMI (Human-Machine Interface), i dispositivi IIoT (Industrial Internet of Things) e le reti di automazione industriale che li collegano.
Gli ambiti di applicazione sono vastissimi: manifatturiero, energia (reti elettriche, raffinerie, gasdotti), trasporti (ferrovie, aeroporti, porti), acqua e acque reflue, settore farmaceutico, agroalimentare, difesa. In tutti questi contesti, la OT Security presidia il confine tra il mondo digitale del controllo e il mondo fisico dei processi.
I sistemi OT sono stati progettati decenni fa per operare in ambienti isolati e prevedibili, con cicli di vita di 15-30 anni, protocolli di comunicazione proprietari e nessuna connettività esterna. La sicurezza era garantita dall’isolamento fisico (il cosiddetto air gap) e non da meccanismi crittografici o di autenticazione.
Questo contesto è radicalmente cambiato con l’avvento dell’Industria 4.0, che ha progressivamente integrato i sistemi OT con le reti IT aziendali per abilitare la raccolta dei dati di produzione, il monitoraggio remoto e l’ottimizzazione dei processi.
Il risultato è un’esposizione ai rischi informatici per cui questi sistemi non erano stati progettati.
Le differenze chiave tra disponibilità dei processi e riservatezza dei dati
In ambito IT, la triade della sicurezza – riservatezza, integrità, disponibilità (CIA, Confidentiality, Integrity, Availability) – viene tradizionalmente prioritizzata in questo ordine: proteggere i dati riservati è la preoccupazione principale, seguita dall’integrità e dalla disponibilità.
In ambito OT, la priorità è invertita: la disponibilità viene prima di tutto, perché l’interruzione di un processo produttivo ha conseguenze immediate e concrete. Un sistema SCADA che va offline per applicare una patch di sicurezza è un sistema che interrompe la produzione: una prospettiva inaccettabile in molti contesti industriali dove la continuità operativa vale decine di migliaia di euro per ora di fermo.
Questa differenza di priorità si traduce in scelte operative concrete che chi proviene dal mondo IT fatica inizialmente a comprendere. In OT non si applica una patch critica entro 24 ore: si pianifica una finestra di manutenzione mesi in anticipo, si testa la patch in un ambiente di staging identico alla produzione, e la si applica solo quando il processo produttivo lo consente.
Non si riavvia un sistema OT per completare un aggiornamento in quanto un riavvio non pianificato può danneggiare un processo in corso. Non si installa un antivirus su un controller PLC perché potrebbe interferire con i cicli di controllo in tempo reale e causare malfunzionamenti.
Queste non sono negligenze di sicurezza, ma vincoli operativi che definiscono i confini entro cui la OT Security deve operare.
I principali rischi informatici per le infrastrutture produttive e critiche
Il panorama delle minacce per le infrastrutture OT è cambiato profondamente negli ultimi anni.
Fino al 2015 gli attacchi agli impianti industriali erano episodi rari, tecnicamente sofisticati e tipicamente attribuiti ad attori statuali: quello di Stuxnet, nel 2010 contro le centrifughe nucleari iraniane resta il caso di riferimento. Oggi la situazione è radicalmente diversa.
I gruppi ransomware hanno scoperto che le organizzazioni industriali hanno una tolleranza al fermo impianto molto bassa, il che le rende più propense a pagare rapidamente riscatti elevati.
Il risultato è che la minaccia OT non è più prerogativa di attori sofisticati con obiettivi geopolitici: è diventata una minaccia di massa, accessibile a gruppi criminali con capacità tecniche medie.
Impatto economico delle interruzioni della catena di fornitura e del fermo impianto
Il costo di un incidente che colpisce un sistema OT è sistematicamente più elevato di un incidente equivalente in ambito IT, per ragioni strutturali.
In primo luogo, il danno non si limita ai sistemi informatici: può estendersi ai processi fisici, causando danni ai macchinari, perdita di materiali in lavorazione, e in alcuni casi danni ambientali o rischi per la sicurezza degli operatori.
In secondo luogo, il ripristino di un sistema OT è tipicamente molto più lento di quello di un sistema IT: non si ripristina da un backup in poche ore, ma si riprogramma fisicamente i controller, si riverifica l’integrità dei parametri di processo, si esegue una messa in servizio graduale.
In terzo luogo, il fermo impianto ha un impatto immediato sulla catena di fornitura dei clienti, con conseguenti penali contrattuali e danni reputazionali.
Il caso Colonial Pipeline (2021) è il riferimento più citato per quantificare l’impatto economico: un ransomware che ha colpito la rete IT dell’operatore ha portato alla chiusura precauzionale dell’oleodotto principale degli Stati Uniti orientali per sei giorni, con un pagamento di riscatto di 4,4 milioni di dollari e danni complessivi stimati in centinaia di milioni.
In Italia, il Rapporto Clusit documenta incidenti al settore manifatturiero con costi medi che, includendo il fermo produttivo, il ripristino dei sistemi e il danno reputazionale, superano sistematicamente il milione di euro per eventi significativi.
Minacce derivanti da ransomware, accessi remoti e protocolli legacy
Il ransomware è oggi la minaccia più frequente e più costosa per le organizzazioni industriali.
La sua efficacia contro gli ambienti OT deriva da una combinazione di fattori: la sensibilità al fermo impianto che rende le organizzazioni propense a pagare rapidamente, la presenza di sistemi obsoleti con vulnerabilità non patchabili che facilitano la propagazione e la convergenza IT/OT che ha eliminato l’air gap che un tempo proteggeva i sistemi di controllo.
Il ransomware che colpisce un ambiente OT raramente cifra direttamente i controller PLC (non è questo il suo obiettivo), ma cifra i sistemi IT di supervisione (SCADA, HMI, historian) rendendo impossibile il monitoraggio e il controllo dei processi fisici, con effetti operativi equivalenti a un attacco diretto.
Gli accessi remoti ai sistemi OT sono diventati un vettore di attacco di primaria importanza durante e dopo la pandemia, quando la necessità di gestione remota degli impianti ha portato all’apertura di canali VPN e di accesso remoto spesso configurati in modo frettoloso e con controlli di sicurezza inadeguati.
Fornitori di manutenzione, system integrator, tecnici specializzati: tutti questi soggetti accedono regolarmente ai sistemi OT da remoto, spesso con credenziali condivise e senza MFA, attraverso canali che rimangono aperti permanentemente invece di essere attivati solo quando necessario.
I protocolli legacy (Modbus, DNP3, Profibus, OPC-DA) sono un’altra categoria di rischio strutturale: progettati per ambienti isolati, non includono meccanismi di autenticazione o cifratura, e la loro sostituzione è spesso impossibile senza sostituire l’intera infrastruttura di controllo.
Uno scenario di rischio
Il vettore più sottovalutato, quando si parla di OT security è il laptop del manutentore.
Un tecnico di manutenzione esterno accede all’impianto con il proprio laptop per aggiornare il firmware di un PLC. Il laptop ha un malware che si è diffuso nella rete del manutentore settimane prima. Connesso alla rete OT dell’impianto per l’aggiornamento, il malware si propaga ai sistemi di controllo.
L’impianto non ha rilevamento delle anomalie in rete OT: il malware rimane dormiente per settimane prima di attivarsi.
Questo scenario, documentato in varianti reali in diversi incidenti industriali, è prevenibile con controlli relativamente semplici: laptop aziendali dedicati per l’accesso OT (non i laptop personali dei manutentori), verifica dell’integrità del dispositivo prima della connessione, rete OT segmentata con accesso limitato alle sole funzioni necessarie, log completi di ogni accesso.
Il nodo della convergenza IT e OT nell’era dell’Industria 4.0
La convergenza IT/OT è la trasformazione che ha reso urgente la OT Security come disciplina aziendale. Fino a dieci anni fa, i sistemi OT erano fisicamente separati dalla rete IT aziendale: l’air gap garantiva che un attacco informatico alla rete office non potesse raggiungere i sistemi di controllo.
Con l’Industria 4.0, questa separazione è progressivamente scomparsa.
La raccolta in tempo reale dei dati di produzione per alimentare i sistemi ERP e MES, il monitoraggio remoto degli impianti, la manutenzione predittiva basata sull’analisi dei dati dei sensori, l’integrazione con i sistemi cloud dei fornitori: tutte queste funzionalità richiedono connettività tra la rete OT e la rete IT, abbattendo la barriera che un tempo proteggeva i sistemi di controllo.
Dalla separazione fisica dei sistemi all’integrazione delle reti aziendali
Il percorso verso la convergenza IT/OT non è avvenuto attraverso una decisione strategica centralizzata: è avvenuto gradualmente, attraverso decine di decisioni locali prese da team diversi per ragioni operative legittime.
Un sistema di telemetria qui, un accesso remoto per la manutenzione là, un’integrazione con il cloud del fornitore altrove: ogni singola connessione aveva una giustificazione valida, ma l’effetto cumulativo è stata la progressiva erosione dell’isolamento che proteggeva i sistemi OT.
Molte organizzazioni industriali hanno scoperto il reale stato della propria convergenza IT/OT solo durante un assessment di sicurezza e la scoperta è stata spesso sorprendente: connessioni non documentate, sistemi OT raggiungibili dalla rete aziendale attraverso percorsi non previsti, accessi remoti mai disabilitati.
La convergenza IT/OT, di per sé, non è un problema: è una necessità competitiva nell’Industria 4.0. Il problema è la convergenza non governata, non documentata e non presidiata da controlli di sicurezza adeguati.
Un’architettura di convergenza ben progettata, con segmentazione delle reti, controllo del traffico tra zone IT e OT, monitoraggio degli accessi e gestione sicura dei dati di produzione, consente di beneficiare dei vantaggi dell’integrazione mantenendo i rischi sotto controllo.
Una convergenza improvvisata e non governata è una superficie di attacco che gli attaccanti trovano e sfruttano sistematicamente.
Gestione della superficie di attacco e punti di vulnerabilità interconnessi
Nella convergenza IT/OT, i punti di vulnerabilità più critici sono i nodi di interconnessione tra i due mondi: i sistemi che hanno un piede in entrambe le reti e che possono diventare il trampolino attraverso cui un attaccante che ha compromesso la rete IT raggiunge i sistemi OT.
Gli historian, ossia i server che raccolgono i dati di processo dalla rete OT e li rendono disponibili alla rete IT per analisi e reportistica, sono un esempio tipico: risiedono in una zona grigia tra i due mondi e se compromessi consentono l’accesso sia alla rete IT sia alla rete OT.
I jump server per l’accesso remoto ai sistemi OT sono un altro punto critico: se un attaccante compromette il jump server, ha accesso a tutti i sistemi OT raggiungibili da quel punto.
La gestione della superficie di attacco in un ambiente IT/OT convergente richiede un inventario completo di tutti i dispositivi connessi (asset inventory) che includa non solo i sistemi IT tradizionali ma anche tutti i dispositivi OT: PLC, HMI, sensori IIoT, switch industriali, convertitori di protocollo.
Questo inventario è il prerequisito di qualsiasi strategia di sicurezza OT: non si può proteggere ciò che non si conosce.
In ambienti OT complessi con centinaia o migliaia di dispositivi, questo inventario richiede strumenti di discovery passivo specificamente progettati per i protocolli industriali, strumenti che possono identificare i dispositivi senza interagire attivamente con loro, evitando il rischio di interferire con i processi di controllo.
Governance della cyber security industriale e modelli di responsabilità aziendale
La governance della OT Security è l’area in cui le organizzazioni industriali mostrano i gap più significativi.
Il problema non è la consapevolezza del rischio (oggi quasi tutti i vertici industriali sanno che gli impianti sono esposti a rischi informatici), ma la distribuzione poco chiara delle responsabilità.
Chi è responsabile della sicurezza di un sistema SCADA? Il responsabile IT, che conosce la cybersecurity ma non i processi industriali? Il responsabile di produzione, che conosce gli impianti ma non la sicurezza informatica? Il fornitore del sistema, che conosce il prodotto ma non l’ambiente in cui opera?
In molte organizzazioni, la risposta implicita è «un po’ tutti», il che nella pratica significa «nessuno in modo definitivo».
Definizione delle competenze tra direttori di stabilimento e responsabili IT
La governance della OT Security richiede una definizione esplicita delle responsabilità tra le funzioni aziendali coinvolte e queste funzioni sono più numerose di quanto sembri.
Il CISO o il responsabile della sicurezza IT ha la competenza sulla cyber security ma non conosce i processi OT. Il responsabile di produzione o il direttore di stabilimento conosce gli impianti e i vincoli operativi ma non la cybersecurity. L’ingegnere di automazione conosce i sistemi di controllo ma spesso non ha una formazione sulla sicurezza informatica. Il fornitore dei sistemi OT conosce i propri prodotti ma non l’architettura complessiva del cliente.
La soluzione non è concentrare tutte queste competenze in una singola persona, ma definire un modello di responsabilità condivisa con ruoli chiari.
Il modello più efficace prevede un OT Security Manager (una figura con competenze ibride IT/OT, sempre più richiesta nel mercato e sempre più rara) che funge da interfaccia tra il mondo della cyber security e quello dell’automazione industriale.
In alternativa, per le organizzazioni che non possono permettersi questa figura interna, la collaborazione tra il CISO e un OT Engineer designato come referente per la sicurezza degli impianti, supportata da un MSSP (Managed Security Service Provider) specializzato in OT, è una soluzione pragmatica che molte organizzazioni di medie dimensioni stanno adottando.
Integrazione della sicurezza operativa nei piani di continuità aziendale
I piani di continuità aziendale (BCP, Business Continuity Plan) e i piani di disaster recovery (DRP) delle organizzazioni industriali sono stati storicamente costruiti intorno agli scenari di rischio fisico (incendi, allagamenti, guasti ai macchinari) e raramente includono scenari di incidente informatico agli impianti OT.
Questa lacuna è diventata critica con la crescita degli attacchi ransomware al settore industriale: un’organizzazione che ha un piano dettagliato per il ripristino dopo un incendio in stabilimento ma non ha un piano per il ripristino dopo un ransomware che cifra i sistemi SCADA è un’organizzazione che scopre durante la crisi quanto è complesso e lungo il processo di recovery in ambito OT.
L’integrazione della sicurezza OT nei piani di continuità richiede di affrontare specificità che non esistono nei piani IT tradizionali: il ripristino dei sistemi di controllo richiede non solo il restore dei dati ma la verifica dell’integrità dei parametri di processo, la riqualificazione delle macchine, e spesso il coinvolgimento dei fornitori dei sistemi OT per la ri-validazione.
I tempi di recovery in ambito OT sono sistematicamente più lunghi di quelli IT (settimane invece di giorni) e devono essere pianificati realisticamente.
Il piano di continuità deve anche includere la modalità di operatività manuale di emergenza: come si gestisce un impianto se i sistemi di controllo automatico sono offline? Questa domanda, apparentemente banale, richiede spesso la riscoperta di competenze operative che le generazioni più giovani di operatori non hanno mai sviluppato.
Quadro normativo e standard internazionali per la conformità aziendale
Il quadro normativo per la OT Security è diventato significativamente più strutturato negli ultimi anni, passando da un insieme di raccomandazioni volontarie a obblighi vincolanti con conseguenze sanzionatorie concrete.
Per le organizzazioni industriali italiane nei settori critici, la navigazione di questo quadro normativo è un’attività che richiede competenze specifiche e aggiornamento continuo: le scadenze si sovrappongono, i requisiti si integrano, e la non-conformità può generare procedimenti paralleli sotto normative diverse.
Direttiva NIS2 e Regolamento Macchine: i nuovi obblighi per i vertici societari
La direttiva NIS2, recepita in Italia con il D.lgs. 138/2024, impone obblighi significativi per le organizzazioni nei settori critici che utilizzano sistemi OT: energia, trasporti, acqua, infrastrutture digitali, produzione e distribuzione di sostanze critiche.
L’art. 21 richiede l’adozione di misure tecniche e organizzative proporzionate al rischio per la sicurezza delle reti e dei sistemi informativi e i sistemi OT sono esplicitamente inclusi in questa definizione. Tra le misure richieste: la gestione del rischio, la sicurezza della supply chain (inclusi i fornitori di sistemi OT), la gestione degli incidenti con notifica ad ACN entro 24-72 ore, e la continuità operativa.
Il nuovo Regolamento Macchine (Regolamento UE 2023/1230), che sostituirà la Direttiva Macchine e diventerà applicabile nel 2027, introduce requisiti espliciti di cyber security per le macchine e i sistemi di controllo.
Per la prima volta, le macchine destinate al mercato europeo dovranno soddisfare requisiti di sicurezza informatica come precondizione per la marcatura CE: protezione da accessi non autorizzati, integrità del software, capacità di rilevamento delle anomalie.
Questo trasforma la OT Security da questione operativa interna a requisito di conformità del prodotto, con implicazioni significative sia per i costruttori di macchine sia per gli utenti finali che devono gestire il ciclo di vita della sicurezza dei sistemi installati.
Lo standard IEC 62443 e le linee guida per la gestione del rischio
Lo standard IEC 62443, «Industrial communication networks – IT Security for networks and systems», è il riferimento normativo internazionale più completo per la sicurezza dei sistemi di automazione e controllo industriale.
Articolato in quattro serie (General, Policies and Procedures, System, Component), definisce requisiti di sicurezza a diversi livelli: per il proprietario dell’impianto (asset owner), per l’integratore di sistema e per il costruttore dei componenti.
Il suo approccio è basato sui Security Levels (SL 1-4), che definiscono livelli crescenti di protezione in funzione delle conseguenze potenziali di un attacco: da SL1 (protezione da attacchi non intenzionali) a SL4 (protezione da attacchi sofisticati e altamente motivati con risorse significative).
Per le organizzazioni industriali italiane che devono dimostrare conformità a NIS2, IEC 62443 fornisce il framework tecnico di riferimento per strutturare il programma di sicurezza OT.
La sua adozione è raccomandata dalle linee guida ENISA per la sicurezza dei sistemi ICS/SCADA e da ACN come standard di riferimento per i soggetti NIS2 nel settore industriale.
La certificazione IEC 62443 dei sistemi OT, disponibile per i prodotti dei principali vendor (Siemens, Rockwell, Schneider Electric) e per gli impianti integrati da system integrator qualificati, è sempre più richiesta nei capitolati di gara delle grandi organizzazioni industriali e nelle condizioni contrattuali dei clienti più strutturati.
Strategie e architetture tecniche per la protezione degli impianti
Le architetture di sicurezza OT non possono essere semplicemente replicate dall’IT: devono essere progettate tenendo conto dei vincoli specifici degli ambienti industriali e quindi di dispositivi che non possono essere riavviati, protocolli che non supportano agenti di sicurezza e reti che non possono tollerare latenze aggiuntive introdotte da strumenti di sicurezza.
L’approccio corretto non è «come applichiamo i nostri strumenti IT alla rete OT» ma «quali architetture e strumenti sono adatti all’ambiente OT tenendo conto dei suoi vincoli specifici».
Segmentazione delle reti industriali secondo il modello Purdue
Il modello Purdue, formalmente noto come Purdue Enterprise Reference Architecture (PERA), è il framework di riferimento per la segmentazione delle reti industriali, sviluppato negli anni ’90 e ancora ampiamente adottato come baseline per la progettazione delle architetture OT.
Il modello organizza i sistemi industriali in livelli gerarchici: dal Livello 0 (dispositivi di campo: sensori, attuatori) al Livello 5 (rete enterprise aziendale), con zone di demilitarizzazione (DMZ industriale) che controllano il traffico tra i livelli. Il principio fondamentale è che il traffico deve fluire solo tra livelli adiacenti e deve essere filtrato e controllato ai confini tra le zone.
Nella sua implementazione moderna, il modello Purdue si integra con i principi Zero Trust: invece di fidarsi implicitamente di tutto il traffico all’interno di una zona, ogni comunicazione viene verificata in funzione dell’identità del dispositivo, del tipo di traffico e della destinazione.
I Data Diode, dispositivi che consentono il flusso di dati in una sola direzione, sono una soluzione hardware spesso usata per garantire che i dati di produzione possano fluire dalla rete OT alla rete IT (per analytics e reporting) senza che nessun traffico possa fluire in direzione opposta, eliminando fisicamente la possibilità di un attacco dall’IT all’OT attraverso quel canale.
Per i casi in cui è necessaria la comunicazione bidirezionale, i firewall industriali (Fortinet, Palo Alto, Cisco) con supporto per i protocolli OT (Modbus, DNP3, OPC-UA) consentono un controllo granulare del traffico tra zone.
Visibilità continua degli asset e monitoraggio delle anomalie in tempo reale
Il monitoraggio continuo degli ambienti OT è la capacità che più differenzia le organizzazioni mature in ambito OT Security da quelle che si limitano alla compliance documentale.
In un ambiente OT privo di monitoraggio, un attaccante che ha ottenuto accesso può muoversi lateralmente per settimane o mesi prima di essere rilevato: il tempo medio di permanenza in ambienti OT, secondo i dati Dragos 2024, è significativamente superiore a quello negli ambienti IT.
Il monitoraggio basato sul rilevamento delle anomalie (identificare comportamenti che si discostano dalla baseline normale del sistema) è particolarmente adatto agli ambienti OT perché i processi industriali sono per loro natura ripetitivi e prevedibili: ogni deviazione dalla norma è un segnale potenzialmente significativo.
Le piattaforme di monitoring OT specializzate (Claroty, Nozomi Networks, Dragos, Microsoft Defender for IoT) operano attraverso il monitoraggio passivo del traffico di rete (port mirroring o TAP), senza installare agenti sui dispositivi OT.
Questo approccio è compatibile con i vincoli degli ambienti industriali: non interferisce con i processi di controllo, non introduce latenze, non richiede l’installazione di software sui controller.
Le piattaforme più avanzate integrano threat intelligence specifica per gli ambienti OT, come indicatori di compromissione (IOC) e tattiche, tecniche e procedure (TTP) documentate per i gruppi che attaccano le infrastrutture industriali, consentendo di rilevare non solo anomalie generiche ma anche gli indicatori specifici dei gruppi più attivi nel settore.
La OT Security non è un progetto da completare: è un programma continuo di gestione del rischio che richiede investimento costante, aggiornamento delle competenze e una cultura organizzativa in cui la sicurezza degli impianti è percepita come un valore condiviso da tutta l’organizzazione, dai vertici aziendali agli operatori di linea.
Le organizzazioni che lo hanno compreso non sono solo più sicure, ma anche più conformi alle normative, più resilienti agli incidenti, e più competitive in un mercato che richiede garanzie crescenti sulla continuità operativa e sulla sicurezza delle infrastrutture produttive.
Partecipa alla community