Gli avvisi critici vengono prima del caffè
Sono le 6:45 del mattino. La sveglia suona e vi alzate dal letto in una camera coperta dal grigio inchiostro dell'alba. La prima cosa che fate è controllare le notifiche sul vostro telefono. Spara. È stato rilevato un allarme P0 e Danny, l'analista dell'EMEA che ha fatto il turno prima di voi, si è già disconnesso. Non lo biasimate: i suoi genitori sono in visita. Perciò ti affretti a fare la tua routine mattutina e rinunci a mettere la caffettiera sul fuoco. Andrà tutto bene; succede spesso e gli avvisi P0 sono sempre sufficienti a scuotervi dal torpore mattutino.
La notifica via e-mail con l'avviso P0 rientra nell'area geografica e nell'area di proprietà EDR assegnata, quindi la assegnate a voi stessi. Poiché il tempo è fondamentale quando si tratta di avvisi critici, si passa rapidamente alla fase successiva: l'indagine. Utilizzando gli strumenti disponibili sulla piattaforma da cui proviene il rilevamento, si esaminano i registri e si cerca di rispondere mentalmente alle 3 domande principali di qualsiasi indagine sulle minacce alla sicurezza: 1) chi è stato, 2) cosa ha fatto e 3) perché sono stato avvisato.
Circa 45 minuti dopo, dopo aver sfogliato diversi strumenti e scorrendo molte righe di registri, è possibile confermare che questo rilevamento era un vero positivo ma benigno. C'era un'attività sospetta, ma non era dannosa. Si rimuove il rilevamento dalla coda e si prende nota di scrivere un rapporto su questo avviso.
Guardate l'orologio: sono le 7:42 del mattino. Finalmente è l'ora del caffè, e giusto in tempo per la riunione di presentazione delle 8:00. Non pensate agli altri 10 rilevamenti in coda.
La rilevazione che gridava "al lupo" era in realtà un lupo
Una settimana dopo, vi sentite bene. Siete entrati in un certo senso in sintonia anche con il numero schiacciante di avvisi in arrivo; avete raggiunto tutti gli avvisi prioritari nel vostro turno e avete scritto alcune regole graziose e ordinate per evitare di ricevere notifiche per quegli avvisi positivi benigni che continuano ad arrivare. Persino il vostro manager vi ha dato una pacca sulla spalla virtuale per aver individuato lo schema dei veri positivi e aver implementato una soluzione permanente per alleggerire il carico di lavoro di tutti.
Anche se vi state crogiolando nel bagliore di un SOC sprint di successo e vi state finalmente godendo un pranzo che non consiste nell'alternare i bocconi di un panino allo scorrere i log per indagare su un rilevamento, qualcosa non quadra. Forse vi siete persi un allarme P1 - no, non è questo il caso perché il vostro collega vi avrebbe avvisato. Forse avete lasciato il fornello del caffè acceso. Si guarda verso di esso; no, è stato spento ore fa.
È tranquillo. La coda di allerta ha la sua fila di rilevamenti, ma non sono prioritari e si può lavorare dopo aver finito di pranzare. Non ci sono allarmi eclatanti né striscioni rossi. È tutto tranquillo. Decidete che la tranquillità è ciò che vi disturba.
Un'ora più tardi, si sta sfrecciando tra i rilevamenti in coda. Quasi tutti non sono dannosi. Sembra una passeggiata nel parco e la soddisfazione è tanta quando si chiude uno dopo l'altro. Si preme il tasto di aggiornamento del browser e ci si siede a guardare il buffer e il rendering dell'interfaccia utente. Pensate di premiarvi con una fine anticipata della giornata. Magari andate in palestra, dove vi siete iscritti mesi fa ma non avete avuto il tempo di andarci.
L'interfaccia utente termina di aggiornarsi e viene visualizzata una fila di banner rossi, che indicano una moltitudine di rilevamenti ad alta priorità. Il vostro stomaco cade a terra. Che cosa è successo?
Il vostro team sta facendo ping nella chat di squadra. Nessuno capisce cosa stia succedendo e perché la piattaforma sia stata improvvisamente inondata di avvisi ad alta priorità. C'è un crescente senso di panico da parte di tutti, compresi voi stessi. Forse più all'interno di voi stessi, perché mentre fate clic su ogni rilevamento, vi accorgete che molti dei registri vi sembrano familiari. Gli ID, i dispositivi, i sistemi operativi: tutto sembra familiare. Ma ovviamente le regole che avete scritto per bloccarle non hanno funzionato, perché quelle regole erano uniche, e i rilevamenti attuali, di colore rosso vivo, le hanno fatte convergere tutte insieme.
Il tutto è confluito in un grave attacco alla sicurezza che ha sconvolto l'azienda.
Cosa è andato storto
Dopo giorni di lavoro per ore e ore per rispondere e rimediare, voi e il vostro team avete impedito all'attacco di causare altri danni. Nulla nell'azienda è stato compromesso, il che è una vittoria per tutti. Ma è stato stressante e travolgente e, dannazione, cosa è andato storto?
In un primo momento vi rimproverate di aver potenzialmente etichettato un rilevamento come positivo benigno, ma il vostro lavoro è stato controllato e verificato da altre due persone del vostro team. Quando siete tornati indietro, il risultato era un positivo benigno ed è stato trattato di conseguenza. Voi, quindi, incolpate la piattaforma. Qualcosa nel suo algoritmo o nei suoi rapporti non vi ha permesso di svolgere correttamente il vostro lavoro, ma sapete che la state solo usando come capro espiatorio.
Mentre esaminate gli eventi e i dati dei tre giorni di lavoro precedenti e redigete un rapporto post-mortem, notate come i rilevamenti convergano verso un attacco unificato e vi rendete conto che non siete stati voi o la piattaforma a causare l'errore e la confusione; il problema risiede nei rilevamenti stessi.
I rilevamenti sono numerosi, soprattutto se isolati e provenienti da diverse superfici di attacco. In genere si dedica la maggior parte del tempo a una piattaforma che raccoglie informazioni da queste diverse superfici di attacco, ma le informazioni sono molte e si finisce comunque per passare a questi strumenti. Il problema risiede nel numero di rilevamenti: ce n'erano troppi e molti di essi erano a bassa priorità, quindi non si prestava loro l'attenzione necessaria.
Ma come potevi saperlo? Erano considerati minori e voi avevate altre cose da fare. Quindi, cosa può risolvere questo dilemma?
Il quadro generale
Gli avvisi e i rilevamenti non tengono conto del quadro generale: gli aggressori sono intelligenti e adattabili, quindi si spostano da un luogo all'altro, sfruttano le lacune di copertura e le backdoor non protette e si presentano come rilevamenti solo in parte pericolosi prima di raccogliere tutte le informazioni necessarie per un attacco su larga scala.
È qui che la prioritizzazione basata sulle entità può risolvere il problema. Un'entità non è un allarme o un rilevamento. È un insieme di eventi correlati che rientrano in un'unica entità. In alcuni casi, include host, account e rilevamenti. Con le entità, gli analisti possono vedere il quadro generale e catturare gli aggressori che giocano a lungo.
Come analista SOC, avete sbagliato tutto. Non siete voi. È il modo in cui le tecnologie di sicurezza considerano gli avvisi e i rilevamenti. Una volta che le tecnologie adottano un tipo di priorità che fa prevalere le entità sugli avvisi e i rilevamenti, vi ritroverete non solo con meno avvisi da monitorare e da coinvolgere, ma anche con un maggior numero di veri positivi a una velocità superiore e con maggiore sicurezza.
E, soprattutto, potrete prendere la vostra tazza di caffè al mattino.