Quando si verifica una violazione dei dati, data breach, o un evento potenzialmente anomalo, la casistica insegna che i tempi di reazione devono essere pressoché immediati.
Il mercato propone numerose soluzioni di difesa e sovente gli slogan pubblicitari ci propinano lo strumento perfetto. La realtà, però, è ben altra, perché è come essere trincerati in un castello mentre si è tempestati di attacchi da ogni lato. Pertanto sarebbe meglio dire che occorre attrezzarsi per limitare i danni, perché la sicurezza assoluta è mera utopia.
Lo scopo è stare nel nostro castello sapendo che potranno danneggiarlo ma con basse probabilità di espugnarlo.
La sicurezza assoluta non esiste
I progressi nella tecnologia hanno notevolmente migliorato la capacità di bloccare minacce, rilevare anomalie, fino alla prevenzione dei danni causati dalle superficialità degli utenti. Il problema è che non esiste lo strumento “principe” e la cyber security consiste nel mettere insieme un puzzle di soluzioni. Per esperienza personale posso dire che la fase preparatoria è più complicata di quella realizzativa ed operativa. La sicurezza non a caso richiede un costante esercizio di analisi. Si è sommersi da centinaia, migliaia, e negli ambienti enterprise anche di milioni di alert, variabili, anomalie, dati illeggibili e di un eccesso d’informazioni. La realtà insegna che nell’oceano sconfinato della rete, l’individuazione dell’evento minaccioso consiste nel trovare l’ago in un enorme pagliaio.
Ma torniamo al puzzle, ovvero al complicato ma essenziale incastro di soluzioni il cui risultato finale è la lente d’ingrandimento sui soli eventi degni della nostra attenzione. Si parte dal presupposto che l’azienda abbia la consapevolezza, volontà e budget per il conseguimento dell’obiettivo. Diamo inoltre per scontato che: sappiamo quali e dove sono i dati che vogliamo monitorare, le policies e le regole minime di sicurezza, e chi è autorizzato ad accedere alla informazioni sensibili.
Stiamo quindi limitando il discorso alla sicurezza intesa come protezione dei dati.
Il security information and event management
Per prima cosa dobbiamo far convogliare tutti gli eventi di sicurezza in un unico punto. Il security information and event management (SIEM) svolgerà il compito di raccolta e revisione centralizzata degli eventi. Abbiamo quello che ci serve? No, siamo solo agli inizi. I SIEM conservano gli eventi in un unico contenitore, garantiscono la compliance, conservano log ed altre fonti dati utili per le attività di analisi. Tuttavia, i SIEM non tengono conto del comportamento e delle interazioni dell’utente; non entrano nel merito della tipologia e delle relazioni tra i database, applicazioni e flussi, a meno di implementare un numero sconfinato di regole ed indicatori. Anche dedicando eserciti di persone alla lettura e consultazione di questa biblioteca, correremo comunque il rischio di non carpire l’evento minaccioso. Una soluzione tampone? Utilizzare il nostro SIEM correlando gli eventi con tutte le informazioni utili possibili.
Due esempi di correlation
Se A > fa azione B > su C > invia alert
Se A > si collega alla macchina X > se dalla macchina X va sulla macchina C > invia alert
Ammesso e concesso che gli alert di sicurezza derivanti dalla correlation saranno pochi, ci riferiamo ad alcune tra le migliaia di possibilità. In altre parole, è difficile generalizzare e standardizzare le casistiche, a meno di creare continuamente nuove regole su eventi specifici, ma con il rischio di annegare in falsi positivi. La correlation sul SIEM va pertanto considerata un filtro ed un aggregatore di eventi e nient’altro.
Ora che gli eventi sono filtrati, correlati ed aggregati possiamo essere soddisfatti? No, per niente. La ricerca dell’ago nel pagliaio è ancora un sogno perché navighiamo ancora in acque torbide.
Al SIEM possiamo aggiungere in parallelo il Machine Learning. Il ML possiamo definirlo come un approccio alla vera e propria Intelligenza Artificiale (AI), che utilizza un sistema in grado di apprendere dall’esperienza, perché capace di riconoscere modelli usando esempi anziché programmandoli. Dopo un periodo di autoapprendimento, tra le due e le quattro settimane, l’algoritmo segnalerà tutti i casi potenzialmente anomali, ovvero quelli che si discosteranno dai suddetti modelli. Sarebbe buona norma far confluire queste segnalazioni nel SIEM, tenendo conto che ad ogni segnalazione il ML attribuisce una descrizione ed indicatore che varia in base a quale fornitore ci siamo rivolti. Il ML consente la raccolta ed l’analisi di enormi volumi di dati che sarebbe altrimenti impossibile da fare utilizzando i mezzi tradizionali.
Limiti e vantaggi del machine learning
E’ probabilisticamente più semplice trovare l’ago nel pagliaio con il Machine Learning piuttosto che con il SIEM.
Ma non è tutto oro quello che luccica. Qual è uno dei limiti del ML? La quantità di falsi positivi al crescere dei dati analizzati. Gli amministratori sono chiamati ad usare parte del proprio tempo a filtrare eventi segnalati come dannosi ma che in realtà non lo sono. Tali azioni sono propedeutiche ad accrescere l’apprendimento dell’algoritmo, ma la dinamicità delle casistiche tipiche di ambienti vasti ed eterogenei comporta, almeno per il momento, un costante dialogo tra l’uomo e la macchina.
L’uso congiunto del Siem per la detection in real time basata su regole e correlation, con l’UEBA (User & Entity Behavior Analytics) basato su algoritmi di machine learning non supervisionati, di fatto è la metodologia di monitoraggio più affidabile e dinamica. Cosa s’intende per UEBA? E’ un tipo di processo in parte già spiegato che in altri termini, crea un modello sul ‘normale’ comportamento degli utenti ed entità (oggetti), e da quel momento in poi evidenzierà tutti gli eventi che non rientreranno in tale schema. Se ad esempio, un utente accede a determinate informazioni in una modalità mai avvenuta prima, presumibilmente l’algoritmo dovrebbe subito alzare una bandierina. Questo è un caso ‘semplice’, ma l’obiettivo è cogliere le attività più raffinate e nascoste. L’algoritmo in questione è di tipo non supervisionato o unsupervised learning, ed estrae una regola o modello che raggruppa e classifica gli eventi secondo caratteristiche che ricava dai dati stessi. Ciò senza una base dati classificati ed etichettati in precedenza.
In linea generale, soprattutto in presenza di quantità imponenti di Big Data, il Machine Learning ha il merito della quasi totalità delle threat detection. In senso più ampio UEBA rileva anomalie usando una varietà di approcci analitici e combinati tra loro; come modelli statistici, il machine learning stesso, regole e policy di base.
La difficoltà nel trovare l’ago nel pagliaio è rappresentata dalla somma tra quantità di log generati, fonti IT e non IT da correlare (es. HR information, Network data ecc ecc) gravata dal livello di complessità degli ultimi attacchi, che di fatto costringe ad implementare algoritmi sempre più sofisticati.
Il futuro? Probabilmente ci sarà un pressoché totale abbandono delle rules, a vantaggio di un monitoraggio ed analisi di tipo euristica. Ad ogni evento indicato come malevolo dal ML, sarà attribuito un punteggio di rischio su una scala da zero (non rischioso) a 100 (molto rischioso).
Questo con buone probabilità è e sarà il modus operandi più idoneo nel ridurre il rumore di fondo, quella paglia nella quale si nasconderà il temibile ago.
