Zeitplan für die Ausführung von Regeln verwalten

Unterstützt in:

Dieses Dokument richtet sich an Sicherheitsanalysten und ‑ingenieure, die Zeitpläne für die Ausführung von Regeln in Google Security Operations verwalten möchten. Darin wird erläutert, wie Sie die Häufigkeitseinstellungen konfigurieren – von Echtzeitscans bis hin zu geplanten Intervallen von 24 Stunden – und wie Sie die Hintergrundläufe interpretieren, bei denen verspätet eingehende Daten verarbeitet werden.

Gängige Anwendungsfälle

Die Wahl des richtigen Zeitplans hängt von der Schwere der Bedrohung und der Komplexität Ihrer Logik ab. Die meisten Teams priorisieren ihre Zeitpläne anhand der folgenden Ziele.

Benachrichtigungen mit hoher Priorität

  • Ziel: Kritische Bedrohungen erkennen, sobald sie auf der Plattform auftreten.
  • Wert: Verkürzt die Verweildauer von Angreifern bei Übereinstimmungen mit einzelnen Ereignissen, für die kein zusätzlicher Kontext erforderlich ist.

Komplexe Korrelation und Berichterstellung

  • Ziel: Regeln ausführen, für die Zählungen, Summen oder Multi-Event-Zeiträume erforderlich sind.
  • Wert: Das System nimmt alle zugehörigen Logs vor der Ausführung auf und reichert sie an. So werden genauere Benachrichtigungen für Compliance und Trendanalysen bereitgestellt.

Hinweis

Bevor Sie Änderungen an Zeitplänen vornehmen, sollten Sie prüfen, ob Ihre Umgebung die folgenden Anforderungen erfüllt, um Konfigurationsfehler zu vermeiden.

  • Berechtigungen: Sie benötigen die Rolle „Chronicle API Admin“ (roles/chronicle.admin) oder „Chronicle API Editor“ (roles/chronicle.editor), um Regelzeitpläne zu ändern.
  • Umgebungsprüfung:Achten Sie darauf, dass Ihre Logs dem einheitlichen Datenmodell (Unified Data Model, UDM) richtig zugeordnet sind, damit geplante Intervallaggregationen unterstützt werden.

Schlüsselterminologie

Damit Sie besser verstehen, wie das System mit dem Timing umgeht, sollten Sie sich mit diesen plattformspezifischen Begriffen vertraut machen.

  • Abgleichsläufe:Automatische Hintergrundausführungen, bei denen Regeln neu ausgewertet werden, um Daten zu erfassen, die verspätet eingegangen sind oder für die Anreicherung zusätzliche Zeit erforderlich war.
  • Anreicherung:Der Prozess des Hinzufügens von Kontext zu einem Log, z. B. Asset-Metadaten oder Nutzeridentität, was kurz nach der ersten Aufnahme erfolgen kann.

Planung von Regelausführungen

Google SecOps ermittelt die verfügbaren Planungsoptionen automatisch anhand Ihrer Regel-Logik. Im Menü Zeitplan für Ausführung werden nur Optionen angezeigt, die mit Ihrem jeweiligen Regeltyp kompatibel sind (z. B. Einzelereignis- oder Mehrere-Ereignisse-Regel).

Standardkonfiguration für den Zeitplan

Das System wertet Ereignisse nach ihrem Eintreffen anhand des folgenden Zeitplans aus. Durch diese Verzögerung wird die Datenvollständigkeit sichergestellt und die Latenz bei der Aufnahme oder Anreicherung berücksichtigt.

Zeitplan Zuweisungskriterien Zeitpunkt der Bewertung Abstimmungszyklen
Echtzeit (10 Minuten) Einzelnes Ereignis oder Spiel mit einem Zeitfenster von weniger als 1 Stunde Kurz nach der Ankunft Nein: Bei der Standardausführung werden verspätete/angereicherte Daten berücksichtigt.
Stündlich (1 Std.) Zeitfenster für den Abgleich zwischen 1 und 48 Stunden 1 bis 2 Stunden nach der Ankunft Ja. Enthält 5-Stunden- und 24-Stunden-Etappen.
Täglich (24 Stunden) Zeitfenster für Abgleich > 48 Stunden 24 bis 25 Stunden nach der Ankunft Ja. Enthält 5-Stunden- und 24-Stunden-Etappen.

Weitere Informationen zum Konfigurieren benutzerdefinierter Zeitpläne für Regeln

Automatische Abgleichsphasen

Um zu verhindern, dass Erkennungen aufgrund von Verzögerungen bei der Aufnahme oder einer späten Anreicherung verpasst werden, führt das System automatisch „True-up“-Läufe für Regeln mit mehreren Ereignissen durch:

  1. Erster Lauf: Wird so schnell wie möglich ausgeführt, um unmittelbare Bedrohungen aufzudecken.
  2. Zwischenlauf (ca. 5 Stunden): Etwa fünf Stunden nach dem Ereignis findet ein zusätzlicher Lauf statt. Hinweis: In dieser Phase wird nicht auf die vollständige Datenanreicherung gewartet.
  3. Endgültiger Abgleich (ca. 24 Stunden): Wird ausgeführt, sobald alle zusätzlichen Daten und die Anreicherung bestätigt wurden (100% Sichtbarkeit).

Hinweis:Bei Regeln für einzelne Ereignisse werden verspätet eingehende und angereicherte Daten während der Standardausführung verarbeitet. Es werden keine Abgleichszyklen von 5 Stunden und 24 Stunden verwendet.

Laufzeitplan ändern

So ändern Sie, wie oft das System Ihre benutzerdefinierte Erkennungslogik auswertet:

  1. Rufen Sie in Google SecOps Detection > Rules & Detections auf.
  2. Klicken Sie auf Regel-Dashboard.
  3. Öffnen Sie das Dreipunkt-Menü more_vert für Ihre Regel.
  4. Wählen Sie im Menü einen Wert für Laufzeit aus (z. B. 10 Minuten).
  5. Klicken Sie auf Speichern. Ihre Änderungen werden automatisch gespeichert.

Erkennungen identifizieren

Sobald eine Regel aktiv ist, können Sie zwischen ursprünglichen Benachrichtigungen und solchen unterscheiden, die durch die automatischen Wiederholungen des Systems generiert werden.

  1. Rufen Sie die Seite Warnmeldungen oder das Regel-Dashboard auf.
  2. Klicken Sie in der Spalte Detection Type (Erkennungstyp) auf Glühbirne , um zu sehen, ob die Erkennung aus einem ersten Lauf, einem Abgleichslauf oder einer Retrohunt stammt.

Fehlerbehebung

Sehen Sie sich die Dimensionen Ihrer Daten an, um herauszufinden, warum bestimmte Erkennungen angezeigt werden oder sich im Laufe der Zeit ändern. Die meisten Bedrohungen werden vom System sofort erkannt. Für eine vollständige Genauigkeit ist jedoch eine Hintergrundverarbeitung bestimmter Datennuancen erforderlich. Wenn Sie diese Hintergrundläufe verstehen, können Sie die mittlere Zieldiagnosezeit (Mean Time to Detection, MTTD) genau messen und die Integrität Ihrer Benachrichtigungen überprüfen.

Latenz und Limits

Die Häufigkeit der Regelausführung wirkt sich direkt auf die Geschwindigkeit der Erkennung aus. Bei weniger häufigen Zeitplänen verlängert sich die Zeit zwischen dem Eintreten eines Ereignisses und der Verarbeitung einer Erkennung durch das System.

  • Stündliche Zeitpläne: Diese werden stündlich mit den neuesten verfügbaren Daten ausgeführt. Es wird kein Puffer angewendet.

  • Tägliche Zeitpläne: Das System führt einen 24-Stunden-Puffer ein, um eine vollständige Datenaufnahme vor der Verarbeitung zu gewährleisten.

Abweichungen zwischen Läufen

Beim ersten Ausführen einer Regel wird möglicherweise keine Erkennung identifiziert, die später bei einer Abgleichsausführung angezeigt wird. So kann das System die meisten Bedrohungen sofort erkennen und später eine Bestätigung mit hoher Genauigkeit ermöglichen. Das kann folgende Gründe haben:

  • Latenz bei der Datenaufnahme:Logdaten, die nach Abschluss des ersten Laufs eingehen.
  • Vollständigkeit der Anreicherung:Der Kontext aus externen Quellen (Asset-Metadaten oder Identitäten) wird während des ersten Laufs noch verarbeitet.
  • Zeitliche Anpassungen:Bei True-up-Läufen wird gewartet, bis der vollständigste Datensatz verfügbar ist, bevor sie ausgeführt werden. Erkennungen im ersten Lauf können später als erwartet eintreffen.

Fehlerbehebung

Mithilfe dieser Tabelle können Sie häufige Probleme mit fehlenden Anpassungsoptionen oder eingeschränkten Zeitplänen beheben.

Problem Ursache und Korrektur
Fehlende Optionen für benutzerdefinierte Zeitpläne Einzelereignisregeln verwenden die Echtzeit-Engine und unterstützen keine geplanten Intervalle. Außerdem folgen kuratierte Regeln festen Systemzeitplänen, die Sie nicht ändern können.
Nicht unterstützte Intervalle Wenn Sie Nahezu in Echtzeit nicht auswählen können, wird in Ihrer Regel wahrscheinlich ein match-Abschnitt oder Aggregationen wie count oder sum verwendet. Für diese Funktionen sind geplante Intervalle erforderlich, um Daten im Zeitverlauf zu verarbeiten.

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