1

Considerazioni sul Risk Management

Gruppo Fondiaria-SAI

Pietro RANIERI

Sicurezza e Privacy

pietro.ranieri@fondiaria-sai.it

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

pietro.ranieri@fondiaria-sai.it