Migliori pratiche per la Threat Intelligence

Molte persone dicono che la Threat Intelligence (TI) è buona, ma poche capiscono come utilizzarla. Ci sono ancora meno persone che sanno quali processi attivare affinché la TI funzioni e porti profitti. Inoltre, un numero trascurabile di persone sa come scegliere un fornitore di feed, dove verificare un indicatore di falsi positivi e se vale la pena bloccare un dominio che un collega ti ha inviato su WhatsApp.

Avevamo due abbonamenti APT commerciali, dieci scambi di informazioni, una dozzina di feed gratuiti e un elenco esteso di nodi di uscita TOR. Avevamo anche utilizzato un paio di reversori potenti, script master Powershell, uno scanner Loki e un abbonamento a pagamento a VirusTotal. Non che un centro di risposta agli incidenti di sicurezza non funzioni senza tutto ciò, ma se si vuole catturare attacchi complessi, bisogna fare tutto il possibile.

Ciò che mi preoccupava particolarmente era la possibile automazione del controllo degli indicatori di compromissione (IOCs). Non c’è nulla di più immorale che l’intelligenza artificiale sostituisca un essere umano in un’attività che richiede pensiero. Tuttavia, mi resi conto che la mia azienda avrebbe affrontato quella sfida prima o poi, poiché il numero dei nostri clienti stava crescendo.

Per diversi anni di attività di TI continua, ho calpestato un mucchio di mine e vorrei fornire alcuni consigli che aiuteranno i principianti a evitare errori comuni.

Suggerimento 1. Non riporre troppe speranze nel rilevamento degli oggetti in base agli hash: la maggior parte del malware è polimorfa oggi

I dati di Threat Intelligence provengono in diversi formati e manifestazioni. Possono includere indirizzi IP di centri di comando e controllo di botnet, indirizzi e-mail coinvolti in campagne di phishing e articoli su tecniche di evasione che i gruppi APT stanno per utilizzare. In poche parole, possono essere diverse cose.

Per sistemare questo pasticcio, David Bianco suggerì di utilizzare ciò che si chiama Pyramid of Pain. Descrive una correlazione tra diversi indicatori che si utilizzano per rilevare un attaccante e la quantità di “dolore” che si causerà all’attaccante se si identifica un IOC specifico.

Ad esempio, se si conosce l’hash MD5 del file maligno, può essere rilevato facilmente e con precisione. Tuttavia, non causerà molto dolore all’attaccante, poiché aggiungere solo 1 bit di informazione a quel file cambierà completamente il suo hash.

Suggerimento 2. Prova a utilizzare gli indicatori che l’attaccante troverà tecnicamente complicati o costosi da cambiare

Anticipando la domanda su come scoprire se un file con un hash specifico esiste nella nostra rete aziendale, dirò il seguente: ci sono diversi modi. Uno dei metodi più semplici è utilizzare una soluzione che mantiene il database degli hash MD5 di tutti i file eseguibili all’interno dell’azienda.

Torniamo alla Pyramid of Pain. A differenza del rilevamento tramite valore di hash, è più produttivo identificare le TTP (tattiche, tecniche e procedure) dell’attaccante. Ciò è più difficile da fare e richiede più sforzi, ma si causerà più dolore all’avversario.

Ad esempio, se si sa che il gruppo APT che si dirige verso il nostro settore dell’economia invia e-mail di phishing con allegati *.HTA, creare una regola di rilevamento che cerchi tali allegati di posta elettronica colpirà l’attaccante sotto la cintura. Dovranno modificare la tattica di spamming e forse spendere soldi per acquistare exploit 0-day o 1-day che non sono economici.

Suggerimento 3. Non riporre troppe speranze nelle regole di rilevamento create da qualcun altro, poiché è necessario controllare queste regole per falsi positivi e regolarle

Quando si inizia a creare regole di rilevamento, c’è sempre la tentazione di utilizzare quelle già disponibili. Sigma è un esempio di repository gratuito. È un formato di metodi di rilevamento indipendente da SIEM che consente di tradurre regole da Sigma a ElasticSearch, nonché regole Splunk o ArcSight. Il repository include centinaia di regole. Sembra una grande cosa, ma il diavolo, come sempre, è nei dettagli.

Vediamo una delle regole di rilevamento di mimikatz. Questa regola rileva processi che hanno tentato di leggere la memoria del processo lsass.exe. Mimikatz lo fa quando tenta di ottenere hash NTLM, e la regola identificherà il malware.

Tuttavia, è fondamentale per noi – esperti che non solo rilevano ma anche rispondono agli incidenti – assicurarci che si tratti effettivamente di un attaccante malintenzionato. Purtroppo, ci sono numerosi processi legittimi che leggono la memoria di lsass.exe (ad esempio, alcuni strumenti antivirus). Pertanto, in uno scenario reale, una regola del genere causerà più falsi positivi che benefici.

Non voglio accusare nessuno a questo riguardo – tutte le soluzioni generano falsi positivi; è normale. Tuttavia, gli specialisti di Threat Intelligence devono capire che il controllo e la regolazione delle regole ottenute da fonti aperte e chiuse sono ancora necessari.

Suggerimento 4. Controllare i nomi di dominio e gli indirizzi IP per comportamento maligno non solo nel server proxy e nel firewall, ma anche nei log del server DNS – e assicurarsi di concentrarsi sia sui tentativi di risoluzione riusciti che su quelli falliti

I nomi di dominio e gli indirizzi IP maligni sono gli indicatori ottimali dal punto di vista della semplicità di rilevamento e della quantità di dolore che si infligge all’attaccante. Tuttavia, appaiono facili da gestire solo a prima vista. Almeno, dovresti chiederti dove prendere il log del dominio.

Se si limita il proprio lavoro al controllo dei log del server proxy solo, si può perdere il codice maligno che tenta di interrogare la rete direttamente o richiede un nome di dominio non esistente generato con DGA, per non parlare del tunneling DNS – nessuno di questi sarà elencato nei log del server proxy aziendale. I criminali possono anche utilizzare servizi VPN con funzionalità avanzate o creare tunnel personalizzati.

Suggerimento 5. Monitorare o bloccare – decidere quale opzione scegliere solo dopo aver scoperto che tipo di indicatore si è scoperto e aver riconosciuto le possibili conseguenze del blocco

Ogni esperto di sicurezza IT ha affrontato un dilemma non banale: bloccare una minaccia o monitorarne il comportamento e iniziare a indagare una volta che scatena allarmi. Alcune istruzioni incoraggiano senza ambiguità a scegliere il blocco, ma a volte farlo è un errore.

Se l’indicatore di compromissione è un nome di dominio utilizzato da un gruppo APT, non bloccarlo – inizia a monitorarlo invece. Le tattiche attuali di attacchi mirati presuppongono la presenza di un canale di connessione segreto aggiuntivo, come ad esempio app di tracciamento cellulare che possono essere scoperti solo attraverso un’analisi approfondita. Il blocco automatico ti impedirà di trovare quel canale in questo scenario; inoltre, gli avversari si renderanno rapidamente conto che hai notato le loro manovre.

Al contrario, se l’IOC è un dominio utilizzato da crypto-ransomware, deve essere bloccato immediatamente. Tuttavia, non dimenticare di monitorare tutti i tentativi falliti di interrogare i domini bloccati – la configurazione dell’encoder maligno può includere più URL di server di comando e controllo. Alcuni di essi potrebbero non essere presenti nei feed e quindi non essere bloccati. Prima o poi, l’infezione raggiungerà quei server per ottenere la chiave di cifratura che verrà utilizzata immediatamente per cifrare l’host. L’unico modo affidabile per assicurarsi di aver bloccato tutti i C&C è eseguire il reverse engineering del campione.

Suggerimento 6. Controllare tutti i nuovi indicatori per rilevanza prima di monitorarli o bloccarli

Tieni presente che i dati di minaccia sono generati da esseri umani che sono soggetti a errori, o da algoritmi di apprendimento automatico che non sono infallibili. Ho visto diversi fornitori di report a pagamento sull’attività dei gruppi APT aggiungere accidentalmente campioni legittimi alle liste di hash MD5 maligni. Considerato che anche i report di minaccia a pagamento contengono IOC di bassa qualità, quelli ottenuti tramite intelligence aperta dovrebbero essere verificati per rilevanza. Gli analisti di TI non controllano sempre i propri indicatori per falsi positivi, il che significa che il cliente deve svolgere il lavoro di controllo per loro.

Ad esempio, se hai ottenuto un indirizzo IP utilizzato da una nuova iterazione di TrickBot, prima di utilizzarlo nei tuoi sistemi di rilevamento, dovresti accertarti che non si tratti di un servizio di hosting o di un indirizzo che proviene dal tuo IP. Altrimenti, avrai difficoltà a gestire numerosi falsi positivi ogni volta che gli utenti che visitano un sito web che risiede su quella piattaforma di hosting accedono a pagine web completamente innocue.

Suggerimento 7. Automatizzare tutti i flussi di lavoro dei dati di minaccia al massimo. Inizia con l’automatizzazione completa del controllo dei falsi positivi tramite un elenco di avvertimenti mentre si istruisce il SIEM a monitorare gli IOC che non scatenano falsi positivi

Per evitare un gran numero di falsi positivi relativi all’intelligence e ottenuti da fonti aperte, è possibile eseguire una ricerca preliminare per questi indicatori negli elenchi di avvertimenti. Per creare questi elenchi, è possibile utilizzare i primi 1000 siti web per traffico, gli indirizzi dei sottoreti interni, nonché i domini utilizzati dai principali fornitori di servizi come Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure e altri. È anche una grande idea implementare una soluzione che modifica dinamicamente gli elenchi di avvertimenti composti dai principali domini / indirizzi IP che i dipendenti dell’azienda hanno accesso durante la settimana o il mese scorso.

La creazione di questi elenchi di avvertimenti può essere problematica per un SOC di medie dimensioni, quindi ha senso considerare l’adozione di piattaforme di Threat Intelligence.

Suggerimento 8. Scansionare l’intera azienda per indicatori di host, non solo gli host connessi a SIEM

Di regola, non tutti gli host all’interno di un’azienda sono collegati a SIEM. Pertanto, è impossibile controllarli per un file maligno con un nome o un percorso specifico utilizzando solo la funzionalità standard di SIEM. È possibile risolvere questo problema nei seguenti modi:

1. Utilizzare scanner IOC come Loki. È possibile utilizzare SCCM per avviarlo su tutti gli host dell’azienda e quindi inoltrare i risultati a una cartella di rete condivisa.
2. Utilizzare scanner di vulnerabilità. Alcuni di essi hanno modalità di conformità che consentono di controllare la rete per un file specifico in un percorso specifico.
3. Scrivere uno script Powershell e eseguirlo tramite WinRM.

Come menzionato sopra, questo articolo non è destinato a essere una base di conoscenza completa su come fare la Threat Intelligence nel modo giusto. Tuttavia, a giudicare dalla nostra esperienza, seguire queste semplici regole consentirà ai principianti di evitare errori critici durante la gestione di diversi indicatori di compromissione.