Ottimizzare le prestazioni di rilevamento e generazione di report

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 il tempo medio alla diagnosi, devi monitorare tre componenti principali:

Latenza di importazione 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 del raccoglitore o del programma di inoltro (ad esempio backlog o limitazione 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 origini log e ottimizza le configurazioni del raccoglitore o dell'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 (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 multi-evento 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 singoli eventi 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 in che modo le ripetizioni delle regole (chiamate anche esecuzioni di pulizia) gestiscono gli aggiornamenti dei dati e del contesto in arrivo in ritardo e in che modo ciò influisce sulle metriche MTTD, consulta Informazioni sulle ripetizioni 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.