Informazioni sui ritardi nel rilevamento delle regole

Supportato in:

Questo documento spiega i ritardi nel rilevamento delle regole in Google Security Operations, identifica i fattori che contribuiscono alle pipeline di importazione ed elaborazione, delinea approcci strutturati per la risoluzione dei problemi e fornisce tecniche per ridurre la latenza di rilevamento.

Panoramica delle regole di rilevamento

Le regole di rilevamento esaminano i log non elaborati normalizzati, sia gli eventi regolari sia quelli del modello di dati universale (UDM) delle entità, per generare rilevamenti di sicurezza in base alle specifiche delle regole. Gli eventi UDM entità in genere contengono informazioni di contesto come i metadati di utenti o asset. Le regole di rilevamento possono anche valutare i rilevamenti generati in precedenza per produrre avvisi compositi.

Ritardi previsti e imprevisti

La latenza di rilevamento varia in base alla logica delle regole, alle dipendenze dei dati e ai cicli di elaborazione del sistema. I ritardi sono suddivisi in due tipi:

  • Ritardi previsti: ritardi dovuti a fattori strutturali, come il processo di importazione, il tipo di regola, la frequenza di esecuzione, il metodo di generazione del rilevamento, la durata della finestra di corrispondenza e i limiti di sistema noti. Puoi ridurre al minimo i ritardi previsti ottimizzando le configurazioni delle regole di rilevamento e i parametri di pianificazione.
  • Ritardi imprevisti: ritardi causati da condizioni della pipeline esterne o dinamiche, inclusi colli di bottiglia nella distribuzione dei log dalle origini dati, latenza di elaborazione temporanea all'interno dei servizi Google SecOps, disponibilità ritardata del contesto e cicli di riarricchimento UDM.

Metodi di generazione del rilevamento

Google SecOps genera rilevamenti delle regole tramite le seguenti pipeline di esecuzione:

  • Motore di streaming: una pipeline ad alta velocità che valuta continuamente le regole a evento singolo standard e in finestra in tempo quasi reale (in genere entro 5 minuti dall'importazione). Gli eventi in arrivo in ritardo e gli arricchimenti retroattivi vengono valutati continuamente durante l'esecuzione standard.
  • Motore di query: valuta le regole che richiedono la correlazione di eventi basata sul tempo in più eventi o unioni di dati esterni:
    • Regole complesse per eventi singoli: includono regole per eventi singoli che eseguono query su elenchi di riferimento o tabelle di dati.
    • Regole multievento: esegue query sui dati in blocchi batch di tempo evento (ad esempio intervalli di 10 minuti o 1 ora oppure match_window / 10 per finestre superiori a 48 ore) in base alle pianificazioni configurate.
  • Regole eseguite sui dati storici: valuta le regole in modo retroattivo rispetto ai log storici tramite le ricerche retroattive. I rilevamenti vengono visualizzati al termine della scansione cronologica.
  • Riarricchimento degli eventi UDM: valuta nuovamente i blocchi temporali elaborati in precedenza quando vengono aggiunti nuovi dati di contesto o entità aggiornati agli eventi storici.

Fattori che contribuiscono ai ritardi nel rilevamento delle regole

La velocità con cui vengono visualizzati i rilevamenti dipende dalla complessità delle regole, dagli intervalli di pianificazione, dalla latenza di importazione dati e dalle pipeline di arricchimento del contesto.

Tipi di regole e complessità

Le regole di rilevamento rientrano in diverse categorie con profili di latenza diversi:

Regole per eventi singoli

Le regole a evento singolo vengono eseguite quasi in tempo reale sul motore di streaming continuo e offrono la latenza di rilevamento più bassa. Queste regole valutano i singoli eventi senza unire set di dati esterni, tabelle di dati o finestre di corrispondenza multievento.

Regole complesse per eventi singoli

Queste regole valutano singoli eventi, ma incorporano dipendenze di dati aggiuntive:

  • Regole per eventi singoli con finestra: regole per eventi singoli che includono una sezione match (ad esempio, la valutazione se un singolo evento corrisponde a una condizione in un intervallo di tempo). Queste regole vengono valutate quasi in tempo reale sul motore di streaming continuo man mano che i dati vengono importati.
  • Fai riferimento alle regole per eventi singoli: regole per eventi singoli che confrontano gli attributi degli eventi con elenchi di riferimento o tabelle di dati.

Regole multi-evento

Le regole per più eventi mettono in correlazione due o più condizioni di eventi UDM in un periodo di corrispondenza specificato ed eseguono intervalli batch pianificati.

  • Regole standard multi-evento: aggrega più eventi in finestre temporali ed esegui a intervalli di 10 minuti o 1 ora (o match_window / 10 per finestre superiori a 48 ore).
  • Regole sensibili al contesto: metti in correlazione i dati sugli eventi con gli eventi delle entità UDM (ad esempio user_context o asset_context) utilizzando l'analisi sensibile al contesto. Poiché le regole sensibili al contesto si basano su più feed di dati, sono più sensibili alla tempistica di importazione. Per saperne di più, vedi Utilizzare dati arricchiti dal contesto nelle regole.

Frequenza di esecuzione delle regole

La frequenza di esecuzione configurata determina la frequenza con cui il motore di query valuta i blocchi di tempo degli eventi:

  • Quasi in tempo reale: valutazione continua per le regole per eventi singoli (standard e in finestra).
  • Frequenza di 10 minuti: disponibile per le regole multi-evento con finestre di corrispondenza inferiori a 60 minuti.
  • Frequenza di 1 ora: intervallo predefinito per le regole multi-evento con finestre di corrispondenza di 48 ore o meno.
  • match_window / 10Frequenza: assegnata automaticamente per le regole multi-evento con finestre di corrispondenza superiori a 48 ore (ad esempio, esecuzione ogni 10 ore per una finestra di corrispondenza di 100 ore o ogni 24 ore per una finestra di 10 giorni).

Durata della finestra di corrispondenza

Per le regole multi-evento, la durata della finestra di corrispondenza definisce il periodo di osservazione necessario per aggregare gli eventi. I rilevamenti non possono essere visualizzati finché non è trascorso l'intero periodo di tempo.

Ritardo di importazione dei log

Il ritardo di importazione è il tempo trascorso tra il momento in cui si verifica un evento nell'origine e il momento in cui Google SecOps riceve e analizza il log.

Se un evento arriva dopo la valutazione pianificata iniziale per quel blocco di tempo, non viene eseguito la prima volta. Il sistema acquisisce i dati in arrivo in ritardo nelle successive esecuzioni automatiche in background (esecuzioni di riconciliazione), che si verificano circa 4 ore (e facoltativamente 30 ore con il completamento dell'arricchimento) dopo l'esecuzione principale.

  • Esempio: una regola correla l'evento A (ora evento 09:03) e l'evento B (ora evento 09:05) in un intervallo di 30 minuti. Se l'evento A arriva alle 10:05 (un'ora in ritardo), non viene eseguito nell'intervallo iniziale dalle 9:00 alle 9:30. Il sistema rivaluta il blocco durante un'esecuzione di riconciliazione successiva circa 4 ore dopo l'esecuzione principale (intorno alle 14:00), generando il rilevamento circa 5 ore dopo l'evento.

Discrepanze del fuso orario

Per impostazione predefinita, Google SecOps interpreta i timestamp dei log come UTC. Se un'origine log omette un offset del fuso orario esplicito, il sistema considera il timestamp come UTC, il che può far sembrare che il log arrivi in ritardo anche se ricevuto immediatamente.

  • Esempio: un evento si verifica alle 10:00 ora della costa orientale (15:00 UTC) e arriva a Google SecOps alle 15:05 UTC senza metadati del fuso orario. Il sistema interpreta il timestamp come 10:00 UTC, creando un ritardo di importazione percepito di 5 ore che posticipa la valutazione delle regole a un'esecuzione di aggiornamento in background.

Soluzioni alternative: per risolvere le discrepanze relative al fuso orario:

  • Configura l'origine log in modo che includa offset del fuso orario UTC espliciti nei timestamp degli eventi.
  • Contatta l'assistenza per impostare un override del fuso orario per il feed di importazione specifico.
  • Utilizza un processore BindPlane per normalizzare i timestamp del corpo dei log in formato UTC prima dell'importazione. Per maggiori informazioni, consulta Modificare i timestamp del corpo dei log utilizzando BindPlane.

Join contestuali e arricchimento dei dati

Google SecOps arricchisce gli eventi UDM aggiungendo metadati di identità, asset e minacce da fonti secondarie. I ritardi nella disponibilità del contesto possono estendere i tempi di rilevamento.

Meccanismi di alias e arricchimento

L'assegnazione di alias e l'arricchimento mettono in correlazione gli indicatori non elaborati con il contesto organizzativo:

  • Assegnazione di alias: identifica e collega diversi identificatori per la stessa entità in più origini dati (ad esempio, mappa un indirizzo IP dai log DHCP a un indirizzo MAC e a un nome host come alex-macbook oppure mappa un ID utente al titolo di lavoro di un dipendente).
  • Arricchimento: compila i campi degli eventi UDM normalizzati con il contesto con alias (ad esempio, compila $udm.event.principal.hostname quando nell'evento non elaborato è presente solo un indirizzo IP).

I tipi di arricchimento supportati includono asset, utenti, processi, metadati hash dei file, località geografiche e risorse cloud. Per saperne di più, consulta la panoramica dell'arricchimento e dell'assegnazione di alias UDM.

Ri-arricchimento degli eventi UDM

Il sistema aggiorna continuamente gli eventi storici man mano che le fonti di contesto si evolvono:

  • Modifiche ai dati sottostanti: gli eventi storici possono essere aggiornati fino a 24 ore dopo l'importazione man mano che arrivano nuovi dati contestuali.
  • Aggiornamenti del sistema di arricchimento: quando vengono aggiornati i metadati delle entità, la geolocalizzazione IP o la threat intelligence di VirusTotal, il motore delle regole rivaluta i blocchi storici (in genere durante le esecuzioni di adeguamento o il rielaborazione pianificata) per generare rilevamenti con contesto aggiornato.
  • Dati di contesto ritardati: se i dati di contesto (ad esempio un nome host) arrivano un giorno dopo il log eventi, il sistema arricchisce nuovamente l'evento UDM e le successive esecuzioni di aggiustamento valutano il record arricchito.
  • Modifiche al contesto: se un aggiornamento dell'arricchimento modifica un attributo evento (ad esempio, se aggiorna la geolocalizzazione IP da USA a Canada), le regole che corrispondono al valore aggiornato attivano i rilevamenti durante le successive rivalutazioni.

Elaborazione del grafico di contesto delle entità (ECG)

Il grafico del contesto delle entità (ECG) correla gli indicatori di compromissione (IOC) e i dati del grafico degli asset aziendali. Poiché la pipeline ECG si basa sull'elaborazione batch (che può richiedere 30 ore o fino a diversi giorni a seconda del volume di dati), le regole che fanno riferimento ai campi graph.entity generano rilevamenti dopo che le relazioni del grafico sono state calcolate completamente.

Esecuzioni di regole e RetroHunt storiche

L'esecuzione di una regola sui dati storici genera rilevamenti solo dopo il completamento della scansione retrohunt nell'intervallo di tempo selezionato.

  • Workflow di arricchimento retroattivo:
    1. Un evento arriva alle 13:00 con ip_address = 10.0.0.5 (nome host sconosciuto).
    2. Alle 14:30 arriva un log DHCP che collega 10.0.0.5 a workstation-123.
    3. La pipeline di aliasing aggiorna l'evento storico delle 13:00 con principal.hostname = workstation-123.
    4. Le riproduzioni successive delle regole valutano il nome host arricchito e mostrano i rilevamenti che non sono stati attivati durante l'esecuzione iniziale.

Elenchi di riferimento

Le regole che eseguono query sugli elenchi di riferimento vengono valutate in base alla versione più recente dell'elenco al momento dell'esecuzione. L'aggiornamento di un elenco di riferimenti può causare la produzione retroattiva di rilevamenti da parte delle regole pianificate rispetto ai log inseriti in precedenza.

Regole di non esistenza

Per evitare falsi positivi, il sistema introduce un buffer minimo di un'ora prima di valutare le regole che verificano le condizioni di non esistenza (come !$e o #e=0), garantendo che tutti i log correlati abbiano il tempo di arrivare.

Limitazioni del trattamento dei dati e del conguaglio

Quando valuti la latenza di rilevamento, tieni presente i seguenti comportamenti del sistema:

  • Elaborazione dell'arricchimento: l'arricchimento del contesto può aggiornare gli eventi UDM storici fino a 24 ore dopo l'importazione iniziale.
  • Cicli di aggiustamento: le regole multi-evento vengono eseguite nuovamente in automatico circa 4 ore (e, facoltativamente, 30 ore) dopo l'esecuzione principale per acquisire i dati in arrivo in ritardo. Per saperne di più, consulta Informazioni sulle ripetizioni delle regole e sul MTTD.
  • Limiti di rilevamento: per i limiti di capacità e throttling della piattaforma, vedi Informazioni sui limiti di rilevamento.

Risolvere i problemi relativi ai ritardi nel rilevamento delle regole

Per diagnosticare il motivo per cui una regola ha generato un rilevamento ritardato, esamina le seguenti euristiche e fasi della pipeline nella console Google SecOps:

  • Esamina i metadati e la pianificazione delle regole: nella Dashboard regole, controlla le colonne Nome regola, Tipo di regola e Pianificazione regola per identificare il motore di esecuzione della regola e la frequenza di valutazione della base di riferimento.
  • Confronta l'ora dell'evento con l'ora di importazione: individua il rilevamento nella scheda Rilevamenti e confronta il timestamp dell'evento con il timestamp dell'importazione. Se il divario tra l'ora dell'evento e l'ora di importazione supera i 30 minuti, la latenza è stata causata da ritardi nella distribuzione dei log all'origine o durante la raccolta. I rilevamenti generati da dati sugli eventi arrivati con un ritardo superiore a 30 minuti, esecuzioni di aggiustamento automatico, pipeline di rielaborazione o retrocaccia mostrano un'icona nella colonna Tipo di rilevamento.
  • Esamina le dipendenze dell'origine del contesto: controlla se la regola fa riferimento all'arricchimento principal, all'assegnazione di alias UDM o ai campi graph.entity. Le pipeline contestuali vengono elaborate in modo asincrono e possono mostrare rilevamenti durante le successive esecuzioni di adeguamento.
  • Verifica la compatibilità della frequenza e della finestra di corrispondenza: verifica che la frequenza di esecuzione configurata corrisponda alle dimensioni della finestra di corrispondenza (ad esempio, assicurati che una regola con una finestra di corrispondenza di 15 minuti sia pianificata per 10 minuti o 1 ora).
  • Controlla le interruzioni dei feed di dati: esamina i log di importazione e le dashboard di gestione dei feed per verificare la presenza di ritardi nell'importazione o interruzioni temporanee dell'origine.

Suggerimenti per ridurre i ritardi di rilevamento

Per ridurre al minimo i ritardi di rilevamento nel tuo ambiente, applica le seguenti tecniche di ottimizzazione:

  • Ottimizza la frequenza di esecuzione delle regole:
    • Utilizza Quasi in tempo reale per le regole per eventi singoli (standard e con finestra).
    • Configura una pianificazione di 10 minuti per le regole multi-evento con finestre di corrispondenza inferiori a 60 minuti.
    • Utilizza 1 ora per le regole con finestre di corrispondenza comprese tra 1 e 48 ore in cui è necessario un avviso rapido.
  • Regola le durate delle finestre di corrispondenza: imposta le finestre di corrispondenza sulla durata minima necessaria per acquisire il comportamento correlato della minaccia.
  • Elimina i colli di bottiglia nella distribuzione dei log: assicurati che gli agenti di inoltro e i raccoglitori inviino immediatamente i dati degli eventi per evitare che i log perdano la finestra di esecuzione iniziale.
  • Convalida le configurazioni del fuso orario: assicurati che le origini log forniscano offset UTC espliciti per evitare ritardi di importazione percepiti di oltre 5 ore.
  • Contesto di controllo e condizioni di non esistenza: utilizza i campi arricchiti di contesto e le condizioni di non esistenza (!$e) solo quando richiesto dalla logica di rilevamento, in quanto introducono periodi di buffering intenzionali.

Passaggi successivi

Per esplorare i concetti di pianificazione correlati e i flussi di lavoro di configurazione, consulta i seguenti documenti:

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.