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 imprevisti.

  • 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 come il sistema crea i rilevamenti delle regole per capire in che modo il metodo di generazione del rilevamento influisce sui ritardi di rilevamento.

Il sistema genera rilevamenti delle regole nei seguenti modi:

  1. Streaming Engine

    Il motore di streaming è una pipeline di streaming dedicata che opera con una bassa latenza (in genere un ritardo inferiore a cinque minuti). Valuta le regole standard a evento singolo che contengono nessuna sezione di corrispondenza, nessun set di dati esterni (come elenchi di riferimento o tabelle di dati) e nessuna funzione UEBA.

  2. Motore di query

    Il motore di query valuta regole complesse a evento singolo e a più eventi:

    • Regole per eventi singoli complesse:

      • Regole per eventi singoli con elenchi di riferimento o tabelle di dati: regole che valutano un singolo evento ed eseguono ricerche negli elenchi di riferimento o nelle tabelle di dati.
      • Regole per singoli eventi con finestra: regole che valutano un singolo evento con una finestra di corrispondenza e una semplice condizione di esistenza (ad esempio $e, #e > 0 o #e >= 1).
      • Sebbene le regole complesse per eventi singoli utilizzino il motore di query anziché il motore di streaming, vengono pianificate in base a una pianificazione quasi in tempo reale ad alta frequenza man mano che vengono inseriti nuovi dati. In questo modo si ottiene una latenza inferiore, vicina a quella tipica del motore di streaming. I dati arricchiti e arrivati in ritardo vengono rivalutati durante l'esecuzione della query standard senza richiedere intervalli di allineamento multievento.

    • Regole per più eventi: queste regole eseguono query sui dati in blocchi di tempo dell'evento (10 minuti, orari, giornalieri), in base a una pianificazione che imposti. I tempi di nuova query per i dati in arrivo in ritardo dipendono dal tipo di pianificazione.

  3. Le regole vengono eseguite sui dati storici

    Per maggiori dettagli, vedi Caccia retroattiva.

  4. Ri-arricchimento degli eventi UDM

    Per maggiori dettagli, vedi Riarricchimento 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.

  • Regole multi-evento:

    • Per le regole multi-evento nella pianificazione predefinita, il sistema esegue nuovamente le regole circa 5 ore e 24 ore dopo l'ora dell'evento.

    • Le regole multi-evento con pianificazioni personalizzabili hanno tempi di riconciliazione diversi.

    Queste riproduzioni delle regole vengono attivate per gestire i dati in arrivo in ritardo.

  • Le regole sensibili al contesto sono regole che si basano su origini di arricchimento come l'assegnazione di alias di 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. 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 è più di 30 minuti dopo Event time.

  2. Rivedi l'ora di raccolta dell'origine del 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 raccolta:

    • 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, per le finestre di corrispondenza inferiori a 60 minuti, è supportata una frequenza di esecuzione di 10 minuti (quasi in tempo reale). Per le finestre di corrispondenza di 60 minuti o più (fino a 48 ore), utilizza 1 ora. Per le finestre di corrispondenza superiori a 48 ore, utilizza Giornaliero.

  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 tutte le regole per eventi singoli: utilizza Quasi in tempo reale.
      • Per le regole per più eventi con finestre di corrispondenza inferiori a 60 minuti: utilizza Quasi in tempo reale (10 minuti).
      • Per le regole multi-evento con finestre di corrispondenza di 60 minuti o più: utilizza 1 ora o Giornaliero, 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 eventi singoli

Le regole a evento singolo standard rilevano singoli eventi senza ricerche di dati esterni, finestre di corrispondenza o analisi del comportamento di utenti ed entità (UEBA). Queste regole vengono eseguite quasi in tempo reale utilizzando un motore di streaming dedicato e raggiungono la latenza di rilevamento più bassa (in genere inferiore a cinque minuti).

Regole complesse per eventi singoli

Le regole complesse per eventi singoli valutano i singoli eventi, ma incorporano elenchi di riferimento, tabelle di dati o semplici finestre di corrispondenza. Vengono eseguiti utilizzando il motore di query anziché il motore di streaming, ma sono pianificati in base a una pianificazione quasi in tempo reale con una bassa latenza simile a quella del motore di streaming:

  • Regole per eventi singoli per elenchi di riferimento e tabelle di dati:

    Queste regole a evento singolo eseguono ricerche in elenchi di riferimento o tabelle di dati senza richiedere una finestra di corrispondenza multi-evento.

  • Regole per eventi singoli con finestra:

    Queste regole per eventi singoli includono una finestra di corrispondenza con una semplice condizione di conteggio degli eventi (ad esempio $e, #e > 0 o #e >= 1).

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 con una latenza minima man mano che gli eventi vengono inseriti. Questo vale per:
    • Tutte le regole per eventi singoli (eventi singoli standard, regole con elenchi di riferimento o tabelle di dati e regole per eventi singoli con finestra).
    • Regole multi-evento con finestre di corrispondenza inferiori a 60 minuti.
  • Altre frequenze:per altre configurazioni delle regole, puoi impostare le seguenti frequenze:
    • La frequenza di 10 minuti è valida per le finestre di corrispondenza inferiori a 60 minuti.
    • Le frequenze oraria e giornaliera sono valide per finestre di corrispondenza fino a 48 ore.
    • La frequenza giornaliera è valida per tutte le finestre di corrispondenza superiori a 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ò introdurre ritardi da 5 a 8 ore.

Ad esempio, l'evento A (ora evento 9:03) e l'evento B (ora evento 9: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'aliasing 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, il processo 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 riassegnati vengono eseguite di nuovo e creano un rilevamento.

  • 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 era così.
    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 al Canada. Quando la regola viene eseguita di nuovo, ora corrisponde e il sistema crea un rilevamento.

Elaborazione del grafico del contesto 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 di contesto dell'entità vengono spesso aggiornate solo dopo che l'esecuzione di una regola crea un rilevamento.

Cacce 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 link. 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 vedono il valore arricchito (workstation-123) e possono attivare rilevamenti precedentemente mancati.

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.