Regelleistung optimieren

Unterstützt in:

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

Gesamtlatenz bei der Erkennung

Für ein Security Operations Center (SOC) ist die gesamte durchschnittliche Zeit bis zur Erkennung (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 primäre Komponenten im Blick behalten:

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

Die Latenz bei der Protokollaufnahme ist die Zeit, die zwischen dem Auftreten des Sicherheitsereignisses im Quellsystem (metadata.event_timestamp) und der erfolgreichen Aufnahme und Analyse des Protokolls in Google Security Operations (metadata.ingested_time) vergangen ist.

Beitragende Faktoren:

  • Probleme mit Collector oder Forwarder (z. B. Backlogs oder Netzwerkdrosselung).
  • Probleme beim Parsen von Protokollquellen (z. B. Verzögerungen bei der UDM-Normalisierung).

So reduzieren Sie die Latenz bei der Aufnahme von Logs:

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

Latenz bei der Regelverarbeitung (Datenaufnahme bis zur Erstellung von Erkennungen)

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

Beitragende Faktoren:

  • Häufigkeit der Regelausführung:Nahezu in Echtzeit (niedrigste Latenz), 10 Minuten, 1 Stunde oder match_window / 10 (für Übereinstimmungsfenster von mehr als 48 Stunden). Weitere Informationen finden Sie unter Regelausführung planen.
  • Regeltyp und Komplexität:Für Regeln für mehrere Ereignisse ist ein Abgleichszeitfenster 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 verringern Sie die Latenz bei der Verarbeitung von Regeln:

  • Verwenden Sie nach Möglichkeit Einzelereignisregeln, die nahezu in Echtzeit ausgeführt werden.
  • Legen Sie für Regeln für mehrere Ereignisse die kleinstmögliche Zeitfenstergröß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

Die folgende YARA-L-Regel identifiziert Fälle, 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 können Sie 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, zu dem Google SecOps das Protokoll empfangen hat) 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 (von der Erkennungserstellung bis zur Analystenzuweisung)

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 Bestätigung von Fällen zu verringern, optimieren Sie das Weiterleiten, die Anpassung und die Automatisierung von Benachrichtigungen (z. B. durch die Verwendung von Playbooks für die automatische Zuweisung oder Anreicherung), damit die Benachrichtigung schnell in die Triage-Phase gelangt.

Nächste Schritte

  • Weitere Informationen zu Regelwiederholungen (auch Bereinigungsdurchläufe genannt) und dazu, wie damit verspätet eingehende Daten und Kontextaktualisierungen verwaltet werden und wie sich das auf die MTTD-Messwerte auswirkt, finden Sie hier.
  • 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