Regelwiederholungen und MTTD

Unterstützt in:

In diesem Dokument wird erläutert, wie bei Regelwiederholungen (auch Bereinigungsdurchläufe oder Abstimmungsdurchlä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 Security Operations verarbeitet große Mengen an Sicherheitsdaten. Damit Regeln, die von Kontext- oder korrelierten Daten abhängen, genaue Ergebnisse liefern, führt die Regel-Engine automatisch einen Regel-Replay-Prozess aus.

Beim Wiederholen von Regeln werden diese Kategorien von Regeln berücksichtigt:

  • Einzelereignisregeln:Diese Regeln werden noch einmal ausgeführt, wenn durch die UDM-Anreicherung ein zuvor ausgewertetes Ereignis aktualisiert wird. Ausnahmen in Bezug auf Regeln mit Datentabellen finden Sie weiter unten in diesem Dokument unter Szenarien für verspätet eintreffende Daten.

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

  • Regeln für mehrere Ereignisse:Diese Regeln werden nach einem Zeitplan ausgeführt und verarbeiten Blöcke von Ereigniszeit. Sie bewerten denselben Zeitblock in unterschiedlichen Intervallen immer wieder neu, 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 erneute Ausführung von Regeln

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 eingehenden Daten umfassen die folgenden Kategorien:

  • Quellereignisse mit verspäteter Ankunft:Das Rohlog oder UDM-Ereignis selbst kommt in Google SecOps deutlich später als der tatsächliche Zeitstempel des Ereignisses an.
  • 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-Anreicherungsupdates:Spät eintreffende Quelldaten (z. B. DHCP-Datensätze, 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 werden. Durch diese verspätete Ankunft werden die Feldwerte rückwirkend aktualisiert.

Das System löst Regelwiederholungen 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 eingehende Daten eine erneute Auswertung der Regel auslösen können.

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

    • Späte Quellereignisse:Diese Regeln verarbeiten ein Ereignis in der Regel unabhängig davon, wie alt sein Zeitstempel ist, wenn es im System eintrifft. Das System legt kein strenges Zeitfenster für die Erstverarbeitung von verspäteten Quellereignissen fest.
    • Späte Anreicherung:Wenn Anreicherungsdaten für ein zuvor ausgewertetes Ereignis eingehen oder eine Aktualisierung erfolgt, wertet das System diese Einzelereignisregeln noch einmal im 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:

    • Bei diesen Regeln wird nicht dieselbe Verarbeitung verspäteter Daten wie bei anderen Einzelereignisregeln oder die Korrekturzeitpläne von Mehrfachereignisregeln verwendet.
    • Sie haben das folgende Verhalten:
      • Annahmeschluss:Bei diesen Regeln werden Ereignisse, die 7 Tage oder länger nach dem Ereignis-Zeitstempel erfasst werden, nicht verarbeitet.
      • Verspätet eingehende Daten (< 7 Tage): Das System verarbeitet Ereignisse, die mit einer Verzögerung von weniger als 7 Tagen eintreffen, aber möglicherweise mit höherer Latenz.
      • Quellereignisse, die zu spät eintreffen: WSE-Regeln verarbeiten keine Ereignisse, wenn die Daten sieben oder mehr Tage nach dem Ereignis-Zeitstempel in Google SecOps eintreffen.
      • 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 bei der ursprünglichen Auswertung keine Erkennung erfolgte.
      • 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 anhand des aktualisierten Ereignisses neu aus. Im Gegensatz zu anderen Regeltypen führen Aktualisierungen des Inhalts von Datentabellen jedoch nicht zu einer automatischen Neubewertung vergangener Ereignisse für diese Regeln.
      • Lookback-Window:Bei diesen Regeln wird ein Lookback-Window von etwa 7 Tagen verwendet, um Ereignisse neu zu bewerten. Wenn Anreicherungsdaten für ein Ereignis eingehen, das Innerhalb von 7 Tagen fällt, wird die Regel neu ausgewertet.

  • Regeln für mehrere Ereignisse:

    • Regeln für mehrere Ereignisse werden nach einem Zeitplan ausgeführt und Zeitblöcke werden neu ausgewertet, um verspätete Daten zu berücksichtigen. Der Zeitplan der Regel bestimmt das effektive Cut-off-Zeitfenster:
      • Primärer Lauf:Das System führt die erste Auswertung zum Zeitpunkt des Ereignisses plus einer konfigurierten Abrechnungsverzögerung aus (z. B. T + 1 Stunde).
      • Abstimmungsdurchlauf 1:Der erste Abstimmungsdurchlauf wird etwa 4 Stunden nach dem primären Durchlauf ausgeführt. So können auch Ereignisse berücksichtigt werden, die erst später eintreffen.
      • Abgleichslauf 2 (bedingungsabhängig): Wenn Sie Vollständigkeit der Anreicherung sicherstellen aktivieren, führt das System etwa 30 Stunden nach dem primären Lauf einen finalen Abgleichslauf aus. Dadurch wird das Zeitfenster für die Verarbeitung von verspätet eingehenden Daten und Kontextanreicherungen durch das System auf etwa 30 Stunden verlängert.
      • Auswirkungen des Stichtags:Der endgültige Abgleich bestimmt den effektiven Stichtag für die Einbeziehung von verspäteten Daten. Das geschieht in der Regel etwa 4 Stunden nach dem primären Lauf (oder etwa 30 Stunden danach, wenn Sie Vollständigkeit der Anreicherung sicherstellen aktivieren). Ereignisse oder Anreicherungen, die nach der letzten Korrekturausführung für einen bestimmten Zeitraum eingehen, werden von dieser Regel für diesen Zeitraum nicht verarbeitet.

Beispiele für Szenarien mit verspätet eingehenden Daten

  • Szenario 1: Spätes Quellereignis – Einzelereignisregel

    • Google SecOps erfasst ein Ereignis mit einem Zeitstempel von vor drei Tagen. Bei einer Standard-Einzelereignisregel wird dieses Ereignis als neue Daten verarbeitet.

  • Szenario 2: Spätere Anreicherung – Einzelereignisregel

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

  • Szenario 3: Spätes Quellereignis – Regel für mehrere Ereignisse (Standard-Abstimmung nach 4 Stunden)

    • Ein Ereignis wird 3 Stunden nach dem Zeitstempel des Ereignisses für eine Regel für mehrere Ereignisse mit Standardeinstellungen empfangen. Das Ereignis wurde beim ersten primären Lauf (T + 1 Stunde) nicht berücksichtigt, wird aber während des 4-stündigen Abgleichslaufs verarbeitet.

  • Szenario 4: Spätes Quellereignis – Regel für mehrere Ereignisse (ohne Vervollständigung der Anreicherung)

    • Sie konfigurieren eine Regel mit mehreren Ereignissen mit einem primären Lauf-Offset von einer Stunde, ohne Vollständigkeit der Anreicherung sicherstellen zu aktivieren. Ein Ereignis geht 6 Stunden nach seinem Zeitstempel ein.
    • Bei diesem Ereignis fehlen der primäre Lauf (T + 1 Stunde) und der erste Abstimmungslauf (T + 4 Stunden). Das System verarbeitet dieses Ereignis für diesen Zeitraum nicht, da es nach dem letzten Abgleichslauf eingegangen ist.

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

    • Eine Regel für mehrere Ereignisse hat einen Offset von einer Stunde und Sie aktivieren Anreicherungsvollständigkeit sicherstellen. Anreicherungsdaten für ein Ereignis werden 28 Stunden nach dem Ereigniszeitstempel empfangen.
    • Das System wertet die Regel während des zweiten Abgleichs nach etwa T + 31 Stunden noch einmal anhand dieser späten Anreicherung aus.

  • Szenario 6: Spätes Quellereignis – Regel für mehrere Ereignisse mit Abgleichszeitraum

    • Eine Regel für mehrere Ereignisse hat ein 48-stündiges match-Zeitfenster und einen Zeitplan, bei dem Vollständigkeit der Anreicherung sicherstellen aktiviert ist (endgültiger Abgleich um T + 30 Stunden). Ein Ereignis geht 36 Stunden nach seinem Zeitstempel ein. Dieses Ereignis wird nicht verarbeitet, da es nach dem letzten Abgleichslauf eingegangen ist. Die Ereigniszeit liegt jedoch im Abgleichszeitraum der Regel in Bezug auf andere Ereignisse. Die Frist 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-Rückblickszeitraums für WSE-Regeln und wird möglicherweise nicht verarbeitet.

Auswirkungen auf Zeitmesswerte

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

  • Das Erkennungszeitfenster oder der Ereignis-Zeitstempel der Benachrichtigung bezieht sich auf den Zeitpunkt der ursprünglichen schädlichen Aktivität.
  • Die Erstellungszeit ist die Zeit, zu der 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.

Zeitachsendelta und MTTD

Die Zeit, die zwischen dem Zeitstempel des ursprünglichen Ereignisses und der Erstellung einer Erkennung vergangen ist, wirkt sich direkt auf die Berechnung der MTTD aus.

Pipeline-/Zeitplanphase Zeitpunkt der Auswertung Auswirkungen auf die MTTD-Messung
Regel für einzelne Ereignisse (Streaming) Kontinuierlich (weniger als 5 Minuten nach der Ankunft) Echtzeiterkennungen sind ein Beweis für die Geschwindigkeit der Plattform und haben nur minimale Auswirkungen auf die MTTD.
Regel für mehrere Ereignisse (primärer Lauf) 1 bis 2 Stunden nach der Ankunft (plus konfigurierte Abrechnungsverzögerung) Enthält das unvermeidliche Batchpufferungsfenster, das zum Aggregieren von Korrelationsstatus für mehrere Ereignisse erforderlich ist.
Regel für mehrere Ereignisse (Abstimmungsdurchläufe) 4 Stunden oder 30 Stunden nach dem primären Lauf Bei einem sekundären (Wiederholungs-)Lauf, in den verspätete Anreicherungsdaten einbezogen werden, erscheint diese Zeit im Vergleich zum Ereigniszeitstempel 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 von der ersten Kompromittierung 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 Erkennungstyp kennzeichnet Erkennungen, die aus Ereignisdaten generiert wurden, die mehr als 30 Minuten zu spät eingegangen sind, aus automatisierten Abgleichsläufen, aus Pipelines für die Neuverarbeitung oder aus Retrohunts. Dieses Symbol wird auch auf der Seite Benachrichtigungen in Google SecOps angezeigt.

Echtzeiterkennungssysteme priorisieren

Verwenden Sie Einzelereignisregeln, um die schnellsten Erkennungen zu erzielen. 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 für mehrere Ereignisse berücksichtigen

Regeln für mehrere Ereignisse haben aufgrund ihrer geplanten Ausführungshäufigkeit naturgemäß eine höhere Latenz. Wenn Sie die MTTD für Erkennungen aus Mehrfachereignisregeln messen, sollten Sie berücksichtigen, dass durch automatische Regelwiederholungen die Abdeckung und Genauigkeit erhöht werden. Bei diesen Replays werden oft Bedrohungen erkannt, die einen späten Kontext erfordern, was die gemeldete Latenz für diese Erkennungen erhöht.

  • Für kritische, zeitkritische Benachrichtigungen:Verwenden Sie Einzelereignisregeln oder Regeln mit mehreren Ereignissen mit den kürzesten praktikablen Ausführungshäufigkeiten. Das Verkürzen des Abgleichszeitraums hat keine direkten Auswirkungen auf die Latenz, kann aber die Effizienz steigern, indem die Mindestverzögerung festgelegt wird.

  • 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. Bei ihnen kann es zu einer hohen Latenz bei spät eintreffenden Kontext- oder Ereignisdaten kommen. Sie bieten jedoch den Vorteil einer höheren Genauigkeit bei der Erkennung anstelle von absoluter Geschwindigkeit.

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

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

Nächste Schritte

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

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