Cyber threat intelligence come abilitatore nelle attività di cyber protection

Cyber threat intelligence come abilitatore nelle attività di cyber protection

58CYBER CRIME CONFERENCE 2017 - ATTI DEL CONVEGNO

Oggi non vi farò vedere tecnologie e soluzioni, né mi prolungherò sulle tipologie di nuove minacce, perché credo che oggi siate stati sufficientemente “bersagliati”, permettetemi una slide di premessa per un concetto che mi interessa trasferirvi, ovvero le tempistiche tra le infezioni, i data breach e la detection.

Secondo una serie di report, ad esempio il DBIR di Verizon (ma ce ne sono anche altri), la linea verde che vedete in alto è il tempo di compromissione, giorni o meno di giorni. Nell’84% dei casi abbiamo una compromissione in giorni o meno di giorni: le infezioni in secondi o minuti, l’exfiltration in giorni o poco più. Per la parte di detection, invece, abbia-mo la linea azzurra, ovvero secondo le statistiche solo nel 25% dei casi ce ne accorgiamo in giorni o meno di giorni.

C’è quindi un chiaro gap tra la parte di tempistiche di infezione o di data exfiltration rispetto a quando ce ne accorgiamo in termini di organizzazione. Questa tempistica può variare e ha una forchetta che in alcuni casi porta addirittura 80-200 giorni. Ovviamente sono troppi, è un tempo troppo elevato. E’ chiaro che questo porta al tema di oggi sulla cyber threat intelligence e quindi come un approccio c.d. intelligence driven può ridurre questo gap e fare in modo che oltre ad avere una buona situation awareness - quindi una conoscenza del contesto, di cosa succede a livello internazionale, ovviamente a livello cyber, ma anche all’interno della propria organizzazione – sia possibile accelerare quei processi di detection e fare in modo che questa tempistica sia ridotta il più possibile.

Ma di solito come avviene l’attività cosiddetta cyber threat hunting? Secondo Gartner esistono tre famiglie di approccio.

Una è ipotesi driven, è quella più semplice ed utilizzata. Per esempio, c’è un’ipotesi di un attacco, c’è un attacco che è uscito sui giornali o una nuova vulnerabilità. Si comincia ad ipotizzare se quel-la vulnerabilità è applicabile o meno, quell’attacco può essere applicabile o meno all’interno della propria organizzazione. Si fanno delle analisi, del-le riunioni, approfondimenti tecnici etc.

Altro approccio è il cosiddetto IoC driven, cioè avere degli indicatori di compromissione che sono ovviamente più tecnici e sono per esempio gli indirizzi IP, possiamo avere gli IP delle macchine dove la exfiltration va a puntare, il command & control, possiamo avere degli hash, possiamo avere tutta una serie di informazioni un po’ più tecniche rispetto all’attacco.

Il terzo è security analytics, quindi utilizzare piat-taforme, tecnologie o data mining per aiutare a fare detection.

È chiaro che non sono tre famiglie separate, almeno le prime due che ho nominato, si usano spesso insieme, ovviamente. La terza dipende dalla maturità dell’azienda o dell’organizzazione. Ma che cos’è la cyber threat intelligence? Noi conosciamo, o più o meno abbiamo una conoscenza di quella che è la intelligence, l’intelligence tradizionale, quella diciamo più istituzionale. La cyber threat intelligence è un knowledge, una conoscenza di meccanismi, di indicatori, di con-testi, di minacce sia esistenti che emergenti, che possono andare ad attaccare i nostri asset tangibili o specialmente intangibili, come per esempio i dati.

È chiaro che la cyber threat intelligence deve con-sentire di contestualizzare la minaccia all’interno della propria organizzazione, deve essere tempestiva, c’è un discorso di tempistiche, di timeline come ho cercando di dire nelle slide precedenti, deve essere comunque accurata e ha tutta una serie di “profili problematici”.

Abbiamo sicuramente un problema di linguaggi e di standard, non esiste un unico standard, ne parlerò anche un po’ dopo, e ci devono essere una serie di obiettivi, cioè dovrò conoscere quel-li che possono essere gli attori, i bad actors, s’è n’è parlato tanto oggi, quali sono le campagne e i TTP e quali possono essere degli indicatori di compromissione.

Qual è l’errore che si fa, o uno degli errori che si fa? E’ confondere i threat data con la threat intelligence. Cioè, se io ho un dump di informazioni su una compromissione generica di un ATM - facendo un esempio bancario - e ho 20.000 numeri di carte, quello è un dato che può diventa-re un’informazione. Esiste un’escalation tra dato, informazione, intelligence. L’ intelligence risponde a una domanda, ad un problema e non è sol-tanto avere un dato, avere una black list non è intelligence, quello è un dato. E’ chiaro che quel dato lo dovrò contestualizzare all’interno della propria organizzazione. Ma quella vulnerabilità o quel breach è applicabile o non applicabile nella nostra organizzazione? Ma quei dati di cui parlavo prima sono dati che possono essere nel mio contesto rilevante o no? O sono le carte di altri brand, o sono ATM che non usiamo noi, o non abbiamo noi quel software, o che non è applicabile quel malware sui nostri sistemi. Ecco, questa è l’intelligence, è prima di tutto un processo che prende queste informazioni, le analizza, le conte-stualizza e approfondisce per avere una risposta rispetto a una domanda a monte, la cui risposta deve essere chiaramente essere “disseminata” ad un gruppo ristretto di persone.

Quali sono gli scenari d’uso? L’anno scorso, proprio alla Cyber Crime Conference, abbiamo par-lato molto di SOC. In effetti il SOC è probabilmente uno dei mondi più interessanti per applicare la cyber threat intelligence, ma non è l’unico. C’è sicuramente necessità di farli diventare intelligence driven, sono ancora pochi i SOC intelligence driven, ma sicuramente il SOC è “un’interessante palestra” per la cyber threat intelligence. Ma esistono anche altri argomenti: l’antifrode, tutti i temi delle carte, delle carte clonate, l’e-commerce, dipende un po’ da quelle che sono le famose “domande” che ci dobbiamo fare per proteggere i nostri asset e ovviamente può esserci anche una questione organizzativa. In alcuni contesti, per esempio, l’antifrode è dentro il SOC, in altri no.

C’è tutto il mondo dell’anti money laundering, dell’antiriciclaggio. Spesso le frodi, specialmente il phishing, hanno un profilo più “digitale” e un momento invece “analogico”. Ad un certo punto, dopo aver raccolto informazioni con il phishing e avendo fatto una frode informatica, il virtuale deve diventare denaro, questo denaro in un modo dovrò anche renderlo fisico, come si fa di solito con i c.d. “muli”, quindi utilizzando delle teste di legno che si prestano a fare cyber-riciclaggio. Esiste intelligence anche su questo ambito.

L’altro aspetto di cui si è parlato molto negli ultimi anni (non nell’ambito security, più in quello marketing e comunicazione), è quello che si chiama reputation, qualcuno poi l’ha chiamata web-reputation o similare. Sto parlando dei social network, di informazioni sulla rete in generale, quindi, sia surface web che deep web - in particolar modo - per quella che può essere il brand, la sentiment analysis. Anche questo è un mondo interessan-te. Sulla cyber security si sono fatti pochi esercizi perché, come accennato, chi ha trainato il merca-to è stato molto il marketing e la comunicazione su quella che è la brand reputation, quindi la semantica, i topic, e tutta la parte di sentiment legata alla cyber security è abbastanza immatura.

Una cosa, secondo me e secondo altri addetti ai lavori a livello internazionale, è fondamentale fare anche in Italia il cyber threat hunting intelligence driven, ovvero fare in modo che l’intelligence, il knowledge, la conoscenza esterna si fonda a quella che può essere la conoscenza interna delle aziende e delle organizzazioni per far diventare i SOC, quindi, “Intelligence SOC”, la parte frode “Intelligence Antifraud” e tutto il resto, cioè tutto deve essere abilitato da informazioni esterne. Questo consentirà di avere una performance migliore nella detection.

È chiaro che i dati interni ed esterni, unendoli (che noi chiamiamo data fusion), arricchendoli, facendo enrichment consentiranno di lavorare su quelle che possono essere delle regole di detection, per migliorarle e affinarle.

L’atomo della cyber threat intelligence sono i feed. I feed sono le informazioni di base che ci sono sul mercato, ci sono sia open source, sia closed, ci sono sia gratis che a pagamento. Negli interventi precedenti si parlava dei prezzi sul mercato nero. In effetti si compra un po’ di tutto, anche i feed si pagano ovviamente, è una parte importante del mercato. Esistono dei feed free e commerciali ed esistono anche per settore. Ci sono feed scada, la parte ICS quindi per ambiti più industriali, ci sono feed un po’ più performanti sulla parte banking e financial services. Il primo tassello di una cyber threat intelligence sono quindi i feed, però come già detto non dobbiamo confonderli con l’intelligence. Questi sono dati, sono dati massivi, tanti, da gestire, però questa non è ancora intelligence. Ovviamente i feed hanno delle relazioni tra di loro, è chiaro che se ho dei feed sul malware, poi i malware mi possono portare a degli host infetti e quindi a feed per esempio sulla parte di network intelligence, su informazioni di IP che “girano” sul dark web, è chiaro che ci deve essere una correlazione tra le informazioni e anche ovviamente un’analisi, e qui c’è il ruolo dell’analista, quindi del soggetto o dei soggetti che devono poi analizzare con competenza queste informazioni. La situazione in Italia è abbastanza a macchia di leopardo. Un ipotetico maturity model può essere su cinque livelli, i primi quattro sono di tipo tattico e l’ultimo di tipo strategico. Cinque livelli divisi per quattro aree: tool, persone, sorgenti e processi. Possiamo ritrovarci anche molto velocemente in uno di questi. Per esempio possiamo avere il SOC abbiamo CSIRT, o il CERT, però non abbiamo necessariamente un team esperto di cyber threat intelligence. Abbiamo dei feed open source ma non abbiamo dei feed un po’ più tattici, non abbiamo ancora dei portali, o abbiamo dei portali di threat intelligence, ad esempio Threatbook o altri. La situazione non è spesso omogenea.

Il primo passo da fare a mio avviso è quello di farsi una sorta di analisi, anche velocemente, di dove si è posizionati, prima di fare un passaggio progettuale.

È chiaro che le piattaforme di threat intelligence sono piattaforme che hanno una loro complessità, che di solito, ma non necessariamente, sono vendute vuote, non hanno informazioni, o possono avere quelle base, e che quindi consentono l’accesso a dei feed che possono essere open source o a pagamento e che su vari livelli consentono poi l’enrichment da parte di analisti.

Come vi raccontavo prima ci sono differenziazioni di standard, lo standard più utilizzato, lo Stix/taxii, o almeno quello che sta prendendo più piede, e ci sono poi Yara, uno standard più sui malware, c’è una parte dashboarding e reporting e però, la cosa fondamentale, al di là della piattaforma in termini tecnologici, sono i processi che sono intorno alle piattaforme, perché le piattaforme da sole non fanno il lavoro senza l’attività “umana”.

Come vi accennavo il protocollo Stix/taxii è un protocollo che sta prendendo molto piede perché è chiaro che se non standardardizziamo la cyber threat intelligence abbiamo problemi poi a velocizzare l’analisi, cioè, se facciamo soltanto collegamenti con API (quindi un po’ massivi di in-formazioni) si possono avere problemi a contestualizzare se quell’IP è un IP attaccante o un IP infetto perché è un indirizzo IP, chiaramente, allora dovrò contestualizzarlo rispetto a se è un attaccante o un attaccato o uno infetto altro. Per questo motivo si è studiata una standardizzazione che sta avendo abbastanza successo, anche tra gli sviluppatori di piattaforme, per standardizzare i dati in Stix. Questo vuol dire che se ho un server, e sopra avrò i dati in STIX, mi basterà puntare con la piattaforma su quel server e, abbastanza velocemente, questa leggerà i dati nella modalità standard senza molto fine tuning sui dati che si stanno raccogliendo. La parte TAXII invece riguarda il protocollo di comunicazione si-curo, sempre in ambito cyber threat intelligence.

Qual è un possibile approccio della materia? A mio avviso, prima di tutto, oltre il discorso che facevo prima sul maturity model, bisogna capire qual è l’ambito di intervento, perché mi devo por-re delle domande e a quelle domande l’intelligence deve rispondere. Quali sono le mie domande, a quali minacce, a quali processi dovrò poi inserire le azioni di intelligence. A cosa? alla parte di security, alla parte di antifrode, a tutto! Perché ovviamente le domande possono essere molteplici.

Capito il contesto, una prima fase può essere quella di mappare le informazioni interne, i feed esterni per capire rispetto la propria industry ed al proprio settore - ed anche agli ambiti di intervento - quali possono essere i feed più buoni rispetto al vestito che vogliamo fare in modo sartoriale, perché non ci sono feed quattro stagioni, informazioni quattro stagioni, ci sono per settori, però ci sono anche qualità diverse, anche all’interno delle stesse famiglie tecniche.

Altro aspetto da non sottovalutare è la posizione geografica dei fornitori di informazioni. Qui vedete qualche bandierina di qualche nazione perché esistono informazioni che possono fornire i provider israeliani, ci sono informazioni che possono venire dalla Russia, informazioni dalla Cina, oltreché dagli Stati Uniti, e chiaramente siamo in Italia non potevo non mettere anche la nostra Italia.

Ecco, unire queste informazioni tra varie country, tra varie georeferenziazioni di know-how, è a mio avviso un valore aggiunto perché è chiaro che le black list, la parte di reputation, IP reputation o network intelligence, se chiediamo ad esperti cinesi ci danno delle risposte diverse rispetto agli americani, questo è ovvio, e quindi unire informazione e knowledge diversi, fare il data fusion di geografie diverse dall’Italia che, tutto sommato, ci consente di parlare con paesi differenziati, a mio avviso è un valore aggiunto per innalzare di molto il livello di cyber security delle nostre organizzazioni. E’ chiaro che una fase importante poi è la parte di tecnologia a supporto. Capite le in-formazioni le devo maneggiare, per maneggiarle ovviamente devo utilizzare delle piattaforme. In un primo momento si può anche utilizzare una piattaforma di security analitycs o piattaforme Siem di varia natura per dare delle informazioni. Quella però non è ancora intelligence, quello è un arricchimento, va bene per alcune cose, per esempio gli indirizzi IP delle black list, può essere interessante inserirli sicuramente, ma invece con altre cose tipo malware targhettizzato, analisi un po’ più particolari, è chiaro che necessitano di un processo di analisi e di un analista che deve fare delle azioni e poi costruire gli indicatori di compro-missioni IoC da inserire all’interno dell’infrastruttura in un secondo momento. Un altro aspetto importante - come consiglio che cerco di lasciarvi oggi - riguarda il contesto e la conoscenza di sé stessi, un po’ l’ho accennato, ma facciamo una sorta di “recap” e vi do qualche indicazione in più.

Prima di tutto, non esiste una fonte unica di informazioni “overall” che vi può risolvere il problema. Se io uso già questi feed, faccio un nome a caso, “Recorded future”, che sono ottimi. Recorded future cosa fa? cosa ha dentro? che informazioni ha? ma sono le informazioni che ti servono per i tuoi processi, oppure è un primo passo rispetto ad altre informazioni, ad altri feed e ad altri dati che invece puoi inserire e unire insieme a quel-li che hai già preso? Non esiste un’unica fonte, ma le fonti sono differenziate perché è chiaro, si parla knowledge, di conoscenza, la conoscenza non può stare in un solo posto, e ho fatto anche l’esempio della georeferenziazione dei paesi che resta valido.

Altro aspetto, la scelta tecnologica delle piatta-forme dei feed può impattare sui processi. Io posso avere dei processi di cyber threat intelligence esterni, anche a livello organizzativo rispetto al SOC, posso decidere di centralizzare, di fare una struttura dedicata - senza fare nomi di una banca importante italiana che ha fatto questa scelta e che ho incontrato qualche giorno fa - è una scelta interessante, cioè anziché far aumentare le competenze del mio SOC metto un altro team che fa delle azioni e che poi è collegato ai processi del SOC che fa parte di operation, rispetto ad una parte un po’ più particolare che è quella di cyber threat intelligence. È un modo, non c’è un modo giusto, ogni approccio ha vantaggi e svantaggi. L’aspetto infatti del conoscere se stessi è fondamentale perché questa attività ha dei costi abbastanza importanti, ha dei costi che possono essere per i feed, per le piattaforme, organizzativi, per le risorse, per le competenze. Va pianificato un budget, sembra una banalità però è così.

Le informazioni, come ho già detto, servono a poco se non ci sono poi le competenze del poter analizzare per poter costruire intorno a quelle informazioni un qualcosa, un knowledge, una conoscenza per fare detection e per ridurre quella forchetta dei 200 giorni di cui si parlava prima. E poi un altro aspetto è andare a capire se le tecnologie di security sono configurate e gestite nel modo corretto, perché può avvenire che questo approccio proattivo di cyber threat intelligence possa mettere anche un po’ in subbuglio quelle di tuning e dei processi che ci sono nei SOC e nella security, perché può andare a mettere un po’ in discussione dei comportamenti o delle azioni o delle derive comportamentali che a volte capitano quando si sta in un ambito di operation tradizionale. Ecco perché si fa alcune volte la scelta di tenere un team a parte, proprio per questo motivo.