Quando il gioco si fa duro, i duri iniziano a giocare

Durante gli ultimi mesi un po’ tutti noi abbiamo dovuto cambiare le nostre abitudini, sia di lavoro, che di acquisti, che di mobilità in generale. Dal punto di vista informatico questo ha comportato una specie di rivoluzione copernicana nell’utilizzo degli strumenti informatici e della rete che ha cambiato radicalmente il tipo di traffico che attraversa le nostre strutture. Si è passati da un sistema “sede-centrico”, cioè dove tutti i compiti istituzionali venivano svolti perlopiù in sede, ad un sistema in cui tutto, dalla didattica, alle attività di ricerca, i servizi, il lavoro amministrativo, e addirittura il settore informatico, vengono fruiti e svolti da casa.

Oltre all’ovvia inversione nella direzione del traffico di rete della propria sede, ci siamo trovati a gestire in emergenza situazioni completamente nuove: lavoratori in smart working, docenti e studenti in didattica a distanza, riunioni, eventi e corsi remoti di ogni genere e, mettere in piedi sistemi funzionanti nel minor tempo possibile, è stata una enorme sfida tecnologica. Dal punto di vista della sicurezza sapevamo che questo avrebbe aperto qualche ferita nel fianco e, adesso che siamo (relativamente) più calmi, cerchiamo di tirare le somme.

Una pandemia anche per gli attacchi informatici

Le somme ci dicono che il numero di attacchi si è moltiplicato di molti fattori durante la pandemia, soprattutto a spese dei client, PC di lavoratori e studenti. È fiorito il phishing, a tema COVID-19 e non solo, ma soprattutto abbiamo visto che la maggior parte di quello che avevamo finora messo in atto per gestire l’accesso di lavoratori e studenti remoti alla nostra intranet sembra non avere più alcun campo di applicazione. Se prima, per esempio, una regola fondamentale era: “chiudo i miei server a tutto il mondo e li apro solo alla sottorete dei dipendenti”, adesso questa semplice regola non è più pensabile o applicabile: non possiamo sapere a priori da quale rete arrivino gli utenti. Questo è un esempio tipico che spiega bene il concetto di assenza di perimetro: non possiamo più chiudere i nostri servizi in una bolla accessibile soltanto da alcune reti, non esiste più differenza fra intranet e internet, i nostri dati e servizi devono poter essere acceduti da qualsiasi parte del mondo, come se fossero esposti direttamente su internet.

Il primo passo che si fa di solito in termini di sicurezza è cercare di ampliare il proprio perimetro, fornendo ai nostri utilizzatori strumenti di accesso remoto come le VPN. In questo caso gli utenti remoti entrano sui server da una rete istituzionale, come se fossero dentro il perimetro. Le VPN sono strumenti usati da sempre per questo tipo di servizi, ma a seguito dell’utilizzo massiccio in pandemia, hanno presentato tutti i loro problemi: scalabilità scarsa o nulla, costi esorbitanti di licenze, difficoltà di gestione delle utenze, dei ruoli e delle reti assegnate. Inoltre ai problemi di implementazione e gestione si aggiungono ulteriori problemi di sicurezza: se con il phishing le password possono essere rubate e utilizzate per qualsiasi servizio, questo succede anche per la VPN. Come possiamo fidarci di un sistema così banale e antico come una password per autenticarci sui sistemi? La coppia utente/password non può bastare per accedere indiscriminatamente a qualsiasi dato! Inoltre i PC degli utenti remoti non sempre sono di proprietà dell’ente, e possono essere infettati o compromessi: la VPN non ci protegge da attacchi all’interno del perimetro, i cosiddetti “movimenti laterali”.

Praticamente stiamo inserendo dentro la nostra intranet macchine sconosciute, che possono girovagare per tutte le reti interne: come possiamo fidarci? Anche in questo caso il perimetro non può essere ampliato più di tanto, o si rischia di portarci in casa anche il nemico.

È quindi forse il caso di fermarsi un attimo a riflettere: tutto quello che sappiamo fare non basta più, è necessario ripensare da zero un nuovo tipo di architettura, immaginare un nuovo modo di dare accesso ai nostri dati e servizi. Insomma, quando il gioco si fa duro.

Si inizia a giocare con Zero Trust.

Non è un concetto nuovo, il problema dell’assenza del perimetro era già stato affrontato da tempo, fin dal 1994, e già allora la soluzione proposta andava nella direzione dello Zero Trust, anche se si chiamava “Black Core”.

Il nome “Zero Trust”, insieme alla sua visione di architettura, fu ideato intorno al 2010 da Forrester Research in partnership con NIST (lo statunitense National Institute of Standards and Technology). Tuttavia in questi ultimi mesi di pandemia si è sentita così tanto la necessità di un sistema che gestisse la sicurezza in assenza di perimetro, che il NIST si è preoccupato di accelerare i lavori e definire uno standard di architettura, in modo che si potesse iniziare ad implementarla. Il risultato è lo standard NIST 800-207, “Zero Trust Technology”, uscito in versione definitiva il 20 Agosto 2020.

Il concetto è esplicitato tutto nel nome: a qualsiasi entità che vuole accedere ai nostri dati, iniziamo a dare “fiducia zero”, e costruiamo un sistema in modo che la fiducia venga progressivamente guadagnata, fino ad ottenere un punteggio di fiducia adeguato ad accedere al dato. Ovviamente la soglia di fiducia dipende dal genere di informazione a cui si vuole accedere: se il dato non è delicato basterà guadagnarsi un punteggio di fiducia non elevato, mentre se il dato fosse addirittura “particolare” (nell’accezione del GDPR) la soglia di fiducia sarà alta e l’utente dovrà guadagnarsela tutta.

Non dare niente per scontato

La prima cosa che si evince da questa breve panoramica è che cambia totalmente il modo di vedere la sicurezza e l’accesso ai dati. Non si parla più di servizi o server, non si parla più di reti, né di sistemi, ma parliamo soltanto di dati e utenti. Semplificando: Zero Trust concentra il suo focus soltanto sul singolo dato, e sul modo migliore per proteggerlo, indipendentemente da dove risieda fisicamente. Possiamo mandare in pensione le VPN!

La decisione di concedere l’accesso al dato si sposta quindi non tanto sull’IP da cui arriva, ma sull’utente che la fa, il suo ruolo, la sua posizione, il suo device, il suo contesto e, per questa ragione, Zero Trust basa tutta l’architettura su un sistema molto forte di autenticazione e autorizzazione.

Il cuore di Zero Trust è il Policy Decision Point e Policy Enforcement Point (PDP/PEP), che si occupano di decidere, di volta in volta, se una richiesta è ammissibile oppure no. Nel caso la richiesta non sia ammissibile, il sistema può decidere se bloccarla oppure, nella maggior parte dei casi, chiedere una forma di autenticazione aggiuntiva, più forte. Questo procedimento non è nuovo, l’abbiamo sperimentato tutti più volte per esempio quando tentiamo di accedere a Gmail da un nuovo device, il sistema ci chiede: ma sei veramente tu? Addirittura a volte ci manda una notifica push sul telefono per chiedere conferma (autenticazione più forte); oppure quando vogliamo fare un pagamento di un bollettino postale tramite app: il sistema ci fa autenticare, immettiamo i dati del bollettino, e per pagare ci viene mandato un SMS con un codice di conferma (autenticazione più forte).

Il funzionamento è il seguente: una volta che l’utente è autenticato il sistema inizia a raccogliere tutte le informazioni che può su di lui e sul suo device: chi è, che ruolo ha nell’organizzazione, quale device sta usando, se il device che usa è dell’organizzazione o sta usando un device suo, se il client che usa è all’ultima versione, la geolocalizzazione tramite l’IP da cui si connette. Tutte queste informazioni vengono raccolte dal PEP e valutate dal PDP per definire il contesto da cui arriva la richiesta e assegnare un punteggio di fiducia. Ma non solo, in un sistema Zero Trust è necessario tenere uno “storico” del comportamento dell’utente: da quali IP di solito si collega, quali sono i suoi device più utilizzati. Inoltre si valuta la fase stessa di autenticazione: se per esempio cerca di connettersi 50 volte al minuto, o se sbaglia la password più di 10 volte.

Tutti questi dati ci aiutano tantissimo a capire se una richiesta è valida e lecita oppure potrebbe essere un tentativo di ingresso da parte di un malfattore. Quando i dati a disposizione durante la fase di autenticazione non convincono del tutto il PDP, non si supera la soglia di fiducia per accedere a quella risorsa e viene chiesta una forma di autenticazione aggiuntiva, in modo da aumentare il punteggio di fiducia o perderla del tutto. Per esempio se Mario Rossi tenta di connettersi 50 volte in un minuto, o da un IP cinese, probabilmente non è Mario Rossi, ma un robot che ci sta provando, quindi il punteggio di fiducia di quella richiesta cala drasticamente. Va notato che in Zero Trust viene screditata quella singola richiesta, che è sospetta, non Mario Rossi in generale, che può continuare tranquillamente a lavorare e a fare richieste legittime.

Architettura di una singola richiesta ad una risorsa da parte di un utente col suo device, che sono nella “untrusted zone”. In Zero Trust un utente, ma anche una risorsa, può essere in qualsiasi posto nel mondo.

Mi piace chiudere questa piccola panoramica su Zero Trust segnalando che l’esperienza degli utenti in Zero Trust risulta essere molto più positiva e confortevole che in un ambiente classico, in quanto le richieste non vengono mai bloccate, l’utente non viene mai screditato, non deve chiedere all’ufficio IT regole speciali sui router per far passare le proprie richieste, nella peggiore delle ipotesi gli si chiede una autenticazione più forte, cosa che lo fa sentire “seguito” e supportato nel proprio lavoro, invece che ostacolato dai soliti paletti di sicurezza.