🥇Creazione di un sistema automatico di difesa dagli attaccanti sul sito (frodi)

Negli ultimi sei mesi, mi sono dedicato alla creazione di un sistema per combattere le frodi (fraudulent activity, fraud, etc.) senza alcuna infrastruttura iniziale. Le idee che abbiamo trovato e implementato nel nostro sistema ci aiutano a rilevare molte attività fraudolente e ad analizzarle. In questo articolo, vorrei condividere i principi che abbiamo seguito e cosa abbiamo fatto per raggiungere lo stato attuale del nostro sistema, senza entrare nei dettagli tecnici.

Principi del nostro sistema

Quando si sentono termini come "automatico" e "frode", si inizia probabilmente a pensare a machine learning, Apache Spark, Hadoop, Python, Airflow e ad altre tecnologie dell'ecosistema Apache Foundation e del campo della Data Science. Tuttavia, c'è un aspetto dell'utilizzo di questi strumenti che di solito non viene menzionato: richiedono determinate condizioni preliminari nel vostro sistema aziendale prima di poterli utilizzare. In breve, è necessaria una piattaforma di dati aziendale che comprenda un lago di dati e un repository. Ma cosa succede se non si dispone di tale piattaforma e si desidera comunque sviluppare questa pratica? I seguenti principi, di cui parlerò di seguito, ci hanno aiutato a raggiungere un punto in cui possiamo concentrarci sul migliorare le nostre idee piuttosto che sulla ricerca di una soluzione funzionante. Tuttavia, non è un "traguardo" del progetto. Ci sono ancora molte cose da considerare dal punto di vista tecnologico e di prodotto.

Principio 1: valore per il business prima di tutto

Al centro di tutti i nostri sforzi abbiamo posto il "valore per il business". In generale, qualsiasi sistema di analisi automatica appartiene a un gruppo di sistemi complessi con un alto livello di automazione e complessità tecnica. Creare una soluzione completa richiederà molto tempo se la si costruisce da zero. Abbiamo deciso di mettere al primo posto il valore per il business e al secondo la completezza tecnologica. Nella vita reale, questo significa che non accettiamo le tecnologie avanzate come dogma. Scegliamo la tecnologia che funziona meglio per noi in questo momento. Con il passare del tempo, potrebbe sembrare che dobbiamo reinventare alcuni moduli. Questo è un compromesso che abbiamo accettato.

Principio 2: Intelligenza aumentata

Scommetto che la maggior parte delle persone che non sono profondamente coinvolte nello sviluppo di soluzioni di apprendimento automatico possa pensare che la sostituzione delle persone sia l'obiettivo. In realtà, le soluzioni di apprendimento automatico sono lontane dalla perfezione e solo in alcune aree è possibile la sostituzione. Abbiamo rigettato questa idea sin dall'inizio per vari motivi: dati sbilanciati sulle frodi e l'impossibilità di fornire un elenco esaustivo delle funzionalità per i modelli di apprendimento automatico. Al contrario, abbiamo optato per un'opzione di intelligenza aumentata. Questa è una concezione alternativa dell'intelligenza artificiale che si concentra sul ruolo di supporto dell'IA, sottolineando il fatto che le tecnologie cognitive sono destinate a migliorare l'intelligenza umana, piuttosto che sostituirla. [1]

Tenendo conto di ciò, lo sviluppo di una soluzione completa di apprendimento automatico fin dall'inizio richiederebbe enormi sforzi, che ritarderebbero la creazione di valore per la nostra azienda. Abbiamo deciso di costruire un sistema con un aspetto di apprendimento automatico in crescita iterativa sotto la guida dei nostri esperti di dominio. La parte complessa dello sviluppo di un tale sistema è che deve fornire ai nostri analisti casi non solo in termini di se si tratti di attività fraudolente o meno. In generale, qualsiasi anomalia nel comportamento dei clienti è un caso sospetto che gli specialisti devono indagare e su cui devono reagire in qualche modo. Solo una parte di questi casi registrati può effettivamente rientrare nella categoria della frode.

Principio 3: piattaforma di analisi dei dati estesa

La parte più complessa del nostro sistema è il flusso di verifica del processo. Analisti e sviluppatori devono facilmente accedere a set di dati storici con tutte le metriche utilizzate per l'analisi. Inoltre, la piattaforma dati deve offrire un modo semplice per integrare nuove metriche a un set di indicatori esistente. I processi che creiamo, non solo quelli software, devono consentire di ricalcolare facilmente i periodi precedenti, aggiungere nuove metriche e modificare le previsioni dei dati. Potremmo farlo accumulando tutti i dati generati dal nostro sistema produttivo. In tal caso, i dati sarebbero diventati gradualmente un ostacolo. Dovremmo affrontare un volume crescente di dati non utilizzati e proteggerli. In uno scenario simile, nel tempo, i dati diventerebbero sempre più irrilevanti, ma richiederebbero comunque il nostro intervento per la gestione. Per noi, l'accumulo di dati non aveva senso, quindi abbiamo deciso di adottare un approccio diverso. Abbiamo scelto di organizzare magazzini di dati in tempo reale attorno a entità target che vogliamo classificare, conservando solo i dati che consentono di verificare i periodi più recenti e rilevanti. La complessità di questi sforzi deriva dal fatto che il nostro sistema è eterogeneo, con più magazzini di dati e moduli software che richiedono una pianificazione accurata per un funzionamento coerente.

Concetti costruttivi del nostro sistema

Abbiamo quattro componenti principali nel nostro sistema: sistema di acquisizione (ingestion system), elaborazione (computational), analisi (BI analysis) e sistema di tracciamento (tracking system). Questi servono scopi specifici e isolati, e li manteniamo isolati seguendo approcci definiti nello sviluppo.

Design basato su contratti

In primo luogo, abbiamo concordato che i componenti devono fare affidamento solo su determinate strutture dati (contratti) che vengono scambiate tra di loro. Questo consente un'integrazione semplice e non impone una composizione (e un ordine) specifici dei componenti. Ad esempio, in alcuni casi, ci consente di integrare direttamente il sistema di ricezione con il sistema di tracciamento degli avvisi. In tal caso, ciò avverrà secondo il contratto concordato per le notifiche. Questo significa che entrambi i componenti saranno integrati utilizzando un contratto che può essere utilizzato da qualsiasi altro componente. Non aggiungeremo un contratto aggiuntivo per l'inserimento degli avvisi nel sistema di tracciamento dal sistema di input. Questo approccio richiede l'uso di un numero minimo di contratti predefiniti e semplifica il sistema e le comunicazioni. Fondamentalmente, utilizziamo un approccio chiamato «Contract First Design» e lo applichiamo ai contratti di streaming dei dati. [2]

Streaming ovunque

La gestione e il mantenimento dello stato in un sistema comporterà inevitabilmente complessità nella sua implementazione. In generale, lo stato deve essere accessibile da qualsiasi componente, deve essere coerente e fornire il valore più aggiornato per tutti i componenti, e deve essere affidabile con i valori corretti. Inoltre, avere chiamate a uno storage permanente per ottenere l'ultimo stato aumenterà il numero di operazioni di input/output e la complessità degli algoritmi utilizzati nei nostri pipeline in tempo reale. Per questo motivo, abbiamo deciso di eliminare completamente la memorizzazione dello stato dal nostro sistema, quando possibile. Questo approccio richiede di includere tutti i dati necessari nel blocco di dati trasmesso (messaggio). Ad esempio, se dobbiamo calcolare il totale di alcune osservazioni (numero di operazioni o casi con determinate caratteristiche), lo calcoliamo in memoria e generiamo un flusso di tali valori. I moduli dipendenti utilizzeranno la partizione e il batch per suddividere il flusso in entità e lavorare con gli ultimi valori. Questo approccio ha eliminato la necessità di avere uno storage di disco permanente per tali dati. Il nostro sistema utilizza Kafka come broker di messaggi e può essere utilizzato come database con KSQL. [3] Tuttavia, il suo utilizzo legerebbe fortemente la nostra soluzione a Kafka e abbiamo deciso di non utilizzarlo. L'approccio scelto ci consente di sostituire Kafka con un altro broker di messaggi senza gravi modifiche interne al sistema.

Questo concetto non implica che non utilizziamo storage e database. Per verificare e analizzare le performance del sistema, è necessario memorizzare su disco una parte significativa dei dati che rappresentano vari indicatori e stati. Un punto importante è che gli algoritmi in tempo reale non dipendono da tali dati. Nella maggior parte dei casi, utilizziamo dati memorizzati per analisi autonome, debugging e monitoraggio di casi specifici e risultati forniti dal sistema.

Problemi del nostro sistema

Ci sono alcuni problemi che abbiamo risolto fino a un certo livello, ma richiedono soluzioni più elaborate. Al momento, vorrei semplicemente menzionarli qui, poiché ogni punto merita un articolo a parte.

Abbiamo ancora bisogno di definire processi e politiche che facilitino l'accumulo di dati significativi e pertinenti per la nostra analisi automatica, la rilevazione e l'indagine dei dati.
L'integrazione dei risultati dell'analisi umana nel processo di configurazione automatica del sistema per il suo aggiornamento con i dati più recenti. Questo non riguarda solo l'aggiornamento del nostro modello, ma anche l'ottimizzazione dei processi e il miglioramento della comprensione dei nostri dati.
Trovare un equilibrio tra l'approccio deterministico IF-ELSE e il ML. Qualcuno ha detto: 'Il ML è uno strumento per i disperati'. Ciò significa che vorrete utilizzare il ML quando non sapete più come ottimizzare e migliorare i vostri algoritmi. D'altra parte, l'approccio deterministico non consente di rilevare anomalie che non sono state previste.
Abbiamo bisogno di un modo semplice per testare le nostre ipotesi o le correlazioni tra le metriche nei dati.
Il sistema deve avere diversi livelli di risultati veri positivi (true positive). I casi di frode rappresentano solo una parte di tutti i casi che possono essere considerati positivi per il sistema. Ad esempio, gli analisti vogliono ricevere tutti i casi sospetti per una verifica, e solo una piccola parte di essi rappresenta frode. Il sistema deve fornire agli analisti tutti i casi in modo efficace, indipendentemente dal fatto che si tratti di frode reale o semplicemente di comportamento sospetto.
La piattaforma dati deve consentire di ottenere set di dati per periodi passati con calcoli creati e calcolati al volo.
Distribuzione semplice e automatica di qualsiasi componente del sistema in almeno tre ambienti diversi: produzione, sperimentale (beta) e per sviluppatori.
E last but not least. Dobbiamo creare una piattaforma estesa per il testing delle performance, su cui possiamo analizzare i nostri modelli. [4]