Article. What i write

Zero Trust nei sistemi OT: dalla teoria all’applicazione, ecco le 5 aree di rischio prioritarie

Pubblicato il 20 agosto 2026 su CyberSecurity360.it

Il paradigma Zero Trust si è ormai consolidato per i sistemi IT aziendali, ma la sua applicazione agli ambienti di Operational Technology (OT) non è affatto immediata. Le profonde differenze architetturali, i vincoli di real time, il parco tecnologico legacy e una gerarchia di priorità rovesciata (la disponibilità viene prima della riservatezza) impongono un adattamento sostanziale dei principi. Partendo da un caso applicativo nel settore elettrico, ecco un approccio mission-focused all’adozione dello Zero Trust nell’ambito OT, nel contesto normativo europeo (NIS2) e tecnico (ISA/IEC 62443).

Zero Trust: modello maturo per l’IT aziendale, meno per l’OT

Lo Zero Trust nasce come risposta all’erosione del perimetro di rete come confine affidabile. Il principio è chiaro: non si deve concedere alcuna fiducia implicita a un utente o a un dispositivo sulla base della sola collocazione fisica o di rete. Questo principio trova la sua formalizzazione di riferimento nella NIST SP 800-207, che sposta le difese dai perimetri statici verso utenti, asset e risorse, con verifica continua di ogni richiesta di accesso. Per l’IT aziendale, il modello è oggi maturo. Per l’OT, invece, molto meno. Il Software Engineering Institute (SEI) della Carnegie Mellon University ha affrontato il problema partendo da un ambito critico: quello dei sistemi di difesa con OT embedded, per poi estenderne le conclusioni al panorama dei sistemi industriali. In un recente caso di studio, illustra l’adozione dello Zero Trust nelle sottostazioni digitali di una utility, un esempio utile proprio perché concreto, che qui utilizziamo come filo conduttore.

Perché l’OT non è l’IT

La tentazione di applicare i controlli IT all’ambito OT si scontra con vincoli non negoziabili. In un sistema industriale, la gerarchia degli obiettivi è invertita rispetto a quella dell’informatica gestionale: prima vengono la sicurezza, la disponibilità e l’affidabilità, e solo dopo la riservatezza e l’integrità dei dati. Un controllore deve rispondere entro finestre temporali deterministiche; l’introduzione di un meccanismo di autenticazione persistente o di uno scanner antimalware in linea può causare latenze non tollerabili e, nel peggiore dei casi, il blocco del processo fisico. A ciò si aggiungono il parco legacy e i vincoli fisici. Molti IED e relè di protezione, installati anni fa, comunicano tramite protocolli proprietari e seriali privi di autenticazione e controlli di integrità, e sono stati progettati per operare in ambienti isolate (“air gapped”), che oggigiorno non esistono più. Sostituirli tutti insieme è spesso impraticabile per motivi di costi, continuità del servizio e affidabilità. La NIST SP 800-82 Rev. 3, guida di riferimento per la sicurezza OT, riconosce esplicitamente questa specificità e integra i concetti di Zero Trust nel proprio impianto, affiancandoli al Risk Management Framework e al Cybersecurity Framework. Le comunicazioni in ambito OT sono storicamente compartimentate secondo il modello Purdue, che organizza i sistemi in livelli isolati con traffico ristretto da segmentazione e controlli di accesso (Figura 1). Si tratta di un buon punto di partenza, ma, come vedremo, da solo non basta più.

Figura 1: Architettura di rete OT, segmentata secondo il modello Purdue.

Una superficie di attacco che non è più isolata: 5 aree di rischio prioritarie

Il caso di studio prende avvio da un’analisi delle minacce. Le linee guida della Cloud Security Alliance per le infrastrutture critiche individuano una decina di motivi, per cui si potrebbe essere interessati ad attaccare l’OT, che vanno dalla pressione normativa disallineata alle pratiche efficaci fino alla guerra cibernetica tra Stati. Filtrandole in base al proprio contesto, l’utility ha individuato cinque aree di rischio prioritarie: Advanced Persistent Threat (APT), ransomware, minacce interne, sistemi legacy e supply chain. Le APT, tipicamente sponsorizzate da attori statali, operano in modo silente e prolungato, studiano il bersaglio e si annidano al di sotto della soglia di rilevazione dei firewall e degli IDS tradizionali, rappresentando una delle minacce più distruttive. Il ransomware ha spostato il mirino verso le infrastrutture critiche per massimizzare il riscatto e, nel settore OT, può tradursi in danni fisici a attuatori, pompe e sensori. La minaccia interna non è solo dolosa: spesso è un operatore distratto che collega una chiavetta USB infetta a una workstation di controllo. I sistemi legacy restano l’anello debole, come già discusso. La supply chain, infine, espone a hardware contraffatto, firmware compromesso e, cosa meno ovvia, al tampering “last-mile” durante la consegna di relè e controllori, dove si sfrutta il “trust gap” della logistica. Il punto centrale è il seguente: le minacce, considerate a lungo come “esterne”, entrano nel sistema attraverso i fornitori, gli aggiornamenti del firmware, le workstation e i dispositivi già presenti nel perimetro. Lo schema di segmentazione Purdue è ancora valido, ma non è più sufficiente fare affidamento solo sull’isolamento e sui controlli di accesso per livello (Figura 2).

Figura 2: Superficie di attacco e principali vettori di compromissione.

Un approccio mission-focused

Il contributo metodologico dell’SEI consiste nel rifiutare la ricetta unica. Prima ancora di scegliere le tecnologie, è necessario comprendere il sistema. L’SEI articola tale comprensione in cinque fattori: mission context, system attributes, threat environment, tradeoff space e mission dependencies, che devono essere analizzati prima di applicare qualsiasi framework di sicurezza. Questi cinque fattori costituiscono il complemento naturale dei cinque passaggi indicati nel rapporto NSTAC del 2022 per la messa in sicurezza di OT e ICS: definire la superficie da proteggere (ovvero gli elementi DAAS da proteggere), mapparne i flussi, costruire l’architettura Zero Trust, definirne le policy e, infine, monitorare e mantenere la rete. Particolarmente concreta è la valutazione dei system attributes ovvero della reale capacità di un sistema di accogliere controlli Zero Trust.

Le 5 dimensioni dell’analisi

L’analisi si basa su cinque dimensioni:

• la dynamic configurability, ovvero la possibilità di riconfigurare policy e relazioni di fiducia quasi in tempo reale;
• la design/retrofit flexibility, ovvero la possibilità di ammodernare l’esistente;
• i vincoli di size, weight and power (SWaP), che possono costituire confini invalicabili;
• la latency tolerance, perché ogni controllo aggiunge un ritardo che il processo deve poter assorbire;
• e l’IT/OT centricity, ovvero quanto un componente OT è “IT-like” e dunque permeabile ai principi di sicurezza informatica.

Nelle sottostazioni, le HMI girano su piattaforma Windows e accettano controlli Zero Trust on-device; i dispositivi di campo più datati, privi di identità e di controlli granulari, devono invece appoggiarsi a meccanismi esterni di enforcement.

Le fasi dell’utility

Su questa base, l’utility procede per fasi:

• protegge gli asset ad alto rischio (engineering e operator workstation, historian) con controlli on-device;
• impone confini logici e controlli di accesso anche tra dispositivi dello stesso livello per bloccare il lateral movement;
• introduce l’autenticazione a più fattori (MFA) e la gestione centralizzata e sicura degli accessi remoti da parte di terzi, con valutazione delle policy a ogni autenticazione;
• e integra il sistema legacy tramite un layer intermedio che offre un’interfaccia standardizzata, in attesa della migrazione a una segnalazione digitale moderna.

Nessuno strappo: un percorso di maturità incrementale, di gran lunga preferibile all’inazione.

Il modello identity-centric

La direzione intrapresa è in linea con quella della letteratura scientifica che converge verso il superamento del perimetro rigido a favore di un modello identity-centric. Zanasi, Russo e Colajanni propongono un’architettura Zero Trust “flessibile” per le infrastrutture IIoT industriali, mostrando come sia possibile passare dal modello Purdue rigido a un approccio più adattivo senza compromettere la sicurezza. Federici, Martinotti e Senni affrontano il problema dell’accesso remoto sicuro in ambito industriale in modo analogo. Le rassegne sistematiche più recenti ne riconoscono il valore, ma ne segnalano anche i limiti aperti: l’impatto prestazionale, la complessità della migrazione e la maturità diseguale delle implementazioni.

La cornice europea: NIS2 e ISA/IEC 62443

Per un operatore italiano, l’adozione dello Zero Trust nell’ambito OT non è solo una scelta tecnica, ma rientra anche in un quadro di obblighi normativi. La direttiva (UE) 2022/2555, nota come NIS2, recepita in Italia con il decreto legislativo del 4 settembre 2024, n. 138, ha ampliato in modo sostanziale la platea dei soggetti obbligati, che ora include diciotto settori, tra cui quello dell’energia, e ha inasprito gli obblighi di gestione del rischio, di notifica degli incidenti e di responsabilità dei dirigenti. L’Agenzia per la Cybersicurezza Nazionale (ACN) è inoltre l’autorità competente e il punto di contatto unico. Le diverse misure richieste dall’articolo 24 del decreto, quali il controllo degli accessi, l’autenticazione a più fattori, la sicurezza della catena di approvvigionamento e l’igiene informatica, costituiscono, di fatto, i componenti di un’architettura Zero Trust e la conformità e l’irrobustimento tecnico procedono nella stessa direzione. Dal punto di vista tecnico, il riferimento per l’industria è la serie di standard ISA/IEC Il suo impianto si basa su zone e condotti, ovvero raggruppamenti di asset con esigenze di protezione comuni e i canali che li collegano, e su quattro livelli di sicurezza (SL 1-SL 4), in funzione della sofisticazione dell’avversario da contrastare, e declinati attraverso sette requisiti fondamentali. La consonanza con il modello Zero Trust è evidente: la segmentazione in zone e condotti è la versione industriale della microsegmentazione, mentre i primi due requisiti fondamentali, “Identificazione e autenticazione” e “Controllo dell’uso”, codificano esattamente l’identità verificata e il principio del minimo privilegio, principi centrali del modello. Tutti insieme, NIS2, IEC 62443 e NIST SP 800-82 delineano un quadro coerente in cui il modello Zero Trust non rappresenta un’alternativa, ma un acceleratore.

L’adozione Zero Trust nel perimetro OT

La lezione dell’esempio trattato è di metodo, prima ancora che di tecnologia. In ambienti con capacità mista, non esiste un’unica implementazione Zero Trust applicabile all’intero perimetro OT/ICS: i componenti del modello devono essere scomposti e applicati dove il sistema può effettivamente sostenerli, valutandone la fattibilità sito per sito, impianto per impianto e sottosistema per sottosistema. Si tratta di un processo evolutivo che richiede anni, un coordinamento tra diverse discipline e il sostegno della dirigenza, e che deve essere inserito sin dalle fasi di progettazione. Alcune installazioni legacy potrebbero non essere ragionevolmente aggiornabili: in questi casi, è necessario riconoscere e gestire il rischio residuo. Comprendere la missione del sistema, ovvero cosa protegge, in quali condizioni e con quali dipendenze, è il presupposto per poter scegliere bene, bilanciando protezione, prestazioni, interoperabilità e vincoli di budget. Si tratta di un lavoro lungo, ma necessario.

Riferimenti

• [1] S. Rose, O. Borchert, S. Mitchell e S. Connelly, “Zero Trust Architecture,” NIST Special Publication 800-207, National Institute of Standards and Technology, ago. 2020.
• [2] Software Engineering Institute, “Tailoring Security and Zero Trust Principles to Weapon-System Environments,” Special Report, Carnegie Mellon University.
• [3] R. Brown, “Implementing Zero Trust in Operational Technology: A Practical Case Study,” SEI Blog, Software Engineering Institute, Carnegie Mellon University, 16 giu. 2026.
• [4] K. Stouffer, M. Pease, C. Tang, T. Zimmerman, V. Pillitteri et al., “Guide to Operational Technology (OT) Security,” NIST Special Publication 800-82 Rev. 3, NIST, set. 2023. DOI: 10.6028/NIST.SP.800-82r3.
• [5] Cloud Security Alliance, “Zero Trust Guidance for Critical Infrastructure,” CSA.
• [6] President’s National Security Telecommunications Advisory Committee (NSTAC), “Report to the President on Zero Trust and Trusted Identity Management,” 2022.
• [7] C. Zanasi, S. Russo e M. Colajanni, “Flexible Zero Trust Architecture for the Cybersecurity of Industrial IoT Infrastructures,” Ad Hoc Networks, vol. 156, art. 103414, 2024. DOI: 10.6028/NIST.SP.800-207. DOI: 10.1016/j.adhoc.2024.103414.
• [8] F. Federici, D. Martintoni e V. Senni, “A Zero-Trust Architecture for Remote Access in Industrial IoT Infrastructures,” Electronics, vol. 12, n. 3, art. 566, 2023. DOI: 10.3390/electronics12030566.
• [9] N. F. Syed, S. W. Shah, A. Shaghaghi, A. Anwar, Z. Baig e R. Doss, “Zero Trust Architecture (ZTA): A Comprehensive Survey,” IEEE Access, vol. 10, pp. 57143–57179, 2022.
• [10] E. Bertino, “Zero Trust Architecture: Does It Help?,” IEEE Security & Privacy, vol. 19, n. 5, pp. 95–96, 2021.
• [11] E. B. Fernandez e A. Brazhuk, “A Critical Analysis of Zero Trust Architecture (ZTA),” Computer Standards & Interfaces, vol. 89, art. 103832, 2024.
• [12] Parlamento europeo e Consiglio, Direttiva (UE) 2022/2555 (NIS2) del 14 dicembre 2022, relativa a misure per un livello comune elevato di cibersicurezza nell’Unione.
• [13] Decreto legislativo 4 settembre 2024, n. 138, di recepimento della direttiva (UE) 2022/2555 (NIS2), G.U. n. 230 del 1º ottobre 2024.
• [14] International Society of Automation / International Electrotechnical Commission, serie ISA/IEC 62443, “Security for Industrial Automation and Control Systems.”

---

---