Zero trust interessa tutto: identità, applicazioni, reti, dati e dispositivi. L’approccio migliore però è non cambiare tutto in una volta, ma iniziare dal quadro generale. Nella nostra ricerca, abbiamo scoperto che le organizzazioni di maggior successo hanno dedicato la prima fase delle loro iniziative zero trust all’elaborazione di un’architettura, senza affrettarsi a implementare soluzioni una dietro l’altra.

Altre organizzazioni invece si sono fiondate velocemente su questo modello, mescolando il lavoro fondamentale sul zero trust con riarchitettura delle reti, sicurezza e gestione dei dati, acquisto di strumenti e formazione di team di implementazione. Tutti questi progetti devono ovviamente concretizzarsi, ma quando c’è di mezzo zero trust vale la pena pensare molto di più a come tutti i pezzi si incastreranno insieme prima di intraprendere le modifiche necessarie a livello architettonico o nel set di strumenti.

Quando parliamo di successo della sicurezza, in questo caso intendiamo organizzazioni con un tasso molto basso di gravi incidenti di sicurezza informatica. Secondo il Secure Cloud Access and Policy Enforcement Research Study 2021-22 di Nemertes, le organizzazioni di maggior successo hanno avuto, al massimo, due incidenti gravi ogni 100 incidenti di sicurezza informatica. E nella maggior parte dei casi, queste organizzazioni di successo hanno mantenuto i loro tassi ben al di sotto di questa soglia del 2%.

Pianificazione zero trust

Zero trust richiederà quasi sicuramente modifiche a livello di architettura per la rete, la sicurezza e l’accesso ai dati. Questo ha senso se si considera il concetto che zero trust mira a rendere reale, ovvero che non può esistere una fiducia implicita quando si parla di sicurezza.

Zero trust va necessariamente a toccare ogni aspetto delle operazioni e ogni livello dei sistemi. Inoltre, è un cambiamento radicale rispetto al paradigma attualmente dominante che porta a fidarsi di alcune parti di una rete più di altre, di alcuni utenti più di quanto sia necessario solo per la posizione in cui si trovano all’interno dell’organizzazione. Tuttavia, le modifiche a questi sistemi di base devono essere prese in considerazione solo dopo che il quadro generale del vostro ambiente zero-trust è stato ben definito.

Ad esempio, i vostri architetti potrebbero decidere che se l’entità A desidera utilizzare il servizio B ma non dispone attualmente dell’autorizzazione per farlo, A non sarà nemmeno in grado di vedere o ottenere pacchetti a B attraverso la rete, per non parlare di inviare le credenziali. In tal caso, potrebbe essere necessario riprogettare la rete.

zero trust

Oppure, l’attuazione zero trust potrebbe essere gestita a livello di endpoint per i sistemi in grado di eseguire un client perimetrale definito dal software e la rete potrebbe essere richiesta solo per gestire l’applicazione delle policy per i dispositivi che non possono farlo (dei sensori, ad esempio). In entrambi i casi, queste scelte di alto livello dovrebbero, per quanto possibile, essere fatte prima che inizino le riprogettazioni negli spazi tecnologici separati.

Ottenere gli strumenti e i talenti giusti

Una volta che l’architettura di alto livello e le varie architetture specifiche sono state definite, l’IT dovrebbe passare alle questioni di implementazione. Come sempre, ciò coinvolgerà le persone, i processi, le politiche e la tecnologia. Per quanto riguarda le persone, la maggior parte delle organizzazioni (comprese quelle di maggior successo) mette insieme team di implementazione interfunzionali all’inizio di un’implementazione zero trust.

Questi team si occupano degli aspetti iniziali del passaggio dalla teoria alla pratica, ma poiché zero trust è un importante cambiamento nei presupposti fondamentali sulla sicurezza e l’accesso, non può esserci un “team zero trust” a lungo termine. A lungo termine, infatti, tutti fanno parte del team zero trust.

Nel breve termine, tuttavia, il personale chiave dell’ingegneria di rete, della gestione dei dati e dell’ingegneria delle applicazioni dovrebbe concentrarsi sull’avvio dell’implementazione zero trust e proporre quali strumenti sono necessari per colmare le lacune tra gli strumenti da mantenere, o per sostituire i vecchi sistemi con quelli più funzionali, o per fornire l’orchestrazione delle politiche esecuzione tra strumenti. Sarà un perimetro definito dal software (SDP)? Se sì, per quali funzioni?

Il team zero trust fornirà anche il primo step delle modifiche alle politiche di sicurezza e di accesso, decidendo ad esempio quali tipi di accesso ai sistemi saranno concessi a qualsiasi dipendente e quali saranno invece vincolati a specifiche responsabilità lavorative. Il risultato è che la transizione verso lo zero trust inizia con un’architettura zero trust; tutto il resto deriva da questo punto di partenza. Ci sono molti altri livelli di architettura necessari a implementare il nuovo paradigma della “fiducia \ero”, ma tutto deve iniziare con un quadro generale ben definito.