Nel mio ultimo post abbiamo parlato del dilemma dei difensori, citando le sfide che i team SOC devono affrontare in base ai risultati del nostro recente State of Threat Detection 2023. Per noi, i risultati erano in qualche modo attesi, considerando i temi comuni che abbiamo sentito da clienti, colleghi e professionisti della sicurezza negli ultimi anni, confermando principalmente ciò che sapevamo essere vero: la maggior parte degli approcci attuali al rilevamento e alla risposta alle minacce sono falliti ed ecco perché:
- I team SOC ricevono in media 4.484 avvisi al giorno, due terzi dei quali (67%) vengono ignorati e l'83% sono falsi positivi.
- Quasi tre quarti (71%) degli analisti ammette che l'organizzazione in cui lavora potrebbe essere stata compromessa e non ne è ancora a conoscenza.
- La maggior parte (97%) degli analisti teme di perdere un evento di sicurezza rilevante perché sepolto da una marea di avvisi di sicurezza.
- Tuttavia, il 90% degli analisti SOC afferma che i propri strumenti di rilevamento e risposta sono efficaci.
Non so voi, ma perché la definizione di efficacia si riduce alla capacità di generare un allarme? Sembra che questo sia il metro di misura che il 90% degli analisti SOC utilizza nonostante ritenga di essere già compromesso e sia sinceramente preoccupato di non riuscire a sferrare un vero attacco. Domande che lasciano perplessi e per trovare delle risposte, Kevin Kennedy, SVP of Product di Vectra AI e Matt Bromiley, Lead Solutions Engineer di LimaCharlie e istruttore SANS hanno partecipato a un recente webinar con SANS in cui hanno lanciato il guanto di sfida: "È ora che i fornitori di sicurezza siano ritenuti responsabili dell'efficacia del loro segnale".
Ci siamo addentrati nella ricerca e abbiamo posto a Kevin, che rappresentava la voce del fornitore, e a Matt, che rappresentava la voce del professionista, 3 semplici domande:
- Più superficie di attacco, più avvisi, più falsi positivi: qual è il problema da risolvere?
- Più punti ciechi, più compromessi, più turnover: da dove cominciare ad affrontare il problema?
- Più visibilità, più rilevamenti, più segnale: cosa rende un analista SOC più efficace nel suo lavoro?
Di seguito sono riportati alcuni punti salienti della conversazione. È possibile guardare l'intera conversazione con Kevin e Matt qui.
D1: 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 la strada. Credo che 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, è un aspetto che è cresciuto negli ultimi anni. Credo che la conoscenza del nostro ambiente sia aumentata. Uno dei problemi è che (l'espansione della superficie d'attacco) non dovrebbe tradursi nell'aggiunta di altre cose alla coda di allarmi e nel fatto che lo scopriremo. Credo che sia successo che superficie di attacco e avvisi siano diventati sinonimi per alcune organizzazioni e per alcuni analisti SOC.
Si tratta del modo in cui li classifichiamo (avvisi). Non voglio che le mie applicazioni vulnerabili vengano segnalate nella stessa coda che segnala l'escalation dei privilegi o l'esecuzione di Mimikat o qualcosa del genere. La vedrei quasi come una coda di posture di sicurezza rispetto a una coda di attività avversarie effettive o qualcosa del genere. E questa classificazione potrebbe allentare un po' la tensione sui SOC, perché non si deve più pensare a un'applicazione web vulnerabile come a un'emergenza da risolvere subito. E quando sentiamo qualcosa come 4.500 avvisi al giorno, questi numeri sono davvero sbalorditivi (e) sembrano bassi rispetto ad alcuni SOC che vedo che si tengono a malapena, a malapena, a galla. Chi possiede le segnalazioni è un'altra parte del problema. Chi è responsabile di risolvere il problema? La sicurezza è responsabile di risolverli o è responsabile di seguirli? E molte volte è la seconda, ma noi la confondiamo con la prima".
Kevin: "Credo che il problema sia l'approccio. Se si guarda a come si è evoluto il sistema, si torna indietro di 10 anni e si trattava di lanciare i dati, scrivere le regole e dare il segnale. Alcune organizzazioni sono riuscite a farlo funzionare, la maggior parte no. Quindi si è assistito all'evoluzione della superficie di attacco e di uno strumento dedicato a ciascuna di esse per (lo scopo di) rilevamento e risposta. C'è l'EDR. C'è l'NDR, c'è l'identità. C'è il rilevamento e la risposta cloud . Quindi, tutto è una soluzione puntuale e praticamente ogni strumento ottimizza la copertura e spesso la copertura a basso livello. Non si pensa realmente al rumore ed è proprio qui che 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. Questo è l'obiettivo e la realtà. Inoltre, è molto più economico sviluppare una copertura di basso livello e rumorosa di quanto non lo sia seguire un singolo. In questo modo, si inondano gli analisti di allarmi, ma si ha una copertura. Ci sarà un falso positivo o un'attività dannosa vera e propria, se si riesce a trovarla. Se si segnala ogni singola esecuzione di codice remoto, si otterrà un'attività dannosa. Inoltre, tutti gli amministratori faranno il loro lavoro e il risultato sarà economico.
In realtà non risolve il problema. È un contributo al problema. E questo si ripercuote su cose come i test. Quindi, se guardate al MITRE, noi mappiamo tutti i nostri rilevamenti su questi metodi. Pensiamo che sia una libreria molto utile nel linguaggio. Se si guarda ai test che eseguono, principalmente incentrati sugli EDR, non c'è alcuna considerazione dei falsi positivi. Si tratta solo di un metodo dannoso. Viene lanciato nell'ambiente. Dicono se questo metodo è stato rilevato o meno.
Non c'è alcun controllo sul fatto che le cose normali stiano lanciando decine di migliaia di allarmi. E se questo è il modo in cui si effettuano i test e le valutazioni, questo è il modo in cui sono impostati gli incentivi, allora si otterranno prodotti che supportano questo. E poi si dice: "Ok, ingegneri della sicurezza, è un vostro problema capire come dare un senso a tutto questo. Con questo approccio stiamo bruciando le persone. Prima di tutto, credo che se stiamo lanciando in media 4.500 avvisi agli analisti, non c'è molto tempo per usare le loro capacità creative quando il tuo obiettivo è chiudere questo avviso in fretta e furia e passare al prossimo, perché mi stanno misurando se sono riuscito a superare la coda e quanto tempo ci è voluto. È un atteggiamento assolutamente sbagliato. Non permette alla creatività di entrare. La cosa più importante è creare spazio e tempo affinché gli analisti possano usare la loro creatività, dando loro ciò che è rilevante da guardare, il contesto e i dati per prendere la decisione giusta in modo rapido ed efficiente. Se è reale, fermate l'attacco. È così che tiriamo fuori il meglio da un analista".
D2: Più punti ciechi, più compromessi, più turnover: da dove dovremmo iniziare ad affrontare il problema?
Kevin: Credo che il fatturato sia il risultato, non la fonte del problema. Penso che il modo per iniziare a risolvere il problema sia un segnale integrato più preciso. Si tratta di capire come consolidare il segnale di attacco. Si parla sempre molto di un'unica lastra di vetro per governarle tutte. È una grande ambizione da perseguire, ma è molto improbabile che si riesca a raggiungere questo obiettivo in un solo passo con molti prodotti puntuali. Pensate quindi a come consolidarvi nel tempo e ritenete i fornitori responsabili della qualità del segnale che forniamo. Se volete sapere chi sta aggiungendo valore, eseguite un red team basato sul vostro modello di minaccia e sulla minaccia avversaria e verificate se i vostri strumenti dimostrano che è accaduto e che ne eravate a conoscenza mentre accadeva. Se siamo in grado di ottenere un segnale integrato e accurato, e voi ci ritenete responsabili per questo, faremo molta strada per risolvere alcuni di questi problemi fondamentali".
Matt: "E perché si concentra sul dare al SOC il potere di fare un passo indietro e dire: "Ehi, i problemi che sto vedendo derivano da uno o due set di strumenti nell'ambiente". Spero che in nessuna organizzazione ci sia una domanda da colloquio di uscita che dica: "Quale strumento è stato il peggiore con cui avere a che fare? Sedetevi e discutete con il vostro team per ottenere il valore di cui abbiamo bisogno dallo stack che abbiamo? E affrontate la questione come punto di contatto, ottenendo il contributo del team SOC. Se si è sommersi da avvisi ogni giorno e si sta pensando di andarsene, ritengo che alcuni di questi dolori possano essere affrontati anche dal punto di vista della gestione. Non si vuole perdere nessuno del team perché l'ambiente ha nicchie uniche che solo il team conosce. Quali sono i nostri punti deboli come organizzazione? Sedetevi e fate questa chiacchierata: è un ottimo modo per iniziare ad affrontare questi problemi.
D3: Più visibilità, più rilevamenti, più segnale: cosa rende un analista SOC più efficace nel suo lavoro?
Matt: Insieme all'idea di burnout arriva anche l'idea che la mia voce non conti nulla. Annegare gli analisti SOC è proprio così. Ed è buffo, stavo leggendo questo thread, su un forum di discussione, credo ieri o l'altro ieri, in cui qualcuno diceva: "Guarda, sono esausto. Ho finito. E questo è quanto. Ed è buffo perché ha proseguito dicendo: "Sto pensando di cambiare lavoro". E la prima risposta è stata. Beh, se sei esausto, dove andrai? Quando guardiamo all'efficacia, dove posso trovare il massimo valore e la massima efficienza? Voglio fare eco ai sentimenti di Kevin: se c'è un'area in cui i vostri strumenti non sono efficaci, voglio dire, il 44% è tornato e ha detto: "Sì, pensiamo che il nostro fornitore potrebbe essere tenuto meglio", per voi, 44%, indovinate cosa farete domani? Ritenete che il vostro fornitore sia responsabile dei segnali che vi sta inviando e lo utilizzate per andare avanti.
Se volessi classificare l'efficacia di un analista SOC, non guarderei al numero di ticket chiusi. Non dovrei. Quello che voglio vedere è che ieri questa cosa ci ha richiesto due ore di lavoro, mentre oggi ci ha richiesto un'ora e 50 minuti. Avete risparmiato tempo. Hai risparmiato produttività. Come hai fatto?
Se il vostro obiettivo è chiudere il maggior numero possibile di ticket, allora è qui che si manifesta il vostro pregiudizio. È qui che si manifesta la mancanza di attenzione per i dettagli e non si utilizzano tutte quelle cose umane che si sanno fare bene, ma si chiudono i ticket solo perché questo è l'incentivo su cui ci si basa. Sembra che i numeri siano quasi opposti a quelli che ci aspettavamo. Mi sarei aspettato un'insoddisfazione maggiore di quella che emerge dal rapporto.
Kevin: Penso che l'efficacia dell'analista SOC sia legata al fatto di dare loro spazio e tempo per essere creativi: le vostre voci devono essere ascoltate sull'efficacia dello strumento dopo il fatto. Ma c'è anche il momento in cui si sceglie (uno strumento). Lavoriamo con molti team SOC e l'ingegneria della sicurezza è in linea con i criteri di scelta degli strumenti. Guardate come funziona con altri strumenti, in modo da poter automatizzare di più. Guardate la qualità. Eseguite un red team. Comprendere il modello di minaccia.
Punti di forza
Nel corso di questa conversazione di un'ora, ci siamo resi conto che il problema da risolvere è quello degli avvisi, e non solo del 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. Assicurarsi che gli analisti del SOC abbiano voce in capitolo per informare la direzione e l'ingegneria della sicurezza sull'efficacia del segnale, perché se è inefficace bisogna dirlo a qualcuno. Abbiamo parlato di come i leader SOC debbano battere la spalla dell'analista SOC chiedendo input. Cosa si può fare per migliorare il lavoro?
Volete saperne di più su Kevin e Matt? Ascoltate la loro precedente conversazione, "Uscire dalla spirale del "di più" nella sicurezza - Perché l'unico "di più" di cui ha bisogno la sicurezza è una maggiore Attack Signal Intelligence", qui.