• Non ci sono risultati.

Titolo e autor

Capitolo 2 L’importanza della gestione del rischio in Telecom Italia

1. Valutazione del rischio, caratteristica delle prime fasi del ciclo di vita del software (gestione dei requisiti, progettazione e parte dello sviluppo) e finalizzata a classificare

2.3.1 Valutazione del rischio

Ogni sistema presente nei cataloghi di Telecom Italia deve essere sottoposto a questa fase del processo di ICT Risk Management. La valutazione del rischio si compone di tre sotto- processi:

a) Demand management, finalizzato a individuare i requisiti di alto livello che il sistema deve rispettare;

b) ICT Risk Analysis, avente l’obiettivo di determinare il grado di copertura dei requisiti rispetto alle caratteristiche del sistema;

c) ICT Risk Treatment, diretto a determinare gli interventi da effettuare per rispondere a ogni requisito del sistema;

La figura 2.6 evidenzia la relazione sequenziale tra i sotto-processi, ognuno dei quali interviene su una fase del ciclo di vita del software. Le funzioni che interagiscono in questa prima fase sono Demand & Assurance Management (DA), Technical Security (TS) e Application Development & Management (ADM).

54

Figura 2.6 - Mappatura della fase di Valutazione del rischio

Si riporta di seguito una sintetica descrizione dei tre sotto-processi della Valutazione del rischio.

a) Demand Management

Come già anticipato, il processo si attiva nel momento in cui la funzione cliente richiede a Technical Security di effettuare la valutazione del rischio di un sistema (nuovo o già esistente). Dopo aver analizzato la documentazione tecnica del sistema per comprenderne le caratteristiche principali, TS richiede alla funzione Demand & Assurance Management (DA) di compilare un questionario finalizzato a valutare il rischio e rappresentarlo con un valore numerico. Tale valore è chiamato VCI (Valutazione della Criticità Intrinseca) e varia tra 6 e 1250 in funzione della criticità del sistema e l’impatto sul business del sistema stesso. Il sistema viene quindi assegnato a una fascia di criticità (C1, C2 o C3) ed è definito “critico” se appartiene alla fascia più alta (C3) e “non critico” se appartiene a una delle fasce più basse (C1 e C2). Questa classificazione determina il tipo di trattamento del rischio da adottare negli step successivi.

Compilata la VCI, Technical Security seleziona i requisiti di sicurezza che il sistema deve soddisfare da un elenco chiamato “libreria dei requisiti”.

L’output principale di questo sotto-processo è il Contributo di Sicurezza (CdS), documento redatto da Technical Security che contiene le informazioni specifiche del sistema (nome, codice, funzione svolta, stato), il valore di criticità e l’elenco dei requisiti individuati. Il CdS viene inoltrato alla funzione DA che provvede a stimare il costo di implementazione dei requisiti di sicurezza definiti. Questa stima sarà impiegata nel successivo ICT Risk Treatment.

55 b) ICT Risk Analysis

L’ICT Risk Analysis ha l’obiettivo di valutare lo scostamento tra i requisiti richiesti e quelli già coperti dal sistema, al fine di progettare opportune contromisure di sicurezza.

La prima attività di questo sotto-processo è differente a seconda della tipologia di sistema in esame:

- Se il sistema è critico, la funzione preposta alla progettazione dei sistemi (Application Development & Management) verifica lo stato di copertura dei requisiti di sicurezza e ne invia un resoconto a Technical Security. Quindi, TS provvede a identificare tutte le componenti con cui il sistema deve interagire all’interno del contesto in cui sarà inserito (modellazione del sistema). Infine, effettua la Gap Analysis tra i requisiti presenti nel Contributo di Sicurezza e quelli che ADM ha dichiarato già coperti;

- Se il sistema è definito non critico, il processo è semplificato in quanto, dopo la verifica di copertura dei requisiti effettuata da ADM, Technical Security si occupa soltanto di convalidarne i risultati.

Successivamente Technical Security si occupa di gestire i requisiti non coperti, stimando la probabilità di accadimento di ognuno di essi, che dipende dalla frequenza di incidenti riscontrati, dal numero di vulnerabilità registrate e dal tempo e dalle competenze necessari per individuare e sfruttare le vulnerabilità.

Il risultato delle analisi è riportato in un documento chiamato Profilo di Sicurezza (PdS) che può essere Personalizzato (per sistemi critici) o Standard (per sistemi non critici). Il PdS contiene l’indicazione sintetica delle caratteristiche principali del sistema, la normativa applicabile e l’elenco dei requisiti che non risultano coperti con la relativa probabilità di accadimento. Oltre a queste informazioni, il PdS Personalizzato contiene la mappatura del sistema risultante dalla modellazione e i risultati della Gap Analysis.

c) ICT Risk Treatment

L’ICT Risk Treatment serve a identificare la tipologia e la tempistica delle soluzioni da adottare per ridurre il rischio del sistema e stabilire il grado di rischio residuo che è possibile tollerare.

Basandosi sull’output del sotto-processo precedente (il Profilo di Sicurezza), Technical Security distingue i requisiti ai quali è associato un rischio trascurabile da quelli per i quali è necessario definire delle misure di sicurezza integrative. La classificazione è effettuata in

56

funzione degli eventi che potrebbero provocare l’incidente di sicurezza e degli impatti di tale incidente.

Le misure di sicurezza integrative vengono selezionate a valle di un’analisi costi-benefici basata sulle stime ricevute da ADM nel sotto-processo di Demand Management. Successivamente, per le soluzioni selezionate e per i requisiti obbligatori per legge, Technical Security definisce una priorità di intervento mentre ADM produce un documento, chiamato Piano di Rientro, contenente la pianificazione delle attività, i dati identificativi del sistema e del PdS, i requisiti non coperti, e il costo stimato per ogni intervento pianificato. Per gli interventi esclusi dal piano, ADM si assume formalmente il rischio derivante dalla mancata implementazione della soluzione, mentre TS calcola il rischio residuo del sistema.

Infine, Technical Security si occupa di monitorare l’esecuzione degli interventi, richiedendo periodicamente alla funzione owner del sistema di riferire lo stato delle attività. In caso di eventuali ritardi, ne vengono analizzate le cause e si determina una pianificazione alternativa o una diversa modalità di trattamento del rischio, effettuando una nuova analisi costi-benefici. Al termine della realizzazione degli interventi, si raccolgono le evidenze delle azioni svolte, così da dichiarare conclusa l’azione.