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 UDM (Universal Data Model) di entità che quelli regolari, per generare rilevamenti di sicurezza in base alle specifiche delle regole. In genere, gli eventi UDM di entità 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 non previsti

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 classificati 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 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 non previsti: 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 con finestra in tempo 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 degli eventi basata sul tempo tra più eventi o join di dati esterni:
    • Regole a evento singolo complesse: include regole a evento singolo che eseguono query su elenchi di riferimento o tabelle di dati.
    • Regole a più eventi: esegue query sui dati in blocchi batch 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.
  • Le regole vengono eseguite sui dati storici: valuta le regole retroattivamente rispetto ai log storici tramite RetroHunt. I rilevamenti vengono visualizzati al termine della scansione storica.
  • Riarricchimento degli eventi UDM: rivaluta i blocchi di tempo elaborati in precedenza quando vengono aggiunti nuovi dati di contesto o di entità 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 a evento singolo

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 a più eventi.

Regole a evento singolo complesse

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

  • Regole a evento singolo con finestra: regole a evento singolo che includono una sezione match (ad esempio, valutare 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 durante l'importazione dei dati.
  • Regole a evento singolo di riferimento: regole a evento singolo che confrontano gli attributi degli eventi con elenchi di riferimento o tabelle di dati.

Regole a più eventi

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

  • Regole a più eventi standard: aggregano più eventi in finestre temporali e vengono eseguite a intervalli di 10 minuti o 1 ora (oppure match_window / 10 per finestre superiori a 48 ore).
  • Regole sensibili al contesto: correlano i dati degli eventi con gli eventi di 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ù, consulta Utilizzare 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 a evento singolo (standard e con finestra).
  • Frequenza di 10 minuti: disponibile per le regole a più eventi con finestre di corrispondenza inferiori a 60 minuti.
  • Frequenza di 1 ora: intervallo predefinito per le regole a più eventi con finestre di corrispondenza di 48 ore o meno.
  • Frequenza match_window / 10: assegnata automaticamente per le regole a più eventi 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 a più eventi, 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 intervallo di tempo.

Ritardo nell'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 ed esegue il parsing del 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 arrivo in ritardo nelle successive esecuzioni automatiche in background (esecuzioni di allineamento), che si verificano circa 4 ore (e facoltativamente 30 ore con la completezza dell'arricchimento) dopo l'esecuzione principale.

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

Discrepanze nei fusi orari

Per impostazione predefinita, Google SecOps interpreta i timestamp dei log come UTC. Se un'origine log omette una differenza di fuso orario esplicita, il sistema tratta il timestamp come UTC, il che può far sembrare che il log sia arrivato in ritardo anche se è stato 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 delle regole a un'esecuzione di allineamento in background.

Soluzioni alternative: per risolvere le discrepanze nei fusi orari:

  • Configura l'origine log in modo che includa differenze di fuso orario UTC esplicite nei timestamp degli eventi.
  • Contatta l'assistenza per impostare una sostituzione 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 Modificare i 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 da origini secondarie. I ritardi nella disponibilità del contesto possono estendere la tempistica di rilevamento.

Meccanismi di aliasing e arricchimento

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

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

Riarricchimento degli eventi UDM

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

  • Modifiche ai dati sottostanti: gli eventi storici possono essere aggiornati fino a 24 ore dopo l'importazione quando 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 allineamento o la rielaborazione pianificate) per generare rilevamenti con il contesto aggiornato.
  • Dati di contesto ritardati: se i dati di contesto (ad esempio un nome host) arrivano un giorno dopo il log degli eventi, il sistema riarricchisce l'evento UDM e le successive esecuzioni di allineamento valutano il record arricchito.
  • Modifiche del contesto: se un aggiornamento dell'arricchimento modifica un attributo di un evento (ad esempio, aggiornando una 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 di 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 storiche e RetroHunt

L'esecuzione di una regola sui dati storici genera rilevamenti solo al termine della scansione RetroHunt nell'intervallo di tempo selezionato.

  • Flusso di lavoro 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 visualizzano 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 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 (ad esempio !$e o #e=0), assicurandosi che tutti i log correlati abbiano il tempo di arrivare.

Limitazioni dell'elaborazione dei dati e dell'allineamento

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

Risolvere i problemi di ritardo 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 delle regole, controlla le colonne Nome regola, Tipo di regola e Pianificazione delle regole per identificare il motore di esecuzione della regola e la frequenza di valutazione di base.
  • 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 di 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 nell'origine o durante la raccolta. I rilevamenti generati da dati degli eventi che arrivano con un ritardo superiore a 30 minuti, le esecuzioni di allineamento automatiche, le pipeline di rielaborazione o le RetroHunt mostrano un'icona nella colonna Tipo di rilevamento.
  • Esamina le dipendenze delle origini di contesto: controlla 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 visualizzare i rilevamenti durante le successive esecuzioni di allineamento.
  • 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).
  • Verifica la presenza di 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 nel rilevamento

Per ridurre al minimo i ritardi nel 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 a evento singolo (standard e con finestra).
    • Configura una pianificazione di 10 minuti per le regole a 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 delle minacce correlate.
  • Elimina i colli di bottiglia nella distribuzione dei log: assicurati che i forwarder e i raccoglitori inviino immediatamente i dati degli eventi per evitare che i log non vengano inclusi nella finestra di esecuzione iniziale.
  • Convalida le configurazioni dei fusi orari: assicurati che le origini log forniscano differenze di fuso orario UTC esplicite per evitare ritardi di importazione percepiti di 5 o più ore.
  • Controlla le condizioni di contesto e di non esistenza: utilizza i campi arricchiti dal contesto e le condizioni di non esistenza (!$e) solo quando richiesto dalla logica di rilevamento, poiché questi 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.