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

Il modello Purdue aiuta a comprendere perché latenza, disponibilità continua, sistemi legacy e requisiti di safety rendono inefficace il trasferimento diretto dei controlli IT agli ambienti OT.

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.

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.

Fonti:

[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.

https://www.ictsecuritymagazine.com/articoli/zero-trust-modello-purdue-ot/