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