Verzögerungen bei der Regelerkennung

Unterstützt in:

In diesem Dokument werden Verzögerungen bei der Regelerkennung in Google Security Operations erläutert, Faktoren in Aufnahme- und Verarbeitungspipelines identifiziert, strukturierte Ansätze zur Fehlerbehebung beschrieben und Techniken zur Reduzierung der Erkennungslatenz vorgestellt.

Erkennungsregeln – Übersicht

Erkennungsregeln prüfen normalisierte Rohlogs – sowohl reguläre als auch Entitäts-UDM-Ereignisse (Universal Data Model) –, um Sicherheitserkennungen gemäß den Regelspezifikationen zu generieren. UDM-Ereignisse für Entitäten enthalten in der Regel Kontextinformationen wie Nutzer- oder Asset-Metadaten. Mit Erkennungsregeln können auch zuvor generierte Erkennungen ausgewertet werden, um zusammengesetzte Benachrichtigungen zu erstellen.

Erwartete und unvorhergesehene Verzögerungen

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

  • Erwartete Verzögerungen: Verzögerungen, die durch strukturelle Faktoren verursacht werden, z. B. den Aufnahmeprozess, den Regeltyp, die Ausführungshäufigkeit, die Methode zur Erkennungsgenerierung, die Dauer des Abgleichsfensters und bekannte Systemlimits. Sie können erwartete Verzögerungen minimieren, indem Sie die Konfigurationen der Erkennungsregeln und die Planungsparameter optimieren.
  • Unvorhergesehene Verzögerungen: Verzögerungen, die durch externe oder dynamische Pipelinebedingungen verursacht werden, einschließlich Engpässen bei der Protokollbereitstellung von Datenquellen, vorübergehender Verarbeitungslatenz innerhalb von Google SecOps-Diensten, verzögerter Kontextverfügbarkeit und UDM-Anreicherungszyklen.

Methoden zur Generierung von Erkennungen

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

  • Streaming-Engine: Eine Hochgeschwindigkeits-Pipeline, die Standard- und zeitfensterbasierte Einzelereignisregeln kontinuierlich und 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 Datenverknüpfungen erfordern:
    • Komplexe Einzelereignisregeln: Umfasst Einzelereignisregeln, die Referenzlisten oder Datentabellen abfragen.
    • Regeln für mehrere Ereignisse: Fragen Daten in Batches von Ereigniszeitblöcken (z. B. 10-Minuten- oder 1-Stunden-Intervallen oder match_window / 10 für Zeitfenster von mehr als 48 Stunden) basierend auf konfigurierten Zeitplänen ab.
  • Regeln werden auf Verlaufsdaten angewendet: Regeln werden rückwirkend auf Verlaufslogs angewendet, indem Retrohunts ausgeführt werden. Erkennungen werden angezeigt, nachdem der historische Scan abgeschlossen ist.
  • Erneute Anreicherung von UDM-Ereignissen: Zuvor verarbeitete Zeitblöcke werden neu bewertet, wenn Verlaufsereignissen neuer Kontext oder aktualisierte Entitätsdaten hinzugefügt werden.

Faktoren, die zu Verzögerungen bei der Regelerkennung beitragen

Wie schnell Erkennungen angezeigt werden, hängt von der Komplexität der Regeln, 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 geringste Erkennungslatenz. Mit diesen Regeln werden einzelne Ereignisse ausgewertet, ohne dass externe Datasets, Datentabellen oder Abgleichsfenster für mehrere Ereignisse zusammengeführt werden.

Komplexe Einzelereignisregeln

Diese Regeln werten einzelne Ereignisse aus, berücksichtigen aber zusätzliche Datenabhängigkeiten:

  • Zeitfensterbasierte Regeln für einzelne Ereignisse: Regeln für einzelne Ereignisse, die einen match-Abschnitt enthalten (z. B. um zu prüfen, ob ein einzelnes Ereignis innerhalb eines Zeitfensters eine Bedingung erfüllt). Diese Regeln werden nahezu in Echtzeit in der kontinuierlichen Streaming-Engine ausgewertet, während Daten aufgenommen werden.
  • Einzelereignisregeln mit Referenz: Einzelereignisregeln, die Ereignisattribute mit Referenzlisten oder Datentabellen vergleichen.

Regeln für mehrere Ereignisse

Regeln für mehrere Ereignisse korrelieren zwei oder mehr UDM-Ereignisbedingungen über ein bestimmtes Abgleichsfenster und werden in geplanten Batchintervallen ausgeführt.

  • Standardregeln für mehrere Ereignisse: Aggregieren Sie mehrere Ereignisse über Zeitfenster hinweg und führen Sie sie in Intervallen von 10 Minuten oder 1 Stunde aus (oder match_window / 10 für Zeitfenster von mehr als 48 Stunden).
  • Kontextsensitive Regeln: Korrelieren Sie Ereignisdaten mit UDM-Entitätsereignissen (z. B. user_context oder asset_context) mithilfe von kontextsensitiven Analysen. Da kontextsensitive Regeln auf mehreren Datenfeeds basieren, sind sie empfindlicher gegenüber dem 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 mit Zeitfenster).
  • Häufigkeit von 10 Minuten: Verfügbar für Regeln für mehrere Ereignisse mit Abgleichszeiträumen von weniger als 60 Minuten.
  • Stündlich: Standardintervall für Regeln mit mehreren Ereignissen und einem Zeitfenster für den Abgleich von höchstens 48 Stunden.
  • match_window / 10-Häufigkeit: Wird automatisch für Regeln mit mehreren Ereignissen und Übereinstimmungsfenstern von mehr als 48 Stunden zugewiesen (z. B. alle 10 Stunden bei einem Übereinstimmungsfenster von 100 Stunden oder alle 24 Stunden bei einem Fenster von 10 Tagen).

Dauer des Zeitfensters für Abgleich

Bei Regeln für mehrere Ereignisse definiert die Dauer des Übereinstimmungszeitfensters den Beobachtungszeitraum, der für die Aggregation von Ereignissen erforderlich ist. Erkennungen können erst angezeigt werden, wenn das gesamte Zeitfenster abgelaufen ist.

Verzögerung bei der Logaufnahme

Die Aufnahmeverzögerung ist die Zeit, die zwischen dem Auftreten eines Ereignisses an der Quelle und dem Empfang und Parsen des Logs durch Google SecOps vergeht.

Wenn ein Ereignis nach der ersten geplanten Auswertung für diesen Zeitblock eintrifft, wird es beim ersten Durchlauf nicht berücksichtigt. Spät eintreffende Daten werden in nachfolgenden automatisierten Hintergrundläufen (True-up-Läufen) erfasst, die etwa 4 Stunden (und optional 30 Stunden mit vollständiger Anreicherung) nach dem primären Lauf stattfinden.

  • Beispiel: Eine Regel korreliert Ereignis A (Ereigniszeit 9:03 Uhr) und Ereignis B (Ereigniszeit 9:05 Uhr) innerhalb eines 30-minütigen Zeitfensters. Wenn Ereignis A um 10:05 Uhr (eine Stunde zu spät) eintrifft, wird es bei der ersten Ausführung für den Block von 9:00 bis 9:30 Uhr nicht berücksichtigt. Das System bewertet die Blockierung während eines nachfolgenden True-up-Laufs etwa 4 Stunden nach dem primären Lauf (gegen 14:00 Uhr) neu und generiert die Erkennung etwa 5 Stunden nach dem Ereignis.

Informationen zur vorgelagerten Indexierungslatenz in API-Abfragefeeds von Drittanbietern finden Sie unter Spät eintreffende Ereignisse in Abfragefeeds.

Zeitzonenabweichungen

Google SecOps interpretiert Logzeitstempel standardmäßig als UTC. Wenn eine Logquelle keinen expliziten Zeitzonenversatz enthält, wird der Zeitstempel als UTC behandelt. Dadurch kann das Log als verspätet angezeigt werden, auch wenn es sofort empfangen wurde.

  • Beispiel: Ein Ereignis tritt um 10:00 Uhr Eastern Time (15:00 Uhr UTC) auf und geht um 15:05 Uhr UTC ohne Zeitzonenmetadaten bei Google SecOps ein. Das System interpretiert den Zeitstempel als 10:00 Uhr UTC, was zu einer wahrgenommenen Verzögerung von 5 Stunden bei der Aufnahme führt. Die Regelbewertung wird dann auf einen Hintergrund-True-Up-Lauf verschoben.

Workarounds: So beheben Sie Zeitzonenabweichungen:

  • Konfigurieren Sie die Logquelle so, dass explizite UTC-Zeitzonenabweichungen in Ereigniszeitstempeln enthalten sind.
  • Wenden Sie sich an den Support, um eine Zeitzonenüberschreibung für den jeweiligen Aufnahme-Feed festzulegen.
  • Verwenden Sie einen BindPlane-Prozessor, um die 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 Kontextverfügbarkeit können die Erkennungszeit verlängern.

Aliasing- und Anreicherungsmechanismen

Durch Aliasing und Anreicherung werden Rohindikatoren mit dem organisatorischen Kontext korreliert:

  • Aliasing: Identifiziert und verknüpft verschiedene Kennungen für dieselbe Entität über Datenquellen hinweg (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: Normalisierte UDM-Ereignisfelder werden mit dem Alias-Kontext gefüllt (z. B. wird $udm.event.principal.hostname gefüllt, wenn im Rohergebnis nur eine IP-Adresse vorhanden ist).

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

Erneute Anreicherung von UDM-Ereignissen

Das System aktualisiert historische Ereignisse kontinuierlich, wenn sich Kontextquellen weiterentwickeln:

  • Änderungen an den zugrunde liegenden Daten: Verlaufsdaten können bis zu 24 Stunden nach der Aufnahme aktualisiert werden, wenn neue Kontextdaten eingehen.
  • Systemupdates für die Anreicherung: Wenn Entitätsmetadaten, IP-Standortbestimmung oder VirusTotal Threat Intelligence aktualisiert werden, werden historische Blöcke von der Regel-Engine neu bewertet (normalerweise während geplanter True-up-Ausführungen oder Wiederaufbereitungen), um Erkennungen mit aktualisiertem Kontext zu generieren.
  • Verzögerte Kontextdaten: Wenn Kontextdaten (z. B. ein Hostname) einen Tag nach dem Ereignisprotokoll eintreffen, reichert das System das UDM-Ereignis noch einmal an. Nachfolgende True-up-Ausführungen werten den angereicherten Datensatz aus.
  • Kontextänderungen: Wenn ein Anreicherungsupdate ein Ereignisattribut ändert (z. B. eine IP-Geolokalisierung von USA in Canada), lösen Regeln, die mit dem aktualisierten Wert übereinstimmen, bei nachfolgenden Neubewertungen Erkennungen aus.

Verarbeitung des Entitätskontextgraphen (ECG)

Der Entity Context Graph (ECG) korreliert Kompromittierungsindikatoren (IOCs) und Asset-Graph-Daten des Unternehmens. Da die EKG-Pipeline auf Batchverarbeitung basiert (was je nach Datenvolumen 30 Stunden oder bis zu mehrere Tage dauern kann), werden bei Regeln, die auf graph.entity-Felder verweisen, erst dann Erkennungen generiert, wenn die Diagrammbeziehungen vollständig berechnet wurden.

Verlauf der Regelausführungen und RetroHunts

Wenn Sie eine Regel auf Verlaufsdaten anwenden, werden erst dann Erkennungen generiert, wenn der Retrohunt-Scan für den ausgewählten Zeitraum abgeschlossen ist.

  • Workflow für die rückwirkende Anreicherung:
    1. Um 13:00 Uhr geht ein Ereignis mit ip_address = 10.0.0.5 (Hostname unbekannt) ein.
    2. Um 14:30 Uhr geht ein DHCP-Log ein, das 10.0.0.5 mit workstation-123 verknüpft.
    3. Die Aliasing-Pipeline aktualisiert das historische Ereignis um 13:00 Uhr mit principal.hostname = workstation-123.
    4. Bei nachfolgenden Regelwiederholungen wird der angereicherte Hostname ausgewertet und es werden Erkennungen angezeigt, die beim ersten Durchlauf 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 erzeugen.

Regeln für nicht vorhandene Elemente

Um falsch-positive Ergebnisse zu vermeiden, wird ein Puffer von mindestens einer Stunde eingeführt, bevor Regeln ausgewertet werden, die auf Nichtvorhandensein prüfen (z. B. !$e oder #e=0). So wird sichergestellt, dass alle zugehörigen Logs Zeit haben, anzukommen.

Einschränkungen bei der Datenverarbeitung und beim True-up

Beachten Sie bei der Bewertung der Erkennungslatenz die folgenden Systemverhaltensweisen:

  • Anreicherung: Durch die Kontextanreicherung können historische UDM-Ereignisse bis zu 24 Stunden nach der ersten Aufnahme aktualisiert werden.
  • True-up-Zyklen: Regeln mit mehreren Ereignissen werden etwa 4 Stunden (und optional 30 Stunden) nach der primären Ausführung automatisch noch einmal ausgeführt, um später eingehende Daten zu erfassen. Weitere Informationen finden Sie unter Regelwiederholungen und MTTD.
  • Erkennungslimits: Informationen zu Plattformkapazität und Drosselungsgrenzen finden Sie unter Erkennungslimits.

Verzögerungen bei der Regelerkennung beheben

Um herauszufinden, warum eine Regel eine verzögerte Erkennung generiert hat, prüfen Sie die folgenden Heuristiken und Pipelinephasen in der Google SecOps-Konsole:

  • Regelmetadaten und Zeitplan prüfen: Prüfen Sie im Regeldashboard die Spalten Regelname, Regeltyp und Regelzeitplan, um die Ausführungs-Engine der Regel und die Häufigkeit der Baseline-Bewertung zu ermitteln.
  • Ereigniszeit mit Aufnahmezeit vergleichen: Suchen Sie die Erkennung auf dem Tab Erkennungen und vergleichen Sie den Ereigniszeitstempel mit dem Aufnahmezeitstempel. Wenn die Differenz zwischen der Ereigniszeit und der Aufnahmezeit mehr als 30 Minuten beträgt, wurde die Latenz durch Verzögerungen bei der Protokollbereitstellung an der Quelle oder während der Erfassung verursacht. Erkennungen, die aus Ereignisdaten generiert wurden, die mehr als 30 Minuten zu spät eingegangen sind, automatisierte True-up-Ausführungen, Pipelines zur erneuten Verarbeitung oder Retrohunts werden in der Spalte Erkennungstyp mit dem Symbol gekennzeichnet.
  • Abhängigkeiten von Kontextquellen prüfen: Prüfen Sie, ob die Regel auf principal-Anreicherung, UDM-Aliasing oder graph.entity-Felder verweist. Kontextpipelines werden asynchron verarbeitet und können bei nachfolgenden True-up-Ausführungen Erkennungen liefern.
  • Kompatibilität von Häufigkeit und Abgleichsfenster prüfen: Die konfigurierte Ausführungshäufigkeit muss mit der Größe des Abgleichsfensters übereinstimmen. Eine Regel mit einem Abgleichsfenster von 15 Minuten muss beispielsweise für 10 Minuten oder 1 Stunde geplant werden.
  • Auf Unterbrechungen des Datenfeeds prüfen: Suchen Sie in den Aufnahme-Logs und Dashboards für die Feedverwaltung nach Verzögerungen bei der Aufnahme oder vorübergehenden Ausfällen 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 Fensterregeln).
    • Konfigurieren Sie einen 10-minütigen Zeitplan für Regeln für mehrere Ereignisse mit Übereinstimmungsfenstern von weniger als 60 Minuten.
    • Verwenden Sie 1 Stunde für Regeln mit Abgleichsfenstern zwischen 1 und 48 Stunden, bei denen eine schnelle Benachrichtigung erforderlich ist.
  • Zeitfenster für den Abgleich anpassen: Legen Sie die Zeitfenster für den Abgleich auf die Mindestdauer fest, die erforderlich ist, um das korrelierte Bedrohungsverhalten zu erfassen.
  • Engpässe bei der Logbereitstellung beseitigen: Sorgen Sie dafür, dass Weiterleitungen und Collectors Ereignisdaten sofort senden, damit Logs nicht das ursprüngliche Ausführungsfenster verpassen.
  • Zeitzonenkonfigurationen validieren: Achten Sie darauf, dass Logquellen explizite UTC-Abweichungen angeben, um wahrgenommene Aufnahmelatenzen von mehr als 5 Stunden zu vermeiden.
  • Audit-Kontext und Bedingungen für Nichtvorhandensein: Verwenden Sie kontextangereicherte Felder und Bedingungen für Nichtvorhandensein (!$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? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten