Kronjuwelen Szenario #1

In diesem Live-Lab Beispiel heute, geht es um das Zusammenspiel zwischen SIEM360 Security (Detection) und Security SOAR (Response). Es geht um eine Möglichkeit, bei dem automatisiert eine QRadar Offense zum Security SOAR System weitergeleitet wird.

Um das zu realisieren, wird im QRadar System ein Plugin etabliert, welches diese Verbindung zum SOAR System herstellt. Dieses Plugin bietet dazu zwei Optionen an:

Manuelle Escalation

• Manuelle Weitergabe über Schaltflächen einer QRadar Offense direkt aus dem Offense Panel

Automatisierte Escalation

• Automatisierte Weitergabe einer QRadar Offense anhand voreingestellten Regelbedingungen und Template-Einstellungen

Activity Feed

Im SOAR System wird aus der „weitergeleiteten“ QRadar Offense automatisch ein „neuer Vorfall“ angelegt und bereits gesammelte Informationen aus der QRadar Offense übernommen. Soweit so gut.

SIEM Anwendungsbeispiel - Kontext

Jetzt aber erst noch ein wenig Kontext zum SIEM Anwendungsbeispiel. Um was geht es dabei genau?

Es geht um ein typisches Szenario, bei dem in einem Kollaboration System (Notes / Domino) privilegierte Admin-Rechte aktiviert werden können. Mit diesen „Full Administration Access Rights“ wird die Sicherheitsebene der „Access Control List“ in Domino Datenbanken umgangen.

Dieser Administrator hat nach dem Aktivieren mit diesem erweiterten Recht die Möglichkeit, auf Datensätze und Informationen in Datenbanken zuzugreifen, ohne selbst dabei in der jeweiligen Zugriffsliste der Datenbank enthalten zu sein!  Soviel zur technischen Detailtiefe dieses Überwachungs-Szenarios.

Domino Administrator - Full Access Rights

Diese “Rechte-Erweiterung” ist für Domino Administratoren ein sehr hilfreiches Feature, wenn es um Troubleshooting oder Datenbank-Migrationen geht, wo Einstellungen der Datenbank Zugriffsliste „Probleme“ bereiten oder aus Sicherheitsgründen „zu recht“ anschlagen.

Diese erweiterten Rechte ermöglichen damit aber zugleich, dass nicht authorisierte Zugriffe auf sensible Datensätze und Datenbanken „unbemerkt“ stattfinden können. Administratoren, die diese Erweiterung aktivieren dürfen, können somit Datensätze/Datenbanken „unbemerkt verarbeiten“. Und damit ein möglicher Compliance/Policy Verstoß!

Kronjuwelen Container - Domino

Aus diesem Grund ist es eine gute Entscheidung, die Aktivierung dieser erweiterten „Full Administration Access Rights“ in jeder Domino Infrastruktur zu überwachen / auditieren!

Einer der Mehrwerte einer Domino Plattform ist „Rapid Applikation Development“. Einige erinnern sich vielleicht noch :)

Was bedeutet das? Mit relativ einfach zu nutzenden Boardmitteln, @Formel- und Scriptsprache können schnell und einfach Anwendungen oder Workflows für Abteilungen oder Geschäftsprozesse bereitgestellt werden. 

Domino - Historie

Dazu werden unstrukturierte Datensätze über Masken erzeugt, sicher in einem .nsf Container (Notes Storage File) gespeichert und abgelegt. Durch unterschiedliche Ansichten wird auf diese Datensätze innerhalb des nsf-Container zugegriffen, bzw. die Datensätze über Select-Statements aufbereitet und präsentiert. 

Und die interne PKI Struktur und Zugriffskontrolle bis auf Feldebene ermöglicht, diese Datensätze flexibel für Zugriffe zu schützen, beziehungsweise zu steuern.

Durch diesen Technologie-Ansatz sind unzählige Datenbanken in Domino-Umgebung entstanden, in denen auch sicherlich viele der sogenannten „Kronjuwelen“ gespeichert sind.

Erkennen - Full-Access-Administrator Events

Und genau darum geht es in diesem spezifischen SIEM-Szenario. 

Wird im Domino System diese erweiterte „Full-Access-Administration-Funktion“ aktiviert, wird dieser spezifische Event im Domino System erzeugt und per SNMP-Trap an das zentrale SIEM System weitergeleitet. 

Custom Regel - DominoFullAccess Event erkennen

Sobald vom SIEM dieser Event in der zentralen Regelüberwachung (Custom Rule Engine) erkannt wird, wird automatisch eine Offense erzeugt. Für die Erkennung dieses skizzierten Szenario wurde von mir eine spezifische Custom-Regel im SIEM erstellt und bereitgestellt. 

Regel Response - Auth.Privilege Escalation Kategorie

Diese aus der Regelerkennung erzeugte Offense bekommt in diesem Szenario auch eine entsprechende “Offense Kategorie” automatisch zugewiesen.

Offense Benachrichtigung

Die Besonderheit hier ist, dass der Betreff für diese E-Mail im SIEM E-Mail-Template modifiziert wurde und zusätzlich ein Prefix „P4B-SecMngt“ eingefügt wird. 

Diese Kategorie (Einordnung in Cyber Kill Chain) sorgt im Prozess der Erkennung dafür, dass eine eine priorisierte Offense Benachrichtigung erzeugt und an eine eigens dafür hinterlegte E-Mailadresse geschickt wird.

Offense Benachrichtigung - E-Mail

Dieser Prefix wird dann typischerweise in einem IT-Service-Management Tool genutzt, um ein internes Service-Ticket zu erzeugen.

Detection - IOCs / Respond

Im vorliegenden Beispiel wird diese E-Mailadresse vom internen SOC Team verwendet. Im ersten Schritt wird die Offense innerhalb des SIEM von einem SOC Team-Mitglied analysiert und einem internen Bearbeiter manuell zugewiesen.

Diese Zuweisung ist der Trigger für das Security SOAR Plugin und leitet diese QRadar Offense an das SOAR System weiter. 

Respond / SOAR Playbook

Das ist eine Möglichkeit, wie aus dem SIEM QRadar eine Offense automatisiert zum SOAR System weitergeleitet werden kann und der IT-Service-Management Prozess und eine Remediation angestoßen werden kann.

Nach der Phase der Erkennung geht es mit der weiteren Analyse, der Verwaltung und strukturierten Bearbeitung des erkannten „nun“ Vorfalls im SOAR System weiter. Dazu können manuell oder automatisiert sogenannte “Playbooks” erstellt und hinterlegt werden.

Dynamischer Schlachtplan / Automated Response

Diese Playbooks liefern dann Methoden, Aktionen, Prozeduren und ergänzende Werkzeuge, diesen Vorfall strukturiert abzuarbeiten. Kurz: einen dynamischen Schlachtplan zur Gegenmaßnahme. 

Zusätzlich helfen die Dokumentation der Schritte zur Lösung des Vorfalls, das IT-Security-Management nachhaltig, belastbar und widerstandsfähiger zu machen.

SIEM - Langzeit Kampagne

Erfahrungsgemäß ist SIEM eher eine Langzeit-Kampagne. Werden die genannten Faktoren regelmäßigen Reviews unterzogen und durch neu gewonnene Erkenntnisse ergänzt, erhöht sich automatisch der Reifegrad des SIEM-Prozesses. 

Ein zusätzliches Ergebnis bei der Entwicklung des SIEM Reifegrads sind KPIs, die genutzt werden können, um Trends und weiteres Optimierungspotential aufzuzeigen.

Cyberdefense automatisiert / Paradigmenwechsel

Eventuell habe ich bisher etwas übersehen, aber aus meiner Erfahrung gilt es folgende organisatorische Faktoren im gesamten SIEM-Prozess zu überwachen:

• warum machen wir was wir machen?
• was ist die Mission?
• „Silos“ abteilungsübergreifend verbinden - kennen alle beteiligten Personen die Mission? 
• Welche Geschäftsprozesse sind von besonderer Bedeutung für das Unternehmen?
• IT Systeme identifizieren, welche zu diesen Geschäftsprozessen gehören. 
• Paradigmenwechsel: Mindset von Compliance (manuell und reaktiv) zu Risiko-Management (automatisiert und proaktiv) entwickeln
• Regelmäßige Feedbacks und Anpassungen im SIEM-Prozess