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, illustra 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 UDM (Universal Data Model) regolari sia quelli delle entità, per generare rilevamenti di sicurezza in base alle specifiche delle regole. Gli eventi UDM delle entità in genere contengono informazioni di contesto come i metadati degli utenti o degli 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 derivanti da fattori strutturali, come il processo di importazione, il tipo di regola, la frequenza di esecuzione, il metodo di generazione dei rilevamenti, 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 esterne o dinamiche della pipeline, tra cui 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 nuovo arricchimento UDM.

Metodi di generazione dei rilevamenti

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

  • Motore di flussi di dati: una pipeline ad alta velocità che valuta continuamente le regole standard e a evento singolo con finestra quasi in tempo reale (in genere entro 5 minuti dall'importazione). Gli eventi in ritardo e gli arricchimenti retroattivi vengono valutati continuamente durante l'esecuzione standard.
  • Motore di query: valuta le regole che richiedono la correlazione degli eventi basata sul tempo tra più eventi o unioni di dati esterni:
    • Regole complesse per eventi singoli: include regole per eventi singoli che eseguono query su elenchi di riferimento o tabelle di dati.
    • Regole per più eventi: esegue query sui dati in blocchi raggruppati di tempo dell'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.
  • Esecuzione delle regole sui dati storici: valuta le regole in modo retroattivo rispetto ai log storici tramite retrohunt. I rilevamenti vengono visualizzati al termine della scansione della cronologia.
  • Nuovo arricchimento degli eventi UDM: rivaluta i blocchi di tempo elaborati in precedenza quando vengono aggiunti nuovi contesti o dati delle 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 di più eventi.

Regole complesse per eventi singoli

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

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

Regole per più eventi

Le regole per più eventi correlano due o più condizioni di eventi UDM in una finestra di corrispondenza specificata e vengono eseguite a intervalli di batch pianificati.

  • Regole standard per più eventi: aggregano più eventi in finestre temporali ed eseguono l'azione a intervalli di 10 minuti o 1 ora (o match_window / 10 per finestre superiori a 48 ore).
  • Regole sensibili al contesto: mettono in correlazione i dati sugli eventi con gli eventi delle entità UDM (come 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 ai tempi di importazione. Per saperne di più, consulta Utilizza i 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 con 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 con più eventi con finestre di corrispondenza di 48 ore o meno.
  • Frequenza match_window / 10: assegnata automaticamente per le regole multievento 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 con più eventi, la durata della finestra di corrispondenza definisce il periodo di osservazione richiesto per aggregare gli eventi. I rilevamenti non possono essere visualizzati fino al termine dell'intera finestra temporale.

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 iniziale pianificata per quel blocco di tempo, non viene incluso nella prima esecuzione. Il sistema acquisisce i dati in ritardo nelle successive esecuzioni automatiche in background (esecuzioni di conguaglio), che si verificano circa 4 ore (e facoltativamente 30 ore con la completezza dell'arricchimento) dopo l'esecuzione principale.

  • Esempio: una regola mette in correlazione l'evento A (ora dell'evento 09:03) e l'evento B (ora dell'evento 09:05) in una finestra di 30 minuti. Se l'evento A arriva alle 10:05 (con un'ora di ritardo), non viene incluso nell'esecuzione iniziale per il blocco dalle 09:00 alle 09:30. Il sistema rivaluta il blocco durante una successiva esecuzione di true-up circa 4 ore dopo l'esecuzione principale (intorno alle 14:00), generando il rilevamento circa 5 ore dopo l'evento.

Per informazioni sulla latenza di indicizzazione upstream nei feed di polling dell'API di terze parti, consulta Eventi in ritardo nei feed di polling.

Discrepanze di fuso orario

Per impostazione predefinita, Google SecOps interpreta i timestamp dei log come UTC. Se un'origine log omette un offset esplicito del fuso orario, il sistema tratta 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 Eastern Time (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 della regola a un'esecuzione di conguaglio in background.

Soluzioni alternative: per risolvere le discrepanze relative ai fusi orari:

  • Configura l'origine log in modo da includere i fusi orari 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 del log in UTC prima dell'importazione. Per saperne di più, consulta Modifica dei timestamp del corpo del log utilizzando BindPlane.

Join contestuali e arricchimento dei dati

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

Meccanismi di aliasing e arricchimento

L'aliasing e l'arricchimento correlano gli indicatori non elaborati con il contesto dell'organizzazione:

  • Aliasing: identifica e collega diversi identificatori per la stessa entità tra le origini dati (ad esempio, mappando un indirizzo IP dai log DHCP a un indirizzo MAC e a un nome host come alex-macbook o mappando un ID utente a un 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 degli hash dei file, posizioni geografiche e risorse cloud. Per saperne di più, consulta Panoramica dell'arricchimento e dell'aliasing di UDM.

Nuovo arricchimento degli eventi UDM

Il sistema aggiorna continuamente gli eventi storici man mano che le origini del 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 di contesto.
  • Aggiornamenti del sistema di arricchimento: quando i metadati delle entità, la geolocalizzazione IP o la threat intelligence di VirusTotal vengono aggiornati, il motore delle regole rivaluta i blocchi storici (in genere durante le esecuzioni di true-up pianificate o la rielaborazione) per generare rilevamenti con un 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 true-up valutano il record arricchito.
  • Modifiche al contesto: se un aggiornamento di arricchimento modifica un attributo dell'evento (ad esempio aggiornando una geolocalizzazione IP da USA a Canada), le regole che corrispondono al valore aggiornato attivano i rilevamenti durante le rivalutazioni successive.

Elaborazione del grafico di contesto delle entità (ECG)

L'Entity Context Graph (ECG) mette in correlazione 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 completamente calcolate.

Esecuzioni di regole e RetroHunt storiche

L'esecuzione di una regola sui dati storici genera rilevamenti solo dopo il completamento della scansione di 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 successive riproduzioni 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 all'ultima versione dell'elenco al momento dell'esecuzione. L'aggiornamento di un elenco di riferimento può far sì che le regole pianificate producano rilevamenti retroattivamente rispetto ai log importati 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), assicurando che tutti i log correlati abbiano il tempo di arrivare.

Limitazioni relative al trattamento dati e al 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 per più eventi vengono eseguite di nuovo automaticamente 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 sull'MTTD.
  • Limiti di rilevamento: per i limiti di capacità e limitazione della piattaforma, consulta Informazioni sui limiti di rilevamento.

Risolvi 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 fasi di euristica e pipeline nella console Google SecOps:

  • Esamina i metadati e la pianificazione della regola: 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 quello 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 che arrivano con più di 30 minuti di ritardo, esecuzioni di true-up automatiche, pipeline di ritrattamento o retrohunt mostrano un'icona nella colonna Tipo di rilevamento.
  • Esamina le dipendenze delle origini di contesto: verifica se la regola fa riferimento all'arricchimento principal, all'aliasing UDM o ai campi graph.entity. Le pipeline di contesto vengono elaborate in modo asincrono e possono mostrare rilevamenti durante le successive esecuzioni di true-up.
  • 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 se ci sono interruzioni del 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 per più eventi 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.
  • Ottimizza la durata delle finestre di corrispondenza: imposta le finestre di corrispondenza sulla durata minima necessaria per acquisire il comportamento della minaccia correlata.
  • Elimina i colli di bottiglia nella distribuzione dei log: assicurati che i forwarder e i collector inviino immediatamente i dati sugli eventi per evitare che i log non vengano inclusi nella finestra di esecuzione iniziale.
  • Convalida le configurazioni del fuso orario: assicurati che le origini dei 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 dal contesto e le condizioni di non esistenza (!$e) solo se richiesto dalla logica di rilevamento, poiché introducono periodi di buffering intenzionali.

Passaggi successivi

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

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