considerazioni sul risk management - ated.ch · attivazione delle contromisure esposizione al...
TRANSCRIPT
1
Considerazioni sul Risk Management
Gruppo Fondiaria-SAI
Pietro RANIERI
Sicurezza e Privacy
Lugano, 13 gennaio 2006
2
L’analisi
3
L’analisi
Per la gestione del rischio, ed in particolare per il rischio informatico, è indispensabile disporre di un’accurata analisi.
Partendo da questa è possibile giungere alla definizione di un opportuno piano di contromisure.
Di norma perché l’analisi sia efficace e porti alla definizione di interventi coerenti con le esigenze del business, si parte proprio dall’analisi dei processi aziendali “core”, valutando il sistemainformativo attraverso la lettura di questi ultimi.
4
L’analisi
Un analogo approccio è stato seguito nel 2001 in un progetto di Risk Assessment/Management presso l’allora Gruppo SAI.
- Definizione delle politiche aziendali di sicurezza ad alto livello- Definizione dei compiti e delle responsabilità della funzione sicurezza
Matrice di valutazione del
rischio
Modelli dei processi di business
Matrice di valutazione degli
assetIdentificazione
assetAsset
ModelingValutazione
Asset
Vulnerabilità eMinacce
IdentificazioneContromisure
IndividuazionePolicy
Piano di Implementazione
Fase 1: Identificazione eValutazione Asset
Fase 2:Analisi Minacce e Vulnerabilità
Fase 3:Politiche di Sicurezza
Attivazione delle contromisure
Esposizioneal Rischio
5
L’analisi
L’analisi si è sviluppata partendo dall’indice dei controlli previsti dal Cobit utilizzando a supporto lo strumento CRAMM
Continuità del businessImmaginePerdite finanziarieInteressi economici e commercialiPrivacy e dati personaliAdempimenti legali e normativiRispetto delle leggi
Indisponibilità delle informazioni
Distruzione delle informazioni
Divulgazione delle informazioni
Modifiche non autorizzate
Alterazione della comunicazione
Scenari di impatto Eventi Dannosi
6
Le politiche
7
Le Politiche
Completata la fase di analisi dei processi aziendali (che postuliamo corretti) è il momento di redigere una politica di sicurezza, adeguata al contesto.
…. una politica di sicurezza documentata, conosciuta ed accettata da tutta l’organizzazione. Tale politica deve essere periodicamente rivista per garantirne l’aggiornamento coerentemente con il mutare delle esigenze di business e l’evolversi delle tecnologie.
Devono essere assegnate formalmente la proprietà dei dati …. e le relative responsabilità ….
Le informazioni devono essere classificate in base alla loro riservatezza ….
8
Il ruolo delle Politiche
Nella definizione del piano di interventi la disponibilità di una politica svolge un ruolo determinante.
Queste ha diverse funzioni:Formalizza le regole generali di sicurezza in coerenza con il business dell’azienda.Definisce le caratteristiche in base alle quali valutare gli assetinformatici per la gap analysis.Stabilisce le linee guida per il disegno degli aspetti di sicurezza delle nuove soluzioni informatiche.Definisce il perimetro di azione del responsabile della sicurezza riducendo la necessità di negoziazione
9
Gli aspetti operativi
La definizione di politiche per ottenere un adeguato contesto non esclude la necessità di affrontare gli aspetti più tecnici.
Alla fine del processo occorre comunque affrontare la gestione operativa della sicurezza e le sue implicazioni in termini di costi, in particolare quelli nascosti nell’aumentata complessità delle procedure.
Se ci poniamo in quest’ottica il lavoro di analisi subisce una “frattura”, portando il piano delle verifiche da una lettura perprocessi di business ad una visione incentrata sulle infrastrutture.
10
Gli interventi
11
La gap analysis
In definitiva dall’attività di gap analysis emerge un insieme di contromisure da applicare in modo puntuale agli asset informaticiinteressati dall’analisi del rischio condotta.
Una volta esaminati complessivamente questi interventi si traducono molto spesso (ma non sempre!) in impostazioni a livello di infrastruttura e quindi assumono una valenza affatto generale.
12
Le definizioni
Un tipico esempio estratto da politiche:
2. Sicurezza logica
2.1 Identificazione ed autenticazione
2.1.1 Identificativi utenteDeve essere garantito che ogni attività svolta sia legata ad un individuo in maniera univoca.
2.1.2 Lunghezza delle passwordLe password devono essere difficili da individuare.
2…..
Si tratta per lo più di dichiarazioni di principio da declinare rispetto alla tecnologia in uso.
13
Le definizioni
Ma l’analisi può scendere molto in dettaglio per ogni linea di business arrivando a definire interventi puntuali per ogni tipo di tecnologia adottata.
Il limite di un approccio profondamente analitico sta nella rapida obsolescenza.
Definire in dettaglio le caratteristiche di configurazione di unsistema operativo è un’operazione che va rivista al più ogni seimesi.
14
Nello schema di approccio canonico le dichiarazioni di principioderivano dall’analisi del rischio condotta sulle aree di business e possono condurre a risultati analoghi o sovrapposti per diverse aree
Amministrazione
Applicazione 1
Fattori comuni
Commerciale
Applicazione 2 Applicazione 3
Sistema Operativo 1 Sistema Operativo 2 Sistema Operativo 1
Hardware1 Hardware2 Hardware1
Data Base 1 Data Base 2 Data Base 2
15
Fattori comuni
Se riprendiamo ad esempio la politica relativa all’identificazione delle utenze, osserviamo che è applicabile ai componenti sensibili deisistemi informativi descritti:
Applicazione 1Sistema Operativo 1 Data Base 1
Applicazione 2Sistema Operativo 2Data Base 2
Applicazione 3
Ma una considerazione analoga potremmo farla su altri argomenti per la gestione della rete o dell’hardware.
16
Criteri comuni di sicurezza
In sostanza si tratta di una serie di configurazioni da applicare a tutti gli elementi facendo i dovuti aggiustamenti imposti dai limiti della tecnologia (e non solo da questa).
Risulta evidente che molti interventi hanno caratteristiche comuni (ad esempio la definizione delle utenze e delle password) e si applicano a sistemi omogenei.
I criteri di sicurezza minimi in genere si equivalgono per i DB e per i sistemi operativi dell’esempio.
17
Criteri comuni di sicurezza
Altri esempi tipici riguardano le politiche di aggiornamento deisistemi:
È essenziale aggiornare i sistemi con le correzioni previste dai produttori.
Oppure la definizione di configurazioni sicure (“hardening”) degli stessi:
Configurare i sistemi perché non espongano servizi non necessari è un’ottima tecnica per ridurre i rischi di violazione.
18
Un approccio su due livelli
19
L’esigenza specifica
È scontato che l’analisi di sicurezza possa portare a conclusioni diverse, in termini di esigenze, per le diverse LOB o per alcuneapplicazioni.
L’esempio più semplice da fare riguarda l’adozione di meccanismidi crittografia per le comunicazioni o per l’archiviazione di dati.
In ordinarie applicazioni in ambito civile non è sostenibile l’utilizzo di crittografia diffusa per la trasmissione o l’archiviazione dei dati, tuttavia spesso risulta indispensabile (ed a livelli adeguati) anche in attività molto comuni (es. consultazione di un conto corrente online).
20
Conciliare i metodi
L’apparente contraddizione si può risolvere segmentando l’approccio all’analisi:
Da un lato si applica la metodologia “classica” di analisi del rischio senza giungere all’esame delle infrastrutture ma indicando a livello di politiche i contenuti di sicurezza specifici o particolari (es. esigenza di non ripudio).Dall’altro si analizza in modo dettagliato ed organico l’infrastruttura, indipendentemente dai servizi che eroga, comparandola con i modelli, gli standard o la letteratura di riferimento.
21
Il livello dell’infrastruttura
Possiamo cioè pensare di realizzare un piano di sicurezza per l’infrastruttura che prevede un approccio basato sugli standard di settore.
Otteniamo così un buon livello di sicurezza minimo sul quale erogare qualsiasi applicazione.
Il fatto che si tratti di impostazioni a livello di infrastruttura consente un rapporto costo/sicurezza minore ed una migliore condivisione con gli utenti dei servizi informatici.
Resta “aperto” il problema di calcolare ed attribuire i costi ed i benefici relativi alla sicurezza dell’infrastruttura.
22
Il livello specifico
Allo stesso tempo possiamo identificare ed isolare gli interventi particolari derivanti da attività di business con esigenze più avanzate e che possono essere correttamente valutati solo con l’analisi “classica” impostando la verifica a partire dalla valutazione del rischio (impatto, minacce, vulnerabilità).
In questo caso è relativamente semplice definire la validità economica di un intervento di sicurezza.
23
Il Disaster Recovery
…
AS400Linux
CommercialeAmministrazione
Vist
a Te
cnol
ogic
a UnixMSFTMainframe
HRSCM
24
Il Disaster Recovery
In un piano di DR la tecnologia abilitate è fortemente condizionante per la selezione delle informazioni da salvaguardare.
Un’analisi dei sistemi da replicare è necessaria laddove la tecnologia è meno consolidata, la complessità maggiore ed i costi (soprattutto quelli di gestione del piano) più elevati.
Nell’ambiente mainframe la tecnologia consente di affrontare il piano con un minore livello di dettaglio rispetto alla criticità delle informazioni.
25
L’evoluzione
In coerenza con l’evoluzione delle soluzioni tecnologiche molte realizzazioni di sicurezza avanzate, derivanti da esigenze particolari, finiscono per entrare a far parte degli elementi diinfrastruttura.
Nel tempo rimane comunque valida la scissione di metodo:valutazione del rischio partendo dalle esigenze di business valutazione dell’infrastruttura partendo dagli standard
Ovvero il metodo di aggiornamento segue lo stesso schema di principio.
26
La flessibilità
Rispettando l’ambito definito dalle politiche, è così possibile apportare delle variazioni all’infrastruttura con tempi compatibili con la rapidità di evoluzione della tecnologia, garantendo adeguato beneficio a tutti i servizi che la utilizzano.
È anche possibile (necessario) specializzare la responsabilità degli interventi, lasciando l’analisi del rischio ai responsabili della sicurezza e la valutazione dell’infrastruttura ai responsabili dei servizi di base (resp. Sistemi, resp. Rete, DBA, …).
27
Grazie per l’attenzione
Gruppo Fondiaria-SAI
Pietro RANIERI
Sicurezza e Privacy