Device Stopped Sending Events
Der Zweck dieses Artikels ist es, eine praktikable und brauchbarere Alternative des DSSE-Tests zu beschreiben, die:
- Beheben Sie das Problem, dass der ursprüngliche DSSE-Test unnötigerweise ausgelöst wird, wenn eine Einheit in einer paarweise verbundenen Einheitengruppe (aktiv/gesichert) nicht mehr reagiert.
- Aktivieren Sie die typischen "CRE-isms" von Aktionen und Antworten, die über den ursprünglichen DSSE-Test nicht mehr verfügbar sind.
Einführung
In QRadar ®arbeitet die Custom Rules Engine (CRE) am Vorhandensein von Ereignissen, indem sie sie verarbeitet und anschließend mit definierten Regeln vergleicht. Im Hintergrund der CRE wird ein weiterer Test ausgeführt, der als DSSE-Test (Device Stopped Sending Events) bezeichnet wird. Im Gegensatz zur CRE wird die DSSE beim Fehlen von Ereignissen ausgeführt. Dies führt zu einem Konflikt, da viele der typischen "CRE-isms" (Lesen: Aktionen, Antworten, andere Tests und Filter in derselben Regel) nicht verfügbar sind und nicht ordnungsgemäß aufgerufen werden. Außerdem erkennt die DSSE-Regel (im folgenden Diagramm dargestellt) ein Problem, wenn ein bestimmter Einheitentyp in einer Einheitengruppe oder Einheitenliste nicht mehr sendet.
Abb. 1. DSSE-Regel (Gerät hat Senden von Ereignissen gestoppt)
Lösung
Diese Lösung ersetzt die drei ursprünglichen Tests (im vorherigen Screenshot dargestellt) durch zwei generische Regeln, die als Tracker-Regel und Watcher-Regel bezeichnet werden. Mit diesen Regeln werden zwei separate Referenzdatencontainer getestet und mit Daten gefüllt. Die Trackerregel folgt den Ereignisdaten, die in Referenzsets eingegeben werden. Wenn der Referenzseteintrag abläuft, werden ihm keine Ereignisse mehr zugeordnet und die Watcher-Regel wird ausgelöst.
Beachten Sie, dass ein Referenzset eine Sammlung von Daten ist, die einen eindeutigen Schlüssel mehreren Werten zuordnen. Legt einen Vergleich eines Eigenschaftswerts mit einer Liste fest, um den zugehörigen Schlüssel zu ermitteln. Eine Referenzzuordnung ist eine Sammlung von Daten, die einen eindeutigen Schlüssel einem Wert zuordnen. Sie werden verwendet, um eine eindeutige Kombination aus zwei Eigenschaftswerten zu überprüfen. Um beispielsweise die Benutzeraktivität in Ihrem Netz mit einer LoginIDzu korrelieren.
Regel #1 -Trackerregel
Eine Trackerregel verfolgt Ereignisse, die durch das System kommen. Wenn eine Protokollquellen-ID in der Referenzzuordnung SystemsToWatch vorhanden ist, wird der Wert in das Referenzset ActiveSystemsSending gestellt.
Abbildung 2. Tracker-Regel in QRadar-Netzdiagramm Console
Anschließend wird dem Wert ein Antwortbegrenzer zugeordnet. Dieser Antwortbegrenzer ist viel kleiner als die Lebensdauer des Referenzsets und wird in der Protokollquelle indexiert.
Abb. 3 Regelantwortauswahl für Trackerregel.
Regel #2 -Watcher-Regel
Eine Watcher-Regel überwacht das System. Solange das System seit dem Start mindestens ein Ereignis aus der Protokollquelle erkennt, werden Werte im Referenzset eingetragen.
Abbildung 4. Watcher-Regel in QRadar-Netzdiagramm Console
Sobald dieser Referenzseteintrag abläuft, bedeutet dies, dass alle Protokollquellen, die an den eindeutigen Namen in der Referenzzuordnung gebunden sind, keine Ereignisse mehr senden. In diesem Fall wird ein Angriff basierend auf diesem eindeutigen Namen generiert und indexiert.
Abbildung 5. Regelantwortauswahl für Watcher-Regel.
Der Protokollquellenname, der in dieser Prozedur erwähnt wird, ist ElementExpiredReference und wird wie folgt konfiguriert:
Abbildung 6. Eigenschaftsdefinition in QRadar-Netzdiagramm Console.