UNIVERSITA DEGLI STUDI ROMA 3
FACOLTA DI SCIENZE M.F.N.
CORSO DI LAUREA MAGISTRALE IN MATEMATICA
Tesi di Laurea Magistrale in
Matematica
Metriche di rischio nel controllo degli accessi:
sintesi
Lucia Miggiano
Anno Accademico 2013/2014
Relatore Correlatore
Prof. Roberto Di Pietro Prof. Alessandro Colantonio
1 Introduzione
L’Identity e Access Management e un aspetto chiave della strategia di si-
curezza per qualsiasi impresa ed e fondamentale per garantire alle persone
di accedere tempestivamente solo alle applicazioni aziendali necessarie per il
loro lavoro. In un’organizzazione di dimensioni medio-grandi, il Chief Infor-
mation Security Officer (CISO) sviluppa politiche di sicurezza che riflettono
la propensione al rischio delle imprese e l’approccio alla gestione delle identita
e degli accessi. Tali politiche sono fondamentali per capire come l’impresa
definisce chi puo accedere ai dati o eseguire una determinata operazione.
Queste politiche sono poi perfezionate in una serie di controlli tecnici e pro-
cedurali che aiutano a raggiungere la posizione di rischio appropriata. Nel
campo delle identita, tali controlli comprendono la gestione degli elenchi dei
dipendenti (es.: active directory e single-sign-on (SSO)), gestione del ciclo di
vita dell’account utente, gestione del controllo dell’accesso alle informazio-
ni e ai sistemi, meccanismi di autenticazione, strumenti di conformita e di
reporting.
Durante la vita di un’impresa, il CISO e gli esponenti aziendali devono
sapere quanto bene stanno incontrando le posizioni di rischio che hanno de-
finito, monitorando le metriche di rischio chiave. In questo lavoro di tesi
ci occuperemo di analizzare approcci innovativi all’identity analytics, cioe
gli strumenti che aiutano il CISO e altri decisori di sicurezza a esplorare
rigorosamente le conseguenze delle scelte delle loro politiche di sicurezza e
piu precisamente spiegano ai dirigenti perche dovrebbero investire in una
soluzione di accesso o identita consigliati. Inoltre, esplorando le relazioni
tra controlli tecnici e procedurali, l’Identity Analytics fornisce una migliore
comprensione di quali parametri devono essere monitorati e i modi in cui essi
indicano il rischio.
Ci proponiamo di comprendere quali sono le principali domande che i
decisori aziendali si pongono quando si tratta di analizzare i rischi legati al
controllo degli accessi. Affineremo poi queste domande in modelli in grado di
esplorare diversi scenari aiutando in tal modo i decisori a valutare le impli-
2
cazioni e le conseguenze di decisioni diverse. Infine analizzeremo il rapporto
tra gestione del rischio e performance aziendale.
3
2 Definizione, proprieta e applicazioni delle
metriche di sicurezza
In questo capitolo definiamo cos’e una metrica di sicurezza, quali sono le sue
proprieta e alcune sue applicazioni.
Il termine metriche di sicurezza e comunemente usato per denotare una
misura che quantifica alcuni aspetti della sicurezza di un sistema IT.
Prima di definire cosa sono le metriche di sicurezza, e importante chiedersi
per cosa sono utilizzate, cioe per quale obiettivo servono. La risposta a questa
domanda si puo ricavare dalla famosa frase “non si puo gestire cio che non
si puo misurare”: le metriche, in generale, sono strumenti per la gestione e le
metriche di sicurezza, in particolare, sono un mezzo per sostenere e migliorare
la gestione della sicurezza delle informazioni.
Definiamo la sicurezza attraverso la sua manifestazione piu concreta, cioe
l’esistenza di perdite quando la sicurezza e assente. Piu formalmente, per un
dato sistema IT S, si calcola la perdita attesa EL (expected loss) da incidenti
di sicurezza.
In una prima approssimazione, EL =∑
loss P (loss)× size(loss). Questa
equazione si puo raffinare e si dimostra l’equazione:
EL = value× E(tm)× vulnerability(S) (1)
In questa equazione, value e il valore monetario (in dollari o euro) del sistema
IT S, il fattore E(Tm) e la malizia attesa dell’ambiente della minaccia in cui
S esiste e l’ultimo fattore e una misura di quanto sia vulnerabile il sistema
IT S. In particolare, il sistema S e tanto piu vulnerabile quanto piu le sue
vulnerabilita sono frequenti, gravi e facilmente sfruttabili. Supponiamo che,
senza modificare il valore del sistema IT S, facciamo alcune modifiche alla
sua architettura che si traduce in una minore perdita attesa EL. Questo si-
gnifica, ovviamente, che abbiamo migliorato la sicurezza. Tuttavia, questo
miglioramento di sicurezza avviene senza modificare il valore del sistema Se senza modificare la malizia attesa E(Tm). Pertanto, la riduzione di EL
4
deve essere il risultato del calo del fattore di vulnerabilita di S. Dunque, la
sicurezza di un sistema e inversamente proporzionale alla sua vulnerabilita.
Questo da luogo alla seguente definizione (ancora informale):
Definizione 1 (informale di metrica di sicurezza): una metrica di
sicurezza e una funzione che misura la vulnerabilita di un sistema e la mappa
a un numero reale non negativo che e inversamente proporzionale alla vulne-
rabilita del sistema. Lo scopo di una metrica di sicurezza e quello di aiutare
la gestione a prendere decisioni migliori di sicurezza informatica.
Per danneggiare il sistema S, una minaccia deve indirizzare una vulne-
rabilita che puo sfruttare con il suo livello di abilita. Lo sfruttamento con
successo da alle minacce certi privilegi sul sistema S, che utilizzano poi per in-
fliggere danni su S. L’entita del danno inflitto dipende da quanto la minaccia
e maliziosa. Per formalizzare questi concetti, definiamo:
• Valore del sistema: la variabile value indica il caso peggiore della
perdita monetaria che i proprietari del sistema S possono incorrere se
S e compromesso. Questo valore di perdita include i costi diretti di
riparazione, spese legali, spese di reputazione, e tutti gli altri costi
potenziali. Si misura in dollari, euro o qualche altra valuta.
• Malizia Tm ∈ [0, 1] di una minaccia T ∈ T: alcune minacce sfruttano
le vulnerabilita solo per il brivido della vittoria, mentre altre lo fanno
al fine di infliggere danni sul sistema di destinazione S. Le minacce
pertanto differiscono rispetto alla loro malizia, che si misura su una
scala da 0 a 1. L’interpretazione e dovuta al fatto che una minaccia
di malizia x causerebbe x per cento della perdita massima che puo
teoricamente infliggere.
• Livello di abilita Ts ∈ [0, 1] di una minaccia T ∈ T: ogni minaccia T
ha un livello di abilita diverso che riflette la sua conoscenza, esperienza,
accesso a strumenti di hacking e altri fattori. Per definire il livello di
5
abilita di una minaccia, prima notiamo che entrambi gli insiemi V e Tsono insiemi finiti perche i sistemi IT hanno un numero finito di stati
e actors.
Sia s(T ) := |{V ∈ V : T puo sfruttare V all’interno dell’unita di tempo ξ}|/|V|la frazione delle vulnerabilita in V che T puo sfruttare entro l’unita di
tempo ξ. L’intuizione e che piu una minaccia T e abile piu e grande
s(t) e viceversa. Ora definiamo il livello di abilita Ts = |{t ∈ T : s(t) <
s(T )}|/|T|. Notiamo che Ts mantiene lo stesso ordine di minacce defini-
to da s() ma ha l’ulteriore proprieta che 1−Ts equivale alla probabilita
che una minaccia abbia livello di abilita Ts o piu.
• Livello di privilegio Vp ∈ [0, 1] raggiunto sfruttando la vulnerabilita
V ∈ V: le vulnerabilita sono differenti per il livello di privilegio che un
utente malintenzionato puo ottenere dal loro sfruttamento. Ad esem-
pio, alcune vulnerabilita danno privilegi agli attacanti root sul sistema
di destinazione, mentre altre permettono all’attaccante solo di legge-
re alcuni dati o rallentare un po la funzione del sistema. Definiamo
il livello di privilegio Vp come la frazione del valore del sistema che e
esposta quando la vulnerabilita V viene sfruttata con successo. Il li-
vello di privilegio di una vulnerabilita e anche conosciuto come la sua
gravita.
• Difficolta Vd ∈ [0, 1] di sfruttare la vulnerabilita V ∈ V : le vulne-
rabilita differiscono anche in quanto sono facili o difficili da sfruttare.
Alcune vulnerabilita, ad esempio race conditions, richiedono notevole
abilita per essere sfruttate, mentre altre, come ad esempio le password
di default, sono molto piu facili da sfruttare. Formalmente, definiamo
la difficolta Vd di sfruttamento come il livello di abilita della minac-
cia meno qualificata in grado di sfruttare la vulnerabilita V, cioe Vd =
min{Ts|T ∈ T e T puo sfruttare V all’interno dell’unita di tempo ξ}.
Non tutte le misure di vulnerabilita di un sistema sono metriche di sicu-
rezza. Piuttosto, la teoria della misurazione definisce tre proprieta operative
6
che ogni metrica deve soddisfare. Queste proprieta sono:
• Validita: la validita indica fino a che punto una metrica riflette ade-
guatamente il significato del concetto che cerca di misurare. In altre
parole, le metriche valide sono altamente correlate ai concetti che cer-
cano di misurare. E generalmente difficile definire metriche valide per
dei concetti immateriali come “sicurezza, “affidabilita, o “intelligenza
perche i concetti di base sono difficili da afferrare.
• Accuratezza: le metriche spesso misurano cose che non sono facil-
mente osservabili. L’accuratezza di una metrica e la differenza tra il
valore determinato dalla metrica e il “vero o “reale valore dell’oggetto
misurato. Gli errori di misurazione sono la principale fonte di impre-
cisioni. Ad esempio, una metrica che usa uno scanner di vulnerabilita
per misurare il numero di vulnerabilita in un sistema IT e accurato se i
suoi valori restituiti corrispondono o sono vicini al numero effettivo di
vulnerabilita.
• Precisione: la precisione valuta la riproducibilita delle misurazioni.
Piu precisamente, essa rappresenta la quantita di variabilita tra misu-
razioni ripetute dello stesso oggetto in condizioni simili. Ad esempio,
il “numero di allarmi virus e una metrica imprecisa di sicurezza del
sistema perche le misurazioni consecutive possono variare significativa-
mente a seconda dell’ambiente della minaccia. In particolare, quando
ci sono piu o meno attacchi virus, il “numero di allarmi virus sara piu
alto o piu basso, anche se non e cambiato nulla nel sistema o nella sua
sicurezza.
Da queste proprieta segue la definizione formale di metrica di sicurezza:
Definizione 2 (formale di metrica di sicurezza) Una metrica di
sicurezza e una funzione m() dall’insieme di tutti i sistemi IT all’insieme dei
numeri reali non negativi. E inoltre valida, accurata e precisa nel seguente
senso:
7
• Validita: per ogni due sistemi IT S1 e S2, la relazionem(S1) ≤ m(S2)⇔vulnerability(S1) ≥ vulnerability(S2) e la funzione definita nella (10).
In altre parole, la validita richiede che i sistemi piu vulnerabili segnino
valori piu bassi sulle metriche di sicurezza.
• Accuratezza: Se S (m) e la specifica della metrica di sicurezza m(),
allora m() e accurata se la differenza tra i suoi valori di ritorno ed i
veri valori secondo S (m) e piccola in media. Le imprecisioni sorgono
quando le metriche utilizzano procedure approssimate, sia perche i va-
lori esatti non possono essere calcolati sia perche sono troppo costosi
da calcolare
• Precisione: Per ogni sistema IT S, misurazioni ripetute sotto le con-
dizioni e i vincoli previsti dalla metrica m(), restituiscono sempre lo
stesso valore m(S). (Una forma piu debole di questo requisito e che la
varianza di misure ripetute deve essere piccola.)
La teoria sviluppata in questo capitolo puo essere utilizzata per risolvere
i seguenti problemi di gestione:
1. Come ridurre al minimo le perdite relative alla sicurezza;
2. Come dividere il proprio budget per la sicurezza tra piu sistemi IT che
necessitano di protezione;
3. Quanto spendere per la sicurezza.
8
3 Sistemi di Identity and Access Management
(IAM)
Nel capitolo 2 abbiamo visto la definizione, le proprieta e alcune applicazioni
delle metriche di sicurezza. In questo capitolo vediamo un caso specifico di
metriche di sicurezza nel controllo degli accessi.
In informatica, la gestione delle identita descrive la gestione delle singole
identita digitali, la loro autenticazione, autorizzazione e i privilegi all’interno
o all’esterno del sistema e delle imprese.
In questo capitolo presentiamo il caso di studio nel settore della gestione
delle identita e degli accessi come esempio significativo per illustrare co-
me l’approccio basato sulla modellazione e simulazione puo essere usato per
fornire un’ idea precisa di come i processi di sicurezza esistenti stanno pro-
teggendo l’organizzazione e per rispondere alle domande “what-if”, come ad
esempio esplorare gli effetti di un cambiamento nella politica di sicurezza o
un investimento in una nuova tecnologia per la sicurezza.
Le soluzioni di Identity and Access Management (IAM) per le imprese
hanno impatto su molteplici aspetti del loro stack IT e coinvolgono l’au-
tenticazione, la gestione del singolo accesso, l’autorizzazione, il controllo, la
conformita e la garanzia, il provisioning, la memorizzazione dei dati, etc.
Ai fini di questo caso di studio, ci concentreremo su soluzioni di provi-
sioning account utente. Queste soluzioni sono utilizzate dalle imprese per
affrontare la gestione del ciclo di vita delle identita degli utenti e degli ac-
count sulle risorse protette. Un processo di provisioning errato o non buono
potrebbe dare piu diritti necessari agli utenti o impedire loro di accedere alle
legittime risorse.
L’approccio basato sulla modellazione e particolarmente adatto per esplo-
rare le implicazioni dell’adozione e implementazione di nuove soluzioni e pro-
cessi (in questo caso il processo di provisioning utente), in quanto permette
la sperimentazione di varie ipotesi e parametri. Questo approccio e sta-
to applicato per studiare le implicazioni nel muoversi gradualmente verso
9
una maggiore automazione del processo di provisioning account per le mol-
te applicazioni in un’organizzazione. Per soddisfare le diverse esigenze degli
stakeholder, alcuni ricercatori hanno individuato una serie di metriche che
possono essere raccolte durante le simulazioni. I risultati per le metriche
selezionate possono quindi essere utilizzati da diversi stakeholder per testare
le proprie intuizioni, condividerle con gli altri in modo coerente e costante,
e insieme indagare le conseguenze di un particolare investimento o cambia-
mento politico nel processo di provision account.
Le tradizionali metriche di basso livello includono: il numero degli ac-
count utente mal configurati e il numero di quelli configurati correttamente;
il numero di account sospesi (di persone che hanno lasciato l’unita di busi-
ness o l’organizzazione); il tempo (ritardi) complessivo di approvazione per
le richieste di provisioning; il tempo (ritardi) di configurazione/distribuzione
globale; il numero delle richieste di configurazione/distribuzione e di appro-
vazione perse; il numero di processi di approvazione disabilitati. Queste me-
triche possono essere monitorate direttamente dai sistemi IAM implementati,
ma spesso sono utili solo ad alcuni stakeholder (ad esempio amministratori
di sicurezza e esperti del settore).
Per far fronte alle esigenze di tutti gli stakeholder coinvolti nella valuta-
zione del nuovo processo di provisioning account, c’e bisogno di un insieme
di metriche piu ampio. Pertanto, effettuando colloqui e convalidandoli con
esperti del settore, i ricercatori hanno identificato un insieme piu completo
di metriche di alto livello elencate di seguito (classificate dagli stakeholder
interessati):
Stakeholder: responsabile della sicurezza/conformita
• Accuratezza dell’accesso: il numero di account utente configurati
correttamente contro il numero totale di account creati, compresi gli
account mal configurati e gli account sospesi;
10
• Accuratezza dell’approvazione: il numero di attivita di provisio-
ning approvate contro le attivita complessive di provisioning, comprese
quelle non autorizzate.
Stakeholder: proprietario dell’applicazione (Business)
• Costo della produttivita : sono i costi, in termini di perdita di
produttivita per i dipendenti, dovuti ai ritardi durante le fasi di appro-
vazione e di configurazione/distribuzione del processo di provisioning.
Stakeholder :Operazioni IT ( IT Budget Holder)
• Costo di Provisioning IAM: il costo della distribuzione di soluzioni
automatizzate di provisioning IAM per un periodo di tempo determi-
nato (costi fissi e variabili);
• Sforzo di Provisioning: il numero effettivo di operazioni di provi-
sioning effettuate dall’organizzazione in un periodo di tempo specifico,
che da un’idea dello sforzo e del carico di lavoro coinvolti.
L’approccio di modellazione si basa su modelli matematici e simulazioni
correlate.
Nel caso di studio di provisioning IAM, modelliamo espressamente la
differenza tra provisioning IAM ad-hoc e centralizzato ed esploriamo l’im-
patto delle scelte sulle politiche esistenti e/o per modellare nuove politiche.
Cerchiamo di illustrare questo attraverso l’impatto sulle misure e metriche
introdotte.
Il modello si concentra esplicitamente sulla rappresentazione dei processi
di provisioning IAM, considerando i vari passaggi necessari nelle fasi di ap-
provazione e di implementazione/configurazione. Il modello ha catturato sto-
casticamente vari eventi esterni (ad esempio come un utente aggiunge, lascia
o cambia il proprio ruolo). In risposta ad ogni evento, e stato identificato un
insieme rilevante di applicazioni (per mezzo di distribuzioni di probabilita) in
11
cui gli account utente devono essere provisioned/deprovisioned in base al ruo-
lo e al profilo dell’utente. Per ogni applicazione considerata, sia gestita a livel-
lo centrale che gestita ad-hoc, i relativi passi di provisioning/de-provisioning
IAM sono modellati con varie misure.
In particolare ogni tipo di attivita di provisioning, che coinvolge un uten-
te e una o piu applicazioni/servizi, e esplicitamente modellato come un
“processo”.
Eventi esterni, come l’arrivo di un nuovo utente, sono modellate stoca-
sticamente, cioe con opportune distribuzioni di probabilita. Intuitivamente,
piu i processi di provisioning IAM sono centralizzati, automatizzati e gestiti
sotto politiche comuni, piu i loro comportamenti sono simili, in contrappo-
sizione ai processi ad hoc. Tuttavia, quando viene introdotta una maggiore
centralizzazione e automazione, l’impatto dei costi IAM (diritti di licenza) e
dei guasti e maggiore.
Il modello tiene traccia di una serie di misure cumulative tra cui: numero
di richieste di approvazione; numero di richieste di approvazione perse; nu-
mero di processi di approvazione bypassati; tempi di approvazione; tempi di
implementazione; numero di account utenti configurati correttamente; nume-
ro di account utente legittimi, negati; numero di account utenti errati (che
non dovrebbero esistere - account utente sospesi). Sulla base delle metriche
di basso livello, come parte del modello, calcoliamo anche le metriche di alto
livello individuate in precedenza.
Questo modello puo essere eseguito da diversi stakeholder (decisori ed
esperti di dominio) per svolgere direttamente esperimenti “what-if”, agendo
su “leve” disponibili e cambiando i parametri del modello. Gli stakeholder
possono concentrarsi su metriche di basso livello o metriche di alto livello, a
seconda del livello desiderato di astrazione per cui lavorano, confrontano i ri-
sultati attraverso piu esperimenti “what-if” e, se necessario, approfondiscono
i dettagli (ad esempio fino al livello delle funzioni di densita di probabilita di
misure/metriche di output). In questo modo gli stakeholder, per migliorare
la loro comprensione degli aspetti generali coinvolti in uno scenario specifico,
12
mappano i risultati previsti alle politiche attuali e le confrontano con le lo-
ro intuizioni; cio gli fornisce ulteriori elementi di prova per sostenere le loro
opinioni e posizioni.
I decisori operanti nell’ambito IAM hanno bisogno di prendere decisioni
di investimento IT consapevoli in un mondo complesso, in continuo cambia-
mento. Vorrebbero avere capacita di supporto alle decisioni per facilitare il
loro lavoro.
Per riuscire a fornire queste capacita, deve essere capita l’economia che
e alla base delle decisioni strategiche di investimento IT. Partiamo dal pre-
supposto che ci dovrebbe essere un quadro economico all’interno del quale il
valore dei diversi esiti di investimento puo essere esplorato e discusso. Cio
comporta all’identificazione dei principali risultati strategici e di business per
fornire e determinare i punti di vista intuitivi dei diversi stakeholder di questi
trade-off e delle loro preferenze per i risultati complessivi.
All’interno di un’organizzazione, i vari decisori strategici di solito hanno
priorita diverse; e importante identificare le preferenze dell’intera organizza-
zione (o ‘decisori’) per raggiungere questi obiettivi. Idealmente l’obiettivo
sarebbe quello di incapsulare queste preferenze in una formale “funzione di
utilita” dell’azienda e/o dei decisori, in modo che possa essere applicato a
ogni risultato un “valore comparativo”.
Nel contesto dell’economia IAM, una o piu funzioni di utilita possono
essere identificate per i decisori strategici coinvolti e/o per l’organizzazione.
13
4 Mappa tra i principali indici di rischio e i
principali indici di performance
Nel capitolo precedente abbiamo visto le metriche di rischio usate in un
modello per il controllo degli accessi. In questo capitolo vedremo come il
rischio si collega con i risultati del business; definiremo dunque gli indicatori
chiave di rischio (KRI) e gli indicatori chiave di performance (KPI) e vedremo
che relazione c’e tra i due. In particolare vedremo come lo sviluppo di catene
casuali e usato per legare rischio e risultati di business.
Il rapporto tra gestione del rischio e performance dovrebbe essere con-
cettualmente e intuitivamente ovvio. Un rischio non gestito correttamente
puo portare a fallimenti di imprese e a una scarsa performance aziendale. I
benefici di numerose attivita di gestione del rischio non sono chiare agli im-
prenditori che sono piu a rischio e spesso non riescono a trarre vantaggio dalle
informazioni disponibili dal rischio quando si prendono decisioni critiche di
business.
Cio che serve e una piu comune e profonda comprensione di come gli
eventi del rischio influenzano le prestazioni del business.
I manager aziendali non capiscono o non apprezzano il valore dell’in-
formazione del rischio o la loro relazione con il rischio; non capiscono che
possiedono i rischi e credono che i rischi siano affrontati esternamente da un
insieme di entita organizzative separate, chiamato “risk management”, che
si occupa per loro di questioni relative al rischio.
Mappare i pricipali indicatori di rischio (KRIs, key risk indicators) con i
principali indicatori di performance (KPIs, key performance indicators) puo
fornire ai manager aziendali le informazioni di rischio di cui hanno bisogno
per prendere decisioni migliori.
Collegando le attivita di gestione del rischio alle prestazioni di business,
le aziende possono supportare meglio le decisioni, basate sul rischio, prese
dai dirigenti aziendali.
Anche se le metriche di performance finanziarie rimangono una misura
14
fondamentale del valore, esse rappresentano solo i risultati delle attivita di
business. Pertanto, esse sono indicatori di ritardo di performance, che signi-
fica che dicono solo ‘quanto bene hai fatto’, non ‘quanto bene potrai fare in
futuro’. Le metriche non finanziarie sono i principali indicatori dei risultati
finanziari.
Vediamo in dettaglio cosa sono i KRI e i KPI e come si possono collegare.
I KPI sono indicatori chiave di prestazioni - una misurazione di un’atti-
vita di business desiderata o un evento che precede un risultato aziendale;
qualcosa da gestire in favore.
I KRI sono indicatori chiave di rischio - una misurazione di un’attivita di
business o un evento che ha preceduto e influenzato negativamente il risultato
desiderato; qualcosa da gestire contro.
I KRI sono buoni se sono semplici e misurabili e questi indicatori hanno
un impatto diretto su piu KPI.
La linea tra rischio IT e rischio di business sta scomparendo. La ge-
stione del rischio operativo gioca sempre piu un ruolo centrale nel processo
decisionale aziendale. Una buona gestione del rischio informa meglio il pro-
cesso decisionale aziendale e mappare i KRI nei KPI e un buon modo per
relazionare la gestione del rischio con la performance aziendale.
Mappare i KPI con i KRI serve per capire che relazioni ci sono tra questi
indicatori e registrare quei rapporti in modo che possano essere utilizzati nella
segnalazione e modellazione del rischio. La mappatura dovrebbe riflettere
esplicitamente l’impatto del KRI su un KPI.
Lo sviluppo di catene causali semplici e complesse aiutera a collegare
meglio un organizzazione di IT o di gestione del rischio con i responsabili
delle decisioni aziendali.
Questa relazione misurabile tra gestione del rischio e performance azien-
dale e sfuggita alla maggior parte delle organizzazioni. Come risultato, i
vantaggi di molte attivita operative di gestione del rischio non sono chiare
per gli imprenditori. Inoltre, spesso non riescono a sfruttare l’informazione
15
del rischio che e disponibile quando si prendono decisioni di business critiche.
Per affrontare questi problemi, le imprese dovrebbero sviluppare indica-
tori di prestazioni chiave (KPI) credibili e discreti, e gli sforzi di gestione del
rischio dovrebbero produrre indicatori di rischio (KRI) credibili e discreti che
impattino direttamente tali indicatori KPI. E necessaria una comprensione
piu profonda e comune di come eventi di rischio influenzano le prestazioni di
business. I KRI, come abbiamo gia detto, sono indicatori anticipatori che le
prestazioni di business sono a rischio.
Una catena causale (casual chain) documenta la confluenza di attivita
ed eventi che producono un risultato di business. Una catena casuale e una
sequenza di eventi che portano ad un effetto finale dove ogni anello della
catena determina il successore. Prima queste attivita e eventi si verificano
nella catena, piu sono principali a indicare i risultati di business. Le organiz-
zazioni possono agire su questi indicatori principali per gestire l’impatto sui
risultati successivi. Queste catene causali possono essere usate per spiegare
l’influenza degli eventi e delle attivita precedenti sui risultati successivi in
modo che i dirigenti possano prendere migliori decisioni di business.
Per aiutare a ottenere una comprensione di come usare le catene causali
per identificare i KRI, dobbiamo fare una distinzione tra catene semplici e
quelle complesse:
• Una catena semplice e un unico insieme lineare di attivita ed eventi
che hanno una relazione causale con i risultati del business desiderati.
Catene semplici sono usate come punto di partenza per la definizione
di relazioni causali. Esse sono prototipi utilizzati per scopi didattici e
non sono destinate a spiegare completamente le relazioni causali.
• Le catene complesse sono una combinazione di catene causali che do-
cumentano la comprensione della gestione dei rapporti causali che pro-
ducono risultati di business.
Uno scarso patching e uno dei vari indicatori anticipatori di potenziali
errori di applicazione e di inattivita. Una misura di errori di applicazione e
16
un indicatore anticipatore della performance dei processi di business, come
ad esempio quelle effettuate in una catena di fornitura. Una misura di pro-
blemi relativi alla catena di fornitura e un indicatore anticipatore di impatti
negativi sui risultati di business desiderati, come la redditivita. Questo sem-
plice esempio riguarda qualcosa di molto tecnico e spesso sottovalutato dai
dirigenti aziendali (patching) per la redditivita.
Alcuni imprenditori avranno familiarita con i diagrammi “fishbone di Ishi-
kawa. Questi diagrammi, noti anche come diagrammi causa-effetto, sono uti-
lizzati in programmi di miglioramento della qualita per identificare i fattori
che influenzano negativamente la qualita e i risultati desiderati. I fattori so-
no raggruppati per categoria lungo una “spina che rappresenta un risultato
desiderato. Frecce piu piccole collegano effetti alle cause principali, che for-
niscono visibilita e comprensione sui potenziali problemi precedenti. Questo
stesso concetto puo essere utilizzato per collegare gli indicatori che porta-
no a risultati di business desiderati. Nel loro insieme, la spina, i rami e le
frecce formano catene che documentano l’esplicita comprensione di un’orga-
nizzazione dei rapporti di causa ed effetto che si traducono in risultati di
business.
Ogni impresa ha una lista di risultati desiderati misurabili. Nel settore
privato, questi risultati misurabili si trovano nei bilanci che includono ta-
li risultati come ricavo e utile netto. Nel settore pubblico, i risultati dello
stato finale desiderato si trovano nel mandato della missione o nella legislazio-
ne/normativa che ha creato l’agenzia o il dipartimento. I KPI sono sviluppati
da questi risultati attesi misurabili, individuando le attivita (processi) e gli
eventi che precedono i risultati. Gli indicatori anticipatori o prospettici sono
i KPI piu efficaci perche si puo intervenire prima che si verifichino i risultati
desiderati.
Esistono opportunita per i CIO e i professionisti della gestione del rischio
di agire come facilitatori nello sviluppo di KPI, KRI e catene causali per
contribuire a migliorare il processo decisionale. Per le imprese che generano
indicatori prospettici sono a disposizione vantaggi finanziari significativi.
17
I KRI complementano i KPI, fornendo una prospettiva che e necessa-
ria per comprendere le relazioni causali da cui possono essere identificati i
principali indicatori.
La prospettiva fornita dai KRI accelera il processo di identificazione dei
KPI accettabili controbilanciando gli obiettivi ambiziosi che guidano l’identi-
ficazione dei KPI con la conoscenza degli eventi indesiderati e incontrollabili
che impediscono il raggiungimento di questi obiettivi. I KRI non misurano
gli eventi indesiderati e incontrollabili, come la probabilita di un terremoto.
Piuttosto, i KRI misurano le attivita (o processi) eseguite dall’impresa per
attenuare la perdita di un evento indesiderabile e incontrollabile, come pro-
cedure di recupero di emergenze. L’identificazione di eventi indesiderabili e
incontrollabili offre una prospettiva piu robusta ed equilibrata sulle relazioni
causali. Questa prospettiva equilibrata velocizza l’approvazione dei KPI e
completa la comprensione della gestione degli indicatori prospettici che por-
tano a risultati di business desiderati.
La maturita del programma di gestione del rischio IT di un’impresa e un
indicatore chiave dell’efficacia e dell’efficienza della sua posizione di rischio
complessivo. Migliorare la maturita della gestione del rischio e fondamentale
per migliorare l’allineamento costo-efficacia e business delle attivita di rischio
dell’impresa; ma questi miglioramenti richiedono azioni diverse a seconda del
livello di maturita attuale del programma di gestione del rischio. In mancanza
di una comprensione realistica e azionabile dello stato attuale del proprio
programma di gestione del rischio IT, l’impresa non e in grado di identificare
i rischi di business critici ai suoi processi e operazioni, identificare e colmare
le lacune nei suoi controlli del rischio, migliorare la maturita del programma
e giustificare i costi non trascurabili di gestione del rischio IT.
La gestione delle identita e dei diritti degli utenti e diventata sempre piu
complessa considerando che i sistemi, le applicazioni e i programmi di acces-
so endpoint si moltiplicano e le imprese consentono ai dipendenti, fornitori,
partner, fornitori e clienti un maggiore accesso ai propri sistemi e dati. Allo
18
stesso tempo, le imprese devono affrontare una crescente pressione a garanti-
re che gestiscano le identita degli utenti e l’accesso in conformita alla nuova
legislazione e normativa - e siano in grado di dimostrare che lo stanno fa-
cendo. Molte grandi imprese hanno cercato di ridurre questa complessita e
di affrontare le questioni di conformita attraverso una varieta di progetti di
tecnologia. Questi progetti sono spesso sconnessi e mal allineati, e l’impresa
si trova alle prese con un altro strato di complessita senza realizzare alcun
valore di business chiaro.
19
5 Conclusioni
L’Identity Analytics e una tematica di ricerca non ancora ampiamente esplo-
rata, aperta all’innovazione e ai contributi. Abbiamo visto che l’opportunita
di ricerca principale consiste nel concentrarsi sulla prospettiva dei decisori
(piuttosto che sul solito punto di vista IT), fornendo strumenti di supporto
alle decisioni e soluzioni che consentano loro di esplorare e prevedere l’impat-
to e le conseguenze delle loro decisioni, tenendo conto di tutti gli aspetti sui
fattori che sono rilevanti per loro, come costi, rischi per la sicurezza e perdite
finanziarie. Ci siamo occupati di analizzare approcci innovativi all’identity
analytics, cioe gli strumenti che aiutano il CISO e altri decisori della sicurez-
za a esplorare rigorosamente le conseguenze delle scelte delle loro politiche di
sicurezza e che spiegano ai dirigenti delle imprese le motivazioni per investire
in una soluzione di accesso o identita consigliata.
Per mostrare cio, abbiamo cominciato definendo il concetto di metrica
di sicurezza, abbiamo visto le sue proprieta e alcune applicazioni; in seguito
abbiamo studiato un caso specifico di metriche di sicurezza nel controllo degli
accessi; in particolare abbiamo analizzato le metriche usate in un modello di
provisioning utente del sistema di Identity and Access Management (IAM);
infine abbiamo mostrato come una buona gestione del rischio informa meglio
il processo decisionale aziendale; per dimostrare cio abbiamo definito gli in-
dicatori chiave di rischio (KRI) e gli indicatori chiave di performance (KPI)
e abbiamo mostrato come collegare i due indici.
Tutto cio suggerisce che l’Identity Analytics e un settore promettente che
portera le attuali tendenze aziendali nel settore strategico/esecutivo decisio-
nale da un approccio guidato dalla conformita ad un approccio guidato dal
rischio.
20
Riferimenti bibliografici
[1] Birch, D., Digital Identity Management: Technological, Business and
Social Implications, Book, 2007
[2] Windley, P., Digital Identity, O Reilly, 2005
[3] Pato, J., Identity Management: Setting the Context, HPL Technical
Report, HPL-2003-72, 2003
[4] Casassa Mont, M, Bramhall, P., Pato, J., On Adaptive Identity Ma-
nagement: The Next Generation of Identity Management Technologies,
HPL Technical Reports, HPL-2003-149, 2003
[5] Trust Economics, UK DTI grant P0007, Trust Economics Project, 2008
[6] SailPoint, SailPoint Identity Risk Management, http://www.
sailpoint.com/product/reporting.php, 2008
[7] Beres, Y., Baldwin, A., Shiu, S., Model-based Assurance of Security
Controls, HPL Technical Report, HPL-2008-7, 2008
[8] Oracle, Reporting and Auditing Solutions Roadmap, ftp://
ftp.oracle.com/sales/outgoing/oam/roadmap.pdf, 2008
[9] IBM, Identity Analytics, http://www-935.ibm.com/services/us/
gbs/bus/ pdf/g510-6527-ibm-identity-risk.pdf, 2008
[10] IdAnalytics, IdAnalytics, http://www.idanalytics.com/, 2008
[11] Shay, R., Bhargav-Spantzel, A., Bertino, B., password policy simulation
and analysis, DIM 2007, 2007
[12] ISO, ISO 27001, Information Security Management,
http://www.iso.org/iso/catalogue detail?csnumber=42103, 2005
[13] ISACA, Cobit, IT Governance, http://www.isaca.org/, 2008
21
[14] ITIL, ITIL IT Infrastructure Library for Service Management,
http://www.itil-officialsite.com/home/home.asp, 2008
[15] Adams, A, Sasse, M.A., Users are not the enemies, Communications of
the ACM, Volume 42, Issue 12, pages 40-46, 1999
[16] Moore, T., Clayton, R., The Consequence of Non-Cooperation in the
Fight Against Phishing, 3rd APWG eCrime Researchers Summit., 2008
[17] Klaus Julisch, A Unifying Theory of Security Metrics with Applications,
IBM Research Zurich 8803 Rschlikon Switzerland, 2009
[18] Yolanta Beres, Marco Casassa Mont, Jonathan Griffin, Simon Shiu,
Using Security Metrics Coupled with Predictive Modeling and Simu-
lation to Assess Security Processes, HP Laboratories, HPL-2009-142,
2009
[19] Marco Casassa Mont, Adrian Baldwin, Simon Shiu, Identity Analytics
- User Provisioning Case Study: Using Modelling and Simulation for
Policy Decision Support, HP Laboratories, HPL-2009-57, 2009
[20] Marco Casassa Mont, Yolanta Beres, David Pym, Simon Shiu, Econo-
mics of Identity and Access Management for Investments: Providing
Decision Support, HP Laboratories, HPL-2010-11, 2010
[21] Paul E. Proctor, Michael Smith, Douglas McKibben, Map Key Risk
Indicators to Key Performance Indicators to Support IT and Enterprise
Risk Management, Gartner, 2009
[22] Paul E. Proctor, Michael Smith, Developing Key Risk Indicators: De-
veloping Causal Chains to Link Risk to Business Outcomes, Gartner,
2010
[23] Paul E. Proctor, Developing Key Risk Indicators: ITScore Overview for
Security and Risk Management, Gartner, 2010
22
Top Related