Verzögerungen bei der Erkennung von Regeln

Unterstützt in:

In diesem Dokument werden Verzögerungen bei der Erkennung von Regeln in Google Security Operations erläutert. Außerdem werden die Faktoren identifiziert, die zu Verzögerungen in den Pipelines für die Aufnahme und Verarbeitung von Daten beitragen. Darüber hinaus werden strukturierte Ansätze zur Fehlerbehebung und Techniken zur Reduzierung der Erkennungslatenz vorgestellt.

Überblick über Erkennungsregeln

Erkennungsregeln untersuchen normalisierte Rohlogs – sowohl reguläre als auch Entitätsereignisse des Universal Data Model (UDM) –, um gemäß den Regelspezifikationen Sicherheitserkennungen zu generieren. UDM-Entitätsereignisse enthalten in der Regel Kontextinformationen wie Nutzer- oder Asset-Metadaten. Erkennungsregeln können auch zuvor generierte Erkennungen auswerten, um zusammengesetzte Benachrichtigungen zu erstellen.

Erwartete und unerwartete Verzögerungen

Die Erkennungslatenz variiert je nach Regellogik, Datenabhängigkeiten und Systemverarbeitungszyklen. Verzögerungen werden in zwei Kategorien unterteilt:

  • Erwartete Verzögerungen: Verzögerungen, die auf strukturellen Faktoren beruhen, z. B. dem Aufnahmeprozess, dem Regeltyp, der Ausführungshäufigkeit, der Methode zur Erkennungserstellung, der Dauer des Abgleichzeitfensters und bekannten Systemlimits. Sie können erwartete Verzögerungen minimieren, indem Sie die Konfigurationen der Erkennungsregeln und die Planungsparameter optimieren.
  • Unerwartete Verzögerungen: Verzögerungen, die durch externe oder dynamische Pipelinebedingungen verursacht werden, einschließlich Engpässen bei der Logbereitstellung aus Datenquellen, vorübergehender Verarbeitungslatenz in Google SecOps-Diensten, verzögerter Verfügbarkeit von Kontextdaten und Zyklen zur erneuten Anreicherung von UDM-Daten.

Methoden zur Erkennungserstellung

Google SecOps generiert Regelerkennungen über die folgenden Ausführungspipelines:

  • Streaming-Engine: Eine Hochgeschwindigkeitspipeline, die Standard- und Fenster-Einzelereignisregeln kontinuierlich nahezu in Echtzeit auswertet (in der Regel innerhalb von 5 Minuten nach der Aufnahme). Spät eintreffende Ereignisse und rückwirkende Anreicherungen werden während der Standardausführung kontinuierlich ausgewertet.
  • Abfrage-Engine: Wertet Regeln aus, die eine zeitbasierte Ereigniskorrelation über mehrere Ereignisse oder externe Daten-Joins erfordern:
    • Komplexe Einzelereignisregeln: Umfasst Einzelereignisregeln, die Referenzlisten oder Datentabellen abfragen.
    • Mehrfachereignisregeln: Fragt Daten in Batchblöcken der Ereigniszeit ab (z. B. in Intervallen von 10 Minuten oder 1 Stunde oder match_window / 10 für Fenster mit mehr als 48 Stunden) basierend auf konfigurierten Zeitplänen.
  • Regeln mit Verlaufsdaten ausführen: Wertet Regeln rückwirkend anhand von Verlaufslogs durch Retrohunts aus. Erkennungen werden nach Abschluss des Verlaufs-Scans angezeigt.
  • Erneute Anreicherung von UDM-Ereignissen: Wertet zuvor verarbeitete Zeitblöcke neu aus, wenn neue Kontextdaten oder aktualisierte Entitätsdaten zu Verlaufsereignissen hinzugefügt werden.

Faktoren, die zu Verzögerungen bei der Erkennung von Regeln beitragen

Die Geschwindigkeit, mit der Erkennungen angezeigt werden, hängt von der Regelkomplexität, den Planungsintervallen, der Latenz bei der Datenaufnahme und den Pipelines für die Kontextanreicherung ab.

Regeltypen und Komplexität

Erkennungsregeln fallen in mehrere Kategorien mit unterschiedlichen Latenzprofilen:

Einzelereignisregeln

Einzelereignisregeln werden nahezu in Echtzeit in der kontinuierlichen Streaming-Engine ausgeführt und bieten die niedrigste Erkennungslatenz. Diese Regeln werten einzelne Ereignisse aus, ohne externe Datasets, Datentabellen oder Abgleichzeitfenster für mehrere Ereignisse zu verwenden.

Komplexe Einzelereignisregeln

Diese Regeln werten einzelne Ereignisse aus, enthalten aber zusätzliche Datenabhängigkeiten:

  • Fenster-Einzelereignisregeln: Einzelereignisregeln, die einen match-Abschnitt enthalten (z. B. um zu prüfen, ob ein einzelnes Ereignis über einen bestimmten Zeitraum hinweg einer Bedingung entspricht). Diese Regeln werden nahezu in Echtzeit in der kontinuierlichen Streaming-Engine ausgewertet, sobald Daten aufgenommen werden.
  • Referenz-Einzelereignisregeln: Einzelereignisregeln, die Ereignisattribute mit Referenzlisten oder Datentabellen vergleichen.

Mehrfachereignisregeln

Mehrfachereignisregeln korrelieren zwei oder mehr UDM-Ereignisbedingungen über ein bestimmtes Abgleichzeitfenster und werden in geplanten Batchintervallen ausgeführt.

  • Standard-Mehrfachereignisregeln: Aggregieren mehrere Ereignisse über Zeitfenster hinweg und werden in Intervallen von 10 Minuten oder 1 Stunde ausgeführt (oder match_window / 10 für Fenster mit mehr als 48 Stunden).
  • Kontextsensitive Regeln: Korrelieren Ereignisdaten mit UDM-Entitätsereignissen (z. B. user_context oder asset_context) mithilfe kontextsensitiver Analysen. Da kontextsensitive Regeln auf mehreren Datenfeeds basieren, reagieren sie empfindlicher auf den Zeitpunkt der Aufnahme. Weitere Informationen finden Sie unter Kontextangereicherte Daten in Regeln verwenden.

Häufigkeit der Regelausführung

Die konfigurierte Ausführungshäufigkeit bestimmt, wie oft die Abfrage-Engine Ereigniszeitblöcke auswertet:

  • Nahezu in Echtzeit: Kontinuierliche Evaluierung für Einzelereignisregeln (Standard und Fenster).
  • 10-Minuten-Häufigkeit: Verfügbar für Mehrfachereignisregeln mit Abgleichzeitfenstern von weniger als 60 Minuten.
  • 1-Stunden-Häufigkeit: Standardintervall für Mehrfachereignisregeln mit Abgleichzeitfenstern von 48 Stunden oder weniger.
  • Häufigkeit match_window / 10: Wird automatisch für Mehrfachereignisregeln mit Abgleichzeitfenstern von mehr als 48 Stunden zugewiesen (z. B. alle 10 Stunden für ein 100-Stunden-Abgleichzeitfenster oder alle 24 Stunden für ein 10-Tage-Fenster).

Dauer des Abgleichzeitfensters

Bei Mehrfachereignisregeln definiert die Dauer des Abgleichzeitfensters den Beobachtungszeitraum, der zum Aggregieren von Ereignissen erforderlich ist. Erkennungen können erst angezeigt werden, wenn das gesamte Zeitfenster abgelaufen ist.

Verzögerung bei der Logaufnahme

Die Verzögerung bei der Aufnahme ist die Zeit, die zwischen dem Auftreten eines Ereignisses in der Quelle und dem Zeitpunkt vergeht, an dem Google SecOps das Log empfängt und parst.

Wenn ein Ereignis nach der ersten geplanten Auswertung für diesen Zeitblock eintrifft, wird es bei der ersten Ausführung nicht berücksichtigt. Das System erfasst spät eintreffende Daten in nachfolgenden automatisierten Hintergrundausführungen (Korrekturausführungen), die etwa 4 Stunden (und optional 30 Stunden mit vollständiger Anreicherung) nach der primären Ausführung stattfinden.

  • Beispiel: Eine Regel korreliert Ereignis A (Ereigniszeit 9:03 Uhr) und Ereignis B (Ereigniszeit 9:05 Uhr) innerhalb eines 30-Minuten-Fensters. Wenn Ereignis A um 10:05 Uhr eintrifft (eine Stunde zu spät), wird es bei der ersten Ausführung für den Block von 9:00 bis 9:30 Uhr nicht berücksichtigt. Das System wertet den Block bei einer nachfolgenden Korrekturausführung etwa 4 Stunden nach der primären Ausführung (gegen 14:00 Uhr) neu aus und generiert die Erkennung etwa 5 Stunden nach dem Auftreten des Ereignisses.

Abweichungen bei der Zeitzone

Google SecOps interpretiert Logzeitstempel standardmäßig als UTC. Wenn eine Logquelle keinen expliziten Zeitunterschied zur Zeitzone angibt, behandelt das System den Zeitstempel als UTC. Dadurch kann das Log als spät eintreffend angezeigt werden, auch wenn es sofort empfangen wurde.

  • Beispiel: Ein Ereignis tritt um 10:00 Uhr Eastern Time (15:00 Uhr UTC) auf und kommt um 15:05 Uhr UTC ohne Metadaten zur Zeitzone bei Google SecOps an. Das System interpretiert den Zeitstempel als 10:00 Uhr UTC, was zu einer scheinbaren Verzögerung bei der Aufnahme von 5 Stunden führt, die die Regelauswertung auf eine Korrekturausführung im Hintergrund verschiebt.

Problemumgehungen: So beheben Sie Abweichungen bei der Zeitzone:

  • Konfigurieren Sie die Protokollquelle so, dass explizite UTC-Zeitzonen-Offsets in Ereigniszeitstempeln enthalten sind.
  • Wenden Sie sich an den Support, um eine Zeitzonenüberschreibung für den jeweiligen Aufnahmefeed festzulegen.
  • Verwenden Sie einen BindPlane-Prozessor, um Zeitstempel im Logtext vor der Aufnahme in UTC zu normalisieren. Weitere Informationen finden Sie unter Zeitstempel im Logtext mit BindPlane ändern.

Kontextbezogene Joins und Datenanreicherung

Google SecOps reichert UDM-Ereignisse an, indem Identitäts-, Asset- und Bedrohungsmetadaten aus sekundären Quellen hinzugefügt werden. Verzögerungen bei der Verfügbarkeit von Kontextdaten können die Erkennungszeit verlängern.

Aliasing- und Anreicherungsmechanismen

Aliasing und Anreicherung korrelieren Rohindikatoren mit dem Organisationskontext:

  • Aliasing: Identifiziert und verknüpft verschiedene IDs für dieselbe Entität in verschiedenen Datenquellen (z. B. Zuordnung einer IP-Adresse aus DHCP-Logs zu einer MAC-Adresse und einem Hostnamen wie alex-macbook oder Zuordnung einer Nutzer-ID zu einer Berufsbezeichnung eines Mitarbeiters).
  • Anreicherung: Füllt normalisierte UDM-Ereignisfelder mit dem Alias-Kontext aus (z. B. Ausfüllen von $udm.event.principal.hostname, wenn im Rohereignis nur eine IP-Adresse vorhanden ist).

Zu den unterstützten Anreicherungstypen gehören Assets, Nutzer, Prozesse, Metadaten zu Dateihashes, geografische Standorte und Cloud-Ressourcen. Weitere Informationen finden Sie unter Übersicht über UDM-Anreicherung und -Aliasing.

Erneute Anreicherung von UDM-Ereignissen

Das System aktualisiert Verlaufsereignisse kontinuierlich, wenn sich Kontextquellen ändern:

  • Änderungen an den zugrunde liegenden Daten: Verlaufsereignisse können bis zu 24 Stunden nach der Aufnahme aktualisiert werden, wenn neue Kontextdaten eintreffen.
  • Updates des Anreicherungssystems: Wenn Entitätsmetadaten, die IP-Geolokalisierung oder VirusTotal Threat Intelligence aktualisiert werden, wertet die Regel-Engine Verlaufsblöcke neu aus (in der Regel während geplanter Korrekturausführungen oder der Neuverarbeitung), um Erkennungen mit aktualisiertem Kontext zu generieren.
  • Verzögerte Kontextdaten: Wenn Kontextdaten (z. B. ein Hostname) einen Tag nach dem Ereignislog eintreffen, reichert das System das UDM-Ereignis erneut an und nachfolgende Korrekturausführungen werten den angereicherten Datensatz aus.
  • Kontextänderungen: Wenn durch ein Anreicherungsupdate ein Ereignisattribut geändert wird (z. B. Aktualisierung der IP-Geolokalisierung von USA zu Canada), lösen Regeln, die mit dem aktualisierten Wert übereinstimmen, bei nachfolgenden Neubewertungen Erkennungen aus.

Verarbeitung des Entitätskontextdiagramms (Entity Context Graph, ECG)

Das Entitätskontextdiagramm (Entity Context Graph, ECG) korreliert Indikatoren für Kompromittierung (Indicators of Compromise, IOCs) und Daten aus dem Unternehmens-Asset-Diagramm. Da die ECG-Pipeline auf der Batchverarbeitung basiert (die je nach Datenmenge 30 Stunden oder mehrere Tage dauern kann), generieren Regeln, die auf graph.entity-Felder verweisen, Erkennungen, nachdem die Diagrammbeziehungen vollständig berechnet wurden.

Verlaufsregelausführungen und Retrohunts

Wenn Sie eine Regel mit Verlaufsdaten ausführen, werden Erkennungen erst generiert, nachdem der Retrohunt-Scan im ausgewählten Zeitraum abgeschlossen ist.

  • Workflow für die rückwirkende Anreicherung:
    1. Um 13:00 Uhr trifft ein Ereignis mit ip_address = 10.0.0.5 ein (Hostname unbekannt).
    2. Um 14:30 Uhr trifft ein DHCP-Log ein, das 10.0.0.5 mit workstation-123 verknüpft.
    3. Die Aliasing-Pipeline aktualisiert das Verlaufsereignis von 13:00 Uhr mit principal.hostname = workstation-123.
    4. Bei nachfolgenden Regelausführungen wird der angereicherte Hostname ausgewertet und es werden Erkennungen angezeigt, die bei der ersten Ausführung nicht ausgelöst wurden.

Referenzlisten

Regeln, die Referenzlisten abfragen, werden zum Zeitpunkt der Ausführung anhand der neuesten Listenversion ausgewertet. Wenn Sie eine Referenzliste aktualisieren, können geplante Regeln rückwirkend Erkennungen für zuvor aufgenommene Logs generieren.

Regeln für „Nicht vorhanden“

Um falsch-positive Ergebnisse zu vermeiden, führt das System einen Puffer von mindestens einer Stunde ein, bevor Regeln ausgewertet werden, die auf Bedingungen für „Nicht vorhanden“ prüfen (z. B. !$e oder #e=0). So haben alle zugehörigen Logs Zeit, einzutreffen.

Einschränkungen bei der Datenverarbeitung und Korrekturausführung

Beachten Sie bei der Bewertung der Erkennungslatenz die folgenden Systemverhaltensweisen:

  • Anreicherungsprozess: Die Kontextanreicherung kann Verlaufs-UDM-Ereignisse bis zu 24 Stunden nach der ersten Aufnahme aktualisieren.
  • Korrekturzyklen: Mehrfachereignisregeln werden etwa 4 Stunden (und optional 30 Stunden) nach der primären Ausführung automatisch neu ausgeführt, um spät eintreffende Daten zu erfassen. Weitere Informationen finden Sie unter Regelausführungen und MTTD.
  • Erkennungslimits: Informationen zu den Kapazitäts- und Drosselungsgrenzen der Plattform finden Sie unter Erkennungslimits.

Fehlerbehebung bei Verzögerungen bei der Erkennung von Regeln

Um zu ermitteln, warum eine Regel eine verzögerte Erkennung generiert hat, untersuchen Sie die folgenden Heuristiken und Pipelinestufen in der Google SecOps Console:

  • Regelmetadaten und -zeitplan prüfen: Prüfen Sie im Regel-Dashboard die Spalten Regelname, Regeltyp und Regelzeitplan, um die Ausführungs-Engine und die grundlegende Auswertungshäufigkeit der Regel zu ermitteln.
  • Ereigniszeit mit Aufnahmezeit vergleichen: Suchen Sie die Erkennung auf dem Tab Erkennungen und vergleichen Sie den Ereigniszeitstempel mit dem Zeitstempel der Aufnahme. Wenn die Differenz zwischen Ereigniszeit und Aufnahmezeit mehr als 30 Minuten beträgt, wurde die Latenz durch Verzögerungen bei der Logbereitstellung in der Quelle oder während der Erfassung verursacht. Erkennungen, die aus Ereignisdaten generiert wurden, die mehr als 30 Minuten zu spät eintreffen, automatisierten Korrekturausführungen, Neuverarbeitungspipelines oder Retrohunts, werden in der Spalte Erkennungstyp mit einem gekennzeichnet.
  • Abhängigkeiten von Kontextquellen prüfen: Prüfen Sie, ob die Regel auf die Anreicherung von principal, UDM-Aliasing oder graph.entity-Felder verweist. Kontextpipelines werden asynchron verarbeitet und können Erkennungen bei nachfolgenden Korrekturausführungen anzeigen.
  • Kompatibilität von Häufigkeit und Abgleichzeitfenster prüfen: Prüfen Sie, ob die konfigurierte Ausführungshäufigkeit mit der Größe des Abgleichzeitfensters übereinstimmt (z. B. ob eine Regel mit einem 15-Minuten-Abgleichzeitfenster für 10 Minuten oder 1 Stunde geplant ist).
  • Auf Unterbrechungen des Datenfeeds prüfen: Prüfen Sie die Aufnahmeprotokolle und Dashboards für die Feedverwaltung auf Verzögerungen bei der Aufnahme oder vorübergehende Ausfälle der Quelle.

Tipps zur Verkürzung von Verzögerungen bei der Erkennung

Wenden Sie die folgenden Optimierungstechniken an, um Verzögerungen bei der Erkennung in Ihrer Umgebung zu minimieren:

  • Häufigkeit der Regelausführung optimieren:
    • Verwenden Sie Nahezu in Echtzeit für Einzelereignisregeln (Standard und Fenster).
    • Konfigurieren Sie einen 10-Minuten-Zeitplan für Mehrfachereignisregeln mit Abgleichzeitfenstern von weniger als 60 Minuten.
    • Verwenden Sie 1 Stunde für Regeln mit Abgleichzeitfenstern zwischen 1 und 48 Stunden, bei denen eine schnelle Benachrichtigung erforderlich ist.
  • Dauer des Abgleichzeitfensters optimieren: Legen Sie Abgleichzeitfenster auf die Mindestdauer fest, die erforderlich ist, um das korrelierte Bedrohungsverhalten zu erfassen.
  • Engpässe bei der Logbereitstellung beseitigen: Achten Sie darauf, dass Weiterleitungen und Erfassungen Ereignisdaten sofort senden, damit Logs das erste Ausführungsfenster nicht verpassen.
  • Zeitzonenkonfigurationen validieren: Achten Sie darauf, dass Logquellen explizite UTC-Zeitunterschiede angeben, um scheinbare Verzögerungen bei der Aufnahme von mehr als 5 Stunden zu vermeiden.
  • Kontext- und Nicht-Vorhanden-Bedingungen prüfen: Verwenden Sie kontextangereicherte Felder und Nicht-Vorhanden-Bedingungen (!$e) nur, wenn dies für die Erkennungslogik erforderlich ist, da diese absichtliche Pufferzeiten einführen.

Nächste Schritte

Weitere Informationen zu verwandten Planungskonzepten und Konfigurationsworkflows finden Sie in den folgenden Dokumenten:

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