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 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 rilevamenti delle regole hanno sempre un certo ritardo, che varia da quasi in tempo reale a pochi minuti o molte ore. 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 il risultato del processo di importazione e delle scelte di configurazione effettuate durante l'impostazione della regola di rilevamento.
    Ad esempio, la creazione di un rilevamento richiede tempo. 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, riarricchimento e altri ritardi nel trattamento 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, utilizza la ricerca per identificare le regole che subiscono lunghi ritardi nel rilevamento.

  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 potrebbe essere stato ritardato.

  4. 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 a evento singolo 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 per un singolo evento 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 (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 che imposti.
      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 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. La rielaborazione dell'arricchimento fa sì che le esecuzioni successive delle regole rivalutino i dati. Il sistema esegue più esecuzioni di arricchimento, l'ultima delle quali tre giorni dopo l'ora dell'evento.
  • 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.
  • 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 si verificano in base ai tempi di esecuzione della pipeline di rielaborazione.

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.

  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 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:

      Le finestre di corrispondenza più piccole sono più efficienti. Modifica una finestra di corrispondenza di 60 minuti in 59 minuti per attivare l'elaborazione di 10 minuti.

  • 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

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

    • Regole semplici per un singolo evento

      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

      • Regole per un singolo evento della finestra

        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 a comprendere sia i pattern comportamentali nella telemetria sia il contesto delle entità interessate da questi pattern.

      • Queste regole sono costituite da due o più condizioni, ma almeno una condizione è un evento entità UDM (in cui l'evento UDM è di tipo context, ad esempio user_context).
      • Questi tipi di regole hanno ritardi più lunghi e non è raro che i rilevamenti richiedano alcuni giorni.
      • Le regole sensibili al contesto in genere hanno i ritardi più lunghi perché il sistema deve prima generare i dati di contesto necessari.

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, in esecuzione costante. 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 e una finestra di corrispondenza più piccola. L'utilizzo di finestre di corrispondenza più brevi (meno di un'ora) consente esecuzioni più frequenti.

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 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 delle 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 di 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 multi-evento che utilizzano dati contestuali, come UEBA o Entity Graph, 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 tramite 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, MAC addresses (dai log DHCP) o un user ID (come alex) al suo job title e employment status (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, IP, MAC), utenti, processi, metadati hash file, posizioni geografiche e risorse cloud. Per maggiori dettagli, vedi Panoramica dell'arricchimento e dell'assegnazione di alias UDM.

Ri-arricchimento degli eventi UDM

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

  • 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, tre giorni 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. 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 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 rielaborazione 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 delle entità

Il sistema genera e aggiunge informazioni sul grafico del contesto dell'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.

Caccia al tesoro retrò

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

Esempio di processo 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 aliasing 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 esecuzioni successive delle regole (esecuzioni di pulizia) ora 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 retrocaccia. 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 inseriti 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.