Leistung bei der Erkennung und Berichterstellung optimieren

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie die Leistung von Erkennung und Berichterstellung optimieren.

Gesamtlatenz bei der Erkennung

Für ein Security Operations Center (SOC) ist die gesamte mittlere Erkennungszeit (Mean Time To Detect, MTTD) die Summe der Zeitverzögerungen in der gesamten Sicherheitspipeline. Um die MTTD genau zu messen und zu reduzieren, müssen Sie drei Hauptkomponenten im Blick behalten:

Latenz bei der Logaufnahme (von der Logerstellung bis zur Datenaufnahme)

Die Latenz bei der Aufnahme von Logs ist die Zeit, die zwischen dem Zeitpunkt, zu dem das Sicherheitsereignis im Quellsystem (metadata.event_timestamp) aufgetreten ist, und dem Zeitpunkt, zu dem das Log in Google Security Operations (metadata.ingested_time) erfolgreich aufgenommen und geparst wurde, vergangen ist.

Beitragende Faktoren:

  • Probleme mit Collector oder Forwarder (z. B. Backlogs oder Netzwerk-Throttling).
  • Probleme beim Parsen von Log-Quellen (z. B. Verzögerungen bei der UDM-Normalisierung).

So reduzieren Sie die Latenz bei der Aufnahme von Logs:

  • Überwachen Sie den Status der Log-Quelle und optimieren Sie die Konfigurationen von Collector oder Forwarder.
  • Um das Delta in YARA-L oder Data Lake zu überwachen, vergleichen Sie die UDM-Zeitstempel – metadata.ingested_timestamp und metadata.event_timestamp.

Latenz bei der Verarbeitung von Regeln (von der Datenerfassung bis zur Erstellung von Erkennungen)

Die Latenz bei der Regelverarbeitung ist die Zeit, die zwischen der Datenerfassung und dem Zeitpunkt vergeht, an dem die Erkennungs-Engine erfolgreich eine Benachrichtigung (detection.creation_time) erstellt. Diese Komponente wird stark von der Konfiguration Ihrer YARA-L-Regeln beeinflusst.

Beitragende Faktoren:

  • Häufigkeit der Regelausführung:nahezu in Echtzeit (am besten), 10 Minuten, 1 Stunde oder 24 Stunden. Je höher die Häufigkeit, desto höher die minimale Verarbeitungslatenz. Weitere Informationen finden Sie unter Ausführungshäufigkeit festlegen.
  • Regeltyp und Komplexität:Für Regeln mit mehreren Ereignissen ist ein Abgleichszeitraum erforderlich, um sie vollständig zu verarbeiten. Das führt zu einer gewissen Latenz. Auch zusammengesetzte Regeln, die auf anderen nicht in Echtzeit erfolgenden Erkennungen basieren, führen zu Verzögerungen. Weitere Informationen finden Sie unter Zusammengesetzte Erkennungen.

So reduzieren Sie die Latenz bei der Verarbeitung von Regeln:

  • Verwenden Sie nach Möglichkeit Regeln für einzelne Ereignisse, die nahezu in Echtzeit ausgeführt werden.
  • Legen Sie für Regeln mit mehreren Ereignissen die kleinstmögliche Fenstergröße fest.

Weitere Informationen finden Sie unter YARA-L 2.0-Beispielabfragen für Dashboards.

YARA-L-Regel zur Überwachung der Latenz bei der Verarbeitung von Regeln

Mit der folgenden YARA-L-Regel werden Instanzen identifiziert, in denen die Differenz zwischen dem Zeitpunkt, zu dem ein Log aufgenommen wurde, und dem Zeitpunkt, zu dem die Erkennung erstellt wurde, einen bestimmten Schwellenwert überschreitet. Mit der Regel lassen sich Leistungsengpässe in Ihrer Erkennungs-Pipeline identifizieren.

Stellen Sie diese Regel in Ihrer Testumgebung bereit, um eine Baseline für Ihre Protokollquellen zu erstellen.

Sie können diese Ergebnisse in ein Dashboard exportieren, um Latenztrends für verschiedene Logtypen zu visualisieren.

In der Regel wird der metadata.event_timestamp-Wert (Zeitpunkt der Aktivität) mit dem metadata.ingested_time-Wert (Zeitpunkt des Empfangs des Logs durch Google SecOps) verglichen. 

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
}

Latenz bei der Fallbestätigung (Erstellung der Erkennung bis zur Zuweisung an einen Analysten)

Dieser Abschnitt ist für Kunden, die die eigenständige Google SecOps SIEM-Plattform verwenden, nicht relevant.

Die Latenz für die Bestätigung von Fällen ist die Zeit, die zwischen der Erkennung, die eine Benachrichtigung auslöst, und der Bestätigung der Benachrichtigung durch einen Analysten für die Triage in der SOAR-Komponente vergeht.

Mit dem Messwert durchschnittliche Zeit bis zur Bestätigung (Mean Time To Acknowledge, MTTA) wird die Effizienz des SOC-Teams bei der Reaktion auf eine generierte Benachrichtigung gemessen.

  • Um die Latenz bei der Fallbestätigung zu verringern, optimieren Sie das Alert-Routing, die Abstimmung und die Automatisierung (z. B. mithilfe von Playbooks für die automatische Zuweisung oder Anreicherung), um den Alert schnell in die Triage-Phase zu verschieben.

Nächste Schritte

  • Informationen dazu, wie Regelwiederholungen (auch Bereinigungsdurchläufe genannt) mit verspätet eingehenden Daten und Kontextaktualisierungen umgehen und wie sich dies auf die MTTD-Messwerte auswirkt, finden Sie unter Regelwiederholungen und MTTD.
  • Weitere Informationen zu Verzögerungen bei der Regelerkennung in Google SecOps, zu den beitragenden Faktoren, zur Fehlerbehebung und zu Techniken zur Verringerung von Verzögerungen finden Sie unter Verzögerungen bei der Regelerkennung.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten