Regelwiederholungen und MTTD

Unterstützt in:

In diesem Dokument wird erläutert, wie Regelwiederholungen (auch Bereinigungsdurchläufe genannt) mit verspätet eingehenden Daten und Kontextaktualisierungen umgehen und wie sich dies auf die Messwerte für die durchschnittliche Zeit bis zur Erkennung (Mean Time To Detect, MTTD) auswirkt.

Regelwiederholungen

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 Prozess zur erneuten Ausführung von Regeln werden zwei verschiedene 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.

  • Regeln für mehrere Ereignisse:Regeln für mehrere Ereignisse werden nach einem von Ihnen ausgewählten 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 Indicator of Compromise (IOC).
    Eine Regel wird beispielsweise mindestens zwei- oder dreimal ausgeführt (5–8 Stunden und dann wieder 24–48 Stunden später), um verspätet eingehende Ereignis- und Kontextdaten zu berücksichtigen.

Trigger für die erneute Ausführung von Regeln

Das System wertet Regeln neu aus (führt sie noch einmal aus), wenn relevante Kontextdaten eingehen oder wenn Kontextdaten später als die ursprünglichen Ereignisdaten verarbeitet werden.

Häufige Gründe für die Wiedergabe sind:

  • Spät eintreffende Anreicherungsdaten:Datenanreicherungspipelines wie der Entity Context Graph (ECG) verarbeiten Daten häufig in Batches. Wenn ein UDM-Ereignis vor den zugehörigen Kontextdaten (z. B. Asset-Informationen oder Nutzerkontext) eintrifft, wird bei der ersten Ausführung der Regel möglicherweise keine Erkennung durchgeführt.

  • Rückwirkende UDM-Anreicherungsupdates:Regeln, die Aliasfelder (angereicherte Felder) in ihrer Erkennungslogik verwenden, z. B. $udm.event.principal.hostname, können Replays auslösen, wenn Quelldaten (z. B. DHCP-Einträge) verzögert werden. Durch diese verspätete Ankunft werden die Feldwerte rückwirkend aktualisiert. Bei nachfolgenden Regelwiederholungen werden diese neu angereicherten Werte verwendet, wodurch möglicherweise eine zuvor übersehene Erkennung ausgelöst wird.

Auswirkungen auf Zeitmesswerte

Wenn eine Erkennung aus einer Regelwiederholung resultiert, verwenden wir die folgende Terminologie:

  • Das Erkennungszeitfenster oder der Ereignis-Zeitstempel der Warnung 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.

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 Zeitquelle Wie sich Wiederholungen auf die MTTD auswirken
Erkennungszeitraum / Event-Zeitstempel Zeitpunkt des ursprünglichen Sicherheitsereignisses. Die Zeitangabe bleibt korrekt.
Erkennungszeit / Erstellungszeit Zeitpunkt, zu dem die Erkennung tatsächlich von der Engine ausgegeben wurde. Diese Zeit wird im Vergleich zum Event-Zeitstempel „spät“ oder „verzögert“ angezeigt, da sie auf einem sekundären (Replay-)Lauf basiert, in den späte Anreicherungsdaten einbezogen werden. 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 Eindringen 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 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.

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, was die gemeldete Latenz für diese Erkennungen erhöht.

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

  • Bei komplexen 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 verspätet eingehenden Kontext- oder Ereignisdaten aufweisen, bieten aber den Vorteil einer höheren Erkennungsgenauigkeit anstelle 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 nicht nachgelagerten Anreicherungspipelines unterliegen) in Ihrer Regel verwenden.

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