ABC della sicurezza: Least Privilege

«Da un grande potere derivano grandi responsabilità» («With great power  there must also come great responsibility!») – Amazing Fantasy #15, 1962
La prima apparizione dell’Uomo Ragno

In una pubblicazione accademica del 1975 “The Protection of Information in Computer Systems” Jerome Saltzer definiva così quello che in inglese viene chiamato “Principle of Least Privilege” (POLP):

“Ogni programma ed ogni utente del sistema dovrebbero operare utilizzando il minimo insieme di privilegi necessari a portare a termine il proprio compito. In primo luogo, questo principio limita il danno che può derivare da un incidente o da un errore. Inoltre esso riduce il numero di potenziali interazioni fra programmi privilegiati al minimo indispensabile per la corretta operatività, affinché il non intenzionale, involontario o improprio uso del privilegio abbia la minima probabilità di accadere. In tal modo, se sorge una questione relativa all’uso sbagliato di un privilegio, il numero di programmi che devono essere sottoposti ad audit è ridotto al minimo. Posto in altri termini, se un meccanismo può mettere a disposizione dei “firewall”, il POLP fornisce le motivazioni su dove installare i firewall. La regola di sicurezza militare del “need-to-know” è un esempio di questo principio.”

Pur risalendo al 1975, la definizione rimane intatta nella sua efficacia e nella sua validità.

La pratica

Nella pratica il principio, applicato alle persone, si traduce nel fornire agli utenti il più basso livello di “diritti” che possono detenere rimanendo comunque in grado di compiere il proprio lavoro. Il principio si applica poi ad altri livelli di astrazione, oltre che alle persone, e dunque ai programmi e ai processi. Lo scopo (del principio come della sua applicazione) è quello di limitare il danno potenziale indotto da un incidente di sicurezza sia esso doloso o accidentale. Nell’utilizzo di un PC, il livello di sicurezza può essere aumentato operando con un utente senza i diritti di “amministratore”. Operare in modalità “amministrativa” può rendere il sistema vulnerabile all’esecuzione di codice malevolo, dal quale potrebbe risultare immune ricorrendo a un utente con minori privilegi. Un concetto strettamente legato al POLP, ma che prende in causa la dimensione tempo, è il “privilege bracketing” che consiste nel concedere un innalzamento dei privilegi concessi all’utente solo e soltanto per un intervallo di tempo necessario a portare a termine uno specifico compito che altrimenti non potrebbe essere eseguito (si pensi all’installazione di un programma su PC per la quale ci viene richiesta dal computer un’esplicita autorizzazione tramite l’inserimento di una password relativa ad un “superuser” abilitato all’installazione).

L’esempio più classico che viene fornito nell’ambito delle utenze di sistema operativo è quello dell’utente destinato a compiere i backup: tale utente ha il solo diritto di eseguire i backup; ogni altro privilegio, come quello di installare programmi, gli è negato.

Oltre ai tentativi fraudolenti di mettere in pericolo il sistema, anche gli errori di programmazione possono infliggere maggiori danni quando le applicazioni operano con privilegi più elevati del necessario.

L’adozione del principio porta quindi una serie di vantaggi di cui i più importanti sono in definitiva ascrivibili all’ambito della sicurezza: quando il codice in esecuzione in un determinato momento nel sistema è limitato nei suoi poteri, le vulnerabilità in un’applicazione non possono essere sfruttate per attaccare il resto della macchina. Vale la pena ricordare che il principio è una teoria. La pratica, dovendo essere applicata agli ambiti più diversi, non ha semplice attuazione a causa della grande complessità dei contesti che vanno governati. La pratica e la realtà dunque, come sempre, rappresentano un’approssimazione di ciò che imporrebbe il principio. Molto spesso, ad esempio, per definire i diritti di un utente si procede per esclusione, ma questo può portare ad avere un utente che detiene un soprainsieme dei diritti ad esso necessari. La granularità nella concessione dei diritti, siano essi riferiti a persone, programmi o processi, non è sempre “atomica” per cui il POLP rimane un modello, un’astrazione a cui la realtà dovrebbe auspicabilmente tendere.

Il pericolo tradotto in cifre

Ci si potrà domandare in effetti se ciò di cui ho parlato sinora sia solo tanta bella teoria, è bene dunque tornare con i piedi ben piantati per terra e fare presente che, secondo il “IBM 2015 Cyber Security Intelligence Index”, il 55% degli attaccanti è costituito da “insider” e, di questi, circa la metà sono attori involontari dell’attacco.

Altre statistiche, rilevabili dal sito “The Privacy Rights Clearinghouse” con una semplice interrogazione, indicano che fra il 2005 e il 2016, i “data breach” imputabili a “diffusione involontaria” riguardano 32 milioni di record, mentre quelli imputabili a “insider” a cui legittimamente era stato concesso l’accesso alle informazioni riguardano 36 milioni di record. Questi numeri da soli dovrebbero essere sufficienti a far comprendere come un’assennata applicazione del principio del minimo privilegio sia fondamentale se si vuole perseguire il più ampio concetto della “difesa in profondità”.

Esiste una lunga serie di motivi che potrebbero spingere un dipendente o un insider in genere a trafugare indebitamente dei dati: lo spionaggio industriale, il guadagno economico, il desiderio di rivalsa di un ex dipendente deluso. Questo tipo di individui (e di attacchi) sono difficili da fronteggiare, in ragione del fatto che essi si trovano a possedere già l’accesso ai dati.  Le informazioni cosiddette sensibili hanno un grande valore economico sul “black market” e più vittime corrispondono a più denaro, guadagnato dai malintenzionati e perduto dalle aziende.

Due necessità contrapposte

Il principio tuttavia si scontra con un’altra forza molto potente: la necessità degli utenti di accedere a dati e informazioni. Gli utenti esigono il massimo accesso possibile affinché il loro lavoro sia facilitato, mentre il reparto IT tende a rimanere “scettico” sulla necessità di tali accessi illimitati e si preoccupa di eventuali “buchi” di sicurezza. È tuttavia indispensabile comprendere come il POLP non sia (solo) una limitazione per l’utente finale, ma debba essere percepito come un vantaggio, una tutela dell’utente stesso (“da un grande potere derivano grandi responsabilità”).

Gli individui non dovrebbero sentire l’assegnazione di un limitato insieme di diritti come una “questione di fiducia” nei loro confronti o un’offesa personale. Questa percezione negativa è maggiormente diffusa quando avviene un “declassamento” dei diritti. Le limitazioni in genere dovrebbero invece essere viste come una tutela dell’individuo e dell’ecosistema in generale dal punto di vista della sicurezza. L’utente “depotenziato”, inoltre, si ritrova a non essere perseguibile per azioni (malevole o involontarie) in quanto impossibilitato a compierle.

Il principio del minimo privilegio si dovrà inoltre applicare, parlando di persone, anche alle “terze parti” che inevitabilmente dovranno accedere ai nostri dati dall’esterno o dall’interno dell’organizzazione. Un buon accordo di non divulgazione sarà opportuno, tuttavia una stretta aderenza al POLP rappresenta il miglior aiuto possibile nel contrasto alla fuoriuscita indesiderata di dati. Da non dimenticare la disattivazione delle utenze quando queste non risultano più necessarie.

Sempre nell’ambito delle “terze parti” che usufruiscono dell’infrastruttura aziendale, è istruttivo l’esempio di consulenti, fornitori e affini che si trovano a dover navigare su Internet quando sono ospiti della nostra rete: essi dovrebbero essere relegati in un segmento di rete apposito e a essi andrebbero concessi i diritti minimi affinché possano accedere all’esterno e tutto questo per lo stretto tempo necessario.

Il principio del minimo privilegio va poi applicato alle macchine (server in primo luogo) non perché esse in quanto macchine abbiano intenzioni malevole, bensì in ragione del fatto che, se dovessero cadere in mano a malintenzionati perché vittime di virus o simili, il danno rimarrebbe contenuto e i cosiddetti “movimenti laterali” sarebbero ostacolati. Lo stesso dicasi in caso di errori umani e non: l’effetto di tali errori verrebbe bloccato o comunque circoscritto ad un’area più ristretta, rendendo di fatto più economiche le operazioni di rimedio.

È bene tenere presente anche le implicazioni legali, personali e aziendali, derivanti da comportamenti, azioni ed eventi legati ad un utilizzo improprio dei diritti concessi. Tutte queste considerazioni dovrebbero contribuire a far percepire il POLP non come uno strumento di coercizione, ma come un alleato al servizio di tutti.

In altri ambiti, il principio del minimo privilegio si scontra con la flessibilità, la fruibilità e la “user experience”; basti pensare ai diritti che dobbiamo (?) concedere alle app sugli smartphone. Se concediamo troppi diritti, rinunciamo alla nostra privacy e ci dobbiamo fidare della correttezza del fornitore e dell’infallibilità del codice, ma se non concediamo alcun diritto dovremo rinunciare a quella feature tanto “cool” che ci facilita nella vita di ogni giorno. Qual è il giusto equilibrio?

Il ruolo dell’Audit

A molti dei lettori che si occupano di ICT sarà capitato di imbattersi nel principio del minimo privilegio nell’ambito degli IT Audit. Tuttavia, relegare l’adesione al principio al mero soddisfacimento delle esigenze  di audit sarebbe falsarne completamente le motivazioni. Il principio del minimo privilegio imposto giustamente dall’Audit deve essere visto e vissuto non come un semplice adempimento regolatorio, bensì come un fiero alleato da applicare a tutte le aree della sicurezza, a partire da quella fisica, per passare a quella di rete, a quella logica e amministrativa.

Il controllo degli accessi fisici dovrà essere fatto “cum grano salis”, per quanto concerne la parte “network” il default dovrà essere un “deny any”, per la parte degli accessi logici i diritti dovranno essere legati alla funzione che viene svolta dall’utente e l’accesso a dati a differente classificazione dovrà seguire logiche di profilatura. Dal punto di vista amministrativo risulta importante quella che viene definita “segregation of duties” che limita le possibilità di ciascun utente all’ambito delle proprie mansioni. L’insieme di queste attività di regolazione degli accessi dovrà poi essere sottoposto a revisioni periodiche per verificare l’aderenza della situazione attuale agli effettivi (solo a quelli) bisogni del momento.

Cosa possono fare le aziende?

Come spesso accade in ambito sicurezza, ogni discussione ricade nella valutazione e gestione del rischio, visto che la distribuzione dei privilegi comporta l’accettazione di un certo livello di rischio. Come possono le aziende gestire questo rischio? In modo più specifico quando si tratta di concedere diritti di accesso al personale?
I suggerimenti tratti da “10 Steps to Cyber Security: Advice Sheets” forniti dal governo britannico mi sembrano un ottimo spunto:

• Effettuare uno “screening” preventivo del personale che si sta assumendo (se si deve concedere l’accesso a dati sensibili o molto importanti, dobbiamo riporre il massimo della fiducia nella persona a cui concediamo tale accesso)
• Stabilire efficaci processi di “gestione delle utenze”,  dalla creazione, alla modifica, alla cessazione o sospensione temporanea delle utenze inutilizzate, con momenti di revisione periodici
• Stabilire policy e standard per l’identificazione e il controllo degli accessi. Non vanno trascurate le policy che governano la complessità delle password (qualora non sia possibile generarle in maniera casuale) e l’utilizzo di token fisici
• Limitare i privilegi degli utenti (il concetto più volte richiamato nel presente contributo)
• Limitare il numero e l’utilizzo di account privilegiati
• Monitorare continuamente l’attività di ciascun utente (particolarmente degli account privilegiati)
• Limitare l’accesso ai sistemi di audit e ai log
• Educare gli utenti e contribuire alla loro consapevolezza.