I presidi per la gestione dell’Information Technology in Italia
Introduzione
1. Il rischio informatico per le banche
1.1. Definizione di rischio informatico per le banche
1.2. Correlazione tra rischio informatico ed altri rischi
1.3. Normativa internazionale
1.3.1. Il processo di regolamentazione a livello europeo
1.3.2. Obiettivi, scopi e definizioni del framework
1.3.3. The Final guidelines on the security of Internet payments
1.4. Normativa nazionale
1.4.1. Definizioni fondamentali
1.4.2. Analisi del rischio informatico
1.4.3. Gestione della sicurezza informatica
1.4.4. Sistema di gestione dei dati
1.4.5. Esternalizzazione del sistema informatico
2. Information and Communication Technology governance
2.1. Rischi tecnologici e modalità di misurazione e gestione
2.2. Modelli di gestione dell’information technology system
2.3. Costi ICT e key performance indicators: TCO e Cash out
2.3.1. Rilevazione del TCO al 2014
2.3.2. Rilevazione del Cash out al 2014
2.4. Il patrimonio applicativo: gestione ed evoluzione
2.5. Le risorse umane del sistema IT
2.6. I social network e le banche
3. Business continuity and disaster recovery
3.1. Il Business continuity management e i suoi impatti sul profilo organizzativo
3.2. Riferimenti normativi
3.2.1. Normativa internazionale
3.2.2. Normativa nazionale
3.2.2.1. Requisiti per tutti gli operatori
3.2.2.2. Requisiti particolari per i processi a rilevanza sistemica
3.3. Obiettivi, procedure e testing della business continuity
3.4. Risk assessment, business impact analysis e cost-benefit analysis
3.5. Il disaster recovery plan
3.6. Procedure e organizzazione per il disaster recovery
3.6.1. Organizzazione
3.6.2. Processo di disaster recovery
3.6.3. Interventi tecnologici per il raggiungimento dei valori obiettivo di RPO e
RTO
Conclusioni
Introduzione
La rapida evoluzione tecnologica ha influito enormemente sull’evoluzione dei sistemi informatici delle varie organizzazioni ed istituzioni di tutto il mondo, anche e soprattutto in ambito finanziario e bancario a partire dagli anni ’70.
Concentrando l’attenzione sul settore bancario, il sistema informativo rappresenta ormai un elemento cruciale per il conseguimento degli obiettivi strategici e operativi in considerazione delle criticità dei processi aziendali che dipendono da esso.
Per le banche, infatti, un sistema informativo sicuro ed efficiente permette un miglioramento ed ampliamento dal lato dell’offerta nei confronti di una domanda sempre più difficile da soddisfare e fidelizzare; si permette una miglior capacità in termini di operatività quotidiana, relativa ad un più sicuro e rapido trattamento dei dati, comportando, ovviamente, un miglioramento in ambito decisionale e strategico.
Appare dunque evidente che l’evoluzione tecnologica, assieme ai vantaggi sopra citati, comporta anche il sostenimento di nuovi rischi per le banche di stampo principalmente operativo ma non solo, in quanto vanno a riguardare situazioni di interruzioni di operatività e di perdita di dati, con conseguenti perdite anche in termini, tra le tante, di reputazione, di compliance e legali.
Occorrerà dunque che le banche seguano il processo di evoluzione tecnologica basandosi sul principio di proporzionalità e analizzando con accuratezza le opportunità di outsourcing quando il sistema informativo risulta eccessivamente oneroso da produrre con risorse interne. È fondamentale che la continuità operativa sia garantita da processi di controllo dei rischi e da una accurato management con forte coinvolgimento da parte degli organi direzionali, nonché da processi in risposta ad eventuali interruzioni della continuità stessa, al fine di ridurre al minimo la perdita di dati e minimizzare i disservizi per l’operatività interna ed i servizi alla clientela. La gestione del sistema informativo diventa fondamentale per la quantità di dati ed operazioni trattate e che sono in continuo aumento, in quanto una perdita anche solo temporanea di dati o di disponibilità operativa può produrre perdite ingenti e disservizi tali da compromettere anche per lungo tempo la normale operatività. Questo ha spinto a un forte intervento in termini normativi e di processi di analisi, gestione e contenimento dei rischi, in ottica di continua evoluzione e miglioramento degli stessi.
L’obiettivo della tesi è dunque quello di osservare come, partendo da una analisi della normativa nazionale ed internazionale, si vada poi ad implementare il processo di acquisizione delle risorse IT necessarie, come si vada a gestire la continuità operativa e come si vada a rispondere nelle situazioni di crisi, al fine di ripristinare, nel minor tempo possibile e con l’obiettivo di minimizzare la perdita di dati, la normale operatività.
Nel primo capitolo la tesi tratterà la definizione di rischio informatico, la normativa a livello internazionale, a livello nazionale e la correlazione con gli altri rischi che le banche devono contrastare, rendendolo quindi un rischio trasversale. Mentre la normativa internazionale tende a indicare una serie di linee guida da seguire, principalmente in ambito di gestione dei dati, la normativa nazionale si occupa non solo di implementare tali indicazioni, ma anche di indicare le modalità di gestione, di analisi dei rischi, indicazioni in merito all’esternalizzazione del sistema informatico.
Nel secondo capitolo si andrà ad indicare quali siano i rischi relativi all’utilizzo della tecnologia nel settore bancario, come questi rischi vengono misurati e l’impatto di tali analisi in merito alla gestione del sistema informatico complessivo, tenendo conto anche dell’influenza dei costi relativi alle decisioni in merito al patrimonio applicativo, alle risorse umane e andando, infine, a valutare l’impatto a livello sia organizzativo che strategico dell’utilizzo dei social network per il settore bancario.
Il terzo capitolo tratterà il tema della continuità operativa, gli impatti sul profilo organizzativo, la normativa e il processo di realizzazione del business continuity plan. Si procede poi ad analizzare la disaster recovery, di cui si analizzerà il processo di programmazione, le modalità di implementazione di un processo di disaster recovery a seguito di un disastro, le tecnologie a disposizione e gli strumenti che permettono di implementare la miglior soluzione possibile dati i fattori quali i rischi, i costi, il budget a disposizione. Le tecniche di risposta alle situazioni di contingenza sono riprese da un seminario del Gruppo Poste Italiane s.p.a., nel quale si analizzano le soluzioni proposte per Banco Posta s.p.a. che, seppur non sia una banca in senso stretto, prevede in questo ambito modalità tecniche, procedurali e strategie molto simili.
1
Capitolo 1. Il Rischio Informatico per le Banche
1.1. Definizione di rischio informatico per le banche
La rapida evoluzione delle tecnologie dell’informazione e della comunicazione ha comportato una centralità nell’assetto organizzativo e funzionale assunta dai sistemi informatici nelle imprese e nelle istituzioni, quindi anche e soprattutto nel settore bancario. La diffusione delle tecnologie fondate sul paradigma Internet, poi, ha favorito il ridisegno dei confini organizzativi dell’impresa, sempre più aperta e connessa con altri soggetti e sistemi informatici1.
Concentrando l’attenzione sugli intermediari finanziari, e soprattutto sulle banche, il sistema informativo, inclusivo delle risorse tecnologiche, hardware, software, dati, documenti elettronici, reti telematiche, e delle risorse umane dedicate alla loro amministrazione, rappresenta uno strumento di primaria importanza per il conseguimento degli obiettivi strategici e operativi, in considerazione della criticità dei processi aziendali che dipendono da esso.
Un sistema informativo sicuro ed efficiente, da un punto di vista strategico, basato su una architettura flessibile, resiliente e integrata a livello di gruppo consente di sfruttare le opportunità offerte dalla tecnologia per ampliare e migliorare i prodotti e servizi offerti alla clientela, accrescere la qualità dei processi di lavoro, dematerializzazione dei valori, riduzione dei costi mediante la virtualizzazione dei servizi bancari; in ottica di sana e prudente gestione, consente di disporre di informazioni dettagliate, pertinenti ed aggiornate per l’assunzione di decisioni consapevoli e tempestive e per la corretta attuazione del processo di gestione dei rischi; riferendosi al rischio operativo, il regolare svolgimento dei processi interni e dei servizi
1 Convenzione Interbancaria per i Problemi dell’Automazione, Gruppo di Lavoro: Il Rischio Informatico, Capitolo
2
forniti alla clientela, l’integrità, la riservatezza e la disponibilità delle informazioni trattate, fanno affidamento sulla funzionalità dei processi e dei controlli automatizzati. Infine, a livello di compliance, al sistema informativo è affidato il compito di registrare, conservare e rappresentare correttamente i fatti di gestione e gli eventi rilevanti per le finalità previste da norme di legge e da regolamenti interni ed esterni.2
La definizione di Rischio Informatico è indicata, nella normativa di Vigilanza Prudenziale per le banche, come “il rischio di incorrere in perdite economiche, di reputazione e quote di mercato in relazione all’utilizzo di tecnologia dell’informazione e della comunicazione”. 3 Si tratta di un rischio che si sviluppa in seguito allo sviluppo tecnologico nelle aree operative delle banche, per cui è considerato come tipologia di Rischio Operativo.
Quest’ultimo viene definito come “rischio di subire perdite derivanti dall’inadeguatezza o dalla disfunzione di procedure, risorse umane e sistemi interni, oppure da eventi esogeni”. Le tipologie di Rischio Operativo derivano dalle tipologie di cause che ne scaturiscono:
Frode interna; Frode esterna;
Rapporto di impiego e sicurezza sul lavoro; Clientela, prodotti e prassi professionali; Danni da eventi esterni;
Interruzioni dell’operatività e disfunzione dei sistemi; Esecuzione, consegna e gestione dei processi.
Osservando gli Event Types, si evidenzia la forte presenza della componente umana, ma appare evidente che la componente Information Communication Technology stia aumentando sempre più peso, anche tenendo conto del continuo sviluppo dello stesso. Essendo una tipologia di Rischio Operativo, mantiene le sue caratteristiche, tra cui la trasversalità, ovvero il fatto di interessare non una particolare area operativa, ma tutte, in quanto tutte le aree vedono un forte sviluppo tecnologico e, conseguentemente, una maggior esposizione a questo rischio.
Proprio la sua trasversalità ha comportato la necessità di un impianto normativo molto importante, prevedendo una serie di principi, definizioni, standards e procedure
2 Banca d’Italia, Circolare 285/2013, Parte Prima “Recepimento della CRD IV” Titolo V, Capitolo 4, Sezione I,
Premesse.
3
metodologiche che andranno ad impattare sulla singola banca in modo diverso a seconda dei modelli di Governance adottati e dalla dimensione della banca stessa.
La complessità in termini di gestione e controllo del Rischio Informatico richiederà che il Sistema di Controlli Interni sia presidio principale per la prevenzione e contenimento di tali rischi. Andranno allora approvate e attuate le politiche e le procedure aziendali volte a definire e identificare, valutare e gestire l’esposizione a tale rischio.4
Nella sua complessità non va assolutamente sottovalutato il rischio di attacchi esterni, in quanto il rischio derivante da attacchi cybernetici risulta in continuo aumento, sia in termini di quantità di attacchi, sia in termini di impatti. La differenza con altre tipologie di crimini è data dal fatto che non risulta necessaria una presenza fisica; conseguemente risulta meno percepibile da parte di chi lo subisce, e anche più conveniente in termini di costi da parte di chi attua tali attacchi di vandalismo, terrorismo, spionaggio.5
Così come per le altre tipologie di rischi, anche dalla definizione di Rischio Informatico si ottiene quella di Rischio Informatico Residuo, derivante dall’analisi del rischio informatico, sua stima e misurazione, per poi andare a definirlo quindi come il rischio a cui l’intermediario è esposto una volta applicate le misure di attenuazione individuate nel processo di analisi dei rischi.6
Il rischio valutato prima dell’applicazione di tali misure è detto rischio potenziale; si noti che quest’ultimo non coincide con la quota parte di “risk capacity” relativa all’ICT, che rappresenta invece il massimo rischio teoricamente sopportabile dalla banca in relazione all’utilizzo delle proprie risorse ICT.7
La finalità dell’andare a definire non solo i rischi diretti, i quali andranno a concorrere alla determinazione dei requisiti patrimoniali come stabilito dalle regole di Basilea 3, ma di andare a definire anche i rischi residui, deriva dal fatto che la sola considerazione dei primi non risulta sufficiente per completare la struttura prudenziale finalizzata al contenimento dei rischi informatici: occorrono anche una serie di requisiti organizzativi che implichino l’introduzione di comportamenti da parte degli intermediari che vadano a minimizzare le cause di rischio.8 La maggior esposizione delle banche a queste tipologie di rischi risulta direttamente proporzionale alla continua crescita della complessità dell’ICT. Ciò ha comportato che anche
4 Circolare 285/2013, Titolo V, Capitolo 7, Allegato A: Disposizioni Relative a Particolari Categorie di Rischio. 5 R. Baldoni, R. de Nicola, Laboratorio Nazionale di Cyber Security Consorzio Interuniversitario Nazionale per
l’Informatica, Il Futuro della Cyber Security in Italia, Ottobre 2015.
6 Circolare 285/2013, Parte Prima “Recepimento della CRD IV”, Titolo IV, Capitolo 4, Definizioni. 7 Banca d’Italia, Nota di chiarimento del 6 giugno 2014- Sistema di Controlli Interni, Sistemi Informativi,
Continuità Operativa
4
rischi non direttamente connessi ai rischi informatici, ma relativi a operatività tipiche, siano anch’essi incrementati significativamente.9
La normativa in merito al Rischio Informatico segue le finalità perseguite dall’introduzione del Rischio Operativo da Basilea 2 come Rischio di Pillar 1. Si vuole fare in modo che tale rischio venga analizzato e gestito mediante un approccio attivo, evitando che si attuino soltanto semplici operazioni di mitigazione senza alcuna analisi antecedente. Infatti, l’introduzione del Rischio Operativo come rischio di Pillar 1 fu voluto per far sì che le banche avessero un approccio attivo e non basato sul semplice trasferimento del rischio mediante tecniche quali le di polizze assicurative. Si tratta di una tipologia di rischio che è insito nell’attività di impresa, qualunque essa sia, e che le banche gestiscono ancora non con la stessa esperienza di cui potrebbero disporre nel caso di altre tipologie di rischi quali quelli di credito, di mercato, di liquidità, su cui le banche hanno certamente un bagaglio di esperienza maggiore.
1.2 Correlazione tra rischio informatico ed altri rischi
Come rilevato dalla Banca d’Italia, la mutazione in corso della composizione dei rischi bancari ha visto proporzionalmente ridursi quelli derivanti dalla detenzione del portafoglio crediti e aumentare quelli operativi, legali, di reputazione, legati alla partecipazione delle banche ai diversi segmenti dell’attività di intermediazione.10
La letteratura economica in ambito di sicurezza informatica è stata quindi estremamente attiva e prolifica nell’individuare e classificare, anche in dettaglio, le diverse tipologie di rischio connesse all’operatività informatica, portando alla definizione di un vero e proprio glossario di rischi articolato e condiviso dagli operatori del settore.
In un contesto bancario dove la componente tecnologica rappresenta un rilevante fattore di produzione, è importante, come evidenziato dall’impianto normativo, definire la corretta sinergia tra la valutazione del rischio informatico e l’ambito dei rischi operativi.
Le manifestazioni del Rischio Informatico, infatti, appartengono al più ampio spettro di quelle del Rischio Operativo. L’identificazione, valutazione/ misurazione, mitigazione e monitoraggio di tale rischio richiedono professionalità specifiche che non risiedono generalmente nella funzione Risk Management. In ottica di efficienza, sarebbe auspicabile
9 Risk Assestment of the European Banking System, Dicembre 2015, Capitolo 6.
5
che venisse esplicitamente richiamata l’opportunità di una stretta collaborazione tra le funzioni preposte al governo della variabile informatica (non inquadrate come funzione di controllo di secondo livello e quindi non richiamate nel paragrafo 5 - Cap. 7 Sezione II) e la funzione di Risk Management/ Operational Risk Management; ad esempio, le attività di raccolta dati di perdita e le valutazioni di scenari di rischio vedono già coinvolta la funzione Operational Risk Management anche con riferimento ai Sistemi Informativi.
I Rischi Informatici, riconducibili cioè allo svolgimento di processi automatizzati di trattamento di dati aziendali, non hanno in realtà una rilevanza autonoma, ma possono tradursi per la banca in una delle seguenti categorie di rischio:
Rischio giuridico legale che attiene al mancato rispetto ovvero alla violazione di disposizioni legislative, amministrative o statuarie ed è strettamente connesso alla tipologia di attività che la banca svolge. Il malfunzionamento dei processi elaborativi può quindi mettere la banca nell’impossibilità di adempiere ad obblighi posti dalla normativa di riferimento;
Rischio operativo; i rischi operativi sono rappresentati dalla possibilità che le procedure di elaborazione dati della banca non consentano la soddisfazione del cliente e il raggiungimento degli obiettivi di correttezza, completezza, tempestività e costo fissati per i diversi processi di elaborazione;
Rischio commerciale e di immagine; tale rischio è rappresentato dalla possibilità che la banca, a causa di errori nei propri processi di elaborazione, possa incrinare i rapporti con clienti, fornitori, dipendenti e in generale i propri stakeholders;
Rischio di frode e infedeltà; tale rischio, come detto, può essere agevolato da malfunzionamenti o abusi del sistema informativo.
Sulla base di tali possibili cause di perdite dovute all’espletamento del rischio informatico in termini generali, si è resa possibile dunque la definizione di un vero e proprio glossario di rischi articolato e condiviso da tutti gli operatori di settore.
Prendendo come riferimento l’elaborazione automatizzata dei dati, i rischi specifici (cui son riconducibili le categorie di rischi operativi precedentemente indicate) possono riferirsi ai tre requisiti che deve possedere un processo elaborativo:
Integrità, intesa come garanzia che ogni dato aziendale corrisponda a quello originariamente immesso nel sistema ovvero successivamente modificato in modo legittimo;
6
Riservatezza, ossia la garanzia che un determinato dato aziendale venga reso disponibile solamente ai processi che lo devono elaborare e all’utilizzatore che ne ha oggettivamente bisogno e pertanto è legittimato al suo utilizzo;
Disponibilità, ossia la garanzia che i dati aziendali siano disponibili in funzione delle esigenze di continuità dei processi e al fine del rispetto delle norme che ne impongono la conservazione storica.
Ne deriva allora l’individuazione di una serie di tipologie di rischi in base all’impatto su tali requisiti:
Rischio di accesso, cioè il rischio che sia, in modo appropriato, concesso o negato l’accesso all’informazione;
Rischio di disponibilità, quindi il rischio che l’informazione non sia disponibile quando necessario;
Rischio di infrastruttura, legato alla mancanza di una efficiente infrastruttura di sistema;
Rischio di integrità, riguardante la completezza e accuratezza dell’informazione; Rischio di rilevanza, connesso alla completezza e accuratezza dell’elaborazione
dell’informazione;
Rischio di rilevanza, legato alla pertinenza dell’informazione in base agli scopi per la quale viene elaborata.
Si osserva quindi una duplice accezione di sicurezza: la prima fa riferimento alla regolarità e funzionamento dei sistemi di elaborazione, mentre la seconda fa riferimento ad un uso improprio delle risorse del sistema e al concretizzarsi di minacce principalmente di origine dolosa.
Ne derivano dunque una serie di metodologie di approccio alla sicurezza, si evidenziano dunque una serie di minacce. Queste minacce vengono poi correlate ai requisiti di sicurezza. Si tratta dunque di:
Furti;
Frodi o malversazioni; Danneggiamento;
Manipolazioni di dati e programmi; Utilizzo di software illecito;
7 Divulgazione di dati e programmi; Utilizzo illegale o errato di risorse; Indisponibilità dei sistemi;
Inagibilità dei locali.
Tali tipologie di minacce inoltre impattano direttamente o indirettamente, su tutti i processi EDP (Electronic Data Processing, ovvero l’utilizzo sistemi automatizzati per processare dati contabili e commerciali11) della banca, quali:
Pianificazione e progettazione; Acquisizione e implementazione; Processi erogativi e di supporto.
Tabella 1. Correlazione Minacce/Requisiti di Sicurezza
Minacce Integrità Riservatezza Disponibilità
Furti X X
Frodi o Malversazioni X X
Danneggiamento X X X
Manipolazioni di dati e programmi X X X
Perdita di Privacy X
Errori sui dati e programmi X X
Utilizzo di Software illecito X X X
Divulgazione di dati e programmi X
Utilizzo illegale o errato di risorse X X
Indisponibilità dei sistemi X X
Inagibilità dei locali X
Fonte: A. Pappadà, G. Varola, “I Rischi Operativi nelle Banche: Misurazione e Gestione”, Capitolo 10, Bancaria Editrice 2003, Nike Consulting
Sul fronte delle soluzioni tecniche, come sottolineato dalla norma, è importante che la Funzione di Sicurezza Informatica mantenga indipendenza di giudizio nell’analisi delle variabili che concorrono alla determinazione del Rischio Informatico. A tal fine, il dialogo fra la Sicurezza Informatica e la Funzione IT dovrebbe essere improntato a favorire la sinergia delle rispettive competenze pur rispettando l’indipendenza nelle valutazioni; le banche caratterizzate da maggiore articolazione organizzativa attuano questo principio collocando la funzione di sicurezza informatica separata dall’IT.
Inoltre, rileva evidenziare come la norma in consultazione ponga grande attenzione al ruolo dell’utente. Esso sembrerebbe dunque più vicino a una figura di business – che per molte realtà italiane sarebbe ancora da identificare – piuttosto che a una figura con competenze tecniche; si ritiene opportuno chiarire tale aspetto nella definizione del ruolo. In assenza delle
11 A. Gord, Analysis and Reporting of Data, Capitolo 5: “Analysis of EDP Auditing System in Banks”, consultabile dal link http://shodhganga.inflibnet.ac.in/bitstream/10603/3727/15/15_chapter%205.pdf
8
necessarie competenze tecnologiche da parte dell’utente, appare difficile poter dedurre che la responsabilità del rischio associato ai vari ambiti applicativi e tecnologici sia riconducibile esclusivamente a tale figura. È importante e innovativo che sia definito un processo di accettazione del rischio residuo da parte dell’utente in base alle soluzioni identificate dai referenti con competenze di Sicurezza Informatica e valutate d’intesa con il Risk Management; tale approccio rappresenterebbe il giusto equilibrio tra il coinvolgimento del business da un lato e delle figure tecniche dall’altro nella corretta valutazione del Rischio Informatico e delle soluzioni necessarie alla relativa mitigazione.12
1.3. Normativa internazionale
1.3.1. Il processo di regolamentazione a livello europeo
La normative sulla sicurezza informatica appare tuttora molto frammentata tra i vari Paesi, seppur si stia provvedendo alla creazione di un framework che abbia validità all’interno dell’Unione Europea. Questo ha fatto sì che si desse avvio a una forte collaborazione tra istituzioni finanziarie, services providers e autorità competenti, facilitando tantissimo il lavoro dell’EBA, la quale sta elaborando una rete di supervisori ICT e autorità competenti che selezionino esperienze e best practices nel cyber risk e cloud computing. L’EBA ha inoltre pubblicato i Requirements on the security of internet payment, che sono entrati in vigore dal 1 Agosto 2015.13
La finalità dei Requirements nasce dalla necessità a livello internazionale di una regolamentazione comune, accettata da tutti, e che quindi permetta una sorta di armonizzazione che, per certi versi, può risultare difficile date le evidenti differenze tra i vari sistemi nazionali ma che, per altri versi, è necessaria per permettere di avere per tutti un indirizzo comune di comportamento dal quale prendere spunto.
Da ciò trae spunto il testo Principles for effective risk data aggregation and risk reporting, pubblicato dal Comitato di Basilea nel 2013. Si tratta di un paper che vuole creare un set di
12 A. Pappadà, G. Varola, “I Rischi Operativi nelle Banche: Misurazione e Gestione”, Capitolo 10, Bancaria
Editrice 2003, Nike Consulting
9
principi che le banche devono seguire per migliorare la capacità di raccolta e la gestione del rischio dato da tale raccolta mediante reporting. Ciò, secondo quanto indicato dal paper stesso, dovrebbe permettere di migliorare l’informativa con gli alti gradi nell’organigramma delle banche, migliorare quindi il processo decisionale, la creazione a livello globale di una sorta di definizione unitaria di esposizione a tale rischio, quindi ridurre le perdite potenziali, migliorare il flusso informativo e migliorare il processo di pianificazione strategica anche in merito alla produzione di nuovi servizi e prodotti per la clientela. 14
A livello comunitario, il legislatore tende sempre a sfruttare un procedimento basato su una iniziale introduzione normativa dal quale parte una consultazione, che dà la possibilità ai Paesi Membri di poter trarre le proprie considerazioni e permettere al regulator quindi di migliorare la normativa, appunto, in ottica di armonizzazione.
Mediante questo procedimento si osserva la nascita di numerosi lavori, tra cui The Final Guidelines of The Security of Internet Payments. Esso trae origine dall’European Forum on the security of Retail Payments, meglio noto come SecuRe Pay, del gennaio 2013, a cui fa seguito la pubblicazione nel 2014 di un Consultation Paper. La finalità è quella di prevedere una solida base legale per l’implementazione di requisiti di base consistenti e armonizzati per i 28 Stati Membri.15
Mediante il Consultation Paper si voleva definire principalmente la modalità di introduzione di una serie di linee guida che permettessero standards di alto livello di sicurezza in attesa della redazione e entrata in vigore della Payment Service Directive 2, con uno sguardo al biennio 2017/2018. Si diede agli Stati Membri l’opportunità di attuare l’implementazione di questi requisiti in due modalità:
Mediante un processo con unico step, con cui l’EBA avrebbe anticipato i requisiti di implementazione al 1 agosto 2015;
Mediante un approccio a due step, con cui invece sarebbe stata imposta una prima implementazione il 1 agosto 2015, seppur in ottica di futura consultazione e rimodifica.
La maggior parte degli stati membri scelse la prima modalità, mentre alcuni scelsero la seconda, e altri ancora erano contrari ad entrambe. L’ottica della maggioranza era basata dal fatto che un approccio basato su un unico step fosse inutilizzabile, data anche la mancanza di una definizione specifica della “strong authentication” La scelta dell’EBA fu quella di seguire il secondo, per due motivi, tenendo conto del fatto che la maggioranza avesse optato per
14 Comitato di Basilea, Principles fod Effective Risk Data Aggregation and Risk Reporting, Gennaio 2013 15 EBA, Final Guidelines on the Security of Internet Payments, Executive Summary, 19 Dicembre 2014
10
l’approccio con un unico step, ma soprattutto tenendo conto del continuo aumento delle frodi via internet dal 2012 in poi, che rendeva non plausibile la possibilità di ritardare ulteriormente l’entrata in vigore del PSD 2.
Durante la fase consultativa si era addirittura ipotizzato che l’insieme delle disposizioni venisse anticipato rispetto all’entrata in vigore della normativa. Tale ipotesi è stata rigettata, tenendo conto di un contesto che avrebbe visto nel caso una forte asimmetria normativa tra la clientela del PSP e delle così dette Terze Parti (TPPs), le quali si troverebbero esenti da tali disposizioni. L’eventuale anticipazione avrebbe introdotto una assenza di tutela nei confronti dei clienti delle TPPs che difficilmente per loro stessi sarebbe stato comprensibile. Altra ipotesi rigettata è quella riguardante la traduzione delle best-practices in misure obbligatorie: tale intervento è stato valutato eccessivo, in quanto, nonostante le rilevazioni sulle frodi e sugli attacchi ai servizi di internet banking indicassero un forte aumento, oltre il 97% di questi è stato efficacemente bloccato. Tenendo conto di ciò, è risultato eccessivo un incremento dei requisiti di sicurezza in via anticipata rispetto all’introduzione della PSD2.16
1.3.2.Obiettivi, scopi e definizioni del framework
Per capire quali siano le finalità che spingano alla definizione di una serie di regolamentazioni, occorre capire il contesto di riferimento. La continua evoluzione dei sistemi di pagamento ha portato ad un aumento delle possibili minacce. Si osserva infatti un incremento costante delle frodi, secondo quanto analizzato dal 2012 in poi mediante il terzo Card Fraud Report della BCE, in cui si sottolinea che nel solo 2012 le perdite dovute a tale tipologia di frodi ammontava a 794 milioni di euro. 17
16 ABI, Position Paper in risposta alla procedura di consultazione della Banca d’Italia sul “Recepimento in Italia
degli Orientamenti dell’ABE in materia di sicurezza dei pagamenti tramite canale internet”, 12 ottobre 2015
17 ECB, Third Report on Card Fraud, February 2014,
11
Figura 1: evoluzione del trend delle frodi nel SEPA
Fonte: EBA, Card fraud report
Si vuole quindi creare un set di regole e requisiti per la sicurezza dei pagamenti via internet. Sono regole definite per le istituzioni finanziarie. Non va considerato come un documento che abbia la finalità di sovrastare la validità del Recommendations for the Security of Internet Payments, il Report della BCE, documento mediante cui le banche centrali osservano la propria compliance in termini di sistemi di sicurezza dei pagamenti online.
Viene poi precisato che dagli scopi di queste linee guida sono escluse una serie di casistiche, quali gli e-brokerage e contratti online, i quali son considerati come altre tipologie di servizi eseguibili via internet attraverso un Payment Service Provider, pagamenti dove le istruzioni vengono indicate via posta, ordine telefonico, messaggi vocali, SMS, pagamenti su altri browser di base, credit transfers dove una terza parte può accedere all’account del consumatore, transazioni in reti aziendali specifiche, pagamenti mediante carte virtuali anonime e non rintracciabili, dove non si ha quindi nessun legame tra utilizzatore e proprietario, regolamentazione su transazioni.
Per gli scopi stessi di queste linee guida, vengono precisate una serie di definizioni:
Authentication: sono le procedure che permettono al PSP di verificare l’identità dell’utilizzatore;
Strong Customer Authentication: è una procedura basata sull’uso di uno o più dei seguenti elementi: a) qualcosa che solo l’utilizzatore conosce, come una password statica, codice, codice di identificazione personale; b) qualcosa che solo l’utilizzatore possiede,
12
come un token, una smart card, numero di telefono; c) qualcosa che rappresenti l’utilizzatore come caratteristiche biometriche, quindi impronta digitale. Almeno uno di questi elementi dovrebbe essere non riutilizzabile e non replicabile, ma soprattutto non suscettibile di furto via internet. La procedura di strong authentication dovrebbe essere delineata al fine di proteggere la confidenzialità dei dati autenticativi;
Authorisation: è la procedura che accerta che un utilizzatore o PSP sia in grado di effettuare determinate operazioni, quali il diritto di movimentare fondi e accedere a dati sensibili;
Credentials: le informazioni che vengono inserite dall’utilizzatore per l’autenticazione, che possono anche significare il possesso di uno strumento materiale contenente tali informazioni o qualcosa che rappresenti l’utilizzatore stesso;
Major payment security incident: riguarda un incidente in cui si ha o potrebbe avere impatto in termini di sicurezza, integrità, continuità del Payment Service Provider e/o la sicurezza dei dati sensibili su pagamenti e fondi;
Transaction risk analysis, cioè la valutazione del rischio legato a specifiche transazioni che riprendono alcuni dati dell’account quali valore della transazione, tipo di prodotto, profilo del pagante;
Virtual cards: è inteso come un sistema di pagamenti basato su utilizzo di carte, dove viene dato in utilizzo un codice con limitata validità temporale, uso, limite di spesa, generato per acquisti via Internet;
Wallet solutions: soluzioni che permettono all’utilizzatore di registrare dati su uno o più strumenti di pagamento in modo da effettuare pagamenti vero più e-merchants.18
1.3.3 The Final guidelines on the security of Internet payments
Il 19 Dicembre del 2014 l’EBA pubblicò il Final Guidelines on the Security of Internet Payments, che indica i requisiti minimi di sicurezza che ci si aspetta che vengano implementati dal 1 Agosto 2015 da parte dei Payment Services Providers.
13
Le line guida indicate dall’EBA in questo documento indicano che i Payment Services Providers realizzino una Strong Customer Authentication tale da verificare l’identità dell’utilizzatore/cliente prima di procedere a pagamenti online, oltre che per tutelare i dati degli stessi, in ottica di tutela della privacy.
Viene considerato come un documento di accompagnamento dalla Payment Service Directive (direttiva 2007/64/CE, la quale stabilisce norme relative all’esecuzione delle operazioni di pagamento qualora i fondi siano moneta elettronica quale definita all’articolo 1, paragrafo 3, lettera b) alla Payment Service Directive 2, una sorta di step che permetta agli intermediari quindi di adeguarsi al passaggio dalla vecchia normativa alla nuova. Questa è stata resa necessaria, secondo quanto indicato nelle considerazioni iniziali della stessa, da una serie di motivi quali la continua e rapida innovazione che ha comportato un maggior sfruttamento di modalità di pagamento online, nonché una maggior offerta di modalità stesse di pagamento; ciò ha messo in discussione lo stato della normativa, la quale quindi è stata rivisitata in modo anche da colmare lacune riscontrate precedentemente e garantire chiarezza giuridica e applicazione uniforme. Si può osservare, infatti, che una delle finalità principali è quella di tutelare i soggetti che devono seguire la normativa da altre modalità di pagamenti online che non vi rientrano, quindi risultanti deregolamentate e con un forte vantaggio competitivo, dati i minori oneri in termini di modalità di fruizione dei servizi senza tutte le garanzie richieste dalla normativa stessa.
In sostanza, la Payment Service Directive 2 allarga lo scopo della precedente a nuove tipologie di operatori e di servizi, disabilitando la possibilità di accesso verso questi da parte di altri operatori verso cui la normativa non vede applicazione.
Si osservano aggiornamenti in termini di pagamenti telematici (che vengono limitati a soli ridotti importi) e limita i pagamenti verso paesi terzi ai soli casi in cui tali pagamenti avvengano verso PSP con sede nell’Unione Europea, secondo il principio del “one-leg transaction”; si occupa anche di sviluppare una maggiore cooperazione e scambio di informazioni tra autorità in termini di autorizzazione e supervisione sugli istituti che forniscono tali servizi. Affida, infine, all’EBA, il compito di sviluppare un registro centrale di operatori che forniscono tali modalità di pagamento, ma anche (e soprattutto), il compito di sviluppare una serie di linee guida che agevolino la comprensione e un comportamento armonizzato da parte degli operatori.19
19 Direttiva (UE) 2015/2366 del Parlamento Europeo e del Consiglio del 25 novembre 2015 relativa ai servizi di
pagamento nel mercato interno, che modifica le direttive 2002/65/CE, 2009/110/CE e 2013/36/UE e il regolamento (UE) n. 1093/2010, e abroga la direttiva 2007/64/CE.
14
Questo ultimo compito viene effettuato mediante la Final Guidelines on the Security of Internet Payments, che si articola in tre macro-argomenti principali, i quali poi spaziano in un totale di 14 linee guida specifiche:
General control and Security Environment: o Governance;
o Risk Assessment;
o Incident monitoring and reporting; o Risk control and mitigation; o Traceability;
Specific control and security measures for internet payments: o Initial customer identification, information;
o Strong customer authentication;
o Enrolment for, and provision of, authentication tools and/or software delivered to the customer;
o Log-in attemps, session time-out, validity of authentication; o Transaction monitoring;
o Protection of sensitive payment data;
Customer awareness, education, and communication o Customer education and communication; o Notification, setting of limits;
o Customer access to information on the status of payment initiation and execution.
Queste linee guida si concentrano molto soprattutto sulla sicurezza della clientela e sulla privacy, spinge a una comunicazione pro-attiva, su un sistema di reporting a notifiche da parte del Payment Services Provider, indirizzate sia alla clientele che alle autorità; indica inoltre quali siano le responsabilità nei confronti dei fornitori.
15
1.3.3.1 General control and security environment
La prima area di linee guida va ad osservare quali siano le condizioni di base necessarie per poter poi fornire alla clientela determinati prodotti. Si tratta quindi di indicazioni di base per quanto concerne la Governance, Controllo e Mitigazione del Rischio, il Risk Assessment. Per quanto riguarda la Governance, si richiede che il Payment Services Provider implementi e revisioni regolarmente una security policy formale per l’ambito dei pagamenti via internet. Si richiede che venga propriamente documentata, possibilmente con un documento apposito, revisionata regolarmente e approvata dal senior management. In essa devono essere indicati gli obiettivi di sicurezza e il risk appetite; devono essere inoltre indicati nella policy i ruoli, le responsabilità, le modalità di reporting nei confronti del Board, incluso il Risk management. Il Risk Assessment riguardante i pagamenti e servizi via internet deve essere redatto e documentato in modo sistematico, sia prima che durante l’utilizzo di questi servizi. Esso dovrà inoltre includere informazioni circa l’ambiente tecnico del cliente dell’outsourcer, così come dovrà aver attenzione in merito alla protezione sui dati sensibili utilizzati nei pagamenti. Payment Services Providers dovrebbero ridurre il rischio di incidenti e denunce/segnalazioni in merito da parte degli utilizzatori mediante un continuo monitoring e un sistema di controllo degli incidenti di tipo follow-up. È prevista anche una procedura di reporting degli incidenti gestiti e per incidenti più gravi in termini di valore delle perdite da parte delle autorità competenti. Questo si dovrà estendere anche agli operatori con cui i Payment Services Providers collaborano, ma risulta fondamentale anche che questi ultimi abbiano un ruolo attivo in tal processo.
Per quanto riguarda le linee guida in merito al controllo e mitigazione del rischio, si richiede di implementare misure di sicurezza in linea con le proprie policy di sicurezza al fine di mitigare determinati rischi. Si richiede che ci siano più strati di difesa in modo che se un livello venga raggirato si abbia subito un altro strato di difesa. Una best practice suggerita è quella di fornire alla clientela strumenti di sicurezza contro usi illeciti della propria interfaccia utente e attacchi esterni. Si tratta sicuramente di uno dei punti più critici tra le linee guida, in quanto va a riguardare la gestione dei rischi in merito alle reti utilizzate, dati su pagamenti, aree ad accesso limitato, esternalizzazioni, tecnologie, i quali necessitano di questa fase per poter essere poi validati.
È necessario che si abbia la tecnologia adatta a tracciare ogni singola transazione online che venga effettuata, inclusi i mandati via internet.
16
1.3.3.2 Specific control and security measures for Internet payments
In questa area, le linee guida si occupano di situazioni specifiche nell’utilizzo dei servizi, situazioni quali controlli sulle operazioni effettuate dagli utilizzatori, modalità delle procedure di sicurezza, identificazione degli utilizzatori e monitoraggio delle loro operazioni.
Gli utilizzatori dovranno essere controllati in linea con quanto indicato dalla Normativa Anti-Money Laundering che valuterà anche la eventuale abilitazione a determinate operazioni come step iniziale per l’accesso a tali servizi. Va eseguita la due diligence e il funzionamento di software e hardware va ben spiegato alla clientela, ai fini di una maggiore chiarezza e trasparenza.
Viene richiesto che le procedure di sicurezza siano tali da permettere la sicurezza sulle credenziali, sui software per i pagamenti, e per tutti i sistemi telematici offerti. Per i software che vengono consegnati via internet occorre la firma digitale del Payment Services Provider al fine di permettere al cliente la verifica di autenticità e che il software non sia stato manomesso.
I meccanismi di monitoraggio delle transazioni sono determinati per prevenire, evitare e bloccare i pagamenti fraudolenti, mediante anche una valutazione preventive con annessa autorizzazione da parte del PSP della transazione stessa; transazioni sospette o ad alto rischio dovrebbero essere assoggettate a particolari processi di screening e valutazione. Deve essere creato anche un meccanismo di monitoring e autorizzazione equivalente per quanto riguarda i mandati online.
Tutti i dati utilizzati per identificare e autenticare i clienti/utilizzatori (ad esempio nel log-in, durante la fase iniziale dei pagamenti online, durante la creazione, modifica e cancellazione dei mandati online), così come l’interfaccia utente, dovrebbero essere appropriatamente sicuri contro furti e accessi e modifiche non autorizzate. È obbligatorio che venga adottata la metodologia di crittografia end-to-end per pagamenti via internet, così come è obbligatorio per il Payment Services Provider il rafforzamento di queste misure verso i propri commercianti online.
17
1.3.3.3 Customer awareness, education, and communication
L’ultima area di linee guida va ad osservare tutto ciò che concerne l’assistenza alla clientela, e le necessarie informative che debbono essere trasmesse in termini di chiarezza e trasparenza nell’utilizzo di determinati servizi offerti e richiesti dal cliente. Si tratta, in sostanza, di linee guida in merito ai servizi di assistenza, eventuali limiti alle operazioni e modalità alternative, e comunicazioni in merito alle autorizzazioni delle operazioni.
I servizi quali le guide e l’assistenza devono saper fornire ai clienti le informazioni necessarie per effettuare transazioni in modo sicuro via internet. Può anche essere utilizzato una modalità di comunicazione diretta con il cliente in tal senso.
I Payment Services Providers dovrebbero inoltre determinare quali siano limiti opportuni per i servizi di pagamento via internet; allo stesso tempo essi debbono fornire agli utenti modalità alternative che però risultano leggermente limitate rispetto alle prime perché esposte a maggiori rischi in termini di sicurezza. Potrebbero inoltre fornire servizi di alert e servizi quali il customer profile management.
I Payment Services Providers dovrebbero confermare, al momento dell’attivazione del servizio, l’effettiva autorizzazione per i pagamenti all’utente con una opportuna tempistica, con le necessarie informazioni, e validare la transazione che sia stata correttamente inizializzata e/o eseguita.
Qualsiasi dichiarazione elettronica dovrebbe essere resa disponibile in un ambiente sicuro e garantito. Quando il Payment Services Provider informa l’utente in merito alla disponibilità delle dichiarazioni elettroniche mediante una modalità diversa, come SMS, e-mail o lettera, essa non dovrebbe includere i dati sensibili.
1.4. Normativa nazionale
All’interno della Circolare 285/2013 vi è, nella Parte Prima, al Titolo IV, un intero capitolo relativo al Rischio Informatico, il quarto, il quale viene strutturato suddividendo definizioni, governo ed organizzazione del sistema informativo, analisi del rischio, la gestione della sicurezza informatica, il sistema di gestione dei dati, l’esternalizzazione del sistema informativo.20
18
Prima di tutto ciò, viene specificato chi sono i destinatari di tale normativa, in sostanza le banche autorizzate ad operare nel territorio italiano, le capogruppo di gruppi bancari.
Le normativa ha come fonti di riferimento la direttiva del parlamento europeo e del consiglio 2013/36/UE del 26 giugno 2013 sull’accesso all’attività degli enti creditizi e sulla vigilanza prudenziale per gli stessi, gli articoli 51, 53, 67 del Testo Unico Bancario, la Recommendation for the security of internet payments, la CRD IV e tiene conto anche dei Principles for effective risk data aggregation and risk reporting.
Prima di andare ad osservare nello specifico le disposizioni dettate dalla normativa, occorre osservare una serie di considerazioni. Il documento vuol definire i requisiti minimi organizzativi stringenti, anche se spesso già approvati dall’Autorità di Vigilanza. Si richiede inoltre che il rispetto delle previsioni vincolanti si basino sul principio di economicità, cioè che eventuali costi di adeguamento organizzativo abbiano come commisurazione vantaggi reali conseguibili in termini di rafforzamento di alcune funzioni specifiche e più in generale del presidio dei rischi aziendali nel quadro del sistema dei controlli interni.
Facendo riferimento specifico al governo e organizzazione dell’Information and Communication Technology e alle relative misure di sicurezza da adottare, si sottolinea l’obbligo da parte dell’organo con funzione strategica di deliberare in ordine al modello di riferimento per l’architettura dei sistemi informativi, facendo emergere al riguardo la necessità di chiarire le modalità di interazione con eventuali outosourcers.21
1.4.1 Definizioni fondamentali
Le definizioni della normativa sul Rischio Informatico vengono indicate nella part iniziale della normativa stessa, precisamente nella Sezione I, Punto 3, in modo da permettere una miglior comprensione delle indicazioni successive. Oltre alle definizioni di Rischio Informatico e di Rischio Informatico Residuo, che son già state citate precedentemente nel paragrafo 1.1, risulta essenziale saper indicare alcuni dei termini che più di tutti risultano essenziali per la comprensione e quindi una maggior capacità per gli addetti ai lavori nell’attuazione delle norme successive, vengono indicate alcune definizioni in particolare:
21 ABI, Position Paper in risposta alla procedura di consultazione della Banca d’Italia “Sistema dei controlli
19
Incidente di sicurezza informatica; ogni evento che implica la violazione o l’imminente minaccia di violazione delle norme e delle prassi aziendali in materia di sicurezza delle informazioni (ad esempio le frodi informatiche, attacchi attraverso internet e malfunzionamenti e disservizi);
Grave incidente di sicurezza informatica: un incidente di sicurezza informatica da cui derivi almeno una delle seguenti conseguenze:
o Perdite economiche elevate o prolungati disservizi per l’intermediario, anche a seguito di ripetuti incidenti di minore entità;
o Disservizi rilevanti sulla clientela e altri soggetti (intermediario o infrastrutture di pagamento); la valutazione della gravità considera il numero dei clienti o controparti potenzialmente coinvolti e l’ammontare a rischio;
o Rischio di inficiare la capacità della banca di conformarsi alle condizioni e agli obblighi di legge o previsti dalla disciplina di vigilanza.
Le due definizioni di incidente informatico evidenziano un diverso peso a seconda dei danni subiti, sia dalla banca, sia dalla clientela, sia a livello di compliance. Non solo implicano effetti più o meno pesanti in termini di perdite, ma anche diverse modalità di gestione e di flussi informativi: in caso di incidente grave, l’intermediario dovrà informare tempestivamente la Banca d’Italia e fornire valutazioni circa l’impatto dell’evento sull’operatività delle strutture (centrali e periferiche) e sui rapporti con la clientela e controparti. La gestione degli incidenti di sicurezza risulta quindi basata su una analisi iniziale di quali siano gli effetti e di quale sia la loro entità. Una volta accertata la natura e l’entità del danno risulterà fondamentale operare il più rapidamente possibile in modo da ripristinare la situazione. Infine, dopo una fase di reporting, sarà compito dei gestori della sicurezza informativa il valutare eventuali modifiche a livello organizzativo e tecnologico che permettano la riduzione della probabilità che tale incidente si verifichi di nuovo.
Risorsa informatica: un bene dell’azienda afferente all’ICT che concorre alla ricezione, archiviazione, elaborazione, trasmissione e fruizione dell’informazione gestita dall’intermediario;
Utente responsabile: la figura aziendale identificata per ciascun sistema o applicazione e che ne assume formalmente la responsabilità, in rappresentanza degli utenti e nei rapporti con le funzioni preposte allo sviluppo ed alla gestione tecnica.
20
Il compito dell’utente responsabile appare quindi in ogni fase organizzativa. Avendo la responsabilità della propria area, sarà necessario che non sia solo un soggetto con capacità manageriali, ma anche un soggetto che conosca la sua area, le specifiche tecniche, anche in ottica di trasmissione dell’operato e dei dati in un linguaggio che sia di facile comprensione nei confronti degli altri organi della banca. 22
1.4.2 Analisi del rischio informatico
La sezione III del capitolo 4, Titolo V, tratta l’Analisi del Rischio Informatico. Al primo comma lo si definisce come “uno strumento a garanzia dell’efficacia ed efficienza delle misure di protezione delle risorse ICT, permettendo di graduare le misure di mitigazione nei vari ambienti in funzione del profilo di rischio dell’intermediario”.
Si tratta quindi di un processo, e la sua peculiarità è la circolarità: un processo che, all’ultimo comma, si indica debba esser effettuato con periodicità adeguata alla tipologia di risorse ICT e dei rischi. Si deve tener conto anche dell’eventualità di situazioni quali gravi incidenti, rilevazione di carenze nei controlli, diffusione di notizie su nuove vulnerabilità o minacce, le quali vengono definite come capaci di influenzare il complessivo livello del rischio informatico.
Vengono individuati, mediante la normativa, i soggetti coinvolti, cui attribuire compiti e responsabilità. Si parla, in questo caso, di soggetti quali l’utente responsabile, il personale della funzione ICT, le funzioni di controllo dei rischi, di sicurezza informatica e, ove opportuno, dell’audit, secondo le metodologie e responsabilità formalmente definite dall’Organo con Funzione di Gestione.
L’importanza del definire quali siano i soggetti coinvolti deriva anche dal fatto che, per realizzare una efficace politica di sicurezza informatica, è necessario che le risorse umane coinvolte siano attentamente formate e sensibilizzate anche sugli aspetti di sicurezza. Va infatti rimarcato che qualunque presidio di sicurezza tecnico-organizzativo adottato può essere vanificato da comportamenti dannosi posti in essere, in modo intenzionale o meno, dal personale dell’azienda.23 Il ricorso alla risorsa umana si basa su una serie di criteri quali la sua affidabilità, cioè la sua capacità di assicurare riservatezza, disponibilità ed integrità, nonché
22 ABI, Position Paper in risposta alla procedura di consultazione della Banca d’Italia “Sistema dei controlli
interni, sistema informativo e continuità operativa”, Novembre 2012.
21
uso legale delle informazioni che tratta; ciò spinge quindi ad una maggior rilevanza della selezione accurata del personale, formazione ed addestramento, progettazione accurata dei processi aziendali, redazione di un adeguato sistema normativo e sanzionatorio interno. Secondo le dichiarazioni della Banca d’Italia, si osserva una forte attenzione sulle responsabilità e compiti dell’utente responsabile. L’utente sembrerebbe dunque più vicino a una figura di business – che per molte realtà italiane sarebbe ancora da identificare – piuttosto che a una figura con competenze tecniche; si ritiene opportuno chiarire tale aspetto nella definizione del ruolo. In assenza delle necessarie competenze tecnologiche da parte dell’utente, appare difficile poter dedurre che la responsabilità del rischio associato ai vari ambiti applicativi e tecnologici sia riconducibile esclusivamente a tale figura. È importante e innovativo che sia definito un processo di accettazione del rischio residuo da parte dell’utente in base alle soluzioni identificate dai referenti con competenze di sicurezza informatica e valutate d’intesa con il Risk Management; tale approccio rappresenterebbe il giusto equilibrio tra il coinvolgimento del business da un lato e delle figure tecniche dall’altro nella corretta valutazione del rischio informatico e delle soluzioni necessarie alla relativa mitigazione. La scelta di definire un quadro organizzativo e metodologico di riferimento deriva da una analisi di impatto, che ha portato ovviamente a questa decisione, tenendo conto di una serie di costi e benefici che tale scelta avrebbe comportato: tra i costi va tenuto conto di quelli di impianto, e la ricerca di personale esterno; questi però son risultati inferiori ai benefici, in quanto il processo di analisi del Rischio Informatico, nel consentire di graduare i presidi di sicurezza in funzione degli specifici rischi ravvisati nei diversi ambienti, offrirebbe benefici all’intermediario in termini di una più efficiente gestione della variabile tecnologica. La corretta considerazione dei rischi di matrice tecnologica all’interno dei processi di gestione del rischio aziendale è funzionale, tra l’altro, a una più salda tutela della stabilità del business e dell’immagine dell’intermediario. Positive ricadute potrebbero esserci anche per il sistema economico nel suo complesso in termini delle maggiori opportunità di introdurre innovazioni nei processi interni e nei servizi forniti alla clientela derivanti da un framework di controllo del Rischio Informatico più rigoroso e maturo.24
Nell’ambito del processo dell’analisi dei rischi, assume particolare rilievo la definizione di componente critica del sistema informativo, indicata in rapporto alle conseguenze di un eventuale incidente nel sistema informativo che produce danni al regolare e sicuro svolgimento delle funzioni operative importanti. L’intermediario, in sostanza, dovrà, mediante
24Banca d’Italia, Disposizioni di Vigilanza Prudenziale per le banche in materia di Sistema dei Controlli Interni, Sistema Informativo e Continuità Operativa, Relazione sulle analisi di impatto, Giugno 2013.
22
il processo di analisi dei rischi, andare ad individuare quali siano le componenti del sistema informativo che svolgono un ruolo cruciale per la sicurezza delle funzioni operative importanti.
Nella normativa si va quindi a definire quali siano le fasi procedurali dell’Analisi del Rischio: La valutazione del Rischio Potenziale, cui sono esposte le risorse informatiche esaminate e riguarda quindi tutte le iniziative di sviluppo di nuovi progetti che di modifica rilevante del sistema informatico. Nel secondo caso ovviamente si avrà a disposizione anche un dataset storico che individua le informazioni di incidenti di sicurezza informatica verificatisi in passato, (Capitolo 6 paragrafo 4). Si tratta di una fase che prende avvio con la classificazione delle Risorse ICT, opportunamente raccordata con il trattamento delle informazioni non in formato elettronico, al fine di conseguire uniformi livelli di protezione indipendentemente dalle modalità di trattamento. Nel caso della Sicurezza Informatica, ad esempio, si assegnerà un indicatore di criticità in relazione al potenziale impatto di violazione dei livelli di riservatezza, integrità, disponibilità richiesti dall’utente responsabile e alla probabilità di accadimento delle minacce che potrebbero causare tali violazioni;
Il trattamento del rischio, volto ad individuare, se necessario, misure di attenuazione- di tipo tecnico o organizzativo- idonee a contenere il rischio potenziale.
Si ha poi la fase di accettazione formale dell’utente responsabile, dove viene espresso chiaramente anche il rischio residuo almeno in termini qualitativi mediante anche una descrizione non tecnica degli eventi dannosi che si possono verificare in determinate circostanze. Nel caso in cui il rischio residuo ecceda la propensione al rischio informatico, allora si propone l’adozione di misure alternative o ulteriori, quali ad esempio non abilitare funzioni troppo rischiose o acquisire una polizza assicurativa (si tratta rispettivamente di misure definite come risk avoidance e risk transfer). Si prevede inoltre, per le procedure in esercizio, le quali non prevedono una analisi del rischio in fase di sviluppo, una valutazione integrativa per evidenziare eventuali presidi in aggiunta a quelli in essere, richiedendo per questi un ulteriore piano di implementazione. Ovviamente tutto sarà poi valutato ed eventualmente accettato in via formale dall’utente responsabile.
Infine, si arriva alla valutazione dei risultati ottenuti, indicando livelli di classificazione, rischi potenziali, residui, minacce considerate, elenco dei presidi. Tale valutazione viene poi documentata e portata a conoscenza dell’Organo con Funzione di Gestione.
23
Figura 2: il processo circolare di analisi del rischio
Fonte: AbiLab
L’analisi del rischio informatico è dunque un processo ciclico, il quale evidenzia la finalità di operare in termini di gestione del rischio in ottica di continuo aggiornamento sia in ottica di aggiornamento con l’evoluzione tecnologica, sia con riferimento alle informazioni ottenute con le valutazioni passate, al fine di evitare quindi di trovarsi in condizioni di ripetitività di errori di valutazione e/o incapacità di mantenersi aggiornati con l’evoluzione del sistema informatico.
•Espressione del Rischio Residuo; •Valutazione Integrativa per le procedure in esercizio. •Livelli di classificazione; •Rischi Potenziali; •Rischi Residui; •Minacce considerate; •Elenco dei Presidi.
•Individuazione delle Misure di Attenuazione di tipo tecnico o organizzativo •Classificazione Risorse ICT; •Valutazione Sicurezza Informatica con indicatori di Criticità
Valutazione
del Rischio
Potenziale
Trattamento
dei Rischio
Accettazione
Formale
Valutazione
dei Risultati
24
1.4.3 Gestione della sicurezza informatica
Per quanto riguarda l’ambito organizzativo e gestionale della sicurezza informatica, si va a definire mediante la normativa quali sono i soggetti e quali sono i loro compiti. Si tiene conto che, nell’ultimo decennio, la vigilanza ha promosso forme di autoregolamentazione e meccanismi di self regulation, i quali comportano un maggior peso della governance e dei controlli interni, data la necessità di una maggiore adeguatezza organizzativa che porti al saper approntare in modo più rapido possibile le misure necessarie per mitigare le possibili situazioni di underperforming.25 Vengono indicati, quindi: l’Organo con Funzione di Supervisione Strategica, il quale assume la generale responsabilità di indirizzo e controllo del sistema informativo, nell’ottica di un ottimale impiego delle risorse tecnologiche a sostegno delle strategie aziendali (ICT Governance) e, nel caso di full outsourcing, richiede l’intervento di risorse esterne indipendenti dal fornitore; Organo con Funzione di Gestione, il quale ha il compito di assicurare la completezza, l’adeguatezza, la funzionalità ( in termini di efficienza ed efficacia) e l’affidabilità del sistema informativo; Funzione ICT, la quale avrà una organizzazione dipendente da una serie di fattori quali la complessità della struttura societaria, dimensione, settori di attività, strategie di business e gestionali, e si ispira a criteri di funzionalità ed efficienza; l’organo di Sicurezza Informatica, deputata allo svolgimento dei compiti specialistici in materia di sicurezza delle risorse ICT; Revisione Interna, la quale deve disporre delle competenze specialistiche necessarie a svolgere i compiti di assurance attinenti al sistema informativo aziendale. Non va inoltre trascurato il compito del sistema dei controlli interni in merito al controllo del rischio informatico e compliance ICT.
Prendendo nello specifico l’Organo con Funzione di Supervisione Strategica, avendo compiti di definizione delle strategie e delle politiche di gestione del rischio, si occuperà di:
Approvazione delle strategie di sviluppo del sistema informativo, tenendo conto del settore di riferimento e dell’articolazione operativa, prendendo come dato un determinato modello di riferimento per l’architettura del sistema informatico;
Approva le policy di sicurezza informatica, spesso riservandosi la possibilità di avvalersi di soggetti terzi indipendenti (situazione prevista nel caso di full outsourcing);
Approvazione delle linee di indirizzo in merito alla selezione del personale, e in generale acquisizione di sistemi e software, quindi anche fornitori esterni;
25 E. Cenderelli, E. Bruno, Profili Regolamentari dell’Attività Bancaria, Capitolo 7, “Governance e Sistemi di
25
Promuove lo sviluppo, la condivisione e aggiornamento di conoscenze in materia di ICT all’interno dell’azienda;
Viene informato con cadenza almeno annuale per quanto riguarda l’adeguatezza dei servizi erogati, in rapporto ai costi sostenuti; viene invece informato tempestivamente in caso di gravi problemi per l’attività aziendale derivanti da incidenti e malfunzionamenti del sistema informativo.
Per quanto riguarda il ruolo di responsabile della supervisione dell’analisi del rischio informativo, lo stesso organo si occuperà anche di:
Approvazione del quadro di riferimento organizzativo e metodologico per l’analisi del rischio informatico, promuovendo l’opportuna valorizzazione dell’informazione su rischio tecnologico all’interno della funzione ICT e l’integrazione con i sistemi di misurazione e gestione dei rischi, tra cui operativi, reputazionali e strategici;
Approva la propensione al rischio informatico;
È informato almeno annualmente sulla situazione di rischio informatico in merito alla propensione al rischio.
Per quanto riguarda l’Organo con Funzione di Gestione, si parla di un Organo con competenze tecnico- manageriali in base alla dimensione, complessità e articolazione organizzativa dell’intermediario, nonché delle strategie di sourcing; si occupa infatti di una serie di compiti molto specifici, derivanti dal fatto che si occupa di definire le attività necessarie per il conseguimento degli obiettivi preposti dall’Organo con Funzione di Supervisione Strategica, quali:
Definisce la struttura organizzativa della funzione ICT;
Definisce l’assetto organizzativo per l’analisi del rischio informatico;
Approva il disegno dei processi di gestione del sistema informativo, garantendo l’efficacia e efficienza dell’impianto, tranne nel caso del full outsourcing;
Approva gli standard di Data Governance, le procedure di gestione dei cambiamenti e degli incidenti;
Valuta almeno annualmente le prestazioni della funzione ICT;
Approva almeno annualmente la valutazione del rischio delle componenti critiche nonché la relazione sull’adeguatezza e costi dei servizi ICT;
Monitora il regolare svolgimento dei processi di gestione e controllo dei servizi ICT e pone le idonee misure correttive, ove necessario;
26
Assume decisioni tempestive in merito a gravi incidenti di sicurezza informatica. Per quanto riguarda la funzione ICT, essa:
Garantisce l’unitarietà della visione gestionale e del rischio informatico mediante linee di riporto dirette a livello dell’organo con funzione di gestione; nel caso di gruppo bancario, è possibile che la funzione ICT sia accentrata in una società controllata: ciò comporterà che tale organo si trovi all’interno di essa, tenendo comunque la necessità di canali informativi diretti con l’organo con funzione di gestione della capogruppo, la quale sarà responsabile di seguire la pianificazione delle iniziative ICT, in modo che queste rispondano alle esigenze e strategie del gruppo;
Governa l’evoluzione dell’architettura e l’innovazione tecnologica, le attività di gestione del sistema informativo, essendo responsabile del portafoglio dei progetti informatici; in caso di full outsourcing ci sarà all’interno di tale organo un referente che si occuperà di garantire, monitorando l’operatività dei fornitori, la realizzazione degli opportuni meccanismi di raccordo con le linee di business;
Realizza gli opportuni meccanismi di raccordo con le linee di business, in particolare riguardo le attività di individuazione e pianificazione delle iniziative informatiche.
La funzione di sicurezza informatica analizza, come precedentemente indicato, la sicurezza delle risorse; in particolare, si tratta di un processo di redazione e aggiornamento delle policy di sicurezza e delle istruzioni operative; dovrà assicurare che tra i presidi di sicurezza e le
policy approvate si abbia un certo grado di coerenza, partecipa alla
progettazione/manutenzione/realizzazione dei presidi id sicurezza dei data center, partecipa alla valutazione del rischio potenziale nonché all’individuazione dei presidi di sicurezza, assicura il monitoraggio continuo delle minacce, segue lo svolgimento dei test di sicurezza prima dell’avvio in produzione di un nuovo sistema o di uno modificato. Tenendo conto di questi compiti, è necessario che abbia una certa indipendenza di giudizio, e questa, in base all’ultimo comma, viene assicurata da una adeguata collocazione organizzativa.
