Che cos'è la fiducia zero?

Il modello Zero Trust sostituisce la fiducia basata sulla posizione con una verifica continua. Mentre il modello perimetrale considerava di default affidabile tutto ciò che si trovava all’interno della rete, il modello Zero Trust valuta ogni richiesta come se provenisse da una fonte non affidabile, indipendentemente dalla sua provenienza effettiva o dai privilegi concessi allo stesso utente un’ora prima.

Tre concetti definiscono il modello nella pratica:

• Nessuna fiducia implicita. La posizione nella rete non garantisce nulla di per sé, e il fatto che una richiesta provenga dall'interno del firewall non costituisce una prova della sua legittimità.
• Verifica continua. L'affidabilità viene valutata ad ogni richiesta, anziché essere stabilita una volta sola al momento dell'accesso e mantenuta per tutta la durata della sessione.
• Privilegio minimo. L'accesso è limitato a quanto richiesto da una specifica richiesta e non va oltre tale ambito.

Lo Zero Trust non è un prodotto che le organizzazioni possono acquistare. Si tratta di una strategia che abbraccia identità, dispositivi, reti, applicazioni e dati, piuttosto che di una tecnologia che risiede in uno qualsiasi di questi livelli. I fornitori che la presentano come un prodotto descrivono in genere un singolo componente dell’architettura.

Il termine risale al 1994, quando Stephen Paul Marsh lo utilizzò in una tesi di dottorato sulla fiducia computazionale presso l’Università di Stirling. È entrato a far parte del panorama della sicurezza tradizionale nel 2010, quando l’analista di Forrester John Kindervag pubblicò “No More Chewy Centers: Introducing the Zero Trust Model of Information Security” e sostenne che la fiducia fosse di per sé una vulnerabilità. Il progetto BeyondCorp di Google, avviato nel 2009, fu tra le prime implementazioni su larga scala.

Il documento NIST SP 800-207 definisce sette principi fondamentali che ogni architettura zero-trust deve soddisfare.

1. Tutte le fonti di dati e i servizi informatici sono risorse. Banche dati, applicazioni, servizi SaaS, dispositivi IoT e postazioni di lavoro degli utenti richiedono tutti una protezione, senza alcuna eccezione in base alla loro ubicazione o alla loro presunta importanza.
2. Tutte le comunicazioni sono protette, indipendentemente dalla posizione della rete. Il traffico che transita sulla rete interna viene autenticato e crittografato secondo gli stessi standard applicati al traffico proveniente dalla rete Internet pubblica.
3. L'accesso viene concesso per singola sessione. L'affidabilità viene valutata per la sessione in corso e non viene trasferita alle sessioni successive; pertanto, l'accesso a una risorsa non implica in alcun modo l'accesso a un'altra.
4. L'accesso è determinato da una politica dinamica. Le decisioni tengono conto dell'identità del cliente, dello stato dell'applicazione, della situazione delle risorse e degli attributi comportamentali e ambientali, anziché basarsi su un insieme statico di regole.
5. L'azienda monitora lo stato di sicurezza di tutte le risorse. Nessuna risorsa è considerata affidabile per impostazione predefinita e l'integrità dei dispositivi viene verificata costantemente, in modo che tale dato possa essere preso in considerazione nelle decisioni relative all'accesso.
6. L'autenticazione e l'autorizzazione sono dinamiche e vengono applicate rigorosamente prima dell'accesso. La verifica funziona come un ciclo continuo di concessione, analisi, adattamento e rivalutazione, piuttosto che come un unico controllo all'inizio di una sessione.
7. L'azienda raccoglie quante più informazioni possibile e le utilizza per migliorare la propria posizione. I dati telemetrici raccolti dalle risorse, dall'infrastruttura e dai sistemi di comunicazione vengono utilizzati per definire le politiche che regolano l'accesso.

È molto diffusa anche una sintesi più breve, articolata in tre parti: verificare in modo esplicito, presumere la violazione, applicare il principio del privilegio minimo. Tale formulazione ha origine da Microsoft e funziona abbastanza bene come sintesi, ma non corrisponde a quanto effettivamente specificato dalla norma SP 800-207; pertanto, le organizzazioni che si allineano alle linee guida del NIST dovrebbero attenersi ai sette principi sopra indicati.

Ogni richiesta di accesso viene intercettata e gestita in tempo reale, seguendo una sequenza che rimane invariata indipendentemente da chi abbia sviluppato lo stack sottostante:

1. Un soggetto richiede l'accesso a una risorsa, dove tale soggetto può essere una persona, un account di servizio, un carico di lavoro o un agente di intelligenza artificiale.
2. I segnali vengono raccolti, tra cui identità, stato del dispositivo, posizione, ora, comportamento precedente e informazioni sulle minacce.
3. Un motore di policy valuta la richiesta in contrasto con la politica aziendale e con un punteggio di rischio calcolato.
4. Una decisione viene emessa e eseguita, concedendo l'accesso, negandolo o rafforzandolo con un fattore di autenticazione aggiuntivo.
5. La sessione è monitorata, in modo che eventuali variazioni del livello di rischio determinino una nuova valutazione e che l'accesso possa essere revocato mentre la sessione è ancora aperta.

È proprio quest’ultimo passo a distinguere il modello Zero Trust dai modelli che lo hanno preceduto, poiché la sicurezza perimetrale prende una decisione al confine e poi ne subisce le conseguenze, mentre il modello Zero Trust continua a valutare la situazione per tutta la durata della sessione.

Il modo più chiaro per comprendere la differenza è che una VPN estende il perimetro, mentre l'approccio Zero Trust lo elimina del tutto.

Quando un utente si connette tramite una VPN tradizionale, viene inserito nella rete aziendale e ottiene un ampio accesso a livello di rete sulla base di un’unica verifica effettuata al momento della connessione. Tutto ciò che è raggiungibile da quella posizione all’interno della rete è accessibile a quell’utente e a chiunque riesca a sottrargli le credenziali.

Il modello Zero Trust concede l'accesso a singole risorse anziché alle reti, pertanto l'autorizzazione ad accedere a un'applicazione non si estende ad altre risorse. Ogni richiesta viene rivalutata alla luce delle condizioni di rischio del momento.

La Pubblicazione speciale 800-207 del NIST, pubblicata nell'agosto 2020, è l'architettura di riferimento su cui si basano la maggior parte delle organizzazioni. Essa traccia una netta distinzione tra i componenti che prendono e applicano le decisioni relative all'accesso e le fonti di dati su cui tali decisioni si basano.

Tre componenti logiche fondamentali

Policy Engine (PE). Prende la decisione relativa all'accesso valutando la politica aziendale alla luce dei dati descritti di seguito, applicando un algoritmo di affidabilità e, infine, concedendo, negando o revocando l'accesso.

Amministratore delle politiche (PA). Attua tale decisione aprendo o chiudendo il canale di comunicazione e rilasciando la credenziale o il token che il soggetto utilizza per accedere alla risorsa. Insieme, il PE e il PA costituiscono ciò che il NIST definisce “punto di decisione sulle politiche”.

Punto di applicazione delle politiche (PEP). Abilita, monitora e interrompe la connessione tra il soggetto e la risorsa, inserendosi nel percorso della richiesta e applicando quanto stabilito dal punto decisionale della politica.

Fonti di dati che alimentano il motore delle politiche

I seguenti elementi forniscono i segnali che il motore decisionale valuta, senza prendere decisioni in proprio:

• Sistema di gestione delle identità. Account, record di identità, ruoli, attributi e autorizzazioni.
• Politiche di accesso ai dati. Le regole che stabiliscono chi può accedere a quali risorse e a quali condizioni.
• Diagnostica continua e misure di mitigazione. Inventario delle risorse e stato dei dispositivi.
• Informazioni sulle minacce. Indicatori interni ed esterni relativi ad attacchi e vulnerabilità appena individuati.
• Registri delle attività e SIEM. Dati telemetrici aggregati utilizzati per perfezionare la politica nel corso del tempo.
• Sistemi di conformità nel settore industriale. Requisiti normativi che l'impresa è tenuta a rispettare.
• PKI. Emissione e convalida dei certificati per soggetti e risorse.

Spesso, durante l'implementazione, i team confondono questo confine, trattando un sistema di gestione delle identità o un feed di minacce come se fossero essi stessi a prendere le decisioni relative all'accesso, mentre nel modello NIST tali sistemi forniscono solo input al motore delle politiche che decide effettivamente. Questa distinzione è particolarmente importante quando si valuta quali parti dell'architettura siano effettivamente coperte da un fornitore.

Come concetto, lo Zero Trust è piuttosto semplice: non fidarsi di nessuno né approvare alcuna azione finché non si è verificata l’identità della persona e autorizzata la richiesta. È proprio nell’implementazione che la maggior parte delle organizzazioni si blocca, poiché lo Zero Trust riguarda contemporaneamente identità, rete, endpoint, applicazioni e dati, e pochi team di sicurezza dispongono del budget o del capitale politico necessario per affrontare tutti e cinque questi aspetti contemporaneamente. Ciò solleva la questione pratica di dove iniziare, e la risposta è quasi sempre l’identità.

Ogni decisione relativa al modello Zero Trust si riduce a un’unica domanda: se quel soggetto sia chi dice di essere e se debba avere quell’accesso in questo momento. La segmentazione e la crittografia non possono rispondere a questa domanda, mentre lo stato di sicurezza dei dispositivi restringe il campo senza risolverla, lasciando l’identità come unico controllo in grado di risolvere la questione. Quando l’identità è debole, ogni controllo a valle applica fedelmente una decisione basata su una premessa non verificata.

L'identità svolge un ruolo fondamentale in tre ambiti:

• Autenticazione. Verifica del soggetto tramite metodi resistenti al phishing piuttosto che segreti condivisi che possono essere rubati, riprodotti o oggetto di ingegneria sociale.
• Autorizzazione. Stabilire a cosa ha diritto un soggetto verificato, sulla base di ruoli regolamentati piuttosto che un accesso maturato nel corso di anni di cambiamenti di ruolo.
• Valutazione continua. Rivalutare entrambi man mano che i segnali di rischio cambiano e revocare l'accesso quando i segnali lo giustificano.

In tutto ciò si nasconde una scomoda conseguenza, ovvero che non è possibile applicare uno standard di “privilegio minimo” che non è mai stato definito, né è possibile definire tale standard senza sapere chi, al momento, abbia accesso a cosa. La maggior parte delle organizzazioni non è in grado di rispondere a questa domanda con certezza, ed è per questo che governance dell'identità va inserito nella fase iniziale di un programma Zero Trust piuttosto che in una fase successiva.

Gestione delle identità e degli accessi fornisce i componenti su cui si basa un’architettura Zero Trust.

Due requisiti tendono ad essere sottovalutati più di ogni altro.

L'autenticazione deve essere a prova di phishing. MFA basato su codici di accesso monouso L'invio tramite SMS o e-mail alza il livello di sicurezza senza però colmare il divario, poiché gli attacchi "man-in-the-middle" e le campagne volte a indurre stanchezza nei confronti dell'autenticazione a più fattori (MFA) riescono a eludere con una certa regolarità i metodi push e OTP. FIDO2 e passkey associati al dispositivo associare la credenziale sia al dispositivo che all’origine: è proprio questo il meccanismo che blocca effettivamente l’attacco, anziché limitarne la velocità. RSA sostiene questa tesi da ben prima che diventasse la posizione condivisa da tutti, in qualità di membro del consiglio direttivo dell’Alleanza FIDO e copresidente del gruppo di lavoro Enterprise.

Access deve continuare a funzionare anche quando il cloud non funziona. Un’architettura che instrada ogni decisione di accesso attraverso un motore di policy cloud introduce, per sua stessa natura, un unico punto di guasto; quando quel servizio diventa irraggiungibile, nessuno può lavorare. Per le organizzazioni che operano in ambienti on-premise, ibridi, air-gapped o a disponibilità costante, dove un’interruzione comporta conseguenze operative piuttosto che semplici disagi, si tratta di un compromesso svantaggioso. L’approccio Zero Trust dovrebbe ridurre il numero di elementi in grado di mettere un’organizzazione fuori linea, anziché concentrarli; ecco perché i percorsi di applicazione offline e on-premise sono ciò che rende il modello sostenibile in questi ambienti.

Una volta che un’organizzazione decide di adottare l’approccio Zero Trust, inizia il vero lavoro. Si tratta di un programma pluriennale e le organizzazioni che ottengono risultati in questo ambito tendono a suddividere il lavoro in fasi, piuttosto che cercare di fare tutto contemporaneamente.

1. Identità delle scorte, risorse e accesso attuale. Il principio del privilegio minimo non può essere applicato in assenza di un punto di riferimento noto; occorre quindi iniziare stabilendo chi e cosa può accedere a quali risorse attualmente, inclusi gli account di servizio, i collaboratori esterni e le identità delle macchine.

2. Rafforzare innanzitutto l'autenticazione. L'implementazione di un'autenticazione a più fattori (MFA) resistente al phishing sui percorsi di accesso più critici garantisce la massima riduzione del rischio per unità di sforzo ed è un prerequisito fondamentale per la maggior parte di quanto segue.

3. Definire e applicare le politiche di accesso. Tradurre i ruoli e le esigenze aziendali in politiche esplicite, quindi eliminare gli accessi generici permanenti e sostituirli con autorizzazioni ben definite e soggette a revisione.

4. Aggiungere contesto alle decisioni relative all'accesso. L'introduzione dell'autenticazione basata sul rischio consente alle richieste a basso rischio di passare senza ostacoli, mentre quelle anomale vengono sottoposte a verifica o bloccate; questo è anche il modo per impedire agli utenti di aggirare il sistema.

5. Risorse di segmento. Limitare l’accesso di una sessione compromessa riduce l’entità del danno nel momento in cui — non “se”, ma “quando” — un controllo fallisce.

6. Monitorare, verificare e revocare. Le revisioni dei diritti devono essere effettuate secondo un calendario prestabilito, poiché l’accesso che si accumula senza essere sottoposto a revisione finisce per diventare proprio quella proliferazione incontrollata di privilegi che il programma avrebbe dovuto impedire.

In questo caso la sequenza è più importante del ritmo, poiché la segmentazione applicata senza un’identità ben definita alla base produce reti ben suddivise che continuano tuttavia a proteggere account con privilegi eccessivi.

Le organizzazioni non raggiungono mai lo Zero Trust. Devono valutare costantemente il proprio livello di sicurezza e riesaminare ogni decisione relativa agli accessi.

Attrito con l'utente. Una verifica troppo invasiva porta alla creazione di soluzioni alternative, all’IT sommerso e a un aumento del carico di lavoro dell’help desk, sebbene l’accessibilità e la sicurezza non debbano necessariamente essere messe in contrapposizione. L’autenticazione basata sul rischio adatta la verifica al rischio che una singola richiesta comporta, anziché applicare ostacoli uniformi a tutti.

Sistemi legacy. Le applicazioni precedenti agli standard di autenticazione moderni spesso non possono essere integrate senza un gateway, un proxy o una sostituzione completa, il che rende questo aspetto il più impegnativo nella maggior parte dei programmi e quello più spesso sottovalutato in fase di pianificazione.

Dipendenza dalla disponibilità. Concentrare le decisioni relative all'accesso in un unico servizio cloud crea una nuova dipendenza critica e, se il motore delle politiche diventa irraggiungibile, tutti si ritrovano esclusi da ogni accesso. Vale la pena chiedere direttamente a qualsiasi fornitore cosa succede all'autenticazione quando il suo servizio smette di funzionare.

Ambito organizzativo. Poiché l’approccio Zero Trust coinvolge i team che si occupano di identità, rete, endpoint, applicazioni e dati, i programmi gestiti interamente da una singola funzione tendono a arenarsi ai confini di tale funzione.

Confondimento dei fornitori. Non esiste un singolo prodotto che garantisca il modello Zero Trust, pertanto è opportuno valutare i fornitori in base ai componenti architetturali che effettivamente forniscono, e l’espressione “piattaforma Zero Trust” va considerata più come un’affermazione da verificare che come una categoria di prodotti da acquistare.

Diffusione incontrollata dei dati identificativi. L'identità rappresenta un problema legato ai dati in continua evoluzione piuttosto che statico, e i diritti di accesso si accumulano più rapidamente di quanto la maggior parte dei team riesca a verificarli manualmente: è proprio a questo punto che l'automazione e l'analisi dei dati smettono di essere facoltative.

Il modello Zero Trust è passato dall'essere una best practice a diventare un requisito in diversi contesti soggetti a regolamentazione.

• Ordine esecutivo 14028 indica Agenzie civili federali statunitensi verso un’architettura Zero Trust.
• Modello di maturità Zero Trust della CISA fornisce il quadro di riferimento in base al quale le agenzie federali valutano il proprio livello di maturità, articolato attorno a cinque pilastri: identità, dispositivi, reti, applicazioni e carichi di lavoro, e dati.
• Strategia "Zero Trust" del Dipartimento della Difesa definisce le attività relative al modello Zero Trust per i componenti di difesa.
• CMMC 2.0 impone requisiti in materia di controllo degli accessi e di autenticazione a più fattori (MFA) in tutto il settore industriale della difesa.
• DORA e NIS2 imporre requisiti in materia di controllo degli accessi, resilienza e continuità operativa a Servizi finanziari dell'UE e le infrastrutture critiche che rispecchiano i principi dello Zero Trust, indipendentemente dal fatto che il termine compaia o meno nel testo.

L'identità figura come pilastro o categoria di controllo in ciascuno di questi casi, ed è anche l’aspetto per cui i revisori tendono a richiedere per primi le prove e per cui le organizzazioni sono meno spesso pronte a fornirle.

Anche i requisiti di resilienza e le architetture esclusivamente basate sul cloud presentano aspetti contrastanti che vale la pena analizzare con anticipo. Le aspettative in materia di continuità operativa previste dal DORA, insieme ai requisiti di disponibilità costante nel settore della difesa e delle infrastrutture critiche, sono difficili da soddisfare utilizzando un modello di accesso che smette di funzionare ogni volta che il servizio di un fornitore diventa irraggiungibile.