Ottimizzare il rendimento delle regole
Questo documento descrive come ottimizzare le prestazioni di rilevamento e generazione di report.
Latenza totale del rilevamento
Per un Security Operations Center (SOC), il tempo medio totale di rilevamento (MTTD) è la somma dei ritardi temporali nella pipeline di sicurezza. Per misurare e ridurre con precisione il tempo medio alla diagnosi, devi monitorare tre componenti principali:
- Latenza di acquisizione dei log (dalla creazione dei log all'importazione dati)
- Latenza di elaborazione delle regole (importazione dati alla creazione del rilevamento)
- Latenza di conferma della richiesta (dalla creazione del rilevamento all'assegnazione all'analista)
Latenza di acquisizione dei log (dalla creazione dei log all'importazione dati)
La latenza di importazione dei log è il tempo trascorso tra il momento in cui si è verificato l'evento di sicurezza nel sistema di origine (metadata.event_timestamp) e il momento in cui il log è stato importato e analizzato correttamente in Google Security Operations (metadata.ingested_time).
Fattori che contribuiscono:
- Problemi dell'agente di raccolta o dell'agente di inoltro (ad esempio, backlog o limitazione della larghezza di banda della rete).
- Problemi di analisi dell'origine log (ad esempio, ritardi nella normalizzazione UDM).
Per ridurre la latenza di importazione dei log:
- Monitora lo stato delle sorgenti log e ottimizza le configurazioni dell'agente di raccolta o dell'agente di inoltro.
- Per monitorare la differenza, in YARA-L o Data Lake, confronta i timestamp UDM:
metadata.ingested_timestampemetadata.event_timestamp.
Latenza di elaborazione delle regole (importazione dati alla creazione del rilevamento)
La latenza di elaborazione delle regole è il tempo trascorso tra l'importazione dati e il momento in cui il motore di rilevamento crea correttamente un avviso (detection.creation_time). Questo componente è fortemente influenzato dalla configurazione delle regole YARA-L.
Fattori che contribuiscono:
- Frequenza di esecuzione della regola:quasi in tempo reale (migliore), 10 minuti, 1 ora o 24 ore. Maggiore è la frequenza, maggiore è la latenza di elaborazione minima. Per saperne di più, vedi Impostare la frequenza di esecuzione.
- Tipo e complessità della regola:le regole per più eventi richiedono una finestra di corrispondenza per essere elaborate completamente, il che comporta una latenza intrinseca. Anche le regole composite che si basano su altre rilevazioni non in tempo reale introducono ritardi. Per saperne di più, consulta Rilevamenti compositi.
Per ridurre la latenza di elaborazione delle regole:
- Se possibile, utilizza regole per eventi singoli eseguite quasi in tempo reale.
- Per le regole multi-evento, imposta la dimensione della finestra più piccola possibile.
Per saperne di più, consulta Query YARA-L 2.0 di esempio per le dashboard.
Regola YARA-L per monitorare la latenza di elaborazione delle regole
La seguente regola YARA-L identifica le istanze in cui il delta tra l'ora di importazione di un log e l'ora di creazione del rilevamento supera una soglia specifica. Utilizza la regola per identificare i colli di bottiglia delle prestazioni nella pipeline di rilevamento.
Esegui il deployment di questa regola nell'ambiente di test per stabilire una baseline per le origini log.
Puoi esportare questi risultati in una dashboard per visualizzare le tendenze della latenza in diversi tipi di log.
La regola confronta metadata.event_timestamp (quando si è verificata l'attività) con metadata.ingested_time (quando Google SecOps ha ricevuto il log).
rule rule_processing_latency_monitor {
meta:
author = "SecOps Engineering"
description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
severity = "Low"
events:
$event.metadata.event_timestamp.seconds = $event_ts
$event.metadata.ingested_time.seconds = $ingest_ts
// Calculate the delta in seconds
$latency_delta = $ingest_ts - $event_ts
// Threshold: 900 seconds (15 minutes)
$latency_delta > 900
match:
$event.metadata.log_type over 1h
outcome:
$max_latency = max($latency_delta)
$log_source = array_distinct($event.metadata.log_type)
condition:
$event
}
Latenza di riconoscimento della richiesta (dalla creazione del rilevamento all'assegnazione all'analista)
Questa sezione non riguarda i clienti che utilizzano la piattaforma standalone Google SecOps SIEM.
La latenza di riconoscimento del caso è il tempo trascorso tra il rilevamento che crea un avviso e l'avviso riconosciuto da un analista per la valutazione nel componente SOAR.
La metrica tempo medio di riconoscimento (MTTA) monitora in modo specifico l'efficienza del team SOC nel rispondere a un avviso generato.
- Per ridurre la latenza di conferma della richiesta, ottimizza il routing, l'ottimizzazione e l'automazione degli avvisi (ad esempio, utilizzando playbook per l'assegnazione automatica o l'arricchimento) per spostare rapidamente l'avviso alla fase di triage.
Passaggi successivi
- Per scoprire di più su come i replay delle regole (chiamati anche esecuzioni di pulizia) gestiscono i dati in arrivo in ritardo e gli aggiornamenti del contesto e in che modo ciò influisce sulle metriche MTTD, consulta Informazioni sui replay delle regole e sull'MTTD.
- Per scoprire di più sui ritardi nel rilevamento delle regole in Google SecOps, sui fattori che contribuiscono a questi ritardi, sulla risoluzione dei problemi e sulle tecniche per ridurre i ritardi, consulta Informazioni sui ritardi nel rilevamento delle regole.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.