Scalare il triage degli avvisi di sicurezza con agenti specializzati su Databricks

E se la gravità bassa non significasse bassa priorità?

Databricks acquisisce petabyte di log di sicurezza da svariate fonti, tra cui strumenti di sicurezza degli endpoint, log delle attività cloud e feed di threat intelligence nel nostro security lakehouse. La nostra architettura di rilevamento monitora continuamente questi dati alla ricerca di attività dannose. Ogni segnale identificato finisce in una tabella centralizzata degli avvisi, dove attende di essere esaminato da un analista di Incident Response (IR).

Trovare una vera minaccia tra migliaia di avvisi di sicurezza giornalieri è il classico problema dell'ago nel pagliaio. La maggior parte dei team gestisce il carico dando priorità agli avvisi in base alla gravità. I team eseguono il triage degli avvisi HIGH e MEDIUM e gestiscono quelli LOW man mano che la larghezza di banda si rende disponibile.

In Databricks, il nostro team di IR gestisce gli avvisi di sicurezza su tutti e tre i livelli di priorità. Storicamente, il team dava la priorità agli avvisi HIGH e MEDIUM a causa del volume e della bassa fedeltà degli avvisi LOW. Ogni team di sicurezza su larga scala si trova di fronte allo stesso compromesso: aumentare il numero di analisti, innalzare le soglie di avviso accettando punti ciechi, oppure trovare un modo per automatizzare il processo. Noi abbiamo scelto quest'ultima strada, sfruttando agenti in grado di ragionare ed esprimere giudizi su larga scala.

Il valore degli agenti specializzati

Per verificare se gli agenti potessero eseguire il triage e l'escalation degli avvisi di sicurezza in modo affidabile, siamo partiti dagli avvisi a bassa gravità. Il nostro obiettivo era semplice: identificare gli avvisi che meritavano ulteriori indagini.

All'inizio abbiamo adottato un approccio ingenuo, inserendo tutti i dati rilevanti dell'avviso in un unico prompt e lasciando che un modello di base decidesse cosa sottoporre a escalation. Questo approccio ha prodotto un tasso di escalation del 50%. Inviare metà di tutti gli avvisi agli analisti non era un triage, era solo un tipo diverso di rumore.

Il problema era il contesto. Un singolo agente che ragiona su ogni avviso non ha modo di distinguere cosa sia anomalo per ciascuna fonte. Tutto ciò che serve per eseguire il triage di un avviso in modo accurato — i suoi pattern di falsi positivi, le baseline comportamentali e il relativo arricchimento — è specifico della fonte. Senza questo contesto, la conoscenza generale della cybersecurity era tutto ciò su cui il modello poteva fare affidamento, e non era sufficiente per un triage accurato.

Architettura: una flotta di agenti

Abbiamo ricostruito la pipeline attorno a 17 agenti specifici per fonte, ciascuno ottimizzato per una singola fonte di rilevamento, poiché il contesto necessario per un triage accurato è altamente specifico della fonte. Una singola fonte può emettere decine di rilevamenti distinti e il suo agente li gestisce tutti.

Abbiamo anche un agente di Threat Intelligence (TI) dedicato che affianca la flotta di triage degli agenti per la bassa gravità e può essere chiamato da qualsiasi agente quando rileva un indicatore o un comportamento che merita un'indagine più approfondita. L'agente TI interroga le nostre fonti di threat intelligence e restituisce una valutazione strutturata: se questo artefatto sia noto come dannoso, sconosciuto o innocuo. Questo è importante perché gli indicatori grezzi di compromissione non hanno senso senza contesto. Un indirizzo IP è solo un numero. Lo stesso IP arricchito con "associato a infrastruttura C2 negli ultimi 14 giorni, alta affidabilità" è immediatamente utilizzabile dall'agente.

Utilizzando Structured Streaming su Databricks, gli avvisi a bassa gravità vengono acquisiti non appena si attivano, arricchiti con ulteriore contesto dall'agente TI e instradati al sotto-agente appropriato per la revisione.

Ogni agente segue gli stessi principi di progettazione:

Filtraggio deterministico. I controlli programmatici verificano la corrispondenza sul titolo dell'avviso e sui campi di contesto per eliminare i segnali noti come innocui (sfumature specifiche dell'ambiente come elenchi di IP attendibili, attività degli account di servizio, comportamento previsto degli strumenti) e produrre decisioni istantanee senza alcuna chiamata LLM. Questi gestiscono il 30-95% del volume degli avvisi a seconda della fonte. Elementi come "ruolo IAM noto come sicuro che esegue operazioni previste" o "e-mail dell'amministratore che esegue la governance ordinaria dell'area di lavoro". Il filtraggio può avvenire a livello di rilevamento o direttamente accanto alla logica di triage.

Arricchimento del contesto. Prima che l'LLM veda l'avviso, l'agente recupera la cronologia recente degli avvisi per l'entità interessata, l'attività correlata e altri segnali rilevanti. Gli agenti possono anche invocare altre funzionalità agentiche durante l'arricchimento, ad esempio chiamando l'agente di Threat Intelligence dedicato quando un avviso contiene un IP o un dominio che vale la pena esaminare.

Funzioni di prompt specializzate. Ogni titolo di avviso è mappato su una funzione di prompt. Ad esempio, gli avvisi di accesso anomalo a S3 vanno a una funzione con istruzioni per valutare la ricognizione IAM, e gli avvisi di escalation dei privilegi vanno a una che conosce i pattern di assunzione dei ruoli previsti rispetto a quelli imprevisti. Se nessuna funzione dedicata corrisponde, un prompt di fallback generico gestisce l'avviso. Le funzioni di prompt vengono eseguite in modalità single-turn (una sola chiamata LLM) o in modalità agentica (loop multi-turn di chiamata degli strumenti) a seconda che l'avviso richieda o meno un contesto aggiuntivo per eseguire il triage in modo sicuro.

Strumenti condivisi. Gli strumenti sono opzionali e specifici per l'agente. Quando il triage richiede più contesto — log di audit cloud grezzi, avvisi correlati tra diverse fonti o cronologia delle attività IdP — dotiamo l'agente di strumenti per recuperarlo, e l'LLM decide se e quando invocarli in base all'ambiguità delle prove.

Utility condivise. Per gestire il sovraccarico derivante dal mantenimento di diversi agenti, abbiamo rifattorizzato il codice delle utility condivise in un framework comune che gestisce l'invocazione degli agenti, i tentativi e la valutazione delle prestazioni. Tutta la logica coerente tra le fonti di dati risiede qui, inclusi il loop di chiamata LLM, il parsing delle decisioni, il dispatch degli strumenti, la persistenza dei risultati nelle tabelle Delta, il tracciamento dei token, il tracciamento MLflow e il rilevamento della prompt injection.

Ragionamento e decisione dell'LLM. Il modello analizza il pacchetto di prove e restituisce un output strutturato che include una decisione (escalation, monitoraggio o chiusura) con l'analisi di supporto.

Gestione dei costi. Esistono tre controlli sulla spesa. Primo, il filtraggio deterministico garantisce che gli avvisi corrispondenti a pattern noti come innocui non raggiungano mai un LLM. La chiamata più economica è quella che non si fa mai. Secondo, un tracker dei costi accumula la spesa stimata per ciascun batch e interrompe l'elaborazione se viene raggiunto un limite configurabile, registrando gli avvisi rimanenti come saltati. Terzo, un limite giornaliero di avvisi stabilisce un tetto al costo totale giornaliero, indipendentemente dal volume in entrata. All'interno di ciascun avviso, i budget per le chiamate degli strumenti per categoria prevengono loop di ricerca infiniti in cui un LLM potrebbe altrimenti continuare a richiedere contesto aggiuntivo all'infinito.

Se l'agente decide di procedere con l'escalation, l'avviso diventa un ticket nella coda di IR, dove gli analisti esaminano sia l'avviso grezzo che l'analisi dell'agente prima di prendere una decisione finale di triage. Quando un analista non è d'accordo con l'escalation di un agente, il ticket viene etichettato come falso positivo e tale feedback viene utilizzato per ottimizzare le prestazioni dell'agente. Abbiamo riscontrato che gli avvisi a bassa gravità sottoposti a escalation dall'agente avevano una probabilità circa 10 volte superiore di essere veri positivi rispetto agli avvisi esistenti classificati con gravità HIGH e MEDIUM.

Il benchmark umano dietro ogni decisione dell'agente

Quando un analista umano esamina un ticket sottoposto a escalation, la sua decisione di confermare o ignorare l'agente diventa la "ground truth" (verità di base) per la valutazione. A differenza dei programmi deterministici, in cui è possibile effettuare test rispetto a una specifica fissa, gli agenti esprimono un giudizio. Lo stesso avviso può produrre output diversi a seconda delle esecuzioni. Quindi, invece di testare rispetto a una specifica, testiamo rispetto a un dataset standard sviluppato dagli analisti di IR che sanno già come si presenta una decisione di triage di alta qualità.

Ogni richiesta dell'agente viene registrata utilizzando MLflow, catturando input, passaggi intermedi e output finali. Man mano che gli analisti di IR etichettano i ticket nel corso del loro normale flusso di lavoro, ogni etichetta viene registrata direttamente sulla traccia MLflow corrispondente come risposta prevista. Queste tracce etichettate stabiliscono un dataset di ground truth che cattura il giudizio degli analisti su larga scala. Quel dataset diventa le benchmark per valutare eventuali modifiche future ai prompt prima del loro rilascio.

Per misurare aspetti che vanno oltre i falsi positivi, prevediamo di utilizzare la Databricks Review App, un'interfaccia per la revisione degli avvisi e l'etichettatura delle tracce MLflow. Gli analisti possono vedere gli input, il ragionamento e la decisione dell'agente per ciascun avviso e registrare il risultato previsto direttamente sulla traccia. Ciò consente agli analisti di esaminare anche gli avvisi non sottoposti a escalation, ampliando la copertura della ground truth per gli avvisi che l'agente ha scelto di monitorare o chiudere e fornendoci uno standard completo per tutte e tre le decisioni.

Risultati

Gli agenti di sicurezza ora esaminano il 100% degli avvisi a bassa gravità. Le metriche chiave includono:

• Gli agenti hanno eseguito il triage di oltre 18.000 avvisi con un tasso di escalation del 3,2%
• Gli avvisi a bassa gravità sottoposti a escalation dall'agente avevano una probabilità circa 10 volte superiore di essere veri positivi rispetto agli avvisi con gravità HIGH o MEDIUM
• Tempo medio di triage: 10,5 secondi
• Oltre 6.500 ore di lavoro degli analisti risparmiate nei primi 30 giorni

Risultati significativi sottoposti a escalation dagli agenti:

• Riduzione del tasso di falsi positivi di una fonte di avvisi dal 72% al 3,4%
• Identificazione di 22 domini sospetti, parcheggiati o dannosi
• Rilevamento di un caso in cui un utente ha scaricato ed eseguito software craccato; l'agente ha segnalato indicatori comportamentali coerenti con la violazione delle policy e l'intento dannoso.

Cosa abbiamo imparato

I LLM hanno allucinazioni con i dati di sicurezza ad alta entropia. Hash, sottodomini casuali e nomi di file generati sono difficili da gestire per i modelli linguistici. I modelli sono abili nel ragionamento sul linguaggio perché il linguaggio presenta dei pattern. Gli artefatti di sicurezza come gli hash sono deliberatamente privi di pattern, ed è proprio questo che li rende difficili per i LLM. Per garantire l'accuratezza, utilizziamo il modello per il ragionamento e non per il richiamo di informazioni. I valori specifici degli artefatti vengono recuperati tramite chiamate a strumenti verso fonti autorevoli, non dalla memoria del modello.

Il contesto è fondamentale. I maggiori incrementi di prestazioni sono derivati dall'aggiunta a ogni prompt di dati storici sugli avvisi, tassi di falsi positivi per tipo di avviso e pattern comportamentali espliciti. Durante l'elaborazione di un avviso, l'agente di triage recupera la cronologia degli avvisi degli ultimi sei mesi per l'utente interessato. In diversi casi, gli agenti hanno inoltrato gli avvisi non perché l'evento scatenante fosse individualmente ad alta affidabilità, ma perché si trattava del terzo o quarto segnale sospetto proveniente dallo stesso utente. Questo tipo di correlazione comportamentale è un elemento che le regole di rilevamento deterministiche precedenti faticavano a catturare.

Automatizza ciò che è prevedibile e lascia che gli agenti ragionino solo su ciò che non lo è. Ove possibile, opta per workflow deterministici per limitare l'ambito di ciò che il LLM deve esaminare. Più le istruzioni sono aperte, maggiore sarà il tasso di falsi positivi. Istruzioni per l'agente dettagliate e passo-passo hanno costantemente superato in termini di prestazioni i prompt generici. L'applicazione di un filtraggio basato su regole prima che il LLM veda un avviso è uno degli esempi più efficaci di questo approccio.

Sviluppato su Databricks

Questo sistema è stato sviluppato su Databricks utilizzando Spark Structured Streaming per l'acquisizione di avvisi in tempo reale, tabelle Delta per la persistenza e la reportistica degli avvisi, MLflow Tracing per catturare ogni decisione dell'agente end-to-end e la Databricks Review App per consentire agli analisti di etichettare le tracce e creare la ground truth direttamente dai dati di produzione.

In Databricks, creiamo gli strumenti che utilizziamo. Questo è un esempio di come la nostra stessa piattaforma stia potenziando le operazioni di sicurezza native per l'IA. Prossimamente: come Databricks Genie può portare l'indagine in linguaggio naturale nel SOC, offrendo agli analisti di IR la possibilità di interrogare i dati sugli avvisi, esplorare il contesto e indagare sulle minacce in modo conversazionale.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale