Fortsetzung   In Outlook sieht das dann z.B so aus:

Damit könnte man zufrieden sein, aber…

Das Problem ist der Betreff in der Email: er enthält lediglich den Namen der auslösenden Regel, in unserem Beispiel

Im Inhalt der Email sind zwar alle notwendigen Angaben enthalten. Bei der automatischen Verarbeitung der Regel ist dies jedoch wenig hilfreich. Daher sollte der Betreff („Subject“) angepasst werden, um in einem nachgelagerten Service Management System automatisch ein Ticket zu eröffnen.

Nun auch dafür gibt es eine Lösung die hier dokumentiert ist:

Damit könnte man wiederum zufrieden sein, aber für viele fängt das Problem erst richtig an, wie der Auszug aus der Community zeigt.

Was also tun? Nun da hilft unser QRadar Email Playbook!

Zunächst einmal: es gibt grundsätzlich zwei Möglichkeiten auf einen Alarm („offense“) zu reagieren:
Erstens auf ein unmittelbares Ereignis, hier dargestellt als ID=78 für die Regel SSH Login. Zweitens als nachträgliche Bewertung aufgetretener Alarme, hier dargestellt als ID= 79-81 als Test für die Regel IT-SECMGMT. Im Überblick sieht das so aus:

Sobald das Email Template erfolgreich um die eigene Definitionen erweitert wurde, lässt es sich den Regeln als „Response“ zuordnen (My Event bzw. My Offense)

Hier die Zuordnung im "Rule Wizard":

Die Regel vom Typ Offense entspricht der Standardregel für Email Benachrichtigung und wurde lediglich zu Testzwecken angepasst! Bitte die oben gezeigten Standardwerte bei severity, credibility und relevance für Produktion übernehmen! Der response limiter sollte den eigenen Bedürfnissen beim Workflow im SOC angepasst werden.

Jetzt wird es richtig spannend, den wir begeben uns in die Tiefen der Programmierung! In der Anleitung steht wo wir unser Template finden und wie wir es verändern können. Für unsere Zwecke reicht die Anpassung des Subjects im Email Typ für Offense und Event Rules. Hier ist ein guter Editor wie XMLmind sinnvoll, um Fehler bereits beim Editieren zu erkennen. Type Offense:

Type Event:

Das überarbeitete Email Template muss jetzt ausgerollt werden. Dazu benötigen wir einen zweistufigen Prozess. Der erste Schritt ist die Übertragung in den Staging Bereich.

der zweite Schritt ist Deploy in unserem System:

vor dem Test sollten alle Offenses geschlossen werden!
Emails können einfach im CLI (Command Line Interface) kontrolliert werden.

Zum Testen benutzen wir Simulationsdaten, die wir aus dem eigenen SIEM als CSV exportiert haben. Die SSH Logins Event Regel reagiert direkt. Die Offense Typ Regel etwas zeitverzögert je nach Response Filter Einstellung. Das mail Kommando zeigt die an root@localhost gesandten Emails an:

Hier die beiden Email Ergebnisse für ID=78 (Ruletype = Event) und ID=81 (Ruletype=Offense):

Ruletype = Offense:

Download alert-config.xml von hier https://my.hidrive.com/share/zi.b3vy1o9

Viel Spaß beim Blättern in der "Mehlbox"!