Nel mondo della cybersecurity, il ruolo di capro espiatorio è stato da tempo assegnato agli utenti, indicati come la causa principale delle violazioni della sicurezza informatica.
Secondo qualcuno, eliminando l’errore umano si eliminerebbe più del 90% delle violazioni informatiche.
Cyber security, come neutralizzare il “fattore umano”: le strategie possibili
Violazioni di sicurezza informatica, non è sempre l’utente il colpevole
In generale con errore umano si indicano o azioni non intenzionali o mancanza di azione che agevolano, permettono o diffondono una violazione della politica di sicurezza. Le possibili azioni vanno dal download di un allegato infetto da malware all’utilizzo di una password troppo semplice. Abbiamo letto tutti che gli utenti sono pronti a vendere la loro password per un pacchetto di caramelle o che scrivono le password su un post-it appiccicato allo schermo o al cassetto della scrivania (i più sofisticati). L’idea è popolare da tanti anni se nel 1999, Anne Adams e Martina Sasse, due computer scientist dell’University College London pubblicarono un citatissimo articolo dal titolo “Users are not the Enemy” per contrastare questo punto di vista. L’ingegneria sociale cerca di spingere gli utenti a questi comportamenti pericolosi in modo da consegnare dati o credenziali nelle mani degli attaccanti limitando la complessità del malware o di un exploit.
Ora se è vero che spesso le azioni degli utenti semplificano la vita degli attaccanti è anche vero che spesso questo è sostanzialmente dovuto ad errori nella progettazione dei sistemi di cui gli utenti non sono in alcun modo responsabili. Questo è un problema particolarmente grave perché spesso si scopre che gli attaccanti erano presenti nel sistema target da parecchi mesi e che l’attribuzione della responsabilità agli utenti garantisce loro un ulteriore periodo di persistenza nel sistema stesso.
La radice del problema e le possibili soluzioni
Consideriamo ad esempio il problema delle password: il modo più semplice di rimediare a perdita o furto di password è quello di utilizzare una autenticazione a più fattori. Basta una app sul cellulare per eliminare la quasi totalità degli attacchi. Una autenticazione a più fattori o un controllo che rifiuti password troppo banali o presenti in dizionari sono ormai prassi consolidate per sistemi di home banking ma, stranamente, spesso non lo sono per proteggere l’accesso ad infrastrutture critiche o a dati particolari o sensibili come quelli biomedici. Se un dipendente di Solarwinds usa la password “Solarwinds123” non dovremmo ridere ma chiederci come mai una società che sviluppa software per la sicurezza non controlla le password dei suoi dipendenti.
L’errata gestione dei diritti
Ma la vera sorgente di tutti i problemi che si attribuiscono agli utenti è l’errata gestione dei diritti assegnati ai vari utenti. Se, ad esempio, un utente è l’amministratore della sua macchina e se esistono relazioni di trust tra le varie macchine è estremamente probabile che ogni errore dell’utente si ripercuota prima sulla sua macchina e poi su tutte le altre di una rete. Anche qui, l’errata progettazione di un sistema, in particolare l’attribuzione errata dei diritti ad ogni utente amplifica in modo drammatico l’impatto dell’errore del singolo utente. Il principio che il progettista non ha applicato è noto da decenni ed è di solito noto come il principio del privilegio minimo. Come ci ricorda Wikipedia, questo principio è stato enunciato quasi in contemporanea in due lavori, uno di P.Denning e l’altro di J. H. Saltzer e M. D. Schroeder alla metà degli anni 70 ed afferma che in un qualunque sistema di calcolo ogni modulo computazionale, ad esempio un thread, un processo, o un utente a seconda del livello di astrazione, deve avere accesso alle sole risorse ed informazioni immediatamente necessarie al suo funzionamento.
Il principio del privilegio minimo
Il principio del privilegio minimo è alla base di molte soluzioni che, se correttamente adottate, allontanano il ruolo di capro espiatorio dall’utente. Un possibile esempio sono le soluzioni di tipo role based access control che determinano i diritti di ogni utente in base al ruolo ed a compiti che essa ha in una organizzazione. Ad esempio, si possono avere ruoli diversi di amministratore di un sistema, con privilegi diversi, e lo stesso utente assume i vari ruoli in base alle funzioni che deve svolgere. Queste soluzioni, nelle loro versioni più evolute, limitano anche il tempo in cui un certo utente può assumere un certo ruolo per ridurre anche temporalmente l’uso di privilegi. E’ ovvio che la gestione di queste soluzioni possa diventare complessa se il numero di ruoli esplode ma è altrettanto evidente che la sicurezza e la robustezza complessiva aumentano in modo significativo anche prevedendo pochi ruoli.
Di recente, il principio del privilegio minimo è risorto mimetizzato sotto il nome di zero trust che afferma che non occorre assegnare privilegi/diritti non necessari e verificare le identità prima di trasformarle in diritti. È chiaro che privilegio minimo e zero trust non sono perfettamente sovrapponibili perché, ad esempio, le soluzioni zero trust cercano anche di valutare il rischio prima di decidere se concedere un certo accesso ma l’idea alla base di entrambi è di minimizzare i diritti concessi. Un modulo che ha pochi diritti è intrinsecamente meno pericoloso e più controllabile di un amministratore di sistema che può tutto su tutti. Come ultima conferma, ricordo la top ten delle vulnerabilità più critiche per sistemi serverless o se preferite sistemi FaaS, function as a service. Una delle dieci vulnerabilità è quella di funzioni overprivileged ovvero con troppi privilegi rispetto ai compiti assegnati. Anche quando i server spariscono, i troppi privilegi restano.
L’attestazione
Un’altra soluzione tecnologica che può aiutare a confinare i comportamenti di un utente è quella dell’attestazione. Questa tecnologia esamina il codice eseguito da una certa applicazione prima di attivarla per verificare che non sia stata modificata da un attaccante. Ad esempio, è possibile usare l’attestazione per verificare che il modulo client che si collega ad un certo server o il peer che cerca di entrare in una applicazione P2P, come un gioco multiplayer, siano quelli legali e non alterati. Solo di recente alcuni provider hanno iniziato ad applicare soluzioni basate su attestazione per verificare i moduli che accedono ai servizi che una architettura cloud può offrire.
Le blacklist
Un’altra accusa frequente agli utenti è quella di visitare siti pericolosi o che ospitano malware. Anche in questo caso esiste una soluzione efficace quella delle whitelist, cioè dei siti permessi, leggermente più complessa ma strutturalmente più robusta delle soluzioni basate su blacklist, ovvero dei siti vietati. Per essere veramente robusta ogni soluzione basata su blacklist deve essere continuamente aggiornata ed ogni mancato aggiornamento abilita l’accesso di tutti gli utenti a siti pericolosi. Ovviamente chi deve aggiornare le blacklist non è sicuramente l’utente.
Politiche di patching non adeguate
Un utente che clicca su un link e scarica un malware ha le sue responsabilità ma qualche altra responsabilità è legata alla presenza delle vulnerabilità che il malware sfrutta per raggiungere i suoi obiettivi, ad esempio cifrare tutto il file system. Infatti, un contributo non banale ai successi degli attaccanti viene da politiche di patching non adeguate. È ormai evidente che politiche come patch all o basate su ranking inadeguati delle vulnerabilità, uno per tutti il tragico CVSS, provocano un ritardo sempre più crescente nel patching. Le imprese sono in grado di patchare, in media, solo il 20% delle vulnerabilità presenti nei loro sistemi ed utilizzare strategie di ranking o scheduling indipendenti dai sistemi provoca un aumento costante del tempo per il patching. Il paradosso è che da tempo sappiamo che è sufficiente patchare poche vulnerabilità critiche per aumentare in modo drammatico la sicurezza dei sistemi. Purtroppo, queste vulnerabilità dipendono dal sistema da difendere e non possono essere individuati da metodi che schedulano le patch nello stesso modo per qualsiasi sistema. Di conseguenza, il tempo per patchare le vulnerabilità più critiche era 197 giorni nell’aprile 2021 e 205 giorni nel maggio 2021. Come ulteriore conferma ricordiamo che nel novembre scorso la Cybersecurity & Infrastructure Security Agency, l’agenzia federale US che si occupa della sicurezza delle infrastrutture ha emesso una lista delle vulnerabilità che ogni altra agenzia federale deve patchare e alcune di queste vulnerabilità sono note da più di tre anni.
Una discussione più approfondita del problema dei link malevoli che gli utenti seguono ci porterebbe poi a parlare degli input malevoli. Sviluppare software in grado di rilevare e gestire input malevoli senza fallimenti, crash o perdita di sicurezza è possibile ed esistono ormai centinaia di funzioni predefinite nei vari linguaggi di programmazione per validare gli input senza intaccare le prestazioni. Richiedere l’uso di tali funzioni nel software che si acquisisce può essere una eccellente soluzione per confinare comportamenti non corretti o maliziosi degli utenti.
Non c’è sicurezza senza investimenti
È chiaro che applicare il principio del privilegio minimo, dello zero trust cosi come utilizzare strumenti di attestazione remota o una politica di patching rigorosa provoca un aumento dei costi ma ci sono due considerazioni altrettanto ovvie. La prima è che uno dei compiti di un progettista è bilanciare il costo della sicurezza e robustezza offerte e le prestazioni del sistema complessivo. Scaricare sulle spalle dell’utente le responsabilità di un compromesso non ottimale tra prestazioni e sicurezza è forse il modo più semplice di non analizzare globalmente il sistema e di individuare le root causes del successo degli attaccanti. La seconda considerazione è che non possiamo ottenere sicurezza se non investiamo, nel progetto di un sistema, nella sua realizzazione e nella sua manutenzione ed aggiornamento. Sperare in pasti gratis è sicuramente possibile ma illusorio e pericoloso.
Come già detto, un mondo che viene spesso citato ma a cui raramente ci si ispira è quello della sicurezza bancaria che ha da tempo imparato, e spesso creato, regole quali il privilegio minimo, l’autenticazione a più fattori, le autorizzazioni multiple, logging ed auditing. Le stesse regole che difendono i nostri risparmi ci permetterebbero di difendere i nostri dati e le nostre infrastrutture che sono altrettanto preziose ma questo banale principio appare molto difficile da accettare.
Conclusioni
Concludendo possiamo dire che ci sono molti problemi non banali e responsabilità diffuse alla base dei problemi di sicurezza informatica. Semplificare la discussione, l’analisi e la progettazione scaricando tutto sull’utente, ed invocare la formazione e l’educazione degli utenti come il magico elisir di Dulcamara è sicuramente un modo di evitare di scoprire le vere cause ed i veri responsabili.
