Negli ultimi anni, lo Zero Trust Security Model, o Zero Trust Architecture, ha guadagnato popolarità sia dal pubblico tecnico che non tecnico.
Non è difficile capire le ragioni alla base di questo successo: l'approccio trust-by-design è obsoleto e ha dimostrato quanto possano andare male le cose quando un dispositivo o un'applicazione sono considerati attendibili a priori, senza alcuna considerazione dinamica del contesto.
In poche parole, supporre che dispositivi e applicazioni possano essere considerati affidabili solo perché si trovano sulla stessa rete è un presupposto vecchio, non sicuro ed errato.
Applicazione dell’Approccio Zero Trust
Applicare correttamente la metodologia Zero Trust (ZT) richiede lo studio di come interagiscono i sistemi, di cosa hanno bisogno gli uni dagli altri e come ridurre al minimo l'accesso alle informazioni. Può sembrare semplice, ma non lo è: soprattutto se i sistemi interagenti esistono già e hanno necessità di essere aggiornati o adattati per implementare ZT.
Nozomi come professionista della sicurezza informatica, ha come obiettivo quello di seguire ciò che dice la teoria nel modo più rigoroso, o il rischio è quello di dover affrontare gli stessi problemi del vecchio approccio trust-by-design (con una certa complessità in più).
In linea di principio, l'endgame desiderato di un'implementazione ZT richiede che tutti i componenti (non alcuni, né i più importanti, né solo conosciuti, ma tutti) interagiscano tra loro con tutte le verifiche di accesso in atto.
Ma per raggiungere questo obiettivo, abbiamo bisogno che tutti i dispositivi, le applicazioni e i protocolli di comunicazione siano progettati pensando a ZT. È possibile in tutti i casi oggi? No. Ma possiamo progettare un piano per arrivarci.
Per raggiungere lo stato di zero trust, sono due le azioni principali da eseguire: la prima in cui le vecchie abitudini di trust-by-design vengono rimosse, anche se permangono problemi a causa dei limiti tecnologici, e la seconda in cui ogni parte del sistema supporta un approccio ZT.
Mentre il primo obiettivo dovrebbe essere raggiungibile con uno sforzo sufficiente, il secondo traguardo richiede tempo e probabilmente potrebbe avvenire in modo incrementale. Ancora più importante, richiederebbe la collaborazione dei migliori professionisti tecnologici nelle varie comunità di standardizzazione.
Rimozione del Bias: Prima Milestone verso lo Zero Trust per OT e IoT
Il mantra di zero trust è non è il trust-by-design, ma verificare sempre se un utente che si è autenticato su un'applicazione/dispositivo/sistema ha i diritti per accedere a una determinata risorsa, in un determinato contesto (dove parte di questo contesto è lo stato di salute del dispositivo).
Quanto è granulare il sistema che richiede l'accesso a una risorsa? È un dispositivo completo, un'applicazione o una sessione specifica? È più granulare di così? E quanto è grande la risorsa richiesta per l'accesso? È un sistema completo, un file, un record o un attributo?
L’Obiettivo di Nozomi
L’obiettivo di Nozomi è costruire lo scheletro di ZT, senza presumere che sia l’endgame. Nel documento NIST.SP.800-207, sono descritti tre approcci principali per l'adozione di ZT: ZTA Using Enhanced Identity Governance, ZTA Using Micro-Segmentation e ZTA Using Network Infrastructure e Software Defined Perimeters. Nessuno di questi è né facile da raggiungere né garantisce la piena compatibilità con i sistemi esistenti.
Si può implementare una qualche forma di decisione delle policy e punti di applicazione, come agent e/o firewall opportunamente abilitati e configurati. Questo fa sicuramente parte della prima milestone: rimuovere il pregiudizio verso "stessa LAN = più sicurezza" e iniziare a pensare in modo diverso. Ma se lo guardiamo più da vicino, non risolverà completamente il problema che ZT vuole risolvere.
Vediamo Perché
Consideriamo una configurazione OT minima con un HMI o SCADA che si collega a un PLC utilizzando Modbus, DNP3 o IEC 104. E supponiamo di riuscire a distribuire un agent abilitato ZT sull'HMI e micro-segmentare la rete in modo che i due attori abbiano un rete per farli comunicare.
Potremmo ancora avere un aggiornamento dannoso (diciamo un attacco basato sulla supply chain in cui il fornitore di automazione è stato compromesso) installato sull'HMI durante la manutenzione tramite chiavetta USB. La decisione di consentire comunque all'HMI di accedere al PLC sarà binaria: sì o no.
A causa delle limitazioni del protocollo presenti, sarà complesso (o praticamente impossibile) consentire l'accesso granulare al PLC a causa della semantica a livello di app; ad esempio i sensori/attuatori controllati. Tenendo presente la terminologia ZT, non sarà così semplice limitare il concetto di risorsa a un'area sufficientemente piccola: sarà probabilmente l'intero PLC. Tutto o niente.
Una sfida correlata è rappresentata ancora dai protocolli di comunicazione: l'esempio precedente utilizzava protocolli standard aperti. Ma le reti OT e IoT sono caratterizzate da un'enorme varietà di protocolli proprietari, il che rende tali aspetti difficili da affrontare. E ovviamente la sicurezza attraverso l'oscurità non è una soluzione.
Un'altra sfida è legata all'autenticazione della sessione senza modificare le applicazioni: molti protocolli OT e IoT o non hanno l'autenticazione e l'autorizzazione incorporate, oppure hanno un modello molto semplice per questo. Eppure, gli operatori spesso accedono con account condivisi, ma questa è un'altra storia.
E la Salute delle Risorse?
Passando a un altro argomento: la salute degli asset. Un bene dovrebbe avere accesso alle risorse considerando anche la sua salute. Ciò significa che se le patch non vengono applicate, un antivirus non è installato sull'endpoint o ha firme obsolete, quell'asset dovrebbe avere accesso solo a quei servizi che ne consentono l'aggiornamento e riprovare.
Ad esempio, negli ambienti OT, è abbastanza comune per i fornitori di automazione convalidare gli aggiornamenti di Windows prima di consentirne l'installazione sugli HMI. Un'implementazione pragmatica di ZT dovrebbe tenerne conto e consentire una certa lacuna nelle patch.
Anche in questo caso, il modello ZT teorico non sarà applicato completamente, lasciando spazio al rischio non gestito, che in definitiva deriva da un falso senso di sicurezza completa e assoluta.
Ora dovrebbe essere chiaro che le sfide relative al protocollo rendono ZT implementabile, ma con alcune limitazioni e compromessi alla fine dati dalle specifiche e dai contesti legacy.
Correggere le Vecchie Limitazioni: Seconda Milestone verso Zero Trust per OT e IoT
La prima milestone riguarda la rimozione del vecchio assetto secondo cui due risorse che vivono sulla stessa rete hanno più fiducia di altre. Ma come abbiamo visto nella sezione precedente, non è possibile fare una distribuzione perfetta in questo momento. Con questo secondo passaggio, vogliamo correggere queste carenze.
E non sarà solo su di noi. Questo non può essere un traguardo del progetto per il cliente X, Y o Z. Avrà bisogno di più tempo e cooperazione e sarà principalmente come un asintoto a cui mirare, il che significa che in determinate situazioni questo secondo traguardo non sarà mai “completato”. Ma sarà più completo man mano che ogni pezzo del puzzle andrà nel posto giusto.
Per quanto riguarda le limitazioni del protocollo, ci sono due possibili approcci: o i protocolli standard sono evoluti per incorporare i principi ZT e vengono adottati dall'industria, oppure i vari fornitori adattano ed evolvono i protocolli e forniscono una soluzione (un agent?) per implementare correttamente ZT.
Per consentire ai protocolli standard di incorporare l'autenticazione e l'autorizzazione nei loro flussi e avere un accesso più granulare alle risorse, si stanno compiendo sforzi su più fronti.
Ad esempio, nel settore dei sistemi di alimentazione, la famiglia di standard IEC 62351 sta aggiungendo utili elementi costitutivi per rendere più avanzate le implementazioni ZT. L'organizzazione di sviluppo degli standard ODVA ha migliorato il protocollo di comunicazione EtherNet/IP OT, aggiungendo un aggiornamento completo con l'estensione CIP Security.
Ci vorrà tempo per consentire ai protocolli di evolversi e offrire funzionalità di sicurezza adeguate per tutti i verticali e i contesti.
Ci sono sicuramente altri aspetti che necessitano di una revisione, abbiamo menzionato ad esempio la tempestività delle patch rispetto alla garanzia di una qualità adeguata. Ci vorrà del tempo per far evolvere l'infrastruttura software per consentire una convalida più rapida e automatica e allo stesso tempo una buona integrazione con i servizi sulla salute degli asset, per consentire al PDP/PEP di prendere la decisione giusta dato il contesto.
Che dire del Modello Purdue?
Il mondo della tecnologia si sta evolvendo, convergendo e al giorno d'oggi è interessante guardare una rete di computer e dire cos'è IT, cos'è OT, cos'è IoT (o IoMT, IIoT, ecc.). I bordi sono sfocati e a volte è meglio dimenticare le etichette e ricordare che alla fine, è tutta solo tecnologia. Un unico sistema da mettere in sicurezza nel miglior modo possibile.
Con ciò, nel mondo OT il Purdue Model (o meglio, la Purdue Enterprise Reference Architecture) esiste da decenni e viene utilizzato come riferimento per progettare nuovi sistemi ed evolvere quelli vecchi.
L'essenza del modello Purdue è dividere la rete in livelli, in cui ogni livello può comunicare solo con i suoi vicini più prossimi e in cui la sicurezza per il processo sottostante diventa più rigorosa all'aumentare dei livelli (e quindi sono più lontani dalle apparecchiature di automazione).
Cosa hanno in comune lo Zero Trust e il Purdue Model? Sono entrambe soluzioni per interconnettere le risorse in modo organizzato, cercando di ridurre al minimo gli accessi di rete indesiderati a determinate risorse.
Tuttavia, ZT incorpora concetti aggiuntivi che potenzialmente rendono il modello Purdue obsoleto. Non vogliamo necessariamente aprire questa conversazione qui, ma un possibile modo per vedere ZT da una prospettiva di Purdue Model è che è necessario implementare più controlli perché la sola separazione nei livelli non è sufficiente; d'altra parte, ZT potrebbe suggerire un'architettura più flessibile e probabilmente ugualmente sicura per OT.
In Conclusione
Come abbiamo visto, ZT per OT e IoT riguarda tanto la verifica quanto la (mancanza di) fiducia.
Ma è bene iniziare ad adottarlo, almeno come mentalità. Zero Trust si evolverà per i prossimi 5-10 anni, forse con lo stesso nome, forse con altri nomi, ma i concetti sono qui per rimanere ed evolversi di sicuro.
Nozomi Networks può aiutare in questa transizione: perché visibilità, monitoraggio continuo e conoscenza della salute di ogni risorsa sono un elemento fondamentale di ZT. E la buona notizia è che tale transizione può iniziare in modo non invadente.
Allo stesso tempo, è importante capire che l'implementazione di reti Nozomi e soluzioni simili è solo l'inizio. Una transizione completa verso lo zero trust richiede pianificazione, tempo e impegno.
Se vuoi avere maggiori informazioni su Nozomi Networks invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250. Visita la pagina dedicata sul nostro sito per richiedere una demo gratuita della soluzione o per ricevere ulteriore materiale informativo.
In alternativa, puoi compilare il form sottostante con la tua domanda.
