Regelwiederholungen und MTTD

Unterstützt in:

In diesem Dokument wird erläutert, wie Regelwiederholungen (auch Bereinigungsdurchläufe oder Abgleichdurchläufe genannt) mit verspätet eingehenden Daten und Kontextaktualisierungen umgehen und wie sich diese Wiederholungen auf die Messwerte für die mittlere Erkennungszeit (Mean Time to Detect, MTTD) auswirken.

Regelwiederholungen

Google Security Operations verarbeitet große Mengen an Sicherheitsdaten. Um genaue Erkennungen für Regeln zu gewährleisten, die von Kontext- oder korrelierten Daten abhängen, führt die Regel-Engine automatisch eine Regelwiederholung aus.

Der Prozess der Regelwiederholung verarbeitet diese Kategorien von Regeln:

  • Einzelereignisregeln: Diese Regeln werden wiederholt, wenn der UDM-Anreicherungsprozess ein zuvor ausgewertetes Ereignis aktualisiert. Ausnahmen in Bezug auf Regeln mit Datentabellen finden Sie weiter unten in diesem Dokument unter Szenarien für verspätet eingehende Daten.

  • Einzelereignisregeln mit Zeitfenster (Windowed Single-event, WSE) und Einzelereignisregeln mit Datentabellen:Diese Regeln haben einen eigenen Zeitplanmechanismus für den Umgang mit verspätet eingehenden Daten, der sich sowohl von Standard-Einzelereignisregeln 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 der Ereigniszeit. Sie werten denselben Zeitblock in unterschiedlichen Intervallen wiederholt aus, um verspätete Anreicherungsaktualisierungen zu erfassen, z. B. übereinstimmende Kontextdaten für Nutzer oder Assets oder einen Kompromittierungsindikator (Indicator of Compromise, IOC). Die genauen Zeitpunkte hängen von der Zeitplankonfiguration ab.

Trigger für Regelwiederholungen

Das System wertet Regeln neu aus (führt sie noch einmal aus), um Erkennungen zu erfassen, auch wenn Daten nach der ersten Ausführung der Regel eingehen oder aktualisiert werden. Zu diesen verspätet eingehenden Daten gehören die folgenden Kategorien:

  • Verspätet eingehende Quellereignisse:Das Rohlog oder UDM-Ereignis selbst kommt in Google SecOps deutlich später an als der tatsächliche Zeitstempel des Ereignisses.
  • Verspätet eingehende Anreicherungsdaten:Kontextdaten (z. B. Nutzer-, Asset- oder Threat Intelligence-Daten) zu einem Ereignis werden verfügbar oder vom System aktualisiert, 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ängen.
  • Nachträgliche UDM-Anreicherungsaktualisierungen:Verspätet eingehende 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 Wiederholungen auslösen, wenn Quelldaten verzögert eintreffen. Durch diese verspätete Ankunft werden die Werte dieser Felder nachträglich aktualisiert.

Das System löst Regelwiederholungen je nach Regeltyp und Art der verspäteten Daten unterschiedlich aus. Ziel ist es, ein Gleichgewicht zwischen der Aktualität der Erkennung und der Vollständigkeit der Daten zu finden.

Umgang des Systems mit verspätet eingehenden Daten nach Regeltyp

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

  • Einzelereignisregeln (ohne Übereinstimmungsfenster oder Datentabellen) :

    • Verspätete Quellereignisse:Im Allgemeinen verarbeiten diese Regeln ein Ereignis unabhängig davon, wie alt der Zeitstempel ist, wenn es im System ankommt. Das System legt kein strenges Zeitfenster für die erste Verarbeitung verspäteter Quellereignisse fest.
    • Verspätete Anreicherung:Wenn Anreicherungsdaten für ein zuvor ausgewertetes Ereignis eintreffen oder eine Aktualisierung erfolgt, wertet das System diese Einzelereignisregeln für das Ereignis mit dem neuen Kontext neu aus. Das kann Stunden oder sogar Tage nach dem ursprünglichen Ereignis geschehen.

  • Einzelereignisregeln mit Zeitfenster (Windowed Single-event, WSE) und Einzelereignisregeln mit Datentabellen :

    • Diese Regeln folgen nicht dem gleichen Umgang mit verspäteten Daten wie andere Einzelereignisregeln oder den Abgleichzeitplänen von Regeln für mehrere Ereignisse.
    • Sie haben folgendes Verhalten:
      • Cut-off:Diese Regeln verarbeiten keine Ereignisse, die 7 Tage oder mehr nach dem Zeitstempel des Ereignisses erfasst wurden.
      • Verspätet eingehende Daten (< 7 Tage): Das System verarbeitet Ereignisse, die weniger als 7 Tage zu spät eintreffen, aber mit potenziell höherer Latenz.
      • Verspätet eingehende Quellereignisse: WSE-Regeln verarbeiten keine Ereignisse, wenn die Daten 7 Tage oder mehr nach dem Zeitstempel des Ereignisses in Google SecOps eintreffen.
      • Kontextaktualisierungen:Wenn der Kontext für ein Ereignis verspätet eintrifft oder ein Ereignis nachträglich angereichert wird, wertet das System Regeln automatisch für das angereicherte Ereignis neu aus. Diese Regelwiederholung kann neue Erkennungen auslösen, auch wenn die erste Auswertung nicht zu einer Erkennung geführt hat.
      • Verspätete Anreicherung: Wenn ein UDM-Ereignis aufgrund einer Anreicherung aktualisiert wird (was bis zu 7 Tage nach der Erfassung geschehen kann), wertet das System diese Regeln für das aktualisierte Ereignis neu aus. Im Gegensatz zu anderen Regeltypen lösen Aktualisierungen des Inhalts von Datentabellen jedoch keine automatische Neuauswertung vergangener Ereignisse für diese Regeln aus.
      • Lookback-Window:Diese Regeln verwenden ein Lookback-Window von etwa 7 Tagen, um Ereignisse neu auszuwerten. Wenn Anreicherungsdaten für ein Ereignis eintreffen, das in dieses 7-Tage-Fenster fällt, wird die Regel neu ausgewertet.

  • Regeln für mehrere Ereignisse :

    • Regeln für mehrere Ereignisse werden nach einem Zeitplan ausgeführt und werten Zeitblöcke neu aus, um verspätete Daten zu berücksichtigen. Der Zeitplan der Regel bestimmt das effektive Cut-off-Fenster:
      • Primäre Ausführung:Das System führt die erste Auswertung zur Ereigniszeit zuzüglich einer konfigurierten Abwicklungsverzögerung aus (z. B. T + 1 Stunde).
      • Abgleichdurchlauf 1:Das System führt den ersten Abgleichdurchlauf etwa 4 Stunden nach der primären Ausführung aus. So können verspätet eingehende Ereignisse berücksichtigt werden.
      • Abgleichdurchlauf 2 (optional): Wenn Sie Vollständigkeit der Anreicherung sicherstellen aktivieren, führt das System etwa 30 Stunden nach der primären Ausführung einen letzten Abgleichdurchlauf aus. Dadurch wird das Zeitfenster für die Verarbeitung verspätet eingehender Daten und Kontextanreicherungen auf etwa 30 Stunden verlängert.
      • Auswirkungen des Cut-offs:Der letzte Abgleichdurchlauf bestimmt den effektiven Cut-off für die Einbeziehung verspäteter Daten. Das geschieht in der Regel etwa 4 Stunden nach der primären Ausführung (oder etwa 30 Stunden nach der primären Ausführung, wenn Sie Vollständigkeit der Anreicherung sicherstellen aktivieren). Ereignisse oder Anreicherungen, die nach dem letzten Abgleichdurchlauf für ein bestimmtes Zeitfenster eintreffen, werden von dieser Regel für dieses Fenster nicht verarbeitet.

Beispiele für Szenarien mit verspätet eingehenden Daten

  • Szenario 1: Verspätetes Quellereignis – Einzelereignisregel

    • Google SecOps erfasst ein Ereignis mit einem Zeitstempel von vor 3 Tagen. Eine Standard-Einzelereignisregel verarbeitet dieses Ereignis als neue Daten.

  • Szenario 2: Verspätete Anreicherung – Einzelereignisregel

    • Das System hat gestern ein Anmeldeereignis verarbeitet. Heute werden neue Informationen für den betreffenden Nutzer erfasst und angereichert (z. B. eine Abteilungsänderung). Das System wertet die Einzelereignisregel für das Anmeldeereignis mit dem aktualisierten Nutzerkontext neu aus.

  • Szenario 3: Verspätetes Quellereignis – Regel für mehrere Ereignisse (Standardabgleich nach 4 Stunden)

    • Ein Ereignis trifft 3 Stunden nach dem Zeitstempel des Ereignisses für eine Regel für mehrere Ereignisse ein, die mit den Standardeinstellungen geplant ist. Das Ereignis wurde bei der ersten primären Ausführung (T + 1 Stunde) nicht berücksichtigt, wird aber während des 4-stündigen Abgleichdurchlaufs verarbeitet.

  • Szenario 4: Verspätetes Quellereignis – Regel für mehrere Ereignisse (ohne Vollständigkeit der Anreicherung)

    • Sie konfigurieren eine Regel für mehrere Ereignisse mit einer primären Ausführungsverzögerung von 1 Stunde, ohne Vollständigkeit der Anreicherung sicherstellen zu aktivieren. Ein Ereignis trifft 6 Stunden nach dem Zeitstempel ein.
    • Dieses Ereignis wird bei der primären Ausführung (T + 1 Stunde) und beim ersten Abgleichdurchlauf (T + 4 Stunden) nicht berücksichtigt. Das System verarbeitet dieses Ereignis für dieses Zeitfenster nicht, da es nach dem letzten Abgleichdurchlauf eingetroffen ist.

  • Szenario 5: Verspätete Anreicherung – Regel für mehrere Ereignisse (mit Vollständigkeit der Anreicherung)

    • Eine Regel für mehrere Ereignisse hat eine Verzögerung von 1 Stunde und Sie aktivieren Vollständigkeit der Anreicherung sicherstellen. Anreicherungsdaten für ein Ereignis treffen 28 Stunden nach dem Zeitstempel des Ereignisses ein.
    • Das System wertet die Regel während des zweiten Abgleichdurchlaufs etwa bei T + 31 Stunden mit dieser verspäteten Anreicherung neu aus.

  • Szenario 6: Verspätetes Quellereignis – Regel für mehrere Ereignisse mit Übereinstimmungsfenster

    • Eine Regel für mehrere Ereignisse hat ein match-Fenster von 48 Stunden und einen Zeitplan, bei dem Vollständigkeit der Anreicherung sicherstellen aktiviert ist (letzter Abgleich etwa bei T + 30 Stunden). Ein Ereignis trifft 36 Stunden nach dem Zeitstempel ein. Dieses Ereignis wird nicht verarbeitet, da es nach dem letzten Abgleichdurchlauf eingetroffen ist, obwohl die Ereigniszeit im Übereinstimmungsfenster der Regel in Bezug auf andere Ereignisse liegt. Der Cut-off basiert auf der Ankunftszeit im Verhältnis zum Abgleichzeitplan und nicht nur auf dem Übereinstimmungsfenster.

  • Szenario 7: Verspätetes Quellereignis – Einzelereignisregel 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 möglicherweise nicht verarbeitet.

Auswirkungen auf Zeitmesswerte

Wenn eine Erkennung auf einer Regelwiederholung beruht, verwendet das System die folgende Terminologie:

  • Das Erkennungsfenster oder der Zeitstempel des Ereignisses der Benachrichtigung bezieht sich auf den Zeitpunkt der ursprünglichen böswilligen 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 Erkennungsverzögerung ist die Zeitdifferenz zwischen dem Zeitstempel des Ereignisses und der Erstellungszeit der Erkennung.

Zeitachsendelta und MTTD

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

Pipeline-/Zeitplanphase Zeitpunkt der Auswertung Auswirkungen auf die MTTD-Messung
Einzelereignisregel (Streaming) Kontinuierlich (< 5 Minuten nach Ankunft) Erkennungen in Echtzeit geben die tatsächliche Plattformgeschwindigkeit mit minimalen Auswirkungen auf die MTTD wieder.
Regel für mehrere Ereignisse (primäre Ausführung) 1 bis 2 Stunden nach Ankunft (plus konfigurierte Abwicklungsverzögerung) Beinhaltet das unvermeidliche Batch-Pufferfenster, das zum Aggregieren von Korrelationsstatus für mehrere Ereignisse erforderlich ist.
Regel für mehrere Ereignisse (Abgleichdurchläufe) 4 oder 30 Stunden nach der primären Ausführung Eine sekundäre Ausführung (Wiederholung), die verspätete Anreicherungsdaten enthält, führt dazu, dass diese Zeit im Verhältnis zum Zeitstempel des Ereignisses verspätet oder verzögert erscheint. Dieses Delta wirkt sich negativ auf die MTTD-Berechnung aus.

Best Practices für die Messung der MTTD

Die MTTD quantifiziert die Zeit von der ersten Kompromittierung bis zur effektiven Erkennung der Bedrohung. Wenn Sie Erkennungen analysieren, die durch Regelwiederholungen ausgelöst wurden, wenden Sie die folgenden Best Practices an, um genaue MTTD-Messwerte zu erhalten.

Google SecOps bietet mehrere vom Nutzer abfragbare Messwerte, um die MTTD genau zu messen. Weitere Informationen zu diesen Messwerten finden Sie unter Beispielabfragen für YARA-L 2.0 auf der Seite „Dashboards“.

Ein Symbol in der Spalte Erkennungstyp kennzeichnet Erkennungen, die aus Ereignisdaten generiert wurden, die mehr als 30 Minuten zu spät eingetroffen sind, aus automatisierten Abgleichdurchläufen, aus Pipelines zur Neuverarbeitung oder aus Retrohunts. Dieses Symbol wird auch auf der Seite Benachrichtigungen in Google SecOps angezeigt.

Systeme zur Erkennung in Echtzeit priorisieren

Für die schnellsten Erkennungen verwenden Sie Einzelereignisregeln. Diese Regeln werden nahezu in Echtzeit ausgeführt, in der Regel mit einer Verzögerung von weniger als 5 Minuten. Dies unterstützt auch eine umfassendere Verwendung von zusammengesetzten Erkennungen.

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 Regeln für mehrere Ereignisse messen, berücksichtigen Sie, dass automatisierte Regelwiederholungen die Abdeckung und Genauigkeit erhöhen. Diese Wiederholungen erfassen oft Bedrohungen, die einen verspäteten Kontext erfordern, was die gemeldete Latenz für diese Erkennungen erhöht.

  • Für kritische, zeitkritische Benachrichtigungen: Verwenden Sie Einzelereignisregeln oder Regeln für mehrere Ereignisse mit der kürzesten praktikablen Ausführungshäufigkeit. Das Reduzieren des Übereinstimmungsfensters wirkt sich nicht direkt auf die Latenz aus, kann aber die Effizienz erhöhen , indem die Mindestverzögerung festgelegt wird.

  • Für komplexe, langwierige Korrelationen (UEBA, mehrstufige Angriffe) Diese Regeln basieren auf umfangreichen Kontextverknüpfungen oder Referenzlisten, die asynchron aktualisiert werden können. Bei verspätet eingehenden Kontext- oder Ereignisdaten kann es zu einer hohen Latenz kommen. Sie bieten jedoch den Vorteil einer Erkennung mit höherer Qualität anstelle einer absoluten Geschwindigkeit.

Regeln optimieren, um die Abhängigkeit von verspäteter Anreicherung zu verringern

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

Nächste Schritte

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

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