ROSI Return on Security Investments: un approccio pratico

Transcript

ROSI Return on Security Investments:
un approccio pratico
Come ottenere Commitment
sulla Security
versione 2.0
AIEA
CLUSIT
Deloitte
Ernst & Young
KPMG
Oracle
PricewaterhouseCoopers
LICENZA D’USO
Il testo completo della Licenza d’uso è disponibile sul sito di Creative Commons, al link
http://creativecommons.org/licenses/by-sa/2.5/it/legalcode
Preghiamo inoltre chi volesse utilizzare questo testo all’interno di propri lavori (non semplicemente
con una citazione) di segnalarlo con un messaggio all’indirizzo [email protected].
Sommario
1.
Introduzione – L’iniziativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Gruppo di Lavoro ROSI e motivazioni del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Perché fare un ROSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.
Management Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Cos’è il ROSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 A chi si rivolge? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 A cosa serve il ROSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Quali benefici porta la costruzione di un ROSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Guida alla lettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.
Metodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Documenti di riferimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Identificazione esigenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Identificazione scenari di intervento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Gestione del rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Output del processo di gestione del rischio . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Identificazione Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Predisposizione Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.2 Area di intervento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.3 Criteri di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.4 Risorse impattate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.5 Driver di business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.6 Contesto di riferimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.7 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.8 Driver/motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.9 Punti di attenzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.10 Elementi di valutazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.11 Benefici/vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Identificazione Business Drivers e Metriche di sicurezza . . . . . . . . . . . . . . . . . . . . 25
3.6.1 Individuazione delle motivazioni operative (business drivers) . . . . . . . . . . . . 25
3.6.2 Identificazione degli stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.3 Identificazione dei benefici e degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.4 Identificazione delle metriche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.5 L’esempio dell’ IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Valutazione del ROSI in un dato scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.1 Approccio per il calcolo dei KCI e dei KRI . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.2 Costi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Diretti/Indiretti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Fissi/Variabili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Capital/Operational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3
3.7.3 I costi per il ROSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7.4 Ritorni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7.5 I ritorni per il ROSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Un esempio di valutazione del ROSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1 Step 1: Individuazione dei costi e dei ritorni . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.2 Step 2: Definizione degli indicatori per il ROSI . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.3 Step 3: Identificazione delle metriche disponibili . . . . . . . . . . . . . . . . . . . . . 34
3.8.4 Step 4: Predisposizione di nuove metriche . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.5 Step 5: Misurazione delle metriche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.6 Step 6: Valutazione degli indicatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.
Documento ROSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Struttura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Obiettivo desiderato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Proposta operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.
Esempi di pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1Pattern “Amministratori di Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2Pattern “Identity and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3Pattern “Single Sign On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4Pattern “IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5Pattern “Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6Pattern “Sicurezza Fisica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.7Pattern “IRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.8Pattern “Security Assessment Industriale” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9 Pattern “PCI-DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.10 Pattern “DLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.11 Pattern “DAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.12 Pattern “Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.13 Pattern “VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.
Company Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1 AIEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2 Clusit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4 Deloitte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.5 Ernst & Young . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.6 KPMG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.7 PricewaterhouseCoopers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.
Appendici e Revisioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.1 Appendice A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.2 Appendice B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3 Storia delle versioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3.1 Versione 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3.2 Versione 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
1. Introduzione - L’iniziativa
1.1 Gruppo di Lavoro ROSI e motivazioni del lavoro
Questa iniziativa è stata avviata da AIEA, Clusit e Oracle, nel settembre 2009, e vede la partecipazione all’interno del Gruppo di Lavoro (GdL) di Deloitte, Ernst & Young, KPMG e PriceWaterhouseCoopers.
L’esperienza delle aziende e delle associazioni componenti del Gruppo di Lavoro mostra chiaramente come esista una necessità, nel mercato della sicurezza informatica, di “fare un passo
avanti” e di disporre di criteri e metodi oggettivi che permettano di ottimizzare gli investimenti nei
differenti capitoli di spesa.
Mentre altri tipi di spesa in migliorie organizzative o tecnologiche vengono riconosciuti, correttamente, non solo come esborsi ma anche come investimenti, volti a rendere in assoluto possibili
certe azioni imprenditoriali, oppure a migliorare l’efficienza e/o l’efficacia di taluni processi, la
spesa in sicurezza è percepita quasi dovunque solo come costo puro, un vincolo, una “tassa” da
pagare per conformarsi alle pratiche correnti piuttosto che alle pretese di un regolatore o di un
legislatore.
Si aggiunga che anche l’industria del software e dell’hardware di sicurezza ha spesso adottato, come propria strategia di vendita, quella di seguire questa linea di minima resistenza. Intere
campagne marketing hanno cercato di indurre alla spesa sventolando lo spauracchio di non ben
identificati “cattivi” (spesso definiti, impropriamente, “hacker”) in agguato al fine di introdursi,
controllare e danneggiare i nostri sistemi informatici. O ancora, la minaccia, tanto più difficile da
razionalizzare perché impersonale ed eterea, del “virus” o del “chissà cosa ti potrebbe succedere”.
La situazione è quindi, spesso (troppo spesso, a nostro parere) quella di spese in sicurezza spiegate e decise in base alla paura, all’incertezza, al dubbio.
La situazione, per chi invece lavora nel settore, è palesemente assai diversa da questa: all’hacker
non ben identificato si sostituiscono criminali ben vivi e presenti, e determinati ad approfittare indebitamente di sistemi ed informazioni altrui per un preciso e personale tornaconto economico.
Al “chissà cosa ti potrebbe succedere” si sostituisce una puntuale analisi del rischio realmente
gravante sulla specifica organizzazione, dove le minacce, le vulnerabilità, le aree d’impatto e le
probabilità d’accadimento vengono valutate in modo oggettivo, per quanto a volte, per forza di
cose, in via qualitativa e non quantitativa.
Alla spesa a fondo perduto si sostituisce l’investimento, deciso in base a motivazioni razionali e
sostenibili, e dal quale ci si attendono precisi ritorni, magari non a livello economico ma comunque
vantaggiosi per l’organizzazione.
L’esperienza dimostra che questi passaggi sono possibili e vantaggiosi, e si vuole, con questo
documento, esporre le necessarie condizioni a priori, le possibili metodologie di approccio ed i
cambiamenti d’atteggiamento che è possibile ottenere.
Obiettivo del lavoro è stato pertanto quello di consolidare una riflessione che da più parti stava
emergendo, senza peraltro avere grande eco, in merito al ROSI, per dare agli operatori economici
pubblici e privati uno strumento che sia di valore per tutto il mercato, e ne stimoli la crescita e la
maturazione su tutti i fronti.
5
1
Attualmente non risulta
ci siano altri documenti
in italiano sul ROSI,
ma esiste dell’ottimo
materiale in inglese e in
francese, in particolare il
documento Clusif “Rétour
sur investissement en
sécurité des systèmes
d’information: quelques
clès pour argumenter”
disponibile al link
https://www.clusif.asso.
fr/fr/production/ouvrages/
pdf/RoSI.pdf
e il documento “ROSI” di
ISF richiamato anche nel
seguito.
versione 2.0
Crediamo quindi che questo lavoro sia vantaggioso per tutto il settore, e contribuisca in modo
sostanziale alla sua maturazione, dando un vantaggio a tutti gli operatori (clienti, fornitori, consulenti, ecc.) e giustificando una collaborazione come questa che vede coinvolte anche aziende
normalmente concorrenti sul mercato.
Si intende quindi consentire ad aziende private, enti pubblici, vendor tecnologici, società di consulenza, e così via, di approcciare la sicurezza delle informazioni – tema obbiettivamente complesso
e tendenzialmente multidisciplinare – in un modo organico e strutturato, dando a ciascuno gli
strumenti per giudicare con cura quali investimenti adottare e su quali strade spingere la propria
evoluzione tecnologica ed organizzativa.
1.2 Perché fare un ROSI?
In generale i security manager e/o i responsabili dell’Information Technology trovano grosse difficoltà a giustificare in azienda gli investimenti in soluzioni per la sicurezza delle informazioni, vuoi
per il proprio background culturale, che in genere è più tecnico e quindi meno avvezzo a considerare gli aspetti economico-finanziari, vuoi per la natura stessa delle soluzioni che nella maggior
parte dei casi sono destinate a prevenire potenziali rischi non completamente quantificabili piuttosto che finalizzate a fornire un beneficio diretto e misurabile.
Tuttavia, proprio gli stessi responsabili della sicurezza e dell’Information Technology lamentano
che ottenere dei budget adeguati per far fronte agli investimenti in sicurezza sia una delle principali sfide che quotidianamente si trovano ad affrontare in azienda, come è emerso dall’annuale
ricerca di Ernst & Young “Global Information Security Survey”.
Figura 1 – Principali
problematiche di
sicurezza che le
imprese stanno
affrontando (fonte:
“Ernst & Young 13th
Global Information
Security Survey”)
A maggior ragione, in un periodo attraversato da una difficile crisi economica, le aziende dovrebbero adottare una strategia di sicurezza risk-based, al fine di definire le iniziative di sicurezza
prioritarie e giustificare al meglio i nuovi investimenti dimostrandone il ritorno in termini di benefici
al business, riduzione dei costi operativi, miglioramento dell’immagine, ecc.
Pertanto l’utilizzo di un approccio strutturato per definire il ritorno degli investimenti in sicurezza
(“ROSI” – Return On Security Investment) può aiutare i manager che in azienda si occupano di
sicurezza a giustificare al meglio le spese ed ottenerne l’approvazione e lo stanziamento di budget
superiori.
6
2. Management Summary
2.1 Cos’è il ROSI?
ROSI sta per “Return On Security Investment”, e s’intende con questa sigla il lavoro di valutazione
dei vantaggi potenziali di un investimento in sicurezza, in particolare in sicurezza delle informazioni.
È un supporto decisionale rivolto in primis a quanti sono in posizioni di responsabilità sul settore di
Information e Communication Technology delle organizzazioni, e devono allocare in modo prudente delle risorse scarse. Può essere anche, a posteriori, un supporto per la valutazione di efficacia
di processi e/o impianti già in produzione.
Non è, come si può intuire, un oggetto paragonabile al ROI che si calcola in ambito finanziario, in
quanto non stiamo trattando un investimento nel senso tecnico del termine ovvero di una spesa
per un bene che di per sé produrrà ricavi, a meno che il business principale dell’investitore sia
proprio la sicurezza (e quindi investire, ad esempio, nell’acquisto di un sistema di sicurezza, consente di sfruttare questo sistema per fornire servizi a valore aggiunto).
In prima istanza, che è spesso l’unica analizzata, le spese in sicurezza possono ripagare con la
minore probabilità di subire dei danni e quindi, salvo i casi (si spera infrequenti) di effettivo manifestarsi della minaccia, richiedono una spesa certa a fronte di un danno incerto.
È sempre vero, inoltre, che nel momento in cui la minaccia si manifesta, il valore delle contromisure diventa almeno pari a quello del bene protetto, se non superiore considerando tutti i mancati
danni indiretti (riduzione di business, danno d’immagine, sanzioni, ecc.).
La spesa in sicurezza, tuttavia, non genera soltanto protezione, ma in svariati casi risulta produttiva
anche in modo diretto.
• La sicurezza abilita alcuni servizi altrimenti impossibili, tanto più quanto sono legati alla protezione della persona o della proprietà (ed in particolare del denaro). Ad esempio, l’incremento
di affidabilità nel riconoscimento dell’utente da parte del sistema informatico permette di automatizzare una serie di servizi (si pensi all’introduzione dell’home banking).
• La spesa in sicurezza può generare dei risparmi in altre parti dell’organizzazione: nell’esempio
precedente, per l’istituto bancario nasce anche un abbattimento dei costi precedentemente
legati al personale operativo.
• Una spesa in sicurezza, se adeguatamente resa nota alla clientela, produce dei benefici reali
in termini di immagine di solidità dell’organizzazione andando ad alimentare la fiducia che la
clientela ha nell’organizzazione stessa. Si intuisce che questa maggiore fiducia si trasferisce
immediatamente in un miglioramento dei risultati operativi.
• il panorama normativo oggi esistente fa sì che, in molti casi, le spese in sicurezza siano obbligatorie per il rispetto delle normative medesime e che quindi abbiano un ritorno effettivo – anche
se difficilmente misurabile numericamente – in termini di compliance.
Non è quindi completamente fuori luogo l’idea di “misurare”, in qualche modo, i benefici derivanti
dall’investimento in sicurezza i quali saranno derivanti dall’unione dei vari insiemi di benefici: quelli operativi (in termini di diminuzione del rischio – e, al limite, ai minori oneri assicurativi), quelli
d’immagine e quelli di compliance.
7
versione 2.0
Si può già intuire che nella maggior parte dei casi, la misura di questi benefici sarà qualitativa, e
nuovamente si capisce quanto il ROSI non sia una misura esatta e numerica come il ROI; ma è
altrettanto indiscutibile, se ben supportato da dati oggettivi, anche se qualitativi, la sua validità e
la sua utilità.
2
La sicurezza delle
informazioni copre
naturalmente un insieme
più grande di oggetti
rispetto alla sola sicurezza
informatica, dal momento
che abbraccia - almeno
concettualmente tutte le informazioni di
un’organizzazione.
Il concetto di informazione, a sua volta, è distinto
da quello di dato, perché
è con un’operazione
logica che dai dati si traggono le informazioni. Ad
esempio, i dati potrebbero
essere le serie storiche
delle vendite. L’informazione che si può trarre da
questi dati è “le vendite
sono cresciute del 6%
rispetto al corrispondente
periodo dell’anno scorso”.
La grande maggioranza
dei dati e delle informazioni, oggi, risiede sui
sistemi informatici, che
comunque non coprono la
totalità poiché ve n’è una
consistente parte ancora
in archivi cartacei, ma
soprattutto (ed è spesso la
parte preponderante delle
informazioni preziose) si
trovano nella “testa delle
persone”.
Anche per questo motivo
la sicurezza delle informazioni in senso lato deve
preoccuparsi anche della
safety del personale, oltre
che dei sistemi tecnologici
e degli archivi tradizionali.
Si potrebbe addirittura
inferire che il fornire un
ambiente di lavoro gradevole e tranquillizzante sia
un problema di sicurezza
delle informazioni, concetto che è molto meno
provocatorio di quanto
non si possa immaginare
a priori.
2.2 A chi si rivolge?
Questo documento è pensato per tutti coloro i quali all’interno di un’organizzazione hanno ricevuto
la responsabilità, in modo più o meno formale, di gestire la sicurezza delle informazioni di cui
l’organizzazione medesima si serve, a qualsivoglia titolo.
Si tratta spesso di specialisti del settore dell’informatica e delle telecomunicazioni, generalmente
all’interno della funzione IT o ICT, ma che non sempre hanno esperienze specifiche in ambito di
sicurezza informatica, né, a maggior ragione, di sicurezza delle informazioni. 2
Si tratta a volte di persone di estrazione diversa, e che magari provengono da esperienze in ambito
organizzativo o della gestione qualità.
Si trovano a riportare a responsabili IT o ICT, ma anche a responsabili dell’organizzazione, delle
risorse umane o dell’amministrazione, o magari addirittura in staff alla direzione generale; ma
questo è ininfluente ai fini di questa trattazione.
2.3 A cosa serve il ROSI?
Il problema condiviso da molte di queste persone è la necessità di “giustificare” ad un superiore la
proposta di spesa in questo ambito, la sicurezza delle informazioni, che si continua a dimostrare
assai sfuggente, perché – trattando di spese certe a fronte di eventi per definizione incerti, anzi
che si cerca di prevenire o mitigare – non si presta ad una trattazione numerica tout court che
richiede che i benefici di una spesa possano essere misurati in modo preciso a priori.
Tuttavia, come esseri umani, siamo abituati in realtà a trattare con situazioni dove il beneficio è
solo ipotetico, e nella nostra vita privata non abbiamo difficoltà ad accettare una spesa il cui ritorno non sia immediatamente tangibile. La difficoltà è in parte generata dall’organizzazione stessa
che, dovendo contenere per forza le sensibilità di molte persone, richiede di essere “convinta”
di questa necessità con argomentazioni il più possibile oggettive e quindi facili da accettare per
chiunque.
Il lavoro di stesura di un ROSI guida quindi nella raccolta di una serie di dati significativi, anche
se non sempre quantitativi, e nella costruzione di un documento di sintesi dove proporre delle
deduzioni ragionevoli e sostenibili rispetto alle possibili spese, con l’ottica di trasformare queste
spese in investimenti.
2.4 Quali benefici porta la costruzione di un ROSI?
• Diventa possibile motivare in modo oggettivo le proposte di investimento sulla sicurezza delle
informazioni.
• Diventa possibile fare una graduatoria tra varie proposte di investimento in modo meno arbitrario che nel passato.
• Diventa possibile valutare in modo oggettivo, a posteriori, la bontà delle scelte di investimento
sulla sicurezza delle informazioni.
8
2 Management Summary
• Costringe ad uscire dall’ambito puramente tecnologico per valutare l’impatto complessivo di
ciascun investimento sui risultati operativi finali.
2.5 Guida alla lettura
Il tema è, come si diceva, obbiettivamente complesso, e, come spesso accade, lo si può approcciare almeno in due modi: uno più analitico (detto nel seguito “Top-Down”), che parte da alcune
ipotesi per arrivare a delle conclusioni, ed uno più pragmatico (detto nel seguito “Verify”), che si
basa su una serie di soluzioni note a problemi comuni e cerca di capirne l’applicabilità alla situazione in esame.
Il metodo per l’identificazione del ROSI è illustrato alla sezione 3, insieme ad alcuni elementi che
riteniamo possano tornare utili al lettore per l’applicazione dello stesso. La stessa sezione contiene
un esempio di applicazione dell’approccio Top-Down, mentre numerosi esempi per l’approccio
Verify sono riportati alla sezione 5. Nella sezione 4 si può invece trovare una guida alla stesura del
documento di presentazione al management dei risultati dello studio.
Numerosi altri documenti sono citati ed in larga misura disponibili su Internet; alcuni, frutto del
lavoro del GdL, sono presenti nel sito ROSI http://rosi.clusit.it/ con la stessa licenza del presente
documento.
Casi reali di incidenti di sicurezza *
Caso 1
In un’azienda a proprietà pubblica, a causa di un malfunzionamento del
Back-up, una parte dei dati contabili e di fatturazione a utenti del servizio
pubblico è andata persa (2 giorni di registrazioni).
Non essendo possibile, per varie ragioni (non ultima quella di ordine politico-industriale) emettere il rendiconto mensile a 45 milioni di utenti, viene
deciso di emettere dei rendiconti per ciascuna operazione registrata (in tal
modo è possibile recuperare quasi tutti i dati), e di inviare in più a ciascuno
degli utenti una lettera di spiegazione e scuse per il disservizio.
I costi dell’operazione (e quindi delle perdite) sono pari a 3 milioni di €
(quasi totalmente indennizzati) a tali costi si sono aggiunti quelli delle lettere di scuse e spiegazione (1 milione); questa ultima parte dei costi non
era assicurata ed è rimasta a carico dell’amministrazione (1 milione).
* Estratto dal documento di Riccardo Scalici “Il panorama dei rischi”
9
3. versione 2.0
Metodo
Se da un lato sono richiesti maggiori investimenti in sicurezza per rispondere ai nuovi dettami legislativi, ai nuovi modelli verso cui tendono le tecnologie a supporto del business (cloud computing,
Service Oriented Architecture, Software as a Service, ecc.), all’aumento delle minacce che incombono sul business e alla maggiore attenzione al rischio da parte degli organi di controllo aziendali,
dall’altro gli amministratori di un’azienda, spinti dalla necessità di ottenere risultati dimostrabili,
richiedono valide giustificazioni prima di autorizzare un qualsiasi tipo d’investimento.
Ecco quindi che il responsabile della sicurezza del sistema informativo aziendale è chiamato come
non mai a superare l’ardua sfida di riuscire a dimostrare compiutamente al management il ritorno
su un investimento, così da ottenere le risorse necessarie per far fronte alle iniziative necessarie a
tutelare la sicurezza del patrimonio informativo aziendale.
Il metodo per l’identificazione del ROSI che illustreremo in questo capitolo vuole costituire una
linea guida in grado di supportare il responsabile della sicurezza in questa sfida rendendo disponibili le indicazioni e gli strumenti che consentano di identificare:
• dove intervenire;
• perchè intervenire;
• come intervenire;
• i benefici;
• chi trae beneficio dall’intervento;
• come misurare l’efficacia dell’intervento;
• come valutare il ROSI.
Il metodo, così come elaborato dal GdL, vuole quindi rendere disponibile al lettore degli spunti di
riflessione, concreti e pragmatici, per:
• identificare gli ambiti in cui la sicurezza contribuisce al perseguimento degli obiettivi aziendali;
• identificare gli interventi;
• identificare e coinvolgere nel processo di approvazione dell’investimento i componenti del
Management, in qualità di Sponsor;
• definire un sistema di indicatori in grado di evidenziare i benefici che l’investimento in sicurezza è e sarà in grado di apportare all’azienda nel tempo;
• valutare il ROSI.
Figura 2
Rappresentazione
Approccio
Top-Down
Identificazione
esigenza
Identificazione
scenari di intervento
schematica
del processo di
valutazione del ROSI
Approccio
Verify
Identificazione
Pattern
Predisposizione
Pattern
Identificazione
Drivers e
Indicatori
Valutazione
ROSI
Il metodo è esposto secondo un formato narrativo. Il testo principale rappresenta la linea guida che
consentirà di raccogliere tutti gli elementi funzionali al calcolo del ROSI.
10
3. Metodo
3.1 Documenti di riferimento
Nel corso dell’illustrazione del metodo talune affermazioni del testo principale saranno spiegate da
note a corredo o espliciti riferimenti a standard e framework internazionali. Per le nostre finalità si
fa riferimento a:
• CoBit 4.1; framework funzionale alla definizione di un sistema di IT Governance perché fornisce un modello per assicurare che: l’IT sia allineato con le strategie dell’azienda, l’IT consenta
la gestione delle funzioni aziendali e ne massimizzi i benefici, le risorse dell’IT siano usate
responsabilmente, i rischi IT siano opportunamente gestiti;
• ISO/IEC 27001:2005; standard internazionale che definisce i requisiti indispensabili di un
sistema per la gestione della sicurezza delle informazioni ed identifica, per ciascuno degli 11
ambiti di sicurezza indicati, gli obiettivi di controllo ed i relativi controlli di sicurezza da porre
in essere;
• ISO/IEC 27002:2005; è il Code of Practice dell’ISO 27001, riporta le best practices di sicurezza per l’implementazione dei controlli di sicurezza previsti dall’ISO 27001;
Figura 3 - Posizionamento ROSI
• ISO/IEC 27005:2008; standard internazionale che definisce le linee guida per la gestione dei
rischi correlati alla sicurezza informatica;
3
• ITIL: insieme di documenti che descrivono le Best Practice nella gestione dei servizi IT e sui
processi ed i mezzi necessari a supportarli, nell’ottica di erogare servizi di alta qualità.
3.2 Approccio Top-Down – Identificazione esigenze
I rischi fondamentali di inefficacia della sicurezza sono la copertura a macchia di leopardo, la
mancanza di riscontro delle iniziative di sicurezza e l’attribuzione di responsabilità e attività di sicurezza a innumerevoli funzioni aziendali. Rischi che, tra l’altro, comportano una frammentazione
degli investimenti e una perdita di opportunità di sinergia.
Queste considerazioni, sulla base anche di standard e best practice consolidate, suggeriscono
alle aziende, e in particolar modo al responsabile della sicurezza, di prevedere un approccio alla
sicurezza basato sui processi 3 (di sicurezza).
11
Fonti professionali che
possono fornire approfondimenti sul significato e
sui contenuti dei processi
di sicurezza sono:
• Common Criteria;
• ITIL (IT Infrastructure
Library);
• CobiT (Control Objective
for IT Organizations);
• SANS Institute;
• National Institute
of Standards and
Technology;
• ISO (con riferimento
allo standard ISO/IEC
27001).
versione 2.0
Per processi di sicurezza s’intende l’insieme delle attività che il sistema di governo della sicurezza
richiede siano svolte nel periodo da coloro che, a vario titolo, sono deputati a gestire la sicurezza
informatica.
La scomposizione delle categorie di processi di sicurezza in attività di sicurezza trova in letteratura
una certa variabilità di contenuti. Per le finalità espositive del metodo di cui alla presente Linea
Guida, un processo di sicurezza è il comportamento di uno o più soggetti avente lo scopo:
• di definire le misure di sicurezza congruenti con gli obiettivi generali di sicurezza;
• e/o di applicare le misure di sicurezza;
• e distintamente, nel rispetto di rigorose regole di separazione dei compiti, di controllarne l’applicazione.
I processi di sicurezza vanno collocati nell’ambito dei quattro momenti tipici del ciclo Deming
(P-Plan, D-Do, C-Check, A-Act) definito dallo standard ISO 9001 da parte dello standard di riferimento ISO/IEC 27001:2005 per la certificazione di un sistema di gestione della sicurezza delle
informazioni.
Questa impostazione presuppone che l’insieme dei processi per il governo della sicurezza sia concepito come un macro-processo di qualità con i suoi momenti tipici (PDCA) che ne consentono il
miglioramento e l’allineamento continuo agli obiettivi di sicurezza aziendali.
Un interessante framework di riferimento per la gestione della sicurezza con un approccio a processi è quello predisposto per conto dell’ABI dal gruppo di lavoro dell’ABI Lab con la partecipazione di 12 banche italiane ed il coordinamento di Deloitte.
Il framework descrive l’approccio alla gestione integrata della sicurezza in ambito bancario definito
dal gruppo di lavoro ABI Lab.
In tale framework i processi sono stati raggruppati in Processi direzionali e Processi operativi e
questi ultimi in Processi inerenti la gestione della sicurezza in fase di esercizio e Processi inerenti
la gestione della sicurezza in fase di sviluppo (sviluppo di applicativi, disegno di reti e configurazioni di sistemi).
La figura che segue illustra i processi di sicurezza previsti dalla linea guida metodologica per l’approccio integrato al governo della sicurezza in ambiente bancario.
Figura 4 - Framework
Processi Sicurezza
ABILab
Per ciascun processo di sicurezza il framework richiama l’obiettivo o scopo del processo; le macroattività che lo caratterizzano e la relativa descrizione; le strutture organizzative a presidio, gli
obiettivi di sicurezza presidiati.
Seppur nato per rispondere alle stringenti esigenze di sicurezza e di efficienza del mondo bancario
12
3. Metodo
e, nello specifico, per proporre un approccio integrato al governo della sicurezza in ambito bancario, il framework può costituire un valido modello di riferimento anche per ambiti non bancari.
Un buon sistema di governo della sicurezza è in grado di ridurre le inefficienze tipiche di un approccio non strutturato tramite una corretta e puntuale individuazione e indirizzamento delle reali
esigenze di sicurezza di un’azienda.
Una visione per processi, inoltre, facilita il compito di individuare eventuali economie di scala.
Possiamo quindi dire che il primo ambito di sicurezza su cui l’azienda deve investire è proprio
quello afferente al sistema di governo della sicurezza affinchè sia in grado di operare efficacemente ed efficientemente nel tempo, consentendo da un lato di garantire un adeguato e costante
livello di sicurezza, evitando false percezioni di sicurezza, e dall’altro di ottimizzare gli investimenti
concentrandoli ove effettivamente necessario.
Nella ricerca dell’investimento “ottimale” in sicurezza è particolarmente importante considerare
oltre che le risorse IT anche i processi che le gestiscono. Molto spesso il problema non è nella
risorsa in se, ma in come viene gestita o utilizzata.
Ad esempio, il più delle volte non mancano i corsi di formazione, ma manca il meccanismo (processo) che provveda ad inviare le persone giuste al corso giusto al momento giusto e che ne valuti
i risultati.
Un altro aspetto non trascurabile da tenere in considerazione, visto che riguarda i ritorni in investimenti in sicurezza, consiste nel fatto che intervenire sul processo invece che sulla risorsa fornisce,
in genere, ritorni molto più elevati.
Ad esempio, integrare il processo di sviluppo delle applicazioni con gli aspetti di sicurezza comporta, a parità di risultati, costi nettamente inferiori rispetto alla successiva aggiunta di sicurezza
tanto che se soltanto il 50% delle vulnerabilità del software fossero rimosse prima del rilascio in
produzione, i costi di mitigazione di tali vulnerabilità sarebbero ridotti del 75% 4.
Come noto la sicurezza informatica è chiamata a tutelare la riservatezza, l’integrità e la disponibilità
(RID) del patrimonio informativo aziendale fornendo un contributo fondamentale nella gestione dei
rischi operativi 5 a cui un’azienda è esposta.
A titolo di esempio si considerino le seguenti categorie di rischio aziendale: • Perdita economica;
• Perdita della proprietà intellettuale;
• Perdita o danno d’immagine;
• Compromissione dei dati dei clienti e/o dei business partner;
• Non conformità a norme nazionali e internazionali (Privacy, 231, SOX, ecc.);
• Indisponibilità dei processi di business;
• Riservatezza dei dati di business.
Non si può non convenire sul fatto che il livello d’esposizione dell’azienda a queste tipologie di rischio è, tra le altre cose, inversamente proporzionale al livello di sicurezza del sistema informatico
a supporto dell’operatività quotidiana delle funzioni di business.
4
Si consideri infatti che:
• una perdita economica può essere dovuta al mancato introito a causa della indisponibilità di
una applicazione di business (virus, attacco Denial Of Service, ecc.);
• una perdita della proprietà intellettuale può essere causata dalla mancanza o carenza di
presidi di sicurezza volti a proteggere, a titolo d’esempio, la documentazione di progettazione
meccanica per la costruzione di un macchinario innovativo;
13
Security at the
Application Level –
Gartner
5
Per una definizione di
rischio operativo, si veda
ad esempio
http://it.wikipedia.org/wiki/
Rischio_operativo
versione 2.0
• una perdita o danno d’immagine il più delle volte è conseguenza di una non corretta protezione delle informazioni sensibili di un’azienda (dati personali dei clienti, dati finanziari, numero
di carte di credito, ecc.) che si traduce in una diffusione incontrollata di informazioni personali o finanziarie;
• causa di non conformità a norme nazionali e internazionali è il mancato rispetto di requisiti di
protezione delle informazioni o di gestione e controllo degli accessi alle stesse per via di una
gestione non strutturata della sicurezza.
L’obiettivo che ci si deve porre, quindi, consiste nell’identificare i processi IT che giocano un ruolo
importante nella mitigazione dei rischi di Riservatezza, Integrità, Disponibilità delle informazioni e
di Conformità alle normative interne ed esterne (in sintesi RIDC).
Se si partisse da un foglio bianco l’identificazione di tali ambiti potrebbe rivelarsi un’impresa ardua,
quasi impossibile, ma fortunatamente la sempre maggiore attenzione da parte delle aziende agli
aspetti di efficienza ed efficacia dei propri processi interni ha fatto sì che gruppi di ricerca, centri
universitari e società di consulenza abbiano investito su queste tematiche rendendo disponibili
tecniche e metodi relativamente semplici, fruibili e ben strutturati, utilizzabili anche autonomamente.
Un approccio all’identificazione delle aree d’intervento può prendere spunto dal CobiT 4.1 6 e
dall’ISO/IEC 27001.
Il primo consentirà di individuare i processi IT che contribuiscono a determinare quello che sarà il
livello di sicurezza del sistema informativo (SI), mentre il secondo guiderà nell’individuazione dei
domini di sicurezza e dei relativi obiettivi di controllo e attività di controllo da porre in essere.
Come è noto lo schema CobiT copre anche gli aspetti di efficienza, efficacia ed affidabilità dei dati.
Nel presente studio si sono considerati solo quelli relative a Riservatezza, Integrità, Disponibilità e
Conformità proprie della Sicurezza informatica.
L’elenco sottostante, liberamente ricavato dal framework CobiT 4.1 conservando esclusivamente
le parti relative alla sicurezza 7, viene, alla data, ritenuto completo ed esaustivo e quindi un suo
utilizzo offre buone garanzie di sistematicità in quanto vengono esaminate tutte le aree dove sono
possibili interventi migliorativi.
Tabella 1 - Processi
Processo CobiT
rispetto alla sicurezza IT
CobiT per la sicurezza
e loro rilevanza
6
Liberamente scaricabile
nella sua traduzione
italiana dal sito AIEA:
http://www.aiea.it/
7
Il Framework CobiT valuta anche gli aspetti relativi
ad efficienza,efficacia ed
affidabilità dell’IT.
Importanza relativa
PO2 - Definire l’architettura informatica
4
PO6 - Comunicare gli obiettivi e gli orientamenti della direzione
1
PO8 - Gestire la Qualità
1
PO9 - Valutare e Gestire i Rischi Informatici
10
AI2 - Acquisire e mantenere il software applicativo
1
AI3 - Acquisire e mantenere l’infrastruttura tecnologica
2
AI4 - Permettere il funzionamento e l’uso dei sistemi IT
3
AI5 - Approvvigionamento delle risorse IT
1
AI6 - Gestire le modifiche
6
AI7 - Installare e certificare le soluzioni e le modifiche
2
DS1 - Definire e gestire i livelli di servizio
4
DS2 - Gestire i servizi di terze parti
4
DS3 - Gestire le prestazioni e la capacità produttiva
1
DS4 - Assicurare la continuità del servizio
3
14
3. Metodo
Processo CobiT
Importanza relativa
rispetto alla sicurezza IT
DS5 - Garantire la sicurezza dei sistemi
8
DS9 - Gestione della configurazione
1
DS10 - Gestione dei problemi
1
DS11 - Gestione dei dati
3
DS12 - Gestione dell’ambiente fisico
6
DS13 - Gestione delle operazioni
2
ME1 - Monitorare e valutare le prestazioni dell’IT
4
ME2 - Monitorare e valutare i controlli interni
4
ME3 - Assicurare la conformità a leggi e normative esterne
3
ME4 - Istituzione dell’IT Governance
4
Sul sito ROSI http://rosi.clusit.it/ è disponibile la versione completa di questo medesimo elenco,
contenente le descrizioni precise di ogni processo, tutte le attività ed i criteri di controllo e lo spazio
da compilare per la raccolta dei dati.
La tabella viene proposta:
• come aiuto per una rapida, efficiente e sistematica ricerca delle aree di maggior criticità nelle
quali è auspicabile / necessario intervenire 8;
• per introdurre alcuni criteri che consentano di individuare la priorità dei singoli interventi;
• per introdurre alcuni criteri utili alla “vendita interna” degli interventi stessi.
Si suggerisce di utilizzarla nel seguente modo:
1. Scorrere la tabella (si consiglia di utilizzare la versione completa disponibile sul sito http://rosi.
clusit.it/) identificando le aree dove si ritiene necessario un intervento migliorativo;
2. Valutare in modo qualitativo (alto, medio, basso) l’entità (costi, impegni di risorse, impatti)
dell’intervento ipotizzato;
3. Valutare i tempi entro i quali l’intervento diviene efficace;
4. Valutare il grado di autonomia dell’azienda nell’area o se si debba ricorrere a risorse / competenze esterne;
5. Indicare se nell’area sono in corso altri progetti: i costi del progetto in questione potrebbero
essere significativamente ridotti;
8
6. Quale aspetto del business viene positivamente impattato: Economico, Clientela, Ambiente
interno, Competitività aziendale? Questa considerazione potrà aiutare ad individuare, all’interno dell’azienda, i responsabili potenzialmente più interessati al progetto, e quindi favorevoli e
disposti a supportarlo. Questo punto viene descritto in maggior dettaglio alla sezione 3.6.2;
7. L’intervento è associabile ad altri interventi consentendo economie di scala?;
8. Si inseriscano altre considerazioni / parametri che si ritengano utili ad un confronto tra i vari
interventi (ad esempio: intervento strutturale o intervento tampone ?).
15
Per chi volesse
approfondire la
conoscenza e l’utilizzo
del framework CobiT,
ricordiamo che propone
metodi di autovalutazione
per verificare quanto i
vari processi siano erogati
in modo adeguato alle
specifiche esigenze,
mettendo in risalto le
aree di miglioramento.
Il framework medesimo
propone inoltre un
ulteriore livello di dettaglio
delle attività/controlli con
le cosiddette “Pratiche di
Controllo”
versione 2.0
3.3 Approccio Top-Down – Identificazione scenari di intervento
Definiti i processi per la gestione della sicurezza e identificati i processi IT che contribuiscono alla
sicurezza del SI dobbiamo, a questo punto, valutare se e come intervenire per mantenere un livello
di sicurezza adeguato al contesto in continua evoluzione (business, minacce, tecnologie, ecc) in
cui opera l’azienda.
Come è noto, gli interventi di sicurezza possono essere di tipo organizzativo, tecnologico o misto in
funzione della problematica che vanno ad indirizzare. In tutti i casi è fondamentale che gli interventi siano individuati attraverso un processo solido e comprensibile per il management.
Una delle principali cause di difficoltà nel giustificare una soluzione di sicurezza è da ricercarsi
proprio nella non sostenibilità del metodo che ha condotto alla scelta della stessa, e non tanto nella
soluzione in sè o nell’entità dell’investimento richiesto.
Il responsabile della sicurezza deve quindi far proprio un approccio in grado di porlo nelle condizioni di illustrare con chiare argomentazioni quantitative e qualitative l’adeguatezza degli interventi
di sicurezza da porre in essere.
Anche in questo caso le Best Practice e gli standard in materia ci vengono in aiuto.
Relativamente al miglioramento dei processi di sicurezza, gli aspetti disponibili in letteratura per la
sua loro valutazione sono i seguenti:
1 Sensibilizzazione e capacità di comunicare.
2 Policy, piani e procedure.
3 Strumenti ed automazione.
4 Competenza ed esperienza.
5 Definizione delle responsabilità.
6 Definizione e misura degli obiettivi.
Esistono in merito tecniche molto evolute e sofisticate che, tramite un’autovalutazione, consentono
di individuare quale sia, in una certa area / processo, la carenza più critica.
Pur mantenendosi nei limiti del presente documento, è opportuna una riflessione: i risultati ottimali in genere si ottengono se i sei elementi sono ragionevolmente tra loro bilanciati.
Un contributo interessante all’identificazione di eventuali punti di miglioramento nei processi di
sicurezza in essere può arrivare da una attività di analisi del loro grado di maturità secondo i criteri
di valutazione tipici del Capability Maturity Model elaborato dall’IT Governance Institute 9.
Il modello, infatti, consente un immediato confronto tra la situazione attuale e la situazione a tendere, potenzialmente rappresentata dal livello di maturità successivo a quello nel quale il singolo
processo risulta posizionato.
I livelli di maturità individuati dal Capability Maturity Model sono:
• Non existent: il processo descritto non esiste;
• Initial: il processo descritto è stato svolto. Lo svolgimento è dipeso dalla competenza specifica
di chi lo ha curato. La replica del processo richiede la disponibilità della stessa risorsa;
9
Si veda per riferimento
il sito ufficiale http://www.
sei.cmu.edu/cmmi/start/.
Può essere utile anche
la trattazione generale
disponibile su Wikipedia:
http://it.wikipedia.org/
wiki/Capability_Maturity_
Model.
• Repeatable: il processo descritto è stato svolto e sono state documentate le risultanze di tale
lavoro. Sulla base di tale documentazione un soggetto diverso può ripetere il processo rispettandone gli stessi passi logici e di documentazione;
• Defined: il processo descritto è stato svolto applicando le istruzioni scritte circa le modalità
di esecuzione. Del processo sono pertanto disponibili il metodo da seguire e l’evidenza dei
risultati;
16
3. Metodo
• Managed: il processo descritto è stato svolto applicando le istruzioni scritte circa le modalità
di esecuzione. Le istruzioni prescrivono che del processo siano effettuate misure quantitative
del progresso e dei risultati ottenuti in un periodo definito di tempo;
• Optimized: il processo descritto è stato svolto applicando le istruzioni scritte circa le modalità
di esecuzione. Le misurazioni effettuate del processo nei vari momenti di esecuzione danno
luogo a una valutazione comparativa e di bilanciamento tra costi del processo e benefici ottenuti, in ottica di miglioramento continuo.
Si precisa che la condizione minima affinché un processo di sicurezza possa definirsi tale è che
di esso si possano indicare con chiarezza l’owner, l’obiettivo di protezione assegnato e gli obiettivi
di controllo da rispettare.
Si osserva che, seppure fattibile (in modo intuitivo nel caso Defined o in modo sistematico nei casi
Managed e/o Optimized), l’evoluzione della qualità dei processi di sicurezza è tanto più realisticamente ottenibile quanto più i processi di sicurezza medesimi sono valutati ai livelli di maturità
Managed o Optimized e non semplicemente al livello Defined.
Ciò è implicito nel fatto che la sicurezza è pianificata e governata da un approccio basato sulla
gestione del rischio, il quale presuppone che di ogni processo di sicurezza sia disponibile un
feedback.
Al contrario, la predominanza di processi valutati allo stadio Non existent, Initial e Repeatable
indica una copertura parziale e poco strutturata degli aspetti di sicurezza, dipendente dall’abilità
professionale dei soggetti dedicati, poco allineata con gli obiettivi di business ed esposta a una
progressiva perdita di efficacia.
3.3.1 Gestione del rischio
Riguardo l’individuazione degli interventi da porre in essere per tutelare RIDC lo standard ISO/IEC
27001:2005 raccomanda di ricorrere ad un approccio basato sulla gestione del rischio.
In particolare, lo standard ISO/IEC 27005:2008 definisce le linee guida per la gestione dei rischi
correlati alla sicurezza informatica.
Il processo di Risk Management proposto dall’ISO/IEC 27005 prevede un approccio iterativo basato, fondamentalmente, su 6 macro-attività:
• Context Establishment;
• Risk Identification;
• Risk Estimation;
• Risk Evaluation;
• Risk Treatment;
• Risk Acceptance.
Un processo di Risk Management consente di valutare l’esposizione al rischio degli asset aziendali; fornisce i criteri per l’identificazione della modalità di gestione del rischio rilevato; fornisce gli
elementi per l’individuazione puntuale degli interventi di sicurezza da porre in essere per ridurre il
rischio; consente di attribuire la giusta priorità agli interventi individuati. Tale processo assume ancora più rilevanza prendendo in considerazione i risultati di alcuni studi (nel box un estratto dalla
IT Business Balance Survey 2011 di Deloitte) che indicano come la reale consapevolezza di quali
incidenti realmente accadano nelle organizzazioni sia ancora assai carente, e di conseguenza
come sia fuorviata la percezione del reale rischio da parte del management.
17
�
�
�
�
�
�
�
�
�
�
�
��
�
�
Inoltre, richiedendo il coinvolgimento dei referenti di business in specifici
��
passi d’analisi per la valutazione dell’esposizione al rischio di un processo di
��
��
business, contribuisce in maniera sensibile alla diffusione in azienda della
��
��
��
��
��
��
��
��
��
��
��
��
�� !�� "��
��
�
�
�
versione 2.0
Figura 5 - Estratto
dalla IT Survey
Deloitte 2011
cultura sulla sicurezza.
Molto spesso, infatti, la piena consapevolezza in azienda circa l’importanza
di proteggere la RIDC di un asset prende corpo solo al termine della Business Impact Analysis, ovvero dopo che l’azienda è stata chiamata a valutare
i possibili impatti (economico, legislativo, d’immagine, ecc.) che la compromissione di uno o più criteri di sicurezza (RIDC) per un determinato asset
causerebbe all’azienda.
A questo proposito, sempre per favorire la consapevolezza di quanti e quali
siano gli incidenti possibili, e quali le loro (anche gravi) conseguenze – proprio perché a volte si fa fatica ad immaginare quanto la realtà possa superare le nostre anche più ardite supposizioni – rimandiamo all’interessante
documento di Riccardo Scalici “Il Panorama dei rischi”, disponibile sul sito del Clusit alla sezione
“Assicurazioni” 10. Questo documento, frutto dell’esperienza dell’autore nel settore assicurativo,
�
riporta numerosi casi realmente accaduti, nei quali, con un minimo sforzo, ci si può riconoscere,
facilitando di molto il lavoro di chi deve presentare un ROSI su casi che altrimenti potrebbero
sembrare assai lontani.
3.3.2 Output del processo di gestione del rischio
Al termine del processo di Risk Management il responsabile della sicurezza ha a disposizione
l’insieme delle informazioni che gli consentono di identificare:
• la strategia di gestione dei rischi da attuare, tra quelle riportate in Tabella 2;
• gli obiettivi di controllo che consentono di ridurre o mitigare il rischio rilevato, con il supporto
dello standard ISO/IEC 27001;
• i controlli da porre in essere per soddisfare gli obiettivi di controllo definiti, con il supporto
dello standard ISO/IEC 27002 Code of Practice;
• le contromisure organizzative e/o tecnologiche che consentono di attuare i controlli identificati. Tali contromisure potranno fornire protezione su diversi fronti:
- ridurre le minacce;
- ridurre le vulnerabilità;
- ridurre l’impatto;
- rilevare una minaccia (contromisura applicabile solo in ambito preventivo).
Tabella 2 - Strategie
di gestione del rischio
(fonte Gartner)
Action
Description
Accept the Risk
When the risk is so unlikely or its impact so low that it warrants no
further action, the company can decide to simply bear the cost of
recovery if the need arises.
Avoid the Risk
When the cost and likelihood of the risk are large, it may no longer
be feasible to continue operation in the area of activity that incurs
the risk.
10
Il documento è
scaricabile dal link
http://www.clusit.it/docs/
rscalici_11-01-24.pdf.
18
3. Metodo
Action
Description
Transfer or Share the When the risk is part of the business — but the cost is predictable —
Risk
the company may share or transfer risk through insurance, contracts
and warranties, and joint-venture agreements. The cost of those penalties belong entirely to the delivery service.
Reduce or Mitigate Often, risk must be borne for a core function of the business; howethe Risk
ver, systems and controls will be needed to mitigate or reduce either
the likelihood or the impact of the risk
Ignore the Risk
It is very dangerous for executives to do nothing — neither consciously accepting the risk nor mitigating it.
A questo punto, dopo aver individuato un certo numero di aree di miglioramento, ed identificato
per ciascuna di esse gli interventi da porre in essere, poiché generalmente le aree di miglioramento sono numerose mentre le risorse disponibili (economiche, persone, ecc.) sono limitate, è
necessario definire delle priorità.
Purtroppo non è possibile qui entrare nel dettaglio delle modalità con cui assegnare le priorità
in modo oggettivo e basato unicamente sui fatti. Ai fini pratici, tuttavia, importa soltanto che una
priorità sia assegnata, anche arbitrariamente, in modo che sia possibile ordinare gli interventi nel
tempo, assegnare le risorse, e così via.
3.4 Approccio Verify – Identificazione Pattern
Nel caso in cui sia già stata definita una soluzione di sicurezza per la risoluzione di una determinata problematica e si debba dimostrare al management il ritorno dell’investimento che si propone,
è possibile adottare un approccio “bottom-up”, che chiamiamo Verify, il quale si basa su un modello di riferimento finalizzato alla valutazione dei potenziali benefici ottenibili dall’adozione della
soluzione.
Questo modello è naturalmente arbitrario, e nulla vieta che faccia riferimento a specifiche tecnologie che già si ritengono promettenti, soprattutto laddove (come nell’impresa privata) non vi è il
prerequisito necessario di neutralità rispetto ai potenziali fornitori.
Di seguito si riporta un possibile approccio di riferimento che può essere utilizzato per descrivere
la necessità di un investimento in sicurezza considerato già noto e definito per diverse motivazioni
(es. imposizione normativa, risoluzione di una vulnerabilità significativa, ecc.) e giustificarne, in
modo strutturato, l’adozione nei confronti del management, individuando anche i potenziali ritorni,
qualitativi e quantitativi, ottenibili.
Si riportano pertanto le modalità di definizione di un pattern e alcune schede esemplificative, che
possono essere utilizzate come riferimento per la rappresentazione delle soluzioni di sicurezza da
sottoporre al management per autorizzazione all’investimento.
3.5 Approccio Verify – Predisposizione Pattern
Per presentare un pattern in maniera coerente e riproducibile, è indispensabile seguire uno schema, che può naturalmente essere arbitrario, ma che è a priori di difficile costruzione.
Si riporta quindi nel seguito una possibile modalità di rappresentazione schematica per la stesura
di un pattern, che potrà essere successivamente utilizzata a supporto del documento di presenta19
versione 2.0
zione al management per ottenere l’approvazione dell’investimento (vedi sezione 4 - “Documento
ROSI”).
Al capitolo 5 “Esempi di pattern” si riportano degli esempi costruiti dal GdL e da altri contributori.
Tabella 3 - Schema di
Pattern
PATTERN
Indicazione del nome del pattern
AREA DI INTERVENTO
Riferimento agli obiettivi di controllo dello standard ISO27001
SINTESI
Criteri di Sicurezza
£
Risorse Impattate
£
Infrastruttura £ Risorse Umane £ Applicazioni £ Informazioni
Driver di Business
£
Rischi operativi £ Compliance £ Immagine aziendale £ Efficienza processi
Conformità £ Riservatezza £ Integrita` £ Disponibilita`
CONTESTO DI RIFERIMENTO
Descrizione dell’ambito di applicazione del pattern
DESCRIZIONE
Descrizione della soluzione di sicurezza per la quale si propone l’investimento
DRIVER / MOTIVAZIONI
Indicazione dei driver e delle motivazioni che inducono ad effettuare l’investimento
PUNTI DI ATTENZIONE
Indicazione di criticità/punti di attenzione correlati all’investimento
ELEMENTI DI VALUTAZIONE
Descrizione degli elementi quantitativi e qualitativi da considerare per la stima del ritorno dell’investimento
BENEFICI / VANTAGGI
Descrizione dei benefici quantitativi e dei vantaggi qualitativi ottenibili dall’investimento
Di seguito si descrivono analiticamente gli elementi riportati nella scheda, per un suo utilizzo più
agevole e coerente con gli obiettivi prefissati.
3.5.1 Pattern
Identifica la soluzione di sicurezza oggetto dell’investimento da valutare, che può essere di tipo
puramente tecnologico, organizzativa o un mix di entrambe. Può pertanto far riferimento sia a
progetti complessi e trasversali a più funzioni aziendali (es. Identity & Access Management), come
a soluzioni tecniche specifiche per la risoluzione di un determinato problema (es. cifratura dei dati
dei PC del management).
3.5.2 Area di intervento
Al fine di uniformare le soluzioni di sicurezza individuate alle best practice nell’ambito dell’information security, si propone di ricondurre l’analisi ad aree di intervento già delineate dagli standard
internazionali quali lo standard ISO/IEC 27001:2005, che definisce i requisiti essenziali per costituire un sistema di gestione della sicurezza delle informazioni.
Lo standard ISO27001 definisce gli obiettivi di controllo ed i controlli di sicurezza, raggruppandoli
secondo undici categorie:
• Security Policy
• Organizing Information Security
• Asset Management
• Human Resources Security
• Physical and Environmental Security
• Communications and Operations Management
• Access Control
20
3. Metodo
• Information Systems Acquisition, Development and Maintenance
• Information Security Incident Management
• Business Continuity Management
• Compliance
L’allegato A dello standard riporta per ognuna delle categorie sopra citate gli obiettivi di controllo
ed i relativi controlli atti a garantire la sicurezza delle informazioni, secondo una logica gerarchica
come quella sotto riportata a titolo esemplificativo per la categoria Asset Management:
A 7 – Asset Management
A 7.1 – Responsibility for assets
A 7.1.1. – Inventory of assets
A 7.1.2 – Ownership of assets
A 7.1.3 – Acceptable use of assets
A 7.2 – Information classification
A 7.2.1. – Classification guidelines
A 7.2.2. – Information labelling and handling
Per l’attuazione dei controlli indicati è possibile far riferimento allo standard ISO27002:2005 che
fornisce, per ogni controllo, linee guida di implementazione e altre informazioni utili per la protezione delle informazioni.
Pertanto nella scheda è opportuno indicare il riferimento agli obiettivi di controllo ed ai singoli
controlli con profondità di dettaglio variabile a seconda che la soluzione proposta sia specifica per
un determinato controllo (es. 7.1.3) piuttosto che si riferisca ad uno o più ambiti di controllo (es.
7.1, 7.2, ecc.).
3.5.3 Criteri di sicurezza
In tale sezione della scheda si riportano in sintesi i criteri di sicurezza impattati dalla soluzione
proposta, classificati come segue:
• Riservatezza: capacità della soluzione di proteggere la confidenzialità delle informazioni da
possibili accessi non autorizzati
• Integrità: capacità della soluzione di garantire l’accuratezza e completezza delle informazioni
ed evitarne la modifica non autorizzata
• Disponibilità: capacità della soluzione di garantire la disponibilità delle informazioni quando
richieste dai processi aziendali
• Conformità: capacità della soluzione di garantire la conformità ai requisiti derivanti da normative esterne, regolamenti, accordi contrattuali e/o policy e procedure interne
Al fine di individuare i criteri di sicurezza impattati dall’adozione della soluzione, si riporta in Appendice B un utile strumento di supporto, che riporta non solo la suddivisione di obiettivi di controllo in controlli e sottocontrolli, ma anche l’efficacia della loro implementazione rispetto ai criteri
di sicurezza di riservatezza, integrità, disponibilità e conformità.
Una volta individuata l’area di intervento con riferimento allo standard ISO27001, lo strumento
permette di analizzare l’efficacia di ogni obiettivo di controllo verso i criteri di sicurezza, espressa in
termini di riduzione di probabilità e impatto che l’adozione delle soluzioni di sicurezza richiamate
avrebbero su tali parametri.
21
versione 2.0
Le scale di valutazione per la riduzione della probabilità e dell’impatto variano da 1 a 5. Per ogni
obiettivo di controllo è possibile individuare il criterio di sicurezza maggiormente impattato verificando i valori indicati in tabella: maggiore è il valore riportato, maggiore è l’efficacia della soluzione
per quel criterio di sicurezza.
Figura 6 - Estratto
tabella efficacia
controlli (Appendice B
da http://rosi.clusit.it/)
3.5.4 Risorse impattate
Si riportano in sintesi in questa sezione della scheda le risorse impattate dall’implementazione della soluzione di sicurezza che si vuol proporre, classificati come segue, con riferimento a framework
consolidati di controllo dell’Information Technology quali CobiT:
• Applicazioni: sistemi informativi che elaborano le informazioni aziendali.
• Informazioni: dati inseriti, prodotti ed elaborati dai sistemi informativi in qualunque forma
utilizzata dall’azienda.
• Infrastruttura: tecnologie, strumenti ed ambiente che li ospita, che consentono il funzionamento delle applicazioni.
• Risorse Umane: personale richiesto per gestire i sistemi informativi ed i servizi erogati.
3.5.5 Driver di business
Si riportano in sintesi in questa sezione della scheda i driver di business che motivano l’adozione
della soluzione, classificati come segue:
• Rischi operativi: la soluzione proposta permette di ridurre il livello di rischio operativo legato
alla gestione dell’Information Technology.
• Compliance: la soluzione permette di rispondere a requisiti imposti da normative, il cui mancato adempimento può comportare delle sanzioni.
• Immagine aziendale: la soluzione permette di ridurre il rischio di un impatto negativo sull’immagine aziendale.
• Efficienza processi: la soluzione proposta permette un efficientamento nella gestione dell’Information Technology e nei processi di business, consentendo anche una riduzione di tempi
e costi nell’esecuzione delle attività.
22
3. Metodo
Si rimanda alla sezione 3.6 - “Identificazione Business Drivers e Metriche di sicurezza” per ulteriori approfondimenti in merito.
3.5.6 Contesto di riferimento
In questa sezione della scheda si riporta lo scenario di riferimento in cui si innesta la soluzione
di sicurezza proposta, indicando il contesto esterno (di business, normativo, tecnologico, sociale,
ecc.) o interno all’azienda (tecnico, organizzativo, ecc.) che richiede l’implementazione di una
soluzione di sicurezza in risposta ai bisogni emersi.
A tal proposito può essere utile far riferimento anche a ricerche di mercato, survey, studi di settore,
ecc. come elemento di confronto della propria situazione rispetto alle best practice di mercato e/o
aziende comparabili per dimensioni o settore industriale di riferimento.
3.5.7 Descrizione
Si descrive in sintesi l’obiettivo che la soluzione di sicurezza si propone di raggiungere ed i principali elementi attuativi che possono essere di natura tecnologica, organizzativa, procedurale, ecc.
in base al tipo di soluzione.
Le modalità ed il dettaglio della descrizione della soluzione devono essere di livello adeguato e di
facile comprensione per il management aziendale che deve approvare l’intervento, pertanto la descrizione può variare notevolmente se il manager interessato appartiene alla funzione Information
Technology, piuttosto che ad una funzione di business.
È opportuno comunque predisporre un documento più tecnico e dettagliato, che può essere riportato in allegato alla scheda e risultare di supporto anche nella fase di rappresentazione del pattern
al management e nelle successive fasi di monitoraggio dell’efficacia della soluzione.
3.5.8 Driver/motivazioni
In questa sezione di descrivono più in dettaglio i driver e le motivazioni che richiedono l’investimento nella soluzione di sicurezza proposta, già indicati in sintesi all’inizio della scheda.
Nel modello proposto i driver che possono spingere ad un investimento in sicurezza sono stati
ricondotti fondamentalmente alle seguenti necessità:
• ridurre i rischi operativi;
• garantire la conformità alle normative;
• salvaguardare l’immagine aziendale;
• consentire maggior efficienza nell’esecuzione dei processi aziendali.
La definizione dei driver che guidano la realizzazione della soluzione risulta utile anche ai fini
dell’individuazione degli stakeholder che in azienda sono maggiormente interessati dai benefici
ottenibili dalla soluzione e sui quali pertanto focalizzarsi per sponsorizzare l’adozione della soluzione ed ottenerne l’approvazione.
Si rimanda alla sezione 3.6 - “Identificazione Business Drivers e Metriche di sicurezza” per ulteriori approfondimenti in merito.
3.5.9 Punti di attenzione
È opportuno indicare, oltre alle motivazioni ed ai benefici ottenibili dalla soluzione di sicurezza
individuata, anche eventuali punti di attenzione ed elementi da considerare per l’implementazione
della stessa, al fine di garantire l’efficacia nel raggiungimento degli obiettivi prefissati.
23
versione 2.0
In tal senso devono essere indicati i fattori critici di successo relativi all’implementazione e gestione
della soluzione proposta, nonché eventuali condizioni al contorno necessarie per il soddisfacimento degli obiettivi.
Pertanto si riportano tutti gli aspetti da tenere in considerazione, facendo riferimento alle proprie
esperienze personali, alla documentazione presente in letteratura, al punto di vista di analisti ed
esperti in materia, nonché alle caratteristiche intrinseche della soluzione stessa.
3.5.10 Elementi di valutazione
In questa sezione si riportano gli elementi di valutazione che sono presi in considerazione, sulla
base dei driver di business e dei vantaggi ottenibili dall’investimento, per determinare da un lato
i costi della soluzione e dall’altro i ritorni, laddove possibile in termini economici, derivanti dalla
realizzazione della stessa.
Questa valutazione non solo è necessaria per lo scopo di individuare il ritorno dell’investimento,
ma ritorna utile anche per la misurazione del ritorno atteso una volta implementata la soluzione e
per l’identificazione di eventuali correttivi.
Relativamente alla quantificazione dei costi, è importante descrivere tutti gli esborsi che dovranno
essere sostenuti per l’implementazione della soluzione adottata, tenendo in considerazione quindi
costi diretti ed indiretti che la soluzione comporta, costi fissi e variabili, nonché i costi operativi di
gestione ed investimenti in conto capitale collegati alla soluzione proposta.
La quantificazione del ritorno dell’investimento è invece determinata in buona parte dalla connotazione tecnica ed organizzativa della tecnologia che si propone e dai driver che ne spingono
l’adozione.
Specifiche soluzioni tecniche attivate per rendere efficienti i processi aziendali consentono una
maggior possibilità di quantificare i benefici della soluzione (tipicamente espressi in risparmio di
costi o aumento di produttività) e quindi evidenziare il ritorno dell’investimento in una tipica ottica
economico-finanziaria più comprensibile al management aziendale che deve, in ultima istanza,
approvare la proposta.
Analogamente, per soluzioni mirate a ridurre i rischi operativi, i benefici possono essere quantificati
in termini di potenziale impatto derivante dall’accadimento dell’evento di rischio (vedi ad esempio
potenziali frodi, furti, ecc.), arrivando in taluni casi anche alla determinazione delle perdite attese
ed individuando i costi legati a premi assicurativi da pagare per far fronte ai potenziali danni.
Al contrario soluzioni organizzative, quali a titolo di esempio attività di sensibilizzazione e formazione del personale sulla sicurezza delle informazioni, avviate in risposta ad esigenze normative o per
migliorare l’immagine aziendale, consentono in misura ridotta una quantificazione del beneficio
ottenibile. Anche per queste situazioni, tuttavia, possono essere trovati indicatori economici di
riferimento, come ad esempio l’importo delle potenziali sanzioni previste in caso di inadempimenti
normativi o i maggiori costi in pubblicità da affrontare per riportare l’immagine aziendale ai valori
antecedenti la sua compromissione.
3.5.11 Benefici/vantaggi
Questa sezione rappresenta la conclusione delle analisi svolte e delle valutazioni effettuate, in
quanto riporta l’evidenza del ritorno dell’investimento proposto.
Si indicano quindi i potenziali benefici e vantaggi ottenibili dall’adozione della soluzione di sicurezza, che potranno essere di natura qualitativa o quantitativa in base ai driver che hanno guidato la
definizione della soluzione ed alla possibilità di tradurre in termini monetari il beneficio atteso, al
24
3. Metodo
fine di valutare la convenienza economica rispetto ai costi da sostenere per la realizzazione della
soluzione.
Oltre all’individuazione dei possibili vantaggi in termini qualitativi e/o quantitativi che la soluzione
proposta può portare, è possibile far riferimento al beneficio ottenibile in termini di riduzione dei
rischi, analisi utile in particolare in alcuni contesti regolamentati dove è forte l’esigenza di mitigare
i rischi operativi e limitare di conseguenza le riserve allocate per fronteggiare il loro accadimento.
A tal fine si può far riferimento ad un elenco non esaustivo di rischi in ambito IT derivante dai
framework di controllo dell’Information Technology quali CobiT.
3.6 Identificazione Business Drivers e Metriche di sicurezza
Attribuita la giusta priorità agli interventi (approccio Top-Down) o ultimata la predisposizione del
Pattern (approccio Verify) non resta che identificare tutti gli elementi che concorrono alla valutazione del ritorno sull’investimento in sicurezza.
Il ROSI deve porre il management nelle condizioni di effettuare una valutazione dell’investimento
in sicurezza supportata non solo da considerazioni legate ai costi correlati al rischio e alla probabilità di accadimento di una minaccia, ma anche dall’insieme dei benefici, quantitativi e qualitativi,
che l’intervento di sicurezza può portare all’azienda anche in ambito business.
3.6.1 Individuazione delle motivazioni operative (business drivers)
Individuare e valutare il ROSI significa, quindi, sommare ai vantaggi qualitativi e prospettici tipici
della sicurezza i vantaggi quantitativi e qualitativi che l’intervento di sicurezza può apportare al
business aziendale: i cosiddetti business drivers.
I principali ambiti aziendali per cui il responsabile della sicurezza deve individuare i business
drivers sono:
• Rischi operativi: l’intervento permette di ridurre il livello di rischio operativo legato alla gestione
dell’Information Technology ?
• Compliance: l’intervento risponde a requisiti cogenti, il cui mancato adempimento può comportare delle sanzioni amministrative e/o penali ?
• Immagine aziendale: l’intervento permette di tutelare l’immagine aziendale e/o migliorare l’immagine dell’azienda sul mercato / verso clienti e fornitori ?
• Efficienza processi: l’intervento consente di incrementare l’efficienza dei processi di gestione
dell’IT, della sicurezza e/o dei processi di business, consentendo una riduzione di tempi e
costi nell’esecuzione delle attività?
3.6.2 Identificazione degli stakeholder
Individuati i business drivers, il passaggio successivo sarà quello di coinvolgere, in qualità di sponsor dell’iniziativa, i cosiddetti stakeholder, ovvero le persone che nell’organizzazione – per ruolo più
che per inclinazioni personali – sono più sensibili alle tematiche oggetto dell’azione.
Tipicamente i principali responsabili che si occupano degli ambiti sopra indicati sono:
• Risk Manager, per i Rischi operativi
• Compliance Manager, organi di controllo interno ed esterno, per la Compliance
• Marketing, per l’Immagine aziendale
• CFO, CEO e CIO, per l’Efficienza dei processi.
25
versione 2.0
Certamente in ciascuna organizzazione gli attori e le motivazioni di scelta possono essere diversi,
ma per non appesantire questo documento si è resa disponibile un’analisi più esaustiva di quali stakeholder potenzialmente coinvolgere in vari casi concreti nel documento “Identificazione
Stakeholder”, disponibile – come gli altri materiali che completano questo studio – sul sito ROSI
(http://rosi.clusit.it/).
3.6.3 Identificazione dei benefici e degli obiettivi
Una volta individuati tra i vari attori i potenziali stakeholder dell’iniziativa si rende necessario identificare, partendo da una valutazione della situazione in essere, i benefici salienti e gli obiettivi
primari che questi potranno trarre e/o traguardare in seguito all’implementazione della soluzione
di sicurezza in questione.
Benefici e obiettivi, infatti, costituiscono un ottimo strumento nelle mani del responsabile della
sicurezza per instaurare un dialogo proficuo sia con lo stakeholder, ai fini di un suo coinvolgimento
in qualità di sponsor dell’iniziativa di sicurezza, sia con il management, ai fini dell’ottenimento delle
risorse necessarie per l’attuazione dell’iniziativa stessa.
3.6.4 Identificazione delle metriche
A questo punto si può valutare l’opportunità di definire delle metriche di sicurezza aventi la finalità
di supportare il responsabile della sicurezza, lo stakeholder e il management nel successivo processo di valutazione dell’adeguatezza dell’iniziativa di sicurezza implementata rispetto agli obiettivi
predefiniti. La metrica, infatti, è uno strumento utilizzato per facilitare la presa di decisioni, migliorare le prestazioni e la responsabilità utilizzando la raccolta, l’analisi e la segnalazione di dati
‘misurati’ relativi alle prestazioni del sistema in esame.
Lo scopo della misurazione delle prestazioni è di controllare lo stato delle attività e facilitare il miglioramento delle attività stesse applicando azioni correttive dedotte dalle misure ottenute.
Le misure forniscono una fotografia in un dato istante temporale dei fattori specifici e discreti del
sistema, mentre la metrica è derivata confrontando due (o più) misure rilevate nel tempo con valori
base di riferimento.
Le misure sono generate contando, la metrica invece è generata dall’analisi delle misure. In altre
parole le misure sono dati grezzi oggettivi e la metrica è l’interpretazione umana oggettiva o soggettiva di quei dati.
Le metriche di sicurezza devono produrre informazioni quantificabili al fine di poterli analizzare
tramite formule e confrontare con valori di riferimento predefiniti. Comunemente vengono utilizzati
valori percentuali, medie e valori assoluti, dipendentemente dall’attività che si vuole misurare.
All’atto della definizione delle metriche di sicurezza si suggerisce di valutare l’opportunità di implementare un programma di metriche su due “livelli”:
• livello security; avente l’obiettivo di fornire al responsabile della sicurezza gli indicatori atti a
valutare l’efficacia delle contromisure attuate (es.: numero di infezioni da virus, numero di
tentativi di attacco alla propria infrastruttura, etc.);
• livello business; avente l’obiettivo di produrre indicatori di performance del business influenzati dalle contromisure attuate (es.: tempo di indisponibilità del processo di business, numero
di transazioni on-line non andate a buon fine, etc.)
Un aspetto importante da tenere in considerazione in fase di implementazione di una metrica è
che questa deve usare dati facilmente ottenibili per far sì che la difficoltà della misurazione non
26
3. Metodo
vanifichi lo scopo della misura, assorbendo troppe risorse che potrebbero essere destinate in altre
attività. Affinché una metrica sia efficace deve essere SMART, ovvero:
• Specifica;
• Misurabile;
• Attendibile;
• Ripetibile e
• Tempo-dipendente.
La metrica di sicurezza può essere utilizzata per misurare ogni funzione di sicurezza all’interno
dell’Organizzazione. Per esempio, i risultati di attività di risk assessment, penetration testing, test
sulla sicurezza ed altre attività correlate all’ambito della valutazione della sicurezza, possono essere quantificate e utilizzate come dato di partenza per la metrica stessa. Utilizzando i risultati ottenuti dall’analisi della metrica, i program manager ed i systems owners possono isolare i problemi
individuati, evidenziare le aree critiche che necessitano di miglioramenti e quindi giustificare gli
investimenti specifici per tali aree.
I vincoli fiscali e le condizioni di mercato costringono le organizzazioni ad operare con budget
ridotti; in tali circostanze è difficile giustificare grandi investimenti nell’ambito della sicurezza, ne
segue che generalmente sono valutati gli investimenti per le singole aree nelle quali sono stati individuati e dettagliati specifici limiti di sicurezza, ma finendo così per non attenuare adeguatamente
il rischio specifico complessivo.
L’uso di metriche di sicurezza permette all’Organizzazione di valutare le funzionalità ottenute dagli
investimenti effettuati e fornisce dati quantificabili utilizzabili come supporto per gli investimenti
futuri.
3.6.5 L’esempio dell’ IAM
A titolo di esempio si supponga che al termine del processo di risk management si sia evidenziata
Figura 7 - Motivazioni
la necessità di dotare l’azienda di un sistema di Identity and Access Management (IAM).
per progetti di IAM –
Semplificando, è possibile immaginare che l’intervento nasca dalla necessità di mitigare i rischi di
Fonte: Deloitte
accesso non autorizzato alle risorse informatiche dell’azienda.
��4��$�
Analizzando più attentamente
*��'��/��'��/��,��M
��-�/��M�'��
�--��0��0�
le funzionalità e le potenzialità
.!4
rendere conto che i business
ulteriormente l’adozione dello
IAM sono molteplici, come evidenziato dallo schema a fianco.
.�4
.��
di una soluzione IAM, ci si può
drivers che possono giustificare
E��1��(��
/��
��3��"��
$��/� ��/��
$��/��,��0�
��-'��'��+
��0��@��
."4
"��0��'��'��M��
!��#��
/��
>��
��-�00�0��'��/��'��
�6�$��00�
�6�\��'�/��5
��&��/#��-��00�3��
*�/�0��'��'��
.�4
Dallo schema si evidenzia di
come lo IAM possa trovare nel
CFO, nel CIO, nel CSO, nelle unità di business dei validi
sponsor.
Identificati i business drivers il
.��0��$�
��+��
"��,��+
��
��
E�
"��6��
G��0��@6��,��'��
"��00�0��/��'��L�3
#� ��00��0��
��@��4��'��
..4
+��C��
27
versione 2.0
responsabile della sicurezza, auspicabilmente con il supporto dello sponsor, può valutare e documentare la totalità dei ritorni quantitativi e qualitativi che deriverebbero dall’adozione della soluzione di sicurezza andando a completare l’analisi del ROSI.
3.7 Valutazione del ROSI
Negli ultimi anni sono stati effettuati numerosi tentativi per definire un metodo scientifico/matematico con cui calcolare i costi e ritorni degli investimenti in iniziative di sicurezza. Tale proliferazione,
che non ha ancora portato ad una comune accettazione di un criterio condiviso, è la testimonianza
delle difficoltà in cui versano gli addetti alla sicurezza.
Facendo esperienza di quando accaduto fino ad oggi, nei prossimi paragrafi è proposto un metodo
pratico per effettuare la valutazione del ROSI, senza utilizzare tuttavia un’unica formulazione matematica che pretenda di essere applicabile in tutti i casi e per tutte le realtà aziendali.
Il processo di identificazione e valutazione dei costi e dei ritorni recepisce l’approccio prodotto in tale ambito da parte dell’Information Security Forum (ISF), organizzazione internazionale,
indipendente e non-profit, con 300 membri fra i principali gruppi multinazionali mondiali (di
tutti i settori), enti pubblici e uffici governativi, che fornisce suggerimenti e guide autorevoli su
tutti gli aspetti dell’“Information Security” (per maggiorni informazioni consultare il sito internet
http://www.securityforum.org/).
La definizione dei processi di gestione e della classificazione dei costi, recepisce invece alcuni
aspetti definiti all’interno dell’ITIL (Information Technology Infrastructure Library) in particolare nel
processo IT Financial Management all’interno del libro Service Strategy.
La valutazione dei costi e dei ritorni per il calcolo del ROSI prevede l’identificazione e la misurazione di due principali tipologie di indicatori:
• Key Cost Indicator: indice utilizzato per misurare le prestazioni di processi ed utili a calcolare
il costo;
• Key Return Indicator: indice utilizzato per misurare le prestazioni di processi ed utili a calcolare il ritorno e a giustificare l’investimento in sicurezza.
Una volta individuati ed analizzati i possibili costi e ritorni impattati dalla soluzione oggetto dell’analisi, l’utilizzo dei KCI e dei KRI consente di sfruttare le metriche attualmente presenti in azienda o,
alternativamente, di individuare quali metriche implementare, al fine di poter calcolare il ROSI.
3.7.1 Approccio per il calcolo dei KCI e dei KRI
L’approccio può essere suddiviso nei seguenti step.
Figura 8 – Approccio
per il calcolo dei
KCI e dei KRI
28
3. Metodo
Come mostrato nella precedente figura, una volta individuati i costi ed i ritorni che impattano la
soluzione di sicurezza oggetto del ROSI, sono definiti gli indicatori di costo e di ritorno. Tali indicatori sono costituiti da metriche. Qualora le metriche siano già disponibili in azienda, è sufficiente
recepire le misurazioni al fine della valutazione degli indicatori.
Qualora invece non siano presenti le metriche desiderate per la valutazione degli indicatori, risulta
necessario impostare le nuove metriche. Qualora la misurazione delle metriche non richieda tempi
lunghi, è possibile recepire i risultati delle nuove metriche. Qualora invece non fosse possibile recepire le misurazioni delle metriche in azienda, potrebbero essere utilizzati benchmark di settore
o l’esperienza del security manager. Anche in questo caso, una volta recepite le misurazioni delle
metriche, è sufficiente valutare gli indicatori definiti in precedenza.
L’individuazione degli indicatori varia in base al tipo di soluzione da adottare ed in base al contesto
di applicazione. Maggiore sarà la maturità dell’azienda in ambito sicurezza delle informazioni,
maggiori saranno le metriche disponibili per calcolo degli indicatori e più preciso sarà il calcolo
del ROSI.
Tuttavia, la possibilità di utilizzare metriche condivise, consente di sfruttare informazioni già presenti presso altri contesti o, in ultima analisi, l’esperienza del security manager, rendendo l’utilizzo
degli indicatori applicabile anche in contesti con una non elevata maturità in ambito sicurezza
delle informazioni.
3.7.2 Costi
Prima di effettuare la valutazione dei costi che impattano il ROSI, è necessario comprendere quali
attività siano richieste per un’efficiente gestione economica del comparto IT. Tale comprensione
può essere utile a comprendere il punto di vista di alcuni interlocutori aziendali attivi nel processo
di approvazione dell’investimento richiesto.
Come definito nell’articolo “IT Financial Management: The Business of IT” 11 la gestione delle
risorse economiche in ambito IT può avvenire sulla base di tre sottoprocessi:
• Budgeting: è il processo in cui si prevedono e si controllano le spese dell’organizzazione e
consiste di periodici cicli di negoziazione (di solito annualmente) per fissare gli importi e di un
quotidiano monitoraggio del budget corrente. Un corretto processo di Budgeting consente di
valutare e ordinare secondo priorità quali iniziative di sicurezza considerare durante l’anno.
• Accounting: è l’insieme di processi che permette all’organizzazione IT di gestire in maniera
completa la modalità con cui sono spesi i budget. In particolare identifica i costi, servizi, attività e centri di costo. Solitamente coinvolge libri contabili ed è supervisionato da personale con
competenze in contabilità aziendale. Ad esempio un’iniziativa di sicurezza come l’implementazione di una soluzione di Identity Management, deve necessariamente essere suddivisa su
diversi centri di costo, appartenenti a chi beneficia dell’implementazione di tale soluzione (i.e.
non solo la Funzione IT, ma anche Organizzazione, Risorse Umane, Compliance, Business
Unit interessate, ecc.)
• Charging: è l’insieme dei processi che consente di addebitare i costi per i servizi erogati al
cliente. Condizione necessaria per un corretto processo di Charging è una buona esecuzione
del processo di Accounting. In particolare maggiore è il dettaglio di analisi, addebiti e in generale dei report di accounting, maggiore sarà la precisione del processo di Charging.
Differenti modalità di pagamento verso i fornitori, potrebbero favorire la scelta di una soluzione di sicurezza rispetto ad un’altra (i.e. il pagamento di un prodotto con licensing annuale potrebbe essere preferito all’acquisto di un prodotto che richieda un pagamento una-tantum).
29
11
Robert Ryan,
Tim Raducha-Grace;
14 Ottobre 2009
versione 2.0
I costi connessi ad iniziative di sicurezza, come qualsiasi altro costo, possono essere categorizzati
in svariati modi: possono essere diretti o indiretti; contemporaneamente possono essere fissi o
variabili, ed ancora in conto capitale o operativi.
Diretti/Indiretti
Per costo diretto si intende un costo imputabile in maniera certa ed univoca ad un solo centro di
costo (prodotto, reparto, stabilimento, ecc.) e che, di conseguenza, può essere attribuito unicamente ad esso nelle analisi dei costi. Ad esempio: l’acquisto di una nuova linea di montaggio per
uno stabilimento è un costo diretto per il centro di costo di quello stabilimento.
I costi indiretti invece sono riconducibili a due o più centri di costo; per questa classe di costi
manca una relazione specifica con il centro di costo considerato. Si tratta ad esempio dei costi
delle funzioni generali come amministrazione e contabilità, segreteria, direzione, dei costi dei servizi ausiliari come le spese di manutenzione, di gestione del magazzino, di pulizia. I costi indiretti
possono essere allocati quindi sui vari centri di costo da cui scaturiscono, e la ripartizione deve
necessariamente considerare la causa che ha originato tali costi.
L’implementazione di una soluzione di Identity Management per esempio, potrebbe essere valutata come costo diretto, imputandone una parte dei costi, per la Funzione IT, ma per l’altra parte,
visto il beneficio per tutta l’azienda, come costo indiretto per altre Business Unit, ripartendo su tali
entità i costi restanti in parti uguali.
Fissi/Variabili
I costi fissi sono costi che non variano al crescere del volume di output. Il comportamento di tali
costi è quindi indipendente dai livelli di produzione o dal numero di utenti o dal numero di incidenti accaduti. Tipici esempi di costi fissi sono le licenze software, canoni di manutenzione ordinaria,
canoni di telefonia, ecc. .
I costi variabili sono costi proporzionali ai livelli di output. Questa tipologia di costi quindi non esiste in assenza di produzione. Esempio principale di costi variabili sono le consulenze esterne, la
manutenzione straordinaria, ecc..
Capital/Operational
Con Capital Cost (ovvero spese per capitale o CAPEX), si intendono le spese che l’azienda sostiene per effettuare investimenti a lunga durata. Si tratta prevalentemente di investimenti in conto
capitale che dovrebbero permettere all’azienda di espandere o migliorare la propria capacità produttiva. Esempi di tali costi sono l’acquisto dei server, l’implementazione o l’aggiornamento di un
sistema, ecc..
Gli Operational Cost (ovvero costo operativi o OPEX) si intendono i costi per la gestione dei sistemi
o del business, utili al mantenimento degli beni tangibili o intangibili dell’azienda. Esempi di costi
operativi sono le licenze software, costo del lavoro, manutenzione non evolutiva, costi per le consulenze esterne straordinarie, ecc. .
3.7.3 I costi per il ROSI
Le indicazioni sui processi di gestione e sulla classificazione dei costi suggerite nei paragrafi precedenti, potrebbero supportare l’identificazione e la corretta allocazione dei costi di iniziative di
sicurezza. Nel presente paragrafo sono elencati i principali costi relativi all’Information Security.
Come suggerito nel report “ROSI – Return on Security Investments” pubblicato dall’ISF, tali costi
30
3. Metodo
possono essere raggruppati in due macro categorie: costi legati alle misura di sicurezza e costi
legati ad incidenti.
I costi delle misure di sicurezza sono principalmente dovuti all’implementazione e alla verifica dei
controlli in ambito Information Security. Tali costi comprendono:
• progettazione, acquisto, implementazione e monitoraggio delle soluzioni;
• spese per l’acquisto di materiale hardware e/o software associato alle soluzioni di sicurezza;
• training per gli utenti;
• spese di consulenza esterne;
• spese generali (come ad esempio quelle legate alle facilities).
I costi relativi agli incidenti includono perdite finanziarie a seguito del verificarsi di uno o più incidenti. Tali costi includono principalmente:
• impatti sul business (diminuzione delle vendite, diminuzione della soddisfazione dei clienti,
perdita di reputazione/immagine, ecc.);
• il tempo richiesto per la gestione dell’incidente;
• spese per consulenze esterne;
• costi di ripristino dei sistemi per portare gli stessi nello stato precedente all’incidente.
La valutazione dei costi relativi agli incidenti solitamente si basa su analisi storiche, interne o esterne, che purtroppo non sono sempre di facile reperimento.
Il rapporto “2010 Global State of Information Security Survey (GISS)” (GISS 2010) è uno studio
mondiale condotto sulla base di una survey online tra aprile e giugno 2009, a cui hanno partecipato 7.276 rappresentanti aziendali dell’Information Security, in oltre 100 nazioni. Secondo tale
rapporto, redatto da CIO e CSO 12 in collaborazione con PricewaterhouseCoopers, uno dei motivi
principali per cui la sicurezza è diventata una priorità aziendale è legato ai rischi derivanti da incidenti di sicurezza.
Il report stima che per violazioni di questo tipo sono previste complessivamente perdite finanziare
per un valore medio di circa $833.000 (che sale a $911.000 per la realtà italiana) all’anno per
ogni singolo incidente.
Sempre secondo i risultati del GISS 2010, gli incidenti, per la maggior parte dei casi, hanno un
impatto legato a perdite finanziarie, perdite di immagine/reputazione e perdite di dati legati alla
proprietà intellettuale. Complessivamente la maggior parte degli incidenti sono causati dai propri
dipendenti per il 33% (7% per la realtà italiana), per il 26% da hacker (20% per la realtà italiana)
e per il 19% da ex dipendenti (2% per la realtà italiana).
3.7.4 Ritorni
I ritorni di iniziative di sicurezza, come risulta dal GISS 2010, sono molteplici e il calcolo del ritorno risulta complesso per sua natura, in quanto risulta necessario rendere comparabili grandezze
quantificabili e grandezze non quantificabili. (Figura 9)
Con l’implementazione di opportune misure di sicurezza le aziende acquisiscono la capacità di
proteggere la riservatezza, l’integrità e la disponibilità delle informazioni aziendali, riducendo la
probabilità che si verifichino incidenti legati a virus, attacchi via web, truffe, ecc.. Qualora invece
si verificasse comunque un incidente, l’implementazione di tali soluzioni potrebbero ridurre o
addirittura annullare l’impatto sul business in termini economici, diminuendo la durata del tempo
necessario alla risoluzione dell’incidente.
Inoltre l’implementazione dei controlli potrebbe supportare la società nel soddisfare alcuni requisiti stabiliti da leggi e regolamenti (locali, di gruppo, ecc.). Nella pratica, però, essere conformi a
31
12
CIO e CSO sono due
magazine internazionali
che forniscono analisi e
ricerche sugli andamenti
dei trend tecnologici, la
prima, e news, analisi e
ricerche sulla sicurezza e
sul risk management, la
seconda
versione 2.0
Figura 9 - Principali
motivazioni degli
investimenti in
sicurezza
specifiche normative e leggi non deve necessariamente trovare una giustificazione finanziaria:
spesso i requisiti normativi sono soddisfatti a prescindere dal costo.
L’investimento nell’implementazione in misure di sicurezza può essere inoltre giustificata come
prevenzione dinanzi ad eventuali minacce previste nel futuro. A tal proposito, un costante monitoraggio degli studi aiuta a giustificare l’investimento nella predisposizione di risposte adeguate ad
eventuali minacce.
Il rapporto “Threat Horizon 2011”, prodotto dall’ISF, mette in risalto le dieci categorie di minacce
previste nei prossimi anni. In particolare, si rileva che le principali minacce saranno costituite da
attacchi criminali (sia sulle organizzazioni che sui singoli individui), le debolezze all’interno dell’infrastruttura, la mancata conformità a leggi/regolamenti e le conseguenti penali, il diffondersi di
codice malevolo, ecc..
3.7.5 I ritorni per il ROSI
Per poter giustificare investimenti in ambito Information Security, risulta comunque di fondamentale importanza riuscire a calcolare in maniera corretta i ritorni sull’investimento. Essi sono suddivisi in due principali tipologie.
I ritorni quantitativi, sulla base di investimenti fatti, producono un reale ritorno finanziario/economico per l’azienda nonché un aumento dei propri indicatori economici (Fatturato, ecc.). Tali ritorni
sono quantificabili in termini monetari e potrebbero essere calcolati in maniera precisa.
Presupposto necessario affinché tali ritorni possano essere calcolati è che l’organizzazione possieda adeguati processi, metodologie e strumenti per raccogliere le informazioni necessarie ed
elaborarle.
I ritorni quantificabili tipicamente includono:
• l’incremento dei profitti e/o del fatturato;
• l’aumento della produttività;
• la riduzione dei costi associati al verificarsi di incidenti e alle conseguenti attività di rimedio;
• la riduzione delle perdite finanziarie dovute a multe o penali per le violazioni di regolamenti
(sia interni che esterni), leggi o normative;
32
3. Metodo
• la riduzione dei costi operativi (diminuzione del personale, riduzione dei costi hardware e
software, riduzione dei costi di licenza e di affitto, riduzione dei costi di manutenzione);
• l’aumento delle prestazioni relative ad alcuni processi IT e di business (sulla base di Key Performance Indicators);
• l’aumento della innovazione tecnologica.
I ritorni qualitativi non producono un reale ritorno finanziario/economico, oppure lo producono in
maniera indiretta, e quindi non quantificabile (prima dell’investimento che verrà fatto). Tali ritorni
quindi non possono essere direttamente misurati in termini monetari e potrebbe essere complesso
calcolarli.
Possono includere ad esempio:
• protezione e/o aumento della reputazione dell’organizzazione;
• miglioramento del clima aziendale nonché del morale dei propri dipendenti;
• riconoscimento del ruolo di leader del settore;
• conformità a normative, leggi o regolamenti (locali, aziendali, di gruppo, ecc.);
• maggiore soddisfazione da parte del cliente;
• acquisizione di specifiche competenze su tematiche innovative, con maggiore motivazione
per il personale coinvolto in tali progetti.
Alcuni di questi benefici potrebbero avere ritorni di tipo quantitativo e quindi economico/finanziari
in maniera indiretta. Per esempio l’utilizzo di adeguate misure di sicurezza per un sito web potrebbe favorire l’aumento della soddisfazione del cliente, e delle relative vendite a lungo termine. Tali
benefici tuttavia sono difficili da quantificare ed in particolare risulta complesso quantificare in che
misura un’iniziativa di sicurezza possa impattare sui ritorni.
Partendo dal modello proposto dal CobiT potrebbero essere utilizzati come linee guida alcuni value
drivers utili all’identificazione del ritorno degli investimenti. I value drivers che impattano sull’iniziativa di sicurezza in esame devono essere adeguatamente valutati e, ove possibile, misurati. Ne
risulta una valorizzazione dei benefici dovuti all’iniziativa di sicurezza.
3.8 Un esempio di valutazione del ROSI
Nel presente paragrafo è fornito un esempio di come applicare l’approccio per il calcolo dei KCI e
dei KRI nel caso in cui il responsabile della sicurezza delle informazioni decidesse di implementare una soluzione di Application Security nella propria azienda. La soluzione potrebbe essere ad
esempio uno strumento di Source Code Scanning (ovvero uno strumento per l’analisi della sicurezza del codice sorgente dei programmi software).
3.8.1 Step 1: Individuazione dei costi e dei ritorni
Il primo passo consiste nell’individuare tutti i costi ed i ritorni applicabili alla soluzione di Source
Code Scanning. I costi, oltre all’acquisto, l’implementazione e la configurazione del sistema, sono
ad esempio quelli da sostenere per la formazione degli utenti. I ritorni invece sono principalmente
quelli del risparmio del costo per bug fixing mediante modifiche all’applicazione e la conformità a
standard o best practice (p.e. PCI-DSS).
33
versione 2.0
3.8.2 Step 2: Definizione degli indicatori per il ROSI
Una volta identificati i principali costi e ritorni, è necessario definire degli indicatori di costo e di
ritorno, che siano SMART, ovvero Specific, Measurable, Acheavable, Realistic, Timeable.
I Key Cost Indicator, e le relative metriche (indicate tra parentesi), potrebbero essere i seguenti:
• KCI_1: Acquisto del prodotto (costo di acquisto per anno, costo di implementazione per anno,
costo di configurazione per anno);
• KCI_2: Formazione degli utenti (numero utenti da formare, costo medio della formazione per
utente per anno).
I Key Return Indicator, e le relative metriche (indicate tra parentesi), invece potrebbero essere:
• KRI_1: Costo annuale per il bug fixing (numero di errori di programmazione rilevati per anno,
FTE necessari per la risoluzione degli errori rilevati in produzione);
• KRI_2: Risparmio rispetto alla non conformità (costo massimo delle multe per anno).
Tali indicatori sono composti da metriche che possono essere già disponibili in azienda o che,
alternativamente, devono essere appositamente predisposte e misurate.
3.8.3 Step 3: Identificazione delle metriche disponibili
Una volta definiti gli indicatori e le relative metriche non resta che identificare quali di esse siano
già disponibili in azienda. Per esempio ipotizziamo che siano già disponibili le seguenti metriche:
• Costo di acquisto del prodotto (di source code scanning) per anno;
• Costo di implementazione prodotto (di source code scanning) per anno;
• Costo di configurazione prodotto (di source code scanning) per anno;
• Numero di utenti da formare;
• Costo massimo delle multe per anno.
3.8.4 Step 4: Predisposizione di nuove metriche
Qualora invece non fossero disponibili in azienda le metriche richieste per il calcolo degli indicatori, risulta necessario identificarne di nuove e predisporre quanto necessario per la loro rilevazione.
Per esempio:
• Costo medio della formazione per utente per anno;
• Numero di errori di programmazione rilevati per anno;
• FTE necessari per la risoluzione degli errori rilevati in produzione.
3.8.5 Step 5: Misurazione delle metriche
Una volta identificate o predisposte, le metriche devono essere misurate. Le metriche già disponibili in azienda saranno facilmente misurabili mentre per quelle non disponibili sono possibili due
alternative.
Qualora la metrica sia misurabile nel breve periodo, allora può essere predisposta e misurata. Per
esempio per valutare il costo medio della formazione per utente per anno è sufficiente ipotizzare
un piano di formazione per gli sviluppatori e valutarne il costo medio per persona.
Qualora invece la metrica non sia misurabile nel breve periodo, è necessario utilizzare l’esperienza
del Security Manager oppure benchmark di settore. Per esempio per valutare l’indicatore di Costo
annuale di bug fixing potrebbe essere necessario confrontarsi con il Responsabile dello Sviluppo
34
3. Metodo
Software che probabilmente sarà in grado di quantificare sia il numero di errori di programmazione
rilevati per anno, sia il numero di FTE necessari per la risoluzione degli errori rilevati in produzione;
in alternativa sarebbe comunque possibile utilizzare il risultato di benchmark di settore.
3.8.6 Step 6: Valutazione degli indicatori
Una volta misurate le metriche non resta che valutare gli indicatori di costo e ritorno e calcolare
il ROSI nella modalità ritenuta più opportuna dal responsabile della sicurezza. Per esempio, nel
caso della soluzione di Source Code Scanning, il ROSI potrebbe 13 essere calcolato nel seguente
modo:
KRI_1 + KRI_2
ROSI =
KCI_1 + KCI_2
Qualora il ROSI dia un valore maggiore di 1, allora l’investimento in sicurezza è vantaggioso per
l’azienda.
Caso 3
Una società di servizi informatici bancari a seguito di un errore del personale addetto
nell’implementazione di una nuova piattaforma (in sostituzione del sistema principale
di gestione dei conti correnti) crea un problema risolto in una giornata circa (su 3,5
milioni di conti); in pratica il mngnt decide di scaricare il nuovo software e ricaricare
il vecchio software in produzione, risolvere il problema e poi ricominciare di nuovo la
nuova installazione; l’operazione costa complessivamente 1,5 milioni di sole spese
extra.
13
La formula riportata è a
titolo esemplificativo e non
ha valenza di carattere
generale.
35
versione 2.0
4. Documento ROSI
Una volta individuate le opportunità di investimento e valutati i relativi ritorni, seguendo l’approccio
Top-down piuttosto che l’approccio Verify, è necessario raccogliere tutte le informazioni e le considerazioni svolte per riportarle in un documento da presentare al management a sostegno delle
proprie scelte per ottenere l’approvazione all’investimento.
Si riporta nel seguito una traccia che può essere utilizzata a supporto della preparazione di un documento da sottoporre al management che rappresenti in sintesi il business case della soluzione
proposta, individuando gli elementi chiave che devono tenuti in considerazione.
La redazione del documento rappresentativo del ritorno dell’investimento dato dalla soluzione di
sicurezza proposta è sostanzialmente analoga a quella di un qualsiasi altro documento predisposto per convincere qualcuno di quello che si sta proponendo ed ottenerne l’approvazione.
È fondamentale tuttavia in questo contesto chiarire gli obiettivi ed i risultati attesi dall’investimento
e dimostrare quali sono i benefici ottenibili per giustificare la valutazione della soluzione da parte
del management e la successiva approvazione.
4.1 Struttura del documento
La scansione logica riesce naturalmente in tre parti: situazione esistente (all’interno dell’ambito di
lavoro ed al suo contorno), situazione desiderata (con motivazioni del cambiamento), azioni per
passare dalla prima alla seconda.
Tali sezioni sono generalmente chiamate:
1. Stato dell’arte;
2. Obiettivo desiderato;
3. Proposta operativa.
e sono precedute da un Executive Summary che di fatto riassume le tre parti presentando con
grande chiarezza i benefici che si intendono cogliere e anticipando in modo sintetico il risultato
della valutazione del ROSI.
Per massima chiarezza, le motivazioni del fare qualcosa (se fare qualcosa, e perché) dovrebbero
essere esposte all’inizio della sezione degli obbiettivi, fermo restando il fatto che la decisione finale
sul procedere o meno ed in che misura deve essere presa al corretto livello manageriale.
Al contempo, questa documentazione, oltre che un supporto decisionale per il manager responsabile, costituirà la base per la necessaria revisione da parte dei livelli superiori, quando a posteriori
sarà valutato l’effettivo rendimento dell’azione intrapresa.
Per motivi di efficienza il taglio ed il livello di approfondimento del documento dovranno essere il
più possibile coerenti alla dimensione dell’investimento da proporre: ben diverso sarà il documento ROSI redatto per decidere se stanziare o meno qualche centinaio di euro per portare lo storage
da RAID 5 a RAID 50 da un documento ROSI predisposto per decidere se intraprendere o no un
progetto di Identity and Access Management.
La documentazione di supporto decisionale rifletterà quindi la dimensione dello sforzo di analisi:
in tutti i casi, tuttavia, è necessario mantenere uno schema riconoscibile ed organizzato, eventual36
4 Documento ROSI
mente dichiarando in maniera esplicita quali parti di essa risultano superflue vista la scala della
proposta, o non sono state affrontate per mancanza di tempo e/o di risorse.
4.2 Executive summary
Si è già detto altrove della necessità di comunicare con il resto dell’organizzazione con il linguaggio e le priorità del resto dell’organizzazione, mantenendo al centro quello che è il core business
– ovvero il motivo per cui l’organizzazione esiste, sia che si tratti ad esempio di “contribuire al
superamento del problema della fame nel mondo” sia che si tratti di “massimizzare i profitti degli
azionisti producendo alimentari di largo consumo”.
Il concetto principale dell’executive summary dovrà quindi essere la risposta alla domanda “quali
benefici questa proposta porta al core business?”
Questi benefici non sono necessariamente finanziari e monetari, anche se sono palesemente
“economici” nel senso più lato del termine, ovvero contribuiscono al raggiungimento degli obbiettivi: ad esempio incrementando l’efficienza, oppure aumentando la fidelizzazione del cliente.
Si dovranno riportare in sintesi le motivazioni che portano a fare una proposta che porterà beneficio all’organizzazione, e quindi dare un “perché” alla proposta – lasciando sempre a chi deve decidere la responsabilità di scegliere se procedere oppure no, o al limite di procedere parzialmente
(se questo è possibile per la specifica proposta).
Può essere assai utile esporre una proposta di minima ed una di massima, o addirittura (in alcuni
casi può essere semplice farlo) uno spettro di proposte, dalla più facile e meno costosa, ma frammentaria, a quella più completa, complessa e costosa.
4.3 Stato dell’arte
Enunciare chiaramente, e senza ricorrere a giri di parole, la situazione corrente, rimanendo il più
possibile distaccati da quanto si presenta.
Riportare unicamente fatti, possibilmente documentati: qualsiasi commento o sensazione è opinabile, e solitamente non vengono prese decisioni in base a voci non supportate. Inserire proprie
valutazioni di merito distrae dal punto, che è quello di presentare nel modo più esauriente ma
conciso possibile la situazione reale. Si consiglia, in altre parole, di adottare in questa sezione un
punto di vista il più possibile neutrale.
Eventuali punti deboli, difficoltà, inefficienze, ecc. dovrebbero essere esposti il più possibile come
dati di fatto, senza indirizzare a priori ad una soluzione piuttosto che ad un’altra, salvo che si tratti
della conformità a normative di legge
In questo specifico caso, tuttavia, è indispensabile la massima precisione nel delineare quali sono
esattamente i requisiti minimi della legge, e quali invece, ad esempio, le raccomandazioni derivanti dal proprio discernimento personale (dati dall’esperienza, dalla conoscenza tecnica, o anche
soltanto dalla propria sensibilità).
Ad esempio, per quanto riguarda il Codice della Privacy, è importante distinguere tra le cosiddette
“misure minime”, che sono obbligatorie per legge, e le “misure idonee”, che l’organizzazione valuta ed adotta in base alle proprie necessità.
Per fare un esempio ancora più specifico, la legge prescrive il cambio password ogni sei mesi,
ma solo per l’accesso informatico a dati “personali”, e ogni tre mesi per i dati “sensibili”, dove
entrambe le definizioni sono esposte con precisione nella legge stessa. Un’organizzazione potreb-
37
versione 2.0
be valutare che sei mesi sia un tempo assai lungo, ed inoltre potrebbe voler semplificare i propri
processi portando il limite a tre mesi per tutti i tipi di accessi: questa proposta sarebbe assolutamente ragionevole, e per un tecnico la risposta sarebbe probabilmente scontata. In un’ottica di
business, tuttavia, è necessario porsi un problema aggiuntivo: la maggiore efficienza data dalla
semplificazione di processo ripagherebbe il probabile incremento di chiamate al supporto tecnico?
La questione deve essere affrontata ed esposta con chiarezza.
4.4 Obiettivo desiderato
Anche in questa sezione si consiglia di adottare uno stile neutrale, evitando di inserire sensazioni
personali o commenti non oggettivi.
Gli obbiettivi dovrebbero essere facilmente riconducibili al core business aziendale, e dare ad esso
dei benefici tangibili anche se, eventualmente, indiretti. Trattandosi di sicurezza delle informazioni,
i collegamenti con l’attività dell’organizzazione possono in alcuni casi essere palesi, oppure derivare da obblighi legali o regolamentari.
In molti altri casi, statisticamente più numerosi, i collegamenti sono meno palesi perché l’idea
iniziale nasce dalla diminuzione di un rischio percepito, e quindi il beneficio è solo ipotetico così
come è ipotetico il danno finché l’evento rischioso non si presenta.
In questo caso si consiglia di predisporre in modo accurato le valutazioni alla sezione precedente, in modo che sia poi possibile esporre una percentuale di probabilità ragionevole dell’evento
dannoso con la quale “pesare” le valutazioni economiche. Si veda a questo proposito, per stimare
questa probabilità ed il costo delle contromisure, la sezione 3.6.
4.5 Proposta operativa
In questa sezione si espone effettivamente l’idea di miglioramento. Deve rispondere alle classiche
domande “giornalistiche”: chi, cosa, quando; ovvero, che cosa si propone di fare, chi se ne deve
occupare, ed in che tempi.
Immediatamente di seguito si deve esporre sinteticamente il “come” si propone di realizzare l’idea,
“dove” la proposta impatta (sull’organizzazione, sull’infrastruttura tecnologica, sulle persone...),
“con quale budget” (se è possibile fare proposte).
In questa sezione si riporta quindi in dettaglio il progetto di attuazione della soluzione proposta,
definendo attività, tempi e risorse necessarie e valutando le eventuali dipendenze da altri progetti
o qualsiasi altro vincolo da considerare nell’implementazione della soluzione.
Successivamente deve essere riportata la valutazione del valore della soluzione proposta, includendo quindi i costi di implementazione e mantenimento ed i relativi benefici, finanziari e non
finanziari, ottenibili: a tal fine possono essere riprese tutte le informazioni e la documentazione
prodotta seguendo il metodo proposto, sia secondo l’approccio Top-down sia secondo l’approccio
Verify, procedendo ad una razionalizzazione ed organizzazione dei contenuti per la presentazione
al management.
Infine è opportuno indicare anche l’impatto del cambiamento organizzativo della soluzione di sicurezza che si propone, come questa si inserisce nelle strategie di sicurezza dell’azienda, nonché
eventuali rischi associati all’implementazione, al fine di fornire un quadro quanto più esaustivo
possibile della proposta.
38
5. Esempi di pattern
5.1 Pattern “Amministratori di Sistema”
PATTERN
Interventi di adeguamento al provvedimento del Garante della Privacy in merito alle funzioni di
amministratore di sistema
AREA DI INTERVENTO
10.10.4 Administrator and Operator Logs
SINTESI
R
Conformita` Risorse Impattate
R
Infrastruttura Driver di Business
£
Rischi operativi £
Riservatezza R
£
Integrita` Risorse Umane R
Compliance £
£
£
Disponibilita`
Applicazioni £
Informazioni
Immagine aziendale £
Efficienza processi
L’autorità italiana Garante della Privacy (Garante per la protezione dei dati personali) ha, in data 27 novembre 2008, adottato
il provvedimento “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente
alle attribuzioni delle funzioni di amministratore di sistema” (gazzetta ufficiale n. 300 del 24 dicembre 2008) ove si prescrivono appropriate misure per controllare l’operato degli amministratori di sistemi. Tale norma pone all’attenzione delle
aziende, come misura minima, la necessità di controllare l’operato degli amministratori di sistema (ADS). In estrema sintesi,
il provvedimento richiede: la valutazione delle caratteristiche soggettive degli ADS, la designazione individuale e nominativa con elencazione degli ambiti di operatività, la disponibilità dell’elenco degli ADS, la verifica periodica delle attività per
valutare la rispondenza alle misure organizzative, tecniche e di sicurezza, la registrazione degli accessi logici ai sistemi di
elaborazione e agli archivi.
DESCRIZIONE
L’adeguamento al provvedimento del Garante può essere ottenuto con una serie di interventi tra loro coordinati a carattere
organizzativo, tecnologico e di formazione delle risorse umane. La profondità e l’ampiezza di tali interventi dovrebbe essere
commisurata alla complessità aziendale e alla qualità dei dati da proteggere; elementi questi ultimi da valutare in relazione
al costo e al rischio. Se da una parte, alcune aziende sono escluse dall’obbligo per via del provvedimento di semplificazione contabile amministrativa (“semplificazioni di taluni adempimenti in ambito pubblico e privato rispetto a trattamenti per
finalità amministrative e contabili” 19 giugno 2008), dall’altra non è detto che un’azienda “piccola” ne sia esente come
ad esempio nei casi del settore della sanità per la tipologia dei dati da tutelare. Nel momento in cui scriviamo, alcune
prescrizioni non sono ritenute dal mercato completamente chiare, esistono sicuramente degli ambiti lasciati inizialmente
alla decisione di chi implementa, e visto che il provvedimento è obbligatorio da poco tempo, non c’è una giurisprudenza
consolidata. Inoltre i sistemi informatici hanno confini fisici che trascendono quelli degli stati nazionali e quindi, qualora i
dati siano gestiti all’estero o in Italia per società estere, eventualmente tramite subappalto, si rende necessario disporre per
l’implementazione di un adeguato livello di supporto legale e consulenziale. Un aspetto centrale del provvedimento consiste
nell’implementare un sistema di gestione dei log degli accessi da parte degli amministratori di sistema. Su questo aspetto
tecnico il mercato, soprattutto i fornitori di software, hanno insistito molto evidenziando le proprie soluzioni da aggiungere
o per sostituire completamente, viste alcune limitazioni, quelle native dei sistemi operativi. Inoltre da un punto di vista sia
tecnico sia organizzativo si pone il problema di ridurre e controllare gli account sistemistici non nominativi. Infatti se ne
deve impedire l’uso in massima misura. Il beneficio di tale sforzo va ben oltre alla semplice compliance al provvedimento:
eliminare gli accessi anonimi e sapere chi ha accesso a quali risorse è una pratica alla base di ogni sistema di sicurezza.
39
versione 2.0
Unitamente agli aspetti tecnologici, si rammenta che per adeguarsi al provvedimento è necessario intervenire su ogni aspetto della prescrizione (si veda sopra al “contesto di riferimento”) predisponendo un sistema di valutazione, la nomina degli
amministratori, strumenti per la gestione e la disponibilità dell’elenco e per la verifica periodica. In aziende molto grandi,
alcuni di questi aspetti possono essere ulteriormente assistiti da soluzioni informatiche come ad esempio strumenti per
propinare questionari via web, ma probabilmente l’aspetto di maggior ritorno consiste nella possibilità di usare i dati raccolti
nei log per implementare un sistema opzionale (non richiesto dalla norma) di analisi del rischio. Tale sistema progettabile
come un data warehouse e dotato di alert e controlli potrebbe evidenziare tempestivamente situazioni anomale relativamente all’accesso (come per esempio accessi fuori dall’orario di lavoro, da parte di personale che ha lasciato l’azienda, da
postazioni remotissime ecc.).
DRIVER/MOTIVAZIONI
Realizzare gli interventi descritti in questo pattern permette di assolvere ad un obbligo di compliance con il suddetto provvedimento del Garante della Privacy, mettendosi al riparo dalle conseguenze legali in caso di ispezioni dell’autorità e riducendo il rischio in sede giudiziaria, in caso di violazione o supposta violazione dei sistemi informativi che abbia procurato
un danno.
Adottando queste raccomandazioni si ottengono inoltre effetti benefici in relazione al rischio operativo, visto che aumenta il
controllo degli ADS e degli account degli stessi.
Infine si protegge l’immagine aziendale, che sarebbe colpita in caso di sanzione per inottemperanza.
PUNTI DI ATTENZIONE
Oltre ai normali fattori che impattano sulle probabilità di successo di un progetto, vale la pena menzionare in maniera
specifica la necessità di supporto legale e consulenziale. Ciò per ridurre le ambiguità del provvedimento conoscendo le
interpretazioni e le soluzioni adottate anche da altre aziende e per riuscire a cogliere l’opportunità della necessità di compliance (driver primario) per cogliere obiettivi di contenimento del rischio operativo e sull’immagine aziendale. Nelle peggiori
implementazioni osservate dagli autori di questo documento, è stato possibile realizzare un sistema adeguato rispetto il
provvedimento ma assolutamente inutile per la sicurezza. Nel caso in cui il sistema di log voglia essere esteso per registrare
altri eventi (oltre al login e logout obbligatori) o ad altre persone in azienda (oltre agli amministratori di sistema), per esempio
per cogliere in pieno l’opportunità relativa al data warehouse e all’alerting sopra citata, si consideri, anche in questo caso,
un supporto legale e consulenziale per raccordare la soluzione con gli aspetti relativi all’art. 4 dello Statuto dei Lavoratori (“È
vietato l’uso di impianti audiovisivi e di altre apparecchiature per finalità di controllo a distanza dell’attività dei lavoratori”).
ELEMENTI DI VALUTAZIONE (Elementi da considerare per la stima del ritorno d’investimento)
Tra gli elementi di valutazione per la scelta se investire o meno in questo pattern bisogna considerare: il costo e la probabilità
delle eventuali multe comminate per inadempienza; il costo e gli impatti sull’immagine aziendale nel caso in cui il pubblico
venga a conoscenza dell’inadempienza; la maggior probabilità di condanna in sede giudiziale nel caso in cui si sia portati
in giudizio da una persona la cui privacy sia stata violata; il rischio e il danno dovuto a furti o frodi operate dagli amministratori di sistema che, in assenza di alcun controllo, violino la riservatezza, alterino l’integrità e/o riducano la disponibilità dei
sistemi.
BENEFICI / VANTAGGI
Compliance al provvedimento del Garante sugli amministratori di sistema, Riduzione del rischio di accadimenti che impattino l’immagine aziendale e riduzione dell’impatto stesso, Riduzione del rischio di frode o furto operato dagli amministratori
di sistema.
40
5.2 Pattern “Identity and Access Management”
NOME
Identity and Access Management
AREA DI INTERVENTO
11.1.1 Access Control Policy
11.2.1 User Registration
11.2.2 Privilege Management
11.2.3 User Password Management
11.2.4 Review of User Access Rights
11.5.2 User Identification and Authentication
11.6.1 Information Access Restriction
SINTESI
R
R
R
Rischi operativi R
Riservatezza R
£
Compliance R
£
£
Disponibilita`
Applicazioni £
Informazioni
Immagine aziendale R
Efficienza processi
La tematica dell’Identity and Access management si colloca nell’ambito delle attività di gestione degli accessi logici ai sistemi
informativi aziendali.
DESCRIZIONE
Per soluzione di Identity and Access Management si intende la definizione di un modello organizzativo e procedurale che sia
in grado, con il supporto di opportuni strumenti tecnologici, di gestire le identità degli utenti per l’intero loro ciclo di vita.
L’adozione di una soluzione IAM consente pertanto la gestione in modalità automatica degli account utente e delle abilitazioni di accesso alle applicazioni impiegate in azienda. Dal punto di vista tecnologico è necessaria l’implementazione di una
suite IAM in grado di svolgere le attività di gestione degli account (intese come creazione, cancellazione, sospensione, ecc.)
e di provisioning e de-provisioning dei profili di accesso alle applicazioni.
I criteri tramite i quali sono attribuiti i profili di accesso sono individuati a priori, tramite la definizione di un modello RBAC
(Role Based Access Control) che consente di attribuire i profili di accesso agli utenti, sulla base del valore di opportuni attributi autorizzativi. Tali attributi fanno riferimento tipicamente alla mansione svolta, alla sede di lavoro, all’unità organizzativa
di appartenenza ma differiscono in base al contesto aziendale e caratterizzano classi di soggetti alle quali devono essere
assegnate le medesime abilitazioni di accesso ai sistemi informativi. La definizione del modello RBAC fa parte degli aspetti
di natura organizzativa necessari per l’implementazione di una soluzione di IAM in azienda.
In estrema sintesi pertanto, l’adozione del modello RBAC, l’implementazione tecnologica di una suite di IAM e la definizione
di opportuni processi di gestione supportati da uno strumento di workflow, costituiscono la soluzione di IAM.
Da una Survey 14 condotta da KPMG in Ottobre 2009 con riferimento ad aziende Europee, è emerso che le motivazioni per
le quali ad oggi le aziende investono in una soluzione di I&AM sono in percentuale:
- Governance, Risk e Compliance . .............................................. 72%
- Miglioramento dell’operatività .................................................... 14%
- Adattabilità all’evoluzione del Business . .................................... 13%
Una ulteriore Survey15 condotta da KPMG con riferimento ad aziende americane ha invece riportato risultati più dettagliati:
- Miglioramento di aspetti di sicurezza ......................................... 72%
14
15
http://www.kpmg.com.sg/publications/Advisory_EuropeanIdenty_AccessMgtSurvey09.pdf
http://www.kpmg.com/Global/en/IssuesAndInsights/ArticlesPublications/Pages/Identity-Access-Management-Initiatives.aspx
41
versione 2.0
- Mitigazione dei rischi ................................................................ 67%
- Adempimenti normativi ............................................................. 63%
- Miglioramento dei processi di Business ..................................... 54%
- Contenimento dei costi ............................................................. 16%
- Aggiornamento dell’infrastruttura IT .......................................... 14%
- Inclusione in progetti più ampi ..................................................... 5%
- Vantaggio competitivo .................................................................. 5%
Nota: tali dati fanno riferimento a domande con possibilità di risposta a scelta multipla
PUNTI DI ATTENZIONE
Una soluzione di Identity and Access Management, affinchè risulti efficace, non può essere implementata autonomamente
dalla singola funzione aziendale che si occupa della gestione dei sistemi informativi, ma necessita del coinvolgimento di
diverse funzioni aziendali.
L’adozione di una soluzione di Identity and Access Management, oltre a migliorare aspetti di sicurezza, presenta il vantaggio
di aumentare l’efficienza dei processi di gestione degli accessi logici. L’aumento dell’efficienza comporta una diminuzione
della “perdita di produttività”, traducibile in valori quantificabili e da prendere in considerazione nel calcolo del ritorno di
investimento.
Di seguito sono descritti alcuni degli elementi che possono costituire delle metriche di riferimento per quantificare i costi
associati alla perdita di produttività e di conseguenza il ritorno di investimento:
L’automatismo nelle attività di provisioning (attivazione) e de-provisioning (disattivazione) di account e profili introduce una
netta riduzione delle tempistiche necessarie alla gestione manuale di tali attività. Pertanto, al fine di quantificare il ritorno
di investimento, un elemento caratterizzante è la riduzione delle tempistiche che si traduce in un aumento di produttività e
pertanto in un risparmio dei costi di gestione. Tale risparmio è quantificabile calcolando in primo luogo il tempo necessario
al provisioning manuale (in assenza di una soluzione di IAM) e successivamente il costo (in termini di FTE) necessario per
tale attività. Supponendo che il tempo necessario per creare un account sia di 1 ora e che un dipendente preposto a tale
attività costi all’azienda 80 e al giorno, il costo della creazione di un account è stimabile in 10 e. Tale valore, moltiplicato
per una media del numero di account creati in un certo arco temporale, rappresenta la perdita di produttività in assenza
di una soluzione di IAM. L’adozione della soluzione introduce quindi un risparmio e di conseguenza un elemento utile per
calcolare il ritorno di investimento.
L’adozione del modello RBAC consente il provisioning automatico di N account e N profili in una sola operazione, dove N è
il numero di applicazioni a cui l’utente deve avere accesso. Tale operazione, svolta in modalità automatica, elimina la perdita di produttività dovuta alla gestione manuale e consente un risparmio del costo di gestione. Tenendo in considerazione
l’esempio precedente, se il numero di applicazioni a cui un utente deve avere accesso è 5, il costo per il provisioning di tutte
le abilitazioni per utente sarà di 50 e. Tale valore, moltiplicato per il numero di utenti, rappresenta un ulteriore elemento di
valutazione del ritorno di investimento.
In assenza di una soluzione di IAM, il provisioning di un account o di un profilo avviene a fronte di una opportuna richiesta.
Generalmente a fronte della formulazione di tale richiesta, prima che l’operazione venga svolta, trascorre diverso tempo,
anche a causa della necessità di uno step autorizzativo. Tale ammontare di tempo, quantificabile in termini di costo tramite
i criteri esposti negli esempi precedenti costituisce un elemento di valutazione in quanto il provisioning automatico (attivato
tramite opportuni attributi), elimina la necessità di effettuare richieste e attenderne l’evasione.
Un ulteriore elemento quantificabile, è il tempo/costo risparmiato per la produzione di report necessari alla revisione delle
42
abilitazioni di accesso. Una soluzione di I&AM consente infatti la possibilità di produrre i report in maniera automatica per
tutti i target system. Ciò introduce un notevole risparmio di tempo in quanto non risulta più necessario accedere a tutte le
applicazioni per le estrazioni delle informazioni, la normalizzazione delle stesse ai fini della redazione dei report, ecc.
Si fa presente che al fine di stimare il ritorno di investimento per anno, i dati relativi al ritorno di investimento per operazione,
dovranno essere moltiplicati per il numero medio di operazioni (ad esempio creazione account) che si verifica in un anno.
Oltre agli elementi sopra elencati, le cui stime possono essere valorizzate tramite applicazione di metodi di calcolo basati su
parametri quantificabili, possono essere considerati ulteriori elementi le cui stime richiedono metodi di valutazione prettamente qualitativi.
Ad esempio, un elemento utile da prendere in considerazione per il ritorno di investimento riferito ad una soluzione di IAM,
è la riduzione del rischio di accessi non autorizzati. Tale elemento potrebbe essere valorizzato stimando la perdita potenziale
che si otterrebbe nel caso in cui si dovessero verificare degli accessi non autorizzati. Tale stima si basa su valori quali il costo
associato ai danni provocati da accessi non autorizzati in termini di perdita di business, di perdita di immagine aziendale,
ecc. La quantificazione di tali aspetti è piuttosto complessa, pertanto la valutazione implica la necessità di adozione di metodi qualitativi.
Un altro elemento significativo per la valutazione del ritorno di investimento è il costo correlato alla riduzione dei rischi di
compliance, che potrebbe essere stimato considerando il valore delle sanzioni di carattere economico previste dalle normative vigenti in caso di mancati adeguamenti.
Analogamente è possibile considerare come elemento utile, il costo associato alla riduzione del rischio di frodi. Per la stima
di tale valore è necessario essere a conoscenza delle frodi che si sono verificate in azienda e dei costi sostenuti per far fronte
a tali avvenimenti, nonché dei costi legati alla perdita di business indotta dalle frodi stesse
BENEFICI / VANTAGGI
• Possibilità di integrazione con soluzioni di Single Sign On e Strong Authentication
• Supporto alle attività di riorganizzazione aziendale
• Aumento del livello di sicurezza
• Garanzia del rispetto di alcuni vincoli normativi (disabilitazione account per inutilizzo, password più robuste, ecc..)
• Rispetto dei principi del “need to know” e “segregation of duties”
• Riduzione dei costi operativi
• Supporto alle attività di Audit / verifiche periodiche
43
versione 2.0
5.3 Pattern “Single Sign On”
PATTERN
Single Sign On
AREA DI INTERVENTO
11.2.1 User Registration
11.2.3 User Password Management
11.5.2 User Identification and Authentication
SINTESI
R
R
R
Rischi operativi R
Riservatezza R
£
Compliance R
£
£
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
Le soluzioni di Single Sign On si collocano nell’ambito dei meccanismi di autenticazione per gli accessi logici ai sistemi
informativi aziendali.
DESCRIZIONE
Per soluzione di SSO (Single Sign On) si intende un sistema in grado di permettere ad un utente di accedere a tutti i sistemi
informativi (o applicazioni) ai quali risulta abilitato, inserendo le credenziali di autenticazione una sola volta.
L’adozione di una soluzione di SSO implica pertanto che le richieste di autenticazione non siano direttamente gestite dal sistema al quale si accede, ma siano re-dirette verso un sistema di autenticazione centralizzato che verifica precedentemente
le credenziali dell’utente connesso, senza necessità di richiederle nuovamente.
L’obiettivo che si prefigge una soluzione di SSO è pertanto quello di rendere la sicurezza trasparente all’utente finale, introducendo efficienza nel processo di autenticazione dovuta dal fatto che l’utente in primo luogo non è tenuto a ricordare N
password di accesso per N applicazioni/sistemi e inoltre non è tenuto ad imputarle ogniqualvolta necessita di accedere.
Il motivo principale per il quale implementare una soluzione di SSO è la riduzione dei costi di gestione, soprattutto per quanto riguarda le attività ordinarie degli amministratori di sistema e degli utenti dell’Help Desk.
PUNTI DI ATTENZIONE
Una soluzione di Single Sign On, affinché possa essere mantenuta nel tempo, necessita di un alto livello di scalabilità, in
quanto deve essere in grado di integrare nuove tecnologie o nuove tipologie di sistemi che potrebbero essere introdotti
nell’infrastruttura nel corso del tempo.
Inoltre è bene considerare l’eventuale difficoltà che potrebbe sorgere nell’integrazione di applicazioni custom, sviluppate
“ad hoc” per contesti specifici.
Analogamente alle soluzioni di Identity and Access Management, con le quali esiste una forte correlazione, le soluzioni di
Single Sign On consentono un notevole aumento di efficacia nel processo di autenticazione e di gestione delle credenziali di
accesso. L’aumento dell’efficacia si traduce in una riduzione della perdita di produttività che, come già descritto nel corso
del presente documento, è un elemento utile per determinare il ritorno di investimento.
Tale valore è quantificabile considerando il tempo impiegato per le attività di gestione delle credenziali di accesso in assenza di una soluzione di SSO e traducendo tali tempistiche in costi di gestione. Ad esempio supponiamo che il tempo
necessario per l’attività di reset password da parte dell’help desk sia di 15 min e che un dipendente preposto a tale attività
costi all’azienda 80€ al giorno. Il costo per una operazione di reset password risulta pertanto stimabile in 2,5€. Tale valore,
44
moltiplicato per la media del numero di richieste di reset password in un certo arco temporale, rappresenta la perdita di
produttività in assenza di una soluzione di SSO. L’adozione della soluzione introduce quindi un risparmio e di conseguenza
un elemento utile per calcolare il ritorno di investimento.
Un altro parametro di interesse è il tempo medio necessario ad un utente finale per imputare le credenziali di autenticazione ogni volta che ha necessità di accedere ad una applicazione. Prendendo come riferimento l’esempio precedente, e
supponendo di nuovo che il costo per l’azienda di un dipendente sia di 80€ al giorno, e che il tempo medio necessario per
autenticarsi ad una applicazione sia di 15s, il costo di ogni operazione di autenticazione risulta di circa 0,04€. Tale valore,
moltiplicato per il numero di applicazioni alle quali ogni utente accede e per il numero di utenti, fornisce una stima dei costi
delle operazioni di autenticazione, traducibile in una perdita di produttività e pertanto un elemento utile per il calcolo del
ritorno di investimento.
Come per le soluzioni di Identity and Access Management, oltre agli elementi sopra elencati, le cui stime possono essere
valorizzate tramite applicazione di metodi di calcolo basati su parametri quantificabili, possono essere considerati ulteriori
elementi le cui stime richiedono metodi di valutazione prettamente qualitativi.
Ad esempio, un elemento utile da prendere in considerazione per il ritorno di investimento è la riduzione del rischio di accessi non autorizzati. Tale elemento potrebbe essere valorizzato stimando la perdita potenziale che si otterrebbe nel caso in
cui si dovessero verificare degli accessi non autorizzati. Tale stima si basa su valori quali il costo associato ai danni provocati
da accessi non autorizzati in termini di perdita di business, di perdita di immagine aziendale, ecc. La quantificazione di tali
aspetti è piuttosto complessa, pertanto la valutazione implica la necessità di adozione di metodi qualitativi.
Un altro elemento significativo è il costo correlato alla riduzione dei rischi di compliance, dovuto al fatto che l’adozione di
una soluzione di SSO permette una gestione molto più semplificata delle password e pertanto più controllabile. Ad esempio
i requisiti normativi correlati alla composizione delle password lunghezza minima, scadenza, cambio al primo logon, ecc,
sono facilmente gestibili in quanto la password viene utilizzata dall’utente una sola volta per accesso a più applicazioni. Il
costo associato alla riduzione del rischio di compliance potrebbe essere stimato considerando ad esempio il valore delle
sanzioni di carattere economico previste dalle normative vigenti in caso di mancati adeguamenti.
BENEFICI / VANTAGGI
• Diminuzione delle tempistiche necessarie alle attività di audit sulle password policy
• Aumento dell’usabilità da parte dell’utente finale, dovuto alla riduzione del numero di autenticazioni
• Minor carico sulle applicazioni
45
versione 2.0
5.4 Pattern “IDS”
PATTERN
Intrusion Detection System
AREA DI INTERVENTO
13.1.1 Reporting Information Security Events
13.2.2 Learning from Information Security Incidents
SINTESI
£
R
R
Rischi operativi R
Riservatezza R
£
Integrita` Risorse Umane £
Compliance R
£
R
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
I sistemi di Intrusion Detection si collocano nell’ambito dei meccanismi di protezione e dei sistemi di monitoraggio dell’infrastruttura applicativa e della rete aziendale.
DESCRIZIONE
Un IDS (Intrusion Detection System) è un sistema in grado di rilevare incidenti di sicurezza quali tentativi di intrusione alla
rete aziendale tramite l’invio di pacchetti malformati, l’installazione di software malevolo (virus, worm, trojan), lo sfruttamento di servizi vulnerabili, ecc. 16
In base all’oggetto di analisi, gli IDS possono essere suddivisi in:
• Network-based Intrusion Detection System: si tratta di sistemi che analizzano il traffico di rete al fine di individuare intrusioni.
• Host-based Intrusion Detection System: si tratta di un agent installato su singoli host in grado di analizzare il sistema al fine
di rilevare intrusioni tramite analisi dei file di log, modifiche ai parametri del file system, ecc..
• Hybrid Intrusion Detection System: si tratta di sistemi che presentano entrambe le caratteristiche e sono in grado di correlare le informazioni raccolte dalla rete e dai vari host.
Le modalità tramite le quali gli IDS preposti all’analisi del traffico di rete rilevano intrusioni sono solitamente due:
• Anomaly Detection: la rilevazione avviene tramite identificazione di comportamenti anomali. Gli eventi che costituiscono
anomalie sono identificati tramite un’analisi preliminare del comportamento del traffico, finalizzata a classificare gli eventi
considerati “normali”. 17
• Pattern Matching: la rilevazione delle intrusioni avviene tramite la ricerca di eventi che corrispondono a firme caratteristiche delle violazioni di sicurezza (signature based). Pertanto affinchè tale modalità di indagine sia efficace è indispensabile
che la base dati contenente le firme d’attacco sia costantemente aggiornata.
La principale motivazione per la quale dotarsi di uno strumento di Intrusion Detection è quella di aumentare il livello di
sicurezza garantendo la pronta individuazione e risoluzione di incidenti di sicurezza.
PUNTI DI ATTENZIONE
L’efficacia di un sistema di Intrusion Detection dipende principalmente dall’accuratezza della configurazione, e di conseguenza dalle modalità con le quali il sistema viene istruito al fine di rilevare incidenti di sicurezza. Una configurazione non
16
Alcuni IDS possono essere classificati come “attivi”, ovvero oltre che individuare un intrusione, sono in grado di bloccarla, modificando
in modalità automatica la configurazione dei Firewall. Tale caratteristica necessita di un’accurata fase di configurazione, al fine di evitare
la possibilità di bloccare traffico lecito a fronte della rilevazione di falsi negativi
17
La definizione di “normalità” è in effetti una potenziale vulnerabilità, in quanto presenta dei problemi di ordine concettuale in generale.
In questi contesti essa rappresenta unicamente l’andamento più frequente di ciascuna delle grandezze sotto osservazione, all’interno del
periodo di riferimento (preso per ipotesi come normale).
46
accurata potrebbe introdurre alcune criticità dovute al rilevamento di un numero elevato di falsi positivi o negativi, con la
diretta conseguenza di non rilevare i veri incidenti di sicurezza oppure rilevare eventi normali come anomali. E’ opportuno
pertanto, in caso di adozione di un IDS, porre molta attenzione nella definizione delle regole.
Un altro importante aspetto da prendere in considerazione qualora si decida di dotarsi di un IDS, è di natura organizzativa.
Affinchè gli allarmi generati dal sistema siano presidiati, è necessario costituire un team specializzato per il monitoraggio e
la risoluzione di incidenti di sicurezza e le relative procedure operative.
La valutazione del ritorno di investimento derivante dall’adozione di un sistema di Intrusion Detection, implica la necessità di
impiego in maniera preponderante di metodi di valutazione qualitativi, piuttosto che metodi di “calcolo” basati su parametri
quantificabili. Ciò è dovuto alla difficoltà di effettuare delle stime accurate di alcuni elementi quali la perdita di guadagno o
il costo attribuito alle attività di risposta ad un incidente di sicurezza.
Un parametro fondamentale per valutare il ritorno di investimento è rappresentato dalla stima del costo associato al tempo
di fermo dei server, verificatosi a causa di un incidente di sicurezza e in assenza di un IDS. Tale stima necessita della valutazione di diversi elementi:
• Perdita di guadagno per minuti di fermo.
• Perdita di opportunità di business. Tale elemento potrebbe essere stimato considerando che durante il periodo di fermo,
le aziende competitor continuano a garantire il proprio business. Una stima di tale parametro potrebbe essere indotta
consultando ad esempio il reparto vendite al fine di valutare la perdita di business dovuta a ritardi o alla mancata possibilità di soddisfare le richieste di mercato per i propri prodotti o servizi.
• Perdita di produttività dovuta al tempo di fermo. Considerando che i dipendenti durante il periodo di fermo dei server non
possono svolgere le proprie mansioni, il valore di tale parametro è stimabile valutando il costo del dipendente all’azienda
per il tempo di fermo. (Esempi di calcolo della perdita di produttività sono riportati nel pattern relativo alle soluzioni di
Identity and Access Management e di Single Sign On).
Per ottenere una stima realistica del costo associato al tempo di fermo in assenza di un IDS, e poterla impiegare per valutare
il ritorno di investimento, è necessario conoscere il tempo medio (ad esempio su base annuale) in cui i server sono stati
resi non operativi a causa di un incidente di sicurezza che un IDS avrebbe invece rilevato. A tal proposito ma non solo, è
raccomandato il tracciamento degli incidenti di sicurezza che si verificano, le cause individuate, i metodi impiegati per la
risoluzione e gli eventuali danni inflitti tra i quali il tempo di fermo.
Oltre al costo dovuto al tempo di fermo, è possibile individuare ulteriori parametri che, opportunamente valutati, risultano
utili alla stima del ritorno di investimento. Tali parametri sono rappresentati dai costi associati alle modalità di svolgimento di
determinate attività (ad esempio la gestione degli incidenti di sicurezza), in assenza di uno strumento di Intrusion Detection.
L’adozione di tale strumento infatti comporta un aumento di efficienza che permette di stimare la perdita di produttività, che
rappresenta di fatto un costo risparmiato. Un primo elemento da considerare è il costo associato all’ammontare di tempo
necessario (in assenza di un IDS) per l’attività di analisi dei file di log. Tale attività risulta onerosa in assenza di opportuni
strumenti, pertanto l’adozione di un IDS introduce un aumento della produttività dovuto alla riduzione delle tempistiche
di analisi. Un altro parametro è rappresentato dal costo associato all’ammontare di tempo necessario per individuare un
incidente di sicurezza, e da quello necessario per comprendere come agire per risolvere il problema che si è verificato.
Pertanto il tempo impiegato per rispondere ad un incidente di sicurezza, a partire dall’individuazione del problema fino alla
relativa risoluzione, rappresenta un costo che potrebbe essere risparmiato introducendo nell’infrastruttura uno strumento
di Intrusion Detection.
Al fine di ottenere una stima dei costi accurata, è necessario disporre di informazioni quali il numero di incidenti di sicurezza che si sono verificati in azienda ad esempio su base annuale. In mancanza di tali informazioni, è possibile prendere in
47
versione 2.0
considerazione dei valori derivanti da statistiche presenti su report annuali relativi a survey condotte sul tema degli incidenti
di sicurezza da istituti o enti governativi quali Computer Security Institute, SANS, NIST, ecc.
BENEFICI / VANTAGGI
• Possibilità di creare regole di rilevazione degli incidenti personalizzate per specifici contesti aziendali
• Individuazione ed eventuale possibilità di blocco automatico (per iDS attivi) di tentativi di intrusione (interni ed esterni)
• Protezione in tempo reale
• Riduzione delle tempistiche necessarie alla predisposizione di reportistica necessaria alle attività di audit.
5.5 Pattern “Application Security”
PATTERN
Application Security Assessment
AREA DI INTERVENTO
10.4.1 Controls Against Malicious Code
10.4.2 Controls Against Mobile Code
10.9.1 Electronic Commerce
10.9.2 On-Line Transactions
10.9.3 Publicly Available Information
11 Access Control
12.2.1 Input Data Validation
12.2.4 Output Data Validation
12.5.4 Information Leakage
12.5.5 Outsourced Software Development
12.6.1 Control of Technical Vulnerabilities
15.2.2 Technical Compliance Checking
SINTESI
R
R
R
Rischi operativi R
Riservatezza £
R
Compliance R
R
R
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
L’Application Security Assessment si colloca nell’ambito delle attività di gestione dei rischi informatici aziendali.
DESCRIZIONE
Con Application Security Assessment si intende la definizione di processi e/o l’implementazione di strumenti per la gestione
delle vulnerabilità nell’intero ciclo di vita del software aziendale.
In questo ambito con Application Security Assessment si farà riferimento alle attività di Source Code Review e di Application
Scanning / Penetration Test.
Tali attività consentono di verificare in maniera manuale e/o automatizzata la presenza di vulnerabilità presenti nelle applicazioni.
• Il 75% delle violazioni di sicurezza avvengono a livello applicativo [Gartner]
• Oltre il 70% delle vulnerabilità sono presenti a livello applicativo, non a livello infrastrutturale [Gartner]
48
• Se soltanto il 50% delle vulnerabilità del software fossero rimosse prima del passaggio in produzione, i costi di mitigazione
sarebbero ridotti del 75% [Gartner]
• La crescente tendenza di affidare alcune (o tutte) le attività connesse allo sviluppo software a società in outsourcing, non
facilita la creazione della completezza e correttezza dello sviluppo dell’applicazione. [Burton]
• La necessità di essere conformi a specifici standard (p.e. Payment Card Industry Data Security Standard -PCI DSS, Health
Insurance Portability and Accountability Act-HIPAA) richiede in alcuni casi l’obbligatorietà di proteggere i dati e di rendere
sicure le applicazioni web. [Burton]
• Nel gennaio 2007 TJX Companies Inc. ha dichiarato pubblicamente di aver subito un’intrusione non autorizzata nel sistema di elaborazione delle carte di credito/debito. In quella che intrusione sono stati derubati qualcosa come 45.700.000
numeri di conti di carte di credito/debito e oltre 455.000 registrazioni di reso merci (contenenti nomi clienti e numeri di
patente) dal sistema informatico della società.
• Tra il 2005 e il 2007, un hacker americano con origini cubane (Alberto Gonzales), riuscì a rubare oltre 170 milioni di
numeri di carte di credito/debito, attraverso tecniche di “sql injection” e sniffer di pacchetti dati.
PUNTI DI ATTENZIONE
L’efficacia del processo di Application Security Assessment è tanto maggiore quanto più tale processo è integrato all’interno
del ciclo di vita del software (SDLC). Tuttavia integrare tale processo all’interno del SDLC può comportare un rallentamento
nel Time to Market, ovvero nel tempo necessario perché un’applicazione sia rilasciata in produzione. Negli ultimi anni, un
Time to Market sempre più stringente ed una complessità sempre crescente degli sviluppi potrebbero ostacolare l’introduzione di misure di sicurezza all’interno del ciclo di vita del software.
ELEMENTI QUANTIFICABILI
L’adozione di un processo (e relativa tecnologia) di Source Code Review e di Application Scanning / Penetration Test, oltre
ad agire migliorando aspetti di sicurezza, ha il vantaggio di aumentare l’efficienza dei processi di conformità e ridurre i costi
di mitigazione delle vulnerabilità.
Di seguito sono descritti alcuni elementi che possono costituire delle metriche di riferimento:
• La verifica periodica delle vulnerabilità cui sono esposte le applicazioni introduce una netta riduzione degli incidenti di
sicurezza. Ipotizzando che è stato stimato dall’azienda che ogni anno avvengano 20 incidenti che causano una perdita di
N €. Ipotizziamo che l’implementazione di una soluzione di Application Security Assessment riduca gli incidenti del 50%.
Tale valore rappresenta un risparmio e di conseguenza un elemento utile per calcolare il ritorno di investimento.
• L’integrazione delle attività di Application Scanning e Source Code Review nel ciclo di vita del software (sia nelle attività di
sviluppo che di test delle applicazioni) consente una notevole riduzione dei costi di mitigazione delle vulnerabilità riscontrate in ambiente di produzione. Ipotizzando che ogni anno l’implementare di patch di sicurezza su applicazioni in produzione necessiti di x1 giornate [FTE/anno] e che 1 FTE abbia il valore di x2 [e/FTE]. Ipotizziamo che l’implementazione
di una soluzione di Application Security Assessment mi costi x3 [e/anno] e che riduca il numero di giornate spese per
l’applicazione di patch del 75%. Tale valore rappresenta un risparmio e di conseguenza un elemento utile per calcolare
il ritorno di investimento.
• Infine nell’ambito della conformità a standard o regolamenti, potrebbe essere calcolato il risparmio su multe o penali in
caso di non conformità. Ipotizzando che ogni anno l’azienda spenda x1 [e/anno] in multe e che l’implementazione di
una soluzione di Application Security Assessment mi costi x2 [e/anno] e che riduca l’importo delle multe del 100%. Tale
valore rappresenta un risparmio e di conseguenza un elemento utile per calcolare il ritorno di investimento.
49
versione 2.0
ELEMENTI QUALITATIVI
• Immagine aziendale
BENEFICI / VANTAGGI
• Aumento del livello di sicurezza
• Innovazione tecnologica
• Aumento della motivazione dei dipendenti
• Supporto alle attività di Audit / verifiche periodiche
• Aumento delle competenze in materia di sicurezza da parte del personale IT
5.6 Pattern “Sicurezza Fisica”
PATTERN
Sicurezza fisica – Misure principali
AREA DI INTERVENTO
9.1.4 Protecting Against External and Environmental Threats
9.2.1 Equipment Siting and Protection
9.2.2 Supporting Utilities
9.2.3 Cabling Security
9.2.4 Equipment Maintenance
SINTESI
R
R
R
Rischi operativi R
Riservatezza £
R
Compliance £
R
R
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
Per quanto riguarda la protezione fisica dei mezzi di elaborazione dei dati e dei supporti (magnetici, ottici, SDRAM, ecc.),
la progettazione è molto superficiale, e a volte addirittura assente; si assiste in questi casi ad una “rincorsa”, trovandosi a
cercare a posteriori di tamponare carenze strutturali (soprattutto di alimentazione elettrica e di raffrescamento) con soluzioni
di tanto in tanto addirittura amatoriali.
È invece importante, naturalmente, adottare un approccio più strutturato e non tralasciare, almeno in linea di principio,
alcun aspetto della sicurezza fisica, tra cui:
• Un impianto di climatizzazione progettato allo scopo (e non adattato dagli usi ufficio)
• Un impianto di spegnimento incendi adatto agli oggetti contenuti nella stanza, e che non sono in grado di sfuggire alle
fiamme (la normativa antincendio pensa a salvaguardare le persone, che si presuppone siano in grado di allontanarsi
dall’incendio)
• Una serie completa di controlli ambientali: almeno temperatura, umidità e fumi
• Un cablaggio strutturato pensato per la situazione, e protetto da manomissioni
• Una doppia fornitura di tutti i servizi essenziali (soprattutto, ovviamente, energia elettrica, ma anche l’acqua)
• Edifici con caratteristiche antisismiche
• Piani di manutenzione omnicomprensivi.
50
DESCRIZIONE
L’intervento parte dalla necessità di ridurre il rischio operativo, anche per contribuire alla diminuzione del premio assicurativo sulle sale CED.
Si inseriscono in questo filone gli interventi di antiincendio, antiallagamento, antiintrusione, ecc..
Rimane nel contempo necessario dimostrare la conformità alle normative vigenti in tema di sicurezza e salute sui luoghi
di lavoro, per cui nella stima degli interventi si terrà conto parallelamente di tutti i requisiti della legge in vigore in modo da
evitare sovrapposizioni e manchevolezze.
La principale motivazione per la quale investire in sicurezza fisica è data dall’osservazione che il dato informatico è estremamente vulnerabile per danni che avvengano ai supporti fisici che lo conservano.
Questa vulnerabilità si traduce in un corrispondente rischio operativo, che è opportuno diminuire quandunque possibile, nei
limiti di ragionevolezza dell’investimento (che in questo caso nella pratica diverge rapidamente).
Per alcuni punti esistono delle normative specifiche, per cui la spesa è obbligatoria: si pensi ad esempio alla normativa
antincendio ed a quelle della sicurezza sul lavoro. Tuttavia, è possibile, naturalmente, adottare una politica di minima
spesa – acquistando lo stretto indispensabile per “tacitare” la norma – o, in modo più lungimirante, sfruttare l’occasione
per migliorare le proprie infrastrutture ed inserire dei vantaggi effettivi che nel medio termine possono portare a maggiore
efficienza e/o a risparmio.
In vari casi, le spese in sicurezza fisica si prestano facilmente a campagne di comunicazione, proprio perché, essendo misure “fisiche”, sono molto concrete ed assai facilmente percepibili. Ad esempio, un Security Operations Center “blindato”,
al piano interrato di un edificio guardato a vista 24x7 da personale armato e con accessi controllati da sensori biometrici ha
sicuramente un effetto altamente emozionale – senza essere, peraltro, unicamente un investimento “di facciata”. In questi
casi la sicurezza fisica è importante tanto quanto quella installata agli accessi “di rete” del SOC.
PUNTI DI ATTENZIONE
La difficoltà maggiore, in questo tipo di situazioni, è quella di non cedere alla tentazione di estendere indefinitamente il
perimetro dell’intervento. Ad esempio, mentre si valuta la spesa per il secondo generatore, ci si rende conto che in effetti
sarebbe possibile richiedere l’installazione anche di una seconda linea di alimentazione elettrica; proseguendo nell’analisi,
che questa linea dovrebbe arrivare da una sottostazione separata; si potrebbe arrivare a richiedere che siano attivi due
contratti separati per la fornitura dell’energia elettrica, quindi due contratti anche per la fornitura del gasolio per i generatori,
e così via. Tutte misure corrette e sagge, ma che palesemente possono arrivare a squilibrare il bilancio tra il valore dei beni
protetti ed il costo delle contromisure applicate. È poi intuibile che nessun progetto può mai arrivare a conclusione quando
il perimetro viene in continuazione esteso.
È opportuno invece, naturalmente, partire con un perimetro già il più definito possibile, e con interventi ben delimitati che
soddisfino esigenze precise.
Un coordinamento complessivo è tuttavia necessario per evitare che questi interventi vivano ciascuno di vita propria, con le
inevitabili conseguenze di ridondanze, duplicazioni e inefficienze.
Se i costi di esecuzione del progetto, una volta completata la progettazione, sono ben noti (almeno in via approssimatama
affidabile), i ritorni sono molto più difficili da valutare, perché in generale qualitativi: minore rischiosità dell’infrastruttura,
migliore immagine aziendale, maggiore conformità con leggi e regolamenti.
La strada più seguita, perché generalmente produce delle stime significative, è quella di stimare i risparmi indotti dall’esistenza delle contromisure fisiche, che sono quasi esclusivamente di tipo preventivo.
• Costi di ricostruzione delle informazioni perdute (p.e. restore di un server dai nastri di backup dopo un incendio);
51
versione 2.0
• Sanzioni per indisponibilità delle informazioni stesse durante e dopo l’incidente (p.e. Codice della Privacy);
• Costi associati al tempo di fermo dei server, dovuto ad esempio ad un incendio o una mancanza di corrente, per perdita
di opportunità di business (eventualmente stimabili insieme al reparto vendite);
• Costi associati a premi assicurativi per l’infrastruttura in questione; i premi si possono invece ridurre in presenza di adeguate contromisure preventive;
• Costi associati alla gestione, in assenza di sorveglianza e di misure antincendio, antiallagamento, antintrusione, ecc., degli
incidenti stessi;
• Perdita di produttività legata all’indisponibilità dei sistemi: diretta, o indiretta perché i sistemi sono sotto indagine e non
possono essere utilizzati nel frattempo;
• Costi associati all’ammontare di tempo necessario per rimediare la situazione dopo che è stato risolto l’incidente, ed al
tempo necessario per comprendere come agire per risolvere il problema che si è verificato.
Al fine di ottenere una stima dei costi accurata, è necessario disporre di informazioni statistiche affidabili. Quelle più indicate
sono certamente quelle raccolte dall’organizzazione stessa; ma, in mancanza, è possibile prendere in considerazione dei
valori derivanti da statistiche presenti su report annuali relativi a survey condotte sul tema degli incidenti di sicurezza da
istituti o enti governativi quali Computer Security Institute, SANS, NIST, ecc.
BENEFICI / VANTAGGI
• Minore rischio operativo
• Maggiore conformità a leggi e regolamenti
• Migliore infrastruttura e maggiore efficacia della stessa
• Minori premi assicurativi
• Miglioramento immagine aziendale
5.7 Pattern “IRM” Autore: Claudio Pasi, Responsabile Div. Tecnologia, Sinfo One
PATTERN
Information Rights Management
AREA DI INTERVENTO
6.1.1 Management Commitment to Information Security
6.1.2 Information Security Co-ordination
6.1.3 Allocation of Information Security Responsibilities
6.1.4 Authorization Process for Information Processing Facilities
Independent Review of Information Security
7.1.1 Inventory Of Assets
7.1.2. Ownership Of assets
7.1.3 Acceptable use of assets
7.2.1 Classification Guidelines
7.2.2 Information labeling and Handling
8.1.1 Roles and Responsibilities
8.3.3 Removal of Access Rights
10.1.3 Segregation of Duties
52
10.10.1 Audit Logging
11.2.2 Privilege Management
11.2.4 Review of User Access Rights
15.1.4 Data Protection and Privacy of Personal Information
SINTESI
R
£
R
Rischi operativi R
Riservatezza R
R
Compliance £
R
R
Disponibilita`
Applicazioni R
Informazioni
Efficienza processi
La tematica dell’Information Rights Management si colloca nell’ambito delle logiche di accesso alle informazioni aziendali.
DESCRIZIONE
Con il termine Information Rights Management (IRM) si identifica una metodologia che permette attraverso l’adozione di
procedure organizzative e il supporto di opportuni strumenti tecnologici, di regolamentare l’accesso alle informazioni aziendali, definendone in maniera puntuale per ogni elemento o gruppo di un’organizzazione, i diritti corrispondenti in lettura,
modifica, eliminazione, copia, ecc: normalmente ci si riferisce ai cosiddetti dati non strutturati, intendendo quelle informazioni (ad esempio i file) che per loro natura non sono memorizzate all’interno di contesti strutturati quali possono essere i
database o i sistemi di Content Management.
Information Rights Management è prima di tutto, quindi, un approccio aziendale alla gestione delle informazioni che si avvia
attraverso un’analisi precisa dell’organizzazione, dei processi aziendali e delle informazioni “critiche” e dell’interazione tra
queste componenti, per identificare in maniera puntuale
- chi,
- con quale modalità
- e per quale fine accede alle informazioni stesse.
Il risultato dell’analisi è un modello di gestione che si evolve in stretta connessione con l’organizzazione ed i processi aziendali, e che può essere implementato attraverso l’utilizzo di soluzioni tecnologiche ma, soprattutto, con la stretta definizione
di policy di sicurezza.
Il modello può essere applicato all’intera azienda oppure limitato a precise aree aziendale, per le quali si identifica una
maggior sensibilità delle informazioni da proteggere (ad esempio l’area Ricerca e Sviluppo o l’area di Gestione delle Risorse
Umane).
Un modello di IRM, in sintesi, permette di raggiungere i seguenti obiettivi:
• Accesso alle informazioni regolamentato da modelli e politiche definite sulla base
- della tipologia, importanza e classificazione dell’informazione da parte del business aziendale
- dell’organizzazione aziendale
- del ruolo delle persone all’interno dell’organizzazione.
• Controllo sulle operazioni eseguite sulle informazioni con possibilità di limitarne o impedirne la creazione, la modifica, la
copia, la stampa, le operazioni copy&paste, le operazioni di printscreen, la cancellazione, ecc.
• Crittografia delle informazioni secondo i più diffusi standard aziendali.
53
versione 2.0
• Possibilità di fissare un tempo limite (offline period) per abilitare l’accesso alle informazioni riservate all’interno ed all’esterno dell’azienda senza la necessità di essere connessi alla rete aziendale.
• Possibilità di abilitare politiche di auditing sulle informazioni al fine di misurare da chi, quando e in che modalità le informazioni stesse sono state accedute.
Gli ultimi studi di settore stanno mostrando come, sempre di più, gli ICT manager e i Security Manager vedano nell’uso
improprio e nell’accesso non autorizzato alle informazioni da parte di personale interno all’azienda due principali preoccupazioni in termini di sicurezza (Fonte Computer Economics - “Trends in IT Security Threats: 2007”). La facilità con la quale,
in virtù dell’evoluzione tecnologica e della modalità di interazione di ogni singolo utente con internet, sia possibile veicolare
informazioni all’esterno delle aziende rende sempre più necessario spostare la focalizzazione delle aziende stesse della protezione dalla salvaguardia dell’infrastruttura dagli attacchi in ingresso alla salvaguardia delle informazioni essenziali contro
minacce a tecnica mista (Trojan, Worms, File infector, spyware, backdoor, ecc) e perdite di dati accidentali o dolose.
A supporto di questa tendenza i seguenti dati:
• L’80% delle informazioni aziendali viene violato all’interno dell’azienda stessa. Solo il 10% di queste azioni viene scoperto
e solo nell’1% di questi casi viene individuato il colpevole.
• Ogni settimana circa 3.000 portatili vengono trovati incustoditi negli otto principali aeroporti europei, con la possibilità
assai concreta di perdere dati sensibili.
• L’85% dell’IT Professionale è preoccupato per la perdita di proprietà intellettuali (Fonte Forrester - Enterprise and SMB
Security Survey, North America and Europe, Q3 2008).
• Il 73% dell’IT manager del Nord America è molto preoccupato circa l’utilizzo non sanzionato dei tools Web 2.0 (Fonte
Forrester - June 2008 US Web 2.0 On Line Survey (the bas ewas 262 US Enterprise IT managers).
• Il 67% delle violazioni dei dati nel 2008 sono state facilitate da “errori significativi” involontari di policy di sicurezza da
parte di utenti interni (Data Breach Investigation Report 2010 (Dibr) di Verizon Business)
Si consideri, nella valutazione dell’importanza dell’adozione di uno strumento di Information Rights Management, come
le organizzazioni stiano generando sempre di più informazioni, e come queste siano per l’80% di tipo non strutturato: per
questo motivo occorre la consapevolezza della necessità di strumenti che proteggano anche questo tipo di informazioni,
siano essi messaggi di posta elettronica, fogli di calcolo o documenti di testo.
Altra importante ragione per l’adozione di strumenti di Information Rights Management è la compliance alle normative vigenti: quante informazioni sensibili sono memorizzate in documenti non protetti e potenzialmente accessibili da personale
non autorizzato.
Ultimo punto da considerare è la protezione delle informazioni dagli accessi degli utenti amministratori di sistema, utenti
solitamente senza limiti di accesso: l’implementazione di una soluzione di IRM, e la delega della gestione dei contenuti da
proteggere alle realtà di business permette di evitare che questi utenti possano vedere informazioni sensibili o comunque
riservate.
L’adozione di una soluzione di IRM permette di realizzare in parte la segregation of duties, separando la gestione amministrativa della soluzione stessa dalla gestione delle informazioni e del relativo potere di accesso.
PUNTI DI ATTENZIONE
Il successo dell’implementazione di una soluzione di Information Right Management dipende dal coinvolgimento che l’intera
organizzazione aziendale avrà nel disegno e nella gestione della soluzione stessa. La protezione delle informazioni non può
essere un problema di esclusiva pertinenza dei CIO o dei CISO, ma richiede la delega alle funzioni aziendali, al business,
veri conoscitori dell’importanza delle informazioni, delle persone che possono accedere ad esse e con quali diritti.
54
L’amministrazione tecnologica della soluzione rimarrà in carico alla struttura IT, ma la gestione dei contenuti da proteggere
dovrà essere delegata ai veri “owner” dell’informazione, ossia le altre funzioni o organizzazioni aziendali (ad esempio Human
resources, Amministrazione e Controllo, Uffici legali,Ricerca e Sviluppo, Marketing, ecc).
La valutazione del ritorno di investimento derivante dall’adozione di una soluzione di Information Rights Management non
è semplice in quanto non è possibile quantificare in anticipo per ogni realtà aziendale quanto sia il costo aziendale per la
perdita di informazioni importanti per il business, o per la pubblicazioni di informazioni sensibili.
Si indicano di seguito alcune delle voci di costo da considerare nella valutazione del quanto possa essere importante in
termini economici un sistema di IRM:
- Perdite di fatturato derivanti dalla “fuga” di informazioni strategiche verso aziende concorrenti;
- Costi associati alle sanzioni derivanti dalla non rispondenza alle normative sulla protezione delle informazioni sensibili;
- Perdita di immagine derivante dalla “fuga” di informazioni riservate;
- Costi per l’indisponibilità delle informazioni ;
L’adozione di strumenti di Information Rights Management, d’altra parte, può avere voci di risparmio non strettamente legati
al tema della sicurezza, quali ad esempio:
• risparmio sui costi di stampa di documentazione riservata (carta, stampanti, ecc) che l’adozione di uno strumento di IRM
permette di rendere disponibile in formato elettronico e inviabile via mail o attraverso la pubblicazione su intranet aziendale;
• aumento dell’efficienza dei processi aziendali impattati da questo processo di digitalizzazione e cifratura delle informazioni;
• diminuzione dei costi operativi relativi all’archiviazione di documentazione cartacea riservata.
BENEFICI / VANTAGGI
• Sicurezza delle informazioni all’interno ed all’esterno dell’azienda;
• Possibilità di integrazione con strumenti aziendali Active Directory;
• L’integrazione con gli strumenti di Office Automation garantisce che la gestione operativa quotidiana non è impattata da
una maggior complessità o da un maggior tempo nell’esecuzione delle attività.Rispetto dei principi “need to know” e
“segregation of duties”.
• Supporto alle attività di audit e verifiche periodiche.
• Supporto alle attività di riorganizzazione aziendale.
55
versione 2.0
5.8 Pattern “Security Assessment Industriale” Autore: Enzo M. Tieghi, ServiTecno S.r.l. e consigliere AIIC
PATTERN
Security Assessment delle reti e dei sistemi per l’automazione industriale e per il controllo
di processo
AREA DI INTERVENTO
11.3.2 Unattended user equipment
12.6.1 Control of Technical Vulnerabilities
13.1.2 Reporting Security Weaknesses
14.1.1 Including Information Security in the Business Continuity Management Process
14.1.5 Testing, Maintaining and Re-Assessing Business Continuity Plans
15.2.1 Compliance with Security Policies and Standards
15.3.1 Information Systems Audit Controlss
SINTESI
R
R
R
Rischi operativi £
Riservatezza R
R
Compliance R
R
R
Disponibilita`
Applicazioni R
Informazioni
Efficienza processi
Proteggere i sistemi informatici è critico in ogni ambito, ma lo è ancor di più nel settore industriale e nelle utility, dove impianti e macchinari sono gestiti da operatori e da sistemi di automazione e controllo sempre più spesso collegati tra loro, alle
reti aziendali e, in definitiva, anche se non sempre direttamente, al web.
Eventuali danni generati da un problema ai sistemi di automazione e controllo di un processo produttivo generalmente non
si limitano ad aspetti economici, ma possono avere conseguenze pericolose per l’impianto stesso, per le persone, l’ambiente
e le cose. Oltre ai danni di immagine. Proviamo ad immaginare, solo per ipotesi, alle conseguenze derivanti da un incidente
ad una centrale elettrica, ad un blocco del sistema bagagli in un aeroporto, ad un problema del sistema di controllo di processo in un reattore chimico o in un depuratore, un’interruzione del telecontrollo di una diga o di un acquedotto, e ancora
in un nodo ferroviario, una fonderia, una linea di produzione farmaci, di confezionamento latticini, o un ospedale.
Minacce e vulnerabilità alle quali sono esposti i sistemi di automazione possono essere le stesse che si riscontrano sui sistemi e sugli ambienti d’ufficio ma altre volte sono sconosciuti e diversi. La tipologia dei malintenzionati, infine, può spaziare
dalla ignoranza e sabotaggio interno, alle menti dello spionaggio industriale (esempio ne è la diffusione in Stuxnet avvenuta
nell’estate 2010) sino ai terroristi (come appurato anche da casi internazionali, da esponenti di CIA, FBI e da altre fonti).
Alcuni riferimenti sulla security industriale e sugli incidenti occorsi e censiti sono reperibili sul blog Sicuramente di Clusit.
Avere una chiara visione dello stato dell’arte della sicurezza dei sistemi industriali pone l’azienda nelle condizioni di definire
un percorso per la loro messa in sicurezza focalizzato sugli interventi che indirizzano le problematiche evidenziate dal Security Assessment. Un security assessment rappresenta quindi un primo step per la comprensione del livello di sicurezza
esistente e per capire come sviluppare gli investimenti riducendo, se non annullando, il rischio di investire in interventi che
non risolvono i problemi, ma che, a volte, addirittura li aggravano.
DESCRIZIONE
Lo scopo di un Security Assessment per reti e sistemi di automazione e controllo di processo è quello di rilevare, tramite
specifiche attività di analisi, il livello di sicurezza ed esposizione al rischio delle componenti tecnologiche e dei processi
deputati alla loro gestione e controllo.
56
Il fine ultimo è quello di individuare puntualmente dove e come intervenire per ridurre la probabilità di accadimento, o
quantomeno i conseguenti impatti sul business aziendale, di potenziali malfunzionamenti, incidenti di sicurezza e problemi
di indisponibilità di servizio di natura sia esterna sia interna all’azienda.
L’importanza di avere una chiara visibilità circa lo stato dell’arte della sicurezza dei sistemi deputati al controllo di processo è
fondamentale: una fermata non prevista di un sistema di controllo può comportare l’interruzione della produzione o dell’erogazione di un servizio o di eventuali danni all’impianto stesso, a cose, a persone e all’ambiente.
Il security assessment dovrà quindi verificare l’accessibilità e la segregazione dei componenti critici che costituiscono il
sistema di controllo di processo nonché la segmentazione delle reti così da evitare che eventuali problemi si possano propagare in modo non controllato anche ad altri componenti. In questa attività ci possono guidare alcuni standard internazionali,
ed in particolare ISA99 (emesso da International Society for Automation and Control www.isa.org/isa99). Il modello di ISA99
prevede la modellazione di reti e sistemi mediante la costituzione ed adozione di “Zone” e “Conduit”.
Da segnalare che sono disponibili anche altri standard e metodologie a livello internazionale: alcuni sono specifici per settori, come ad esempio il NERC-CIP, divenuto norma in USA per il mondo energia, oppure GAMP per i sistemi utilizzati nelle
produzioni del Life Science. Esistono sul mercato anche alcuni tool software per verificare il posizionamento (ed eventuali
gap) rispetto a tali standard.
Da un punto di vista operativo i passi da seguire per l’esecuzione dell’Assessment sono:
• Definizione del perimetro e dello scopo
• Raccolta documentazione aggiornata sulle reti e sulle configurazioni dei sistemi
• Valutazione dei livelli di protezione con riferimento agli standard (es. ISA99)
• Verifica dispositivi ed eventuali test su connessioni, protocolli, dispositivi, ecc.
• Report e valutazione degli impatti derivanti da eventuali malfunzionamenti e/o incidenti
Il Security Assessment va ripetuto periodicamente sia per poter valutare l’efficacia degli interventi effettuati sia per rilevare
eventuali nuove vulnerabilità e minacce intervenuti in seguito a cambiamenti tecnologici, organizzativi o normativi intervenuti nel periodo di tempo intercorso dall’ultimo assessment.
Ulteriore possibile step (valutando attentamente impatti sui processi controllati) è un “penetration test”, da eseguire seguendo, a titolo di esempio, lo standard di riferimento mondiale OSSTMM (www.osstmm.org).
• Tutela dell’immagine aziendale
• Ottimizzazione degli investimenti in sicurezza
• Individuazione e conseguente gestione dei rischi tipici dei sistemi di controllo di processo
• Conformità alle normative di settore nazionali e internazionali
• Contributo alla continuità del business aziendale
PUNTI DI ATTENZIONE
Ecco qui di seguito i punti cardine di un buon programma per la Security Industriale:
Assessment – Valutazione. Avere chiara la situazione e tenere aggiornata la documentazione, avendo una visione dei confini,
degli scopi, delle responsabilità e di quant’altro sia necessario, consente di evitare investimenti e attività inutili. Ecco una
breve check-list per iniziare: documentazione aggiornata di rete/sistema; elenco dei componenti e delle applicazioni, dei dati
gestiti e delle connessioni per identificare anelli deboli; elenco delle persone che utilizzano ed hanno accesso ai sistemi ed
ai dati; policy e procedure presenti ed utilizzate; altre informazioni che possano risultare utili per una “fotografia” della rete
e del sistema da proteggere.
57
versione 2.0
Hardening - Sicurezza del sistema e delle applicazioni. Spesso nei sistemi e nelle applicazioni sono già previste all’interno
funzioni di “security”: è utile valutarle ed attivarle correttamente, disattivando quelle funzioni che potrebbero indurre vulnerabilità nel sistema e nelle applicazioni.
Firewall -Protezione Perimetrale. E’ importante definire il perimetro e mettere in pratica le azioni per difenderlo. Di solito
l’ambito perimetro è il sistema e/o la rete di produzione; si tende a separarlo dalla rete “aziendale/gestionale” che, avendo
quasi sempre accesso ad Internet, può essere veicolo di malware. Le macchine in produzione, infatti, possono non essere
protette dal malware in modo puntuale quanto quelle della rete “enterprise”. Si pongono quindi uno o più firewall come protezione tra le due reti. Guardiamo anche alle estensioni (connessioni esterne per manutentori, fornitori, outsourcer, Wireless,
ecc.) che potrebbero “allargare” il perimetro
Firewall - SEG-SEG (Segmentazione e Segregazione). Segmentare ulteriormente la rete in “compartimenti” permette di attuare quella che viene chiamata la “protezione-in-profondità”. E’ importante segregare gli asset critici (server condivisi, accessi
da remoto, access-point wireless, ecc.) in zone ben definite (dichiarate DMZ, Zone De-Militarizzate, terre di nessuno) con
policy basate sul controllo di accessi con un’attenta gestione dei privilegi.
Monitoraggio Performance dei sistemi e dei Log: storicamente i sistemi in produzione sono soggetti a manutenzione meno
assidua rispetto ad altri sistemi in azienda. I motivi possono essere l’impossibilità di riavviare i sistemi per l’installazione di
patch o semplicemente il fatto che il sistema è considerato una “black-box” funzionante ed integrata in cui non è possibile
intervenire. Rimane quindi come indicatore dello stato di salute del sistema la periodica valutazione delle performance e
l’analisi dei log di eventuali fault o warning.
Verifica Periodica o dopo eventuali problemi (lesson learned). Come per tutti i programmi di gestione e miglioramento è
necessario prevedere dei controlli da effettuare periodicamente o dopo problemi che si possano verificare. Ciò permette di
valutare se le contromisure adottate sono state efficaci e se lo potranno ancora essere dopo eventuali variazioni al sistema
o al contesto di funzionamento.
Come molti altri sistemi che gestiscono informazioni all’interno dell’organizzazione dell’azienda, anche i sistemi di controllo
(PLC, SCADA, DCS, MES, ecc.) utilizzati in produzione fanno parte di processi spesso critici per l’azienda.
La continuità della produzione, l’affidabilità e la sicurezza degli impianti e la tutela della proprietà intellettuale permettono
all’azienda di mantenersi solida e competitiva, garantire le consegne e le obbligazioni prese con i propri clienti, mantenere
e migliorare le proprie quote di mercato e la propria reputazione.
La conoscenza di dettaglio del livello di integrità e sicurezza dei sistemi, delle informazioni relative a come si stanno comportando i sistemi che gestiscono il nostro impianto, a cosa stiamo producendo e a come lo stiamo producendo, all’OEE, alle
rese, agli scarti e ad ogni altra informazione relativa alla produzione ed ai prodotti che escono dalla linea e vengono instradati
nella Supply Chain, molto spesso è anche un preciso requisito per rimanere sul mercato.
Per ulteriori approfondimenti, sul sito di Clusit (Associazione Italiana per la Sicurezza Informatica) www.clusit.it è disponibile un Quaderno dal titolo “Introduzione alla protezione di reti e sistemi di controllo ed automazione (PLC, SCADA, DCS,
ecc.)”.
Tra gli elementi di valutazione per la scelta se investire o no in questo pattern bisogna considerare:
• costo di mancata produzione o interruzione del servizio in seguito ad un incidente di sicurezza informatica;
• costo di ricostruzione delle informazioni
• risarcimenti/penali per costi di mancata consegna dei prodotti/servizi ai clienti
• costo e probabilità delle eventuali multe comminate per inadempienza a standard nazionali e internazionali;
• impatti sulla competitività dell’azienda in seguito alla compromissione di segreti industriali/proprietà intellettuali
• danni collaterali ad impianto, persone, ambiente
58
• costo e impatti sull’immagine aziendale nel caso in cui si dovesse verificare un incidente con conseguenze su persone
e/o sull’ambiente
• costi per la verifica della conformità a regolamenti e normative
BENEFICI / VANTAGGI
• Migliore conformità a normative e regolamenti
• Riduzione dei costi assicurativi
• Incremento della sicurezza del personale
• Incremento della sicurezza dell’ambiente
• Tutela del marchio
• Miglioramento dell’immagine aziendale
• Riduzione dei rischi operativi
• Riduzione dei costi di verifica della conformità
5.9 Pattern “PCI-DSS” Autore: Stefano Saibene, Deutsche Bank - PBC - Project & Process Management
PATTERN
Payment Card Industry – Data Security Standard
AREA DI INTERVENTO
9.1.4 Protecting Against External an Environmental Threats
10.0.1 Electronic Commerce
10.9.1 On-line Transaction
SINTESI
R
R
R
Rischi operativi £
Riservatezza £
£
Compliance £
R
£
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
L’incremento del volume d’acquisti effettuati tramite carte di credito e di debito e lo sfruttamento delle tecnologie e dei sistemi di pagamento a fini illeciti rende l’ambito della sicurezza nei modelli di business sempre più importante.
Nel tempo i principali Circuiti Internazionali hanno avviato vari programmi di sicurezza – si pensi a Account Information
Security Program per Visa International, Site Data Program per Mastercard, DSOP per AMEX, ecc. - che non sono risultati
particolarmente incisivi poiché ciascun circuito ha fissato dei propri requisiti per la stessa tematica e di fatto rendendo la
reale applicabilità confusa ed inefficiente.
Al fine di armonizzare i differenti programmi nel settembre 2006 viene istituito il Payment Card Industry Security Standard
Council 18 (PCI SSC) che si pone come obiettivi lo sviluppo e gli aggiornamenti, la pubblicazione e la distribuzione degli
standard di sicurezza per la protezione dei dati dei titolari di carte.
Lo standard PCI DSS stabilisce i requisiti di sicurezza, nell’ambito dei sistemi di pagamento, ove vengano trasmessi e/o
memorizzati dati relativi a carte di credito e di debito.
18
https://www.pcisecuritystandards.org/
59
versione 2.0
DESCRIZIONE
Attraverso lo standard PCI viene imposta l’osservanza di specifici requisiti di sicurezza (6 obiettivi e 12 requisiti) a tutte le
società che gestiscono i dati relativi alle carte di pagamento.
Lo standard è rivolto a tutti i Membri (Acquiring Members ovvero gli accettatori di pagamenti effettuati su terminali POS/
ATM) affiliati ai circuiti di carte di credito, i quali devono obbligatoriamente assicurare che venga esteso a tutti gli esercenti
(merchant) e fornitori di servizi (centri applicativi, service provider, ecc.), ad essi collegati.
Questo processo prevede che ogni acquirer debba informare i propri merchant (classificati in base ai volumi di transazioni:
livelli da 1 a 4 per i merchant e da 1 a 3 per gli IPSP Internet Payment Service Provider) sull’importanza della gestione sicura
dei dati e verificarne lo stato di compliant degli stessi. Viene condiviso un programma che prevede l’allineamento “graduale
e progressivo” allo standard PCI DSS, così come richiesto dai Circuiti Internazionali, con il supporto di specifica documentazione di supporto e un questionario di autovalutazione.
Agli acquirer è in carico l’attività di aggiornare trimestralmente i Circuiti Internazionali, mediante auto-certificazione, sullo
stato dei merchant ed ISP soggetti a programmi di compliance.
Il merchant ha due possibilità: 1) identificare un responsabile della sicurezza interno all’azienda, in grado di raggiungere
le richieste del piano di compliance, oppure 2) rivolgersi ad un QSA (Qualified Security Assessor). In quest’ultima ipotesi si
passa allo stato di Engaged e Preparing (“The Merchant has been contracted to the QSA and made aware of requirements &
is doing a gap analysis”) ed entro i 30/40 giorni successivi il merchant opera con il QSA al fine di permettere a quest’ultimo
di formalizzare una Gap-Analysis con un piano di massima delle attività previste (remediation) che verranno svolte nei mesi
successivi con l’obiettivo di raggiungere lo stato di “Full compliant”.
Il QSA presenta tale piano ai Circuiti. Questa condizione permette al merchant di passare così allo stato di Committed: “The
Merchant is either signed up with a QSA & has performed a gap analysis and preparing remediation plan/seeking budget
for it”. Anche il QSA informa i circuiti degli avanzamenti del progetto.
Finalmente raggiunta la “Full compliance” quest’ultima condizione dovrà essere mantenuta con periodiche attività di verifica prestando particolare attenzione ai nuovi requisiti della normativa, che è in continuo e progressivo aggiornamento.
Lo standard PCI DSS è in primis un obbligo di compliance imposto dai Circuiti Internazionali, tuttavia considerare il presente pattern come un’opportunità e non un’imposizione (che comporta in caso di inottemperanza penali di rilevante entità
differenziate rispettivamente nel caso di compromissioni o nel caso non sia stato attivato un piano di compliance) dovrebbe
essere il corretto approccio per sfruttare i numerosi benefici che ne derivano.
Essere certificati PCI DSS implica l’opportunità di nuovi business (è il caso di merchant che gestiscono pagamenti per altri
clienti ai quali danno evidenza di questa certificazione come elemento qualificante e distintivo) e permette l’integrazione di
nuovi ed innovativi servizi di pagamento in sicurezza (ambito pagamenti in mobilità da parte di società telefoniche nonché
ambito e-commerce). Inoltre, considerando l’equazione dati=identità=denaro, è facile comprendere l’importanza di ridurre
il rischio di danno reputazionale su un tema tanto delicato come il trattamento dei dati di clienti ove l’aggravante di possibili
frodi ha un immediato riscontro economico.
Attivare per tempo un piano di compliance implica evitare costosi (perché urgenti) piani di remediation. Alcune aziende
quotate, che hanno subito intrusioni ed attacchi informatici con pesanti conseguenze, hanno avuto ripercussioni su quotazioni di borsa dovendo rispondere ai propri azionisti. Rimane sempre il rischio (già attuato in numerose circostanze) di
essere “sconvenzionati” (non poter più accettare i pagamenti elettronici dei vari circuiti internazionali). A tale proposito
molti business non potrebbero oggi sopravvivere senza questa modalità e varie società sono fallite proprio per questa conseguenza.
60
PUNTI DI ATTENZIONE
• È opportuno evidenziare sempre a merchant e fornitori, che gestiscono dati carte di credito sui propri sistemi, le responsabilità a loro carico. A tale proposito gli acquirer devono inserire nei contratti specifici richiami allo standard PCI DSS e
alle previste sanzioni per inosservanza delle clausole contrattuali.
• Gestione costante del flusso di informazioni dal merchant o direttamente dal QSA in merito ai progressi nelle attività di
compliance che vengono poi inoltrate verso i Circuiti Internazionali. Sempre tali circuiti impongono ai propri membri
(acquirer) di tenersi aggiornati tramite le business publications (member letters, announcements, newsletters, op. regulations, manuali e documentazione tecnica).
• In fase di gap analysis evitare di estendere eccessivamente il perimetro soggetto allo standard PCI DSS. È buona norma
attenersi ai sistemi informatici ove transitano o sono memorizzati dati carte di pagamento e l’ambito TLC impattato nello
scope. Utilizzare i tools previsti da PCI DSS. Dividere le interviste interne all’azienda coinvolgendo separatamente gli ambiti applicativi e networking.
• Fare ricorso, ove previsto, alla cifratura degli archivi.
• Chiedere al cliente di non mantenere in alcun modo dati relativi a carte di credito/debito su supporti magnetici (hard
disk drive o tape), ottici, memorie ecc. Spesso i dati delle carte credito/debito vengono conservati, dalle aziende, per più
settimane dopo una richiesta di autorizzazione per varie finalità (ricerche di marketing, identificazione univoca del cliente,
analisi delle frodi e creazione del profilo cliente). Gestire la dismissione dei sistemi di storage, la sostituzione del parco
macchine, il “fine vita” di specifici supporti dando priorità alla rimozione dei dati relativi alla banda magnetica ed i codici
di verifica. Procedere, con il principio dei “quattro occhi”, alla cancellazione/distruzione sistematica dei dati obsoleti/
inutili presenti su archivi. Sarebbe opportuno, inoltre, un verbale firmato da chi ha presenziato alle attività a garanzia
dell’attività svolta. Le società che gestiscono dati relativi a carte di credito sono pertanto tenute a cancellare i dati in modo
sicuro anche per altre ragioni. Si tratta di un obbligo stabilito anche dalla normativa Privacy (D.Lgs. 196/2003) e, in termini piu’ generali, dal Provvedimento del Garante del 13 ottobre 2008 (G.U. nr. 287, 9 dicembre 08). Per ottemperare
appieno alla normativa vigente, senza il rischio di incorrere nelle severe sanzioni penali e civili previste e’ indispensabile
procedere con la distruzione definitiva dei dati “con efficacia” (la sola formattazione non è sufficiente. Occorre adottare
strumenti progettati per la cancellazione sicura e selezionare prodotti certificati da enti od autorita’ indipendenti).
Ipotizzare la liability finanziaria dopo un caso di compromissione (rischio di non essere conformi allo standard).
Può essere difficile sostenere i costi finanziari legati alle manomissioni per via di:
• Obblighi contattuali non rispettati (rif. member letter e bulletin);
• Danni reputazionali e perdite finanziarie (relazione giustificativa agli azionisti per le società quotate in borsa);
• Perdite Issuing/Acquiring (transazioni autorizzate/ammontare frodi);
• Se è stato compromesso il contenuto della traccia magnetica viene applicato il programma DCRS (Data Compromise
Recovery Solution);
• Rischio penali: i Circuiti Internazionali contrattualmente, in caso di violazioni, multano l’acquirer;
• Conseguente rivalsa diretta (pagamento della penale come notificata dai circuiti) od indiretta (aumento delle commissioni) sul merchant;
• I costi delle indagini sono a carico del merchant (Forensic investigation cost);
• Possibile revoca del merchant (conseguenze di non accettare più le carte di pagamento);
• Frodi e penali come fattore non competitivo (perdite finanziarie);
• Costi aggiuntivi per piani di remediation, imposti dai circuiti, in un breve arco temporale;
61
versione 2.0
• Conseguenze negative sulla clientela dovute alla mancata disponibilità di servizi di pagamento (ridotto fatturato e perdita
di clienti).
• Costi diretti (penali) ed indiretti (danno reputazionale);
• Analisi di come ridurre i dati relativi alle carte di pagamento sui sistemi informatici. Considerare modi alternativi per
ottenere gli stessi obiettivi (ambiti operativi, marketing ed antifrode) senza memorizzare dati non necessari ai fini della
richiesta di autorizzazione.
A fronte di essere individuati dai circuiti internazionali come non certificati PCI DSS:
• Rischio penali;
• Costi aggiuntivi per piani di remediation imposti dai circuiti in intervalli temporali stabiliti (30/60/90 gg.).
BENEFICI / VANTAGGI
• La principale motivazione di ogni merchant e di ogni società che gestisca dati carte di pagamento è quella di poter operare
in armonia con lo standard PCI DSS a tutela del proprio business e con la consapevolezza di gestire responsabilmente e
in estrema sicurezza i dati dei propri clienti.
• Nella condizione di committed, dopo aver intrapreso i primi passi con la certificazione PCI DSS, il merchant è già al riparo
dalle previste sanzioni.
• Conformità ed adempimenti normativi previsti dai Circuiti Internazionali. Ovvero maggiore sicurezza ed adeguamento ai
“mandati”.
• Minori rischi operativi (ridotta gestione delle “dispute”, “chargeback”, ecc.).
• Nuove opportunità di business (vantaggio competitivo).
• Responsabile coinvolgimento del personale preposto ai piani di compliance ed acquisizione di nuove ed innovative competenze a supporto della sicurezza.
5.10 Pattern “DLP” Autore: Andrea Zapparoli Manzoni, Principal Security Consultant, B.U. Security Gruppo Terasystem
PATTERN
DLP (Data Loss prevention)
AREA DI INTERVENTO
Principali aree interessate:
12.5.4 Information Leakage
15.1.2 Intellectual Property Rights
15.1.3 Protection of Organizational Records
15.1.4 Data Protection and Privacy
NOTA: poiché il DLP riguarda la sicurezza delle informazioni aziendali, sono praticamente interessate
tutte le aree dello standard ISO 27001, in particolare quelle relative all’IRMg
SINTESI
R
£
R
Rischi operativi 62
R
Riservatezza £
£
Compliance R
£
£
Disponibilita`
Applicazioni R
Informazioni
Efficienza processi
Spesso per difendere il patrimonio informativo aziendale ci si limita a difendere il perimetro esterno e le linee di comunicazione; questo riduce sicuramente i rischi di attacchi malevoli dall’esterno, ma non garantisce la riservatezza delle informazioni, che invece possono uscire dall’Azienda in molteplici forme e per svariati motivi, quali:
• Impiegati infedeli: i quali possono accedere a quantità di informazioni preziose e trasportarle fuori dall’azienda con i mezzi
più disparati, ed apparentemente innocenti, quali: Memorie USB, CD e DVD, I-pod, cellulari, etc.
• Impiegati distratti: i quali possono smarrire, per esempio, la Pen-Drive su cui avevano, lecitamente, copiato informazioni
riservate per poterle travasare sul PC di casa, o del collega, e continuare a lavorare (quando non smarriscano direttamente il PC!)
Si aggiunga poi che l’aumentata complessità delle tecnologie porta a norme e riferimenti complessi, che talvolta al loro stesso interno possono avere delle vulnerabilità (o semplicemente possono essere difficili da applicare).
La tecnologia DLP è in fase evolutiva, ma comunque, a dispetto dei prodotti non sempre maturi, può già offrire buoni risultati
alle Aziende che devono proteggere i loro dati da una divulgazione impropria: il mercato è ancora in buona parte appannaggio di Fornitori di nicchia, ma anche i grandi player (CA, IBM, EMC2, ORACLE, etc.) si sono orienti decisamente su queste
problematiche.
NOTA: essendo il DLP collegato all’IRM, si faccia anche riferimento al pattern “IRM”.
DESCRIZIONE
Un Sistema DLP deve proteggere i dati lungo tutto il loro ciclo di vita, e pertanto deve considerare, e definire esattamente, i
livelli di protezione per tutti gli ambienti ove possono verificarsi perdite di dati:
• data in motion: dati in movimento (dati che lasciano la rete attraverso posta elettronica o traffico web come HTTP, IM FTP
etc.);
attività utili:  crittografia, filtraggio ed eventuale blocco del contenuto in uscita, sia esso un messaggio e-mail, un messaggio istantaneo, un trasferimento di file peer-to-peer, posting sul web o altri tipi di traffico
• data in usage: dati in uso: dati che vengono stampati, salvati con nome, copiati su dispositivi USB o su altre unità rimovibili;
attività utili:  monitoraggio dei dati in uso negli end-point e applicazione dei relativi controlli
• data at rest: dati a riposo (immagazzinati o archiviati); dati contenuti nel data center (file in condivisione, repository dei
contenuti come SharePoint, Documentum, DB, SAN/NAS);
attività utili:  monitoraggio dei dati presenti su server, database, computer, desktop, portatili, e su altri tipi di repository,
con possibilità di crittografia, filtraggio ed eventuale blocco del contenuto
Pertanto un Sistema DLP presuppone l’esistenza delle seguenti funzionalità di base:
• Policy management: definizione enforcement e gestione centralizzata di Policy, Standard, Regole, Procedure e quant’altro
serve per proteggere i nostri dati, in accordo con la Normativa e gli Standard di settore
• Content analysis: analisi dei dati da proteggere e del necessario livello di protezione in base al contenuto dei dati stessi, e
non solo al Nome del File o del DB; ciò comporta conoscenza dei propri processi e dei dati gestiti, ed una classificazione
adeguata
• Content coverage: possibilità di protezione dei dati in tutti i momenti del loro ciclo di vita: dalla preparazione, all’utilizzo,
alla trasmissione e alla archiviazione, qualunque siano i dispositivi usati
In aggiunta, un Sistema DLP efficace deve disporre di funzionalità aggiuntive, quali:
• Gestione delle minacce: funzioni di rilevazione, classificazione, controllo e reporting, atte a valutare il rischio associato a
ogni situazione e ad impedire l’uso improprio delle risorse critiche
• Garanzia conformità: funzioni atte ad aiutare nell’individuazione delle informazioni critiche soggette a normativa
63
versione 2.0
Essendo il DLP strettamente integrato con i processi IRM e DAM, driver e motivazioni relative a questi sistemi hanno valore
anche per il DLP stesso; nello specifico poi, i principali Driver che spingono verso l’implementazione di un Sistema DLP
sono:
• Compliance: necessità, in base a Standard e Normative di proteggere adeguatamente tutte le informazioni importanti
(sensibili, private, segrete, etc.) definendo opportune policy e controlli per ciscun passo del loro ciclo di vita
• Sicurezza: necessità di proteggre le informazioni aziendali non solo dagli attacchi esterni, ma anche dalle perdite
interne
• Organizzazione: necessità di ottimizzare i vari processi di sicurezza: la classificazione delle informazioni e la definizione
dei relativi livelli di sicurezza (protezione) può fornire il punto di partenza per una ottimizzazione dei processi stessi
A supporto di queste motivazioni, può essere utile ricordare che, secondo le statistiche dei vari analisti di mercato:
• L’80% delle informazioni aziendali viene violato all’interno dell’azienda stessa; meno del 10% di queste azioni viene scoperto e quasi mai viene individuato il colpevole.
• Ogni settimana migliaia di portatili vengono trovati incustoditi nei vari aeroporti, con la possibilità concreta di perdere dati
sensibili.
• Il 70% delle violazioni dei dati nel 2008 sono state facilitate da errori involontari nell’applicazione di policy di sicurezza da
parte di utenti interni .
PUNTI DI ATTENZIONE
Un primo punto riguarda il fatto che il DLP (Data Loss prevention) rappresenta una delle attività più importanti in un Progetto
generale di protezione dati, e che quindi va valutato insieme ai corrispondenti Progetti IRM e DAM; buona parte delle attività
sono infatti comuni ai tre progetti.
Un secondo punto importante riguarda il fatto che , prima di scegliere e implementare un qualsiasi Sistema DLP, occorre
tenere presenti i prerequisiti indispensabili al suo corretto funzionamento:
• Classificazione: occorre definire quali devono essere considerate importanti, e come devono essere protette
• Scenari: occorre definire quali sono gli scenari di riferimento per il fenomeno
• Data Base: occorre identificare dove sono le informazioni da proteggere
• Processi: occorre identificare i processi dove vengono trattati i dati da proteggere
• Exit point: occorre identificare gli exit point dove la diffusione delle informazioni è più probabile
• Utenti: occorre definire gli utenti che possono avere accesso alle informazioni e quali di loro possono essere la causa di
Information Leakage
Pertanto, l’implementazione di un Sistema DLP è un processo iterativo in tre fasi principali:
• Inventario: discovery e assessment delle informazioni, strutturate o non, ovunque si trovino nell’infrastruttura IT, siano
esse in uso, in movimento o a riposo; analogo discovery per quanto riguarda processi, utenti ed exit point
• Definizione Policy: creazione di policy atte a rilevare e proteggere tutte le informazioni mentre sono in uso, a riposo o in
movimento
• Applicazione Policy: applicazione delle policy a repository, dispositivi end-point, online e offline, etc., per determinare le
violazioni e fornire risoluzioni e azioni in tempo reale, allo scopo preservare i dati
Un terzo punto importante è legato al fatto che l’implementazione di un Progetto DLP pone alle Aziende sfide particolari in
termini di:
• Competenza: il processo di rilevazione richiede molta competenza ed esperienza; è necessario il supporto di esperti per
comprendere e rilevare i reali problemi, oltre a tool specifici di automazione
64
• Pianificazione: è importante definire dove iniziare e come procedere; di norma è necessario che il lavoro sia focalizzato
sulle necessità immediate e sia mantenuto molto semplice nelle prime fasi di implementazione
Attuazione: dopo l’implementazione di una soluzione DLP, cominciano ad arrivare report di violazioni: occorre operare una
scelta precisa sull’uso di questi report: inizialmente possono essere usati come strumento di formazione, in seguito come
base per azioni correttive.
Un’esatta definizione del Ricavo (beneficio) di un Progetto DLP deve innanzi tutto considerare tutti i benefici che tale Progetto
può portare all’Azienda, in termini di:
• Sicurezza: aumento del livello di sicurezza, con tutto quello che ciò comporta (dal costo diretto degli incidenti di sicurezza
all’immagine aziendale positiva o negativa che ne deriva)
• Compliance: rispondenza alle richieste della Normativa e degli Standard, con tutto quello che ciò comporta (dal costo
diretto del non adeguamento all’immagine aziendale positiva o negativa che ne deriva)
La definizione del Costo della componente inventariale del Progetto deve tenere in considerazione:
• Organizzazione: struttura organizzativa aziendale, dettagliata a livello di singola UO e dei rispettivi compiti
• Processi: numero e tipologia dei vari processi aziendali che generano – trattano – utilizzano informazioni
• Livelli protezione: necessità di protezione per le diverse classi di informazioni
• Sistemi esistenti: numero dei repository contenenti informazioni di sicurezza (es.: AD, LDAP, RACF, etc.), che devono
essere analizzati e normalizzati
• Applicazioni esistenti: numero delle applicazioni il cui utilizzo deve essere regolamentato tramite la definizione di Utenti
- Autorizzazioni
• Account esistenti: numero degli utenti e degli account con relativi profili ed autorizzazioni
• Autorizzazioni esistenti: numero delle autorizzazioni esistenti e di quelle effettive
La definizione del Costo della componente implementativa del Progetto deve tenere in considerazione:
• Infrastruttura HW e SW – Implementazione – Integrazione – Gestione
NOTA: per una valutazione economica è disponibile sul sito ROSI un modello in formato Microsoft Excel (DLP + IRM). 19
BENEFICI / VANTAGGI
L’implementazione di un sistema DLP, opportunamente ed efficacemente integrato con l’intero Sistema di Sicurezza (ed in
particolare con le componenti IRM e DAM), comporta benefici da vari punti di vista:
• da un punto di vista organizzativo e generale:
- la definizione di un Sistema DLP permette un deciso innalzamento di tutto il livello di sicurezza
- la definizione di un Sistema DLP permette di adeguarsi alle richieste della Normativa e degli Standard, sia per quanto
riguarda l’assegnazione dei diritti di accesso, sia per quanto riguarda la loro revisione periodica
• da un punto processuale:
- la necessità di definire esattamente i livelli di protezione delle informazioni aziendali comporta una loro conoscenza
dettagliata, non solo a livello teorico, ma a livello pratico (descrizione e documentazione delle stesse)
- la conoscenza dettagliata del ciclo di vita delle varie informazioni permette di operare miglioramenti sui processi elaborativi stessi
- la conoscenza dettagliata delle informazioni disponibili e dei relativi processi permette di analizzare meglio anche i
processi decisionali e migliorare quindi l’organizzazione del business stesso.
19
In definizione
65
versione 2.0
5.11 Pattern “DAM” Matteo Galimberti, Security Program Manager, B.U. Security Gruppo Terasytem
PATTERN
DAM (Data Base Access Monitoring)
AREA DI INTERVENTO
10.10.1 Audit Logging
10.10.3 Protection of logging information
10.10.4 Administrator and operator log
10.10.5 Fault logging
11.1.1 Access control policy
11.2.2 Privileges management
11.5.2 User identification and authentication
12.3.1 Use of cryptographic controls
12.4.2 Protection of test data
15.1.4 Data Protection and Privacy
15.2.1 Compliance with security Policy and Standards
NOTA: poiché il DAM riguarda la sicurezza delle informazioni aziendali, sono praticamente interessate
tutte le aree dello standard ISO 27001, in particolare quelle relative all’IRM e al DLP).
SINTESI
£
R
R
Rischi operativi R
Riservatezza £
R
Compliance R
£
£
Disponibilita`
Applicazioni R
Informazioni
Efficienza processi
La sicurezza dei DB, sia come argomento di discussione sia come insieme di prodotti e soluzioni, è un elemento noto da
molto tempo, ma solo da pochi anni sta cominciando a diventare argomento di attenzione da parte degli analisti del settore
e degli esperti di sicurezza, e ciò grazie alla combinazione di clamorose violazioni, altamente pubblicizzate, da una parte, e
alla domanda per una maggiore aderenza alle regole di “compliance” dall’altra, che stanno portando la tematica della sicurezza dei DB ad un’alta priorità in tutte le Aziende.
Rimane il fatto che molti esperti hanno familiarità con tematiche di sicurezza dei network e dei desktop, ma non di sicurezza
dei DB; eppure, se proviamo ad analizzare le statistiche 20 troviamo autentiche sorprese.
La situazione
• Le violazioni ai Database sono circa il 30% di tutte le violazioni rilevate.
• Le violazioni ai Database riguardano circa il 75% di tutte le informazioni violate.
• Gli attacchi sofisticati sono solo (circa) il 15% di tutti gli attacchi informatici.
• Gli attacchi sofisticati, però, riguardano circa il 95% di tutte le informazioni violate.
20
Anno 2009: media tra i vari analisti (IDC, Gartner, etc.)
66
Chi si nasconde dietro gli attacchi alla sicurezza dei Dati? 21
• 70% dei danni è stato causato da agenti esterni.
• 50 % degli attacchi è stato generato da insider.
• 10% ha visto il coinvolgimento di partner dell’Azienda.
• 30% ha coinvolto più partner.
Come avvengono le violazioni?
• 50% circa per un errato utilizzo dei privilegi.
• 40% per hacking vero.
• 40% per utilizzo di malware (da parte di insider).
• 30% per social engineering.
• 15% per attacchi fisici
Quali sono gli elementi in comune tra le varie violazioni?
• 95% dei dati violati stavano su server DB
• 80% degli attacchi è stato valutato “semplice” (e quindi facilmente contrastabile).
• 60% degli attacchi è stato scoperto da soggetti terzi.
• 85% delle volte le Aziende avevano le prove della violazione nei vari LOG(!).
• 95% delle violazioni erano evitabili con semplici controlli.
• 80% delle Aziende vittime, pur essendo soggette a standard e normative, non aveva mai ottenuto la certificazione(!)
Questi numeri dicono chiaramente che bisogna proteggere i nostri DB, utilizzando sistemi DAM!! Tali sistemi DAM (Data
Base Access Monitoring) riguardano i controlli applicabili ai dati, al fine di garantirne la sicurezza in tutti i suoi aspetti, secondo lo schema CIA:
• Confidenzialità: solo le persone autorizzate devono potervi accedere, ognuno secondo i propri privilegi;
• Integrità: i dati devono poter essere modificati solo in base alle regole stabilite ed utilizzando i mezzi appropriati (sistemi
ed applicazioni predisposti);
• Disponibilità: i dati devono rimanere disponibili ed essere utilizzabili quando necessario.
NOTA: essendo il DAM collegato all’IRM e al DLP, si faccia anche riferimento ai rispettivi pattern.
DESCRIZIONE
Un Sistema DAM correttamente approcciato si muove sostanzialmente secondo tre direzioni (approcci):
• a priori: basato sull’aumento delle difese preventive (eventualmente integrate con controlli di tipo compensativo),
comprensivo di: identificazione – autenticazione – autorizzazione, e completato attraverso attività di: formazione – deterrenza
• a posteriori: basato sul controllo sistematico di tutte le transazioni, soprattutto quelle appetibili a chi vuole perpetrare una
frode (di norma, transazioni economiche – finanziarie), e di tutte le attività effettuate su File e Data Base; tale controllo
deve essere esplicato attraverso attività di:
- analisi – reporting – forensic analysis
• real-time: basato sul controllo online di tutte le transazioni e le attività fatte sul DB ed esplicato attraverso attività di:
- definizione policy e baseline
21
La somma > 100% è dovuta alla combinazione dei diversi fattori
67
versione 2.0
- definizione profili (operativo, economico, ambientale, temporale, geografico)
- controllo online (controllo network, controllo locale, controllo host)
- deterrenza (alerting, blocco transazione, disattivazione transazione)
Un Progetto DAM deve comprendere i moduli seguenti.
Attività preliminari:
• Classificazione: definizione sistema interno di Classificazione delle Informazioni
• Inventario: discovery, catalogazione e classificazione di Dati – Utenti – Location – Applicazioni ed individuazione scenari
organizzativi e operativi di riferimento
• Applicazioni: analisi delle applicazioni che accedono ai DB, dei dati gestiti, dei processi serviti e degli utenti abilitati
• Profili: raggruppamento delle classi di utenza in Profili mappando su questi i diritti sulle Classi di Informazioni
Attività tecniche:
• Scelta prodotti: scelta dei prodotti che meglio si adattano alle esigenze del Cliente
• Implementazione: implementazione della tecnologia scelta
• Crittografia: scelta e implementazione crittografia dati (per aumentare la sicurezza dei dati stessi), indipendentemente
dalle applicazioni che li utilizzano
• Hardening: messa in sicurezza dei server DB e delle postazioni di lavoro, con eliminazione delle componenti non necessarie, e blocco possibilità di modifica di configurazione
Attività specifiche:
• Protezione diretta: utilizzo di strumenti che garantiscano l’inaccessibilità all’Informazione se non a chi ne detenga il reale
diritto (RM – IDM – AM – ESSO)
• Protezione DB: protezione dei DB in cui le informazioni vengono depositate e mantenute, per assicurare che non se ne
possa violare l’integrità
• Protezione rete: protezione dei dispositivi di trasmissione dati, per assicurare che non se ne possa violare l’integrità
• Protezione EP: protezione dei dispositivi dove le informazioni vengono elaborate (Server, Work Station, PC, laptop, etc.),
per assicurarne l’integrità; questo comporta anche l’analisi delle applicazioni, e la valutazione dei controlli attivi
• Protezione centrale: definizione norme e tecnologie che permettano di assicurare un uso appropriato delle Informazioni
stesse.
Attività gestionali:
• Monitoraggio: raccolta, normalizzazione, analisi e archiviazione dei dati di log (registrazione attività) da parte dei vari sistemi
• Archiviazione: implementazione procedure di Backup / Restore, e definizione Piani di Continuità e di Disaster Recovery
Oltre alla necessità intrinseca di garantire le informazioni registrate sui DB, ci sono almeno tre grandi categorie di Driver che
motivano l’adozione di un Sistema DAM.
Aspetti di COMPLIANCE
Ci sono diverse leggi e normative con cui il business si deve confrontare, i principali dei quali sono:
• SOX: legge federale degli USA che, pur non specificando misure tecniche o strumenti da utilizzare, richiede di implementare controlli efficaci (sezione 404); l’esatta natura dei controlli non è stata specificata, ma i revisori pongono
particolare enfasi su: Integrità dei dati – Attività svolte dagli utenti privilegiati – Tracciabilità dei dati – Separazione delle
responsabilità
68
• BASEL II: rappresenta le raccomandazioni prese dal comitato di supervisione bancario (BCBS) per promuovere maggiore
consistenza nel modo in cui le banche approcciano la gestione dei rischi; la normativa indirizza numerosi prerequisiti di
sicurezza, tra i quali: Tracciabilità degli eventi (e conservazione sicura delle rilevazioni) e Policy di divulgazione dei dati;
• PCI/DSS 22: obbliga le aziende che trattano i dati delle carte di credito a rispettare una serie di requisiti tecnici e procedurali, e a superare le verifiche di auditing;
• D. Lgs. 196/2003: raccoglie in un testo unico leggi, decreti e codici deontologici in tema di riservatezza delle informazioni
personali e sensibili; per essere conformi, le Aziende devono: pianificare misure organizzative, amministrative e tecniche
di sicurezza e documentarle in un documento programmatico (DPsS) – adeguarsi alle misure minime di sicurezza definite
nell’allegato “B” – dare informativa completa nel trattamento dei dati personali.
• Disposizione AdS: introduce l’obbligo per gli amministratori di sistema (compresi coloro che svolgono la mansione di amministratore di rete e di DB), di conservare i Log delle attività per un certo periodo in archivi immodificabili e inalterabili;
• ISO 27001: fornisce i requisiti di un Sistema di Gestione della Sicurezza delle Informazioni, in particolare per gli aspetti
della sicurezza fisica, logica e organizzativa, al fine di garantire la sicurezza dei propri dati;
• HIPAA 23: comprende una serie generale di obblighi che vanno dal trattamento manuale dei form ai requisiti di sicurezza
su Internet; le parti riguardanti i DB sono: Access Control – Audit Control – Integrity Control
• SAS 70: si tratta di norme professionali per un servizio di auditing sui controlli interni; non specifica quale controllo deve
essere attivato, ma strumenti e procedure che possano facilitare il lavoro dei revisori.
Necessità di AUDITING
Per verificare la conformità alla normativa e agli Standards, gli auditor guardano ad una molteplicità di aspetti, quali:
• Gestione Utenti – Identificazione – Autenticazione – Autorizzazione – Controllo Accessi
• Separazione delle funzioni
• Registrazione completa e sicura delle attività
L’ultimo aspetto riguarda il DAM e definisce i requisiti specifici di tali registrazioni:
• Indipendenza: l’intero processo deve essere indipendente dal DBMS stesso e dagli amministratori dei DB; e questo comporta che: le attività di controllo siano separate da quelle di gestione – la raccolta dei dati di controllo sia indipendente da
quanto fornito dal DBMS stesso – eventuali soluzioni esterne non si basino solo sulle features DBMS.
• Identificazione: le registrazioni devono permettere di attribuire tutte le transazioni a un utente specifico; 24
• Dettaglio: le registrazioni devono fornire, per ogni singola richiesta, un dettaglio atto a per ricostruire esattamente la catena
delle evidenze;
• Importanza: un sistema efficace non deve limitarsi a registrare tutti gli eventi ma deve organizzare le informazioni, normalizzarle, correlarle, dare loro una priorità, segnalare gli scostamenti etc.: aiutare, insomma, i controllori a capire le
situazioni che necessitano di intervento;
• Ambito: l’ambito delle registrazioni deve essere sufficientemente ampio da poter identificare tutti i tentativi di effrazione;
alcune tipologie di attacco sono nascoste, ed è necessario usare strumenti diversi tra loro integrati (es.: IDS / IPS - VA /
VM – DLP), e confrontare i loro dati in maniera uniforme.
22
Payment Card Industry’s Data Security Standard
Healthcare Insurance Portability Accountability Act
24
Quando gli utenti accedono alle applicazioni via Web, le registrazioni native del DB non hanno in genere visibilità dell’identità di chi ha
fatto l’operazione, in quanto l’utente non agisce direttamente sul DB: infatti, spesso si utilizza la tecnica pooled connection, in cui l’applicazione autentica i vari utenti, ma poi accoda le richieste e le invia al DB con un Account interno suo; il DBMS non può che registrare
questo Utente generico.
23
69
versione 2.0
PUNTI DI ATTENZIONE
Nella scelta e nella definizione di un Progetto DAM ci sono alcune aree che devono essere attentamente valutate.
Tecniche utilizzate
Per quanto riguarda le tecniche di intercettazioni usate, alcuni Fornitori DAM sostengono di poter far tutto utilizzando solo
una tecnica di tipo Networking oppure una tecnica di tipo Local Agent; in realtà le cose stanno un po’ diversamente; se
prendiamo i principali prodotti DAM di mercato, vediamo come questi, per proteggere in modo adeguato un DB da tutte le
possibili azioni dannose, utilizzino tre componenti:
• Network Agent: posizionati in rete, per le richieste provenienti dalla rete (network scanning) + appliance di aggregazione
e gestione dati
• Local DB Agent: installati su DB Server, per le attività eseguite direttamente sul DB Server
• Remote DB Agent: installati su DB Server, per gli accessi di tipo remoto
Le soluzioni basate su Agent locali, tramite sensori collocati direttamente sui DB Server, possono, se correttamente implementate, controllare tutte le attività fatte sul DB, con una architettura concettualmente semplice; mentre, secondo quanto
riportato da alcuni analisti, un DAM basato solo su Network non sarebbe in grado di intercettare richieste che non contengono comandi SQL diretti, ma che richiedono l’esecuzione di altre Procedure, che a loro volta potrebbero contenere comandi
SQL dannosi.
Requisiti di Compliance
Per quanto riguarda gli aspetti di COMPLIANCE, tutti dicono di fare tutto (e, infatti, nel momento in cui ho le tracce di tutte
le attività, posso preparare qualsiasi report): il problema è se tali report sono già presenti, se si dispone di tool semplici per
completarli, etc.
Requisiti funzionali base
Un sistema DAM non può non disporre delle seguenti funzionalità:
• Discovery: inventario DB e dati contenuti, e relativa classificazione (livelli di protezione)
• Aggregation: aggregazione dei dati di Log raccolti
• Correlation: correlazione dei dati raccolti (anche provenienti da fonti diverse)
• Policy: definizione ed enforcement di Policy di controllo DB (controllo online)
• Content rules: definizione di regole basate sul contenuti dei dati
• Alerting: attivazione alerting a fronte di violazione o scostamento da baseline
• Workflow: definizione processi di gestione eventi e incidenti
• Reporting: reporting a diversi livelli: manageriale, auditing, operativo, tecnico, etc.
Requisiti opzionali
Un sistema DAM dovrebbe in aggiunta fornire le seguenti funzionalità:
• Identification: possibilità di abbinare qualsiasi attività ad un utente specifico
• Blocking: blocco transazione a fronte di violazione o scostamento da baseline
• Application: controllo attività delle applicazioni (e non solo attività sul DB) e disponibilità Policy (e regole) per i le principali
offerte di mercato (SAP, Siebel, etc.)
• Compliance: disponibilità di Policy (e regole) per la conformità alle normative in essere ed ai principali standard)
• Change: funzionalità di Change Management a livello di Query dei DB
• Vulnerability: funzionalità di verifica configurazioni DB, installazioni patches, etc.
NOTA: per una valutazione tecnica dei prodotti DAM  Vedere Modello DAM allegato.
70
Un’esatta definizione del Ricavo (beneficio) di un Progetto DAM deve innanzi tutto considerare tutti i benefici che tale Progetto può portare all’Azienda, in termini di:
• Sicurezza: aumento del livello di sicurezza, con tutto quello che ciò comporta (dal costo diretto degli incidenti di sicurezza
all’immagine aziendale positiva o negativa che ne deriva)
• Compliance: rispondenza alle richieste della Normativa e degli Standard, con tutto quello che ciò comporta (dal costo
diretto del non adeguamento all’immagine aziendale positiva o negativa che ne deriva)
La definizione del Costo della componente inventariale del Progetto deve tenere in considerazione:
• Processi: numero e tipologia dei vari processi aziendali che generano – trattano – utilizzano informazioni
• Livelli protezione: necessità di protezione per le diverse classi di informazioni
• Sistemi: numero dei repository contenenti informazioni di sicurezza relativi all’utilizzo dei DB (es.: AD, LDAP, RACF, etc.),
che devono essere analizzati
• Applicazioni: numero delle applicazioni che accedono ai DB e il cui utilizzo deve essere regolamentato tramite la definizione di Utenti - Autorizzazioni
• Account: numero degli utenti e degli account con relativi profili ed autorizzazioni
• Autorizzazioni: numero delle autorizzazioni esistenti e di quelle effettive
La definizione del Costo della componente implementativa del Progetto deve tenere in considerazione:
• Infrastruttura HW e SW
• Implementazione
• Integrazione
• Gestione
BENEFICI / VANTAGGI
L’implementazione di un sistema DAM, opportunamente ed efficacemente integrato con l’intero Sistema di Sicurezza (ed in
particolare con le componenti IRM e DLP), comporta benefici da vari punti di vista:
• da un punto di vista organizzativo e generale:
- la definizione di un Sistema DAM permette un deciso innalzamento di tutto il livello di sicurezza (i DB contengono le
Informazioni da proteggere!)
- la definizione di un Sistema DAM permette di adeguarsi alle richieste della Normativa e degli Standard circa il controllo
degli accessi e dell’utilizzo dei dati
- la necessità di definire esattamente i livelli di protezione delle informazioni aziendali contenute nei DB comporta una
loro conoscenza dettagliata, non solo a livello teorico, ma a livello pratico (descrizione e documentazione delle stesse)
- la conoscenza dettagliata del ciclo di vita delle varie informazioni permette di operare miglioramenti sui processi elaborativi stessi
- la conoscenza dettagliata delle informazioni disponibili e dei relativi processi permette di analizzare meglio anche i
processi decisionali e migliorare quindi l’organizzazione del business stesso
71
versione 2.0
5.12 Pattern “Role Management” Autore: Giacomo Aimasso, CISA, CISM, CTO B.U. Security, Gruppo Terasystem
PATTERN
RM (Role Management)
AREA DI INTERVENTO
8.1.1. Roles and Responsibilities
8.2.1. Management responsibilities
10.1.3. Segregation of Duties
11.2.2. Privilege Management
11.2.4. Review of User Access Rights
NOTA: essendo il RM un prerequisito per IDM, indirettamente sono interessate anche tutte le aree di
competenza dell’IDM (si veda il pattern specifico).
SINTESI
R
£
R
Rischi operativi R
Riservatezza R
R
Compliance R
£
R
Disponibilita`
Applicazioni £
Informazioni
Efficienza processi
Con il termine RM (Role Management) si fa riferimento a tutti gli aspetti riguardanti la gestione dei Ruoli Aziendali, e la definizione di un Modello RBAC (Role Based Access Control) atto a rinforzare il Modello di Policy Aziendali.
Introdotto da D. Ferraiolo e R. Kuhn del NIST nel 1992, e adottato nel 1994 dall’ANSI quale Standard, l’approccio RBAC si
fonda su due principi:
• L’assegnazione delle autorizzazioni (Access Rights) è basato sul ruolo che una persona ha all’interno di una Organizzazione, e non sulla persona stessa.
• I Ruoli definiscono i diritti di accesso in base alle responsabilità ed all’autorità di una persona all’interno di una determinata job function.
NOTA:  essendo il RM collegato all’IDM, fare anche riferimento al pattern “IDM”
DESCRIZIONE
L’Identity Management riguarda la gestione centralizzata del ciclo di vita delle utenze, intese come assegnate a persone
fisiche che ricoprono un certo ruolo aziendale, in base al quale necessitano di determinate autorizzazioni all’utilizzo delle
risorse IT. All’interno di tale area, la componente RM (Role Management) riguarda la gestione dei Ruoli (Business Roles e
IT Roles) e si sviluppa su due linee principali:
• Role Management (RM): insieme delle attività di gestione del ciclo di vita dei Ruoli.
• Role Engineering (RE): insieme delle attività di individuazione dei Ruoli; il suo scopo è definire un set di Ruoli che sia
completo, corretto ed efficiente, con le autorizzazioni che ciascun ruolo comporta.
Le attività RM possono essere approcciate secondo due metodologie principali:
• Top down approach: quest’approccio rappresenta la via principale per definire i ruoli, quando il Modello RBAC deve mappare la struttura organizzativa aziendale; esso include: analisi dei processi di business, individuazione delle necessità
informative, definizione dei Business Roles, raffinamento (attraverso tecniche di clusterizzazione), definizione del Modello
RBAC.
• Bottom-up approach: quest’approccio rappresenta una via pratica per riutilizzare quanto già definito sui vari sistemi in
termini di: account – gruppi – profili; esso include: inventario autorizzazioni esistenti (Utenti – Gruppi – Profili – Risorse),
72
clusterizzazione Gruppi e Profili, definizione nuovi Gruppi e Profili e relativo raffinamento, definizione dei nuovi Ruoli
IDM.
Essendo il RM parte integrante del processo di IDM, driver e motivazioni relative all’IDM hanno valore anche per il RM stesso; nello specifico, i driver che spingono verso un approccio RBAC sono:
• Compliance: necessità, in base a Standard e Normative, di definire correttamente i ruoli aziendali e di assegnare le autorizzazioni di accesso agli Utenti in base al loro ruolo aziendale
• Efficienza: necessità di ridurre i costi della sicurezza: un approccio RBAC riduce l’effort necessario a gestire i vari utenti
e i relativi profili, essendo il numero dei ruoli inferiori al numero delle autorizzazioni; si può in genere dire che il beneficio
di un tale approccio è sintetizzabile nella formula:
∑i (Ui+Pi) < ∑i (Ui*Pi)
dove
Ui = numero di utenti che svolgono una determinata funzione
Pi = numero di accessi (permessi) necessari per tale funzione
• Efficacia: necessità di aumentare la Sicurezza: un approccio RBAC garantisce un maggior livello di sicurezza, e soprattutto un più facile controllo sui suoi processi
• Organizzazione: necessità di ottimizzare i vari processi aziendali: la definizione dei ruoli comporta l’analisi dei processi
esistenti, e la definizione delle relative necessità informative ed informatiche; e questo può fornire il punto di partenza per
una ottimizzazione dei processi stessi
PUNTI DI ATTENZIONE
Un primo punto riguarda il fatto che il Role Management (RM) rappresenta una delle attività più importanti in un Progetto
IAM, e un approccio non adeguato può portare allo sviluppo di un Sistema non efficace, in quanto:
• solo definendo un Modello RBAC un Sistema IAM può fornire i benefici attesi (come dimostrato dalle analisi di Coyne –
Ferraiolo – Kuhn – Neumann)
• solo con un corretto approccio al RM ed al RE è possibile definire un Modello RBAC efficace 25.
Il secondo punto riguarda l’attenzione che si deve porre, nel definire un progetto RM, su alcuni aspetti che possono essere
causa di insuccesso se non adeguatamente considerati, e che possono essere così riassunti:
• Situazione: necessità di una conoscenza effettiva di sistemi, applicazioni, utenti, account, profili ed autorizzazioni esistenti
nell’ambiente IT in essere
• Processi: necessità di una conoscenza effettiva dei processi aziendali) e loro strutturazione (funzioni – processi – processi
elementari – attività – condizioni – necessità informative – etc.)
• Ruoli: necessità di una conoscenza effettiva dei ruoli aziendali, loro strutturazione e relativa assegnazione (job function e
job description)
ELEMENTI di VALUTAZIONE (da considerare per la stima del ROSI)
Un’esatta definizione del Ricavo (beneficio) di un Progetto RM deve considerare tutti i benefici che tale Progetto può portare
all’Azienda, in termini di:
• Operatività: diminuzione delle necessità operative (e quindi delle risorse dedicate), grazie agli automatismi che un approccio RBAC può offrire
25
Oggi si parla spesso di altri modelli: ABAC, IBAC, NBAC, …, ZBAC; pur contenendo tutti interessanti spunti per la sicurezza e il controllo
degli accessi, il modello RBAC rima quello fondamentale.
73
versione 2.0
• Sicurezza: aumento del livello di sicurezza, con tutto quello che ciò comporta (dal costo degli incidenti di sicurezza all’immagine aziendale positiva o negativa che ne deriva)
• Compliance: rispondenza alle richieste della Normativa e degli Standards, con tutto quello che ciò comporta (dal costo del
non adeguamento all’immagine aziendale positiva o negativa che ne deriva)
La definizione del Costo della componente RM deve tenere in considerazione il costo (in termini di tempo – risorse – denaro)
necessario per l’analisi dei seguenti aspetti:
• Processi: numero e tipologia dei vari processi aziendali da analizzare (dettagliati a livello di singolo processo elementare)
• Necessità informative: necessità informative dei singoli processi (a livello di processo elementare)
• Funzioni: funzioni azindali deputate a svolgere i singoli processi elementari
La definizione del Costo della componente RE deve tenere in considerazione il costo (in termini di tempo – risorse – denaro)
necessario per l’analisi dei seguenti aspetti:
• Sistemi esistenti: numero dei repository contenenti informazioni di sicurezza (es.: AD, LDAP, RACF, etc.), che devono
essere analizzati e normalizzati
• Applicazioni esistenti: numero delle applicazioni il cui utilizzo deve essere regolamentato tramite la definizione di Utenti
– Autorizzazioni
• Account esistenti: numero degli utenti e degli account con relativi profili ed autorizzazioni
• Autorizzazioni esistenti: numero delle autorizzazioni esistenti e numero delle autorizzazioni effettive
Infine, poiché un Modello RBAC da benefici veri quando è integrato in un Sistema IDM, occorre considerare anche il costo
di implementazione di tale sistema in termini di:
• Infrastruttura HW e SW – Implementazione – Integrazione – Gestione
NOTA: per una valutazione economica è disponibile sul sito ROSI un modello in formato Microsoft Excel (RM + IDM).
BENEFICI / VANTAGGI
L’approccio RBAC, e la corrispondente definizione di un corretto set di Ruoli aziendali, comporta benefici da vari punti di
vista:
• da un punto di vista generale:
- il numero di ruoli da gestire è inferiore al numero delle singole autorizzazioni e pertanto si può avere un maggior controllo
- le attività operative sono di molto ridottea, con conseguente riduzione di errori e di costi
- le definizione dei ruoli ai vari livelli organizzativi (Azienda – Divisione – Servizio – Ufficio – etc.) può automatizzare le
attività di provisioning nei vari processi di Gestione Utenti
- la necessità di definire esattamente le necessità informative dei vari processi aziendali comporta una loro conoscenza
dettagliata, e ciò permette di operare miglioramenti sugli stessi ...
- ... e di analizzare meglio anche i processi decisionali e migliorare quindi l’organizzazione del business stesso
• da un punto organizzativo, la definizione dei ruoli:
- rinforza la percezione di responsabilità da parte degli utenti e permette di attuare una fattiva SoD (Separation of Duty)
- permette di operare in modo più efficace (obiettivo sicurezza), e non solo più efficiente (obiettivo operatività)
- permette un deciso innalzamento di tutto il livello di sicurezza
74
- permette di adeguarsi alle richieste della Normativa e degli standard, sia per quanto riguarda l’assegnazione dei diritti
di accesso, sia per quanto riguarda la loro revisione periodica (attestation)
• da un punto operativo il Modello RBAC:
- permette di risparmiare sul numero di risorse da dedicare alla gestione degli Utenti e degli Account
- riduce gli errori non solo grazie alla riduzione dell’operatività ma anche dal maggior controllo che un approccio RBAC
consente
- permette un’immediatezza altrimenti non raggiungibile, sia per quanto riguarda l’aggiunta – la gestione – la rimozione
di risorse IT, sia per quanto riguarda le attività di gestione del ciclo di Vita degli Utenti
5.13 Pattern “VDI” Autori: Paolo Marelli, Senior Sales Consultant - VDI Global Business Unit - Giuseppe Russo,
Chief Technologist e Security Top Gun, Oracle Italia
PATTERN
Sicurezza intrinseca del Desktop Virtuale e della postazione di accesso al medesimo
AREA DI INTERVENTO
9.2 Equipment security
10.5 Back-up
11 Access Control
14 Business continuity management
SINTESI
R
R
R
Rischi operativi R
Riservatezza R
£
Compliance £
£
R
Disponibilita`
Applicazioni R
Informazioni
Efficienza processi
Nel panorama IT mondiale assistiamo ad una sempre maggiore esigenza di mobilità della postazione di lavoro. Nel 2008,
per la prima volta, la vendita di “laptop” ha superato quella dei “desktop” (Fonte iSuppli) e la tendenza non accenna a diminuire. Se ciò permette una efficienza mai vista prima, dall’altro lato vi è un incremento dei problemi di sicurezza sia fisica del
dato (backup), sia correlata all’esposizione della proprietà intellettuale e dei dati sensibili ad un sempre maggiore rischio.
Da una ricerca IDC del 2010, risulta che la maggioranza di Aziende ha subito sia furti (89%), sia smarrimenti (72%) di
portatili. Il dato più eclatante riguarda il luogo dove più frequentemente avvengono i furti. La ricerca mostra infatti che la
maggioranza avviene proprio in ufficio, luogo di lavoro e sale riunioni, per un totale di circa il 65%. Questo dato ci fa riflettere,
oltre che sulla fragilità del laptop, quale anello più debole nella catena della sicurezza, anche sulla sicurezza in generale del
dato in ufficio. Se infatti i furti di un bene fisico possono essere misurati, il rischio di furto di informazioni, da sessioni lasciate
disattese nelle pause provoca certamente molta più inquietudine.
Ecco perché oggi si rende necessario ripensare alla sicurezza della postazione di lavoro, cercando di individuare soluzioni
architetturali che siano già intrinsecamente sicure.
DESCRIZIONE
La soluzione ideale dovrebbe basarsi su alcuni punti fondamentali:
• Il PC dell’utente, contenente dati, applicazioni, configurazioni, etc. non deve mai uscire dall’Azienda ma, grazie alle metodologie di virtualizzazione del Desktop, viene eseguito su server nel datacenter.
75
versione 2.0
• Le postazioni di lavoro negli uffici, dovranno essere l’equivalente di terminali grafici, steteless, sui quali l’accesso al proprio
Desktop Virtuale si ottiene tramite autenticazione multi-factor.
• Uno dei fattori di autenticazione è meglio che sia un supporto fisico, che possa essere in qualche modo “vincolato” all’utente, così che l’eventuale suo allontanamento dalla postazione di lavoro determini la chiusura della sessione di lavoro.
• Il Desktop deve poter essere acceduto da qualsiasi terminale, presso qualsiasi sede.
• Il Desktop deve poter essere acceduto, in modo sicuro, anche via Internet, da devices di vario tipo, senza la necessità
di installare manualmente software per abilitare la connessione sicura, così da eliminare totalmente la necessità di un
dispositivo portatile anche per gli utenti mobili.
• L’utilizzo di devices aggiuntivi (stampanti, USB memory sticks, etc.) deve poter essere regolamentata dell’Amministratore
di Sistema, secondo i requisiti di sicurezza ed il profilo dell’utente.
La soluzione individuabile sul mercato che risponde a tutti i punti sopra elencati è Oracle Virtual Desktop Infrastructure.
Essa fornisce un ambiente di virtualizzazione versatile, in grado di integrarsi con più piattaforme di virtualizzazione. Nel caso
si scelga la piattaforma di virtualizzazione Oracle, ha però il vantaggio di poter gestire Desktop Virtuali anche Linux. La sua
architettura permette di creare dei gateway di accesso che “isolano” completamente la rete protetta, sia nell’ambito degli
accessi esterni (tramite Internet), che di quelli interni (dall’ufficio o dalle sedi remote direttamente connesse alla sede centrale). I thin-client Oracle Sun Ray, infatti, oltre ad avere tutti il lettore di smartcard, usata come fattore aggiuntivo di autenticazione, possono funzionare unicamente se si connettono ad un Sun Ray server. Questo rende possibile la creazione, negli
uffici, di una rete neutra, “isolata” dalla rete protetta, nella quale chi usa un dispositivo Sun Ray può accedere al proprio
desktop, ma un qualsiasi altro dispositivo non riconosciuto non avrebbe alcuna possibilità di accedere alla rete protetta. Da
non sottovalutare neppure il cosiddetto “hot-desking”, cioè la trasposizione di una sessione Desktop tra due device di tipo
Sun Ray, anche presso sedi diverse, semplicemente usando la smartcard, e la possibilità di trasposizione della sessione
Desktop anche verso connettività di tipo WEB. Così la postazione di lavoro è disponibile all’utente sia internamente all’ufficio,
sulle Sun Ray, sia esternamente, su qualsiasi altro PC dotato di un WEB browser e di un JRE (hotel, internet cafe, etc...).
L’adozione di una soluzione Oracle di Desktop Virtualization, nella sua accezione più completa, può essereagevolata da due
punti di forza, con tutte le loro naturali implicazioni:
• La sicurezza implicita della soluzione
• Doppio authentication factor (smartcard per devices Sun Ray, strumento opzionale di strong authentication per accessi
da PC)
• Stateless clients
• Session “hot-desking”
• Access gateways interni ed esterni
• Gestione utilizzo degli “attached devices”
• Eliminazione di tutti i dispositivi mobili e conseguente eliminazione del rischio di furto/smarrimento
• Eliminazione del rischio delle sessioni disattese. Integrando nella smartcard anche dispositivi per l’accesso aree aziendali
(RFID, banda magnetica...) e ad altre risorse (credito distribuzione alimenti e bevande, etc.), l’utente sarà costretto a portare sempre con sé la smartcard, e la sua estrazione dalla Sun Ray chiuderà automaticamente la sua sessione Desktop.
• L’eliminazione completa di tutti i laptop ed i desktop esistenti in Azienda, insieme a tutte le loro problematiche classiche
di installazione, manutenzione, riparazione, back-up, furti, ciclo di vita breve, consumo elettrico (un thin-client sun Ray
consuma 14W nella sua operatività, 0,4W in power saving, escluso il monitor), condizionamento atmosferico ed acustico
degli ambienti (un thin-client Sun Ray è solid-state, emette pochissimo calore e rumore, rispetto ad un comune PC).
76
Inoltre, l’adozione del Desktop Virtuale e dell’architettura thin-client semplifica notevolmente la creazione di scenari di
Disaster Recovery sia lato Datacenter (tramite replica dello storage) sia lato ambiente di lavoro (tramite l’accesso via Internet, gli utenti possono lavorare dal proprio PC di casa con gli stessi strumenti che avrebbero in ufficio.
PUNTI DI ATTENZIONE
• Connettività di rete. Per una soluzione di questo tipo, basata sull’accesso a strumenti centralizzati, vanno potenziate e
ridondate le infrastrutture di rete. Una caduta di connessione comprometterebbe tutte le postazioni e la scarsità di bandwidth od un’eccessiva latenza influenzerebbe negativamente la produttività degli operatori.
• Hardware failure-tolerant e ridondato per sopportare failure di uno o due componenti. La mancata ridondanza impatterebbe infatti un numero di utenti consistente.
• Ridondanza elettrica, generatore autonomo o ambiente di DR. Una interruzione di fornitura elettrica del datacenter impatterebbe tutti gli utenti.
• Attached devices: non tutti i devices possono lavorare correttamente attraverso un protocollo di connettività di rete. Una
percentuale variabile di postazioni di lavoro NON potranno essere migrate alla nuova architettura.
• Accettazione, da parte dell’utente, del nuovo standard operativo. Spesso la disponibilità di un PC viene percepita come un
benefit personale, poiché le Aziende generalmente tollerano tipi di operatività diversa da quella Aziendale (foto, musica,
masterizzazione...). L’utilizzo di una piattaforma “asettica” e controllata come un thin-client potrebbe sollevare disappunto.
• Quantità complessiva di posti di lavoro impattati dalla nuova architettura. Soluzione di questo genere richiedono un investimento iniziale in hardware “pregiato” il cui valore supera molto quello della semplice sostituzione dei PC. Si suggerisce
quindi l’implementazione di queste soluzioni per popolazioni non inferiori ai 300-400 posti di lavoro. Un calcolo ben fatto
del ROI, abbinato a quello del ROSI potrebbe tuttavia rendere la soluzione appetibile anche per organizzazioni più piccole
che debbano comunque rispondere a particolari requisiti di sicurezza, flessibilità, disponibilità.
• Gestione degli investimenti iniziali. Per alleviare gli investimenti iniziali si suggerisce l’utilizzo di servizi finanziari, che
possono ridistribuire detti costi su un lasso di tempo sufficiente perché vengano compensati da adeguati ritorni di investimento.
ELEMENTI di VALUTAZIONE (da considerare per la stima del ROSI)
Per agevolare la redazione di un ROSI e di un ROI abbinati, gli spunti di seguito vengono divisi in due parti.
ELEMENTI DI VALUTAZIONE ROSI
• Costo furto e smarrimento laptops, che viene pressoché azzerato. Questo elemento deve tenere in considerazione:
• i costi di acquisto di un nuovo laptop
• la predisposizione e la eventuale movimentazione degli eventuali laptop temporanei sostitutivi
• il fermo produttivo ed il disagio del dipendente per i tempi in cui non dispone del PC
• i costi di preparazione del nuovo desktop, che includono, oltre all’installazione standard del Sistema Operativo e delle
applicazioni, anche il restore degli eventuali dati utente
• i costi produttivi correlati alla perdita di dati utente, non ancora salvati su altri supporti di back-up.
• Costo soluzioni di back-up di desktop classici, che viene pressoché azzerato, in quanto i dati rimangono centralizzati su
storage.
• Costo soluzioni di sicurezza per accesso remoto. L’immagine del PC aziendale risiede nella rete protetta e ne viene esportato il desktop. Non si pone più il tema di garantire un accesso VPN, ma è sufficiente un accesso WEB, il cui prezzo è già
incluso nella soluzione in questione.
• Potenziale semplificazione di un piano di Disaster Recovery, sia lato data center, sia lato uffici. Per la prima è infatti suf-
77
versione 2.0
ficiente predisporre in altro sito, con connessione ridondata, uno storage per la replica dello storage in produzione, ed
una quantità di server fisici sufficiente per il numero di utenti da gestire in situazione di DR. Per la seconda parte, si può
pensare:
• di predisporre un altro sito con una quantità di thin-client sufficiente per il numero di utenti da gestire in situazione di DR,
oppure
• grazie all’accesso remoto sicuro, far lavorare gli utenti da casa propria o da un qualsiasi altro ufficio preso a nolo, ovunque
siano disponibili dei PC generici ed una connessione a Internet sufficientemente dimensionata.
• Compliance aziendale alla normativa privacy e trattamento dati. Questi costi, come quelli dei punti successivi, sono quelli
tipicamente più complessi da valutare. Per la stima possono essere presi in considerazione i costi correlati ad eventuali
fatti realmente accaduti nel passato.
• Costo ipotizzato furto dati sensibili e/o proprietà intellettuale.
• Potenziale danno immagine aziendale.
ELEMENTI DI VALUTAZIONE ROI
• Interruzione di produttività. L’ambiente Desktop Virtualizzato offre una maggiore garanzia di continuità, sia perché è basato su hardware ridondato, sia per la possibilità di clonare istantaneamente, da immagini campione, macchine virtuali
nuove da offrire in brevissimo tempo all’utente. Gestendo la parte dati utente e preferenze in modo completamente separato dal Sistema Operativo, è possibile offrire all’utente un replacement quasi immediato del proprio PC virtuale. Questo
elemento si applica non solamente agli smarrimenti o furti di laptops, ma anche ai desktop, a seguito di guasti hardware
o malfunzionamenti software, dovuti a molteplici fattori:
• Installazione di freeware (e relative dll) da parte dell’utente, che causano malfunzionamenti alle applicazioni Aziendali
• Infezione da parte di Virus. E’ noto che gli utenti tendono ad utilizzare la piattaforma PC aziendale anche per scopi personali.
• Costi di gestione delle postazioni di lavoro. Comprende tutti i costi materiali (esclusa l’interruzione di produttività menzionata al punto precedente) di gestione dei PC, cioè tutti i costi Aziendali correlati alla numerosità del team di assistenza,
alla movimentazione di persone e/o materiali necessari per la manutenzione di postazioni di lavoro di tipo PC distribuito.
Tra questi ricordiamo:
• Installazione fisica e configurazione
• Manutenzione ed aggiornamenti
• Sostituzione e riparazione
• Back-up
• Ciclo di vita del PC. Mediamente un PC deve essere sostituito ogni 4-5 anni, poiché le risorse hardware diventano insufficienti e per via dell’usura meccanica. L’immagine virtualizzata del PC non ha più questo limite, poiché le piattaforme
server consentono sia una scalabilità verticale (aggiungere nuovi componenti al server, CPU e RAM), sia orizzontale (aggiungere nuovi server alla farm per distribuire il nuovo carico di lavoro). Anche lato storage è molto più semplice sostituire
od aggiungere nuove risorse disco e distribuirle alle varie immagini di PC. Il ciclo di vita di una immagine virtuale di PC
viene quindi estesa praticamente a piacere. Dal punto di vista dell’usura, cioè il decadimento materiale della postazione
di lavoro, questa si applica in misura maggiore ai portatili, più esposti a shock di vario genere, ma anche ai desktop, se
parliamo di usura meccanica delle componenti in movimento (disco, ventola, etc.). Le Sun Ray sono “solid-state”, e permettono di estendere il ciclo di vita fisico ad oltre 10 anni.
• Consumo elettrico. Un thin-client Sun Ray consuma 14W quando è acceso e 0,4W in modalità “power save”, escluso il
monitor. Il consumo medio di un PC completo si aggira tra i 100 e i 150W. Sarebbe facile calcolare il vantaggio annuale
78
in termini di consumo. Tuttavia, a fronte della drastica diminuzione dei costi energetici lato postazioni di lavoro va considerato un incremento dei costi energetici lato data center. Va però detto che gli alimentatori utilizzati nei server sono più
efficienti ed hanno meno dispersioni rispetto a quelli di basso costo utilizzati nei PC. Inoltre, i PC classici utilizzano per la
maggior parte del tempo una quantità di risorse elaborative che vanno da un decimo a circa metà di quella disponibile,
che deve però comunque essere tenuta tutta “accesa” anche quando non viene utilizzata, per poter gestire i rari picchi
elaborativi. La virtualizzazione su server sfrutta invece l’asimmetria temporale tra i picchi elaborativi dei vari PC virtuali
ed i tempi di attesa di input da parte dell’utente, assegnando le risorse hardware alle varie macchine virtuali secondo la
necessità del momento. E’ pertanto possibile eseguire una certa quantità di macchine virtuali con solamente un una frazione di quella che sarebbe la somma delle risorse hardware complessive necessarie per dei PC fisici, realizzando quindi
un minore consumo energetico.
• Condizionamento atmosferico ed acustico degli ambienti di lavoro. La necessità di ridurre gli spazi di lavoro o di creare
più posti di lavoro nel medesimo spazio porta inevitabilmente a complicazioni in termini di condizionamento e rumore. Un
thin-client Sun Ray è solid-state, emette pochissimo calore e, rispetto ad un comune PC, assolutamente nessun rumore.
È quindi la postazione di lavoro ideale per coniugare con successo sia le necessità Aziendali che quelle degli operatori.
BENEFICI / VANTAGGI
• Azzeramento furti materiali di postazioni di lavoro
• Drastica diminuzione furti di dati e/o proprietà intellettuale
• Semplificazione degli scenari per la sicurezza fisica del dato (back-up, soluzioni di accesso remoto)
• Semplificazione degli scenari di Disaster Recovery
• Miglioramento della compliance Aziendale alle normative in termini di privacy e gestione dati sensibili
• Drastica diminuzione eventi di fermo produttivo dei dipendenti con conseguente aumento della produttività complessiva
• Drastica diminuzione costi di gestione delle postazioni di lavoro
• Maggiore flessibilità e rapidità nella gestione delle postazioni di lavoro, a fronte di rapide variazioni del volume di richiesta
• Estensione del ciclo di vita delle postazioni di lavoro
• Importante riduzione del consumo elettrico e dei costi di condizionamento ambientale (aria e rumore)
Caso 15
L’evoluzione dei sistemi informatici ha portato alla concentrazione, anche di
peso per metro quadro dei macchinari principali coinvolti, sostituendo macchinari obsoleti con macchinari moderni; in una sala macchina si è verificato un
“crollo” del sottopavimento flottante (evidentemente progettato in passato e al
limite della portata media) con il risultato che alcune macchine nuove si sono
danneggiate; è stato necessario smontare tutto il centro e rifare l’intero pavimento flottante e rimontare tutto. Tempi lunghi per un CED e danno notevole in
tutti i sensi soprattutto per i periodi di mancato utilizzo (danno economico).
79
Caso 9
In un ospedale ottimamente attrezzato, la sezione medicina nucleare era situata negli scantinati e una particolare attenzione era stata dedicata al personale anche di supporto che poteva accedere al piano interrato. Durante un turno di
riposo, la ditta delle pulizie, che normalmente mandava una persona che era stata istruita specificatamente dal personale addetto alle macchine, sostituiva questa persona momentaneamente malata con altra persona del loro staff.
La donna delle pulizie si sostitutiva alla persona malata, e con una grande macchina lava pavimenti procedeva alle
pulizie del sotterraneo; le era stato detto di non entrare nelle stanze ove erano presenti le grandi macchine per le radiografie ma, nonostante l’avvertimento, la signora trovando una porta aperta entra a cavallo della macchina lava pavimenti
industriale pensando di far bene; la macchina a risonanza magnetica era purtroppo rimasta accesa e l’enorme forza del
magnetismo in funzione è risultata talmente potente da attirare improvvisamente la macchina lava pavimenti e con lei
la sfortunata donna delle pulizie.
Risultato: macchina a risonanza magnetica distrutta all’80%, donna delle pulizie deceduta, macchina lava pavimenti
distrutta, blocco da parte della magistratura del reparto ospedaliero e danno per l’ospedale di
svariati milioni di €.
Caso 19
Una società finanziaria ha affidato a un impiegato esperto la gestione di alcuni portafogli, nell’ambito di limiti precostituiti e definiti nei processi operativi informativi. L’individuo ha provveduto a forzare i medesimi ai fini di ottenere sempre
migliori risultati ad ogni fine mese di chiusura del bilancio di attività. Viene scoperto, dopo un periodo di alcuni anni,
che l’ottimo impiegato aveva esposto l’azienda per cifre esorbitanti, e questo quando il volume delle perdite non poteva
più essere nascosto tramite forzatura del sistema informativo.
Caso 21
Un errore di implementazione di una patch di aggiornamento del software messa in produzione blocca un sistema aeroportuale che gestisce 30.000 passeggeri al giorno e merci corrispondenti.
Il blocco totale dura un giorno e diversi sono i giorni necessari per smaltire l’arretrato accumulatosi nello smaltimento
bagagli (con un incremento dei costi di spedizione, e delle perdite dei medesimi).
Caso 22
Un’azienda che produce il suo business con l’aggiudicazione di gare soffre di una riduzione degli esiti positivi con corrispondente riduzione del fatturato annuo. Ad un’indagine più approfondita del management si scopre che la flessione
corrisponde all’uscita di uno dei principali agenti di vendita che si è messo in proprio.
Denunciato il fatto alle autorità, l’indagine di polizia scopre che un programma spyware inserito nei computer dei dipendenti comunicava in real time alla concorrenza, in anticipo sulla data della gara, i piani di vendita e i prezzi che
poi venivano comunicati (ecco perché i prezzi della concorrenza erano sempre inferiori a quelli dell’azienda colpita).
L’Agente di vendita viene arrestato dopo aver scoperto l’indirizzo finale dove arrivavano le informazioni estorte dal programma dannoso, tuttavia la perdita di mercato e il profitto perduti non potranno essere rimborsati per mancanza di
fondi del colpevole. Trattasi di un 30% del fatturato annuo.
Caso 5
Un ente pubblico la cui rete è costituita da moltissime sottoreti ha subito un crash down totale di 1 giorno e malfunzionamenti parziali per i giorni successivi per l’accumularsi di alcuni malware al suo interno. Il calcolo della perdita per
l’ente pubblico, per le sole spese fisse su 10.000 postazioni di lavoro supera il milione e mezzo, mentre la somma delle
spese per tutti gli interventi di disinfestazione su client e server ammonterà a quasi 1 milione di euro.
* Estratti dal documento di Riccardo Scalici “Il panorama dei rischi”
6. Company Profiles
6.1 AIEA
AIEA
L’AIEA è l’Associazione Italiana Information Systems Auditors.
Costituita in Milano nel 1979, l’AIEA riunisce e certifica coloro che in Italia svolgono professionalmente attività di Auditing e Controllo di sistemi ITC sia individualmente, sia come associati, partner
o dipendenti di società.
Gli obiettivi dell’AIEA:
• •
ampliare la conoscenza e l’esperienza dei suoi aderenti nel campo dell’Information Sy-
stems Auditing, favorendo lo scambio di metodologie per lo studio e la soluzione dei problemi
inerenti;
• provvedere ad una adeguata informazione e comunicazione reciproca ai fini dell’aggiornamento
nel campo delle tecniche di auditing nell’Information Technology and Communication;
• promuovere un processo di sensibilizzazione di tutti i livelli organizzativi aziendali alla necessità
di stabilire adeguati criteri di controllo di affidabilità dell’organizzazione e di sicurezza dei sistemi;
• facilitare i rapporti di scambio con analoghe associazioni estere;
• promuovere a livello nazionale la partecipazione degli Information Systems Auditor, alla certificazione C.I.S.A. (Certified Information Systems Auditor)
L’AIEA è membro dell’ISACA, International System Audit and Control Association, l’organismo che
riunisce le associazioni professionali nazionali, che hanno lo scopo di rappresentare e certificare
la figura professionale degli aderenti in quanto conforme alle caratteristiche richieste dai propri
statuti.
Ad ISACA attualmente aderiscono circa 20.000 auditors e consulenti informatici in più di 100
Paesi, di cui circa 3.000 in Europa. Costituita nel 1969 a Los Angeles, l’ISACA organizza conferenze, effettua corsi e seminari, pubblica informazioni tecniche, edita guide, sviluppa, promuove e
regolamenta l’attività professionale, effettua lavori di ricerca e rilascia l’abilitazione CISA di Auditor
di Sistemi Informativi (Certified Information Systems Auditor).
http://www.aiea.it/
Alberto Piamonte
Laureato all’Università di Padova in Ingegneria Elettronica, si occupa attualmente dello sviluppo di
strumenti automatizzati e metodologie per l’analisi e gestione dei rischi, la certificazione conformità e la realizzazione di efficaci ed efficienti sistemi di controllo e di governo.
Oltre che svolgere in prima persona attività di consulenza, come socio AIEA si occupa attivamente
dei problemi relativi al governo dei sistemi IT tenendo frequenti corsi e seminari su metodologie
quali CobiT, ITIL e ISO27001 ed alla sensibilizzazione e diffusione delle relative tematiche.
Inizia la sua carriera come ricercatore IBM con permanenza più che decennale nei laboratori di
ricerca e sviluppo (USA, Germania, Svezia ed Italia) occupandosi principalmente di comunicazioni
(SNA) e relativi problemi di sicurezza.
Successivamente, come Direttore Responsabile del Marketing Olivetti per le Pubbliche Amministrazioni, è stato coinvolti nella gestione e realizzazione di grandi progetti
81
versione 2.0
Più recentemente come Direttore Marketing Software Europa di Amdahl Corporation si è occupato
delle problematiche di gestione e sicurezza di grandi reti di utenti.
Clusit
6.2 Clusit
Nato nel 2000 presso il Dipartimento di Informatica e Comunicazione dell’Università degli Studi
di Milano, il Clusit è la più numerosa ed autorevole associazione italiana di sicurezza informatica.
Oggi rappresenta oltre 500 organizzazioni, appartenenti a tutti i settori del Sistema-Paese (Ricerca,
Industria, Commercio e Distribuzione, Banche e Assicurazioni, Pubblica Amministrazione, Sanità,
Consulenza e Audit, Servizi, Telecomunicazioni, Informatica).
Tra i principali obiettivi:
• diffondere la cultura della sicurezza informatica presso le aziende, la Pubblica Amministrazione e i cittadini;
• partecipare alla elaborazione di leggi, norme e regolamenti che coinvolgono la sicurezza informatica, a livello nazionale ed europeo;
• contribuire alla definizione di percorsi di formazione per la preparazione e la certificazione delle
figure professionali operanti nel settore della sicurezza;
• promuovere l’uso di metodologie e tecnologie che consentano di migliorare il livello di sicurezza
delle varie realtà.
Fanno parte delle attività:
• formazione specialistica;
• certificazioni professionali (CISSP, CSSLP e BCI);
• produzione di documenti tecnico-scientifici;
• ricerca e studio (tra questi il premio ‘Innovare la Sicurezza delle Informazioni’ per la migliore
tesi universitaria);
• attività convegnistica (oltre 50 convegni all’anno);
• manifestazioni specialistiche (in particolare il Security Summit www.securitysummit.it);
• condivisione delle informazioni (information sharing).
L’associazione mette a disposizione Online Sicuro, un portale italiano per la sicurezza delle informazioni e delle reti, con servizio di assistenza online per i cittadini. È inoltre promotrice del progetto ‘Rischio IT e piccola impresa’, dedicato alle piccole e microimprese.
http://www.clusit.it/
Mauro Cicognini
Laureato nel 1995 al Politecnico di Milano in ingegneria elettronica (specializzazione in ingegneria
biomedica, derivante da una personale passione le neuroscienze), ha lavorato a lungo nell’ambito tecnico, prima da specialista e poi da manager, in aziende di varie dimensioni nel settore dei
servizi e dell’alta tecnologia (software, systems integration, telecomunicazioni, automazione industriale). Ha avuto l’occasione di progettare prodotti e servizi, e di gestire la realizzazione di progetti
in realtà dalla PMI alla multinazionale. Ha conosciuto così il modo di fare business del credito, dei
servizi, dell’alimentare, dell’industria manifatturiera; ha inoltre servito con profitto il mondo della
pubblica amministrazione, della sanità e della difesa. Da tempo coltiva una forte attenzione alle
tematiche di organizzazione dei processi e di rispetto delle normative; interesse che lo ha portato a
costituire intorno a sé – tra il 2001 ed il 2006 in Siosistemi S.p.A. – un gruppo di consulenti attivi
sulla conformità legale e sugli standard internazionali (Privacy, ISO 9000, ISO 27000).
82
6. Company Profiles
Dopo una fruttuosa esperienza manageriale in ambito commerciale e marketing in I.NET S.p.A. e
quindi in BT Italia S.p.A., si dedica da qualche tempo alla consulenza direzionale, in tutti quegli
ambiti dove il successo del progetto nella grande scala richiede non solo una buona tecnologia ma
anche un’eccellente organizzazione ed una chiara leadership.
Collabora dal 2006 con il Clusit, dove siede nel Comitato Direttivo e nel Comitato Tecnico Scientifico. Per Clusit Education è il coordinatore dei seminari, ed ha tenuto sessioni sulla Business
Continuity, sugli aspetti di sicurezza dell’RFID, sulla sicurezza fisica, ed altri.
6.3 Oracle
Oracle
Presente in oltre 145 paesi nel mondo con 85.000 dipendenti e un fatturato GAAP nell’anno fiscale 2009 di 23,3 miliardi di dollari, Oracle Corporation è la più grande società al mondo di software
per le imprese. Vi operano attualmente 21.000 sviluppatori per un investimento in R&D pari a 2,8
miliardi di dollari.
Oracle ha sempre messo la sicurezza al centro dei propri prodotti e, anche a seguito di alcune
acquisizioni mirate in quest’area (Oblix, OctetString, Thor Technologies, Bridgestream, Bharosa),
oggi fa sì che le organizzazioni possano contare su infrastrutture IT protette sia dalle minacce
esterne che da quelle interne. Ciò è possibile grazie a prodotti, tecnologie e processi che consentono di indirizzare tutte le esigenze in termini di sicurezza, privacy e rispetto delle normative.
Oracle propone tecnologie per il controllo degli accessi basato su privilegi e sulla combinazione
di più fattori, di classificazione dei dati e di cifratura trasparente, di auditing, di monitoraggio e
di crittografia dei dati. In area middleware propone Oracle Identity Management che consente di
gestire l’intero ciclo di vita delle identità degli utenti su tutte le risorse aziendali sia all’interno sia
all’esterno del firewall.
In Italia, Oracle è impegnata a far crescere il livello di competenza del sistema attraverso la Oracle
Community for Security. Nata nel 2007, si tratta della comunità dei Partner di Oracle dedicata alle
tematiche che ruotano intorno alla sicurezza informatica. Oggi conta circa 30 membri.
http://www.oracle.com/global/it/security/partner.html
Alessando Vallega
In Oracle Italia dal 1997 come Project Manager in ambito ERP e nell’Information Technology dal
1984, è Business Development Manager e si occupa di Governance Risk and Compliance, Database Security ed Identity & Access Management. Inoltre è il coordinatore della Community for Security, responsabile della Governance del programma italiano delle Partner Community e membro
attivo del team di Governance delle Partner Community dell’area Western Continental Europe di
Oracle. Dal 2010 fa parte del Comitato Direttivo di Clusit.
Giuseppe D’Asta
Laureato in Scienze delle Comunicazione e Marketing, lavora in Oracle Italia dal 2008 come Business Development Representative nel team di Business Development, all’interno della struttura
di vendita Technology. Si occupa della gestione e organizzazione dei programmi di demand generation e lead generation per il mercato italiano, con particolare focalizzazione alle attività correlate
alle aree di prodotto di Database Security e di Identity & Access Management. Inoltre, supporta i
lavori promossi dalla Community italiana di Partner Oracle sulle tematiche dell’IT Security e della
Governance Risk & Compliance.
83
Deloitte
versione 2.0
6.4 Deloitte
Deloitte è una fra le più grandi realtà nei servizi professionali a livello mondiale. In Italia è presente
dal 1923 e oggi conta circa 2.800 professionisti. L’offerta multidisciplinare, unica nel suo genere,
è articolata in diverse società specializzate in singole aree professionali: audit, tax, consulting e
financial advisory.
Deloitte ERS Enterprise Risk Services Srl è la società del network Deloitte leader mondiale nell’offerta di servizi in materia di Corporate Governance, Sistemi di Controllo Interno, gestione dei rischi
aziendali, regulatory compliance, Sicurezza e Privacy.
In Italia questa è costituita da oltre 200 professionisti dedicati alle tematiche del rischio aziendale:
opera infatti su 8 uffici dislocati sul territorio nazionale e vanta competenze multidisciplinari e
specialistiche, molte delle quali attestate da certificazioni e titoli riconosciuti a livello internazionale
quali CIA, CRSA, CCSA,CISA, CISM, CISSP, BS7799 - Lead Auditor (ISO27001), Quality Assurance, LoCSI (Localizzazione Competenze Sicurezza Informatica), ITIL e Revisore contabile.
Il nome Deloitte si riferisce a una o più delle seguenti entità: Deloitte Touche Tohmatsu (una Verein
svizzera), le member firm aderenti alla sua rete e le relative entità controllate e/o licenziatarie,
ciascuna delle quali è un’entità giuridicamente separata ed indipendente. Si invita a leggere l’informativa completa relativa alla descrizione della struttura legale di Deloitte Touche Tohmatsu e
delle sue member firm all’indirizzo web www.deloitte.com/it/ChiSiamo
Andrea Longhi
Deloitte Enterprise Risk Services
In Deloitte dal 2003, è Director della Service Line Security & Privacy Services.
Durante la sua ventennale esperienza ha ricoperto posizioni di responsabilità in primarie aziende
di Consulenza e System Integration quali Arthur Andersen e Cap Gemini Italia, sviluppando forti
competenze in tema di sicurezza informatica, organizzazione e gestione di progetti complessi. In
particolare è punto di riferimento per le tematiche di Information & Communication Security, Physical Security e Risk & Compliance Management.
http://www.deloitte.com/view/it_IT/it/servizi/ERS/security-services/index.htm
Ernst & Young
6.5 Ernst & Young
Ernst & Young è leader mondiale nei servizi professionali di revisione e organizzazione contabile,
fiscalità, transaction e advisory. Il network Ernst & Young fornisce anche consulenza legale, nei
paesi ove è consentito. In tutto il mondo le nostre 144.000 persone sono unite da valori condivisi
e da un saldo impegno costantemente rivolto alla qualità. Facciamo la differenza aiutando le nostre persone, i nostri clienti e la nostra comunità di riferimento ad esprimere pienamente il proprio
potenziale.
Nell’ambito dei servizi di advisory, i nostri professionisti della sub-service line IT Risk & Assurance
aiutano le organizzazioni ad affrontare la sfida della gestione dei rischi informatici mantenendosi in
linea con la strategia aziendale. Grazie alla vasta esperienza in questo ambito, i nostri team hanno
a disposizione la profonda conoscenza tecnica e di gestione del rischio informatico della nostra organizzazione globale e possono così garantire ai clienti e alle parti interessate che i principali rischi
informatici della loro organizzazione saranno identificati, compresi e gestiti in maniera efficace.
Offriamo servizi su misura, che vanno dalla valutazione e gestione del rischio informatico, sicurez84
6. Company Profiles
za e privacy, alla revisione di controlli su specifici sistemi di Enterprise Resource Planning e terze
parti.
Per maggiori informazioni: www.ey.com; [email protected]
Raoul Savastano
Partner di Ernst & Young, è responsabile dei servizi di ICT Security.
Ha maturato una significativa esperienza nell’ambito dei servizi professionali relativa alla gestione
della sicurezza informatica, occupandosi della definizione di modelli organizzativi, metodologie di
risk assessment, definizione di piani di interventi di sicurezza, valutazione dell’efficacia dei sistemi
di controllo IT e conformità alle normative.
Laureato in Economia e Commercio, è certificato Lead Auditor ISO27001, CISM e CGEIT e collabora con le principali associazioni del settore, intervenendo a convegni e seminari; è inoltre autore
di alcuni scritti nell’ambito della gestione dei rischi IT e della sicurezza delle informazioni.
Andrea Mariotti
Senior Manager di Ernst & Young Financial Business Advisors S.p.A., ha maturato una esperienza
più che decennale nel settore dell’Information Technology con particolare riferimento alle tematiche inerenti l’information security, la business continuity e la compliance alle normative.
Laureato in ingegneria, è socio delle principali associazioni di settore ed ha ottenuto le certificazioni CISA, CISM, Lead Auditor ISO27001, Lead Auditor ISO20000; ha inoltre partecipato come relatore a diversi convegni e seminari sul tema della sicurezza dei sistemi informativi ed ha contribuito
ad alcune pubblicazioni in tema di analisi dei rischi IT e sicurezza informatica.
Riferimenti bibliografici
Ernst & Young’s 12th annual global information security survey
KPMG
6.6 KPMG
KPMG è un network globale di società di servizi professionali, attivo in 146 paesi del mondo con
circa 144 mila persone: in Italia, il network KPMG è rappresentato da diverse entità giuridiche attive nel business advisory, nella revisione e organizzazione contabile, e nei servizi fiscali e legali.
I servizi di IT Advisory di KPMG contano circa 500 professionisti in Italia presenti in 6 uffici e si
focalizzano sullo sviluppo, sulla gestione dei sistemi informativi e sul presidio dei relativi rischi.
KPMG possiede le conoscenze e le esperienze necessarie a supportare le aziende nella ricerca di
soluzioni che abilitano l’innovazione e incrementano le perfomance, bilanciando rischio informatico e necessità di raggiungere obiettivi strategici e finanziari.
Grazie ad un approccio multidisciplinare unico all’interno del panorama nazionale, KPMG è in
grado di assistere le aziende nei processi di allineamento dei servizi IT alle strategie aziendali,
offrendo un giusto bilanciamento di rischi, innovazione, performance, con attenzione ai costi e alle
best practice di settore e nel rispetto della compliance.
La business unit “Security and IT Risk & Compliance”, focalizzata negli ambiti della sicurezza
dei sistemi informativi, compliance, sicurezza e monitoraggio delle performance, ha l’obiettivo di
garantire ai propri clienti un servizio di eccellenza nella valutazione e nello sviluppo di strategie
e soluzioni a supporto del business che riducono i rischi associati alla pianificazione, all’introduzione e alla scelta di tecnologie. Effettua valutazioni indipendenti sulle strategie, sui progetti e
sulla sicurezza, fornendo valore e soluzioni per l’impresa nell’ambito della security, della privacy e
85
versione 2.0
dell’integrità dei dati; ottimizzando la gestione dei rischi e delle risorse IT con un pieno controllo
dei livelli di servizio e dei costi.
Pierluigi Lonero
Nato nel 1969 frequenta l’Accademia Navale (Livorno- 87/91), si laurea in Scienze dell’Informazione (Milano -1996) ed in Scienze Politiche (Trieste -2004). Nel 2000 lascia la Marina Militare,
dove é comandane di unità navale, per occuparsi di consulenza, nel 2006 si unisce Network KPMG
come Senior Manager.
Esperto IT Advisory, Information Risk Management e Security. Ha sviluppato forti competenze nella
gestione di progetti complessi, nell’analisi dei processi e dei sistemi informativi, IT Audit, IT Governance, e dell’integrazione dei sistemi con focus sull’analisi rischi, sicurezza e compliance normativa.
Ha operato prevalentemente negli ambiti TELCO, Energy e Multiutilities, Public Sector.
Luca Boselli
Nato ne 1975, si è laureato in Economia Aziendale presso l’università L.Bocconi di Milano. In
KPMG dal 2001, è attualmente Senior Manager nell’ambito dei servizi di Information Protection
& Business Resilience all’interno del gruppo IT Advisory - Information Risk Management. Ha
conseguito la certificazione CISA e la qualifica di Lead auditor ISO27001. Ha maturato esperienze
significative in progetti complessi principalmente in aziende e gruppi privati, nelle seguenti aree di
intervento: Business Process Analysis, Information System Audit, Security & Business Continuity,
IT Governance & Compliance, Enterprise Risk management.
Alberto Borgonovo
Laureato in Ingegneria delle Telecomunicazioni nel 2003, ha ottenuto le certificazioni CISA, Lead
Auditor 27001, OPST, Prince2 Foundation ed ENA.
In KPMG da Gennaio 2005, dopo un periodo di attività nell’ambito IT, ha maturato una significativa esperienza nella gestione di progetti relativi ai servizi di Information Security e Risk Management. Nel corso di tali attività ha acquisito competenze relativamente a tematiche quali security
risk assessment, identity and access management, business continuity, IT compliance, IT audit,
business impact analysis, IT governance, ethical hacking, security policy e standard di sicurezza
informatica.
PricewaterhouseCoopers
6.7 PricewaterhouseCoopers
Il network PricewaterhouseCoopers (PwC) è una delle principali organizzazioni internazionali di
servizi professionali alle imprese. L’obiettivo di PwC è creare valore per i propri clienti e produrre
vantaggio competitivo per le loro attività facendo leva sui valori dell’integrità e della qualità dei servizi offerti. PwC opera in 151 paesi nel mondo con oltre 163.000 professionisti di cui circa 3.000
presenti in Italia in 17 uffici.
La rete globale di specialisti PwC in Information Security conta oltre 3.200 professionisti. Secondo
una ricerca di Forrester “PwC risulta leader di mercato per ciascuno dei seguenti tre criteri di
valutazione: ampiezza dell’offerta, strategia, e presenza sul mercato”. La nostra Value Proposition
include:
• costante ricerca e sviluppo nel settore;
• metodologie omnicomprensive per ogni ambito di intervento;
86
6. Company Profiles
• vaste competenze specialistiche in tutti i settori;
• indipendenza ed eticità.
In ambito Information Security PwC Advisory offre una gamma di servizi end-to-end, erogati attraverso 4 principali filoni:
• Security Governance, Strategy and Planning: analisi e disegno del sistema di gestione della
sicurezza, analisi dei rischi, security policy, conformità a leggi e regolamenti e simili;
• Identity Management and Application Security: regole di autorizzazione, controllo degli accessi,
gestione delle utenze e sicurezza delle applicazioni;
• Threat & Vulnerability Management: censimento degli asset, verifica delle minacce e delle
vulnerabilità, Attack & Penetration, information management, ecc.;
• Crisis Management and Cybercrime: gestione delle crisi, investigation degli incidenti e remediation.
http://www.pwc.com/it/it/index.jhtml
Sebastiano D’Amore
Sebastiano è un Director in PricewaterhouseCoopers Advisory responsabile per lo sviluppo dei
servizi di IT Effectiveness, Security, Technology e Data Services.
Sebastiano è inoltre Chief Information Officer della network PwC Italiana e negli anni 2006/2008 è
stato responsabile dei servizi di security nelle Eurofirms di PwC.
Sebastiano ha ottenuto uno “Bachelor of Business & Administration (Double majors in Accounting
& Law)” dalla Curtin University of West Australia (BBus accgt & law). E’ professionalmente qualificato dall’Australian Institute of Chartered accountants (ACA). E’ inoltre un “Certified Information
Security Manager” (CISM) e “Certified Governance of Enterprice IT” (CGEIT) dell’ISACAA ed ha
conseguito numerosi attestati fra cui il “BS7799 Lead Auditor”.
Durante la sua carriera ha eseguito o è stato responsabile per circa 1000 incarichi presso clienti
PwC, ricoprendo anche ruoli operativi e manageriali e operando in una varietà di settori, fra cui
Information & Communication Technology (ICT) e Consumer & Industrial Products (CIP).
Le attività di “Partner Relationship Management” lo hanno coinvolto con i più importanti operatori
del mondo della sicurezza.
Fabio Lorenzo
Fabio è un Manager in PricewaterhouseCoopers Advisory responsabile per le attività in ambito
Information Security e IT Effectiveness.
Fabio è laureato in Ingegneria delle Telecomunicazioni presso il Politecnico di Milano Ha conseguito gli attestati di “ISO 27001 Lead Auditor” e “ITIL V3 Foundation”.
Durante la sua carriera in PwC ha preso parte a numerosi incarichi presso clienti, ricoprendo sia
ruoli operativi sia manageriali e operando in una varietà di settori industriali fra cui Information &
Comunication Technology (ICT), Consumer & Industrial Products (CIP), Financial Services, Retail
ed Entertainment.
Giuseppe D’Agostino
Giuseppe è un Senior Consultant in PricewaterhouseCoopers Advisory. Dal 2007 fa parte del
gruppo Technology & Data Services e si occupa prevalentemente di progetti in ambito Information
Security.
Giuseppe è laureato in Ingegneria delle Telecomunicazioni presso il Politecnico di Milano.
87
versione 2.0
Durante la sua esperienza in PwC ha preso parte a numerosi incarichi presso clienti del settore
Information & Comunication Technology (ICT) e Consumer & Industrial Products (CIP), ricoprendo
ruoli operativi ed assistendo il manager nelle attività di Project Management.
Caso 11
Un porto container a gestione avanzata è in grado di garantire un tempo di carico/scarico
dei container in transito inferiore al minuto e mezzo. Il volume di container depositati e in
transito si aggira sui 30mila giornalieri e costituisce una delle principali fonti di reddito della
zona.
La gestione avanzata è costituita da un sofisticato sistema informatico che recepisce ed
integra le informazioni in arrivo da navi e traffico su gomma o ferro, raccoglie in un sistema
efficiente le prenotazioni di carico e scarico, tempi e programmazioni con aggiornamenti in
tempo reale di tutto il database sulla situazione e posizionamento di ogni container stoccato
da caricare o scaricare sui mezzi di trasporto.
Una nuova release più performante del programma viene elaborata e messa in produzione , il
sistema si impalla malamente e viene danneggiato anche il database (si perdono le posizioni
e le informazioni di circa un migliaio di container), ma quello che è peggio è che non si riesce a trovare il mezzo di ritornare alla situazione pre-incidente. Navi vengono dirottate verso
altri porti, code chilometriche sulle strade di accesso al porto container, treni merci fermi
nelle stazioni; risultato: una riduzione del 24 % del totale merci in transito per la regione sul
quale esiste il porto; i danni economici diretti sono quantificabili, ma quelli indiretti a terzi
e da responsabilità assumono dimensioni incalcolabili. Dopo circa 3 mesi, durante i quali la
situazione da fuori controllo passa ad un controllo limitato e poi ad una normalizzazione, il
porto torna ad una normalità, ma molti clienti hanno deciso di trasferirsi altrove e il recupero
dei flussi di merci non tornerà, almeno per qualche anno ai regimi precedenti (il danno non
è stato solo immediato, ma ha avuto anche strascichi per lunghissimo tempo).
Caso 13
Una società di telecomunicazioni propone dei servizi aggiuntivi ai propri clienti, tra i quali
l’abbinamento ai servizi telefonici fissi con quello dei portatili; cioè, in pratica, è possibile
addebitare i costi del cellulare sul contratto del fisso. Per rendere l’operazione molto semplice ed appetibile, vengono volutamente “semplificate” le operazioni di riconoscimento delle
istruzioni al servizio automatizzato. Il crimine organizzato provvede a verificare il punto debole delle procedure e si inserisce nel sistema trasferendo ingenti costi di traffico telefonico
(probabilmente vendendo in automatico tale potenzialità di traffico reperita dolosamente)
ai conti degli ignari frodati. Alla resa dei conti, quando vengono richieste somme milionarie
di recupero di traffico telefonico, la società di telecomunicazione si accorge del “buco” e
provvede a trattare un accomodamento interno con i creditori; ai clienti restituisce conteggi
depurati di tale abnorme traffico per un normale pagamento delle bollette.
* Estratti dal documento di Riccardo Scalici “Il panorama dei rischi”
88
7. Appendici e Revisioni
7.1 Appendice A
Si veda la tabella “Analisi Top Down”, disponibile sul sito http://rosi.clusit.it/
7.2 Appendice B
Si veda la tabella “Aree d’Intervento”, disponibile sul sito http://rosi.clusit.it/
7.3 Storia delle versioni
7.3.1 Versione 1
La versione 1 corrisponde alla prima release pubblica. È stata presentata il 16 marzo 2010 a Milano in occasione del Security Summit 2010.
7.3.2 Versione 2
La versione 2, rilasciata in concomitanza con il Security Summit 2011, riorganizza l’esposizione
del metodo ed incorpora contributi forniti da autori che non facevano parte del Gruppo di Lavoro
originale, ma hanno volontariamente contribuito il loro know-how ed il loro tempo, e ad essi va il
sentito ringraziamento del GdL:
• Riccardo Scalici, responsabile sottoscrizione rischi informatici per l’Italia,
ACE European Group Ltd
• Claudio Pasi, Responsabile Div. Tecnologia, Sinfo One
• Enzo M. Tieghi, ServiTecno S.r.l. e consigliere AIIC
• Stefano Saibene, Deutsche Bank - PBC - Project & Process Management
• Andrea Zapparoli Manzoni, Principal Security Consultant, B.U. Security
Gruppo Terasystem
• Matteo Galimberti, Security Program Manager, B.U. Security Gruppo Terasytem
• Giacomo Aimasso, CISA, CISM, CTO B.U. Security, Gruppo Terasystem
• Paolo Marelli, Senior Sales Consultant - VDI Global Business Unit
• Giuseppe Russo, Chief Technologist e Security Top Gun, Oracle Italia
89
http://rosi.clusit.it
matteo olivari :: [email protected]

ROSI Return on Security Investments: un approccio pratico

Transcript

Documenti analoghi

ABI_Basilea 2016_CV Diego Travaini

La tregua di Francesco Rosi con Claudio Bisio, John Turturro

La tregua - Andrea Crisanti

La tregua

GlobalTrust RMS

Matteo Meucci

Rocco ei suoi fratelli

Apri PDF

La figura del security manager - Università degli Studi del Sannio

Configurazione Porte - eMule-Wiki