Verzögerungen bei der Regelerkennung

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, um Verzögerungen nach Möglichkeit zu reduzieren.

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 unerwartete Verspätungen

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 sind auf den Aufnahmeprozess und die Konfigurationsoptionen zurückzuführen, 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 regelspezifische 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 Regeldashboard 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

Informationen dazu, 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 schnelle Pipeline, die in der Regel mit einer Verzögerung von weniger als fünf Minuten arbeitet. Es werden Einzelereignisregeln mit Abschnitt ohne Übereinstimmung und keinen externen Datasets wie Referenzlisten oder Datentabellen verarbeitet.

  2. Abfrage-Engine

    Die Query-Engine verarbeitet Regeln so:

    • Komplexe Regeln für einzelne Ereignisse:

      • Regeln für einzelne Ereignisse, die auf Referenzlisten oder Datentabellen verweisen.
      • Regeln für einzelne Ereignisse mit Zeitfenster, die ein Abgleichszeitfenster mit einer einfachen Bedingung verwenden. Beispiel: „Ein Ereignis, bei dem die Anzahl der Ereignisse > 0 ist.“ Diese Regeln werden mit einer hohen Frequenz (nahezu in Echtzeit) ausgeführt, wenn neue Daten aufgenommen und für die Verarbeitung von Regeln verfügbar gemacht werden.

    • Regeln mit mehreren Ereignissen: Bei diesen Regeln werden Daten über Blöcke von Ereigniszeit (10 Minuten, stündlich, täglich) gemäß einem von Ihnen festgelegten Zeitplan abgefragt.
      Bei einem 10-Minuten-Zeitplan werden die Blöcke mit Ereigniszeit beispielsweise nach 5 bis 8 Stunden und nach 24 bis 48 Stunden noch einmal abgefragt, je nach Zeitplan für die Upstream-Verarbeitung.

  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 neu anreichern und Verarbeitung von Kontextgraphen für Entitäten.

Bekannte Einschränkungen

Hier sind einige Standardeinschränkungen, die zu Verzögerungen bei der Erkennung von Regeln 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.
  • Bei Regeln mit mehreren Ereignissen werden häufig Kontextdaten zusammengeführt, die viele Stunden nach der Ereigniszeit des primären Ereignisses eintreffen. Eine hohe Latenz bei diesen Kontextdaten kann dazu führen, dass die Verarbeitung von erneuter Anreicherung und Regelwiederholungen interagieren, was zu einer verzögerten Erkennung führt. Google SecOps verwendet diese Funktion, um Daten zu verarbeiten, die sehr spät eintreffen. Dies führt zu einem großen Zeitraum zwischen dem Erkennungszeitraum (Ereigniszeitblock) und der Erstellungszeit der Benachrichtigung.
  • Kontextsensitive Regeln basieren auf Anreicherungsquellen wie Aliasen für Assets und Identitäten oder dem Kontextdiagramm für Entitäten. 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 Erkennung von Regeln durch Ausschlussverfahren beheben

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

  1. Auf offensichtliche Verzögerungen prüfen:

    So stellen Sie fest, ob es eine Verzögerung bei der Aufnahme gibt:

    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 erfolgt.

  2. Erfassungszeit 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 Konfiguration des Abgleichszeitraums 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 Zeitfensters.
    • Beziehung zwischen Häufigkeit und Abgleichszeitraum:Die Häufigkeit des Abgleichs muss mit dem Abgleichszeitraum kompatibel sein. Wenn das Abgleichszeitfenster beispielsweise 5 Minuten beträgt, ist eine Ausführungshäufigkeit von 10 Minuten akzeptabel. Wenn das Abgleichszeitfenster jedoch länger als 10 Minuten ist, verwenden Sie die nächste verfügbare Ausführungshäufigkeit, also 1 Stunde.

  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 Regeln für einzelne Ereignisse: Verwenden Sie Nahezu in Echtzeit.
      • Bei Regeln mit mehreren Ereignissen und Abgleichszeiträumen von weniger als 60 Minuten: Verwenden Sie 10 Minuten.
      • Für Regeln mit Abgleichszeiträumen von mindestens 60 Minuten: Verwenden Sie je nach Bedarf 1 Stunde oder 24 Stunden.

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

    • Dauer des Abgleichszeitraums verkürzen:

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

  • Verspätete Daten vermeiden:

    Spät 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 Erkennung von Regeln bei.

Regeltypen

Regeln lassen sich in zwei Hauptkategorien einteilen:

Regeln für einzelne Ereignisse

Da Regeln für einzelne Ereignisse mithilfe eines Streamingansatzes nahezu in Echtzeit ausgeführt werden, sollten Sie sie nach Möglichkeit verwenden, um Verzögerungen zu minimieren.

Mit diesen Regeln werden einzelne Ereignisse erkannt. Es werden keine Referenzlisten, Datentabellen, Abgleichszeiträume oder UEBA (User and Entity Behavior Analytics) verwendet. Diese Regeln werden nahezu in Echtzeit und im Streamingmodus ausgeführt und haben die kürzesten Erkennungsverzögerungen.

Komplexe Regeln für einzelne Ereignisse

Bei diesen Regeln kann es eher zu Verzögerungen bei der Erkennung kommen, da sie Zeitfenster für den Abgleich oder Referenzlisten enthalten:

  • Regeln für einzelne Ereignisse mit Zeitfenster

    Das sind Regeln für einzelne Ereignisse, die ein Zeitfenster für den Abgleich enthalten und in der Regel eine etwas längere Verzögerung als andere Regeln für einzelne Ereignisse haben. Ein Abgleichszeitraum ist in der Regel ein Zeitraum, in dem eine Regel ein oder mehrere Ereignisse untersucht.

  • Regeln für einzelne Ereignisse referenzieren

    Dies sind Regeln für einzelne Ereignisse, die Referenzlisten oder Datentabellen enthalten.

Regeln mit mehreren Ereignissen

Regeln mit mehreren Ereignissen werden planmäßig ausgeführt, was aufgrund der Zeit zwischen den geplanten Ausführungen zu längeren Verzögerungen führt.

  • Regeln für mehrere Ereignisse

    In diesen Regeln werden zwei oder mehr UDM-Ereignisbedingungen untersucht. Sie haben in der Regel einen Abgleichszeitraum und mehrere Bedingungen.

  • Kontextsensitiven 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.
    • Kontextbezogene 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 zu 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 für Echtzeitdaten häufiger ausgeführt. Dies gilt nur für Regeln für einzelne Ereignisse.
  • Andere Häufigkeiten:Für andere Regeltypen können Sie die folgenden Häufigkeiten festlegen:
    • Die Häufigkeit von 10 Minuten gilt für Abgleichszeiträume von weniger als 60 Minuten.
    • 1-Stunden- und 24-Stunden-Häufigkeiten sind für Zeitfenster für den Abgleich von weniger als 48 Stunden gültig.
    • Die 24-Stunden-Häufigkeit gilt für alle Abgleichszeiträume von mindestens 48 Stunden.

Mögliche Problemumgehung:Wenn Sie schneller Ergebnisse erhalten möchten, können Sie die Ausführungshäufigkeit verkürzen. Das Verkleinern des Abgleichszeitraums wirkt sich nicht direkt auf die Latenz aus, kann aber die Effizienz erhöhen, indem die Mindestverzögerung festgelegt wird.

Zeitfenster für den 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 Folgeabfrage 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 beim Überprüfen einer Erkennung sorgfältig die Zeitstempel für UDM-Ereignisse und ‑Aufnahme.

Probleme mit der Zeitzone

Die Standardzeitzone für Google SecOps SIEM ist UTC. Wenn Protokolle keine explizite Zeitzonendefinition enthalten, werden sie vom System als UTC interpretiert. Bei einer falschen Interpretation können 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 ursprünglichen Ereignisses.
  • 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 mit der Regel ein angereichertes Feld ausgewertet wird, kann sich die Erkennung verzögern.

Weitere Informationen finden Sie unter Datenanreicherung.

Aliasing und Anreicherung

Aliasing und Anreicherung sind zwei Schritte im Prozess zur Anreicherung von Sicherheitsdaten in Google SecOps, bei dem Kontextdaten mit Ereignisdatensätzen korreliert und hinzugefügt werden. Beim Aliasing werden die Verbindungen ermittelt und beim Enrichment werden die UDM-Felder mit den entsprechenden 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 ein user ID (z. B. alex) mit dem 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 das zugehörige hostname (z. B. alex-macbook) ermittelt 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 Aliasbildung.

UDM-Ereignisse neu anreichern

  • Änderungen an zugrunde liegenden Daten:Wenn sich die zugrunde liegenden Daten nach der Erfassung eines Ereignisses ändern, verarbeitet das System Verlaufsdaten noch einmal und aktualisiert 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 berücksichtigen.
    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. Jetzt stimmt die Regel ü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. Diese Funktion sorgt dafür, dass das System auch dann Erkennungen erstellt, wenn der Kontext verzögert ist.

  • Änderungen an Anreicherungsdaten:Änderungen an 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 Diagrammen zum Entitätskontext

Das System generiert und fügt den Logdaten Informationen zum Entitätskontextdiagramm (Entity Context Graph, ECG) hinzu, um Kontext bereitzustellen, z. B. Indikatoren für Kompromittierung (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-Jagden

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. Ausgangsereignis:Um 13:00 Uhr geht ein Ereignis mit ip_address = 10.0.0.5 ein. Derzeit ist die hostname unbekannt.
  2. Alias-Quelle wird empfangen:Um 14:30 Uhr (mehr als eine Stunde später) wird ein DHCP-Log für 13:00 Uhr empfangen, in dem 10.0.0.5 mit workstation-123 verknüpft wird.
  3. Nachträgliche 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 erfolgt sind.

Hinweis:Latenzüberwachungs-Messwerte für Live-Erkennungsregeln können nicht von denen für Retrohunt-Erkennungsregeln unterschieden werden. Um eine Verfälschung der Messwerte für die Überwachung der Erkennungslatenz zu vermeiden, sollten Sie keine Live-Regel verwenden, um eine Retrohunt-Regel zu simulieren. Als Best Practice sollten Sie eine spezielle Erkennungsregel erstellen und als Retrohunt-Regel ausführen.

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 neue Erkennungen basierend auf aktualisierten Inhalten der Referenzliste 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 Verzögerungen bei der Erkennung:

  • Protokolldaten an Google SecOps senden, 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 auch nach der ersten Erkennung weiterhin Daten, was zu neuen oder aktualisierten Erkennungen führen kann. Weitere Informationen finden Sie unter Wann werden Regelwiederholungen ausgelöst?.

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