Informazioni sulle ripetizioni delle regole e sul tempo medio di rilevamento

Supportato in:

Questo documento spiega in che modo le ripetizioni delle regole (chiamate anche esecuzioni di pulizia) gestiscono i dati in arrivo in ritardo e gli aggiornamenti del contesto e in che modo queste ripetizioni influiscono sulle metriche del tempo medio di rilevamento (MTTD).

Ripetizioni delle regole

Google SecOps elabora grandi volumi di dati di sicurezza. Per garantire rilevamenti accurati per le regole che dipendono da dati contestuali o correlati, il motore delle regole esegue automaticamente un processo di ripetizione delle regole.

Il processo di riproduzione delle regole gestisce le seguenti categorie di regole:

  • Regole per singolo evento:quando il processo di arricchimento UDM aggiorna un evento valutato in precedenza, il sistema riproduce le regole per singolo evento. Consulta le eccezioni per le regole con tabelle di dati riportate di seguito.

  • Regole a evento singolo con finestra (WSE) e regole a evento singolo con tabelle di dati:queste regole hanno un meccanismo di pianificazione distinto per la gestione dei dati in arrivo in ritardo, diverso dalle regole a evento singolo e a più eventi standard.

  • Regole multi-evento:le regole multi-evento vengono eseguite in base a una pianificazione, elaborando blocchi di tempo degli eventi. Queste regole rivalutano ripetutamente lo stesso blocco di tempo a intervalli diversi per acquisire aggiornamenti tardivi dell'arricchimento, ad esempio la corrispondenza dei dati di contesto dell'utente o dell'asset o un indicatore di compromissione (IOC). Le tempistiche esatte dipendono dalla configurazione della pianificazione.

Trigger di riproduzione delle regole

Il sistema rivaluta (riesegue) le regole per garantire il rilevamento, anche se i dati arrivano o vengono aggiornati dopo l'esecuzione iniziale della regola. Questi dati in ritardo includono le seguenti categorie:

  • Eventi di origine con arrivo in ritardo: l'evento di log o UDM non elaborato arriva in Google SecOps molto più tardi del timestamp effettivo dell'evento.
  • Dati di arricchimento in arrivo in ritardo:i dati contestuali (ad esempio, utente, asset, threat intelligence) relativi a un evento diventano disponibili o il sistema li aggiorna dopo aver elaborato l'evento per la prima volta. Ciò si verifica spesso perché le pipeline di arricchimento, come il grafico del contesto delle entità (ECG), elaborano i dati in batch o dipendono da origini dati esterne.
  • Aggiornamenti retroattivi dell'arricchimento UDM:i dati di origine in arrivo in ritardo (come i record DHCP che aggiornano i nomi host) attivano modifiche ai campi evento UDM. Le regole che utilizzano campi con alias (campi arricchiti) nella loro logica di rilevamento, ad esempio $udm.event.principal.hostname, possono attivare ripetizioni quando i dati di origine vengono ritardati. Questo arrivo in ritardo aggiorna retroattivamente i valori dei campi.

Il sistema attiva le ripetizioni delle regole in modo diverso a seconda del tipo di regola e della natura dei dati in ritardo. L'obiettivo è bilanciare la tempestività del rilevamento con la completezza dei dati.

Come il sistema gestisce i dati in ritardo in base al tipo di regola

Il tipo di regola e la relativa configurazione determinano la finestra temporale entro la quale i dati in ritardo possono attivare una rivalutazione della regola.

  • Regole per un singolo evento (senza finestre di corrispondenza o tabelle di dati):

    • Eventi di origine in ritardo:in genere, queste regole elaborano un evento indipendentemente dall'età del timestamp quando arriva nel sistema. Il sistema non impone una finestra di interruzione rigorosa per l'elaborazione iniziale degli eventi di origine in ritardo.
    • Arricchimento tardivo:se arrivano dati di arricchimento per un evento valutato in precedenza o si verifica un aggiornamento, il sistema rivaluta queste regole per singolo evento in base all'evento con il nuovo contesto. Ciò può accadere ore o persino giorni dopo l'evento iniziale.

  • Regole relative a un singolo evento in una finestra e regole relative a un singolo evento con tabelle di dati:

    • Queste regole non seguono la stessa gestione dei dati in ritardo delle altre regole a evento singolo o delle pianificazioni di riconciliazione delle regole a più eventi.
    • Hanno il seguente comportamento:
      • Limite:queste regole non elaborano gli eventi inseriti 7 giorni o più dopo il timestamp dell'evento.
      • Dati in ritardo (<7 giorni): il sistema elabora gli eventi che arrivano con un ritardo inferiore a 7 giorni, ma con una latenza potenzialmente maggiore.
      • Eventi di origine in ritardo: le regole di WSE non elaborano gli eventi se i dati arrivano in Google SecOps 7 giorni o più dopo il timestamp dell'evento.
      • Aggiornamenti del contesto:se il contesto di un evento arriva in ritardo o se un evento viene arricchito retroattivamente, il sistema rivaluta automaticamente le regole in base all'evento arricchito. La riproduzione di questa regola può attivare nuovi rilevamenti, anche se la valutazione iniziale non ha prodotto un rilevamento.
      • Arricchimento tardivo: se un evento UDM viene aggiornato a causa dell'arricchimento (che può verificarsi fino a 7 giorni dopo l'importazione), il sistema rivaluta queste regole in base all'evento aggiornato. Tuttavia, a differenza di altri tipi di regole, gli aggiornamenti ai contenuti delle tabelle di dati non attivano una rivalutazione automatica degli eventi passati per queste regole.
      • Finestra temporale:queste regole utilizzano una finestra temporale di circa 7 giorni per rivalutare gli eventi. Se arrivano dati di arricchimento per un evento che rientra in questo periodo di 7 giorni, la regola verrà rivalutata.

  • Regole per più eventi:

    • Le regole multi-evento vengono eseguite in base a una pianificazione e rivalutano i blocchi di tempo per tenere conto dei dati in ritardo. Il modo in cui configuri la pianificazione della regola determina la finestra di interruzione effettiva:
      • Programmazione predefinita:il sistema esegue in genere aggiustamenti automatici circa 5 ore e 24 ore dopo l'ora dell'evento. Se i dati arrivano dopo il completamento dell'esecuzione di 24 ore, non verranno valutati da questa regola per quel periodo di tempo.
      • Programmi personalizzabili attivati:questa funzionalità ti offre un maggiore controllo sui tempi di esecuzione tramite le impostazioni "Frequenza di esecuzione". Consulta Configurare pianificazioni personalizzate per le regole. Le tempistiche chiave sono:
        • Prima esecuzione:il sistema esegue la prima esecuzione all'ora dell'evento più l'offset configurato (ad esempio, T + 1 ora).
        • Esecuzione di aggiustamento 1:il sistema esegue la prima esecuzione di aggiustamento circa 4 ore dopo la prima esecuzione. Ciò significa che il sistema può includere eventi che arrivano fino a circa T + 4-5 ore.
        • Esecuzione di adeguamento 2 (condizionale): se attivi l'opzione Garantisci il completamento dell'arricchimento, il sistema esegue un'ultima esecuzione di adeguamento circa 30 ore dopo la prima esecuzione. In questo modo, la finestra per l'elaborazione dei dati in ritardo da parte del sistema viene estesa a circa T + 30-31 ore.
      • Implicazioni del limite:con le pianificazioni personalizzabili, l'ultima esecuzione del conguaglio determina il limite effettivo per l'inclusione dei dati in ritardo. In genere, questo avviene circa 4 ore dopo la prima esecuzione o circa 30 ore dopo la prima esecuzione se attivi l'opzione Garantisci il completamento dell'arricchimento. Gli eventi o gli arricchimenti che arrivano dopo l'ultima esecuzione di riconciliazione per un determinato periodo di tempo non verranno elaborati da questa regola per quel periodo.

Esempi di scenari di dati in arrivo in ritardo

  • Scenario 1: evento di origine in ritardo - Regola per un singolo evento

    • Google SecOps acquisisce un evento con un timestamp di 3 giorni fa. Una regola standard per un singolo evento elabora questo evento come nuovi dati.

  • Scenario 2: arricchimento tardivo - Regola basata su un singolo evento

    • Il sistema ha elaborato un evento di accesso ieri. Oggi, acquisisce e arricchisce le nuove informazioni per l'utente coinvolto (ad esempio, un cambio di reparto). Il sistema rivaluta la regola relativa a un singolo evento in base all'evento di accesso con il contesto utente aggiornato.

  • Scenario 3: evento di origine in ritardo - Regola multi-evento (pianificazione predefinita)

    • Se un evento arriva 10 ore dopo il timestamp dell'evento, il sistema lo perde durante l'esecuzione del riallineamento di 5 ore, ma lo elabora durante l'esecuzione del riallineamento di 24 ore. Un evento che arriva con 25 ore di ritardo non verrà elaborato.

  • Scenario 4: evento di origine in ritardo - Regola multi-evento (pianificazione personalizzabile)

    • Configuri una regola multi-evento con un offset di prima esecuzione di 1 ora. Un evento arriva 6 ore dopo il timestamp.
    • Questo evento non include la prima esecuzione (T + 1 ora) e la prima esecuzione di aggiustamento (T + 4 ore). Il sistema NON elaborerà questo evento con questa regola, a meno che tu non attivi l'opzione Garantisci il completamento dell'arricchimento.

  • Scenario 5: arricchimento tardivo - Regola per più eventi (personalizzabile con il completamento dell'arricchimento)

    • Una regola a più eventi ha un offset di 1 ora e tu attivi l'opzione Garantisci il completamento dell'arricchimento. I dati di arricchimento per un evento arrivano 28 ore dopo il timestamp dell'evento.
    • Alcuni di questi dati di arricchimento tardivo potrebbero essere disponibili per la seconda "esecuzione di aggiustamento", che si verifica circa 30 ore dopo l'ora T (perché hai attivato l'opzione Garantisci la completezza dell'arricchimento). Se i dati di arricchimento sono disponibili, il sistema rivaluta la regola utilizzando questo arricchimento tardivo.

  • Scenario 6: evento sorgente in ritardo - Regola multi-evento con finestra di corrispondenza

    • Una regola multi-evento ha una finestra di match ore e una pianificazione personalizzata con l'opzione Garantisci il completamento dell'arricchimento attivata (riconciliazione finale intorno a T + 30 ore). Un evento arriva 36 ore dopo il timestamp. Questo evento non verrà elaborato perché è arrivato dopo l'ultima esecuzione di riconciliazione, anche se l'ora dell'evento rientra nella finestra di corrispondenza della regola rispetto ad altri eventi. Il termine si basa sull'orario di arrivo rispetto al programma di aggiustamento, non solo sulla finestra di corrispondenza.

  • Scenario 7: evento di origine in ritardo - Regola a evento singolo con finestra

    • Se un evento sorgente con un timestamp di 8 giorni prima arriva in ritardo, potrebbe non rientrare nella finestra temporale di 7 giorni per le regole WSE e potrebbe non essere elaborato.

Impatto sulle metriche di timing

Quando un rilevamento è il risultato di una riproduzione di regole, il sistema utilizza la seguente terminologia:

  • La finestra di rilevamento o il timestamp dell'evento dell'avviso si riferisce all'ora dell'attività dannosa originale.
  • L'ora di creazione è l'ora in cui il sistema crea il rilevamento, che può essere molto successiva, a volte ore o giorni dopo.
  • La latenza di rilevamento è la differenza di tempo tra il timestamp dell'evento e l'ora di creazione del rilevamento.

Il riarricchimento dovuto a dati in arrivo in ritardo o alla latenza con un aggiornamento dell'origine del contesto come il grafico del contesto delle entità (ECG) in genere causa un'elevata latenza di rilevamento.

Questa differenza di orario può far sembrare un rilevamento "in ritardo" o "posticipato", il che può confondere gli analisti e distorcere le metriche di rendimento come il tempo medio di rilevamento.

Componente della metrica Fonte dell'ora In che modo le repliche influiscono sul tempo medio alla diagnosi
Finestra di rilevamento / Timestamp evento L'ora in cui si è verificato l'evento di sicurezza originale. I replay mantengono la precisione in base all'ora dell'evento.
Tempo di rilevamento/Data/ora creazione Ora in cui il motore ha effettivamente emesso il rilevamento. Un'esecuzione secondaria (replay) che incorpora dati di arricchimento tardivi fa sì che questo orario appaia in ritardo rispetto al timestamp dell'evento. Questa differenza influisce negativamente sul calcolo del MTTD.

Best practice per la misurazione del tempo medio di rilevamento

L'MTTD quantifica il tempo che intercorre tra la compromissione iniziale e il rilevamento effettivo della minaccia. Quando analizzi i rilevamenti attivati dalle ripetizioni delle regole, applica le seguenti best practice per mantenere metriche MTTD accurate.

Google SecOps fornisce diverse metriche interrogabili dagli utenti per misurare con precisione il MTTD. Per informazioni dettagliate su queste metriche, consulta Query YARA-L 2.0 di esempio per la pagina Dashboard.

Un'icona nella colonna Tipo di rilevamento identifica i rilevamenti generati dal sistema a partire dai dati degli eventi arrivati con un ritardo superiore a 30 minuti, dalle esecuzioni di rielaborazione delle regole o dalle ricerche retrospettive. Questa icona viene visualizzata anche nella pagina Avvisi di Google SecOps.

Dai la priorità ai sistemi di rilevamento in tempo reale

Per rilevamenti più rapidi, utilizza le regole per singoli eventi. Queste regole vengono eseguite quasi in tempo reale, in genere con un ritardo inferiore a 5 minuti.

Inoltre, supporta un utilizzo più completo dei rilevamenti compositi.

Tenere conto della riproduzione delle regole nelle regole multi-evento

Le regole multi-evento comportano intrinsecamente una latenza maggiore a causa della frequenza di esecuzione pianificata. Quando misuri l'MTTD per i rilevamenti dalle regole multi-evento, tieni presente che le ripetizioni delle regole automatizzate aumentano la copertura e la precisione. Queste repliche spesso rilevano minacce che richiedono un contesto tardivo, il che aumenta la latenza segnalata per questi rilevamenti.

  • Per avvisi critici e urgenti:utilizza regole per singoli eventi o regole per più eventi con le frequenze di esecuzione pratiche più brevi. La riduzione della finestra di corrispondenza non influisce direttamente sulla latenza, ma può aumentare l'efficienza impostando il ritardo minimo.

  • Per la correlazione complessa e di lunga durata (UEBA, attacchi multifase): Queste regole si basano su unioni contestuali o elenchi di riferimento estesi, che potrebbero essere aggiornati in modo asincrono. Possono riscontrare una latenza elevata con dati contestuali o sugli eventi in arrivo in ritardo, ma offrono il vantaggio di un rilevamento di fedeltà superiore rispetto alla velocità assoluta.

Ottimizzare le regole per ridurre la dipendenza dall'arricchimento tardivo

Per ottimizzare la velocità di rilevamento e ridurre al minimo l'impatto delle esecuzioni di arricchimento retroattivo, valuta la possibilità di utilizzare campi non alias (campi che le pipeline di arricchimento downstream non elaborano) nella logica della regola, ove possibile.

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