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, delinea gli approcci per la risoluzione dei problemi e suggerisce tecniche per ridurre i ritardi, ove possibile.

Regole di rilevamento

Le regole di rilevamento esaminano gli eventi Universal Data Model (UDM) regolari e delle entità, ovvero i log non elaborati normalizzati, per generare rilevamenti in base alle specifiche della regola. Gli eventi UDM delle entità in genere contengono informazioni contestuali come i dettagli dell'utente o dell'asset. Le regole generano rilevamenti anche in base a rilevamenti generati in precedenza.

Ritardi previsti e imprevisti

I tempi di rilevamento sono soggetti a ritardi di elaborazione. Mentre alcune regole vengono attivate in tempo quasi reale, altre potrebbero richiedere diversi minuti o ore per essere completate. Fattori come il tipo di regola, la frequenza di esecuzione e il metodo di generazione del rilevamento influiscono su questi ritardi. Questo documento esamina questi e altri fattori di ritardo.

Classifichiamo i ritardi come previsti o imprevedibili.

  • Ritardi previsti: questi ritardi sono dovuti al processo di importazione e alle scelte di configurazione effettuate durante l'impostazione della regola di rilevamento. Ad esempio, il tempo impiegato per creare un rilevamento è un fattore. Questi ritardi dipendono da fattori strutturali noti, come il tipo di regola, la frequenza di esecuzione, il metodo di generazione del rilevamento, le limitazioni note e altri fattori prevedibili.
    Puoi ridurre al minimo questi ritardi modificando o ottimizzando le configurazioni delle regole di rilevamento, come descritto in questo documento.
    Per maggiori dettagli, vedi Suggerimenti per ridurre i ritardi.

  • Ritardi imprevisti: si tratta di ritardi specifici per regole o eventi causati da molti fattori, tra cui ritardi nell'arrivo dei dati degli eventi a Google SecOps, rallentamenti temporanei nell'elaborazione delle pipeline all'interno dei servizi Google SecOps, ri-arricchimento e altri ritardi nell'elaborazione dei dati.

Analizzare i ritardi nel rilevamento delle regole

Per analizzare i ritardi nel rilevamento delle regole, trova informazioni sulla regola e sui fattori circostanti:

  1. Nella console Google SecOps, vai a Rilevamento > Regole e rilevamenti.

    La dashboard regole mostra i metadati delle regole, come Rule name, Rule type e Run frequency.

    Per maggiori dettagli, vedi Visualizzare le regole nella dashboard delle regole.

  2. Nella dashboard delle regole, fai clic sul nome di una regola per visualizzare la cronologia dei rilevamenti e altri dettagli per una regola specifica.

  3. Per l'esecuzione di una determinata regola, esistono diversi fattori che possono influire sulla latenza di rilevamento. Dimensioni come Rule type, Run frequency, Event type, Event time e Ingested time sono buone euristiche per capire perché un particolare rilevamento è stato ritardato.

Un'icona nella colonna Tipo di rilevamento identifica i rilevamenti generati da dati degli eventi ritardati di oltre 30 minuti, esecuzioni di rielaborazione delle regole o retrocaccia. Questa icona viene visualizzata anche nella pagina Avvisi di Google SecOps.

  1. Acquisisci familiarità con i seguenti argomenti per capire in che modo questi fattori influiscono sui ritardi nel rilevamento delle regole:

Metodi di generazione del rilevamento

Scopri in che modo il sistema crea i rilevamenti delle regole per capire come il metodo di generazione dei rilevamenti influisce sui ritardi di rilevamento.

Il sistema genera rilevamenti delle regole nei seguenti modi:

  1. Streaming Engine

    Il motore di streaming è una pipeline veloce che in genere opera con un ritardo inferiore a cinque minuti. Elabora le regole single-event senza sezione corrispondenza e senza set di dati esterni come elenchi di riferimento o tabelle di dati.

  2. Motore di query

    Il motore di query elabora le regole nel seguente modo:

    • Regole complesse per un singolo evento:

      • Regole a evento singolo che fanno riferimento a elenchi di riferimenti o tabelle di dati.
      • Regole per un singolo evento in finestra che utilizzano una finestra di corrispondenza con una condizione semplice. Ad esempio, "un evento in cui il nostro conteggio degli eventi è > 0". Queste regole vengono eseguite a una frequenza di query elevata (quasi in tempo reale) man mano che vengono inseriti nuovi dati e resi disponibili per l'elaborazione delle regole.

    • Regole multi-evento: queste regole eseguono query sui dati in blocchi di ora dell'evento (10 minuti, orari, giornalieri), in base a una pianificazione impostata.
      Ad esempio, per una pianificazione di 10 minuti, la regola esegue nuovamente query sui blocchi di ora dell'evento dopo 5-8 ore e 24-48 ore, a seconda delle tempistiche di elaborazione upstream.

  3. Le regole vengono eseguite sui dati storici

    Per maggiori dettagli, vedi Ricerche retrospettive.

  4. Ri-arricchimento degli eventi UDM

    Per maggiori dettagli, vedi Ri-arricchimento degli eventi UDM ed Elaborazione del grafico del contesto delle entità.

Limitazioni note

Ecco alcune limitazioni standard che contribuiscono ai ritardi nel rilevamento delle regole:

  • A volte i ritardi nell'arricchimento possono richiedere più tempo del previsto. Il nuovo trattamento dell'arricchimento fa sì che le esecuzioni successive delle regole rivalutino i dati. Il sistema esegue più esecuzioni dell'arricchimento e può aggiornare gli eventi UDM fino a 24 ore dopo l'importazione.
  • Le regole multi-evento spesso uniscono dati contestuali che arrivano molte ore dopo l'ora dell'evento principale. L'elevata latenza di questi dati contestuali può causare l'interazione tra l'elaborazione del riarricchimento e le riproduzioni delle regole, con conseguente ritardo nel rilevamento. Sebbene Google SecOps utilizzi questa funzionalità per gestire i dati che arrivano in ritardo, viene visualizzato un ampio intervallo di tempo tra la finestra di rilevamento (blocco di tempo dell'evento) e l'ora di creazione dell'avviso.
  • Le regole sensibili al contesto sono regole che si basano su origini di arricchimento come l'assegnazione di alias ad asset e identità o il grafico del contesto delle entità. Poiché queste regole si basano su più origini eventi, sono più soggette a latenza elevata.
  • Il sistema esegue nuovamente le regole tra le 5 e le 8 ore e di nuovo tra le 24 e le 48 ore dopo l'esecuzione iniziale della regola. Queste due riproduzioni delle regole separate vengono attivate in base ai tempi di esecuzione della pipeline di rielaborazione.
  • Per ulteriori limiti di rilevamento, vedi Comprendere i limiti di rilevamento.

Risolvere i problemi relativi ai ritardi nel rilevamento delle regole

Risolvi i problemi relativi ai ritardi nel rilevamento delle regole tramite un processo di eliminazione.

Segui questo approccio suggerito per esaminare e risolvere i problemi relativi ai ritardi nel rilevamento delle regole:

  1. Controlla se ci sono ritardi evidenti:

    Determina se esiste un ritardo di importazione:

    1. Nella console Google SecOps, vai a Rilevamento > Regole e rilevamenti.

    2. Cerca la regola da analizzare nella Dashboard regole.

    3. Confronta Event time con Ingested time.

      Ad esempio, per il rilevamento di una determinata regola, se esiste un ampio divario tra Event time e Ingested time, puoi probabilmente attribuire il ritardo di rilevamento a un ritardo previsto. Un'icona nella colonna Tipo di rilevamento viene applicata quando Ingestion time si verifica più di 30 minuti dopo Event time.

  2. Rivedi l'ora di raccolta dell'origine contesto:

    Controlla l'ora di raccolta dell'origine del contesto.

    Le regole sensibili al contesto possono includere le seguenti origini del contesto. Controlla gli orari di ritiro:

    • Campi derivati dall'arricchimento UDM.
    • Eventi che includono un campo principal.

    • Regole che fanno riferimento a un campo graph.entity.

      Le regole che fanno riferimento al grafico del contesto delle entità (ECG) con la sintassi graph.entity possono causare una latenza particolarmente elevata. Ad esempio, la pipeline ECG genera dati di contesto, un processo che può richiedere 30 ore o, in alcuni casi, fino a 8 giorni, a seconda del tipo di dati.

    Per maggiori dettagli, consulta Ritardi nel trattamento dei dati.

  3. Esamina la frequenza di esecuzione e la configurazione della finestra di corrispondenza della regola:

    • Frequenza:controlla la frequenza di esecuzione della regola. Una regola configurata per essere eseguita meno frequentemente ha naturalmente ritardi di rilevamento più lunghi.
    • Finestra di corrispondenza:se una regola ha una finestra di corrispondenza, il ritardo minimo è la durata di questa finestra.
    • Relazione tra frequenza e finestra di corrispondenza: assicurati che la frequenza di esecuzione sia compatibile con la finestra di corrispondenza. Ad esempio, se la finestra di corrispondenza è di 5 minuti, una frequenza di esecuzione di 10 minuti è accettabile. Tuttavia, se la finestra di corrispondenza è superiore a 10 minuti, utilizza la frequenza di esecuzione successiva disponibile, ovvero 1 ora.

  4. Controlla gli incidenti recenti:

    Cerca eventuali incidenti recenti che potrebbero aver causato ritardi o problemi con i feed di dati.

Suggerimenti per ridurre i ritardi

Per aggiornare le configurazioni delle regole di rilevamento, consulta Gestione delle regole mediante Rules Editor (Editor regole).

Utilizza le seguenti tecniche per ridurre i ritardi, ove possibile:

  • Per le regole sensibili alla latenza, utilizza le opzioni di esecuzione più frequenti:

    • Aumenta la frequenza della regola:

      Per ridurre i ritardi, configura la frequenza più alta possibile in base al tipo di regola e alla finestra di corrispondenza:

      • Per le regole relative a un singolo evento: utilizza Quasi in tempo reale.
      • Per le regole multi-evento con finestre di corrispondenza inferiori a 60 minuti: utilizza 10 minuti.
      • Per le regole con finestre di corrispondenza di 60 minuti o più: utilizza 1 ora o 24 ore, a seconda dei casi.

      Per maggiori dettagli, vedi Impostare la frequenza di esecuzione.

    • Riduci la durata della finestra di corrispondenza:

      La riduzione della finestra di corrispondenza non influisce direttamente sulla latenza, ma può aumentare l'efficienza impostando il ritardo minimo.

  • Evita i dati in ritardo:

    I dati che arrivano in ritardo non vengono inclusi nella query iniziale e il sistema li elabora solo quando esegue nuovamente una query sul blocco di tempo dell'evento 5-8 ore dopo, causando ritardi significativi. I dati puntuali in genere hanno un ritardo di circa 20 minuti.

Fattori che contribuiscono ai ritardi nel rilevamento delle regole

Il tipo di regola, la frequenza di esecuzione e la velocità di importazione di Google SecOps sono fattori chiave nei ritardi di rilevamento delle regole.

I seguenti fattori contribuiscono ai ritardi nel rilevamento delle regole.

Tipi di regole

Le regole rientrano in due categorie principali:

Regole per un singolo evento

Poiché le regole per singolo evento vengono eseguite in tempo quasi reale utilizzando un approccio di streaming, utilizzale per ridurre al minimo i ritardi, ove possibile.

Queste regole rilevano singoli eventi e non utilizzano elenchi di riferimento, tabelle di dati, finestre di corrispondenza o l'analisi del comportamento di utenti ed entità (UEBA). Queste regole vengono eseguite quasi in tempo reale, in modalità streaming e hanno i ritardi di rilevamento più brevi.

Regole complesse per un singolo evento

Queste regole sono più soggette a ritardi nel rilevamento perché includono finestre di corrispondenza o elenchi di riferimento:

  • Regole per un singolo evento in una finestra temporale

    Si tratta di regole per un singolo evento che includono una finestra di corrispondenza e in genere hanno un ritardo leggermente più lungo rispetto ad altre regole per un singolo evento. Una finestra di corrispondenza è in genere un periodo di tempo in cui una regola esamina uno o più eventi.

  • Fare riferimento alle regole per un singolo evento

    Si tratta di regole per un singolo evento che includono elenchi di riferimento o tabelle di dati.

Regole per più eventi

Le regole multi-evento vengono eseguite in base a una pianificazione, il che comporta ritardi più lunghi a causa del tempo che intercorre tra le esecuzioni pianificate.

  • Regole per più eventi

    Queste regole esaminano due o più condizioni di eventi UDM. In genere hanno una finestra di corrispondenza e più condizioni.

  • Regole sensibili al contesto

    Le regole sensibili al contesto ti aiutano ad aggiungere dati di contesto aggiuntivi relativi a entità e rilevamento agli eventi.

    • Queste regole sono costituite da due o più origini dati, in cui almeno una condizione è un evento di entità UDM (in cui l'evento UDM è di tipo contesto, ad esempio user_context).
    • Le regole sensibili al contesto sono le più sensibili ai dati in ritardo.
    • Le regole sensibili al contesto in genere hanno i ritardi più lunghi perché il sistema deve prima generare i dati di contesto necessari, ad esempio i dati nel grafico del contesto delle entità .
    • Per maggiori dettagli, vedi Utilizzare dati arricchiti dal contesto nelle regole.

Scopri di più sulla differenza tra le regole Single-Event e Multiple-Event.

Frequenza di esecuzione delle regole

La frequenza di esecuzione delle regole influisce direttamente sul ritardo di rilevamento.

  • Quasi in tempo reale:le regole vengono eseguite più frequentemente per i dati in tempo reale. Questo vale solo per le regole relative a un singolo evento.
  • Altre frequenze:per altri tipi di regole, puoi impostare le seguenti frequenze:
    • La frequenza di 10 minuti è valida per le finestre di corrispondenza inferiori a 60 minuti.
    • Le frequenze di 1 ora e 24 ore sono valide per le finestre di corrispondenza inferiori a 48 ore.
    • La frequenza di 24 ore è valida per tutte le finestre di corrispondenza >= 48 ore.

Soluzione alternativa possibile: per ottenere rilevamenti più rapidi, utilizza una frequenza di esecuzione più breve. La riduzione della finestra di corrispondenza non influisce direttamente sulla latenza, ma può aumentare l'efficienza impostando il ritardo minimo.

Finestra di corrispondenza

Se una regola ha una finestra di corrispondenza, la durata della finestra determina il ritardo minimo di rilevamento, poiché il sistema deve attendere che si verifichi l'intera finestra.

Ritardo di importazione

Il ritardo di importazione si riferisce al tempo impiegato da Google SecOps per importare i dati dopo che si è verificato l'evento.

Se i dati arrivano in ritardo, non rientrano nella finestra della query iniziale. Una query di elaborazione cronologica successiva lo rileva, ma ciò può comportare ritardi di 5-8 ore.

Ad esempio, l'evento A (ora evento 09:03) e l'evento B (ora evento 09:05) fanno parte di una regola che cerca due eventi entro 30 minuti. Se l'evento A arriva alle 10:05 (con un'ora di ritardo), non rientra nelle query iniziali del blocco dalle 9:00 alle 9:30. Una query di follow-up per quel blocco tra le 14:00 e le 17:00 genera quindi il rilevamento, con conseguenti ritardi di 5-8 ore.

Risoluzione dei problemi:verifica di inviare i dati a Google SecOps non appena si verifica l'evento. Quando esamini un rilevamento, controlla attentamente i timestamp dell'evento UDM e dell'importazione.

Problemi relativi al fuso orario

Il fuso orario predefinito di Google SecOps SIEM è UTC. Se i log non includono una definizione esplicita del fuso orario, il sistema li interpreta come UTC. Un'interpretazione errata può far sì che i log vengano trattati come arrivati in ritardo, il che comporta ritardi nel rilevamento, anche se il sistema li riceve in tempo reale.

Ad esempio, un log con un'ora dell'evento alle 10:00 Eastern Time (15:00 UTC) arriva alle 15:05 UTC, ma non ha un fuso orario. Se il log non include un fuso orario, il sistema interpreta l'ora dell'evento come 10:00 UTC. Il sistema calcola quindi un ritardo di 5 ore tra l'ora dell'evento interpretata (10:00 UTC) e l'ora di importazione effettiva (15:05 UTC). Questo ritardo calcolato attiva ritardi nel rilevamento perché le regole danno la priorità all'elaborazione in base all'importazione in tempo reale.

Soluzioni alternative:se il timestamp dell'evento dei dati originali si trova in un fuso orario diverso da UTC, prova una delle seguenti soluzioni:

  • Aggiorna il fuso orario dell'evento dei dati originali.
  • Se non riesci ad aggiornare il fuso orario nell'origine log, contatta l'assistenza per ignorare il fuso orario.
  • In alternativa, utilizza un processore BindPlane per correggere il timestamp e formattarlo come UTC o aggiungi l'indicatore del fuso orario appropriato. Per maggiori dettagli, vedi Modificare i timestamp del corpo dei log utilizzando BindPlane.

Join contestuali

Le regole per più eventi che utilizzano dati contestuali, come i campi UEBA o del grafico del contesto delle entità, potrebbero subire ritardi più lunghi. Google SecOps deve prima generare i dati contestuali.

Sistema di arricchimento

Google SecOps arricchisce gli eventi UDM aggiungendo dati contestuali provenienti da altre origini. Di solito, questa procedura viene completata entro 30 minuti. I ritardi nell'aggiunta di questi dati arricchiti agli eventi UDM possono aumentare i tempi di rilevamento.

Per verificare se una regola sta valutando un campo arricchito, esamina il Visualizzatore eventi. Se la regola valuta un campo arricchito, il rilevamento potrebbe essere ritardato.

Per maggiori dettagli, consulta Arricchimento dei dati.

Alias e arricchimento

L'assegnazione di alias e l'arricchimento sono due passaggi del processo di arricchimento dei dati di sicurezza di Google SecOps che mettono in correlazione e aggiungono dati di contesto ai record degli eventi. L'assegnazione di alias trova le connessioni e l'arricchimento compila i campi UDM con i dati connessi. I campi compilati da questo processo sono chiamati campi con alias o campi arricchiti.

  • Assegnazione di alias:il processo di identificazione e collegamento di nomi o identificatori diversi per la stessa entità. Trova dati di contesto aggiuntivi che descrivono un indicatore. Ad esempio, l'assegnazione di alias può collegare un singolo hostname (come alex-macbook) ad altri indicatori correlati, come il suo IP addresses e MAC addresses (dai log DHCP). L'assegnazione di alias può anche collegare un user ID (come alex) all'job title e all'employment status dell'utente (dai dati di contesto dell'utente).
  • Arricchimento:il processo che utilizza le informazioni raccolte dall'assegnazione di alias per aggiungere contesto a un evento UDM. Ad esempio, quando arriva un nuovo evento con solo un IP address, la procedura di arricchimento utilizza i dati con alias per trovare l'hostname associato (ad esempio, alex-macbook) e compila il campo $udm.event.principal.hostname.

Google SecOps supporta l'assegnazione di alias e l'arricchimento per diversi tipi di entità, tra cui: asset (ad esempio nomi host, indirizzi IP, MAC), utenti, processi, metadati hash dei file, posizioni geografiche e risorse cloud. Per maggiori dettagli, consulta Panoramica dell'arricchimento e dell'assegnazione di alias di UDM.

Ri-arricchimento degli eventi UDM

  • Modifiche ai dati sottostanti: se i dati sottostanti cambiano dopo l'importazione di un evento, il sistema rielabora i dati storici e aggiorna gli eventi fino a 24 ore dopo l'importazione.

  • Aggiornamenti del sistema di arricchimento:se il sistema di arricchimento aggiorna i metadati di entità o processi, la geolocalizzazione IP o gli indicatori VirusTotal, il motore delle regole rivaluta questi blocchi 24-48 ore dopo per acquisire gli aggiornamenti.
    Ad esempio, un evento alle 9:03 ha entity.asset.hostname = hostnameA ma nessun IP. Un log DHCP delle 8:55 mostra hostnameA = IP 1.2.3.4. Il motore delle regole viene eseguito alle 9:10 e la regola non corrisponde. La pipeline di elaborazione dell'arricchimento correla hostnameA a 1.2.3.4 per quella finestra temporale, aggiornando l'evento UDM. Ora la regola corrisponde e il sistema crea un rilevamento.

  • Dati contestuali ritardati:se invii dati contestuali, ad esempio un hostname, un giorno dopo il log iniziale, il sistema arricchisce nuovamente l'evento UDM. Le regole che cercano questi dati riarricchiti vengono eseguite di nuovo e creano un rilevamento. Questa funzionalità garantisce che il sistema crei rilevamenti anche quando il contesto è ritardato.

  • Modifiche ai dati di arricchimento:le modifiche ai dati di arricchimento possono far sì che una regola venga abbinata in un secondo momento, anche se inizialmente non lo era.
    Ad esempio, un evento alle 9:03 ha entity.ip_geo_artifact.country_or_region = USA. Il motore delle regole viene eseguito alle 9:10, esegue query dalle 9:00 alle 10:00 e la regola non corrisponde. In un secondo momento, il nuovo trattamento dell'arricchimento aggiorna la geolocalizzazione in Canada. Quando la regola viene eseguita di nuovo, ora corrisponde e il sistema crea un rilevamento.

Elaborazione del grafico del contesto delle entità

Il sistema genera e aggiunge informazioni del grafico del contesto delle entità (ECG) ai dati dei log per fornire il contesto, ad esempio indicatori di compromissione (IOC) o dati di contesto delle risorse. Poiché la pipeline ECG si basa principalmente sull'elaborazione batch, le informazioni sul contesto dell'entità vengono spesso aggiornate solo dopo che l'esecuzione di una regola crea un rilevamento.

Caccia al tesoro retrò

Quando esegui una regola sui dati storici utilizzando una ricerca retrospettiva, il sistema crea il rilevamento solo al termine della procedura di ricerca retrospettiva. Questa procedura può richiedere molto tempo, il che causa un ritardo nel rilevamento.

Esempio di procedura di aggiornamento retroattivo:

  1. Evento iniziale:un evento arriva alle 13:00 con ip_address = 10.0.0.5. Al momento, hostname è sconosciuto.
  2. Arriva l'alias della sorgente:alle 14:30 (più di un'ora dopo), arriva un log DHCP per le 13:00, che collega 10.0.0.5 a workstation-123.
  3. Arricchimento retroattivo:il sistema di creazione di alias elabora questo nuovo collegamento. Aggiorna retroattivamente l'evento UDM dalle ore 13:00, arricchendo il campo $udm.event.principal.hostname precedentemente vuoto con il valore workstation-123.
  4. Rilevamento:le riproduzioni successive delle regole visualizzano il valore arricchito (workstation-123) e possono attivare rilevamenti precedentemente mancati.

Nota: non puoi distinguere le metriche di monitoraggio della latenza per le regole di rilevamento in tempo reale dalle regole di rilevamento retrohunt. Per evitare di distorcere le metriche di monitoraggio della latenza di rilevamento, non utilizzare una regola live per simulare una regola di retrocaccia. Come best practice, crea una regola di rilevamento dedicata ed eseguila come regola di retrocaccia.

Elenchi di riferimento

Le esecuzioni delle regole utilizzano sempre l'ultima versione di un elenco di riferimento. Quando le regole pianificate vengono eseguite di nuovo, il sistema può creare nuovi rilevamenti in base ai contenuti aggiornati dell'elenco di riferimento. Questi rilevamenti potrebbero essere visualizzati in ritardo perché si basano sui dati importati prima dell'aggiornamento dell'elenco di riferimento.

Per ridurre i ritardi di rilevamento:

  • Invia i dati dei log a Google SecOps non appena si verifica l'evento.
  • Esamina le regole di controllo per determinare se utilizzare dati di non esistenza o arricchiti dal contesto.
  • Configura una frequenza di esecuzione inferiore.

Regole di non esistenza

Il sistema attende almeno un'ora prima di eseguire le regole che verificano l'inesistenza (ad esempio, le regole che contengono !$e o #e=0), garantendo che i dati abbiano il tempo di arrivare.

Ritardi nel trattamento dei dati

Il sistema potrebbe continuare a elaborare i dati anche dopo aver creato un rilevamento iniziale, il che potrebbe portare a rilevamenti nuovi o aggiornati. Per maggiori dettagli, vedi Quando vengono attivate le ripetizioni delle regole.

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