Nel mio ultimo post abbiamo parlato del dilemma dei difensori citando le sfide che i team SOC devono affrontare, tratte dal nostro recente rapporto State of Threat Detection 2023. Per noi i risultati erano in qualche modo prevedibili, considerando i temi ricorrenti che abbiamo sentito dai clienti, dai colleghi e dai professionisti della sicurezza negli ultimi anni, confermando principalmente ciò che sapevamo essere vero, ovvero che la maggior parte degli approcci attuali al rilevamento e alla risposta alle minacce sono inadeguati, ed ecco perché:
- I team SOC ricevono in media 4.484 avvisi al giorno, due terzi (67%) dei quali vengono ignorati, mentre l'83% sono falsi positivi.
- Quasi tre quarti (71%) degli analisti ammettono che l'organizzazione per cui lavorano potrebbe essere stata compromessa e che ancora non ne sono a conoscenza.
- La maggior parte degli analisti (97%) teme di perdere un evento di sicurezza rilevante perché sepolto da una marea di avvisi di sicurezza.
- Eppure, il 90% degli analisti SOC afferma che i propri strumenti di rilevamento e risposta sono efficaci.
Non so voi, ma perché la definizione di "efficace" si riduce alla capacità di generare un allarme? Questo sembra essere il metro di misura utilizzato dal 90% degli analisti SOC, nonostante credano di essere già compromessi e provino una sincera ansia di non riuscire a individuare un attacco reale. Domande sconcertanti: per trovare alcune risposte, Kevin Kennedy, vicepresidente senior del reparto Prodotti di Vectra AI Matt Bromiley, ingegnere capo delle soluzioni presso LimaCharlie e istruttore SANS, hanno partecipato a un recente webinar con SANS in cui hanno lanciato la sfida: "È ora che i fornitori di sicurezza siano ritenuti responsabili dell'efficacia dei loro segnali".
Ci siamo immersi nella ricerca e abbiamo posto tre semplici domande a Kevin, che rappresentava il punto di vista del fornitore, e a Matt, che rappresentava il punto di vista del professionista:
- Più superficie di attacco, più avvisi, più falsi positivi: qual è il problema da risolvere?
- Più punti ciechi, più compromessi, più turnover: da dove dovremmo iniziare ad affrontare il problema?
- Maggiore visibilità, più rilevamenti, più segnali: cosa rende un analista SOC più efficace nel proprio lavoro?
Di seguito sono riportati alcuni punti salienti della conversazione. È possibile guardare l'intera conversazione con Kevin e Matt qui.
Q1: Più superficie di attacco, più avvisi, più falsi positivi: qual è il problema da risolvere?
Matt: "Penso che siano successe un paio di cose dal punto di vista degli strumenti e della tecnologia che hanno aperto questa possibilità. Se avessimo posto questa domanda 4 o 5 anni fa, i risultati sarebbero stati molto diversi. La superficie di attacco, o meglio, la comprensione della superficie di attacco, è qualcosa che è cresciuta negli ultimi anni. Penso che abbiamo aumentato la nostra conoscenza del nostro ambiente. Uno dei problemi è che (l'espansione della superficie di attacco) non dovrebbe tradursi semplicemente nell'aggiunta di ulteriori elementi alla coda degli avvisi, che poi risolveremo. Penso che ciò che è successo qui è che la superficie di attacco e gli avvisi sono diventati sinonimi per alcune organizzazioni e per alcuni analisti SOC.
Si tratta di come li classifichiamo (gli avvisi). Non voglio che le mie applicazioni vulnerabili vengano segnalate nella stessa coda che segnala l'escalation dei privilegi o l'esecuzione di Mimikats o qualcosa del genere. Lo considererei quasi come una coda di sicurezza rispetto a una coda di attività nemiche effettive o qualcosa del genere. E questa classificazione potrebbe alleggerire un po' la tensione sui SOC, semplicemente perché non si deve più pensare a un'applicazione web vulnerabile come a un'emergenza da risolvere immediatamente. E sapete, quando sentiamo parlare di 4.500 avvisi al giorno, questi numeri sono semplicemente sbalorditivi (e) sembrano bassi rispetto ad alcuni dei SOC che vedo e che riescono a malapena a tenere la testa fuori dall'acqua. Chi è responsabile degli avvisi è un altro aspetto del problema. Chi è effettivamente responsabile della risoluzione? La sicurezza è responsabile della risoluzione o del follow-up? Molte volte è la seconda, ma la confondiamo con la prima".
Kevin: "Penso che il problema sia l'approccio. Se si guarda a come si è evoluta la situazione, tornando indietro di 10 anni, si trattava di inserire dati, scrivere regole e ottenere un segnale. Alcune organizzazioni hanno fatto funzionare questo sistema, ma la maggior parte no. E così si è assistito a questa evoluzione della superficie di attacco e alla creazione di uno strumento dedicato a ciascuno di essi (allo scopo di) rilevare e rispondere. C'è l'EDR. C'è l'NDR, c'è l'identità. C'è cloud e la risposta cloud . Quindi, tutto è una soluzione puntuale e praticamente ogni strumento ottimizza la copertura, spesso di basso livello. Non si pensa davvero al rumore e questo è proprio il punto in cui si trovano gli incentivi dal punto di vista dei fornitori. Si tratta di una copertura di basso livello a causa del modo in cui i prodotti vengono testati e valutati. Questa è la spinta e la realtà. Inoltre, è molto più economico sviluppare una copertura rumorosa di basso livello piuttosto che ottenere effettivamente un singolo risultato. Quindi, si sommergono gli analisti di avvisi, ma si ottiene la copertura. Ci saranno falsi positivi o attività effettivamente dannose, se si riesce a individuarle. Se si segnalano tutte le singole esecuzioni di codice remoto, si otterranno risultati dannosi. Otterrete anche che ogni amministratore faccia il proprio lavoro e lo farete a basso costo.
In realtà non risolve il problema. Contribuisce al problema. E questo si riflette anche in aspetti come i test. Se guardiamo al MITRE, mappiamo tutti i nostri rilevamenti su quei metodi. Riteniamo che sia una libreria davvero utile nel linguaggio. Se si osservano i test che effettuano, incentrati principalmente sugli EDR, non viene presa in considerazione alcuna possibilità di falsi positivi. Si tratta solo di un metodo dannoso. Viene attivato nell'ambiente. Si chiedono: questo ha rilevato o no?
Non viene verificato se le cose normali generano decine di migliaia di avvisi. E se questo è il modo in cui si effettuano i test e le valutazioni, se è così che sono impostati gli incentivi, allora si otterranno prodotti che supportano questo approccio. E poi si dice: "Ok, ingegneria della sicurezza, è un tuo problema capire come dare un senso a tutto questo". Stiamo esaurendo le persone con questo approccio. Prima di tutto, penso che se inviamo in media 4.500 avvisi agli analisti, non c'è molto tempo per usare le loro capacità creative quando il vostro pregiudizio è: chiudete questo avviso il più velocemente possibile e passate al prossimo perché io vengo valutato in base a questo: riesco a smaltire la coda e quanto tempo ci ho messo? Questo è assolutamente il modo sbagliato di procedere. Non permette alla creatività di emergere. La cosa più importante è creare lo spazio e il tempo affinché gli analisti possano usare la loro creatività, fornendo loro ciò che è rilevante da esaminare, il contesto e i dati necessari per prendere la decisione giusta in modo rapido ed efficiente. Se è reale, fermate l'attacco. È così che tiriamo fuori il meglio da un analista".
Q2: Più punti ciechi, più compromessi, più turnover: da dove dovremmo iniziare ad affrontare il problema?
Kevin: Credo che il turnover sia il risultato, non la causa del problema. Penso che il modo migliore per affrontare la questione sia quello di utilizzare un segnale integrato più accurato. Si tratta di consolidare la fonte da cui proviene il segnale di attacco. Si parla sempre molto di un unico pannello di controllo per gestirli tutti. È un obiettivo ambizioso, ma è altamente improbabile che si possa raggiungere in un unico passo con molti prodotti specifici. Quindi, pensate a come consolidare nel tempo e rendete noi fornitori davvero responsabili della qualità del segnale che forniamo. Se volete sapere chi sta aggiungendo valore, create un red team basato sul vostro modello di minaccia e sul vostro avversario e verificate se i vostri strumenti mostrano che ciò è avvenuto e che ne eravate a conoscenza mentre stava accadendo. Se riusciamo a ottenere un segnale integrato e accurato e voi ci ritenete responsabili di ciò, sarà un grande passo avanti verso la risoluzione di alcune di queste questioni fondamentali".
Matt: "E perché si concentra sul dare al SOC il potere di fare un passo indietro e dire: 'Ehi, sapete, i problemi che sto riscontrando derivano da uno o due set di strumenti nell'ambiente'. Spero che non ci sia una domanda di fine rapporto per nessuna organizzazione che chieda: "Qual è stato lo strumento peggiore con cui hai avuto a che fare? Siediti e discuti con il tuo team su come ottenere il valore di cui abbiamo bisogno dallo stack che abbiamo a disposizione. Affronta la questione come un punto di contatto e ottieni il contributo del team SOC. Essere sommersi ogni giorno da avvisi e considerare di andarsene, ritengo che alcuni di questi (problemi) possano essere affrontati anche dal punto di vista gestionale. Non volete perdere nessuno del team perché il vostro ambiente ha nicchie uniche che solo il vostro team conosce. Quali sono i nostri punti deboli come organizzazione? Sedetevi e discutetene: è un ottimo modo per iniziare ad affrontare queste preoccupazioni.
Q3: Maggiore visibilità, più rilevamenti, più segnali: cosa rende un analista SOC più efficace nel proprio lavoro?
Matt: All'idea di burnout si aggiunge anche quella che la mia voce non conta. Sommersione degli analisti SOC è semplicemente così. Ed è buffo, stavo leggendo questo thread, su un forum di discussione, credo ieri o l'altro ieri, dove qualcuno diceva: "Senti, sono semplicemente esaurito. Ho chiuso. Tutto qui". Ed è divertente perché poi ha aggiunto: "Sto pensando di cambiare lavoro". E la prima risposta è stata: "Beh, se sei esaurito, dove pensi di andare? Quando guardiamo all'efficacia, dove posso trovare il massimo valore ed efficienza? Vorrei ribadire il pensiero di Kevin, ovvero: se c'è un'area in cui i tuoi strumenti non sono efficaci, voglio dire, il 44% ha risposto dicendo: "Sì, pensiamo che il nostro fornitore potrebbe essere migliore", per te, 44%, indovina cosa farai domani? Riterrai il tuo fornitore responsabile dei segnali che ti sta inviando e poi lo userai come spinta per andare avanti.
Se volessi classificare l'efficacia degli analisti SOC, non guarderei al numero di ticket chiusi. Non dovrei farlo. Quello che mi interessa è che ieri ci sono volute due ore per fare una cosa, mentre oggi ci è voluta solo un'ora e 50 minuti. Hai appena fatto risparmiare tempo. Hai aumentato la nostra produttività. Come ci sei riuscito?
Se il tuo obiettivo è semplicemente quello di chiudere il maggior numero possibile di ticket, allora è qui che entra in gioco il tuo pregiudizio. È qui che entra in gioco la tua mancanza di attenzione ai dettagli e non stai utilizzando tutte quelle qualità umane in cui eccelli: stai semplicemente chiudendo i ticket solo perché questo è l'incentivo su cui ti basi. Sembra che i numeri siano quasi l'opposto di quello che ci aspettavamo. Mi sarei aspettato più insoddisfazione di quella che vediamo (nel rapporto).
Kevin: Credo che l'efficacia degli analisti SOC dipenda dalla possibilità di avere spazio e tempo per essere creativi: le vostre opinioni sull'efficacia degli strumenti devono essere ascoltate a posteriori. Ma è importante anche il momento in cui si sceglie uno strumento. Lavoriamo con molti team SOC e l'ingegneria della sicurezza è in prima linea quando si tratta di stabilire i criteri di scelta degli strumenti. È importante valutare come funzionano con altri strumenti, in modo da poter automatizzare maggiormente i processi. Valutate la qualità. Create un red team. Comprendete il vostro modello di minaccia.
Da portare via
Nel corso di questa conversazione di un'ora, abbiamo concluso che il problema da risolvere riguarda gli avvisi, e non solo il rumore degli avvisi: chiunque può affermare di ridurre il rumore. Il problema principale è l'approccio agli avvisi. L'uso degli avvisi per misurare. La proprietà degli avvisi e la definizione di ciò che giustifica un avviso. In termini di priorità da stabilire, abbiamo parlato di segnale integrato. La capacità di consolidare e misurare l'efficacia del segnale. Assicuratevi (analisti SOC) di avere voce in capitolo per informare la direzione e gli ingegneri della sicurezza sull'efficacia di quel segnale, perché se è un segnale inefficace, dovete dirlo a qualcuno. Abbiamo parlato di come i responsabili SOC debbano dare una pacca sulla spalla agli analisti SOC chiedendo loro un parere. Cosa si può fare per migliorare il lavoro?
Vuoi saperne di più da Kevin e Matt? Ascolta la loro precedente conversazione, "Uscire dalla spirale del "di più" nella sicurezza - Perché l'unica cosa di cui la sicurezza ha bisogno è più Attack Signal Intelligence", qui.