Suggerimenti sulle best practice per l'intelligence sulle minacce

Molte persone dicono che l'intelligence sulle minacce (TI) ha un buon sapore, ma pochi sanno come cucinarla. Sono ancora meno coloro che sanno quali processi attivare affinché TI funzioni e porti profitto. Inoltre, un numero trascurabile di persone sa come scegliere un fornitore di feed, dove controllare un indicatore di falsi positivi e se vale la pena bloccare un dominio che il tuo collega ti ha inviato su WhatsApp.

Avevamo due abbonamenti APT commerciali, dieci scambi di informazioni, circa una dozzina di feed gratuiti e un ampio elenco di nodi di uscita TOR. Abbiamo utilizzato anche un paio di potenti invertitori, master script Powershell, uno scanner Loki e un abbonamento VirusTotal a pagamento. Non che un centro di risposta agli incidenti di sicurezza non funzionerà senza tutto ciò, ma se sei in grado di catturare attacchi complessi devi andare fino in fondo.

Ciò di cui ero particolarmente preoccupato era la potenziale automazione del controllo degli indicatori di compromissione (IOC). Non c'è niente di così immorale come l'intelligenza artificiale che sostituisce un essere umano in un'attività che richiede pensiero. Tuttavia, mi sono reso conto che prima o poi la mia azienda avrebbe incontrato questa sfida, dato che il numero dei nostri clienti stava crescendo.

Per diversi anni di attività TI permanente, ho calpestato un mucchio di rastrelli e vorrei fornire alcuni suggerimenti che aiuteranno i neofiti a evitare errori comuni.

Suggerimento 1. Non riporre troppe speranze nel catturare elementi tramite hash: la maggior parte dei malware oggigiorno è polimorfica

I dati di Threat Intelligence sono disponibili in diversi formati e manifestazioni. Può includere indirizzi IP dei centri di comando e controllo della botnet, indirizzi e-mail coinvolti campagne di phishinge articoli sulle tecniche di evasione che i gruppi APT stanno per iniziare a sfruttare. Per farla breve, queste possono essere cose diverse.

Per sistemare tutto questo pasticcio, David Bianco ha suggerito di usare quello che viene chiamato il Piramide del dolore. Descrive una correlazione tra i diversi indicatori che usi per rilevare un attaccante e la quantità di "dolore" che causerai all'attaccante se identifichi uno specifico IOC.

Ad esempio, se conosci l'hash MD5 del file dannoso, può essere rilevato facilmente e con precisione. Tuttavia, non causerà molto dolore all'attaccante perché l'aggiunta di solo 1 bit di informazioni a quel file cambierà completamente il suo hash.

Suggerimento 2. Prova a utilizzare gli indicatori che l'aggressore troverà tecnicamente complicati o costosi da modificare

Anticipando la domanda su come scoprire se esiste un file con un determinato hash nella nostra rete aziendale, dirò quanto segue: ci sono diversi modi. Uno dei metodi più semplici consiste nell'utilizzare una soluzione che mantenga il database degli hash MD5 di tutti i file eseguibili all'interno dell'azienda.

Torniamo alla Piramide del Dolore. A differenza del rilevamento tramite un valore hash, è più produttivo identificare il TTP dell'attaccante (tattiche, tecniche e procedure). Questo è più difficile da fare e richiede più sforzi, ma infliggerai più dolore all'avversario.

Ad esempio, se sai che l'equipaggio APT che prende di mira il tuo settore dell'economia sta inviando e-mail di phishing con file *.HTA a bordo, la creazione di una regola di rilevamento che cerchi tali allegati e-mail colpirà l'attaccante sotto la cintura. Dovranno modificare la tattica dello spamming e forse anche spendere qualche soldo per acquistare exploit di 0 giorni o 1 giorno che non sono economici.

Suggerimento 3. Non porre eccessive speranze sulle regole di rilevamento create da qualcun altro, perché devi controllare queste regole per i falsi positivi e perfezionarle

Man mano che inizi a creare regole di rilevamento, c'è sempre la tentazione di utilizzare quelle prontamente disponibili. Sigma è un esempio di repository gratuito. È un formato di metodi di rilevamento indipendente dal SIEM che consente di tradurre regole dal linguaggio Sigma a ElasticSearch, nonché regole Splunk o ArcSight. Il repository include centinaia di regole. Sembra una gran cosa, ma il diavolo, come sempre, sta nei dettagli.

Diamo un'occhiata a una delle regole di rilevamento mimikatz. Questa regola rileva i processi che hanno tentato di leggere la memoria del processo lsass.exe. Mimikatz lo fa quando tenta di ottenere gli hash NTLM e la regola identificherà il malware.

Tuttavia, è fondamentale per noi, esperti che non solo rilevano ma rispondono anche agli incidenti, assicurarci che si tratti effettivamente di un malintenzionato. Sfortunatamente, esistono 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 sono disposto ad accusare nessuno in questo senso – tutte le soluzioni generano falsi positivi; è normale. Tuttavia, gli specialisti dell'intelligence sulle minacce devono comprendere che è ancora necessario ricontrollare e perfezionare le regole ottenute da fonti aperte e chiuse.

Suggerimento 4. Controlla i nomi di dominio e gli indirizzi IP per comportamenti dannosi non solo sul server proxy e sul firewall, ma anche nei registri del server DNS e assicurati di concentrarti sia sui tentativi di risoluzione riusciti che su quelli falliti

I domini e gli indirizzi IP dannosi sono gli indicatori ottimali dal punto di vista della semplicità di rilevamento e della quantità di dolore che infliggi all'attaccante. Tuttavia, sembrano facili da maneggiare solo a prima vista. Almeno, dovresti farti una domanda su dove prendere il registro del dominio.

Se limiti il ​​tuo lavoro al solo controllo dei log del server proxy, puoi perdere codice dannoso che tenta di interrogare direttamente la rete o richiede un nome di dominio inesistente generato con DGA, per non parlare del tunneling DNS: nessuno di questi sarà elencato nel log di un server proxy aziendale. Anche i criminali possono utilizzare i servizi VPN là fuori con funzionalità avanzate o creare tunnel personalizzati.

Suggerimento 5. Monitora o blocca: decidi quale scegliere solo dopo aver scoperto che tipo di indicatore hai scoperto e 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 attiva gli avvisi. Alcune istruzioni ti incoraggiano inequivocabilmente 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 invece a monitorarlo. Le odierne tattiche di dispiegamento di attacchi mirati presuppongono la presenza di un ulteriore canale di connessione segreto 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 presto conto che hai notato i loro imbrogli.

D'altra parte, se l'IOC è un dominio utilizzato da cripto-ransomware, dovrebbe essere bloccato subito. Ma non dimenticare di monitorare tutti i tentativi falliti di interrogare i domini bloccati: la configurazione del codificatore dannoso può includere diversi URL del server Command and Control. Alcuni di essi potrebbero non essere presenti nei feed e quindi non verranno bloccati. Prima o poi, l'infezione li raggiungerà per ottenere la chiave di crittografia che verrà immediatamente utilizzata per crittografare l'host. L'unico modo affidabile per assicurarsi di aver bloccato tutti i C&C è invertire il campione.

Suggerimento 6. Verifica la pertinenza di tutti i nuovi indicatori prima di monitorarli o bloccarli

Tieni presente che i dati sulle minacce sono generati da persone soggette a errori o da una macchina algoritmi di apprendimento che non sono a prova di errore O. Ho visto diversi fornitori di rapporti a pagamento sull'attività dei gruppi APT aggiungere accidentalmente campioni legittimi agli elenchi di hash MD5 dannosi. Dato che anche i rapporti sulle minacce a pagamento contengono IOC di bassa qualità, quelli ottenuti tramite l'intelligence open source dovrebbero essere assolutamente controllati per rilevanza. Gli analisti TI non controllano sempre i loro indicatori per i falsi positivi, il che significa che il cliente deve fare il lavoro di controllo per loro.

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

Suggerimento 7. Automatizza al massimo tutti i flussi di lavoro relativi ai dati sulle minacce. Inizia con il controllo dei falsi positivi completamente automatizzato tramite un elenco di avvisi mentre istruisci il SIEM a monitorare gli IOC che non attivano falsi positivi

Per evitare un gran numero di falsi positivi legati all'intelligence e ottenuti da fonti aperte, è possibile eseguire una ricerca preliminare di questi indicatori negli elenchi di avvisi. Per creare questi elenchi, puoi utilizzare i primi 1000 siti Web per traffico, indirizzi di sottoreti interne, nonché i domini utilizzati dai principali fornitori di servizi come Google, Amazon AWS, MS Azure e altri. È anche un'ottima idea implementare una soluzione che modifichi dinamicamente gli elenchi di avvisi costituiti dai principali domini/indirizzi IP a cui i dipendenti dell'azienda hanno avuto accesso durante l'ultima settimana o mese.

La creazione di questi elenchi di avvisi può essere problematica per un SOC di medie dimensioni, quindi ha senso prendere in considerazione l'adozione delle cosiddette piattaforme di intelligence sulle minacce.

Suggerimento 8. Analizza l'intera azienda per gli indicatori host, non solo gli host connessi a SIEM

Di norma, non tutti gli host di un'azienda sono collegati a SIEM. Pertanto, è impossibile controllarli per un file dannoso con un nome o un percorso specifico utilizzando solo la funzionalità SIEM standard. Puoi occuparti di questo problema nei seguenti modi:

1. Usa il Scanner IOC come Loki. Puoi utilizzare SCCM per avviarlo su tutti gli host aziendali e quindi inoltrare i risultati a una cartella di rete condivisa.
2. Usa scanner di vulnerabilità. Alcuni di loro hanno modalità di conformità che consentono di controllare la rete per un file specifico in un percorso specifico.
3. Scrivi uno script Powershell ed eseguilo tramite WinRM.

Come accennato in precedenza, questo articolo non intende essere una base di conoscenza completa su come eseguire correttamente l'intelligence sulle minacce. A giudicare dalla nostra esperienza, tuttavia, seguire queste semplici regole consentirà ai neofiti di evitare errori critici mentre gestiscono diversi indicatori di compromesso.