Zero Trust Security: come assegnare correttamente il livello di fiducia agli utenti aziendali

È prassi diffusa confondere la fiducia negli utenti con quella nei dispositivi. Le organizzazioni più attente alla cyber security inseriscono certificati digitali X.509 nei dispositivi degli utenti al fine di generare credenziali più solide rispetto a quelle fornite dalle password.

Si potrebbe pensare che il certificato nel dispositivo identifichi in maniera irrevocabile l’utente che lo sta utilizzando, ma è proprio così? Come facciamo a sapere che l’utente a cui avevamo assegnato il dispositivo e il certificato digitale, effettivamente è seduto di fronte alla postazione? Non è che magari ha lasciato il suo dispositivo incustodito e sbloccato?

Il connubio tra l’identità dell’utente e l’identità del dispositivo può generare problematiche che siamo chiamati a gestire quando gli utenti hanno più dispositivi, condizione che sta diventando progressivamente la norma nella maggior parte delle organizzazioni: le credenziali spesso vengono copiate tra diversi dispositivi, esponendole a un maggior rischio di cattura o compromissione, così come i dispositivi potrebbero richiedere credenziali diverse in base alle loro funzionalità.

Nelle reti ICT che utilizzano postazioni di lavoro condivise da più utenti, questo problema si acuisce.

Le reti Zero Trust identificano e considerano attendibili gli utenti separatamente dai dispositivi. A volte l’identificazione di un utente utilizza la medesima tecnologia utilizzata per identificare i dispositivi, ma teniamo ben presente che trattasi di due credenziali separate.

Questo articolo si focalizza su ciò che significa identificare un utente e memorizzare la sua identità: vedremo come e quando autenticare gli utenti. La fiducia degli utenti generalmente è più forte quando sono coinvolte più persone, quindi, discuterò di come creare fiducia di gruppo e come costruire una cultura della sicurezza informatica.

Zero Trust Security: il ruolo dell’Identity Authority

Ogni utente dispone di un’identità, che rappresenta il modo in cui è conosciuto in una comunità più ampia. Nel caso di un sistema in rete, l’identità di un utente consente al soggetto di essere riconosciuto e censito in quel sistema.

Può sembrare banale apparentemente, ma dato il numero di individui nel mondo, identificare un utente può essere un problema sorprendentemente complicato. Esploriamo due tipi di identità:

1. identità informale;
2. identità autorevole.

L’identità informale è il modo in cui i gruppi autodefiniscono un’Identità. Consideriamo una situazione reale in cui incontriamo qualcuno: in base a come appare e soprattutto si comporta, possiamo definire l’identità per quella persona.

Quando incontreremo nuovamente il soggetto di persona, possiamo ragionevolmente presumere che sia la stessa persona in base ad un matching tra le caratteristiche fisiche che rammentiamo dal nostro ultimo incontro e quelle attuali.

L’identità informale viene utilizzata nei sistemi informatici: gli account pseudonimi, account che non sono associati al proprio nome nel mondo reale, sono diffusissimi nelle organizzazioni online.

Mentre l’effettiva identità di un individuo non è necessariamente nota in queste comunità, attraverso ripetute interazioni si crea un’identità informale.

L’identità informale funziona in piccoli gruppi, dove la fiducia tra gli individui è alta mentre i rischi sono relativamente bassi, ma questo tipo di identità ha chiari punti deboli quando la posta in gioco diventa più alta:

1. gli utenti potrebbero crearsi un’identità fittizia;
2. potrebbero rivendicare l’identità di un’altra persona;
3. potrebbero crearsi più identità;
4. più individui in comune accordo potrebbero condividere un’unica identità.

Quando è richiesta una forma di identità più precisa, un ente preposto deve rilasciare delle apposite credenziali di identità per gli individui.

Nel mondo reale, questo ente spesso è costituito dai governi: i documenti d’identità rilasciati dal governo (ad esempio, una patente di guida o un passaporto) vengono distribuiti ai cittadini per consentirci di interagire con le Istituzioni ma soprattutto per rappresentare la nostra identità nei confronti di aziende, di università, di svariate organizzazioni e di tutti gli altri cittadini.

Per le situazioni a basso rischio, questi documenti da soli sono una prova sufficiente della propria identità.

Tuttavia, per situazioni a rischio più elevato, il controllo incrociato delle credenziali con i database governativi fornisce una verifica più scrupolosa. I sistemi informatici spesso necessitano di un’autorità centralizzata per rilasciare un’identità agli utenti che la chiedono.

Analogamente al mondo reale, agli utenti vengono concesse credenziali (di vario grado) che li identificano nel sistema. In base al grado di rischio, potrebbe essere opportuno eseguire un controllo incrociato delle credenziali rispetto a un database centralizzato.

Le credenziali possono essere perse o rubate, quindi è fondamentale che una Identity Authority disponga di meccanismi che consentano alle persone di riprendere il controllo della propria identità.

Nel caso di un documento d’identità rilasciato dal governo, una persona spesso deve presentare altre informazioni identificative (come, ad esempio, un certificato di nascita o un’impronta digitale) a un’autorità governativa per far rilasciare il proprio documento d’identità.

Allo stesso modo, i sistemi informatici necessitano di meccanismi che consentano a un utente di riprendere il controllo della propria identità in caso di smarrimento o furto delle credenziali: questi sistemi richiedono spesso la presentazione di un’altra forma di verifica, ad esempio un codice di recupero o una credenziale di autenticazione alternativa.

La scelta del materiale necessario per riottenere la propria identità può avere implicazioni nella cyber security, di cui parlerò in seguito.

Inizializzazione delle identità in un sistema privato

Memorizzare e autenticare l’identità degli utenti è fondamentale ma, per cominciare, come si genera un’identità?

Quando interagiamo con i sistemi informatici abbiamo bisogno di un modo per rappresentare digitalmente l’identità degli utenti, e cerchiamo di legare quella rappresentazione digitale il più strettamente possibile al mondo reale umano.

La genesi di un’identità digitale, e il suo iniziale abbinamento a un essere umano, è un’operazione molto delicata.

I controlli per autenticare l’essere umano al di fuori del tuo sistema digitale devono essere capillari per impedire, ad esempio, a un utente malintenzionato di mascherarsi da nuovo dipendente o consulente.

Controlli simili potrebbero essere esercitati anche per le procedure di recupero dell’account nei casi in cui l’utente non è in grado di fornire le proprie credenziali aggiornate.

Data la delicatezza di questa operazione, è importante progettare e applicare una precisa policy al modo in cui viene gestita.

Una delle principali raccomandazioni per eseguire l’autenticazione umana è attraverso l’uso dell’identificazione rilasciata dal governo. In alcune implementazioni, potrebbe anche essere necessario richiedere forme sequenziali di identificazione, alzando il livello di sicurezza per bloccare anticipatamente potenziali impostori.

Va da sé che il personale deve essere opportunamente addestrato alla convalida dei documenti d’identità, per evitare che i controlli possano essere aggirati.

Per fidarsi degli utenti, in genere i sistemi professionali necessitano di record centralizzati contenenti informazioni sugli utenti. La propria presenza in tali record è la base su cui si verificheranno tutte le future autenticazioni: avere tutti questi dati altamente sensibili archiviati centralmente è una sfida che non può essere evitata.

Una rete ZTS fa uso di numerosi dati utente per prendere le decisioni di autenticazione migliori.

I database utente memorizzano informazioni tradizionali come account, numeri di telefono e ruoli nell’organizzazione, nonché informazioni estese come la posizione dell’utente prevista, piuttosto che la chiave pubblica di un certificato X.509 che è stato rilasciato.

Data la natura sensibile dei dati archiviati sugli utenti, è meglio non archiviare tutte le informazioni insieme in un unico database: le informazioni sugli utenti in genere non sono considerate segrete, ma diventano cruciali quando si utilizzano tali dati per prendere decisioni autorizzative.

Inoltre, avere un’ampia conoscenza di tutti gli utenti in un sistema può rappresentare un rischio per la privacy. Ad esempio, un sistema che memorizzi l’ultima posizione nota di tutti gli utenti potrebbe essere utilizzato per spiarli.

Anche i dati utente archiviati possono rappresentare un rischio per la cyber security se possono essere sfruttati per attaccare un altro sistema.

Prendiamo in considerazione i sistemi che richiedono agli utenti informazioni basate sui fatti come mezzo per convalidare ulteriormente la loro identità: invece di archiviare tutte le informazioni utente in un unico database, valuta la possibilità di suddividere i dati in diversi database isolati; questi database dovrebbero idealmente essere esposti solo tramite un’API offuscata, che limiti le informazioni divulgate.

Nel migliore dei casi, i dati grezzi non verranno mai divulgati, ma piuttosto, potranno essere fatte affermazioni aggiornate su di un utente dall’applicazione che ha accesso ai dati.

Ad esempio, un sistema che memorizzi la precedente posizione nota di un utente potrebbe esporre le seguenti API:

1. l’utente è attualmente vicino a queste coordinate, o piuttosto è probabile che si trovi vicino a queste coordinate?
2. qual è la frequenza con cui l’utente cambia posizione?

Mantenere aggiornate le directory degli utenti è fondamentale per la sicurezza di una rete ZTS.

Ci si aspetta che gli utenti vadano e vengano per tutta la durata di un sistema di rete, quindi dovrebbero essere create efficienti procedure di onboarding e offboarding per mantenere il sistema “vivo” e accurato.

Per quanto possibile, è meglio integrare i sistemi di Identità già in essere (LDAP o account utente locali) nei sistemi organizzativi.

Ad esempio, un’azienda potrebbe disporre di software gestionali proprietari per tenere traccia dei dipendenti che lasciano o si uniscono all’azienda: ci si aspetta che queste due fonti di dati siano coerenti tra loro, ma a meno che non ci sia un sistema automatizzato piuttosto che un addetto che le abbia integrate o ne stia verificando il contenuto, le serie di dati generalmente divergono con rapidità (e la creazione di processi automatizzati per la connessione di questi sistemi è uno sforzo che ripaga ampiamente).

Il caso di due sistemi di identità divergenti solleva un punto cardinale: quale tra i due sistemi è autorevole?

Chiaramente un’Identity Authority deve poter registrare e generare le identità, ma tale scelta deve essere effettuata in base alle esigenze dell’organizzazione: non importa tanto quale sistema viene scelto, quanto che uno sia autorevole e tutti gli altri sistemi di Identità derivino i propri dati dal sistema principale.

Non è obbligatorio che un sistema di archiviazione e tracciamento delle identità contenga necessariamente tutte le informazioni sulle identità: infatti, è più prudente segmentare intenzionalmente i dati degli utenti: il sistema memorizzerà così le sole informazioni minimali per l’identificazione univoca dell’individuo.

Questo scenario potrebbe essere raggiunto con semplicità memorizzando uno username e alcune informazioni personali con cui l’utente possa recuperare la propria Identità nel caso la dimenticasse.

I sistemi derivati potranno utilizzare questo “ID autorevole” per memorizzare ulteriori informazioni sull’utente.

Anche se in una rete Zero Trust l’autenticazione è obbligatoria, può essere applicata in modi ingegnosi da una parte per rafforzare significativamente la cyber security, dall’altra per ridurre al minimo i disagi degli utenti.

Anche se può essere allettante (e persino logico) adottare una posizione ferrea del tipo “Non dovrebbe essere facile, ma sicuro”, la comodità degli utenti è un altro dei fattori da non trascurare nella progettazione di una rete Zero Trust.

Le tecnologie di sicurezza informatica che presentano un’esperienza utente insoddisfacente vengono spesso indebolite e sistematicamente trascurate dagli stessi utenti. Un’esperienza negativa disincentiverà l’utente dall’interagire con la tecnologia, e le scorciatoie per eludere l’applicazione delle norme verranno attuate sempre più spesso.

Essenzialmente l’autenticazione di un utente è un sistema che cerca di verificare che l’utente sia effettivamente chi sostiene di essere.

I metodi di autenticazione hanno livelli diversi di efficacia, e alcuni sono più adeguati se combinati con altri. Dato che i meccanismi di autenticazione non sono mai assoluti, possiamo assegnare un certo livello di fiducia al risultato dell’operazione.

Ad esempio, potremmo aver bisogno solo di una password per accedere ad un servizio di streaming a cui siamo abbonati, mentre l’accesso ad un home banking richiede come minimo una password e un secondo fattore di autenticazione, e questo perché un home banking è un sistema delicato: il sistema deve avere fiducia nell’autenticità dell’utente.

Un servizio di streaming, invece, non è così attento tant’è che sceglie di non richiedere un codice aggiuntivo, poiché farlo sarebbe un costo aggiuntivo a livello d’infrastruttura, ma soprattutto un fastidio per l’utente medio.

In aggiunta, un utente può dover superare ulteriori forme di autenticazione per aumentare il proprio livello di fiducia: questo può essere fatto specificatamente in particolare necessità.

A un utente il cui punteggio di fiducia è sceso al di sotto dei requisiti per una particolare richiesta, può essere chiesta una prova aggiuntiva, che, se superata, riporterà la fiducia ai livelli accettabili.

Questo è tutt’altro che un approccio inusuale, tant’è che possiamo riscontrarlo nell’uso comune oggi: richiedere agli utenti di inserire nuovamente la propria password prima di eseguire un’operazione sensibile è un esempio attualissimo di questo approccio in azione.

Si noti, tuttavia, che la quantità di fiducia che si può ottenere attraverso i soli meccanismi di autenticazione non dovrebbe essere illimitata.

Poiché l’autenticazione deriva dalla fiducia, ed è il nostro obiettivo principale non trascinare in maniera superficiale gli utenti attraverso le applicazioni e i sistemi aziendali, ha senso utilizzare il punteggio di fiducia come meccanismo che impone requisiti di autenticazione.

Ciò significa che a un utente non dovrebbe essere chiesto di autenticarsi ulteriormente se il suo punteggio di fiducia è sufficientemente alto, ma al contrario, l’autenticazione dovrebbe essergli imposta quando il suo punteggio dovesse diventare pericolosamente basso: in questo modo si offrirà al sistema l’opportunità di scegliere una combinazione di metodi per raggiungere l’obiettivo, possibilmente riducendo l’invasività, fornendo contestualmente informazioni sul livello di sensibilità e conoscenza di quanto ogni metodo sia attendibile.

Questo approccio è fondamentalmente diverso dagli approcci tradizionali alla progettazione dell’autenticazione che cercano di designare le aree e le azioni più sensibili e autenticarle in modo più pesante: per certi versi, l’approccio tradizionale può essere paragonato alla sicurezza perimetrale, in cui le azioni sensibili devono superare un particolare test, dopo il quale non sono presenti ulteriori protezioni.

Viceversa, sfruttare il punteggio di affidabilità per guidare queste decisioni rimuove i requisiti di autenticazione arbitrari, configurando al tempo stesso le autenticazioni e le autorizzazioni adattative che vengono richieste solo quando necessario.

Canali multipli per raggiungere gli utenti

Quando si autentica e si autorizza una richiesta, l’utilizzo di più canali per raggiungere l’utente può essere molto efficace.

I codici monouso forniscono un ulteriore fattore di autenticazione, soprattutto quando il sistema di generazione del codice si trova su un dispositivo separato.

Le notifiche push forniscono una funzionalità simile utilizzando una connessione attiva in un dispositivo mobile. Esistono molte applicazioni di questo approccio, e possono assumere forme diverse.

A seconda del caso d’uso, si può optare per sfruttare più canali come parte integrante di uno schema di autenticazione.

In alternativa, questi canali potrebbero essere utilizzati esclusivamente come componente di autorizzazione, in cui a un utente potrebbe essere richiesto di approvare un’operazione rischiosa: entrambi gli usi sono efficaci di per sé, anche se l’esperienza dell’utente dovrebbe (come sempre) essere tenuta presente quando si decide quando e dove applicarli.

I canali di comunicazione sono costituiti da diversi gradi di autenticazione e fiducia. Quando si sfruttano più canali, è importante capire quanta fiducia è opportuno riporre nel canale stesso: questo determinerà quali canali saranno selezionati per l’utilizzo, e quando.

Ad esempio, i dispositivi fisici basati su OTP sono sicuri tanto quanto il sistema utilizzato per distribuirli o il controllo di identificazione richiesto per ottenerne fisicamente uno dal sysadmin.

Allo stesso modo, una richiesta tramite un sistema di chat aziendali è robusta quanto le credenziali richieste per accedervi. In primo luogo, assicurati di utilizzare un canale diverso da quello che stai tentando di autenticare/autorizzare.

Sfruttare più canali è efficace non perché compromettere un canale sia impossibile per l’attacker, ma perché è difficile comprometterne molti.

Caching dell’identità e della fiducia

Il caching delle sessioni è una tecnologia matura e ben documentata, a cui non dedicherò molto spazio per tali motivi, ma è importante evidenziare alcune scelte di progettazione che sono importanti per un funzionamento impeccabile in una rete Zero Trust.

La convalida frequente dell’autorizzazione del client è fondamentale: è uno dei pochi meccanismi che consentono al piano di controllo di effettuare modifiche nelle applicazioni del piano dati come risultato di cambiamenti nella fiducia.

Quanto più frequentemente può essere fatto, meglio è. Alcune implementazioni autorizzano ogni richiesta con il piano di controllo: anche se questo è l’ideale, a seconda della situazione potrebbe non essere una prospettiva realistica.

Molte applicazioni convalidano i token SSO solo all’inizio di una sessione e, successivamente, impostano i propri token. Questa modalità operativa rimuove il controllo della sessione dal piano di controllo ed è rischiosa.

L’autorizzazione delle richieste attraverso token del piano di controllo anziché attraverso i token dell’applicazione consente di effettuare facilmente revoche quando i livelli di fiducia fluttuano o si indeboliscono.

Come autenticare le identità

Appurato quando autenticare l’utente, cerchiamo di comprendere come autenticarlo.

Esistono tre modi per identificare gli utenti:

1. in base a qualcosa che conoscono (come una password conosciuta solo dall’utente);
2. in base a qualcosa che hanno (una credenziale fisica che l’utente può fornire (ad esempio, un token con una password temporizzata);
3. in base a qualcosa che impersonano (una caratteristica intrinseca dell’utente, ad esempio un’impronta digitale o la retina).

Tralasciando il primo punto, che indubbiamente il lettore conoscerà già anche per via dei fiumi di parole spesi da innumerevoli autori ed esperti InfoSec, concentriamoci sugli altri due metodi.

Identificare gli utenti in base a qualcosa che hanno

La password monouso con scadenza, o TOTP (Time-based One-Time Password) costituiscono uno standard di autenticazione in cui l’utente fornisce un codice che in realtà cambia tempestivamente, ed RFC 6238 ne definisce lo standard implementativo adottato nei dispositivi hardware e nelle applicazioni software.

Che si utilizzi un’applicazione o un dispositivo hardware, TOTP richiede la condivisione di un valore segreto casuale tra l’utente e il servizio. Questo segreto insieme all’orario corrente vengono fatti passare attraverso una funzione hash, quindi troncati per produrre il codice da inserire.

Finché il dispositivo e il server concordano sull’ora corrente, un codice corrispondente conferma che l’utente è in possesso della chiave condivisa.

L’archiviazione della chiave condivisa è fondamentale, sia sul dispositivo che sul server di autenticazione. La perdita del controllo di quel segreto interromperebbe permanentemente questo meccanismo di autenticazione: la RFC consiglia di cifrare la chiave utilizzando un dispositivo hardware come un TPM, e successivamente di limitare l’accesso ai dati cifrati.

L’utilizzo della chiave condivisa in un dispositivo mobile la espone a un pericolo maggiore rispetto all’utilizzo in un server: il dispositivo potrebbe infatti connettersi a un endpoint dannoso, o potrebbe ospitare un’app malevola (come negli smartphone) che potrebbe essere in grado di estrarre la chiave.

Per mitigare questo vettore d’attacco, un’alternativa al TOTP è quella di inviare al cellulare dell’utente un codice casuale su un canale crittografato: questo codice viene quindi inserito su un altro dispositivo per accertarsi che l’utente è in possesso del proprio telefono cellulare.

Attenzione: come ripeto da anni ai miei studenti e clienti, gli SMS non costituiscono un canale sicuro per l’invio di credenziali o di codici.

L’invio di un codice per l’autenticazione richiederebbe che il codice stesso venga consegnato in modo affidabile al dispositivo destinatario, ergo che non venga esposto durante il transito: il ricercatore Karsten Nohl ha dimostrato da tempo le insicurezze intrinseche nel protocollo SS7, e di come sia possibile intercettare SMS altrui con budget irrisori.

Un altro metodo per autenticare gli utenti consiste nell’associare un certificato X.509 ad ognuno di loro. Il certificato deriva da una chiave privata complessa, e successivamente firmata utilizzando la chiave privata dell’organizzazione che ha fornito il certificato. Il certificato non può essere modificato senza invalidare la firma dell’organizzazione, ergo può essere utilizzato come credenziale con qualsiasi servizio che consideri attendibile la firma dell’organizzazione.

Un certificato X.509 è in grado di fornire numerosi dettagli quando viene presentato a un servizio d’autenticazione. Ad esempio, un sistema potrebbe codificare i metadati dell’utente nel certificato, e quindi rendere attendibili tali dati poiché firmati dalla Certification Authority interna.

L’utilizzo dei certificati per identificare gli utenti dipende in gran parte dalla loro archiviazione sicura: è assai preferibile generare ed archiviare la componente della chiave privata su hardware dedicato in modo da prevenire il furto digitale (chi non ricorda lo scioccante caso Diginotar?).

Un altro metodo per autenticare gli utenti consiste nell’usare token hardware di sicurezza: dispositivi utilizzati principalmente per l’autenticazione dell’utente, ma in grado di fornire applicazioni aggiuntive.

Non sono dispositivi di archiviazione di massa che memorizzano una credenziale fornita altrove, viceversa, l’hardware stesso genera una chiave privata, e le informazioni sulle credenziali non lasciano mai il token.

Il dispositivo interagisce con le API dell’hardware al fine di eseguire operazioni crittografiche per conto dell’utente: con il progredire della cyber security è verosimile affermare che le organizzazioni si affideranno sempre più a meccanismi hardware per l’autenticazione dell’identità degli utenti, tant’è che dispositivi come smart card o Yubikey possono fornire un’asserzione 1:1 di una particolare identità.

Associando l’identità all’hardware, il rischio che le credenziali di un particolare utente possano essere duplicate a sua insaputa viene notevolmente ridotto, poiché sarebbe necessario un furto fisico (scenario diametralmente opposto, purtroppo, in tutti quegli home banking che usano lo smartphone dell’utente come generatore TOTP): la chiave privata memorizzata può quindi essere utilizzata come supporto per schemi di autenticazione differenti.

Tradizionalmente vengono utilizzati insieme a X.509, ma ad esempio Universal 2nd Factor (U2F) fornisce un’alternativa all’approccio tramite PKI, offrendo un protocollo di risposta progettato specificatamente per l’utilizzo da parte dei servizi web.

Sebbene i token hardware forniscano una valente protezione contro il furto di credenziali, non garantiscono che il token stesso non venga rubato o utilizzato in maniera impropria.

Pertanto, è importante riconoscere che, sebbene questi token siano ottimi strumenti per costruire un sistema informatico sicuro, non possono sostituire completamente l’affermazione della propria identità da parte di un utente.

Identificare gli utenti in base a qualcosa che impersonano

Se vogliamo la massima garanzia che un particolare utente sia chi dichiara di essere, è comunque fortemente raccomandato l’utilizzo di una chiave di sicurezza con fattori di autenticazione aggiuntivi (ad esempio, una password o ancor meglio un sensore biometrico).

Affermare l’identità riconoscendo le caratteristiche fisiche dell’utente è ciò che fa di mestiere la biometria.

La biometria sta diventando sempre più pervasiva man mano che i sensori si fanno avanti nei dispositivi che usiamo ogni giorno. Questo sistema di autenticazione offre una maggiore comodità e potenzialmente un sistema più sicuro se i segnali biometrici, come i seguenti, vengono utilizzati in maniera combinata:

1. impronte digitali;
2. impronte delle mani;
3. scansioni della retina;
4. analisi della voce;
5. riconoscimento facciale.

L’uso della biometria potrebbe sembrare il metodo di autenticazione ideale, dopotutto, autenticare un utente significa poter confermare che è esattamente chi sostiene di essere. Cosa c’è di meglio che misurare le caratteristiche fisiche di un utente?

Sebbene la biometria sia un utile complemento alla sicurezza dei sistemi ICT, ci sono alcuni aspetti negativi che non dovrebbero essere trascurati.

L’autenticazione tramite dati biometrici si basa sulla misurazione accurata di una caratteristica fisica: se un attacker riuscisse a ingannare lo scanner, potrà accedere. Le impronte digitali, essendo un comune sistema biometrico, vengono lasciate su tutto ciò che una persona tocca, e infatti nel corso degli anni sono emersi e sono stati dimostrati attacchi contro lettori di impronte digitali: gli aggressori ottengono immagini di un’impronta digitale latente e poi ne stampano una falsa in 3D, che lo scanner accetta.

Inoltre, le credenziali biometriche non possono essere variate, poiché costituiscono una caratteristica fisica. Possono anche presentare un problema di accessibilità se, ad esempio, un individuo nasce senza impronte digitali (una condizione nota come adermatoglifia) o se perde le dita in un incidente.

Infine, la biometria può presentare sfide legali insidiose se confrontata con altri meccanismi di autenticazione. Negli Stati Uniti, ad esempio, un cittadino può essere obbligato da un tribunale a fornire la propria impronta digitale per autenticarsi su un dispositivo, ma non lo si può obbligare a divulgare la propria password a causa del Quinto Emendamento contro l’autoincriminazione!

Autenticazione out-of-band

L’autenticazione out-of-band utilizza intenzionalmente un canale di comunicazione separato rispetto al canale primario utilizzato dall’utente per autenticare la richiesta. Ad esempio, un utente che accede a un sito Web per la prima volta, potrebbe ricevere una telefonata per convalidare la richiesta sul suo dispositivo.

Avvalendosi di un controllo out-of-band, un servizio può aumentare la complessità necessaria per violare un account, poiché l’attacker avrebbe bisogno anche di accedere al canale di comunicazione secondario.

I controlli out-of-band possono presentarsi sotto forme diverse, e dovrebbero essere selezionati in base al livello di criticità per ciascuna interazione:

1. un’e-mail di servizio può informare gli utenti di azioni potenzialmente rischiose che hanno avuto luogo di recente;
2. può essere richiesta una conferma prima che la richiesta venga completata; la conferma potrebbe essere un semplice “sì”, oppure potrebbe comportare l’inserimento di un codice TOTP;
3. una terza parte potrebbe essere contattata per confermare l’esecuzione dell’azione richiesta.

Se utilizzata a dovere, l’autenticazione out-of-band diventa uno strumento formidabile per aumentare la sicurezza del sistema.

Lo schema di autenticazione Single Sign-On

Dato l’elevato numero di servizi con cui gli utenti interagiscono, disaccoppiare l’autenticazione offre vantaggi sia per il servizio che per l’utente:

1. gli utenti dovranno autenticarsi solo con un unico servizio;
2. le credenziali di autenticazione sono archiviate in un servizio dedicato, a cui possono essere applicati i più rigorosi standard di sicurezza informatica;
3. credenziali in meno sedi significano, automaticamente, meno rischi e rotazioni semplificate.

Il Single Sign-On (SSO) è uno schema di autenticazione ormai utilizzatissimo.

Attraverso il SSO gli utenti si autenticano attraverso una Identity Authority, dopodiché verrà assegnato loro un token. Questo token viene quindi utilizzato in ulteriori comunicazioni con i servizi protetti.

Quando il servizio riceverà una richiesta, contatterà l’Identity Authority su di un canale sicuro per convalidare il token fornito dal client.

Questo approccio è in contrasto con l’autenticazione decentralizzata: una rete Zero Trust che impieghi l’autenticazione decentralizzata utilizzerà il piano di controllo per inserire credenziali e policy di accesso nel piano dati. Ciò consente al piano dati di eseguire l’autenticazione autonomamente quando e dove necessario, pur essendo supportato dalle policy del piano di controllo.

Questo approccio talvolta è preferibile rispetto a un approccio basato su SSO poiché non richiede l’esecuzione di un servizio aggiuntivo, sebbene introduca una complessità tale da non essere consigliato.

I token SSO dovrebbero essere convalidati rispetto all’Identity Authority il più spesso possibile.

Ogni chiamata al piano di controllo per autorizzare un token SSO offre l’opportunità di revocare l’accesso o modificare il livello di fiducia.

Una modalità operativa diffusa prevede che il servizio esegua il proprio accesso, supportato dall’autenticazione SSO.

Lo svantaggio principale di questo approccio è che consente al Piano di controllo di autorizzare la richiesta solo una volta, lasciando poi che sia l’applicazione a prendere tutte le successive decisioni.

La varianza e l’invalidazione della fiducia sono aspetti chiave di una rete Zero Trust, quindi, la decisione di applicare o meno questo modello non dovrebbe essere presa alla leggera. L’SSO esiste da molto tempo e, come tale, esistono svariati protocolli e tecnologie affidabili per supportarlo, inclusi SAML, Kerberos e CAS.

In una rete Zero Trust è fondamentale che l’autenticazione rimanga una prerogativa del piano di controllo. Pertanto, quando si progettano sistemi di autenticazione in contesti ZTS, è opportuno puntare alla massima responsabilità possibile del piano di controllo, così come convalidare l’autorizzazione attraverso di esso il più spesso possibile.

Autenticazioni locali e di gruppo

L’autenticazione locale estesa ai servizi remoti è un altro meccanismo di autenticazione che sta diventando sempre più diffuso. In questo sistema gli utenti autenticano la propria presenza con un dispositivo affidabile, e a sua volta il dispositivo attesterà tale Identità con un servizio remoto.

Gli standard aperti come l’UAF della FIDO Alliance utilizzano crittografia asimmetrica e sistemi di autenticazione dei dispositivi locali (ad esempio, password e dati biometrici) per spostare la fiducia da un gran numero di servizi a relativamente pochi endpoint controllati dall’utente.

UAF, in un certo senso, somiglia molto a un gestore di password, tuttavia, invece di memorizzare le password, memorizza chiavi private: il servizio di autenticazione riceve la chiave pubblica dell’utente, ed è quindi in grado di verificare e confermare che l’utente è in possesso della chiave privata.

Si ottengono numerosi vantaggi gestendo l’autenticazione attraverso un dispositivo locale intelligente:

1. gli attacchi di tipo reply possono essere mitigati attraverso sistemi di challenge-and-response;
2. i man-in-the-middle possono essere contrastati facendo sì che il servizio di autenticazione si rifiuti di firmare la challenge a meno che non provenga dallo stesso dominio che l’utente sta visitando;
3. non è necessario un riutilizzo delle credenziali poiché le credenziali per il servizio possono essere facilmente generate.

Quasi ogni sistema ha un piccolo insieme di azioni o di richieste che devono essere attentamente custodite: la quantità di rischio che si è disposti a tollerare in quest’area varia da un’applicazione all’altra, sebbene praticamente non esista un limite inferiore.

Uno dei rischi maggiori che si corrono avvicinandosi alla % di rischio zero è la quantità di fiducia riposta in ogni singolo essere umano.

Esattamente come nella vita reale, sono molti i casi in cui è auspicabile ottenere il consenso di più individui per autorizzare un’azione particolarmente delicata. Ci sono un paio di modi in cui questo può essere ottenuto nel mondo digitale, e la parte interessante è che possiamo garantirlo attraverso l’applicazione della crittografia.

Shamir’s Secret Sharing, ad esempio, è uno schema crittografico per distribuire un segreto tra un gruppo di individui. L’algoritmo suddivide il segreto originale in n parti, che potranno poi essere distribuite tra i depositari delle chiavi, ciascuno di loro con una chiave differente.

Un esempio:

A seconda di come viene configurato l’algoritmo al momento della generazione delle parti, saranno necessarie k parti per ricalcolare e risalire al valore originale del segreto (nell’esempio sopra, ho protetto il messaggio segreto con cinque chiavi, tuttavia, per risalire al messaggio ho disposto che occorrano solo tre di queste).

Fase di decifrazione in base ai requisiti precedenti:

Quando si proteggono grandi quantità di dati utilizzando lo schema di condivisione del segreto di Shamir, una chiave di crittografia simmetrica viene sezionata e distribuita invece di utilizzare l’algoritmo direttamente sui dati, e questo poiché la dimensione del segreto che viene suddiviso deve essere inferiore a quella di alcuni dati utilizzati nell’algoritmo di condivisione.

Una versione per Unix/Linux di questo algoritmo è utilizzato nel software ssss, ma esistono librerie simili anche per altri sistemi operativi.

Il progetto Ottobre Rosso di CloudFlare costituisce un altro approccio all’implementazione dell’autenticazione di gruppo per accedere a dati condivisi.

Questo servizio Web utilizza la crittografia asimmetrica a livelli per cifrare i dati in modo tale che un certo numero di utenti debba riunirsi per poterli decifrare. I dati cifrati non vengono effettivamente archiviati sul server, vengono invece archiviate solo le coppie di chiavi pubblica/privata dell’utente (cifrate con una password scelta dall’utente).

Quando i dati verranno inviati per essere cifrati, verrà generata una chiave di crittografia casuale per cifrarli: questa chiave verrà quindi cifrata a sua volta utilizzando combinazioni univoche di chiavi di crittografia specifiche dell’utente, in base a una policy di sblocco richiesta dall’utente.

Nel caso più semplice, un utente potrebbe cifrare alcuni dati in modo tale che due persone (in un gruppo più ampio) debbano collaborare per decifrare i dati. In questo scenario, la chiave di crittografia dei dati (originali) cifrati viene quindi cifrata due volte con ciascuna coppia univoca di chiavi di crittografia dell’utente.

La cerimonia di firma di una Root Zone DNS è un esempio interessante di procedura di autenticazione di gruppo. Questa cerimonia viene istituita per generare le chiavi root, chiavi su cui si basa tutta la sicurezza nell’infrastruttura DNSSEC.

Se la chiave root venisse compromessa, l’affidabilità dell’intero sistema DNSSEC verrebbe meno, ergo, il protocollo per la generazione della chiave root è stato creato appositamente per mitigare tale rischio.

La prima cerimonia si è svolta il 16 giugno 2010, e ogni trimestre si svolge una nuova cerimonia che si avvale di sette funzionari, ciascuno con un ruolo diverso. Durante la cerimonia, per proteggere la chiave digitale vengono utilizzati HSM, scanner biometrici e sistemi air-gapped.

Al termine viene generata e firmata una nuova coppia di chiavi pubblica/privata, che continuerà la catena di fiducia di Internet per un altro trimestre.

Per avere maggiori informazioni sulle cerimonie svolte fino ad oggi, è possibile consultare il sito CloudFlare o leggere direttamente i dettagli di ogni cerimonia messi a disposizione sul portale IANA.

Riflessioni conclusive

Gli utenti di una rete Zero Trust, come i dispositivi, dovrebbero diventare elementi attivi della cyber security del sistema.

Le organizzazioni tendenzialmente formano team interni dedicati alla sicurezza informatica dei sistemi, tuttavia, tali team nella maggior parte dei casi interpretano erroneamente tale mandato, nel senso che le modifiche alle policy vengono spesso controllate solo da loro per garantire che la sicurezza complessiva del sistema non sia compromessa.

Questo approccio produce un antagonismo tra i team di cyber security e il resto dell’organizzazione e, di conseguenza, riduce la sicurezza informatica.

Un approccio più costruttivo può essere quello di promuovere una Cultura di collaborazione verso i team di cyber security: gli utenti dovrebbero essere incoraggiati a parlare apertamente della loro vita informatica e di quello che reputano strano o pericoloso, anche se apparentemente a loro sembra di lieve entità.

Questa condivisione delle conoscenze fornirà un contesto migliorativo relativamente alle minacce informatiche e controffensive a cui il team di cyber security lavora per difendere l’organizzazione.

Segnalare e-mail di phishing anche quando gli utenti non hanno interagito con esse, può mettere a conoscenza il SOC se un determinato aggressore sta tentando di infiltrarsi nella rete.

I dispositivi smarriti o rubati dovrebbero essere segnalati immediatamente.

I team di cyber security potrebbero prendere in considerazione la possibilità di fornire agli utenti modalità tempestive per avvisarli H24 nell’ipotesi in cui un dispositivo aziendale dovesse essere rubato o venisse smarrito.

Quando rispondono ai suggerimenti o agli avvisi degli utenti, i team di cyber security dovrebbero essere maggiormente consapevoli di come la loro risposta ad un incidente informatico inciderà sull’organizzazione: un utente che si vergogna di aver perso un dispositivo, ad esempio, sarà meno disposto a denunciarne lo smarrimento in modo tempestivo.

Allo stesso modo, un falso allarme a tarda notte, lato SOC dovrebbe essere affrontato comunque con entusiasmo e gestito, poiché tra dieci falsi allarmi, potrebbe invece essercene uno autentico e andato a segno.

Per quanto possibile bisognerebbe incentivare l’organizzazione verso una libera segnalazione da parte degli utenti, non creare un clima di omertà, facendo finta che tutto va bene, che non ci sono problemi.

A tal proposito, lo “storico-attività” degli utenti è una ricca fonte informativa per determinare l’affidabilità delle azioni in corso.

È possibile costruire un sistema che estragga l’attività dell’utente al fine di delinearne un modello comportamentale: questo sistema confronterà il comportamento attuale dell’utente con il modello, al fine di calcolare un punteggio di fiducia dell’utente in esame.

Gli esseri umani tendono ad avere modelli di accesso prevedibili: ad esempio, la maggior parte delle persone non tenta di autenticarsi più volte al secondo.

Inoltre, è improbabile che tentino di autenticarsi centinaia di volte.

Questi tipi di modelli di accesso sono estremamente sospetti e vengono spesso mitigati tramite strumenti attivi come i CAPTCHA (sfide automatizzate a cui solo un essere umano è in grado di rispondere) o con il blocco dell’account.

La riduzione dei falsi positivi richiede l’impostazione di parametri abbastanza elevati per essere efficaci: includere questa attività in un punteggio complessivo di valutazione delle minacce può aiutare a individuare comportamenti sospetti, ma non ovviamente dannosi.

L’esame dei modelli di accesso non dovrebbe essere limitato necessariamente ai tentativi di autenticazione. Anche i modelli di utilizzo delle applicazioni da parte degli utenti possono rivelare intenti dannosi.

La maggior parte degli utenti tende ad avere ruoli piuttosto limitati in un’organizzazione, e pertanto potrebbe aver necessità solo di accedere a un sottoinsieme di dati a loro disposizione.

Nel tentativo di aumentare la sicurezza informatica le organizzazioni rimuovono i diritti di accesso degli account di dipendenti e collaboratori, a meno che non ne abbiano assolutamente necessità per svolgere il proprio lavoro.

Tuttavia, questo tipo di controllo restrittivo degli accessi può influire sulla capacità dell’organizzazione di rispondere rapidamente a eventi univoci.

Gli amministratori di sistema sono una classe di utenti a cui vengono concessi ampi privilegi, indebolendo così questo approccio come meccanismo di difesa. Invece di scegliere tra questi due estremi, è possibile valutare l’attività dell’utente in modo aggregato utilizzando il suo punteggio per determinare se è ancora affidabile per accedere a una risorsa particolarmente sensibile.

Elenchi pubblici di traffici di rete dannosi, come quelli forniti da Spamhaus, possono essere un altro segnale utile per valutare l’affidabilità di un utente: il traffico che ha origine da questi indirizzi e tenta di utilizzare l’identità di un particolare utente potrebbe sfruttare l’account di un dipendente potenzialmente compromesso (e ignaro di esserlo).

La geolocalizzazione può essere un altro segnale utile per determinare la fiducia di un utente.

Possiamo confrontare la posizione attuale dell’utente con le posizioni visitate in precedenza per determinare se è fuori dall’ordinario.

Il dispositivo dell’utente è stato geolocalizzato in una nuova posizione in un intervallo di tempo in cui non poteva ragionevolmente viaggiare? Se l’utente dispone di più dispositivi, sono emerse posizioni in conflitto? (esempio: il suo smartphone aziendale in Italia, il suo notebook in Estonia).

La geolocalizzazione può essere sbagliata o fuorviante, quindi i sistemi non dovrebbero dargli un peso eccessivo.

A volte gli utenti dimenticano i dispositivi a casa, oppure i database di geolocalizzazione non sono aggiornati. Ciononostante, la geolocalizzazione costituisce un altro degli strumenti a disposizioni di sysadmin e in generale degli operatori attivi nel mondo della cyber security.