Regelwiederholungen und MTTD

Unterstützt in:

In diesem Dokument wird erläutert, wie bei Regelwiederholungen (auch Bereinigungsdurchläufe genannt) verspätet eingehende Daten und Kontextaktualisierungen verarbeitet werden und wie sich diese Wiederholungen auf die Messwerte für die durchschnittliche Zeit bis zur Erkennung (Mean Time To Detect, MTTD) auswirken.

Regelwiederholungen

Google SecOps verarbeitet große Mengen an Sicherheitsdaten. Damit Regeln, die von Kontext- oder korrelierten Daten abhängen, genau erkannt werden, führt die Regel-Engine automatisch einen Regel-Replay-Prozess aus.

Beim Wiederholen von Regeln werden die folgenden Kategorien von Regeln berücksichtigt:

  • Regeln für einzelne Ereignisse:Wenn beim UDM-Anreicherungsprozess ein zuvor ausgewertetes Ereignis aktualisiert wird, werden Regeln für einzelne Ereignisse noch einmal ausgeführt. Ausnahmen für Regeln mit Datentabellen finden Sie unten.

  • Regeln für Einzelereignisse mit Zeitfenster (Windowed Single-event, WSE) und Regeln für Einzelereignisse mit Datentabellen:Diese Regeln haben einen eigenen Planungsmechanismus für die Verarbeitung von Daten, die verspätet eintreffen. Er unterscheidet sich sowohl von Standardregeln für Einzelereignisse als auch von Regeln für Mehrfachereignisse.

  • Regeln mit mehreren Ereignissen:Regeln mit mehreren Ereignissen werden nach einem Zeitplan ausgeführt und verarbeiten Blöcke von Ereigniszeit. Bei diesen Regeln wird derselbe Zeitblock in unterschiedlichen Intervallen immer wieder neu ausgewertet, um späte Aktualisierungen zu erfassen, z. B. übereinstimmende Nutzer- oder Asset-Kontextdaten oder einen Kompromittierungsindikator (IOC). Die genauen Zeitangaben hängen von der Zeitplankonfiguration ab.

Trigger für die Regelwiedergabe

Das System wertet Regeln neu aus (führt sie noch einmal aus), um sicherzustellen, dass Erkennungen erfasst werden, auch wenn Daten nach der ersten Regelausführung eingehen oder aktualisiert werden. Diese spät eintreffenden Daten umfassen die folgenden Kategorien:

  • Quellereignisse mit verspäteter Ankunft:Das Rohprotokoll oder UDM-Ereignis selbst kommt in Google SecOps deutlich später an als der tatsächliche Zeitstempel des Ereignisses.
  • Spät eintreffende Anreicherungsdaten:Kontextbezogene Daten (z. B. Nutzer-, Asset- oder Threat Intelligence-Daten) zu einem Ereignis werden verfügbar oder das System aktualisiert sie, nachdem das Ereignis zum ersten Mal verarbeitet wurde. Das liegt oft daran, dass Anreicherungspipelines wie der Entity Context Graph (ECG) Daten in Batches verarbeiten oder von externen Datenquellen abhängig sind.
  • Rückwirkende UDM-Anreicherungsaktualisierungen:Spät eintreffende Quelldaten (z. B. DHCP-Einträge, die Hostnamen aktualisieren) lösen Änderungen an UDM-Ereignisfeldern aus. Regeln, die Aliasfelder (angereicherte Felder) in ihrer Erkennungslogik verwenden, z. B. $udm.event.principal.hostname, können Replays auslösen, wenn Quelldaten verzögert eintreffen. Durch diese verspätete Ankunft werden die Feldwerte rückwirkend aktualisiert.

Das System löst die erneute Ausführung von Regeln je nach Regeltyp und Art der verspäteten Daten unterschiedlich aus. Ziel ist es, die Aktualität der Erkennung mit der Vollständigkeit der Daten in Einklang zu bringen.

So verarbeitet das System verspätet eingehende Daten nach Regeltyp

Der Regeltyp und seine Konfiguration bestimmen das Zeitfenster, in dem verspätet eintreffende Daten eine erneute Auswertung der Regel auslösen können.

  • Regeln für einzelne Ereignisse (ohne Abgleichszeiträume oder Datentabellen):

    • Späte Quellereignisse:Bei diesen Regeln wird ein Ereignis in der Regel unabhängig davon verarbeitet, wie alt sein Zeitstempel ist, wenn es im System eingeht. Das System legt kein strenges Zeitfenster für die Erstverarbeitung von späten Quellereignissen fest.
    • Späte Anreicherung:Wenn Anreicherungsdaten für ein zuvor ausgewertetes Ereignis eintreffen oder eine Aktualisierung erfolgt, wertet das System diese Regeln für einzelne Ereignisse noch einmal anhand des Ereignisses mit dem neuen Kontext aus. Das kann Stunden oder sogar Tage nach dem ursprünglichen Ereignis passieren.

  • Regeln für einzelne Ereignisse mit Zeitfenster (Windowed-Single-Event, WSE) und Regeln für einzelne Ereignisse mit Datentabellen:

    • Für diese Regeln gilt nicht die gleiche Verarbeitung verspäteter Daten wie für andere Regeln für einzelne Ereignisse oder die Abgleichspläne von Regeln für mehrere Ereignisse.
    • Sie verhalten sich so:
      • Ausschluss:Bei diesen Regeln werden keine Ereignisse verarbeitet, die 7 Tage oder länger nach dem Ereignis-Zeitstempel erfasst wurden.
      • Spät eintreffende Daten (< 7 Tage): Das System verarbeitet Ereignisse, die mit einer Verzögerung von weniger als 7 Tagen eintreffen, aber mit potenziell höherer Latenz.
      • Quellereignisse mit verspäteter Ankunft: WSE-Regeln verarbeiten keine Ereignisse, wenn die Daten sieben oder mehr Tage nach dem Ereignis-Zeitstempel in Google SecOps eingehen.
      • Kontextaktualisierungen:Wenn der Kontext für ein Ereignis verspätet eintrifft oder ein Ereignis nachträglich angereichert wird, werden die Regeln automatisch anhand des angereicherten Ereignisses neu ausgewertet. Durch die erneute Ausführung der Regel können neue Erkennungen ausgelöst werden, auch wenn die ursprüngliche Auswertung nicht zu einer Erkennung geführt hat.
      • Späte Anreicherung: Wenn ein UDM-Ereignis aufgrund der Anreicherung aktualisiert wird (was bis zu 7 Tage nach der Aufnahme erfolgen kann), wertet das System diese Regeln noch einmal anhand des aktualisierten Ereignisses aus. Im Gegensatz zu anderen Regeltypen wird bei Aktualisierungen des Inhalts von Datentabellen jedoch keine automatische Neubewertung vergangener Ereignisse für diese Regeln ausgelöst.
      • Lookback-Window:Bei diesen Regeln wird ein Lookback-Window von etwa 7 Tagen verwendet, um Ereignisse neu zu bewerten. Wenn für ein Ereignis, das innerhalb von 7 Tagen liegt, Anreicherungsdaten eingehen, wird die Regel neu ausgewertet.

  • Regeln für mehrere Ereignisse:

    • Regeln mit mehreren Ereignissen werden nach einem Zeitplan ausgeführt und Zeitblöcke werden neu ausgewertet, um verspätete Daten zu berücksichtigen. Wie Sie den Zeitplan der Regel konfigurieren, bestimmt das effektive Ablaufzeitfenster:
      • Standardzeitplan:Das System führt in der Regel etwa 5 und 24 Stunden nach der Eventzeit automatische Abstimmungen durch. Wenn die Daten nach Abschluss des 24-Stunden-Zeitraums eingehen, werden sie für dieses Zeitfenster nicht von dieser Regel berücksichtigt.
      • Anpassbare Zeitpläne aktiviert:Mit dieser Funktion haben Sie über die Einstellungen für die „Ausführungshäufigkeit“ mehr Kontrolle über die Ausführungszeiten. Weitere Informationen finden Sie unter Benutzerdefinierte Zeitpläne für Regeln konfigurieren. Die wichtigsten Termine sind:
        • Erster Lauf:Das System führt den ersten Lauf zur Ereigniszeit plus dem konfigurierten Offset aus (z. B. T + 1 Stunde).
        • Abstimmungsdurchlauf 1:Das System führt den ersten Abstimmungsdurchlauf etwa 4 Stunden nach dem ersten Durchlauf aus. Das bedeutet, dass das System Ereignisse berücksichtigen kann, die bis zu etwa T + 4–5 Stunden eintreffen.
        • Abstimmungsdurchlauf 2 (bedingt): Wenn Sie Vervollständigung der Anreicherung sicherstellen aktivieren, führt das System etwa 30 Stunden nach dem ersten Durchlauf einen letzten Abstimmungsdurchlauf aus. Dadurch wird das Zeitfenster für die Verarbeitung verspäteter Daten auf etwa T + 30–31 Stunden verlängert.
      • Auswirkungen des Cut-offs:Bei anpassbaren Zeitplänen bestimmt der letzte Abgleichslauf den effektiven Cut-off für die Einbeziehung verspäteter Daten. Das passiert in der Regel etwa 4 Stunden nach dem ersten Lauf oder etwa 30 Stunden nach dem ersten Lauf, wenn Sie Vollständigkeit der Anreicherung sicherstellen aktivieren. Ereignisse oder Anreicherungen, die nach dem letzten Abgleichslauf für einen bestimmten Zeitraum eintreffen, werden von dieser Regel für diesen Zeitraum nicht verarbeitet.

Beispiele für Szenarien mit spät eintreffenden Daten

  • Szenario 1: Spätes Quellereignis – Regel für ein einzelnes Ereignis

    • Google SecOps erfasst ein Ereignis mit einem Zeitstempel von vor drei Tagen. Bei einer Standardregel für einzelne Ereignisse wird dieses Ereignis als neue Daten verarbeitet.

  • Szenario 2: Späte Anreicherung – Regel für einzelnes Ereignis

    • Das System hat gestern ein Anmeldeereignis verarbeitet. Heute werden neue Informationen für den betreffenden Nutzer (z. B. eine Änderung der Abteilung) aufgenommen und angereichert. Das System wertet die Regel für einzelne Ereignisse anhand des Anmeldeereignisses mit dem aktualisierten Nutzerkontext neu aus.

  • Szenario 3: Spätes Quellereignis – Regel mit mehreren Ereignissen (Standardzeitplan)

    • Wenn ein Ereignis 10 Stunden nach seinem Ereigniszeitstempel eintrifft, wird es während des 5-stündigen Abgleichs nicht berücksichtigt, aber während des 24-stündigen Abgleichs verarbeitet. Ein Ereignis, das 25 Stunden zu spät eintrifft, wird nicht verarbeitet.

  • Szenario 4: Spätes Quellereignis – Regel für mehrere Ereignisse (anpassbarer Zeitplan)

    • Sie konfigurieren eine Regel mit mehreren Ereignissen mit einem ersten Lauf-Offset von 1 Stunde. Ein Ereignis wird 6 Stunden nach seinem Zeitstempel empfangen.
    • Bei diesem Ereignis fehlen der erste Lauf (T + 1 Stunde) und der erste Abstimmungsdurchlauf (T + 4 Stunden). Das System verarbeitet dieses Ereignis mit dieser Regel NICHT, sofern Sie Ensure enrichment completeness (Vollständigkeit der Anreicherung sicherstellen) nicht aktivieren.

  • Szenario 5: Späte Anreicherung – Regel für mehrere Ereignisse (anpassbar mit Anreicherungs-Vollständigkeit)

    • Eine Regel mit mehreren Ereignissen hat einen Offset von einer Stunde und Sie aktivieren Vollständigkeit der Anreicherung sicherstellen. Die Anreicherungsdaten für ein Ereignis werden 28 Stunden nach dem Ereigniszeitstempel empfangen.
    • Einige dieser Daten für die späte Anreicherung sind möglicherweise für den zweiten „True-up-Lauf“ verfügbar, der etwa bei T + 30 Stunden stattfindet, da Sie Vollständigkeit der Anreicherung sicherstellen aktiviert haben. Wenn die Anreicherungsdaten verfügbar sind, wird die Regel mit dieser späten Anreicherung neu ausgewertet.

  • Szenario 6: Spätes Quellereignis – Regel mit mehreren Ereignissen und Abgleichszeitraum

    • Eine Regel mit mehreren Ereignissen hat ein match-Zeitfenster von 48 Stunden und einen benutzerdefinierten Zeitplan mit aktivierter Option Vollständigkeit der Anreicherung sicherstellen (endgültiger Abgleich um T + 30 Stunden). Ein Ereignis wird 36 Stunden nach seinem Zeitstempel empfangen. Dieses Ereignis wird nicht verarbeitet, da es nach dem letzten Abgleichslauf eingegangen ist, obwohl die Ereigniszeit im Abgleichszeitraum der Regel in Bezug auf andere Ereignisse liegt. Der Stichtag basiert auf der Ankunftszeit im Verhältnis zum Abgleichszeitplan und nicht nur auf dem Abgleichszeitraum.

  • Szenario 7: Spätes Quellereignis – Regel für einzelne Ereignisse mit Zeitfenster

    • Wenn ein Quellereignis mit einem Zeitstempel von vor 8 Tagen verspätet eintrifft, liegt es möglicherweise außerhalb des 7-Tage-Lookback-Windows für WSE-Regeln und wird nicht verarbeitet.

Auswirkungen auf Zeitmesswerte

Wenn eine Erkennung aus einer Regelwiedergabe resultiert, verwendet das System die folgende Terminologie:

  • Das Erkennungszeitfenster oder der Ereigniszeitstempel der Warnung bezieht sich auf den Zeitpunkt der ursprünglichen schädlichen Aktivität.
  • Die Erstellungszeit ist der Zeitpunkt, zu dem das System die Erkennung erstellt. Das kann viel später sein, manchmal Stunden oder Tage später.
  • Die Erkennungs-Latenz ist die Zeitdifferenz zwischen dem Event-Zeitstempel und der Erstellungszeit der Erkennung.

Eine erneute Anreicherung aufgrund von Daten, die erst spät eingehen, oder eine Latenz bei der Aktualisierung einer Kontextquelle wie dem Entity Context Graph (ECG) führt in der Regel zu einer hohen Erkennungslatenz.

Diese Zeitdifferenz kann dazu führen, dass eine Erkennung „spät“ oder „verzögert“ erfolgt. Das kann Analysten verwirren und Leistungsmesswerte wie MTTD verzerren.

Messwertkomponente Quelle der Zeit Wie sich Wiederholungen auf die MTTD auswirken
Erkennungszeitraum / Ereigniszeitstempel Zeitpunkt des ursprünglichen Sicherheitsereignisses. Bei Wiederholungen wird die Zeit des Ereignisses beibehalten.
Erkennungszeit / Erstellungszeit Zeitpunkt, zu dem die Engine die Erkennung tatsächlich ausgegeben hat. Bei einem sekundären (Wiederholungs-)Lauf, in den verspätete Anreicherungsdaten einbezogen werden, erscheint diese Zeit im Vergleich zum Ereignis-Zeitstempel als verspätet oder verzögert. Dieses Delta wirkt sich negativ auf die Berechnung der MTTD aus.

Best Practices für die Messung der MTTD

Die MTTD gibt die Zeit vom ersten Kompromiss bis zur effektiven Erkennung der Bedrohung an. Wenn Sie Erkennungen analysieren, die durch das erneute Ausführen von Regeln ausgelöst wurden, sollten Sie die folgenden Best Practices anwenden, um genaue MTTD-Messwerte zu erhalten.

Google SecOps bietet mehrere Messwerte, die Nutzer abfragen können, um die MTTD genau zu messen. Weitere Informationen zu diesen Messwerten finden Sie auf der Seite YARA-L 2.0-Beispielabfragen für Dashboards.

Ein -Symbol in der Spalte Detection Type (Erkennungstyp) kennzeichnet Erkennungen, die vom System aus Ereignisdaten generiert werden, die mehr als 30 Minuten zu spät eintreffen, aus der erneuten Verarbeitung von Regeln oder aus Retrohunts. Dieses Symbol wird auch auf der Seite Benachrichtigungen in Google SecOps angezeigt.

Echtzeit-Erkennungssysteme priorisieren

Für die schnellsten Erkennungen sollten Sie Regeln für einzelne Ereignisse verwenden. Diese Regeln werden nahezu in Echtzeit ausgeführt, in der Regel mit einer Verzögerung von weniger als 5 Minuten.

Außerdem wird so eine umfassendere Nutzung von zusammengesetzten Erkennungen unterstützt.

Regelwiederholung in Regeln mit mehreren Ereignissen berücksichtigen

Regeln mit mehreren Ereignissen haben aufgrund ihrer geplanten Ausführungshäufigkeit eine höhere Latenz. Wenn Sie die MTTD für Erkennungen aus Mehrfachereignisregeln messen, sollten Sie berücksichtigen, dass durch automatisierte Regelwiederholungen die Abdeckung und Genauigkeit erhöht werden. Bei diesen Replays werden häufig Bedrohungen erkannt, die einen späten Kontext erfordern. Dadurch erhöht sich die gemeldete Latenz für diese Erkennungen.

  • Für kritische, zeitkritische Benachrichtigungen:Verwenden Sie Regeln für einzelne Ereignisse oder Regeln für mehrere Ereignisse mit den kürzesten praktikablen Ausführungshäufigkeiten. Das Verkleinern des Abgleichszeitraums wirkt sich nicht direkt auf die Latenz aus, kann aber die Effizienz durch Festlegen der Mindestverzögerung erhöhen.

  • Für komplexe Korrelationen mit langer Dauer (UEBA, mehrstufige Angriffe): Diese Regeln basieren auf umfangreichen Kontext-Joins oder Referenzlisten, die möglicherweise asynchron aktualisiert werden. Sie können eine hohe Latenz bei Kontext- oder Ereignisdaten aufweisen, die spät eintreffen, bieten aber den Vorteil einer höheren Qualität bei der Erkennung anstelle von absoluter Geschwindigkeit.

Regeln optimieren, um die Abhängigkeit von der späten Anreicherung zu verringern

Wenn Sie die Erkennungsgeschwindigkeit optimieren und die Auswirkungen von nachträglichen Anreicherungen minimieren möchten, sollten Sie nach Möglichkeit Felder ohne Alias (Felder, die von nachgelagerten Anreicherungspipelines nicht verarbeitet werden) in Ihrer Regel verwenden.

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