Ottimizzare il rendimento delle regole

Supportato in:

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 l'MTTD, devi monitorare tre componenti principali:

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 relativi all'agente di raccolta o all'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 inserimento dei log:

  • Monitora l'integrità della sorgente 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_timestamp e metadata.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 delle regole:quasi in tempo reale (latenza più bassa), 10 minuti, 1 ora o match_window / 10 (per finestre di corrispondenza superiori a 48 ore). Per saperne di più, consulta Informazioni sulla pianificazione dell'esecuzione delle regole.
  • 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 altri rilevamenti 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 il momento dell'importazione di un log e il momento della 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 base di riferimento 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 del caso (dalla creazione del rilevamento all'assegnazione all'analista)

Questa sezione non è pertinente per 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 come influiscono sulle metriche MTTD, consulta Informazioni sui replay delle regole e sull'MTTD.
  • Per saperne 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.