The e-banking antifraud solution
Il software intelligente che protegge
consumatori e banche dagli attacchi
più sofisticati degli hacker
SCENARIO
Frodi on - line
L’aumentare delle transazioni bancarie on-line e il conseguente movimento di denaro che
passa attraverso la rete hanno spostato l’obiettivo della criminalità organizzata dalle rapine
nelle banche alle frodi on-line ugualmente lucrative ma a più basso rischio.
1
SCENARIO
Meccanismi di frode
I meccanismi con cui viene attuata la frode sono i seguenti:
Accesso illecito al conto corrente on-line attraverso:
Furto di Credenziali e successivo utilizzo
Web-in-the-Middle
E successivo trasferimento di denaro attraverso tre tipologie di comportamento:
– Trasferimento su una catena di conti civetta fino al definitivo accredito su
banche estere (spesso attraverso reclutamento on-line dei correntisti, non
sempre in buona fede).
– Ricariche telefoniche multiple e immediato riversamento delle stesse
attraverso numeri telefonici ad alta fatturazione.
– Ricarica di Carte di Credito prepagate e immediato utilizzo per l’acquisto
di beni facilmente rivendibili (oreficeria, elettronica).
2
SCENARIO
Furto di Credenziali e successivo utilizzo
Furto di dati di accesso attraverso il cracking dei Database posseduti dalle
Banche
È il meccanismo più brutale, ma spesso più efficace, permette di ottenere
migliaia di dati di autenticazione in un solo tentativo.
(Ultimo evento noto, 12 Dicembre 2008, 450.000 Account, Germania)
Phishing basato su e-mail
È il primo meccanismo di spionaggio e raccolta delle credenziali di
autenticazione nell’ambito delle Banche on line.
Trojans bancari
Integrano diversi meccanismi per l’acquisizione e l’invio dei dati di accesso:
dai keylogger alla generazione di filmati del movimento del mouse sullo
schermo.
La loro diffusione iniziata quattro anni fa negli ultimi tempi ha raggiunto un
livello critico di penetrazione.
(Circa il 1 % dei PC degli end-user ne è affetto, secondo una valutazione empirica effettuata nel
novembre 2008)
3
SCENARIO
Trojans bancari
I Trojans agiscono trasferendo Utenze, Password e Certificati di Firma Digitale,
ma anche schermate e tutti i caratteri digitati a siti pirati creati per accumulare
questo genere di informazioni.
La lista di questi trojans è lunga e ben documentata anche se la massa dei
navigatori Internet ne è poco informata e gli strumenti antivirus spesso non li
individuano.
Il loro principio di funzionamento non si discosta di molto da quello inaugurato da
Bancos.NL, il primo Trojans fra quelli documentati.
Nelle loro varianti più diffuse rimangono in standby finché il navigatore non si
collega ad uno degli indirizzi elencati all’interno del codice.
A questo punto, quando l’utente naviga su un sito di internet banking, i Trojans si
attivano inviando Utenza e Password e altre informazioni riservate, ai siti pirata
che le raccolgono.
4
SCENARIO
Web-in-the-middle
I Trojan.silentbanker e tutte le successive varianti, colpiscono gli ignari utenti
dei servizi dell’on-line banking; agiscono intercettando le informazioni sul conto
corrente dei clienti prima che vengano codificate e le inviano a un database di
attacco centrale.
Possono intercettare le transazioni bancarie on-line che normalmente sono ben
protette da procedure di autenticazione a due livelli.
Durante una transazione bancaria, Silentbanker sostituisce l'account utente con
l'account dell'hacker, mentre l'utente continua a percepire una normalissima
transazione bancaria.
Poiché gli utenti non sospettano che i loro dati siano stati manipolati,
inconsapevolmente inviano denaro all'account dell'hacker dopo aver avuto
accesso al secondo livello di autenticazione.
5
SCENARIO
Contromisure
La banca non dispone di strumenti per contrastare questo fenomeno.
L’infezione infatti, colpisce i computer dei loro clienti senza che si registri
alcuna anomalia sul server di Internet Banking.
Solamente in alcuni casi da parte della banca viene percepita a livello di
file di log la presenza del malware sul computer dei clienti. Questo
avviene quando il Trojan modifica le pagine del sito per richiedere
informazioni aggiuntive e al server web arrivano campi POST che non
sono presenti nelle transazioni “pulite”. L’analisi di questi campi POST
consente di individuare quale cliente abbia il PC infettato, anche se
resta difficile capire quali azioni successive intraprendere:
a) Avvisare l’utente: c’è il rischio che questa operazione venga da lui
percepita come una lesione alla sua privacy. Potrebbe pensare che la
banca per disporre di questa informazione sia penetrata nel suo PC.
b) Monitorare manualmente l’account in questione per evidenziare
eventuali azioni fraudolente.
6
ANALISI
Analisi di casi reali
Valutando la presenza di questi campi POST aggiuntivi è possibile avere una
stima della percentuale di computer infetti tra i clienti delle banche.
In particolare dal settembre al novembre 2008 analizzando i file di log di alcune
banche nostre clienti, abbiamo stimato che :
Circa lo 0,5% degli utenti è infetto da Trojan.silentbanker.
0,5% delle transazioni possono potenzialmente diventare fraudolente.
Un restante 0,5% sembra affetto da altri Trojans che modificano le pagine di
accesso ma che non siamo riusciti a identificare.
Ampliando la valutazione allo scenario nazionale possiamo calcolare:
• Il numero degli account di on-line banking in Italia è fra i 5 e i 10 milioni e
questo porta a 50.000 potenziali computer infetti.
• Le frodi normalmente vengono effettuate disponendo tre o più bonifici con
importi variabili tra i 2.000 e 5.000 €.
• Il giro di affari di questo tipo di frodi è pari a 300.000.000 di euro.
7
RAKE
La soluzione vincente
Rake consente di individuare comportamenti anomali dell’utenza attraverso
metodologie di clustering e classificazione proprie del Data Mining, come
avviene per i prodotti di fraud detection implementati dai principali gestori di
carte di credito
Monitoraggio automatico dei conti correnti e segnalazione di tutti i movimenti
anomali sulla base di procedimenti di data mining rivolti all’individuazione del
profilo di comportamento di ogni singolo utente;
Clusterizzazione automatica del comportamento degli utenti: permette di
identificarne le abitudini e di riconoscere tutto ciò che si discosta da queste;
Analisi storica dei parametri tipici dell’utente per diminuire la presenza di falsi
positivi aumentando l’efficacia dello strumento stesso.
Questa metodologia ha successo anche nei confronti di nuove tipologie di
malversazione, proprio perché basata sull’analisi del comportamento dell’utente
e non sulla conoscenza del procedimento con cui viene effettuata la frode.
Le frodi già avvenute di cui si conoscono i pattern di comportamento, possono
essere inserite in un secondo step di valutazione per una ulteriore verifica.
8
RAKE
Come funziona
Fase diRaccolta
raccolta
dati dati
Caricamento e mantenimento di un numero di
settimane di operazioni atte a garantire un
numero minimo di transazioni.
Processi di Clustering
I Cluster sono calcolati impiegando
solamente i movimenti relativi agli ultimi 6 mesi
per tenere conto delle abitudini “recenti”.
Su questi movimenti sono valutati i cluster
statistici con l’algoritmo di E.M. (Expectation
Maximization) dopo aver escluso gli Outliers
(gli eventi estranei ai clusters) mediante altri
algoritmi di clustering (OPTICS LOF o
DENCLUE).
Il processo di clustering è effettuato
giornalmente dopo l’acquisizione e
l’elaborazione dei log e i risultati sono salvati
su un secondo DB per migliorare le prestazioni
del sistema
I risultati del clustering sono inseriti nel Db in
modo da effettuare facilmente i confronti tra le
nuove disposizioni e i cluster precalcolati per
dare un peso alle transazioni.
9
RAKE
Come funziona
Meccanismi di Pattern Recognition
Per l’individuare le successioni di eventi che in passato hanno condotto a
malversazioni
Una serie di malversazioni sono avvenute attraverso una serie di bonifici effettuati in giorni consecutivi e
con importi crescenti di 1.000 € l’uno dall’altro. E’ possibile integrare questa conoscenza nei
meccanismi di ricerca delle frodi, ma è necessario prima di tutto effettuare una ricerca degli eventi di
quella natura nella storia pregressa allo scopo di accertarne la reale “pericolosità”.
Se, infatti, risultasse che la predetta successione è un evento molto diffuso e non legato a intenti
fraudolenti, sarebbe inutile ricercarlo tra le nuove operazioni.
Meccanismi di Georeferenziazione IP
Per individuare le variazioni repentine delle località (o dei provider) di accesso
all’Internet Banking.
Questa feature è integrata con l’analisi dei beneficiari (ed eventualmente degli userAgents) per
selezionare i falsi positivi.
Il sistema prevede il controllo dell’IP di provenienza dell’utente verso una blacklist contenente indirizzi
utilizzati dal servizio TOR di anonimizzazione (in fase successiva l’inserimento di altri anonymizer).
10
RAKE
Come funziona
Meccanismi di ricerca anonymizer
Per l’individuare delle transazioni originate da servizi di oscuramento
dell’indirizzo IP
Intelligrate raccoglie gli indirizzi IP dei più importanti servizi di anonimizzazione, come TOR per
esempio, aggiornando RAKE su base giornaliera. In questo modo è possibile valutare la provenienza
delle diverse transazioni, bloccando o valutando negativamente quelle provenientidai suddetti servizi.
Whitelist e Blacklist
Per una eventuale gestione distinta di conti correnti particolari
RAKE supporta l’inserimento in whitelist di particolari account che non si vogliono controllare in alcun
modo e l’inserimento in blacklist di coordinate bancarie, numeri telefonici o numeri di carte ricaricabili
particolarmente sospetti..
11
RAKE
Come funziona
Per la valutazione della “distanza” tra il singolo movimento e il
comportamento usuale sono implementati diversi meccanismi:
Cluster EM
(Expectation Maximization)
Valutazione dell’appartenenza
alla combinazione di distribuzioni
normali individuata dal clustering
E.M. (con pesi diversi a seconda
della distanza dalla media e dai
bordi del cluster).
Questa valutazione viene
effettuata senza effettuare alcuna
rivalutazione dei cluster.
Cluster 2D-GridClustering
Valutazione geometrica della
distanza dai cluster esistenti
utilizzando una versione bidimensionale di algoritmi di
GridClustering.
Anche questa valutazione viene
effettuata senza un ricalcolo dei
cluster.
OPTICS Local Outlier
Detection
Calcolo delle distanze dai
cluster con OPTICS per
valutare l’appartenenza del
singolo evento ai cluster o
l’identificazione come Outlier.
Dall’applicazione dei tre meccanismi si può adottare una politica di “Rapporto di
minoranza” per segnalare l’anomalia e eventualmente, solo nel caso si abbiano tre
positivi, chiamare l’utente.
12
RAKE
Modalità di Applicazione
Rake è disponibile in due diverse modalità di applicazione che possono essere
scelte insieme alla banca in base alla caratteristiche tecniche del e-banking, alla
modalità di interazione con i clienti e alla effettiva necessità di tempestività nelle
operazioni.
Modalità di applicazione On-Line
RAKE è direttamente collegato all’applicativo di e-banking. Ad ogni transazione
viene inviata a RAKE una stringa contenente tutti i dati della transazione stessa e
viene restituito un peso variabile da 0 (transazione OK) a 10 (transazione con una
altissima probabilità di essere una frode). L’applicativo di e-banking può proporre al
cliente una domanda aggiuntiva per verificarne l’autenticità o inviare un SMS di
conferma.
Modalità di applicazione Off-Line
Ogni sera vengono valutate le transazioni della giornata con la produzione di un
report contenente le segnalazioni degli eventi probabilmente fraudolenti che può
essere inoltrato all’help-desk per una verifica telefonica dei più sospetti.
13
RAKE
Modalità di Applicazione On-Line
Nella Modalità On-Line è necessario restituire il peso della transazione in tempi
dell’ordine di un massimo di 1 secondo.
In questa condizione non è possibile effettuare il clustering con tutti gli strumenti
a disposizione, ma è necessario basarsi sui cluster di tipo EM che permettono
una rappresentazione geometrica del risultato e su cluster di tipo GridBased che
permettono un veloce riconoscimento dell’appartenenza ai cluster di ogni nuovo
evento.
Con il clustering EM le nuove operazioni dispositive vengono confrontate quindi
con le ellissi che rappresentano i cluster e ricevono un peso tanto più negativo
quanto sono distanti dal centro dei cluster.
Con il clustering 2D-GC viene valutato se le nuove disposizioni cascano nelle
celle già appartenenti a un cluster o se la loro presenza fa diventare cluster
gruppi di operazioni che non lo erano
14
RAKE
Clustering EM – Prima della Ricerca degli Outlier
15
RAKE
Clustering EM esclusi gli Outlier
16
RAKE
Clustering 2D-GC con 2 punti per cluster
17
RAKE
Clustering 2D-GC con 3 punti per cluster
18
RAKE
Clustering EM – Prima della Ricerca degli Outlier
19
RAKE
Clustering EM esclusi gli Outlier
20
RAKE
Clustering 2D-GC con 2 punti per cluster
21
RAKE
Clustering 2D-GC con 3 punti per cluster
22
RAKE
Modalità di Applicazione OFFLINE
Nella Modalità Off-Line non è necessario rispettare tempi di calcolo ridotti.
E’ possibile quindi effettuare l’analisi completa utilizzando i tre metodi descritti in
precedenza, restituendo dei valori di “probabilità di evento fraudolento” più
precisi.
Il risultato è un report giornaliero che permette agli uffici preposti di indagare
sugli eventi particolarmente sospetti.
23
RAKE
Ricerca degli Outlier
24
RAKE
Outlier individuati
25
RAKE
Ricerca degli Outlier
26
RAKE
Outlier individuati
27
RAKE
Installazione e configurazione
Rake è composto da tre moduli:
Il clusterizzatore, che tiene conto della storia di ogni account, con la lista dei
movimenti, dei beneficiari, degli user-agent e degli IP/provider di collegamento
Il Database che, oltre a mantenere i movimenti e i clusters, attraverso Stored
Procedures produce ogni giorno i report di sospette malversazioni
Il client che fornisce in tempo reale le risposte sul grado di affidabilità di ogni
transazione.
I tre moduli possono essere consolidati su un’unica macchina o distribuiti su
diverse macchine per migliorare le performance.
La componente client può essere replicata e integrata con apparati di load
sharing.
Il prodotto supporta nativamente sia MySQL sia Oracle 11g ma può essere
integrato con DB forniti dal cliente.
28
RAKE
Installazione e configurazione
Rake è fornito sia come applicativo da installare su macchine Unix sia
Solaris sia Linux RedHat, sia come Virtual Appliance per VMware:
CentOS + MySQL
CentOS + Oracle
Solaris 10 + Oracle
Solaris 10 + MySQL
Rake può essere integrato con gli applicativi del cliente e fornito di moduli di
comunicazione ad hoc nel caso sia necessario adattarlo ad ambienti di Internet
Banking particolari.
29
RAKE
Installazione e configurazione
Rake è facilmente amministrabile via interfaccia Web.
La reportistica può essere visualizzata via web o scaricata in formato CSV
o XLS.
Su richiesta del cliente può essere esposta da un Web Service.
Di seguito alcune schermate dell’interfaccia di amministrazione e dei
report.
30
RAKE
Configurazione
31
RAKE
Configurazione
32
RAKE
Configurazione
33
RAKE
Configurazione
34
RAKE
Reportistica
35
RAKE
Reportistica
36
RAKE
GRAZIE!
INTELLIGRATE srl
Via XII OTTOBRE 2/92
16121 GENOVA
ITALY
Phone: +39 0105954161
Fax: +39 010586753
Email: [email protected]
Web: www.intelligrate.it
37