Splunk Garante Banche

Provvedimento del 12 maggio 2011 del Garante per la Privacy
in materia di circolazione delle informazioni in ambito
bancario e di tracciamento delle operazioni bancarie
Splunk>
La soluzione più semplice per adeguarsi al Provvedimento:
gestire i log, implementare gli alert, supportare l’audit
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
Copyright CS InIT srl – Settembre 2012
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.
www.csinit.it
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
(www.garanteprivacy.it/garante/doc.jsp?ID=1813953).
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.
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
Copyright CS InIT srl – Settembre 2012
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.
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.
www.csinit.it
Scadenza
supporti di archiviazione dati.
Le misure necessarie devono essere adottate dalle banche
entro 30 mesi dalla pubblicazione, ovvero entro la fine del
2013.
Osservazioni 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 2013.
2. 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.
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.
Con Splunk è possibile gestire tutti gli aspetti legati ai
punti 2 (gestione dei log) e 3 (alert e audit), descritti in
precedenza al 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’helpdesk.
Gestione dei log
Con Splunk e CS InIT la soluzione operativa per
il Provvedimento
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
Copyright CS InIT srl – Settembre 2012
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 è
www.csinit.it
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=123456” 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=123456” 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, Splunk è in grado di 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.
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.
Copyright CS InIT srl – Settembre 2012
Interfaccia Utente
L’interfaccia web di Splunk è intuitiva e facilmente
utilizzabile in quanto costruita sul modello dei motori di
ricerca internet. E’ personalizzabile e ad ogni utente può
essere assegnato l’accesso ad una singola porzione di dati.
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.
CS InIT è il distributore italiano di Splunk.
Mission di CS InIT è la ricerca di soluzioni software
innovative per migliorare la gestione dei data center,
riducendo i costi di esercizio e migliorando la qualità
del servizio. Per informazioni:
[email protected]
www.csinit.it
www.splunk.com
www.csinit.it