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).
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 due diverse categorie di regole:
Regole per un singolo evento:quando il processo di arricchimento UDM aggiorna un evento valutato in precedenza, il sistema riproduce le regole per un singolo evento.
Regole multi-evento:le regole multi-evento vengono eseguite in base a una pianificazione selezionata da te, 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 di utenti o asset o un indicatore di compromissione (IOC).
Ad esempio, una regola potrebbe essere eseguita almeno due o tre volte (a distanza di 5-8 ore e di nuovo a distanza di 24-48 ore) per tenere conto dei dati di contesto e degli eventi in ritardo.
Attivatori di riproduzione delle regole
Il sistema rivaluta (riesegue) le regole quando arrivano dati contestuali pertinenti o quando i dati contestuali vengono elaborati in un secondo momento rispetto ai dati iniziali dell'evento.
I motivi più comuni per la riproduzione includono:
Dati di arricchimento in ritardo:le pipeline di arricchimento dei dati, come il grafico del contesto delle entità (ECG), spesso elaborano i dati in batch. Quando un evento UDM arriva prima dei dati contestuali correlati (come le informazioni sugli asset o il contesto dell'utente), l'esecuzione iniziale della regola potrebbe non rilevare una minaccia.
Aggiornamenti retroattivi dell'arricchimento 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 (ad esempio, i record DHCP) vengono ritardati. Questo arrivo in ritardo aggiorna retroattivamente i valori dei campi. Le riproduzioni successive delle regole utilizzano questi valori appena arricchiti, il che potrebbe attivare un rilevamento precedentemente mancato.
Impatto sulle metriche di timing
Quando un rilevamento è il risultato della riproduzione di una regola, utilizziamo la seguente terminologia:
- 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 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. | Questo valore rimane preciso rispetto all'ora 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.
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 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.
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 il MTTD per i rilevamenti dalle regole multi-evento, tieni presente che le ripetizioni automatiche delle regole aumentano la copertura e l'accuratezza. 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 in più fasi): 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 più fedele anziché 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 delle regole, ove possibile.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.