Moviri e Splunk: la soluzione al provvedimento Garante II

Transcript

1 Moviri e Splunk: la soluzione al provvedimento Garante II Approccio per l adeguamento al provvedimento 12/5/11 in materia di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni bancarie In partnership con:

2 I contenuti del Provvedimento Il provvedimento del Garante per la Protezione dei dati personali in materia di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni bancarie, pubblicato sulla GU il 3/6/2011, nasce a seguito di istanze pervenute negli anni al Garante relativamente ad un uso improprio dei dati personali in possesso degli istituti bancari. Tali istanze facevano supporre un accesso indebito ai dati personali da parte di alcuni dipendenti bancari e la comunicazione a terzi di tali dati per un uso in contrasto con le normative in vigore. In considerazione della rilevanza giudiziale di tali comportamenti, il Garante ha disposto un attività istruttoria, in collaborazione con l ABI, per rilevare le scelte organizzative degli Istituti bancari in relazione alla circolazione delle informazioni personali dei clienti. Da tale indagine è risultata l esistenza di diverse forme organizzative e di diverse modalità di trattamento dei dati personali. In particolare è emerso che tutte le banche partecipanti all indagine, nonostante l assenza di disposizioni normative al riguardo, si erano autonomamente dotate di strumenti per tracciare le operazioni dispositive, ma solo alcune erano in grado di tracciare anche le operazioni di inquiry (e per una finestra temporale limitata). Date le premesse, il Garante ha ritenuto opportuno prescrivere alcune misure in ordine a: "tracciamento" degli accessi ai dati bancari dei clienti; tempi di conservazione dei relativi file di log; implementazione di alert volti a rilevare intrusioni o accessi anomali ai dati bancari, tali da configurare eventuali trattamenti illeciti; Nel Provvedimento vengono definite in modo chiaro le norme alle quali devono attenersi le banche per tutelare le informazioni dei propri clienti (effettivi e potenziali). Per ogni interpretazione legale si rimanda al testo completo del Provvedimento.. Nel seguito se ne riassumono gli elementi essenziali, dando particolare evidenza alle attività di adeguamento richieste alle strutture informatiche delle banche. A chi si applica Sono interessate le seguenti organizzazioni, stabilite sul territorio italiano: le banche, indipendenti o facenti parte di un gruppo; le società diverse dalle banche, ma facenti parte di un gruppo bancario, nell ambito dei trattamenti effettuati sui dati personali della clientela; Poste Italiane, limitatamente alle sue funzioni di banca Quali operazioni sono coinvolte Sono interessate tutte le operazioni, dispositive ed interrogative, effettuate sui dati personali della clientela da parte dei dipendenti delle società interessate. Page 2

3 Non si applica alle operazioni effettuate dai clienti stessi (internet banking) e alle operazioni effettuate dai dipendenti in forma aggregata, dalle quali è impossibile risalire ai dati del singolo cliente. Misure prescritte Il Provvedimento definisce alcune misure come necessarie, altre come opportune. Le misure necessarie riguardano la disponibilità dei dati di accesso, la conservazione degli stessi e l audit interno, le misure opportune riguardano l informazione al Garante e agli interessati di ogni comportamento potenzialmente illecito. Nel seguito vengono sviluppate le misure necessarie. Prescrizioni legali Nel caso il trattamento dei dati venga effettuato da una società esterna (outsourcer), sia essa interna o esterna al gruppo, devono essere definiti i ruoli di titolare e di responsabile del trattamento dati, in base alla legislazione vigente e al contratto in essere fra banca e outsourcer. Dall indagine effettuata dal Garante è infatti emerso che non sempre i ruoli sono definiti in modo conforme alla legislazione (punto 3.2 del Provvedimento). Tracciamento delle operazioni Ogni operazione deve essere tracciata e registrata in un apposito log, contenente almeno le seguenti informazioni: il codice identificativo del soggetto incaricato che ha posto in essere l'operazione di accesso; la data e l'ora di esecuzione; il codice della postazione di lavoro utilizzata; il codice del cliente interessato dall'operazione di accesso ai dati bancari da parte dell'incaricato; la tipologia di rapporto contrattuale del cliente a cui si riferisce l'operazione effettuata (es. numero del conto corrente, fido/mutuo, deposito titoli). Di norma le applicazioni bancarie registrano su log ogni operazione e la registrazione comprende un insieme di informazioni più ampio di quello minimo prescritto. In tutti i casi in cui ciò non è vero, le applicazioni dovranno essere modificate e rese conformi al Provvedimento. Conservazione dei log Viene prescritto un periodo minimo di conservazione per le operazioni di inquiry pari a 24 mesi. Page 3

4 Implementazione di alert Le banche devono sviluppare specifici alert che individuino comportamenti anomali o a rischio. Gli strumenti software utilizzati per rilevare i comportamenti anomali devono ricevere i log di tutti gli applicativi utilizzati per gli accessi. Audit interno L audit deve essere effettuato da una unità diversa da quella incaricata del trattamento dei dati. Questa unità ha il compito di controllare che le misure prescritte siano attuate e di effettuare controlli a campione o su eventuali allarmi. Scadenza Le misure necessarie devono essere adottate dalle banche entro 30 mesi dalla pubblicazione, ovvero entro la fine del Implicazioni pratiche L attuazione del provvedimento da parte delle banche si può ricondurre a tre macro-attività: 1. Registrazione su log delle informazioni minime prescritte. E necessario verificare che ogni applicazione rientrante nel provvedimento registri su log le informazioni di accesso. In tutti i casi in cui ciò non è vero è necessario adeguare le applicazioni. Tenuto conto del parco applicativo delle banche, è presumibile che la semplice operazione di verifica richieda tempi significativi, tempi molto maggiori nel caso sia necessario attivare operazioni di adeguamento del codice. E pertanto opportuno che tale attività venga avviata in tempo utile a rispettare la scadenza di fine Gestione dei log. Considerate la numerosità e la complessità delle applicazioni, è presumibile che ciascuna banca debba gestire centinaia o anche migliaia di diversi file di log. Data anche l assenza, nella maggior parte dei casi, di formati standard, è probabile che ciascuna banca debba gestire non solo innumerevoli file, ma anche decine di formati diversi. E essenziale pertanto disporre di uno strumento che semplifichi al massimo l acquisizione di log di formato, dimensione e provenienza diversa. 3. Alert e Audit. L eterogeneità delle sorgenti e la diversa organizzazione di ciascuna banca rende impossibile la realizzazione di una soluzione totalmente out-of-the-box in grado di produrre alert e supportare le funzioni di audit. E però possibile immaginare uno strumento software flessibile ed adattabile alle singole esigenze che in tempi rapidi consenta di raggiungere lo scopo. Page 4

5 Il metodo Moviri per l adeguamento al Provvedimento Moviri è in grado di supportare i clienti sia guidando il processo di adeguamento, sia occupandosi della piattaforma tecnica che implementa tramite Splunk. L approccio Moviri prevede tre fasi di progetto: Fase 1 As-Is Assessment In questa fase si esegue il censimento delle applicazioni bancarie che processano dati sensibili, raccogliendo informazioni di dettaglio sul contenuto del logging infrastrutturale e applicativo già implementato. A valle di questa analisi vengono identificati i change necessari al tracciamento delle informazioni obbligatorie. Fase 2 - Raccolta, indicizzazione e analisi dei log La seconda fase prevede in primo luogo il censimento dei repository di interesse (log, database) e imposta l importazione automatica delle informazioni in Splunk, personalizzando la conservazione del dato in linea con il provvedimento. In seguito, le informazioni importate vengono arricchite tramite una serie di tecniche (tag, lookup e semantiche) per massimizzare l usabilità del dato. Infine si identificano le possibili casistiche «anomale» sui log importati. Fase 3 - Impostazione dashboard, alert, audit Nell ultima fase vengono identificati e profilati in Splunk i diversi livelli di sicurezza e privacy in base ai ruoli (trattamento, audit,..); vengono quindi disegnate e create le maschere di ricerca, le dashboard e i report periodici configurando infine l opportuna allarmistica. Perché Splunk Splunk è la più evoluta soluzione di IT search e log management oggi disponibile: con Splunk è possibile raccogliere, memorizzare, indicizzare, certificare centralmente qualunque tipo, numero e volume di log. Le informazioni memorizzate ed indicizzate possono successivamente essere ricercate nel repository Splunk in modo libero tramite un qualunque browser (con una modalità simile ad un motore di ricerca internet). Splunk ha una architettura robusta, facilmente scalabile, configurabile in alta affidabilità ed integrabile con diversi supporti di archiviazione dati. Page 5

6 Splunk adotta una politica di licenza estremamente flessibile, di facile giustificazione economica ed evoluzione di utilizzo, essendo basata sul volume dei dati memorizzati ed indicizzati (dopo l eventuale applicazione di filtri di esclusione), ed è indipendente dal volume dei dati originali o dal numero di sistemi e applicazioni che generano i log. Attraverso Splunk è possibile gestire tutti gli aspetti legati alla gestione dei log, all alert e audit, descritti nel paragrafo Osservazioni pratiche. Ma è anche possibile andare oltre quanto prescritto, trasformando una necessità di adeguamento normativo, e quindi un costo, in una occasione per valorizzare le informazioni contenute nei log, e quindi in una opportunità di business o di miglioramento dei processi IT. I file di log contengono infatti una enorme quantità di informazioni, usualmente acceduta solo in caso di necessità e con modalità complesse: Splunk permette un accesso intuitivo, immediato e in tempo reale di tutto quanto viene registrato dalle applicazioni, consentendo ad esempio di realizzare applicazioni di monitoraggio per il business o dashboard a supporto dell help-desk. Page 6

7 Gestione dei log La caratteristica principale dei log applicativi è di non avere un formato standard. Questo rende difficile l utilizzo di strumenti che hanno bisogno di normalizzare gli eventi prima di poterli inserire nel proprio repository, ovvero di ricondurre ad uno schema predefinito o formato standard le informazioni contenute nei log applicativi. Splunk non necessita di normalizzazione: qualunque sia il formato del log, Splunk è in grado di acquisire l evento as is, di memorizzarlo nel proprio repository e di permetterne successivamente la ricerca. Splunk riconosce automaticamente gli eventi multi-linea e in molti casi è in grado di associare automaticamente un nome logico (campo) alle informazioni registrate nell evento; quando ciò non può avvenire in automatico è sempre possibile intervenire con una operazione di mappatura per assegnare nomi logici ai dati. A questo proposito, e in riferimento alle informazioni minime che devono essere scritte nei log, è importante specificare che con Splunk lo stesso nome logico può essere assegnato alla stessa informazione, anche se appare con formati diversi in log diversi. Se ad esempio il dipendente viene registrato come UID= nel log di una prima applicazione, e come Operatore=Rossi in una seconda applicazione, è possibile definire come campo di ricerca la voce dipendente, associata a UID in un caso e a Operatore nel secondo caso; le operazioni di alert e audit potranno essere effettuate ad esempio con dipendente=rossi, posta l esistenza di una tabella che permetta di associare UID= all operatore Rossi. Questa caratteristica rende semplici le attività di audit, senza richiedere interventi sulle applicazioni. Il periodo di conservazione può essere definito a piacere: per le operazioni di inquiry verrà impostato ad almeno 24 mesi come prescritto. Alert Nel Provvedimento viene prescritta l attivazione di alert volti ad individuare comportamenti anomali o a rischio. La traduzione del concetto in regole da applicare ai dati viene lasciata alle singole banche, anche in relazione alle diverse forme organizzative rilevate con l indagine. Comportamenti anomali possono essere: interrogazioni su clienti non di propria competenza (ad esempio perché appoggiati su una diversa filiale) interrogazioni frequenti su un cliente da parte di un singolo dipendente interrogazioni al di fuori dell orario di lavoro o da postazioni esterne alla banca utilizzo di credenziali su postazioni interne da parte di dipendenti non in servizio (furto di identità) Qualunque sia l interpretazione del concetto da parte della singola banca, attraverso Splunk è possibile implementare le regole, anche correlando gli eventi provenienti dai log applicativi con informazioni provenienti da data base o altre sorgenti. Anche se il Provvedimento non lo prescrive, l applicazione della regola può essere effettuata in tempo reale, offrendo quindi un valore aggiunto alla funzione di audit. Page 7

8 Audit Le funzioni di audit possono essere esercitate mediante un accesso diretto al repository di Splunk, oppure tramite report predefiniti che possono offrire viste delle interrogazioni, combinando criteri di ricerca quali: dipendente, filiale, postazione di lavoro, cliente. Interfaccia Utente L interfaccia web di Splunk è intuitiva e facilmente utilizzabile in quanto costruita sul modello dei motori di ricerca internet. L attività di Moviri inoltre permette di assegnare ad ogni utente l accesso ad una singola porzione di dati a seconda del ruolo assegnato. Con Splunk la modalità di accesso alle informazioni contenute nei log è uniforme, indipendente dalla piattaforma di origine. I dati sono sempre disponibili per ridurre al minimo i tempi di indagine e di conseguenza migliorare la disponibilità complessiva del servizio. Inalterabilità e Integrità dei dati Splunk prende in carico l evento non appena viene scritto sul file di log, trasferendolo automaticamente sul proprio repository, dove l evento viene indicizzato e certificato. In questo modo si annulla la possibilità che l evento possa essere alterato in modo fraudolento. Per maggior garanzia il repository può essere allocato su un supporto WORM (non riscrivibile). Scalabilità Splunk è installabile su qualunque server Linux, Unix o Windows e facilmente scalabile. Può gestire centinaia di GB al giorno su un singolo server e al crescere delle necessità è sufficiente affiancare uno o più server per costruire un repository distribuito, ma logicamente unitario. Page 8

9 Moviri + Splunk = Successo Moviri e Splunk sono partner di lunga data con comprovata esperienza nel settore bancario. Affidati a un tandem di successo. Moviri è il partner di riferimento per servizi di IT performance. Le principali aree di riferimento in cui opera sono IT Operations, Testing e Analytics. Moviri conduce progetti nel settore bancario con Splunk dal 2009, oltre ad essere Splunk Powered Reseller in Italia. Per informazioni: info@moviri.com CS InIT è il distributore italiano di Splunk. Per informazioni: info@csinit.it Page 9