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, sowie 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 Rohprotokolle 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

Regelerkennungen sind immer mit einer gewissen Verzögerung verbunden, die von nahezu in Echtzeit bis zu einigen Minuten oder vielen Stunden reichen kann. Faktoren wie der Regeltyp, die Ausführungshäufigkeit und die Methode zur Generierung von Erkennungen wirken sich auf diese Verzögerungen aus. In diesem Dokument werden diese und andere Verzögerungsfaktoren erläutert.

Wir kategorisieren Verzögerungen als erwartet oder nicht vorhergesagt.

  • Erwartete Verzögerungen: Diese Verzögerungen sind das Ergebnis des Aufnahmeprozesses und der Konfigurationsoptionen, die Sie beim Einrichten der Erkennungsregel auswählen.
     Das Erstellen einer Erkennung dauert beispielsweise eine Weile. 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 Verlangsamung 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. Verwenden Sie im Dashboard für Regeln die Suche, um Regeln mit langen Erkennungsverzögerungen zu finden.

  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.

  4. Machen Sie sich mit den folgenden Themen vertraut, um zu verstehen, wie sich diese Faktoren auf Verzögerungen bei der Erkennung von Regeln 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 ohne Abschnitt für keine Übereinstimmung und ohne externe Datasets wie Referenzlisten oder Datentabellen verarbeitet.

  2. Abfrage-Engine

    Die Query-Engine verarbeitet Regeln so:

    • Komplexe Einzelereignisregeln:

      • 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 (in Echtzeit) ausgeführt, sobald neue Daten aufgenommen und für die Regelverarbeitung 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 der Ereigniszeit beispielsweise nach 5 bis 8 Stunden und nach 24 bis 48 Stunden noch einmal abgefragt, je nach Zeitplan der 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. Die letzte Anreicherung erfolgt drei Tage nach dem Ereigniszeitpunkt.
  • 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 sich die Verarbeitung von erneuter Anreicherung und Regelwiederholungen überschneidet, 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 Asset- und Identitäts-Aliasing oder dem Entity-Kontextdiagramm. Da diese Regeln auf mehreren Ereignisquellen basieren, sind sie anfälliger für Latenz.
  • Das System führt Regeln zwischen 5 und 8 Stunden sowie zwischen 24 und 48 Stunden nach der ersten Ausführung noch einmal aus. Diese beiden separaten Regelwiederholungen erfolgen je nach Ausführungszeiten der Pipeline für die Neuverarbeitung.

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:

    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 Erkennungsverzögerung wahrscheinlich auf eine erwartete Verzögerung zurückführen.

  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 häufigsten Ausführungsoptionen:

    • Regelfrequenz erhöhen:

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

      • 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:

      Kleinere Abgleichszeiträume sind effizienter. Ändern Sie ein 60‑minütiges Abgleichszeitfenster in 59 Minuten, um die 10‑minütige Verarbeitung zu aktivieren.

  • 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 Event-Zeitblock 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 für einzelne Ereignisse:

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

    • Einfache Regeln für einzelne Ereignisse

      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

      • Regeln für einzelne Ereignisse im Fenster

        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 für mehrere Ereignisse:

    Regeln mit mehreren Ereignissen werden planmäßig ausgeführt. Das führt zu längeren Verzögerungen, da die Ausführung erst nach dem nächsten geplanten Lauf erfolgt.

    • Regeln für mehrere Ereignisse

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

    • Kontextsensitive Regeln

      Kontextbezogene Regeln helfen Ihnen, sowohl die Verhaltensmuster in der Telemetrie als auch den Kontext der betroffenen Einheiten aus diesen Mustern zu verstehen.

      • Diese Regeln bestehen aus mindestens zwei Bedingungen, wobei mindestens eine Bedingung ein UDM-Entitätsereignis ist (wobei das UDM-Ereignis vom Typ context ist, z. B. user_context).
      • Bei diesen Regeltypen kann es zu längeren Verzögerungen kommen. Es ist nicht ungewöhnlich, dass Erkennungen einige Tage dauern.
      • Kontextbezogene Regeln haben in der Regel die längsten Verzögerungen, da das System zuerst die erforderlichen Kontextdaten generieren muss.

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 und laufen ständig. 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:
    • Eine Häufigkeit von 10 Minuten ist für Abgleichszeiträume von weniger als 60 Minuten gültig.
    • 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 schnellere Erkennungen wünschen, verwenden Sie eine kürzere Ausführungshäufigkeit und ein kleineres Übereinstimmungsfenster. Bei Verwendung kürzerer Zeitfenster für den Abgleich (weniger als eine Stunde) sind häufigere Ausführungen möglich.

Zeitfenster für den Abgleich

Wenn eine Regel ein Zeitfenster für den Abgleich hat, bestimmt die Dauer des Fensters die minimale Verzögerung bei der Erkennung, 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 bei der Überprüfung eines erkannten Problems sorgfältig die Zeitstempel für UDM-Ereignisse und die 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 Graph verwenden, kann es zu längeren Verzögerungen kommen. Google SecOps muss zuerst die Kontextdaten generieren.

Anreicherungssystem

Google SecOps reichert UDM-Ereignisse mit Kontextdaten aus anderen Quellen an. 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 in Beziehung gesetzt 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. Beispiel: Durch Aliasing kann eine einzelne hostname (z. B. alex-macbook) mit anderen zugehörigen Indikatoren verknüpft werden, z. B. mit der IP addresses, der MAC addresses (aus DHCP-Protokollen) oder einer user ID (z. B. alex) mit der job title und der employment status (aus Nutzerkontextdaten).
  • Anreicherung:Bei diesem Prozess werden die durch Aliasing erfassten Informationen verwendet, um einem UDM-Ereignis Kontext hinzuzufügen. Beispiel: Wenn 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, IPs, MACs), Nutzer, Prozesse, Metadaten für Dateihashes, 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 Aufnahme eines Ereignisses durch das System ändern, werden die Verlaufsdaten noch einmal verarbeitet und die Ereignisse bis zu 24 Stunden lang aktualisiert.

  • Aktualisierungen des Anreicherungssystems:Wenn das Anreicherungssystem Entitäts- oder Prozessmetadaten, die IP-Geolokalisierung oder VirusTotal-Indikatoren aktualisiert, werden diese Blöcke 24 bis 48 Stunden später von der Regelausführung neu ausgewertet, um diese Aktualisierungen zu erfassen.
    Beispiel: Ein Ereignis um 9:03 Uhr hat 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 hostname drei Tage nach dem ursprünglichen Log senden, wird das UDM-Ereignis 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 wird.

  • Ä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, stimmt sie nun überein und das System erstellt eine Erkennung.

Verarbeitung von Entitätskontextdiagrammen

Das System generiert und fügt den Logdaten Informationen zum 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, nachdem 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 kommt an:Um 14:30 Uhr (mehr als eine Stunde später) geht ein DHCP-Log für 13:00 Uhr ein, das 10.0.0.5 mit workstation-123 verknüpft.
  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 Regelausführungen (Bereinigungsdurchläufen) wird jetzt der angereicherte Wert (workstation-123) berücksichtigt. Dadurch können Erkennungen ausgelöst werden, die zuvor nicht möglich waren.

Hinweis:Latenzüberwachungs-Messwerte für Live-Erkennungsregeln lassen sich nicht von denen für Retrohunt-Erkennungsregeln unterscheiden. 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 Erkennungsverzögerungen:

  • Protokolldaten an Google SecOps senden, sobald das Ereignis eintritt.
  • Prüfen Sie die Audit-Regeln, 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 wird 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