Regelwiederholungen und MTTD
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
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. Bei diesem Prozess wird derselbe Block von Ereignisdaten mehrmals in verschiedenen Intervallen ausgewertet, um verspätet eingehende Daten oder Regeln zu verarbeiten, für die ein aktualisierter Kontext erforderlich ist, z. B. beim Abgleich mit einem Indicator of Compromise (IOC).
Trigger für die erneute Regelausführung
Regeln werden neu ausgewertet (erneut ausgeführt), wenn relevante Kontextdaten später als die ursprünglichen Ereignisdaten eingehen oder verarbeitet werden.
Häufige Auslöser für die erneute Ausführung von Regeln:
Verspätet eintreffende Anreicherungsdaten
Datenanreicherungspipelines wie der Entity Context Graph (ECG) verarbeiten Daten möglicherweise 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.
Nachträgliche Aktualisierungen der UDM-Anreicherung
Wenn in Ihrer Regel Aliasfelder (angereicherte Felder) in der Erkennungslogik verwendet werden, z. B.
$udm.event.principal.hostname, und die Quelldaten (z. B. DHCP-Datensätze) mehr als eine Stunde später eintreffen, werden diese Feldwerte rückwirkend für den jeweiligen Ereigniszeitpunkt aktualisiert. Bei nachfolgenden Regelausführungen („Bereinigungsdurchläufen“) werden dann diese neu angereicherten Werte verwendet, was zu einer Erkennung führen kann, die zuvor übersehen wurde.Geplante Regeln mit mehreren Ereignissen
Regeln mit mehreren Ereignissen (Multi-Event, ME) werden nach einem Zeitplan (z. B. alle 10 Minuten, stündlich oder täglich) ausgeführt, um Blöcke von Ereigniszeit zu bewerten. Um späte Aktualisierungen der Anreicherung historischer Daten zu erfassen, werden diese Regeln später noch einmal für denselben Zeitraum ausgewertet. Das erfolgt oft mindestens zwei- oder dreimal (z. B. mit Prüfungen nach 5–8 Stunden und noch einmal nach 24–48 Stunden).
Auswirkungen auf Zeitmesswerte
Wenn eine Erkennung aus einer Regelwiederholung resultiert, bezieht sich das Erkennungszeitfenster oder der Ereigniszeitstempel der Warnung auf den Zeitpunkt der ursprünglichen schädlichen Aktivität. Die Erstellungszeit ist die Zeit, zu der die Erkennung erstellt wird. Das kann viel später sein, manchmal Stunden oder Tage später.
Eine hohe Erkennungslatenz (ein großer Zeitunterschied zwischen dem Ereignis und der Erkennung) wird in der Regel durch die erneute Anreicherung von Daten mit verspäteter Ankunft oder durch Latenz in der Entity Context Graph-Pipeline (ECG) verursacht.
Durch diese Zeitdifferenz kann es so aussehen, als ob eine Erkennung „zu spät“ oder „verzögert“ erfolgt ist. Das kann Analysten verwirren und Leistungsmesswerte wie MTTD verzerren.
| Messwertkomponente | Quelle der Zeit | 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 Zeitangabe erscheint im Vergleich zum Event-Zeitstempel „spät“ oder „verzögert“, da sie auf einem sekundären (Wiederholungs-)Lauf basiert, in den verspätete 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 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.
Echtzeit-Erkennungssysteme priorisieren
Für die schnellsten Erkennungen sollten Sie Regeln für einzelne Ereignisse verwenden. Diese Regeln werden 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. Bei der Messung der MTTD für Erkennungen, die durch Mehrfachereignisregeln generiert werden, ist es wichtig zu wissen, dass Erkennungen, die aus automatischen Regelwiederholungen resultieren, dazu dienen, die Abdeckung und Genauigkeit zu erhöhen. Diese Replays fangen zwar oft Bedrohungen ab, die einen späten Kontext erfordern, erhöhen aber zwangsläufig die gemeldete Latenz für diese spezifische Erkennung.
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 (z. B. kürzere Abgleichszeiträume, unter einer Stunde).
Bei komplexen Korrelationen mit langer Dauer (UEBA, mehrstufige Angriffe): Wenn Regeln auf umfangreichen Kontext-Joins oder Referenzlisten basieren, die möglicherweise asynchron aktualisiert werden, ist mit einer höheren Latenz (bis zu 48 Stunden oder mehr) zu rechnen. Hier liegt der Vorteil in der höheren Genauigkeit der Erkennung und nicht in der absoluten 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 nicht aliasierte Felder (Felder, die nicht nachgelagerten Anreicherungspipelines unterliegen) in Ihrer Regel-Logik verwenden.
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten