Informazioni sulle ripetizioni delle regole e sul MTTD
Questo documento spiega in che modo le riproduzioni delle regole (chiamate anche esecuzioni di pulizia) gestiscono i dati in arrivo in ritardo e gli aggiornamenti del contesto e in che modo ciò influisce sulle metriche del tempo medio di rilevamento (MTTD).
Replay 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. Questo processo valuta più volte lo stesso blocco di dati sugli eventi a intervalli diversi per gestire dati in arrivo in ritardo o regole che richiedono un contesto aggiornato, ad esempio la corrispondenza con un indicatore di compromissione (IOC).
Attivatori di riproduzione delle regole
Le regole vengono rivalutate (eseguite di nuovo) quando i dati contestuali pertinenti arrivano o vengono elaborati in un secondo momento rispetto ai dati iniziali dell'evento.
I trigger di riproduzione delle regole più comuni includono:
Dati di arricchimento in ritardo
Le pipeline di arricchimento dei dati, come Entity Context Graph (ECG), potrebbero elaborare i dati in batch. Se un evento UDM arriva prima dei dati contestuali correlati (come le informazioni sugli asset o il contesto utente), una rilevazione potrebbe non essere eseguita durante l'esecuzione iniziale della regola.
Aggiornamenti retroattivi dell'arricchimento UDM
Se la regola utilizza campi con alias (campi arricchiti) nella logica di rilevamento, ad esempio
$udm.event.principal.hostname, e i dati di origine (ad esempio i record DHCP) arrivano più di un'ora dopo, i valori di questi campi vengono aggiornati retroattivamente per l'ora specifica dell'evento. Le esecuzioni successive delle regole ("esecuzioni di pulizia") utilizzano questi valori appena arricchiti, che possono attivare un rilevamento precedentemente mancato.Regole multi-evento programmate
Le regole multi-evento (ME) vengono eseguite in base a una pianificazione (ad esempio, ogni 10 minuti, ogni ora o ogni giorno) per valutare i blocchi di tempo degli eventi. Per acquisire gli aggiornamenti dell'arricchimento tardivo dei dati storici, queste regole rivalutano lo stesso blocco di tempo in un secondo momento, spesso eseguendo almeno due o tre volte (ad esempio, con controlli a 5-8 ore e di nuovo a 24-48 ore di distanza).
Impatto sulle metriche di timing
Quando un rilevamento è il risultato della riproduzione di una regola, la Finestra di rilevamento o il Timestamp evento dell'avviso si riferisce all'ora dell'attività dannosa originale. L'ora di creazione è l'ora in cui viene creata la rilevazione, che può essere molto successiva, a volte ore o giorni dopo.
Una latenza di rilevamento elevata (una grande differenza di tempo tra l'evento e il rilevamento) è in genere causata dal riarricchimento dei dati in arrivo in ritardo o dalla latenza nella pipeline del grafico del contesto delle entità (ECG).
Questa differenza di tempo 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 decisione |
|---|---|---|
| Finestra di rilevamento / timestamp evento | L'ora in cui si è verificato l'evento di sicurezza originale. | Queste informazioni rimangono accurate rispetto all'orario dell'evento. |
| Tempo di rilevamento / Ora di creazione | Ora in cui il rilevamento è stato effettivamente emesso dal motore. | Questo orario viene visualizzato come "in ritardo" o "posticipato" rispetto al timestamp dell'evento perché si basa su un'esecuzione secondaria (replay) che incorpora i dati di arricchimento tardivi. 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.
Dai la priorità ai sistemi di rilevamento in tempo reale
Per i 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 si misura l'MTTD per i rilevamenti generati da regole multi-evento, è fondamentale riconoscere che i rilevamenti risultanti dalle ripetizioni automatiche delle regole servono ad aumentare la copertura e la precisione. Sebbene questi replay spesso rilevino minacce che richiedono un contesto tardivo, aumenteranno necessariamente la latenza segnalata per quel rilevamento specifico.
Per avvisi critici e urgenti:utilizza regole per singoli eventi o per più eventi con le frequenze di esecuzione pratiche più brevi (ad esempio, finestre di corrispondenza più brevi, inferiori a un'ora).
Per la correlazione complessa e di lunga durata (UEBA, attacchi in più fasi): prevedi una latenza maggiore (fino a 48 ore o più) se le regole si basano su unioni contestuali estese o elenchi di riferimento che potrebbero essere aggiornati in modo asincrono. Il vantaggio in questo caso è un rilevamento più fedele, non una 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 non soggetti a pipeline di arricchimento downstream) nella logica della regola, ove possibile.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.