Verzögerungen bei der Erkennung von Regeln

Unterstützt in:

In diesem Dokument werden Verzögerungen bei der Regelerkennung in Google Security Operations erläutert. Außerdem werden die Faktoren, die dazu beitragen, und Ansätze zur Fehlerbehebung beschrieben und Techniken vorgeschlagen, mit denen sich Verzögerungen nach Möglichkeit reduzieren lassen.

Erkennungsregeln

Erkennungsregeln untersuchen sowohl reguläre als auch Entitätsereignisse des Universal Data Model (UDM), die normalisierte Rohlogs sind, um Erkennungen gemäß den Spezifikationen der Regel zu generieren. UDM-Ereignisse für Entitäten enthalten in der Regel Kontextinformationen wie Nutzer- oder Asset-Details. Regeln generieren auch Erkennungen basierend auf zuvor generierten Erkennungen.

Erwartete und unvorhergesehene Verzögerungen

Die Erkennungszeiten können sich aufgrund von Verzögerungen bei der Verarbeitung verlängern. Einige Regeln werden in Echtzeit ausgelöst, andere können mehrere Minuten oder Stunden in Anspruch nehmen. Faktoren wie Regeltyp, Ausführungshäufigkeit und Methode zur Erkennungserstellung wirken sich auf diese Verzögerungen aus. In diesem Dokument werden diese und andere Verzögerungsfaktoren untersucht.

Wir kategorisieren Verzögerungen als erwartet oder unvorhergesehen.

  • Erwartete Verzögerungen: Diese Verzögerungen ergeben sich aus dem Aufnahmeprozess und den Konfigurationsoptionen, die Sie beim Einrichten der Erkennungsregel auswählen. Ein Faktor ist beispielsweise die Zeit, die zum Erstellen einer Erkennung benötigt wird. Diese Verzögerungen hängen von bekannten strukturellen Faktoren ab, z. B. vom Regeltyp, der Ausführungshäufigkeit, der Methode zur Generierung von Erkennungen, bekannten Einschränkungen und anderen vorhersehbaren Faktoren.
     Sie können diese Verzögerungen minimieren, indem Sie die Konfigurationen der Erkennungsregeln ändern oder optimieren. Das wird in diesem Dokument beschrieben.
    Weitere Informationen finden Sie unter Tipps zur Verkürzung von Verzögerungen.

  • Unvorhergesehene Verzögerungen: Dies sind regel- oder ereignisspezifische Verzögerungen, die durch viele Faktoren verursacht werden, darunter Verzögerungen beim Eintreffen von Ereignisdaten bei Google SecOps, vorübergehende Verlangsamungen bei der Verarbeitung von Pipelines in Google SecOps-Diensten, erneute Anreicherung und andere Verzögerungen bei der Datenverarbeitung.

Verzögerungen bei der Regelerkennung analysieren

Wenn Sie Verzögerungen bei der Erkennung von Regeln analysieren möchten, suchen Sie nach Informationen zur Regel und den zugehörigen Faktoren:

  1. Rufen Sie in der Google SecOps Console Detection > Rules and detections auf.

    Im Regel-Dashboard werden Regelmetadaten wie Rule name, Rule type und Run frequency angezeigt.

    Weitere Informationen finden Sie unter Regeln im Dashboard „Regeln“ ansehen.

  2. Klicken Sie im Regel-Dashboard auf einen Regelnamen, um den Erkennungsverlauf und andere Details für eine bestimmte Regel aufzurufen.

  3. Bei der Ausführung einer bestimmten Regel gibt es mehrere Faktoren, die sich auf die Erkennungslatenz auswirken können. Dimensionen wie Rule type, Run frequency, Event type, Event time und Ingested time sind gute Heuristiken, um zu verstehen, warum eine bestimmte Erkennung verzögert wurde.

Ein -Symbol in der Spalte Erkennungstyp kennzeichnet Erkennungen, die aus Ereignisdaten generiert wurden, die um mehr als 30 Minuten verzögert sind, aus der erneuten Verarbeitung von Regeln oder aus Retrohunts. Dieses Symbol wird auch auf der Seite Benachrichtigungen in Google SecOps angezeigt.

  1. Machen Sie sich mit den folgenden Themen vertraut, um zu verstehen, wie sich diese Faktoren auf Verzögerungen bei der Regelerkennung auswirken:

Methoden zum Generieren von Erkennungen

Hier erfahren Sie, wie das System Regelerkennungen erstellt und wie sich die Methode zur Generierung von Erkennungen auf Erkennungsverzögerungen auswirkt.

Das System generiert Regelerkennungen auf folgende Weise:

  1. Streaming Engine

    Die Streaming Engine ist eine spezielle Streamingpipeline, die mit geringer Latenz (in der Regel weniger als fünf Minuten Verzögerung) arbeitet. Es werden standardmäßige Single-Event-Regeln ausgewertet, die keinen Abgleichabschnitt, keine externen Datasets (z. B. Referenzlisten oder Datentabellen) und keine UEBA-Funktionen enthalten.

  2. Abfrage-Engine

    Die Query-Engine wertet komplexe Einzelereignis- und Mehrfachereignisregeln aus:

    • Komplexe Einzelereignisregeln:

      • Regeln für einzelne Ereignisse mit Referenzlisten oder Datentabellen: Regeln, mit denen ein einzelnes Ereignis ausgewertet und in Referenzlisten oder Datentabellen nachgeschlagen wird.
      • Regeln für einzelne Ereignisse mit Zeitfenster: Regeln, mit denen ein einzelnes Ereignis mit einem Abgleichszeitfenster und einer einfachen Existenzbedingung ausgewertet wird (z. B. $e, #e > 0 oder #e >= 1).
      • Komplexe Einzelereignisregeln verwenden zwar die Abfrage-Engine anstelle der Streaming-Engine, werden aber mit einem hochfrequenten Nahezu in Echtzeit-Zeitplan ausgeführt, sobald neue Daten aufgenommen werden. Dadurch wird eine niedrigere Latenz erreicht, die der typischen Latenz der Streaming-Engine entspricht. Spät eintreffende und angereicherte Daten werden während der Standardabfrageausführung neu ausgewertet, ohne dass Abgleichsintervalle für mehrere Ereignisse erforderlich sind.

    • Regeln für mehrere Ereignisse: Bei diesen Regeln werden Daten über Blöcke von Ereigniszeit (10 Minuten, stündlich, täglich) gemäß einem von Ihnen festgelegten Zeitplan abgefragt. Die Zeitpunkte für die erneute Abfrage von Daten, die verspätet eintreffen, hängen vom Zeitplantyp ab.

      • Beim Standardschema werden Abfragen etwa 5 und 24 Stunden nach der Ereigniszeit wiederholt.
      • Bei anpassbaren Zeitplänen sind unterschiedliche Abstimmungszeitpunkte möglich. Weitere Informationen finden Sie unter Regelwiederholungen und MTTD.

  3. Regeln werden für Verlaufsdaten ausgeführt

    Weitere Informationen finden Sie unter Retro-Suchen.

  4. UDM-Ereignisse noch einmal anreichern

    Weitere Informationen finden Sie unter UDM-Ereignisse noch einmal anreichern und Verarbeitung von Kontextgraphen für Entitäten.

Bekannte Einschränkungen

Hier sind einige Standardeinschränkungen, die zu Verzögerungen bei der Regelerkennung führen können:

  • Verzögerungen bei der Anreicherung können manchmal länger dauern als erwartet. Durch die erneute Verarbeitung der Anreicherung werden Daten bei späteren Regelausführungen neu ausgewertet. Das System führt mehrere Anreicherungen durch. UDM-Ereignisse können bis zu 24 Stunden nach der Aufnahme des Ereignisses aktualisiert werden.

  • Regeln für mehrere Ereignisse:

    • Bei Regeln für mehrere Ereignisse mit dem Standardzeitplan werden die Regeln etwa 5 und 24 Stunden nach der Ereigniszeit noch einmal ausgeführt.

    • Für Regeln für mehrere Ereignisse mit anpassbaren Zeitplänen gelten unterschiedliche Abgleichszeiten.

    Diese Regelwiederholungen werden ausgelöst, um verspätet eingehende Daten zu verarbeiten.

  • Kontextsensitive Regeln basieren auf Anreicherungsquellen wie Asset- und Identitäts-Aliasing oder dem Objektkontextdiagramm. Da diese Regeln auf mehreren Ereignisquellen basieren, sind sie anfälliger für hohe Latenz.

  • Das System führt Regeln zwischen 5 und 8 Stunden und noch einmal zwischen 24 und 48 Stunden nach der ersten Ausführung der Regel aus. Diese beiden separaten Regelwiederholungen werden basierend auf den Ausführungszeiten der Pipeline für die Neuverarbeitung ausgelöst.

  • Weitere Erkennungslimits finden Sie unter Erkennungslimits.

Verzögerungen bei der Erkennung von Regeln beheben

Verzögerungen bei der Regelerkennung durch Ausschlussverfahren beheben

So können Sie Verzögerungen bei der Erkennung von Regeln untersuchen und beheben:

  1. Auf offensichtliche Verzögerungen prüfen:

    Feststellen, ob eine Verzögerung bei der Aufnahme vorliegt:

    1. Rufen Sie in der Google SecOps Console Detection > Rules and detections auf.

    2. Suchen Sie im Regeldashboard nach der zu analysierenden Regel.

    3. Vergleiche die Event time mit der Ingested time.

      Wenn beispielsweise bei der Erkennung einer bestimmten Regel eine große Lücke zwischen Event time und Ingested time besteht, können Sie die Verzögerung bei der Erkennung wahrscheinlich auf eine erwartete Verzögerung zurückführen. Ein -Symbol in der Spalte Erkennungstyp wird angewendet, wenn die Ingestion time mehr als 30 Minuten nach der Event time liegt.

  2. Erfassungszeitpunkt der Kontextquelle prüfen:

    Prüfen Sie den Erfassungszeitpunkt der Kontextquelle.

    Kontextsensitive Regeln können die folgenden Kontextquellen enthalten. Prüfen Sie die Abholzeiten:

    • Felder, die aus der UDM-Anreicherung abgeleitet werden.
    • Ereignisse, die das Feld principal enthalten.

    • Regeln, die auf ein graph.entity-Feld verweisen.

      Regeln, die mit der graph.entity-Syntax auf den Entity Context Graph (ECG) verweisen, können zu einer besonders hohen Latenz führen. Beispiel: Die EKG-Pipeline generiert Kontextdaten. Dieser Vorgang kann je nach Datentyp 30 Stunden oder in einigen Fällen bis zu 8 Tage dauern.

    Weitere Informationen finden Sie unter Verzögerungen bei der Datenverarbeitung.

  3. Ausführungshäufigkeit und Abgleichszeitraum der Regel prüfen:

    • Häufigkeit:Prüfen Sie, wie oft die Regel ausgeführt wird. Bei einer Regel, die seltener ausgeführt wird, sind die Erkennungsverzögerungen natürlich länger.
    • Zeitfenster für den Abgleich:Wenn eine Regel ein Zeitfenster für den Abgleich hat, entspricht die Mindestverzögerung der Dauer dieses Fensters.
    • Beziehung zwischen Häufigkeit und Abgleichszeitraum:Die Häufigkeit der Ausführung muss mit dem Abgleichszeitraum kompatibel sein. Für Abgleichszeiträume von weniger als 60 Minuten wird beispielsweise eine Ausführungshäufigkeit von 10 Minuten (nahezu in Echtzeit) unterstützt. Verwenden Sie für Zeitfenster für den Abgleich von 60 Minuten oder mehr (bis zu 48 Stunden) 1 Stunde. Verwenden Sie „Täglich“ für Abgleichszeiträume von mehr als 48 Stunden.

  4. Nach aktuellen Vorfällen suchen:

    Suchen Sie nach aktuellen Vorfällen, die zu Verzögerungen oder Problemen mit Datenfeeds geführt haben könnten.

Tipps zur Verkürzung von Verzögerungen

Informationen zum Aktualisieren von Konfigurationen für Erkennungsregeln finden Sie unter Regeln mit dem Regeleditor verwalten.

Mit den folgenden Techniken können Sie Verzögerungen nach Möglichkeit reduzieren:

  • Verwenden Sie für latenzempfindliche Regeln die Optionen für die häufigste Ausführung:

    • Regelhäufigkeit erhöhen:

      Um Verzögerungen zu vermeiden, konfigurieren Sie die höchstmögliche Häufigkeit basierend auf dem Regeltyp und dem Abgleichszeitraum:

      • Für alle Einzelereignisregeln: Verwenden Sie Nahezu in Echtzeit.
      • Für Regeln mit mehreren Ereignissen und Übereinstimmungsfenstern von weniger als 60 Minuten: Verwenden Sie Nahezu in Echtzeit (10 Minuten).
      • Bei Regeln mit mehreren Ereignissen und Übereinstimmungsfenstern von mindestens 60 Minuten: Verwenden Sie je nach Bedarf 1 Stunde oder Täglich.

      Weitere Informationen finden Sie unter Ausführungshäufigkeit festlegen.

    • Dauer des Abgleichszeitraums verkürzen:

      Das Verringern des Abgleichszeitraums wirkt sich nicht direkt auf die Latenz aus, kann aber die Effizienz steigern, indem die Mindestverzögerung festgelegt wird.

  • Verspätete Daten vermeiden:

    Später eingehende Daten werden bei der ursprünglichen Abfrage nicht berücksichtigt. Das System verarbeitet sie erst, wenn es den entsprechenden Zeitraum 5 bis 8 Stunden später noch einmal abfragt. Das führt zu erheblichen Verzögerungen. Die Daten zur Pünktlichkeit haben in der Regel eine Verzögerung von etwa 20 Minuten.

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

Der Regeltyp, die Ausführungshäufigkeit und die Geschwindigkeit der Aufnahme von Google SecOps sind wichtige Faktoren für Verzögerungen bei der Regelerkennung.

Die folgenden Faktoren tragen zu Verzögerungen bei der Regelerkennung bei.

Regeltypen

Regeln lassen sich in zwei Hauptkategorien einteilen:

Einzelereignisregeln

Standardmäßige Regeln für einzelne Ereignisse erkennen einzelne Ereignisse ohne externe Datenabrufe, Abgleichszeiträume oder Analysen des Nutzer- und Entitätsverhaltens (User and Entity Behavior Analytics, UEBA). Diese Regeln werden nahezu in Echtzeit mit einer dedizierten Streaming-Engine ausgeführt und erreichen die niedrigste Erkennungslatenz (in der Regel weniger als fünf Minuten).

Komplexe Einzelereignisregeln

Bei komplexen Einzelereignisregeln werden einzelne Ereignisse ausgewertet, es werden jedoch Referenzlisten, Datentabellen oder einfache Abgleichszeiträume berücksichtigt. Sie werden mit der Query Engine anstelle der Streaming Engine ausgeführt, aber mit einem Near-Realtime-Zeitplan mit niedriger Latenz ähnlich der Streaming Engine geplant:

  • Regeln für einzelne Ereignisse in Referenzliste und Datentabelle:

    Für diese Regeln für einzelne Ereignisse sind keine Abgleichszeiträume für mehrere Ereignisse erforderlich, da sie Referenzlisten oder Datentabellen abgleichen.

  • Zeitfensterbasierte Einzelereignisregeln:

    Diese Regeln für einzelne Ereignisse enthalten einen Abgleichszeitraum mit einer einfachen Bedingung für die Ereignisanzahl (z. B. $e, #e > 0 oder #e >= 1).

Regeln für mehrere Ereignisse

Regeln für mehrere Ereignisse werden nach einem Zeitplan ausgeführt. Das führt zu längeren Verzögerungen, da die Zeit zwischen den geplanten Ausführungen berücksichtigt werden muss.

  • Regeln für mehrere Ereignisse

    Bei diesen Regeln werden zwei oder mehr UDM-Ereignisbedingungen untersucht. Sie haben in der Regel ein Abgleichszeitfenster und mehrere Bedingungen.

  • Kontextsensitive Regeln

    Mit kontextsensitiven Regeln können Sie Ihren Ereignissen zusätzliche Kontextdaten zu Entitäten und Erkennung hinzufügen.

    • Diese Regeln bestehen aus mindestens zwei Datenquellen, wobei mindestens eine Bedingung ein UDM-Entität-Ereignis ist (wobei das UDM-Ereignis vom Kontexttyp ist, z. B. user_context).
    • Kontextsensitive Regeln reagieren am empfindlichsten auf verspätet eingehende Daten.
    • Kontextsensitive Regeln haben in der Regel die längsten Verzögerungen, da das System zuerst die erforderlichen Kontextdaten wie Daten im Entity Context Graph generieren muss.
    • Weitere Informationen finden Sie unter Kontextbezogene Daten in Regeln verwenden.

Weitere Informationen zum Unterschied zwischen Regeln für einzelne Ereignisse und Regeln für mehrere Ereignisse

Häufigkeit der Regelausführung

Die Häufigkeit der Regelausführung wirkt sich direkt auf die Erkennungsverzögerung aus.

  • Nahezu in Echtzeit:Regeln werden mit minimaler Latenz ausgeführt, wenn Ereignisse erfasst werden. Das gilt für:
    • Alle Einzelereignisregeln (Standard-Einzelereignisregeln, Regeln mit Referenzlisten oder Datentabellen und Fenster-Einzelereignisregeln).
    • Regeln mit mehreren Ereignissen und Zeitfenstern für den Abgleich von weniger als 60 Minuten.
  • Andere Häufigkeiten:Bei anderen Regelkonfigurationen können Sie die folgenden Häufigkeiten festlegen:
    • Die Häufigkeit von 10 Minuten gilt für Abgleichszeiträume von weniger als 60 Minuten.
    • Die Häufigkeiten „1 Stunde“ und „Täglich“ sind für Übereinstimmungszeiträume von bis zu 48 Stunden gültig.
    • Die tägliche Häufigkeit ist für alle Abgleichszeiträume mit mehr als 48 Stunden gültig.

Mögliche Problemumgehung:Wenn Sie möchten, dass Probleme schneller erkannt werden, können Sie die Ausführungshäufigkeit verkürzen. Das Verringern des Abgleichszeitraums wirkt sich nicht direkt auf die Latenz aus, kann aber die Effizienz steigern, indem die Mindestverzögerung festgelegt wird.

Zeitfenster für Abgleich

Wenn eine Regel ein Zeitfenster für den Abgleich hat, bestimmt die Dauer des Fensters die minimale Erkennungsverzögerung, da das System das gesamte Fenster abwarten muss.

Verzögerung bei der Aufnahme

Die Aufnahmeverzögerung bezieht sich auf die Zeit, die Google SecOps benötigt, um Daten nach dem Eintreten des Ereignisses aufzunehmen.

Wenn Daten zu spät eintreffen, werden sie nicht im ursprünglichen Abfragezeitraum berücksichtigt. Eine nachfolgende Abfrage zur historischen Verarbeitung erfasst sie, aber das kann zu Verzögerungen von 5 bis 8 Stunden führen.

Beispiel: Ereignis A (Ereigniszeit: 9:03 Uhr) und Ereignis B (Ereigniszeit: 9:05 Uhr) sind Teil einer Regel, die nach zwei Ereignissen innerhalb von 30 Minuten sucht. Wenn Ereignis A um 10:05 Uhr eintrifft (eine Stunde zu spät), werden die ursprünglichen Anfragen des Blocks von 9:00 bis 9:30 Uhr nicht berücksichtigt. Eine Folgeanfrage für diesen Block zwischen 14:00 und 17:00 Uhr führt dann zur Erkennung, was zu Verzögerungen von 5 bis 8 Stunden führt.

Fehlerbehebung:Prüfen Sie, ob Sie Daten an Google SecOps senden, sobald das Ereignis eintritt. Prüfen Sie bei der Überprüfung eines erkannten Problems sorgfältig die Zeitstempel für UDM-Ereignisse und die Aufnahme.

Probleme mit der Zeitzone

Die Standardzeitzone von Google SecOps SIEM ist UTC. Wenn Protokolle keine explizite Zeitzonendefinition enthalten, werden sie vom System als UTC interpretiert. Eine falsche Interpretation kann dazu führen, dass die Logs als verspätet eingehend behandelt werden, was zu Verzögerungen bei der Erkennung führt, auch wenn das System sie in Echtzeit empfängt.

Ein Log mit einer Ereigniszeit von 10:00 Uhr Eastern Time (15:00 Uhr UTC) kommt beispielsweise um 15:05 Uhr UTC an, aber es fehlt eine Zeitzone. Wenn im Log keine Zeitzone angegeben ist, interpretiert das System die Ereigniszeit als 10:00 UTC. Das System berechnet dann eine Verzögerung von 5 Stunden zwischen der interpretierten Ereigniszeit (10:00 Uhr UTC) und der tatsächlichen Aufnahmezeit (15:05 Uhr UTC). Diese berechnete Verzögerung führt zu Erkennungsverzögerungen, da bei Regeln die Verarbeitung auf Grundlage der Echtzeitaufnahme priorisiert wird.

Problemumgehungen:Wenn der Ereigniszeitstempel der Originaldaten in einer anderen Zeitzone als UTC liegt, versuchen Sie Folgendes:

  • Aktualisieren Sie die Zeitzone des Ereignisses der Originaldaten.
  • Wenn Sie die Zeitzone in der Protokollquelle nicht aktualisieren können, wenden Sie sich an den Support, um die Zeitzone zu überschreiben.
  • Alternativ können Sie einen BindPlane-Prozessor verwenden, um den Zeitstempel zu korrigieren und als UTC zu formatieren oder den entsprechenden Zeitzonenindikator hinzuzufügen. Weitere Informationen finden Sie unter Zeitstempel im Logtext mit BindPlane ändern.

Kontextbezogene Joins

Bei Regeln mit mehreren Ereignissen, die Kontextdaten wie UEBA- oder Entity Context Graph-Felder verwenden, kann es zu längeren Verzögerungen kommen. Google SecOps muss zuerst die Kontextdaten generieren.

Anreicherungssystem

Google SecOps reichert UDM-Ereignisse an, indem Kontextdaten aus anderen Quellen hinzugefügt werden. Dieser Vorgang ist normalerweise innerhalb von 30 Minuten abgeschlossen. Verzögerungen beim Hinzufügen dieser angereicherten Daten zu UDM-Ereignissen können die Erkennungszeiten verlängern.

Wenn Sie prüfen möchten, ob eine Regel ein angereichertes Feld auswertet, sehen Sie sich die Ereignisanzeige an. Wenn in der Regel ein angereichertes Feld ausgewertet wird, kann sich die Erkennung verzögern.

Weitere Informationen finden Sie unter Datenanreicherung.

Aliasing und Anreicherung

Aliasing und Datenanreicherung sind zwei Schritte im Prozess zur Datenanreicherung von Sicherheitsdaten in Google SecOps, bei dem Kontextdaten mit Ereignisdatensätzen korreliert und hinzugefügt werden. Beim Aliasing werden die Verbindungen ermittelt und bei der Anreicherung werden die UDM-Felder mit diesen verbundenen Daten gefüllt. Die Felder, die durch diesen Prozess ausgefüllt werden, werden als Aliasfelder oder angereicherte Felder bezeichnet.

  • Aliasing:Hierbei werden verschiedene Namen oder Kennungen für dieselbe Einheit identifiziert und verknüpft. Es werden zusätzliche Kontextdaten gefunden, die einen Indikator beschreiben. Durch Aliasing kann beispielsweise eine einzelne hostname (z. B. alex-macbook) mit anderen zugehörigen Indikatoren wie IP addresses und MAC addresses (aus DHCP-Logs) verknüpft werden. Durch Aliasing kann auch eine user ID (z. B. alex) mit der job title und employment status des Nutzers (aus Nutzerkontextdaten) verknüpft werden.
  • Anreicherung:Bei diesem Prozess werden die durch Aliasing erfassten Informationen verwendet, um einem UDM-Ereignis Kontext hinzuzufügen. Wenn beispielsweise ein neues Ereignis mit nur einem IP address eingeht, wird beim Anreicherungsprozess anhand der Aliasdaten die zugehörige hostname (z. B. alex-macbook) gesucht und das Feld $udm.event.principal.hostname wird ausgefüllt.

Google SecOps unterstützt Aliasing und Anreicherung für verschiedene Entitätstypen, darunter Assets (z. B. Hostnamen, IP-Adressen, MACs), Nutzer, Prozesse, Metadaten für Datei-Hashes, geografische Standorte und Cloud-Ressourcen. Weitere Informationen finden Sie unter Übersicht über UDM-Anreicherung und Aliasierung.

UDM-Ereignisse noch einmal anreichern

  • Änderungen an zugrunde liegenden Daten:Wenn sich die zugrunde liegenden Daten nach der Erfassung eines Ereignisses ändern, verarbeitet das System die Verlaufsdaten noch einmal und aktualisiert die Ereignisse bis zu 24 Stunden nach der Erfassung.

  • Aktualisierungen des Anreicherungssystems:Wenn das Anreicherungssystem Entitäts- oder Prozessmetadaten, die IP-Geolokalisierung oder VirusTotal-Indikatoren aktualisiert, wertet die Regelausführung diese Blöcke 24 bis 48 Stunden später neu aus, um diese Aktualisierungen zu erfassen.
    Ein Ereignis um 9:03 Uhr hat beispielsweise entity.asset.hostname = hostnameA, aber keine IP-Adresse. Ein DHCP-Log von 8:55 Uhr zeigt hostnameA = IP 1.2.3.4. Die Regel-Engine wird um 9:10 Uhr ausgeführt und die Regel stimmt nicht überein. In der Pipeline für die Anreicherung werden hostnameA und 1.2.3.4 für diesen Zeitraum in Beziehung gesetzt und das UDM-Ereignis wird aktualisiert. Die Regel stimmt jetzt überein und das System erstellt eine Erkennung.

  • Verzögerte Kontextdaten:Wenn Sie Kontextdaten wie eine hostname einen Tag nach dem ursprünglichen Log senden, werden die UDM-Ereignisse noch einmal angereichert. Regeln, die nach diesen neu angereicherten Daten suchen, werden dann noch einmal ausgeführt und es wird eine Erkennung erstellt.

  • Änderungen bei Anreicherungsdaten:Änderungen bei Anreicherungsdaten können dazu führen, dass eine Regel später übereinstimmt, auch wenn das anfangs nicht der Fall war.
    Ein Ereignis um 9:03 Uhr hat beispielsweise entity.ip_geo_artifact.country_or_region = USA. Die Regel-Engine wird um 9:10 Uhr ausgeführt und fragt Daten für den Zeitraum von 9:00 bis 10:00 Uhr ab. Die Regel stimmt nicht überein. Später wird die Geolocation durch die erneute Verarbeitung der Anreicherung auf Kanada aktualisiert. Wenn die Regel noch einmal ausgeführt wird, wird sie jetzt abgeglichen und das System erstellt eine Erkennung.

Verarbeitung von Entitätskontextdiagrammen

Das System generiert und fügt Logdaten Informationen zum Entity Context Graph (ECG) hinzu, um Kontext bereitzustellen, z. B. Indikatoren für Sicherheitsrisiken (Indicators of Compromise, IOCs) oder Asset-Kontextdaten. Da die EKG-Pipeline hauptsächlich auf der Batchverarbeitung basiert, werden Informationen zum Kontext von Rechtssubjekten oft erst aktualisiert, nachdem durch die Ausführung einer Regel eine Erkennung erfolgt ist.

Retro-Suchen

Wenn Sie eine Regel mit Verlaufsdaten mithilfe einer Retro-Suche ausführen, wird die Erkennung erst erstellt, wenn die Retro-Suche abgeschlossen ist. Dieser Prozess kann einige Zeit in Anspruch nehmen, was zu einer Verzögerung bei der Erkennung führt.

Beispiel für einen rückwirkenden Aktualisierungsprozess:

  1. Erstes Ereignis:Ein Ereignis mit ip_address = 10.0.0.5 wird um 13:00 Uhr empfangen. Derzeit ist die hostname unbekannt.
  2. Alias-Quelle kommt an:Um 14:30 Uhr (mehr als eine Stunde später) geht ein DHCP-Log für 13:00 Uhr ein, in dem 10.0.0.5 mit workstation-123 verknüpft wird.
  3. Rückwirkende Anreicherung:Das Aliasing-System verarbeitet diesen neuen Link. Das UDM-Ereignis von 13:00 Uhr wird rückwirkend aktualisiert und das zuvor leere Feld $udm.event.principal.hostname wird mit dem Wert workstation-123 angereichert.
  4. Erkennung:Bei nachfolgenden Regelwiederholungen wird der angereicherte Wert (workstation-123) berücksichtigt. Dadurch können Erkennungen ausgelöst werden, die zuvor nicht erkannt wurden.

Referenzlisten

Bei der Ausführung von Regeln wird immer die aktuelle Version einer Referenzliste verwendet. Wenn geplante Regeln noch einmal ausgeführt werden, kann das System basierend auf aktualisierten Inhalten der Referenzliste neue Erkennungen erstellen. Diese Erkennungen werden möglicherweise erst spät angezeigt, da sie auf Daten basieren, die vor der Aktualisierung der Referenzliste erfasst wurden.

So verkürzen Sie die Erkennungsverzögerungen:

  • Senden Sie Protokolldaten an Google SecOps, sobald das Ereignis eintritt.
  • Prüfen Sie die Prüfregeln, um zu entscheiden, ob Sie Daten verwenden möchten, die nicht vorhanden sind, oder kontextbezogene Daten.
  • Konfigurieren Sie eine geringere Ausführungshäufigkeit.

Regeln für nicht vorhandene Elemente

Das System wartet mindestens eine Stunde, bevor Regeln ausgeführt werden, mit denen auf Nichtvorhandensein geprüft wird (z. B. Regeln, die !$e oder #e=0 enthalten). So ist sichergestellt, dass genügend Zeit für den Datenempfang ist.

Verzögerungen bei der Datenverarbeitung

Das System verarbeitet möglicherweise weiterhin Daten, auch nachdem eine erste Erkennung erfolgt ist. Das kann zu neuen oder aktualisierten Erkennungen führen. Weitere Informationen finden Sie unter Wann werden Regelwiederholungen ausgelöst?.

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