Regelleistung optimieren

Unterstützt in:

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

Gesamte Erkennungslatenz

Für ein Security Operations Center (SOC) ist die 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 Hauptkomponenten im Blick behalten:

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

Die Latenz bei der Logaufnahme ist die Zeit, die zwischen dem Auftreten des Sicherheitsereignisses im Quellsystem (metadata.event_timestamp) und dem erfolgreichen Aufnehmen und Parsen des Logs in Google Security Operations (metadata.ingested_time) vergangen ist.

Beitragende Faktoren:

  • Probleme mit dem Collector oder Weiterleiter (z. B. Backlogs oder Netzwerkdrosselung).
  • Probleme beim Parsen der Protokollquelle (z. B. Verzögerungen bei der UDM-Normalisierung).

So reduzieren Sie die Latenz bei der Logaufnahme:

  • Überwachen Sie den Status der Logquelle und optimieren Sie die Konfigurationen des Collectors oder Weiterleiters.
  • Vergleichen Sie in YARA-L oder Data Lake die UDM-Zeitstempel metadata.ingested_timestamp und metadata.event_timestamp, um die Differenz zu überwachen.

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

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

Beitragende Faktoren:

  • Regelausführungshäufigkeit:Nahezu in Echtzeit (niedrigste Latenz), 10 Minuten, 1 Stunde oder match_window / 10 (für Abgleichszeiträume von mehr als 48 Stunden). Weitere Informationen finden Sie unter Ausführung von Regeln planen.
  • Regeltyp und -komplexität:Für die vollständige Verarbeitung von Regeln mit mehreren Ereignissen ist ein Abgleichszeitraum erforderlich, was zu einer inhärenten Latenz führt. Auch zusammengesetzte Regeln, die auf anderen Erkennungen beruhen, die nicht in Echtzeit erfolgen, führen zu Verzögerungen. Weitere Informationen finden Sie unter Zusammengesetzte Erkennungen.

So reduzieren Sie die Latenz bei der Regelverarbeitung:

  • 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 Regelverarbeitung

Die folgende YARA-L-Regel identifiziert Fälle, in denen die Differenz zwischen dem Zeitpunkt, an dem ein Log aufgenommen wurde, und dem Zeitpunkt, an dem die Erkennung erstellt wurde, einen bestimmten Schwellenwert überschreitet. Verwenden Sie die Regel, um Leistungsengpässe in Ihrer Erkennungspipeline zu identifizieren.

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

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

Die Regel vergleicht metadata.event_timestamp (Zeitpunkt des Ereignisses) mit metadata.ingested_time (Zeitpunkt, an dem Google SecOps das Log erhalten hat). 

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 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 bei der Fallbestätigung ist die Zeit, die zwischen der Erkennung, die eine Benachrichtigung erstellt, und dem Zeitpunkt vergangen ist, an dem die Benachrichtigung von einem Analysten zur Triage in der SOAR-Komponente bestätigt wurde.

Mit der Messung Mean Time to Acknowledge (MTTA) wird speziell die Effizienz des SOC-Teams bei der Reaktion auf eine generierte Benachrichtigung erfasst.

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

Nächste Schritte

  • Informationen dazu, wie Regelwiederholungen (auch Bereinigungsdurchläufe genannt) verspätet eingehende Daten und Kontextaktualisierungen verwalten 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 beitragenden Faktoren, zur Fehlerbehebung und zu Techniken zur Reduzierung 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