Panoramica dei rilevamenti compositi
Questo documento presenta i rilevamenti compositi e spiega come possono migliorare i flussi di lavoro di rilevamento delle minacce correlando gli output di più regole.
I rilevamenti compositi vengono generati da regole che utilizzano come input i rilevamenti di altre regole, combinati con eventi, metriche o indicatori di rischio delle entità. Queste regole vengono poi combinate con eventi, metriche o indicatori di rischio delle entità per rilevare minacce complesse e in più fasi che le singole regole possono perdere.
I rilevamenti compositi aiutano ad analizzare gli eventi tramite interazioni e trigger di regole definiti. In questo modo, si migliora l'accuratezza, si riducono i falsi positivi e si ottiene una visione completa delle minacce alla sicurezza correlando i dati provenienti da diverse fonti e fasi di attacco.
I seguenti concetti definiscono i blocchi predefiniti delle regole composite e chiariscono il loro funzionamento all'interno dei flussi di lavoro di rilevamento:
Regole composite: utilizzano come input rilevamenti o avvisi (o entrambi). Facoltativamente, puoi arricchirli con eventi, metriche e un'ampia gamma di dati contestuali dal grafico delle entità, come dati di prevalenza, intelligence sulle minacce o un punteggio di rischio delle entità. Queste regole devono sempre avere una sezione di corrispondenza e possono fare riferimento a metadati, variabili
matche variabilioutcomedelle regole di input.Rilevamento: output generato quando le condizioni di una regola sono soddisfatte.
Regole di solo rilevamento: regole composite che utilizzano solo rilevamenti o avvisi come input.
Quando utilizzare i rilevamenti compositi
I rilevamenti compositi possono essere utili per raggiungere i seguenti obiettivi:
Correlare i risultati di due o più regole (ad esempio, collegare un rilevamento di download di malware con un successivo avviso di beaconing C2 dallo stesso host).
Arricchire gli avvisi con i dati degli eventi correlati.
Ridurre l'affaticamento da avvisi attivando un avviso finale solo quando si verifica più volte un rilevamento rumoroso e a bassa confidenza o in combinazione con altre attività sospette.
Creare un avviso per un attacco complesso e multifase in cui ogni fase è già identificata dalla propria regola.
Vantaggi dei rilevamenti compositi
I rilevamenti compositi presentano i seguenti vantaggi:
Smacherare gli attacchi multifase: gli attacchi informatici sono spesso sfaccettati e interconnessi. Il rilevamento composito rivela la narrativa più ampia dell'attacco collegando eventi di sicurezza apparentemente isolati. Ad esempio, i rilevamenti compositi possono identificare la sequenza completa di un attacco, come una violazione iniziale seguita da un'escalation dei privilegi e dall'esfiltrazione di dati.
Ridurre l'affaticamento da avvisi: le regole composite consolidano e filtrano gli avvisi rumorosi, consentendo una risposta più mirata. Questo approccio aiuta a dare la priorità agli incidenti ad alto impatto e a ridurre l'affaticamento da avvisi complessivo.
Migliorare l'accuratezza del rilevamento: combina gli insight degli eventi del modello di dati unificato (UDM), i rilevamenti delle regole, il contesto delle entità, i risultati di User and Entity Behavior Analytics (UEBA) e le tabelle di dati per creare una logica di rilevamento più accurata.
Semplificare la logica complessa: suddivide gli scenari di rilevamento complessi in regole gestibili, interconnesse e riutilizzabili per semplificare lo sviluppo e la manutenzione.
Utilizzare nelle dashboard: integra senza problemi i rilevamenti compositi come origini dati per le dashboard di Google SecOps. Puoi utilizzarli per creare visualizzazioni che riepilogano i pattern di attacco multifase, semplificando la comprensione dei rischi complessi.
Casi d'uso comuni
Questa sezione elenca alcuni casi d'uso comuni per i rilevamenti compositi.
Arricchire i rilevamenti con il contesto degli eventi non elaborati
Questo caso d'uso prevede il collegamento di un avviso di alto livello di un sistema con i log degli eventi di un altro sistema.
Obiettivo: identificare l'azione locale specifica che ha causato un avviso di alto livello.
Esempio:
Viene attivato un avviso in Google Cloud Event Threat Detection perché un workload ha effettuato una chiamata DNS a un dominio dannoso. Questo è il rilevamento.
Una regola composita viene attivata da questo rilevamento.
La regola cerca quindi i log non elaborati di Endpoint Detection and Response (EDR) (eventi) dello stesso workload in una finestra di un minuto, alla ricerca di operazioni della riga di comando che contengano lo stesso dominio dannoso.
L'avviso finale fornisce un contesto ricco: mostra che è stato contattato un dominio dannoso e il comando
sshspecifico utilizzato. Queste informazioni rendono il risultato molto più fruibile rispetto al rilevamento originale.
Monitorare l'attività utente dopo l'accesso
Un caso d'uso principale si concentra sul collegamento dell'evento di accesso di un utente con le successive attività sospette. Sebbene una regola standard per più eventi possa monitorare una sequenza breve, un rilevamento composito è più adatto per creare un profilo di rischio completo dell'intera sessione di un utente.
Obiettivo: correlare un singolo evento, come un accesso ad alto rischio, con un'ampia gamma di attività successive di "segnali deboli" per un periodo più lungo, ad esempio un giorno intero.
Esempio: crea più regole che producono rilevamenti di livello inferiore. Quindi, utilizza una regola composita con una finestra di corrispondenza lunga (ad esempio, 24 ore) per attivare un accesso sospetto iniziale e correlarlo con uno dei seguenti rilevamenti dello stesso utente:
Un utente che cancella la cronologia della riga di comando.
La creazione di un nuovo account amministratore locale.
Un caricamento di dati di grandi dimensioni in un sito di Cloud Storage personale.
Combinare con le metriche UEBA
Questo caso d'uso sfrutta le metriche UEBA esistenti come punto di partenza per un rilevamento composito per trovare comportamenti più complessi e a lungo termine.
Obiettivo: correlare un picco in una metrica UEBA con un'altra attività anomala.
Esempio:
Una regola UEBA rileva un numero eccessivo di tentativi di accesso non riusciti per un utente.
Un'altra regola UEBA rileva un numero elevato di byte in uscita dallo stesso utente.
Un rilevamento composito collega questi due risultati UEBA separati per un periodo di giorni per identificare una potenziale compromissione dell'account seguita dal furto di dati.
Rilevare i tentativi di esfiltrazione di dati
Si tratta di correlare diverse azioni utente distinte che, se combinate, potrebbero indicare un tentativo di esfiltrazione dei dati.
Obiettivo: creare un profilo di gestione dei dati rischiosa da parte di un singolo utente su più dispositivi e azioni.
Azioni correlate:
Accesso da più dispositivi (ad esempio, computer di casa e di lavoro).
Accesso a un numero di origini dati superiore al solito.
Download, stampa e invio di dati via email simultaneamente.
Conteggio del numero di documenti classificati che un utente tocca in un determinato periodo di tempo.
Presentazione di una lettera di dimissioni.
Rilevare malware multifase
Questo caso d'uso prevede l'identificazione di malware che operano lentamente per un lungo periodo, difficili da rilevare con singole regole con finestre di corrispondenza brevi.
Obiettivo: collegare il vettore di infezione iniziale con le successive azioni dannose, anche se distanti ore o giorni.
Esempio:
Un utente visita un sito web dannoso (evento di rete iniziale).
Viene scaricato ed eseguito un "file dropper" (primo evento di processo).
Molto tempo dopo, il file di rilascio scarica ed esegue un altro eseguibile (secondo evento di processo).
Per collegare i processi padre e figlio è necessaria una finestra
matchlunga, che i rilevamenti compositi possono fornire.
Ridurre il rumore degli avvisi
Questo caso d'uso prevede la gestione dei rilevamenti che sono troppo "rumorosi" o producono troppi falsi positivi da soli.
Obiettivo: perfezionare una regola rumorosa senza disattivarla o creare esclusioni complesse.
Esempio:
Imposta un rilevamento curato rumoroso su "solo rilevamento" in modo che non generi più avvisi.
Crea un rilevamento composito che utilizza l'output di quella regola curata come prima condizione.
Aggiungi una seconda condizione per fornire una qualifica aggiuntiva, ad esempio "avvisa solo se questo rilevamento si verifica 5 volte per lo stesso utente in un'ora" o se è combinato con un rilevamento di una regola diversa.
Come funzionano i rilevamenti compositi
Quando le regole soddisfano le condizioni predefinite, generano rilevamenti. Questi rilevamenti possono includere facoltativamente variabili di risultato, che acquisiscono dati o stati di eventi specifici.
Le regole composite utilizzano questi rilevamenti di altre regole come parte dei loro input. La valutazione può essere basata sulle informazioni della sezione meta della regola originale, sulle variabili di risultato e sulle variabili di corrispondenza.
In base a questa valutazione, puoi utilizzare le regole composite per creare nuovi rilevamenti da utilizzare come rappresentazione intermedia per l'indagine e l'avviso con una regola successiva. In questo modo, puoi correlare più fattori di rilevamenti diversi per identificare minacce complesse.
Per ulteriori informazioni sulla sintassi e sugli esempi, vedi Regole di rilevamento composito e Esempi.
Definire la strategia
Prima di iniziare a creare regole composite, pianifica la tua strategia per assicurarti che le nuove regole siano efficaci, efficienti e risolvano i problemi giusti.
Valuta la tua strategia di rilevamento attuale. Esamina le regole esistenti per identificare quelle troppo rumorose, che generano un numero elevato di falsi positivi o che sono eccessivamente complesse e difficili da gestire.
Determina gli scenari specifici in cui le regole composite possono fornire valore. Ciò include il rilevamento di attacchi multifase, la correlazione di più avvisi a bassa confidenza in un singolo avviso ad alta confidenza o l'arricchimento dei rilevamenti con un contesto aggiuntivo da altre origini dati.
In base alla tua valutazione, crea un piano di implementazione. Decidi quali regole rumorose devi perfezionare, quali regole complesse devi semplificare e quali nuovi rilevamenti in più fasi devi dare la priorità.
Questo piano definito fornisce una roadmap per la creazione di regole composite mirate ed efficaci. Prendi in considerazione le seguenti strategie di alto livello per ottenere il massimo valore dai rilevamenti compositi gestendo al contempo i vincoli tecnici.
Selezionare il metodo appropriato
Prima di creare un rilevamento composito, verifica se puoi ottenere il risultato richiesto con altre alternative. Analizza se puoi identificare un pattern complesso con un rilevamento UEBA esistente. Complicare eccessivamente un rilevamento potrebbe aumentare il sovraccarico di manutenzione e consumare la quota di regole.
Utilizza un rilevamento composito quando: il tuo obiettivo è correlare i risultati finali di due o più regole diverse preesistenti. In questo modo, puoi collegare fasi di un attacco concettualmente separate.
Esempio: correlare un rilevamento di una regola di download di malware con un rilevamento successivo di una regola di rilevamento di beaconing C2.
Utilizza un rilevamento UEBA esistente quando: vuoi scoprire quando un utente o un dispositivo interrompe il suo pattern di attività normale.
Esempio: rilevare automaticamente che un utente ha scaricato 100 GB di dati oggi, mentre normalmente ne scarica solo 1 GB.
Gestire le quote di regole e i punteggi di rischio
Per gestire le risorse della tua organizzazione, devi capire in che modo i diversi tipi di regole influiscono sulla quota di regole.
Le regole curate non vengono conteggiate ai fini della quota di regole personalizzate.
Le regole composite e le regole personalizzate per più eventi vengono conteggiate ai fini della quota.
Puoi utilizzare un rilevamento curato impostandolo su solo rilevamento. In questo modo, la regola curata può eseguire il rilevamento iniziale ampio senza produrre avvisi. Puoi quindi utilizzare una regola composita per applicare una logica specifica a questi risultati, fornendo più valore e gestendo strategicamente la quota.
Comprendere la differenza tra rischio e contesto
Quando progetti la logica di rilevamento, devi distinguere tra le regole che valutano il rischio e le regole che forniscono il contesto.
Il rischio è la valutazione della pericolosità di un insieme di attività. Una regola progettata per il rischio spesso aggrega più eventi o rilevamenti contestuali per esprimere un giudizio. Ad esempio, mentre un singolo tentativo di accesso non riuscito fornisce il contesto, un numero elevato di tentativi indica il rischio di un attacco di forza bruta.
Il contesto si riferisce ai dettagli fattuali che circondano un evento. Una regola progettata per il contesto arricchisce un evento con i dettagli di un altro. Ad esempio, mentre una regola può rilevare un accesso utente riuscito, una regola contestuale fornisce il contesto cruciale che questo accesso proviene da un paese nuovo e insolito.
Esempio: un rilevamento iniziale può avvisarti di un potenziale rischio, ad esempio una chiamata DNS a un dominio dannoso. Una regola composita correla quindi l'avviso con i log degli eventi in Google SecOps per trovare il processo della riga di comando specifico che ha avviato la chiamata. In questo modo, l'avviso di rischio di alto livello viene arricchito con un contesto critico e fruibile.
Utilizzare le finestre di corrispondenza lunghe in modo strategico
Le regole composite configurate con finestre di corrispondenza lunghe (ad esempio, 14 giorni) vengono eseguite meno frequentemente. La loro latenza elevata può renderle inadatte per gli avvisi sensibili al tempo. Valuta la possibilità di utilizzare queste finestre di lunga durata per rilevare attività avversarie lente e persistenti per periodi prolungati.
Utilizzare i rilevamenti per la visualizzazione
Una strategia per la gestione delle regole rumorose consiste nel trasformare il loro output in una visualizzazione su una dashboard. Questo approccio non consuma la quota di regole e può trasformare i dati a volume elevato e a bassa fedeltà in insight preziosi.
Se imposti una regola su solo rilevamento e poi tracci i relativi rilevamenti in un widget della dashboard, puoi monitorare le tendenze, identificare i valori anomali e ottenere una visualizzazione di controllo di alto livello dell'attività senza essere sopraffatto dai singoli avvisi.
Esempio: monitorare la gestione dei dati PII
Una regola monitora ogni volta che un utente gestisce dati PII sensibili.
Invece di inviare un avviso ogni volta, la regola è impostata su solo rilevamento. Un widget della dashboard
mostra quindi quali utenti si stanno avvicinando a un limite di uscita giornaliero (ad esempio,
10,000 byte). In questo modo, puoi ottenere una visualizzazione di controllo rapida del comportamento rischioso senza generare avvisi costanti.
Esempio: monitorare rischi DLP specifici:
Un widget aggrega i punteggi di rischio di un sottoinsieme molto specifico di regole DLP. In questo modo, un team specifico (ad esempio, gli amministratori di prevenzione della perdita di dati (DLP)) può monitorare solo i rischi pertinenti, filtrando il rumore di altri domini di sicurezza.
Creare rilevamenti compositi
Il seguente flusso di lavoro descrive il percorso tipico per la creazione di una regola composita. Per ulteriori informazioni sulla sintassi e sugli esempi, vedi Regole di rilevamento composito e Esempi.
Definisci lo scenario di minaccia: definisci la minaccia specifica che vuoi rilevare.
Crea o identifica le regole di input: per ogni fase dello scenario di minaccia, crea o identifica una regola di input che rileva l'attività specifica.
Definisci le condizioni di join: determina l'informazione comune che collega i rilevamenti delle regole di input, come etichette di regole, variabili o campi di rilevamento.
Crea la regola composita: scrivi la regola che acquisisce i rilevamenti delle regole di input.
Definisci la sezione
events, facendo riferimento alle regole di input per nome, ID o un'etichetta meta condivisa.Definisci la sezione
matchper specificare la chiave di join e la finestra temporale per la corrispondenza.Definisci la sezione
conditionper impostare la condizione che deve essere soddisfatta affinché venga attivato l'avviso finale.
Testa ed esegui il deployment della catena di regole: ti consigliamo di eseguire manualmente una ricerca retroattiva per ogni regola nella sequenza.
Quando utilizzi la funzionalità Testa regola su una regola composita, questa viene eseguita solo sui rilevamenti preesistenti che corrispondono ai criteri di input della regola. Non esegue automaticamente le regole sottostanti per generare nuovi input per il test, il che significa che non puoi convalidare un'intera catena di regole in una singola azione.
Per eseguire una ricerca retroattiva per la sequenza di regole:
Avvia manualmente una ricerca retroattiva dalla prima regola della sequenza.
Attendi il completamento.
Continua con la regola successiva.
Esempio:
rule CheckCuratedDetection_with_EDR_and_EG {
meta:
author = "noone@cymbal.com"
events:
$d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
$d.detection.collection_elements.references.event.network.dns.questions.name = $domain
$d.detection.collection_elements.references.event.principal.asset.hostname = $hostname
$e.metadata.log_type = "LIMACHARLIE_EDR"
$e.metadata.product_event_type = "NETWORK_CONNECTIONS"
$domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
$hostname = re.capture($e.principal.hostname, "([^.]*)")
$prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
$prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
$prevalence.graph.entity.hostname = $domain
$prevalence.graph.entity.domain.prevalence.day_count = 10
$prevalence.graph.entity.domain.prevalence.rolling_max <= 5
$prevalence.graph.entity.domain.prevalence.rolling_max > 0
match:
$hostname over 1h
outcome:
$risk_score = 80
$CL_target = array($domain)
condition:
$e and $d and $prevalence
}
Visualizzare i risultati del rilevamento composito
Puoi visualizzare i risultati del rilevamento composito
nella pagina Rilevamenti. Un avviso è un rilevamento composito quando la colonna Input
mostra Rilevamento come origine e la colonna Tipo di rilevamento
mostra un'etichetta Avviso con un numero accanto (ad esempio, Alert (3)).
Nota: se hai sia SIEM sia SOAR, puoi anche visualizzare i risultati nella scheda Richieste.
Ottimizzare i rilevamenti compositi
Ti consigliamo di seguire queste best practice per la creazione di regole composite.
Ottimizzare per la latenza
Per una latenza minima nelle pipeline di rilevamento, utilizza le regole per singoli eventi, ad esempio per il trigger iniziale. Le regole composite possono utilizzare i relativi rilevamenti per eseguire correlazioni più complesse con altri eventi, entità o rilevamenti, il che contribuisce a ridurre la latenza complessiva.
Utilizzare metodi efficienti per unire i rilevamenti
Ti consigliamo di utilizzare le variabili di risultato, le etichette meta e le variabili di corrispondenza per unire i rilevamenti. Questi metodi forniscono risultati più deterministici e affidabili rispetto all'utilizzo di campioni di eventi. Le etichette meta sono particolarmente flessibili perché ti consentono di classificare le regole in modo che una regola composita possa scegliere come target qualsiasi rilevamento con quell'etichetta.
Ad esempio, se più regole condividono la stessa etichetta meta
tactic: exfiltration, puoi avere una regola composita che sceglie come target qualsiasi rilevamento
in cui l'etichetta della tattica ha il valore exfiltration.
Quando utilizzi nocase con le variabili di join nei rilevamenti compositi, potresti ricevere il seguente errore di analisi semantica:
semantic analysis: match variable <variable_name> is not assigned to an event field.
Nei rilevamenti compositi, la prima assegnazione di variabili (ad esempio, $username = $fact1...)
definisce le proprietà della variabile, inclusa la distinzione tra maiuscole e minuscole quando si utilizza
nocase. L'applicazione di nocase alle successive assegnazioni di variabili della stessa variabile di join (ad esempio, $username = $fact2...) viene interpretata dal compilatore come una ridefinizione in conflitto o un vincolo ridondante, con conseguente errore semantico.
Migliorare i rilevamenti con la libreria di funzioni
Puoi utilizzare la libreria di funzioni YARA-L in punti strategici all'interno di una regola composita per aumentare l'indicatore e aggiungere una logica più complessa.
Gestire gli aggiornamenti delle regole
Quando aggiorni una regola utilizzata in una o più regole composite, il sistema crea automaticamente una nuova versione della regola. Le regole composite utilizzano automaticamente la nuova versione. Ti consigliamo di testare l'intera sequenza di regole aggiornata per verificare il comportamento previsto.
Limitazioni
Quando progetti e implementi rilevamenti compositi, tieni presente le seguenti limitazioni:
Disponibilità dei dati delle richieste SOAR: i rilevamenti compositi non hanno accesso a tutti i dati delle richieste SOAR. La logica delle regole che tenta di filtrare o escludere le richieste in base allo stato (ad esempio,
$edetection.feedback_summary.status != "CLOSED") non è supportata.Regole composite: Google SecOps supporta una profondità massima di 10 per le regole composite. La profondità è il numero di regole da una regola di base alla regola composita finale.
Regole di solo rilevamento: hanno una finestra di corrispondenza massima di 14 giorni e sono soggette a un limite di rilevamento giornaliero di 10.000 rilevamenti per regola.
Variabili di risultato: ogni regola è limitata a un massimo di 20 variabili di risultato. Inoltre, ogni variabile di risultato ripetuta è limitata a 25 valori.
Campioni di eventi: in una regola vengono memorizzati solo 10 campioni di eventi per variabile di evento, ad esempio 10 per
$e1e 10 per$e2.
Per ulteriori informazioni sui limiti di rilevamento, vedi Limiti di rilevamento.
Passaggi successivi
Per informazioni su come creare regole di rilevamento composito, vedi Regole di rilevamento composito ed Esempi.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.