Verso il GOVERNO dei SISTEMI INFORMATIVI NORMATIVA, … · GOVERNO dei SISTEMI INFORMATIVI. 29.5.2014 - Padova - ISACA VENICE Chapter 2 TITOLO BREVE - N. COGNOME NORMATIVA, BEST PRACTICES

29.5.2014 - Padova - ISACA VENICE Chapter

1TITOLO BREVE - N. COGNOME

NORMATIVA, BESTPRACTICES EDAPPLICAZIONE

PRATICA

ROBERTO NICCOLI

Padova, 29 maggio 2014

Verso ilGOVERNOdei SISTEMI INFORMATIVI



NORMATIVA, BESTPRACTICES EDAPPLICAZIONE

PRATICA

IT affidabile per ilbusiness e

IS GOVERNANCEcome punti di arrivo

della conformità



Verso il GOVERNO dei SISTEMI INFORMATIVI

Sponsor esostenitori diISACA VENICEChapter

Con ilpatrocinio di



ROBERTO NICCOLI

QUALIFICHE PROFESSIONALI

Laurea in Economia e Commercio, Università L. Bocconi di Milano

STORIA PROFESSIONALE

Entrato in PwC nell’ottobre del 2000, ha svolto numerose attività in differenti settori ricoprendo rilevanti ruoli di

responsabilità nel gruppo “IT Governance & Data Management”.

ESPERIENZE PROGETTUALI

Ha gestito e realizzato molteplici progetti nelle seguenti aree tematiche:

Technology

• Supporto alla definizione dei processi operativi IT (Change Management, IT Security, Incident Managementecc);

• Supporto alla definizione di sistemi di monitoraggio e qualità IT (dashboard KPI e BSC);

• Supporto nella valutazione del sistema di controllo IT;

• ICT Compliance;

• Supporto alla ridefinizione organizzativa della funzione IT e/o del modello di IT Sourcing.

Data Management

• Implementazione di Dashboard di fraud management (specifiche funzionali, specifiche tecniche edimplementazione);

• Revenue Maximizer (Riconciliazioni End-To-End, Error Management) ed assistenza nella definizione dellafunzione Revenue Assurance;

• Analisi e ricalcoli di dati operativi non finanziari, CAAT, ecc.



ABSTRACT

L'intervento si concentrerà sull'esperienza maturata negli ultimi mesi da PwC nell'ambito del 15°

aggiornamento della Circolare 263 (Nuove disposizioni di vigilanza prudenziale per le banche) e, nello

specifico, del Capitolo 8 Sistemi Informativi.

Da un'esigenza di conformità ad una norma, sono stati avviati una serie di interventi prima di valutazione e

successivamente di implementazione/revisione di processi di gestione dei Sistemi Informativi che porteranno

gli operatori del settore a dotarsi di nuovi presidi organizzativi e nuove metodologie in ambito IT Governance

entro il 1° febbraio 2015.

Gli operatori nei prossimi mesi avranno il compito di implementare soluzioni che siano da un lato coerenti

con i propri modelli di sourcing e di business (organizzazione, persone e tecnologie) e dall'altro con quanto

richiesto da Banca d'Italia. Stiamo vivendo un momento di profondo cambiamento in cui quanto definito da

best practices e framework di settore (COBIT, ISO27000, ITIL) sta diventando ora un’esigenza di business e

di compliance.



Agenda

• Breve introduzione 263: principi generali

• Circolare 263 e metodologie di riferimento

(COBIT, ISO27000)

• Assessment 263

• Il piano di implementazione 263



Sezione 1

BREVE INTRODUZIONE 263: PRINCIPI GENERALI

• Struttura

• Il capitolo 8 e la sua articolazione

Le scadenze normative

Le principali novità


8TITOLO BREVE - N. COGNOMEPwC

Sezione 1 – Breve introduzione 263: principi generali

L’evoluzione della normativa verso un migliore presidio del rischio

• Banca d’Italia ha recentemente avviato una profonda revisione del

quadro normativo volta a condurre il sistema bancario verso un

migliore presidio del rischio a tutti i livelli aziendali e più in

generale a migliorare l’intera governance

• Le nuove disposizioni prendono le mosse dalla circolare 229/1999

“Istruzioni di Vigilanza per le Banche”, sostanzialmente “principle

based”, declinando ed approfondendo taluni aspetti in una

“normativa basata sulle regole” (Principi vs Regole)

• Banca d’Italia ha inteso modificare ed integrare l’attuale normativa

di riferimento con la finalità ultima di istituire una governance

aziendale volta a garantire una sana e prudente gestione ed il cui

punto fulcro è rappresentato dalla comprensione, il governo del

rischio e la sua remunerazione

• I principi cardine della nuova normativa sono stati condivisi anche

dal Fondo Monetario Internazionale, con il quale la Banca

d’Italia si è confrontata prima della sua emanazione in occasione

del FSAP

L’Autorità di Vigilanza ha emanato lo scorso 2 luglio il 15°

aggiornamento alla Circolare 263/2006, recante disposizioni

prudenziali in materia di sistema dei controlli interni, sistema

informativo e continuità operativa (di seguito, “testo normativo” o

“aggiornamento”), i cui principali ambiti sono di seguito elencati:

• Il sistema dei controlli interni (Cap. 7)

• Il ruolo degli Organi aziendali (Cap.7, Sez. II)

• Funzioni aziendali di controllo (Cap. 7, Sez. III)

• Esternalizzazione di funzioni aziendali al di fuori del gruppo

bancario (Cap. 7, Sez. IV)

• Il RAF, il sistema dei controlli interni e l’esternalizzazione nei

gruppi bancari (Cap. 7, Sez. V)

• Il sistema informativo (Cap. 8)

• La continuità operativa (Cap. 9)

• In particolare, nelle Nuove Disposizioni è richiesto che gli intermediari debbano, entro il 30 gennaio 2014 (termine prorogato):

inviare all’Autorità di Vigilanza una “relazione recante un’autovalutazione della propria situazione aziendale rispetto alle previsioni

della nuova normativa” (cd “gap analysis”)

indicare in tale relazione le “misure da adottare e la relativa scansione temporale per assicurare il pieno rispetto” delle disposizioni

(cd “piano interventi Bankit”) e l’elenco dei contratti di esternalizzazione in essere

per il Capitolo 8 e 9, è stata fornito un questionario specifico da utilizzare per la risposta a Banca d'Italia

Il contesto di riferimentoLe nuove disposizioni




Principali novità

Istituzione e requisiti dellefunzioni aziendali dicontrollo

I principi generali di Organizzazione

Il Risk Appetite Framework - RAF

Il codice etico

Il processo di approvazione di nuoviprodotti e servizi, l’avvio di nuoveattività, l’inserimento in nuovi mercati

Il coordinamento dellefunzioni/Organi di controllo

Il rafforzamento dei poteri delRisk Management

La compliance fiscale

La previsione di una disciplinaOrganica in materia dioutsourcing

Principalinovità

normative

Il rischio informatico edil governodell’Information eCommunicationTechnology (ICT)




Principi cardine

1. Proporzionalità e

autonomia

Organizzativa

2. Crescente ruolo

degli Organi divertice

3. Cultura deicontrolli

che coinvolge tutta

l’Organizzazione

aziendale

4. Visione integrata

dei rischi

5. Efficienza,

Efficacia,

costi e

coordinamento

6. Gestione econtrollo

dell’outsourcing

I principi cardinedella normativa

Le banche applicano le disposizioni secondo ilprincipio di proporzionalità, tenendo conto delladimensione e complessità operative, della naturadell’attività svolta, della tipologia dei serviziprestati.

La responsabilità primaria è rimessaagli Organi di governance, ciascunosecondo le rispettive competenze.L’articolazione dei compiti e delleresponsabilità degli Organi e dellefunzioni aziendali deve esserechiaramente definita.

Il sistema dei controlli interni ha rilievostrategico; la cultura del controllo deveavere una posizione di rilievo nella scaladei valori aziendali: non riguarda solo lefunzioni aziendali di controllo, macoinvolge tutta l’Organizzazioneaziendale e presuppone un fortecoinvolgimento ed impegno da parte deivertici.

Sono considerati parametri di integrazione: la diffusione di unlinguaggio comune nella gestione dei rischi a tutti i livelli dellabanca; l’adozione di modelli e strumenti di rilevazione evalutazione tra di loro coerenti; la definizione di modelli direportistica dei rischi; l’individuazione di momenti formalizzatidi coordinamento ai fini della pianificazione delle rispettiveattività.

Le banche assicurano una strettacoerenza e un puntuale raccordo tra: ilmodello di business, il pianostrategico, il RAF, il processo ICAAP, ibudget, l’Organizzazione aziendale e ilsistema dei controlli interniattraverso un’integrazione delle fontiinformative al fine di ottimizzare i costidel controllo.

Definizione di un processo diesternalizzazione basato su un’analisidel rischio, che considera in primoluogo la stima dei rischi delle risorse eservizi da esternalizzare e quindivaluta i rischi dei possibili fornitori.




• Le nuove disposizioni delineano un quadro di cambiamento che impatta su più attori e richiede l’attivazione di un programma Organico e

trasversale

• Di particolare rilievo il ruolo attivo riconosciuto agli Organi aziendali nel processo decisionale di assunzione e di monitoraggio dei rischi (es.

definizione Risk Appetite Framework), il consolidamento della funzione di Controllo dei Rischi e l’estensione delle responsabilità della

funzione Compliance

• L’Autorità di Vigilanza, in un’ottica di ridefinizione e rafforzamento dei modelli governance degli intermediari, ha posto grande enfasi sulle

regole specifiche in materia di Organizzazione e governo dell’ICT

• I destinatari della disciplina devono adeguarsi in modo graduale alle nuove disposizioni sulla base del seguente piano:

30-01-’14 01-07-’14 01-07-’15 01-07-’1601-02-’15

• Gap Analysis per

Banca d’Italia

• Mappatura contratti di

esternalizzazione in

essere

• Entrata in vigore di

una prima parte delle

disposizioni

• Entrata in vigore delle

disposizioni in materia

di sistema informativo


disposizioni relative

alle linee di riporto dei

responsabili delle

funzioni di controllo di

II livello


disposizioni in materia

di esternalizzazione

La “timeline” normativa



Capitolo 8 - La governance ICTIl nuovo quadro d’insieme ICT in coerenza con la governance aziendale (1/2)


L’Organo con funzione di supervisione strategica assume la generale responsabilità di indirizzo e controllo del sistema informativo a

sostegno delle strategie aziendali. In particolare:

• approva le strategie di sviluppo del sistema informativo e relativo modello di riferimento per l’architettura

• approva le policy di sicurezza informatica

• promuove lo sviluppo, la condivisione e l’aggiornamento di conoscenze in materia di ICT all’interno dell’azienda

• è informato tempestivamente in caso di gravi incidenti e con cadenza almeno annuale circa l’adeguatezza dei servizi erogati

• approva il framework metodologico per l’analisi del rischio informatico

• approva la propensione al rischio informatico in coerenza con la propensione al rischio definito a livello aziendale

• è informato con cadenza almeno annuale sulla situazione di rischio informatico rispetto alla propensione al rischio

L’Organo con funzioni di gestione ha il compito di assicurare la completezza, l’adeguatezza, la funzionalità e l’affidabilità del sistema

informativo. In particolare:

• definisce la struttura Organizzativa della funzione ICT assicurandone la rispondenza alle strategie e ai modelli architetturali definiti

• definisce l’assetto Organizzativo, metodologico e procedurale per il processo di analisi del rischio informatico raccordandosi con la

funzione di risk management

• approva gli standard di Data Governance ed il piano operativo delle iniziative informatiche

• valuta almeno annualmente le prestazioni della funzione ICT rispetto alle strategie ed agli obiettivi fisssati utilizzando opportuni sistemi di

misurazione (KPI)

• approva almeno annualmente la valutazione del rischio delle componenti critiche

Principali aspetti normativi




• monitora il regolare svolgimento dei processi di gestione e di controllo dei servizi ICT e, a fronte di anomalie rilevate, pone in atto

opportune azioni correttive;

• assume decisioni tempestive in merito a gravi incidenti di sicurezza informatica

La funzione ICT si caratterizza per linee di riporto dirette a livello dell’organo con funzione di gestione garantendo l’unitarietà della visione

gestionale e del rischio informatico nonché dell’uniformità di applicazione delle norme riguardanti il sistema informativo. In particolare, ha la

responsabilità:

• della pianificazione e del controllo del portafoglio dei progetti informatici in coerenza con il governo dell’evoluzione dell’architettura e

dell’innovazione tecnologica nonché con le attività di gestione del sistema informativo

• della realizzazione degli opportuni meccanismi di raccordo con le linee di business

Le responsabilità in merito allo svolgimento dei compiti di controllo di secondo livello sono chiaramente assegnati. In particolare:

• il controllo dei rischi, basato su flussi informativi continui in merito all’evoluzione del rischio informatico e sul monitoraggio dell’efficacia

delle misure di protezione delle risorse ICT. Le valutazioni svolte sono documentate e riviste in rapporto ai risultati del monitoraggio e

comunque almeno una volta l’anno.

• il rispetto dei regolamenti interni e delle normative esterne in tema di ICT garantendo, tra l’altro:

l’assistenza su aspetti tecnici in caso di questioni legali relative al trattamento dei dati personali

la coerenza degli assetti Organizzativi alle normative esterne, per le parti relative al sistema informativo

l’analisi di conformità dei contratti di outsourcing e con fornitori (inclusi i contratti infra-gruppo)

La funzione di revisione interna è in grado di fornire valutazioni sui principali rischi tecnologici identificabili e sulla complessiva gestione del

rischio informatico dell’intermediario mediante il ricorso a competenze specialistiche (interno o mediante il ricorso a risorse esterne)

Principali aspetti normativi

Capitolo 8 - La governance ICTIl nuovo quadro d’insieme ICT in coerenza con la governance aziendale (2/2)




• La gestione del rischio informatico è ad oggi limitato allo

specifico contesto ICT e spesso con approcci parcellizzati,

metodologicamente differenziati a seconda dello specifico

ambito:

i processi di definizione dei piani di Continuità

Operativa;

i processi di analisi del rischio di sicurezza;

i processi di analisi del rischio ai fini Privacy.

• Gli approcci adottati non prevedono (o solo limitatamente)un’integrazione con le funzioni di controllo ed unaconnessione con la tassonomia dei rischi da queste utilizzate

Situazione attuale

• Il rischio informativo diventa parte integrante del rischio

aziendale complessivo e deve trovare una idonea

integrazione con i rischi operativi, strategici e

reputazionali

• L’outsourcer recepisce dalla capogruppo/ banca utente un

approccio metodologico ove siano descritti i principi sui quali

deve poggiare la periodica valutazione e gestione del rischio

informatico, definendo inoltre un impianto metodologico e

flussi informativi che devono trovare un’idonea integrazione

rispetto a quanto previsto dalla capogruppo (Capitolo 7, RAF)

• Occorre definire un processo di gestione che permetta

periodicamente e/o in caso di modifiche significative di

valutare il rischio informatico su tutte le componenti critiche

del sistema informativo e ne condivide con la capogruppo gli

aspetti che possono impattare su di esse. A tal fine, il

Consorzio di riferimento dovrà attivare tempestivamente

adeguati flussi informativi in tale ambito

Modello a tendere

• Realizzazione di una visione integrata del rischio tra le funzioni di controllo e le strutture specialistiche che permetta di presidiare il rischio

informatico sia nella gestione dei processi IT sia come una delle componenti del RAF. L'integrazione deve avvenire in modo strutturato lungo tutti

i principali processi IT mediante l'adozione di presidi organizzativi, processi e soluzione tecnologiche che possano permettere di monitorare l'intero

perimetro delle componenti ICT e distinguerne l'impatto/ criticità per il business. L'analisi del rischio informatico diventa uno dei driver principali su

cui basare l'evoluzione del proprio sistema informativo di riferimento.

Spunto PwC

Capitolo 8 – Il rischio informaticoTendenze evolutive




• La gestione della sicurezza informatica è prevalentementevista come sicurezza fisica e logica, senza darne uninquadramento unico

• I processi di gestione dei cambiamenti sono spesso pocoformalizzati e si basano su prassi che non permettono diassicurare che aspetti rilevanti per il sistema di controllo(valutazione del rischio in caso di modifiche, accettazioneformale delle modifiche, definizione di specifici flussi incaso di emergenza, ecc) siano recepiti e gestiti in base aflussi strutturati e consistenti sulla base della tipologia dimodifica

• La gestione degli incidenti è gestita all’interno dei processidi Service Desk (di primo, secondo e terzo livello) maspesso non è garantita l’attivazione dei necessari flussiinformativi verso soggetti interni

Situazione attuale

• La definizione di policy di sicurezza, procedure e documentidi maggiore dettaglio operativi devono permettere diattuare modelli tecnico-organizzativi capaci di garantirela protezione degli asset aziendali ed assicurareun’evoluzione nel tempo in coerenza con i prodottiforniti, le tecnologie utilizzati e i rischi fronteggiati

• Nel caso di modelli di sourcing misti occorre implementareun modello operativo che permetta di assicurare comunqueuna visione unitaria ed integrata mediante standard diriferimento condivisi

• L’outsourcer deve definire i processi per la gestione degliincidenti di sicurezza integrati anche con i processi digestione della Continuità Operativa della banca,attivando, nel caso, le previste comunicazioni alle forzedell’ordine e/o a Banca d’Italia

Modello a tendere

• La gestione della sicurezza abbraccia orizzonti sempre più vasti in cui i sistemi di gestione della sicurezza delle informazioni diventanoprocessi di gestione complessi ed articolati, dove la corretta definizione delle regole di sicurezza è raggiunta solo attraverso una valutazione(da parte delle strutture di business) del grado di importanza delle informazioni trattate, anche alla luce dalle risultanze del processo dianalisi dei rischi

Spunto PwC

Capitolo 8 – La gestione della sicurezzaTendenze evolutive




• La mancanza di idonei presidi organizzativi (come adesempio, uffici architetture) non ha permesso di sviluppare,parallelamente alla messa in produzione di procedure edapplicazioni informatiche, un sistema capace di definire,formalizzare e mantenere nel tempo una completatracciatura dei flussi informativi in termini di procedure diestrazione, trasformazione e controllo dei dati

• Tali approcci sono stati introdotti spesso con Basilea II e IIIe l’introduzione dei processi di Data Quality ad essi sottesi

Situazione attuale

• La registrazione nei sistemi informativi delle principalioperazioni aziendali e dei fatti di gestione deve avvenireassicurando nel continuo l'integrità, completezza ecorrettezza dei dati e delle informazioni. Occorre inoltreprevedere processi di tracciamento e controllo in caso diimmissione o rettifica manuale di dati

• Occorre definizione uno standard di Data Governance chepermetta di definire un modello di riferimento (processi,strutture e tecnologie) atto a definire la proprietà del dato ea misurare la qualità del dato

• All’interno dell’analisi del rischio informatico, deve esseredefinito uno specifico ambito legato alla qualità del dato

• La formalizzazione dei data model per i sistemiinformativi (es.: DWH), compresi i processi di caricamentoed elaborazione, i processi di quadratura dei dati e tutte leattività di estrazione e reporting dei dati, diventano unrequisito per migliorare la qualità del reporting aziendale

Modello a tendere

• L’accountabilty (data classification) e la verificabilità del dato (definizione e formalizzazione di modelli dati) lungo tutto il suo ciclo di vitapermette di implementare sistemi di gestione capaci di fornire informazioni complete ed aggiornate sulle attività aziendali rilevanti esull’evoluzione dei rischi ad esse connesse

Spunto PwC

Capitolo 8 – Il sistema di gestione dei datiTendenze evolutive




• L’esternalizzazione segue prevalentemente logiche diefficienza economica ed operativa, il cui processo nonsempre è supportato da adeguati percorsi decisionali e dicontrollo

Situazione attuale

• L’esternalizzazione delle funzioni aziendali dovrà seguireun percorso più “rigido”, obbligando le capogruppo adefinire una politica aziendale in tema che sancisca ilprocesso decisionale seguito dalle banche/entità delgruppo per esternalizzare le funzioni aziendali, i criteriper individuare i fornitori, gli SLA ed i flussi informativi

• Si vuole in questo modo “guidare” e “tracciare”maggiormente il percorso di esternalizzazione,inducendo a valutare nel merito il processo decisionale, ela scelta dei fornitori (competenze e capacità). Inoltre, siirrobustisce il “controllo” delle attività svolte dalfornitore, tramite il rispetto formale di SLA e l’obbligo diproduzione di appositi flussi informativi indirizzati agliOrgani aziendali per consentire la piena coscienza egovernabilità dei fattori di rischio delle attività esternalizzate

• Requisiti meno stringenti sono previsti nel caso diesternalizzazioni all’interno del medesimo Gruppo Bancario

Modello a tendere

• Definizione del nuovo processo di esternalizzazione e delle attività di controllo, da realizzarsi in ottica condivisa ed integrata a livelloaziendale (coinvolgimento delle funzioni interessate, funzioni di controllo, alta direzione) come primo passo del presidio a livellocomplessivo

Spunto PwC

Capitolo 7 – Nuove logiche di esternalizzazioneTendenze evolutive




• L’esternalizzazione segue prevalentemente logiche diefficienza economica ed operativa, il cui processo nonsempre è supportato da adeguati percorsi decisionali e dicontrollo

Situazione attuale

• L’esternalizzazione delle componenti critiche dei sistemiinformativi dovrà seguire un percorso più “rigido”,obbligando le capogruppo/ banche utenti a definire unquadro di riferimento idoneo a garantire l’indirizzo ed ilcontrollo del sistema informativo e la supervisionedell’analisi del rischio informatico mediante idoneestrutture organizzative, metodologie e processi digestione dell’ICT

• Si vuole in questo modo “governare” ed “indirizzare”maggiormente il percorso di esternalizzazione, sia in fasedi definizione del modello di sourcinng sia nel corso deltempo nell’erogazione dei servizi. Si irrobustisce dunqueil “controllo” delle attività svolte dall’outsourcer, anchetramite la definizione e il monitoraggio di SLA coerenti conle esigenze di business ed attivando appositi flussiinformativi indirizzati agli organi aziendali di supervisionestrategica e di gestione

Modello a tendere

• Definizione di flussi informativi che possano permettere di offrire agli organi di supervisione strategica e di gestione un corretto e tempestivoquadro di riferimento, misurando anche la contribuzione della funzione ICT al raggiungimento degli obiettivi strategici aziendali

• Definizione di un sistema di controllo ICT integrato con il più ampio sistema di controllo aziendale anche a causa della pervasività che isistemi informativi hanno sui processi aziendali

Spunto PwC

Capitolo 8 – Le logiche di esternalizzazione in ambito ICTTendenze evolutive




• Sono implementati processi che garantiscono la definizionee la gestione dei piani di continuità operativa,eventualmente, in modo accentrato per gruppi bancari (intal caso, dotando le controllate di piani di continuitàoperativa e verificando la coerenza degli stessi con gliobiettivi strategici del gruppo in tema di contenimento deirischi)

• Il CdA ha la responsabilità di stabilire obiettivi e strategiedi continuità operativa; a tal fine, attribuisce risorseadeguate ad assicurarne il conseguimento, approva ilpiano di continuità e nomina un responsabile del piano,comunicandone il nominativo a Banca d’Italia. Inoltre, ilCdA è informato, con frequenza almeno annuale, sugliesiti dei controlli sull’adeguatezza del piano e sulleulteriori verifiche

• La procedura per la dichiarazione dello stato di crisi èdefinita in raccordo con il processo di gestione degliincidenti

Situazione attuale

• Occorre completare l’implementazione di quanto giàdefinito dai precedenti Bollettini di Vigilanza in ambitoContinuità Operativa

Modello a tendere

• I processi di gestione degli incidenti e di escalation devono essere integrati tra le differenti entità che, a vario titolo, concorrono allacontinuità operativa del gruppo bancario

• La definizione di componente critica ai fini della continuità operativa deve trovare un allineamento logico anche con quanto definito dalCapitolo 8

Spunto PwC

Capitolo 9 – La continuità operativaTendenze evolutive



Sezione 2

CIRCOLARE 263 E METODOLOGIE DIRIFERIMENTO (ISO27000, COBIT)



Sezione 2 – Circolare 263 e metodologie di riferimento (COBIT, ISO27000)

La normativa nelle considerazioni generali sulla gestione del Sistema Informativo fa un chiaroriferimento all'utilizzo di standard e best practices di settore.

In tal senso, gli standard che sono stati presi in considerazione come riferimento sono:

l'ISO 27001-2:2013 che copre in maniera esaustiva tutti gli ambiti introdotti dalla 263 in ambitosistema di gestione della sicurezza delle informazioni e del rischio informatico

il CobiT 5 (o il CobiT 4.1), utilizzato come framework di riferimento dall'ufficio Audit per il sistemadi controllo interno IT.

Sono inoltre utilizzati altri standard/ framework come ITIL (erogazione dei servizi), ISF Standard ofGood Practices (sicurezza), DAMA Framework (data governance) ad integrazione di approccimetodologici già adottati o per definire aspetti prevalentemente operativi.

A tal proposito le banche valutano l’opportunità di avvalersi degli standard e bestpractices definiti a livello internazionale in materia di governo, gestione, sicurezzae controllo del sistema informativo.

[rif. TITOLO V - Capitolo 8, Sezione I – Disposizioni di carattere generale]

Gli standard di riferimento




Lo standard di riferimento per la sicurezza delle informazioniSeries ISO2700x




• Il 25 Settembre 2013 è stato pubblicato il nuovo Standard ISO 27001-2:2013, che contiene i requisitiper implementare, gestire e certificare un Information Security Management System (ISMS).

• Lo Standard ISO 27001-2:2013 si applica a tutte le organizzazioni (aziende, PubblicaAmministrazione, Onlus) di ogni dimensione e settore.

• Lo Standard ISO 27001-2:2013 prende in considerazione tutti gli aspetti della sicurezza delleinformazioni:

organizzazione;

persone;

luoghi fisici;

documenti cartacei;

sistemi IT.

• L'assessment sulla sicurezza IT è stato condotto partendo dalla rilevazione dei processi di sicurezzaad oggi definiti sulla base dello standard ISO27001-2:2013.

Lo standard di riferimento per la sicurezza delle informazioniISO 27001-2:2013




• Il COBIT5 consolida in una medesima entità di tre differenti framework: Cobit (216 ControlObjectives), e RiskIT (69 Management Practice) e ValIT (43 Management Practice). Tale processodi consolidamento ha permesso al Cobit di diventare uno strumento di governance a 360° ovverouno strumento con cui definire ed implementare i processi di gestione delle funzioni SistemiInformativi.

• I quattro domini del Cobit 4.1 sono diventati cinque e i processi in essi contenuti sono statiridistribuiti riuscendo a:

recepire in maniera ottimale nell’impianto metodologico i principi di segregation of duties(definire, implementare e monitorare);

distinguere puntualmente i processi di governance da quelli relativi al management.

• Il primo dominio Evaluate, Direct and Monitor (EDM) si concentra sulla definizione di modelli digestione che possano garantire un allineamento costante e duraturo con gli obiettivi di business,ottimizzando rischi, risorse e capability tipiche di una struttura IT.

• Il secondo dominio Align, Plan and Organise (APO) conferma i principali obiettivi di controllo delCobit 4.1 introducendo in questa nuova versione nuovi processi tipici delle attività di pianificazioneed organizzazione quali ad esempio la gestione dei fornitori (APO10), la gestione dei Service LevelAgreements (APO09), la definizione di un framework di gestione IT (APO01). Elemento ulteriore dinovità è rappresentato dall’introduzione in tale dominio dei processi di governo della Sicurezza ITche vengono separati dai relativi processi operativi ed inclusi in un processo ad hoc (APO13).

Lo standard di riferimento per il sistema di controllo internoCOBIT5




• Anche il terzo dominio Build, Acquire and Implement (BAI) si arricchisce in termini di processitipici delle attività di acquisizione, implementazione e mantenimento delle componenti di un sistemainformativo, intese non solo come programmi ed applicazioni ma anche come gestione degli asset edel relativo ciclo di vita (BAI09 e BAI10).

• Il quarto dominio Deliver Serve and Support (DSS) si concentra esclusivamente sui processi digestione della macchina IT quali la gestione delle operations, dei processi di service desk, dicontinuità e di gestione operativa della sicurezza. In tale dominio, è stato introdotto un nuovoprocesso (DSS06) che si focalizza, tra l’altro, sui controlli applicativi che assicurano che dati edinformazioni siano processati in modo coerente ai requisiti di business e che sia assicurata neltempo la loro completezza, accuratezza, validità ed un accesso ristretto. Tale tipologia di controlligià presente nel Cobit4.1 ma solo nella parte introduttiva, diventa oggi una componente di dettagliodel modello.

• In ultimo, il dominio Monitor, Evaluate and Assess (MEA) si focalizza sui processi di monitoraggiodelle performance e delle conformità con riferimento al sistema di controllo interno e ai requisitiimposti dalla normativa vigente.









• Per ciascuno dei 37 processi del Cobit 5,viene fornito nel documento Enabling Process una sezionespecifica in cui viene dettagliato:

la descrizione del processo;

gli obiettivi del processo che vengono suddivisi ulteriormente in IT-related Goals e in BusinessGoals;

la matrice dei ruoli e responsabilità (RACI) con tutti gli attori coinvolti IT e di business;

le Governance o Management Practice in termini di:

attività tipiche del processo (sono l’equivalente delle COBIT 4.1 control practice e Val ITe Risk IT management practice),

input ed output;

i riferimenti puntuali ad altri standard e best practices IT.




Sezione 3

ASSESSMENT 263

• Le modalità di svolgimento sulla base dell'esperienza PwC

• Il reporting verso Banca d'Italia



Sezione 3 – Assessment 263

Le analisi si sono focalizzate in questa fase progettuale sui Capitoli 8 (Sistemi Informativi) e 9(Continuità Operativa). A ciascun requisito normativo, allineato a quanto definito anche da AbiLab,sono stati associati uno o più processi CobiT 4.1 al fine di fornire un’interpretazione chiara ed univocadelle tematiche in oggetto e renderle comparabili con uno standard di riferimento.Sugli ambiti specifici relativi alla gestione della Sicurezza dei Sistemi (DS5), le analisi sarannoeffettuate anche sulla base dell’ISO2700x.

A ciascun requisito normativo, è stato inoltre attribuito un referente (Banca, outsourcer di riferimentoo entrambi) con un’indicazione della struttura di riferimento e del referente con cui sono state svolte adoggi le analisi.

Sulla base delle analisi effettuate, il gruppo di lavoro sta procedendo con la formalizzazione delleattività e dei processi di controllo rilevati (assessment), con la contestuale definizione di gap didettaglio sui singoli requisiti identificati e con anche una valutazione della copertura deglispecifici requisiti.

Il processo di assessment condotto da PwC in ambito Circolare 263




La presente sezione ha lo scopo di fornire una valutazione di sintesi circa la conformità rispetto airequisiti normativi dei Capitoli 8 e 9, individuando su specifici ambiti operativi (processi di controlloCOBIT4.1) un livello di maturità riscontrato.

La valutazione avviene quindi sulla base del requisito normativo ed è espressa su una valutazione acinque livelli così definita:

0 Non esistente

1 Prassi non consolidata

2 Prassi consolidata

3 Formalizzato

4 Ottimizzato

Nel corso del mese di dicembre è stato circolarizzato un questionario da parte di Banca d'Italiaspecifico per la risposta sul Capitolo 8 e 9 che è stato utilizzato dalle banche per rispondere allaGap Analysis. Generalmente, è stata quindi redatta una relazione che conteneva un giudizio disintesi e le valutazioni relative al Capitolo 7 a cui è stato allegato il questionario di banca d'Italia.

La relazione conteneva in allegato o faceva riferimento anche a tutti gli strumenti /carte dilavoro utilizzate per le valutazioni di dettaglio.

Una valutazione articolata su più livelli




• Il documento qui sotto riportato a titolo esemplificativo rappresenta lo strumento di lavoro per laformalizzazione puntuale di tutte le analisi condotte a livello di singolo requisito. Tale documentorappresenterà l’input per la formalizzazione dei documenti di Gap Analysis e Master Plan.

Rif. Disposizioni diVigilanza BdI

ID RequisitoAssessmentOutsouercer

AssessmentBanca

Gap rilevato inBanca

Descrizione delrequisito

QuesitoGap rilevatoOutsouercer

Struttura mappatura di dettaglio




IV – Par.3) La sicurezza delle informazioni e delle risorse ICT

Ambito(Rif. COBIT)

Requisito normativo di dettaglio Osservazioni Valutazione

Garanzia dellasicurezza dei

sistemi(DS5)

La sicurezza delle informazioni e dellerisorse informatiche è garantita attraverso:• la regolamentazione dell'accesso logico a

reti, sistemi, basi di dati sulla base delleeffettive esigenze operative;

• la procedura di autenticazione perl'accesso alle applicazioni e ai sistemi, inparticolare sono garantiti l'univocaassociazione a ciascun utente delle propriecredenziali di accesso;

• la segmentazione della rete ditelecomunicazione, con controllo dei flussiscambiati, in particolare tra dominiconnotati da diversi livelli di sicurezza;

• l'accesso a sistemi e servizi critici tramitecanali pubblici (ad es., nel caso dell'e-banking tramite internet) sono presidiati inmodo da soddisfare rigorosi requisiti disicurezza.

2Prassi

Consolidata

Una valutazione di sintesi




Questionario di gapanalysis Capitolo 8 e 9

Esternalizzazione dellecomponenti ICT rilevanti

La comunicazione a Banca d'Italia



Sezione 4

IL PIANO DI IMPLEMENTAZIONE 263

• Master Plan

• Piano operativo

• L'implementazione: modalità di svolgimento



Sezione 4 – Il piano di implementazione 263

Sulla base delle valutazioni condotte rispetto ai requisiti del 15° aggiornamento (Gap Analysis) è statoavviato un processo che ha portato alla definizione di tre distinte fasi

Fase 1

Master Plan

Fase 2

Piano operativo

Fase 3

Attività di progetto

(1) Formalizzare leprincipali azioni di

remediation da attivare

(2) Attività propedeuticaper l'attivazione dei

singoli Cantieri

(3) Attività operative diprogetto dei singoli

cantieri

Piano di alto livelloformalizzato per l'organo disupervisione strategico e di

gestione al fine dirappresentare gli impatti del

15° aggiornamentoPiano di dettaglio

formalizzato per le struttureoperative al fine di definire

gli specifici ambitiprogettuali, i task, i ruoli e le

responsabilità e letempistiche

Svolgimento delle attività cheporteranno a colmare i gap identificati

mediante la definizione di presidiorganizzativi, processi, supporti

tecnologi e la formalizzazione di tutta ladocumentazione a supporto

Il piano di implementazione




La valutazione rispetto ai requisiti del 15° aggiornamento (Gap Analysis) è stato seguito da una serie di analisiche hanno portato alla definizione di master plan di dettaglio che hanno cercato di definire tutte le azioninecessarie a colmare i gap individuati in termini di:

• attività di dettaglio;

• tempistiche di realizzazione;

• prima stima delle giornate/uomo (con la spaccatura tra risorse interne e risorse consulenziali);

• prima stima degli investimenti.

Le analisi hanno portato alla formalizzazione di una serie di documentazione che è stata utilizzata per laformalizzazione del questionario di Banca d'Italia e per verificare la sostenibilità delle azioni dichiarate.

Il piano di attività si sviluppa mediante l'integrazione dei Master Plan che la Banca/ gli outsourcer di riferimentohanno definito sui capitoli 8 e 9. Le azioni si sviluppano su una roadmap che prevede tre orizzonti temporali:

entro i 6 mesi (luglio 2014), interventi che riguardano la valutazione preliminare utile alla definizione deimodelli operativi TO BE dei processi della Banca/ degli outsourcer di riferimento ed interventi afferenti anon conformità rispetto a normative già in essere (o che prevedono scadenze di attuazione già definite);

da 6 mesi a 14 mesi (febbraio 2015), formalizzazione dei modelli operativi;

oltre i 14 mesi, finalizzazione dei modelli e del sistema di controllo della Banca/ degli outsourcer diriferimento.

Le principali azioni sono referenziate con best practices di riferimento e/o framework metodologici di ITGovernance al fine di permettere una piena condivisione dei principi e delle linee guida sottostanti alle azioniidentificate.

Il Master Plan




Un esempio Master Plan per un outsourcer relativo al Capitolo 8

- ESEMPLIFICATIVO -




Nelle pagine seguenti, sono riportate le iniziative identificate nel master Plan (ID e titolo) in ordinesequenziale per ambito omogeneo, identificando sei "cantieri":

[ID 1] – Processo di gestione dei flussi informativi di supporto alle banche

[ID 2] – Gestione dell'impianto normativo della Banca/ degli outsourcer di riferimento

[ID 3] – Completamento assessment "Recommendations for the security of internet payments"

[ID 4] – Integrazione del processo di security incident management

[ID 5] – Implementazione "Recommendations for the security of internet payments"

[ID 6] – Definizione metodologia di analisi del rischio informatico

[ID 7] – Analisi del rischio informatico

[ID 8] – Fine tuning analisi del rischio informatico ed integrazione della metodologia con le procedureaziendali

Organizzazione e processi

Sicurezza IT

Rischio informatico

Un esempio Master Plan per un outsourcerIl Master Plan per ambito (1/2)

- ESEMPLIFICATIVO -




[ID 9] – Revisione ed integrazione modellogestione dei cambiamenti

[ID 10] – Completamento progetto tracciatura dati bancari

[ID 11] – Assessment del modello di gestione dei dati

[ID 12] – Fine tuning operativo del modello di gestione dati

[ID 13] – Revisione ed integrazione del corpo normativo sulla base dei modelli operativi inambito data governance

[ID 14] – Allineamento del processo di ICT Audit

[ID 15] – Definizione policy di esternalizzazione e adeguamento contratti fornitori

[ID 16] – Completamento del processo di adeguamento contratti di esternalizzazione clienti

Gestione dei cambiamenti

Sistema di gestione dei dati

Altri cantieri IT Governance

Un esempio Master Plan per un outsourcerIl Master Plan per ambito (2/2)

- ESEMPLIFICATIVO -




Occorre non solo definire leattività operativi ma anchefornire una pianificazione di

dettaglio del rilascio deidifferenti deliverable di progettoal fine di (1) permettere che ilcorpo normativo della banca edegli outsourcer di riferimentopossano essere allineati edintegrati (mediante ancheattività di fine tuning) e (2)siano intrapresi nei tempi

stabiliti dal 15° aggiornamentol'avvio di tutti i processi

autorizzativi e di emanazionedelle norme (policy, procedure,

ecc)

Allegato A e una sintesi dei deliverable per cantiere progettuale

- ESEMPLIFICATIVO -




Le attività diimplementazione della

banca devono verificarel'integrazione tra il proprio

modello operativo e quello inessere presso l'/ gli

outsourcer di riferimento,attuando un processo di

costante allineamento tra idiversi cantieri progettuali.

Per la complessità degliinterventi di remediation, leattività di implementazionedell'eventuale outsourcer di

riferimento precedono osono contestuali a quellesvolte presso la Banca,

recependo le linee guida, iframework di riferimento e/oindicazioni su approcci da

adottare da parte dellebanche utenti.

Una timeline integrata di progettoL'integrazione tra il piano di progetto Banca ed outsourcer di riferimento

- ESEMPLIFICATIVO -




Occorre definire tutti gli aspettiche possono permettere di

coordinare il progetto:

1) riferimenti ai singoli masterplan

2) attori coinvolti nelle analisi enella definizione dei modelli

operativi TO BE

3) input necessari nei momentidi condivisone

4) SAL di progetto permonitorare le attività ed

identificare eventuali issuedi progetto

5) definizione dei deliverable diprogetto e scadenze di

rilascio di bozze e versionifinali

Un esempio di gestione di un cantiereLa pianificazione operativa del Cantiere Sicurezza

- ESEMPLIFICATIVO -



Un esempio di gestione di un cantiereLa pianificazione operativa del Cantiere Sicurezza


Follow up stesuraprocedure a settembre

Macro-attività per risoluzione Gap Febbraio

2014

Marzo Aprile Maggio Giugno

Mappatura Processi AS IS1

15 int. 15 est.

− supporto alla rilevazione di dettaglio deiprocessi di sicurezza ad oggi definiti

1.1

10 int. e 20 est.

10 int. e 25 est.

35 int. 65 est.

Policy di Sicurezza

w1 w2 w3 w4 w1 w2 w3 w4 w1 w2 w3 w4 w1 w2 w3 w4 w1 w2 w3 w4

Procedure operative

− definizione delle aree di miglioramento1.2

− definizione delle possibili aree diintegrazione con le strutture lato Banca

1.3

Definizione scenari TO BE2

− definizione scenari TO BE identificatorispetto ai domini ISO27002

2.1

Condivisione modello Banca3

PMO5

− condivisione modello con le Banche3.1

− stesura Policy di Sicurezza3.2

− stesura e/o completamento procedureoperative sulla base del nuovo modello

3.3

Proposizione delle attività , policy,controlli e output forniti alla

Banche

Deliverable

5 int. 10 est. Assessment Internet Payments BCE4 Piano di adeguamentoBCE

Condivisione DirezioneIT e/o IT AuditBanche

Condivisione DirezioneIT e/o IT AuditBanche

Owner interno: Mario Rossi

Consulente: Mario Rossi

Impegno: Lunedì e Martedì

- ESEMPLIFICATIVO -




• Una volta definito il master operativo che ha determinato le attività dei singoli cantieri, i ruoli e leresponsabilità, le modalità e le tempistiche di integrazione tra i diversi attori coinvolti, per ognidominio dell'ISO27001-2:2013 sono stati definiti:

riferimenti 263 – riferimento puntuale alla normativa 263 in cui sono trattate le specifichetematiche di sicurezza dei vari ambiti ISO;

impatto Banca – eventuale impatto del processo di sicurezza sui processi interni dellaBanca;

cantieri 263 – eventuali altri cantieri progettuali che impattano il processo di riferimento;

referenti cantieri – referente responsabile del Cantiere 263 individuato;

strutture coinvolte – eventuali altre strutture coinvolte nei processi di sicurezza;

priorità – priorità di analisi del dominio (1 - priorità alta, 2 - priorità media, 3 - priorità bassa)assegnata sulla base dell'impatto della 263 e/o sulla base della presenza di legami con iprocessi di sicurezza lato Banca.

• Sono state quindi avviate le attività di analisi di dettaglio sul modello operativo AS IS identificandoeventuali gap attraverso la mappatura di policy/ procedure/istruzioni operative e i controlli in essere.Prima di formalizzare il nuovo corpo normativo, è definito un modello operativo TO BE e condivisocon gli attori di riferimento.

• Nelle slide successive sono state riportate a titolo esemplificativo possibili deliverable di dettaglio asupporto delle analisi eseguite

Le attività di progettoUn esempio di cantiere – La Sicurezza IT

- ESEMPLIFICATIVO -




La definizione dei modelli operativiTO BE avviene mediante la

rilevazione di dettaglio di processi,attività operative e di controllo,

corpo documentale, meccanismidi raccordo con le Banche

attualmente in essere.

Occorre quindi definire eventualigap che necessitano di essere

colmati in termini di risorse,competenze, tecnologie a

supporto rispetto al modello TOBE e definire le azioni di

implementazioni che dovrannoessere adottate entro il 1 febbraio

2015.


- ESEMPLIFICATIVO -




.

Policy e procedure

Corpo documentale AS IS Corpo documentale TO BE

Primarie attività di gestione

Attività di gestione AS IS Attività di gestione TO BE

Controlli in ambito

Attività di gestione AS IS Attività di gestione TO BE


- ESEMPLIFICATIVO -




Attività \ Ruolo

Dominio 5. Access Control (ID 9)

Att

ore

1

Att

ore

3

Att

ore

3

……

Att

ore

n

Definizione di ruoli di responsabilità per singolo dominio e per attività definite nel modello TO BE

Cross-reference dei controlli su framework e standard di riferimento al fine di poter pervenire ad una definizione di unsistema di controllo integrato multireferenziato

ISO 27001:2013 CobiT 4.1 ISF Security Healtcheck

Asset Management PO2 - Define the Information ArchitecturePO4 - Define the IT Processes, Organisation and RelationshipsPO6 - Communicate Management Aims and DirectionPO7 - Manage IT Human ResourcesAI2 - Acquire and Maintain Application SoftwareDS9 - Manage the ConfigurationDS11 - Manage Data

CF1 - Security Policy and OrganisationCF2 - Human Resource SecurityCF7 - System ManagementCF13 - Desktop ApplicationCF16 - External Supplier Management


- ESEMPLIFICATIVO -



Grazie per l’attenzione!

ROBERTO NICCOLI

TELEFONO

(39) 02 66720332 (office)

(39) 348 1505631 (cellulare)

(39) 02 66720514 (fax)

MAIL

[email protected]

Documents

Verso il GOVERNO dei SISTEMI INFORMATIVI NORMATIVA, … · GOVERNO dei SISTEMI INFORMATIVI. 29.5.2014 - Padova - ISACA VENICE Chapter 2 TITOLO BREVE - N. COGNOME NORMATIVA, BEST PRACTICES