Misure di Awareness, finalizzate a sensibilizzare i dipendenti e i fornitori di TI.IT all’importanza degli aspetti di sicurezza.

Tali misure sono state pianificate nel dettaglio nella successiva fase di definizione (cfr. § 3.2).

Dopo aver individuato gli obiettivi, è stata definita la struttura di governo del PSS. In primo luogo, è stato istituito lo Steering Committee, composto dai responsabili di secondo livello di Technical Security. Il dirigente di primo livello ha guidato il comitato in qualità di Project Sponsor, dovendo garantire il raggiungimento degli obiettivi del progetto nei confronti della direzione aziendale e di Audit. Lo Steering Committee si è occupato di assegnare i ruoli in base alle competenze presenti all’interno dell’unità, affidando un Project Manager a ogni cantiere e collocando un Program Manager a supervisione dell’intero Programma. Tali incarichi sono stati assegnati a figure che, avendo già ricoperto in passato il ruolo di responsabili delle attività di patching, hardening, gestione delle credenziali e sviluppo sicuro del codice, possedevano maggiore esperienza nell’ambito di questi processi.

Per prevenire possibili ostacoli alla comunicazione in fase di pianificazione, è stato formato un team di supporto che assolvesse ad alcuni compiti tipici di un Project Management Office, quali:

- Favorire il flusso di informazioni tra il Program Manager e i principali attori coinvolti nel PSS, con particolare riferimento ai quattro Project Manager;

- Facilitare la diffusione dei risultati raggiunti dai team di progetto elaborando una reportistica standardizzata e condivisa;

- Aiutare la pianificazione con l’adozione di strumenti e tecniche di Project Management; - Fornire un supporto al Program Manager in fase di monitoraggio degli avanzamenti per

la rapida individuazione delle criticità.

La struttura di governo del Programma si è affiancata alla struttura permanente di Telecom Italia IT presentata nel Capitolo 2. Già a partire dalla fase di concezione, è stato

71

indispensabile coinvolgere l’Operating Team, composto dalle funzioni incaricate dell’esecuzione operativa (Infrastructure, Application Development & Management) e da quelle di supporto alle azioni dei cantieri (Demand & Assurance Management e Operating Governance e Architecture). Queste hanno svolto le attività del PSS in parallelo a quelle tipiche della gestione ordinaria (cfr. Operating team di Figura 3.4).

In particolare, sono state definite le responsabilità delle funzioni Application

Development & Management (ADM) e Infrastructure (I), impegnate sui diversi cantieri in qualità di:

Figura 3.4 – Struttura di governo del Programma Strutturato di Sicurezza Operating Team

Application Development & Management, Infrastructure, Demand & Assurance Management, Operating Governance, Architecture

Project Manager CREDENZIALI TS - Demand & Risk Management Project Manager BSA TS - Security Lab Project Manager HARDENING TS - Security Operations Center Project Manager PATCHING TS - Security Operations Center Program Manager TS - Demand & Risk

Management

Steering Committee - Technical Security

72

- Ingegneria: area che progetta il sistema sulla base dei requisiti provenienti dalla funzione Demand, la quale si occupa di raccogliere i bisogni dei clienti per trasformarli in requisiti funzionali. Le specifiche della progettazione vengono poi inviate alla Software Factory;

- Software Factory: area che sviluppa e rilascia il codice delle applicazioni; - Control Room: area che controlla i server che ospitano le applicazioni;

- Gestione Applicativa: area che gestisce la fase di esercizio, monitorando il corretto funzionamento del sistema una volta che è stato attivato.

È stata quindi costruita la matrice RACI rappresentata nella Tabella 3.1, indicando ruoli di Responsible, Accountable, Consulted e Informed delle diverse aree all’interno dei quattro cantieri.

Inizialmente, il team di progetto si è occupato di definire il perimetro, cioè l’insieme di sistemi sui quali implementare le misure tecniche. In particolare, in questa fase è stato identificato un perimetro teorico, dal quale, nella successiva fase di definizione, sono stati esclusi i sistemi che non potevano essere oggetto di interventi a causa di vincoli di diversa natura.

RACI Patching Hardening

Gestione delle credenziali Sviluppo sicuro del codice Ingegneria (ADM) R R A I Software Factory (ADM) R C A I Control Room (I) A A A A Gestione Applicativa (ADM) I I I R

73

Il perimetro teorico è stato identificato prendendo in considerazione tutte le applicazioni sulle quali Telecom Italia IT ha responsabilità diretta nel sanare le non conformità riscontrate da Audit avendo almeno un ruolo in qualità di Ingegneria, Software Factory, Control Room e Gestione Applicativa. Alle applicazioni così individuate (circa 2.400) è stato poi associato un ordine di priorità, sulla base di due parametri:

- Rischio RID (Riservatezza, Integrità e Disponibilità dei dati trattati): valuta gli impatti di business derivanti dall’eventuale perdita delle caratteristiche di sicurezza del sistema sulle informazioni da esso trattate classificando le applicazioni in tre classi (C1, C2 e C3, con grado di rischio crescente);

- Criticità di Business: valuta, da un lato, l’importanza che un sistema riveste per il funzionamento dei processi aziendali da esso supportati e, dall’altro, la compliance dei dati trattati. Per classificare le applicazioni, è utilizzata una scala verbale che associa ai sistemi meno critici il valore “basso” e a quelli più critici il valore “mission critical”.

In questo modo, sono state identificate quattro zone (mostrate in Figura 3.5 12), ognuna caratterizzata da una priorità di intervento:

- Red Zone, composta dalle 482 applicazioni più critiche dal punto di vista della sicurezza;

- Yellow Zone, composta da applicazioni caratterizzate da elevata criticità di business; - Green Zone, composta da applicazioni con medio-bassa criticità di business;

- Black Zone, composta da applicazioni per le quali non è ancora stata identificata la criticità di business.

Il PSS ha l’obiettivo prioritario di intervenire sulle applicazioni maggiormente esposte a rischio, cioè quelle della Red Zone. Dopo aver trattato questi sistemi, sarà valutata la modalità sostenibile per estendere, anche parzialmente, le azioni dei cantieri alle restanti zone.

Infine, il team di progetto ha voluto formalizzare l’approccio da adottare nelle successive fasi di definizione e analisi. Questa esigenza si è manifestata per indicare una metodologia condivisa per rispondere alle eventuali criticità che si sarebbero potute manifestare in seguito all’avvio delle attività.

12

I numeri riportati sono il risultato della moltiplicazione per un coefficiente correttivo, applicato per garantire la riservatezza dei dati.

74

In un’ottica di miglioramento continuo, la scelta della metodologia è ricaduta sul ciclo PDCA (Plan Do Check Act) teorizzato da Deming (cfr. Figura 3.6). L’approccio prevede di seguire quattro step:

1. Pianificazione del programma (Plan), composta dalle seguenti attività (cfr. §3.2):