Zero trust e modello Purdue: perché i controlli IT non bastano nell’OT

Pubblicato il 7 ottobre 2026 su ICTSecurityMagazine.com

Nella prima parte della serie Vincenzo Calabrò ha spiegato perché la fine dell’air gap impone di ripensare la sicurezza degli impianti industriali, e perché lo zero trust non può essere applicato all’OT in modo uniforme.

Questa seconda parte fornisce gli strumenti per orientarsi: i principi della NIST SP 800-207, l’organizzazione degli impianti secondo il modello Purdue e le ragioni tecniche per cui i controlli IT non si trasferiscono. Il paragrafo 2.3 merita attenzione particolare: introduce i cinque attributi di idoneità che torneranno in tutto il framework.

Modello Purdue e Zero Trust negli ambienti OT

Fondamenti dello Zero Trust, anatomia degli ambienti OT e limiti del trasferimento diretto dei controlli EIT.

Zero Trust: dai perimetri alle identità

Lo zero trust non è un prodotto o una tecnologia specifica, ma una strategia di sicurezza basata su un insieme di principi. La NIST SP 800-207 ne enuncia i principi fondamentali:

• tutte le risorse di dati e di calcolo sono trattate come tali, indipendentemente dalla loro posizione;
• ogni comunicazione è protetta, a prescindere dalla rete su cui transita;
• l’accesso alle singole risorse è concesso per sessione, sulla base del principio del privilegio minimo;
• le decisioni di accesso sono determinate da una policy dinamica che considera l’identità del richiedente, lo stato del dispositivo e altri attributi comportamentali e ambientali;
• l’organizzazione monitora e misura costantemente l’integrità e la postura di sicurezza dei propri asset, applica e rivaluta in modo continuo l’autenticazione e l’autorizzazione e raccoglie quante più informazioni possibili sullo stato corrente, al fine di migliorare nel tempo la propria postura.[1]

Sul piano logico, questi principi si traducono in un’architettura in cui il piano di controllo e il piano dei dati sono nettamente separati. Il policy engine, il cuore decisionale del sistema, esegue un algoritmo di fiducia per concedere, negare o revocare l’accesso; il policy administrator instaura o interrompe il canale di comunicazione in base alla decisione presa; il policy enforcement point, collocato lungo il percorso tra il soggetto e la risorsa, applica materialmente l’esito.[2]

Il passaggio concettuale più rilevante consiste nello spostare il baricentro dei controlli dalla segmentazione basata su parametri di rete quali indirizzi, sottoreti e perimetri, verso l’identità di utenti, dispositivi e servizi, con politiche di autorizzazione costruite attorno ad attributi anziché a topologie.[3]

La letteratura ha contribuito a sistematizzare il campo: la rassegna di Syed et al. offre una tassonomia esaustiva delle architetture e delle componenti zero trust,[4] mentre Fernandez e Brazhuk ne propongono un’analisi critica, mettendo in luce le ambiguità definitorie e nodi irrisolti nella traduzione dei principi in pratica.[5] Bertino, da parte sua, invita a una valutazione misurata dei benefici effettivi, ricordando che lo zero trust non è una panacea ma una strategia il cui valore dipende dalla qualità dell’implementazione.[6]

Modello Purdue: come sono organizzati gli ambienti OT

Per comprendere perché lo zero trust non può essere trasferito senza adattamenti nell’ambito OT, è necessario osservare la struttura tipica di un ambiente OT. Il modello architetturale dominante è il modello Purdue, derivato dalla Purdue Enterprise Reference Architecture, elaborata all’inizio degli anni Novanta da Williams e dal consorzio universitario sul Computer Integrated Manufacturing.[7] Concepito originariamente per razionalizzare i flussi informativi negli impianti automatizzati, il modello è stato adottato dalla comunità della sicurezza, in quanto la gerarchia funzionale che descrive si presta a delimitare confini difensivi naturali.

La serie di standard ISA/IEC 62443 ha adottato questa stratificazione traducendola nei concetti di zone e conduits: raggruppamenti di sistemi con requisiti di sicurezza omogenei e canali di comunicazione controllati che li collegano e ciascuno associato a un livello di sicurezza target commisurato al rischio.[8] La Figura 1 riassume questa organizzazione.

Figura 1. L’architettura di rete OT secondo il modello Purdue prevede i livelli funzionali, la zona demilitarizzata IT/OT e l’intensificarsi dei vincoli di tempo reale verso il processo fisico.

Ai livelli inferiori si trova il processo fisico (Livello 0), con i suoi sensori e attuatori, governato dai dispositivi di controllo di base (Livello 1), quali i controllori logici programmabili (PLC), le unità terminali remote (RTU), i dispositivi elettronici intelligenti (IED) e i relè di protezione. Il livello di supervisione (Livello 2) ospita i sistemi SCADA e le interfacce uomo-macchina (HMI), che consentono il monitoraggio e il comando, mentre il livello di operations management (Livello 3) raccoglie gli historian, le workstation per l’ingegneria e i sistemi di gestione della produzione.

Tra il dominio OT e la rete aziendale (livelli 4 e 5) si interpone, nelle architetture mature, una zona demilitarizzata industriale che media ogni scambio. Come evidenziato sul lato destro della figura, una caratteristica fondamentale è che i requisiti di tempo reale e di sicurezza aumentano scendendo verso il processo, mentre l’affinità con le tecnologie IT e, di conseguenza, la possibilità di riutilizzare i relativi controlli di sicurezza, aumenta risalendo verso l’alto.

Perché i controlli IT non si trasferiscono direttamente nell’OT

Le ragioni dell’incompatibilità sono molteplici e si rafforzano a vicenda. In primo luogo, l’eterogeneità: un impianto OT è costituito da apparecchiature di generazioni e fornitori diversi, spesso governate da protocolli proprietari che non prevedono autenticazione e controlli di integrità. In secondo luogo, la disponibilità continua: molti processi non tollerano interruzioni e le finestre di manutenzione per aggiornamenti o riconfigurazioni sono rare e costose. Infine, la sensibilità alla latenza: l’introduzione di un controllo che aggiunga ritardo alla catena di comando può compromettere la funzione, pertanto ogni meccanismo zero trust deve dimostrare di non interferire con i vincoli temporali del processo.[9]

A questi si aggiungono i limiti di calcolo, memoria ed energia dei dispositivi più datati che non dispongono del margine necessario per ospitare agenti software o funzioni crittografiche. Un filone di ricerca del Software Engineering Institute, sviluppato originariamente per i sistemi di difesa con OT embedded ma di valenza generale, ha condensato questi fattori in un insieme di attributi utili a valutare l’idoneità di un sistema ad accogliere le capacità zero trust: la configurabilità dinamica, la flessibilità di progettazione o retrofit, i vincoli di dimensione, peso e potenza (size, weight and power, SWaP), la tolleranza alla latenza e il grado di centralità IT rispetto a OT.[10]

Riprenderemo questi attributi nella sezione successiva come base per la fase di profilazione.

Standard e architetture per la sicurezza degli ambienti OT

Sul fronte normativo e istituzionale, oltre alle già citate NIST SP 800-207 e 800-82r3, meritano attenzione alcuni documenti per il loro approccio metodologico. La guida della Cloud Security Alliance per le infrastrutture critiche suddivide l’adozione dello zero trust in cinque fasi: definire la superficie da proteggere in termini di dati, applicazioni, asset e servizi; mappare i flussi delle transazioni; costruire l’architettura zero trust; formulare le relative politiche; monitorare e mantenere la rete.[11]

A livello europeo, l’ENISA (Agenzia dell’Unione europea per la cybersicurezza) ha pubblicato una guida tecnica che traduce le misure di gestione del rischio della NIS2 in indicazioni operative, esempi di documentazione e mappature verso standard internazionali quali ISO/IEC 27001, il NIST Cybersecurity Framework e la serie IEC 62443, offrendo un riferimento direttamente utilizzabile dalle organizzazioni dell’Unione.[12]

La ricerca accademica ha affrontato il problema da angolazioni complementari. Feng e Hu propongono un’architettura zero trust per i sistemi cyber-fisici industriali, mostrando come i principi possano essere riformulati tenendo conto dell’accoppiamento tra computazione e processo fisico.[13] Zanasi, Russo e Colajanni hanno elaborato un’architettura zero trust flessibile per le infrastrutture industriali basate su Industrial IoT, con l’obiettivo esplicito di adattare l’applicazione delle regole alla diversità dei dispositivi.[14] Federici, Martintoni e Senni si concentrano in particolare sull’accesso remoto alle infrastrutture IIoT, proponendo un’architettura a due livelli di controllo conforme al modello zero trust.[15] Per quanto riguarda la transizione, Phiayura e Teerakanok delineano un framework di migrazione verso lo zero trust, sebbene orientato principalmente ai contesti IT.[16]

Da questa analisi emerge un quadro coerente, ma incompleto. Le linee guida istituzionali forniscono processi di alto livello validi, ma volutamente generici, mentre i contributi accademici offrono architetture e meccanismi puntuali, spesso validati su scenari circoscritti o su sistemi relativamente moderni. Resta scoperto lo spazio intermedio: una metodologia che, a partire da una comprensione mission-centrica dell’ambiente, conduca in modo tracciabile alla selezione dei controlli effettivamente sostenibili per ogni classe di asset, integri esplicitamente l’analisi dei compromessi tra sicurezza e continuità operativa e gestisca il rischio residuo dei componenti non adeguabili. È questo lo spazio che MATRIX intende occupare, non in alternativa, ma in complemento agli schemi esistenti, dei quali assume e perfeziona i passaggi.

VINCOLI OT: Latenza stringente, disponibilità continua, eterogeneità dei protocolli, margini di calcolo e memoria ridotti (SWaP) e requisiti di safety restringono lo spazio dei controlli applicabili.

Nella prossima parte: dal modello Purdue al framework MATRIX

La rassegna si chiude su uno spazio scoperto, tra linee guida istituzionali generiche e architetture accademiche puntuali. Nella terza parte della serie l’autore presenta il framework MATRIX e le sue prime tre fasi: missione, idoneità degli asset e superficie d’attacco. Il paper integrale «Zero Trust selettivo negli ambienti OT» è disponibile per il download.

Riferimenti

• [1] S. Rose, O. Borchert, S. Mitchell e S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207. Gaithersburg, MD, USA: National Institute of Standards and Technology, 2020, doi: 10.6028/NIST.SP.800-207.
• [2] S. Rose, O. Borchert, S. Mitchell e S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207. Gaithersburg, MD, USA: National Institute of Standards and Technology, 2020, doi: 10.6028/NIST.SP.800-207.
• [3] S. Rose, O. Borchert, S. Mitchell e S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207. Gaithersburg, MD, USA: National Institute of Standards and Technology, 2020, doi: 10.6028/NIST.SP.800-207.
• [4] 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.
• [5] E. B. Fernandez e A. Brazhuk, "A critical analysis of zero trust architecture (ZTA)," Computer Standards & Interfaces, vol. 89, art. 103832, 2024.
• [6] E. Bertino, "Zero trust architecture: Does it help?," IEEE Security & Privacy, vol. 19, n. 5, pp. 95–96, 2021.
• [7] T. J. Williams, "The Purdue enterprise reference architecture," Computers in Industry, vol. 24, n. 2-3, pp. 141–158, 1994.
• [8] International Electrotechnical Commission, IEC 62443: Security for Industrial Automation and Control Systems (serie). Ginevra, Svizzera: IEC.
• [9] K. Stouffer, M. Pease, C. Tang, T. Zimmerman, V. Pillitteri, S. Lightman, A. Hahn, S. Saravia, A. Sherule e M. Thompson, Guide to Operational Technology (OT) Security, NIST Special Publication 800-82r3. Gaithersburg, MD, USA: National Institute of Standards and Technology, 2023, doi: 10.6028/NIST.SP.800-82r3.
• [10] C. J. Alberts, T. Morrow, R. Brown e C. M. Wallen, Tailoring Security and Zero Trust Principles to Weapon System Environments, Special Report. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University, 2025.
• [11] Cloud Security Alliance, Zero Trust Guidance for Critical Infrastructure. Seattle, WA, USA: CSA Zero Trust Working Group, ott. 2024.
• [12] Agenzia dell’Unione europea per la cibersicurezza (ENISA), Technical Implementation Guidance on Cybersecurity Risk Management Measures, v1.0. Atene, Grecia: ENISA, giugno 2025.
• [13] X. Feng e S. Hu, "Cyber-physical zero trust architecture for industrial cyber-physical systems," IEEE Transactions on Industrial Cyber-Physical Systems, vol. 1, pp. 394–405, 2023.
• [14] 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.1016/j.adhoc.2024.103414.
• [15] 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.
• [16] P. Phiayura e S. Teerakanok, "A comprehensive framework for migrating to zero trust architecture," IEEE Access, vol. 11, pp. 19487–19511, 2023.

Vincenzo Calabro' | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Autore di articoli e saggi. Lecturer, Speaker, Trainer.