Verzögerungen bei der Regelerkennung

Unterstützt in:

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

Übersicht über Erkennungsregeln

Mit Erkennungsregeln werden normalisierte Rohlogs untersucht – sowohl reguläre als auch Entity-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 unerwartete 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 auf strukturelle Faktoren zurückzuführen sind, z. B. den Aufnahmeprozess, den Regeltyp, die Ausführungshäufigkeit, die Methode zur Generierung von Erkennungen, die Dauer des Abgleichszeitraums und die bekannten Systemlimits. Sie können erwartete Verzögerungen minimieren, indem Sie die Konfigurationen von Erkennungsregeln und Planungsparameter optimieren.
  • Unvorhergesehene Verzögerungen: Verzögerungen, die durch externe oder dynamische Pipelinebedingungen verursacht werden, einschließlich Engpässen bei der Protokollbereitstellung aus Datenquellen, vorübergehender Verarbeitungslatenz in Google SecOps-Diensten, verzögerter Kontextverfügbarkeit und UDM-Re-Enrichment-Zyklen.

Methoden zum Generieren von Erkennungen

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

  • Streaming-Engine: Eine Hochgeschwindigkeitspipeline, die Standard- und Fensterregeln für Einzelereignisse kontinuierlich in nahezu Echtzeit (in der Regel innerhalb von 5 Minuten nach der Aufnahme) auswertet. 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: Dazu gehören Einzelereignisregeln, mit denen Referenzlisten oder Datentabellen abgefragt werden.
    • Regeln für mehrere Ereignisse: Daten werden in Batchblöcken der Ereigniszeit (z. B. 10-Minuten- oder 1-Stunden-Intervallen oder match_window / 10 für Zeiträume von mehr als 48 Stunden) basierend auf konfigurierten Zeitplänen abgefragt.
  • Regeln werden für Verlaufsdaten ausgeführt: Regeln werden durch Retrohunts rückwirkend anhand von Verlaufslogs ausgewertet. Erkennungen werden angezeigt, nachdem der bisherige Scan abgeschlossen ist.
  • Erneute Anreicherung von UDM-Ereignissen: Bereits verarbeitete Zeitblöcke werden neu ausgewertet, wenn historischen Ereignissen neuer Kontext oder aktualisierte Entitätsdaten hinzugefügt werden.

Faktoren, die zu Verzögerungen bei der Regelerkennung führen

Wie schnell Erkennungen angezeigt werden, hängt von der Komplexität der Regel, den Planungsintervallen, der Datenaufnahme-Latenz und den Pipelines zur Kontextanreicherung ab.

Regeltypen und Komplexität

Erkennungsregeln fallen in mehrere Kategorien mit unterschiedlichen Latenzprofilen:

Regeln für einzelne Ereignisse

Einzelereignisregeln werden nahezu in Echtzeit in der Continuous Streaming Engine ausgeführt und bieten die niedrigste Erkennungslatenz. Mit diesen Regeln werden einzelne Ereignisse ausgewertet, ohne dass externe Datasets, Datentabellen oder Zeiträume für den Abgleich mehrerer Ereignisse einbezogen werden.

Komplexe Einzelereignisregeln

Bei diesen Regeln werden einzelne Ereignisse ausgewertet, es werden jedoch zusätzliche Datenabhängigkeiten berücksichtigt:

  • Regeln für einzelne Ereignisse mit Zeitfenster: Regeln für einzelne Ereignisse, 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.
  • Einzelereignisregeln mit Referenz: Einzelereignisregeln, mit denen Ereignisattribute mit Referenzlisten oder Datentabellen verglichen werden.

Regeln für mehrere Ereignisse

Bei Regeln für mehrere Ereignisse werden zwei oder mehr UDM-Ereignisbedingungen über ein angegebenes Abgleichszeitfenster hinweg korreliert und in geplanten Batchintervallen ausgeführt.

  • Standardregeln für mehrere Ereignisse: Hier werden mehrere Ereignisse über Zeiträume hinweg zusammengefasst und in Intervallen von 10 Minuten oder 1 Stunde ausgeführt (oder match_window / 10 für Zeiträume von mehr als 48 Stunden).
  • Kontextbezogene Regeln: Korrelieren Sie Ereignisdaten mit UDM-Entitätsereignissen (z. B. user_context oder asset_context) mithilfe von kontextbezogenen Analysen. Da kontextbezogene Regeln auf mehreren Datenfeeds basieren, reagieren sie empfindlicher auf den Zeitpunkt der Aufnahme. Weitere Informationen finden Sie unter Kontextbezogene Daten in Regeln verwenden.

Häufigkeit der Regelausführung

Die konfigurierte Ausführungshäufigkeit bestimmt, wie oft die Abfrage-Engine Zeitblöcke für Ereignisse 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ündliche Häufigkeit: Standardintervall für Regeln mit mehreren Ereignissen und Übereinstimmungszeiträumen 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 für ein 100-Stunden-Übereinstimmungsfenster oder alle 24 Stunden für ein 10-Tage-Fenster).

Dauer des Zeitfensters für den Abgleich

Bei Regeln für mehrere Ereignisse wird mit der Dauer des Abgleichszeitfensters der Beobachtungszeitraum definiert, der zum Aggregieren von Ereignissen erforderlich ist. Erkennungen können erst angezeigt werden, wenn der gesamte Zeitraum abgelaufen ist.

Verzögerung bei der Log-Aufnahme

Die Erfassungsverzögerung ist die Zeit, die zwischen dem Eintreten 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 Zeitraum eintrifft, wird es bei der ersten Ausführung nicht berücksichtigt. Das System erfasst verspätet eingehende Daten in nachfolgenden automatischen Hintergrundläufen (Abstimmungsläufen), die etwa 4 Stunden (und optional 30 Stunden mit Vervollständigung der 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-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 einem nachfolgenden Abgleichslauf etwa vier Stunden nach dem primären Lauf (gegen 14:00 Uhr) neu aus. Die Erkennung erfolgt also etwa fünf Stunden nach dem Ereignis.

Abweichungen bei der Zeitzone

In Google SecOps werden Log-Zeitstempel standardmäßig als UTC interpretiert. Wenn in einer Logquelle kein expliziter Zeitzonenversatz angegeben ist, behandelt das System den Zeitstempel als UTC. Das kann dazu führen, dass das Log als verspätet eingehend angezeigt wird, auch wenn es sofort empfangen wurde.

  • Beispiel: Ein Ereignis tritt um 10:00 Uhr Eastern Time (15:00 Uhr UTC) auf und wird um 15:05 Uhr UTC ohne Zeitzonenmetadaten bei Google SecOps empfangen. Das System interpretiert den Zeitstempel als 10:00 Uhr UTC. Dadurch entsteht eine scheinbare Verzögerung von 5 Stunden bei der Aufnahme, die die Regelauswertung auf einen Hintergrundabgleich verschiebt.

Problemumgehungen: So beheben Sie Abweichungen bei der Zeitzone:

  • Konfigurieren Sie die Protokollquelle so, dass explizite UTC-Zeitzonenabweichungen in Ereigniszeitstempel aufgenommen werden.
  • Wenden Sie sich an den Support, um eine Zeitzonenüberschreibung für den jeweiligen Ingestionsfeed festzulegen.
  • Verwenden Sie einen BindPlane-Prozessor, um Zeitstempel im Log-Body vor der Aufnahme in UTC zu normalisieren. Weitere Informationen finden Sie unter Zeitstempel im Log-Body 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 Kontext können die Erkennungszeit verlängern.

Aliasing- und Anreicherungsmechanismen

Durch Aliasing und Anreicherung werden Rohindikatoren mit dem Organisationskontext in Beziehung gesetzt:

  • Aliasing: Hier werden verschiedene Kennungen für dieselbe Einheit in verschiedenen Datenquellen identifiziert und verknüpft. So kann beispielsweise eine IP-Adresse aus DHCP-Protokollen einer MAC-Adresse und einem Hostnamen wie alex-macbook zugeordnet werden oder eine Nutzer-ID einem Mitarbeitertitel.
  • Anreicherung: Normalisierte UDM-Ereignisfelder werden mit dem Alias-Kontext gefüllt, z. B. $udm.event.principal.hostname, wenn im Rohereignis nur eine IP-Adresse vorhanden ist.

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

UDM-Ereignisse neu anreichern

Das System aktualisiert Verlaufsereignisse kontinuierlich, wenn sich Kontextquellen weiterentwickeln:

  • Änderungen an zugrunde liegenden Daten: Verlaufsereignisse können bis zu 24 Stunden nach der Aufnahme aktualisiert werden, wenn neue Kontextdaten eingehen.
  • Aktualisierungen des Anreicherungssystems: Wenn Entitätsmetadaten, IP-Geolokalisierung oder VirusTotal-Threat Intelligence aktualisiert werden, wertet die Regel-Engine frühere Blöcke neu aus (in der Regel bei geplanten Abgleichsläufen oder der Neuverarbeitung), um Erkennungen mit aktualisiertem Kontext zu generieren.
  • Verzögerte Kontextdaten: Wenn Kontextdaten (z. B. ein Hostname) einen Tag nach dem Ereignisprotokoll eingehen, reichert das System das UDM-Ereignis noch einmal an und bei nachfolgenden Abgleichsvorgängen wird der angereicherte Datensatz ausgewertet.
  • Kontextänderungen: Wenn durch eine Aktualisierung der Anreicherung ein Ereignisattribut geändert wird (z. B. wenn die IP-Geolokalisierung von USA auf Canada aktualisiert wird), lösen Regeln, die dem aktualisierten Wert entsprechen, bei nachfolgenden Neubewertungen Erkennungen aus.

Verarbeitung von Entitätskontextdiagrammen (Entity Context Graph, ECG)

Im Entity Context Graph (ECG) werden Daten zu Indicators of Compromise (IOCs) und zum Enterprise Asset Graph in Beziehung gesetzt. Da die EKG-Pipeline auf der Batchverarbeitung basiert, die je nach Datenvolumen 30 Stunden oder bis zu mehreren Tagen dauern kann, werden durch Regeln, die auf graph.entity-Felder verweisen, erst dann Erkennungen generiert, wenn die Diagrammbeziehungen vollständig berechnet wurden.

Bisherige Regelausführungen und RetroHunts

Wenn Sie eine Regel für Verlaufsdaten ausführen, werden Erkennungen erst 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 ein (Hostname unbekannt).
    2. Um 14:30 Uhr geht ein DHCP-Log ein, in dem 10.0.0.5 mit workstation-123 verknüpft wird.
    3. In der Alias-Pipeline wird das historische Ereignis um 13:00 Uhr mit principal.hostname = workstation-123 aktualisiert.
    4. Bei nachfolgenden Regelwiederholungen wird der angereicherte Hostname ausgewertet und es werden Erkennungen angezeigt, die beim ersten Durchlauf nicht ausgelöst wurden.

Referenzlisten

Regeln, mit denen Referenzlisten abgefragt werden, 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 vorhandene Elemente

Um falsch-positive Ergebnisse zu vermeiden, führt das System eine Pufferzeit von mindestens einer Stunde ein, bevor Regeln ausgewertet werden, mit denen Bedingungen für das Nichtvorhandensein (z. B. !$e oder #e=0) geprüft werden. So wird sichergestellt, dass alle zugehörigen Logs rechtzeitig eintreffen.

Einschränkungen bei der Datenverarbeitung und dem Abgleich

Beachten Sie bei der Bewertung der Erkennungslatenz die folgenden Systemverhaltensweisen:

  • Anreicherung: Die Kontextanreicherung kann historische UDM-Ereignisse bis zu 24 Stunden nach der ersten Aufnahme aktualisieren.
  • Abstimmungszyklen: Regeln mit mehreren Ereignissen werden etwa 4 Stunden (und optional 30 Stunden) nach dem primären Lauf automatisch noch einmal ausgeführt, um spät 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 Erkennung von Regeln beheben

Wenn Sie herausfinden möchten, warum eine Regel eine verzögerte Erkennung generiert hat, sehen Sie sich die folgenden Heuristiken und Pipelinephasen in der Google SecOps Console an:

  • Regelmetadaten und ‑zeitplan prüfen: Sehen Sie sich im Regeldashboard die Spalten Regelname, Regeltyp und Regelzeitplan an, um die Ausführungs-Engine und die Häufigkeit der Baseline-Bewertung der Regel zu ermitteln.
  • Ereigniszeit mit der Aufnahmezeit vergleichen: Suchen Sie auf dem Tab Erkennungen nach der Erkennung und vergleichen Sie den Ereigniszeitstempel mit dem Aufnahmezeitstempel. Wenn die Differenz zwischen der Ereigniszeit und der Aufnahmezeit 30 Minuten überschreitet, wurde die Latenz durch Verzögerungen bei der Protokollübermittlung an der Quelle oder während der Erfassung verursacht. Bei Erkennungen, die aus Ereignisdaten generiert werden, die mehr als 30 Minuten zu spät eintreffen, bei automatisierten Abgleichsvorgängen, Pipelines für die Neuverarbeitung oder Retrohunts wird in der Spalte Erkennungstyp das Symbol  angezeigt.
  • Abhängigkeiten der Kontextquelle prüfen: Prüfen Sie, ob in der Regel auf die principal-Anreicherung, UDM-Aliasing oder graph.entity-Felder verwiesen wird. Kontext-Pipelines werden asynchron verarbeitet und können bei nachfolgenden Abgleichsläufen Erkennungen liefern.
  • Häufigkeit und Kompatibilität des Abgleichszeitraums prüfen: Prüfen Sie, ob die konfigurierte Ausführungshäufigkeit mit der Größe des Abgleichszeitraums übereinstimmt. Eine Regel mit einem 15-minütigen Abgleichszeitraum sollte beispielsweise für 10 Minuten oder 1 Stunde geplant werden.
  • Nach Unterbrechungen des Datenfeeds suchen: Prüfen Sie die Ingestion-Logs und Feedverwaltungs-Dashboards auf Ingestion-Verzögerungen oder vorübergehende Quellausfälle.

Tipps zur Verkürzung von Erkennungsverzögerungen

Um Erkennungsverzögerungen in Ihrer Umgebung zu minimieren, wenden Sie die folgenden Optimierungstechniken an:

  • Häufigkeit der Regelausführung optimieren:
    • Verwenden Sie Nahezu in Echtzeit für Einzelereignisregeln (Standard und mit Zeitfenster).
    • Konfigurieren Sie einen 10-Minuten-Zeitplan für Regeln für mehrere Ereignisse mit Abgleichszeiträumen von weniger als 60 Minuten.
    • Verwenden Sie 1 Stunde für Regeln mit Abgleichszeiträumen zwischen 1 und 48 Stunden, bei denen eine schnelle Benachrichtigung erforderlich ist.
  • Zeitfenster für den Abgleich anpassen: Legen Sie Zeitfenster für den Abgleich auf die Mindestdauer fest, die erforderlich ist, um das korrelierte Bedrohungsverhalten zu erfassen.
  • Engpässe bei der Log-Übermittlung beseitigen: Sorgen Sie dafür, dass Forwarder und Collectors Ereignisdaten sofort senden, damit Logs nicht das ursprüngliche Ausführungsfenster verpassen.
  • Zeitzonenkonfigurationen validieren: Log-Quellen müssen explizite UTC-Offsets enthalten, um wahrgenommene Verzögerungen bei der Aufnahme von mehr als 5 Stunden zu vermeiden.
  • Prüfkontext und Bedingungen für das Nichtvorhandensein: Verwenden Sie kontextbezogene Felder und Bedingungen für das Nichtvorhandensein (!$e) nur, wenn dies für die Erkennungslogik erforderlich ist, da dadurch absichtliche Pufferzeiten eingeführt werden.

Nächste Schritte

Weitere Informationen zu verwandten Planungskonzepten und Konfigurationsabläufen finden Sie in den folgenden Dokumenten:

  • Planung von Regelausführungen: Hier erfahren Sie, wie Google SecOps Regelkonfigurationen kontinuierlichen Streaming- und geplanten Batchabfrage-Engines zuordnet.
  • Benutzerdefinierte Zeitpläne für Regeln konfigurieren: Sie können die Ausführungshäufigkeit, Abrechnungsverzögerungen und die Vollständigkeit der True-up-Anreicherung für Regeln für mehrere Ereignisse anpassen.
  • Regelwiederholungen und MTTD: Hier erfahren Sie, wie bei automatisierten Abgleichsvorgängen mit verspätet eingehenden Daten und Kontextaktualisierungen umgegangen wird und wie sich das auf die Messwerte für die durchschnittliche Zeit bis zur Erkennung (Mean Time to Detect, MTTD) auswirkt.
  • Regeln mit dem Regeleditor verwalten: Erstellen, bearbeiten und verwalten Sie benutzerdefinierte Erkennungsregeln in Google SecOps.

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