Informazioni sulle riproduzioni delle regole e sul MTTD

Supportato in:

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

Riproduzioni delle regole

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

Il processo di riproduzione delle regole gestisce queste categorie di regole:

  • Regole per eventi singoli: queste regole vengono riprodotte quando il processo di arricchimento UDM aggiorna un evento valutato in precedenza. Per le eccezioni relative alle regole con tabelle di dati, consulta la sezione Scenari di dati in arrivo in ritardo più avanti in questo documento.

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

  • Regole per più eventi: queste regole vengono eseguite in base a una pianificazione, elaborando blocchi di tempo degli eventi. Rivalutano ripetutamente lo stesso blocco di tempo a intervalli diversi per acquisire gli aggiornamenti di arricchimento in ritardo, ad esempio i dati di contesto dell'utente o dell'asset corrispondenti 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 assicurarsi di rilevare le minacce, anche se i dati arrivano o vengono aggiornati dopo l'esecuzione iniziale della regola. Questi dati in arrivo in ritardo includono le seguenti categorie:

  • Eventi di origine in arrivo in ritardo: l'evento del log non elaborato o UDM stesso arriva in Google SecOps molto più tardi rispetto al 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 vengono aggiornati dal sistema dopo la prima elaborazione dell'evento. 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 di arricchimento UDM retroattivi: i dati di origine in arrivo in ritardo (ad esempio, i record DHCP che aggiornano i nomi host) attivano modifiche ai campi degli eventi UDM. Le regole che utilizzano campi con alias (campi arricchiti) nella logica di rilevamento, ad esempio $udm.event.principal.hostname, possono attivare le riproduzioni quando i dati di origine vengono ritardati. Questo arrivo in ritardo aggiorna retroattivamente i valori di questi campi.

Il sistema attiva le riproduzioni 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.

In che modo il sistema gestisce i dati in arrivo 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 arrivo in ritardo possono attivare una rivalutazione della regola.

  • Regole per eventi singoli (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 in ritardo: se i dati di arricchimento per un evento valutato in precedenza arrivano o si verifica un aggiornamento, il sistema rivaluta queste regole per eventi singoli rispetto all'evento con il nuovo contesto. Ciò può accadere ore o persino giorni dopo l'evento iniziale.

  • Regole per eventi singoli con finestra (WSE) e regole per eventi singoli con tabelle di dati:

    • Queste regole non seguono la stessa gestione dei dati in ritardo delle altre regole per eventi singoli o le pianificazioni di allineamento delle regole per più eventi.
    • Hanno il seguente comportamento:
      • Interruzione: queste regole non elaborano gli eventi importati 7 giorni o più dopo il timestamp dell'evento.
      • Dati in arrivo 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 arrivo in ritardo: le regole 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 rispetto all'evento arricchito. Questa riproduzione delle regole può attivare nuovi rilevamenti, anche se la valutazione iniziale non ha generato un rilevamento.
      • Arricchimento in ritardo: 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 rispetto 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 i dati di arricchimento arrivano per un evento che rientra in questa finestra di 7 giorni, la regola verrà rivalutata.

  • Regole per più eventi:

    • Le regole per più eventi vengono eseguite in base a una pianificazione e rivalutano i blocchi di tempo per tenere conto dei dati in ritardo. La pianificazione della regola determina la finestra di interruzione effettiva:
      • Esecuzione principale: il sistema esegue la prima valutazione all'ora dell'evento più qualsiasi ritardo di liquidazione configurato (ad esempio, T + 1 ora).
      • Esecuzione di allineamento 1: il sistema esegue la prima esecuzione di allineamento circa 4 ore dopo l'esecuzione principale. In questo modo, il sistema può includere gli eventi in arrivo in ritardo.
      • Esecuzione di allineamento 2 (condizionale): se attivi l'opzione Garantisci la completezza dell'arricchimento, il sistema esegue un'esecuzione di allineamento finale circa 30 ore dopo l'esecuzione principale. In questo modo, la finestra per l'elaborazione dei dati in arrivo in ritardo e degli arricchimenti del contesto da parte del sistema viene estesa fino a circa 30 ore.
      • Implicazioni dell'interruzione: l'esecuzione di allineamento finale determina l'interruzione effettiva per l'inclusione dei dati in ritardo. In genere, ciò si verifica circa 4 ore dopo l'esecuzione principale (o circa 30 ore dopo l'esecuzione principale se attivi l'opzione Garantisci la completezza dell'arricchimento). Gli eventi o gli arricchimenti che arrivano dopo l'esecuzione di allineamento finale per una determinata finestra temporale non verranno elaborati da questa regola per quella finestra.

Esempi di scenari di dati in arrivo in ritardo

  • Scenario 1: evento di origine in ritardo - regola per eventi singoli

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

  • Scenario 2: arricchimento in ritardo - regola per eventi singoli

    • Il sistema ha elaborato un evento di accesso ieri. Oggi importa e arricchisce nuove informazioni per l'utente coinvolto (ad esempio, una modifica del reparto). Il sistema rivaluta la regola per eventi singoli rispetto all'evento di accesso con il contesto utente aggiornato.

  • Scenario 3: evento di origine in ritardo - regola per più eventi (allineamento predefinito di 4 ore)

    • Un evento arriva 3 ore dopo il timestamp dell'evento per una regola per più eventi pianificata con le impostazioni predefinite. L'evento non è stato incluso nell'esecuzione principale iniziale (T + 1 ora), ma il sistema lo elabora durante l'esecuzione di allineamento di 4 ore.

  • Scenario 4: evento di origine in ritardo - regola per più eventi (senza completezza dell'arricchimento)

    • Configuri una regola per più eventi con un offset di esecuzione principale di 1 ora senza attivare l'opzione Garantisci la completezza dell'arricchimento. Un evento arriva 6 ore dopo il timestamp.
    • Questo evento non viene incluso nell'esecuzione principale (T + 1 ora) e nella prima esecuzione di allineamento (T + 4 ore). Il sistema non elaborerà questo evento per questa finestra temporale perché è arrivato dopo l'esecuzione di allineamento finale.

  • Scenario 5: arricchimento in ritardo - regola per più eventi (con completezza dell'arricchimento)

    • Una regola per più eventi ha un offset di 1 ora e attivi l'opzione Garantisci la completezza dell'arricchimento. I dati di arricchimento per un evento arrivano 28 ore dopo il timestamp dell'evento.
    • Il sistema rivaluta la regola utilizzando questo arricchimento in ritardo durante la seconda esecuzione di allineamento a circa T + 31 ore.

  • Scenario 6: evento di origine in ritardo - regola per più eventi con finestra di corrispondenza

    • Una regola per più eventi ha una finestra di match di 48 ore e una pianificazione con l'opzione Garantisci la completezza dell'arricchimento attivata (allineamento finale intorno a T + 30 ore). Un evento arriva 36 ore dopo il timestamp. Questo evento non verrà elaborato perché è arrivato dopo l'esecuzione di allineamento finale, anche se l'ora dell'evento rientra nella finestra di corrispondenza della regola rispetto ad altri eventi. L'interruzione si basa sull'ora di arrivo rispetto alla pianificazione di allineamento, non solo sulla finestra di corrispondenza.

  • Scenario 7: evento di origine in ritardo - regola per eventi singoli con finestra

    • Se un evento di origine con un timestamp di 8 giorni fa 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 tempistica

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

  • La finestra di rilevamento o il timestamp dell'evento dell'avviso si riferiscono all'ora dell'attività dannosa originale.
  • L'ora di creazione è l'ora in cui il sistema crea il rilevamento, che può essere molto più tardi, 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.

Delta Timeline e MTTD

Il tempo trascorso tra il timestamp dell'evento iniziale e la creazione di un rilevamento influisce direttamente sul calcolo del MTTD.

Fase della pipeline / della pianificazione Tempistica di valutazione Impatto sulla misurazione del MTTD
Regola per eventi singoli (streaming) Continua (<5 minuti dopo l'arrivo) I rilevamenti in tempo reale rappresentano la velocità effettiva della piattaforma con un impatto minimo sul MTTD.
Regola per più eventi (esecuzione principale) Da 1 a 2 ore dopo l'arrivo (più il ritardo di liquidazione configurato) Include la finestra di buffering batch inevitabile necessaria per aggregare gli stati di correlazione di più eventi.
Regola per più eventi (esecuzioni di allineamento) 4 ore o 30 ore dopo l'esecuzione principale Un'esecuzione secondaria (di riproduzione) che incorpora i dati di arricchimento in ritardo fa sì che questo tempo appaia in ritardo rispetto al timestamp dell'evento. Questo delta influisce negativamente sul calcolo del MTTD.

Best practice per la misurazione del MTTD

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

Google SecOps fornisce diverse metriche interrogabili dall'utente per misurare con precisione il MTTD. Per saperne di più su queste metriche, consulta la sezione Esempi di query YARA-L 2.0 per la pagina Dashboard.

Un'icona nella colonna Tipo di rilevamento identifica i rilevamenti generati da dati sugli eventi arrivati con un ritardo superiore a 30 minuti, esecuzioni di allineamento automatiche, pipeline di rielaborazione o retrohunts. Questa icona viene visualizzata anche nella pagina Avvisi in Google SecOps.

Dai la priorità ai sistemi di rilevamento in tempo reale

Per i rilevamenti più rapidi, utilizza le regole per eventi singoli. Queste regole vengono eseguite quasi in tempo reale, in genere con un ritardo inferiore a 5 minuti. Ciò supporta anche un utilizzo più completo dei rilevamenti compositi.

Tieni conto della riproduzione delle regole nelle regole per più eventi

Le regole per più eventi comportano intrinsecamente una latenza maggiore a causa della frequenza di esecuzione pianificata . Quando misuri il MTTD per i rilevamenti dalle regole per più eventi, tieni presente che le riproduzioni delle regole automatizzate aumentano la copertura e l'accuratezza. Queste riproduzioni spesso rilevano minacce che richiedono un contesto in ritardo, il che aumenta la latenza segnalata per questi rilevamenti.

  • Per gli avvisi critici e urgenti: utilizza regole per eventi singoli 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 join contestuali estesi o elenchi di riferimento, 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 maggiore fedeltà anziché di una velocità assoluta.

Ottimizza le regole per ridurre la dipendenza dall'arricchimento in ritardo

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

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.