Zunehmend treten neben rein finanziell motivierte Angreifer auch staatliche Akteure, die Schwachstellen ausnutzen, um Lieferketten zu sabotieren oder Informationen zu erbeuten. Bedrohungen werden entsprechend nicht nur zahlreicher, sondern auch komplexer und vielfältiger. Administratoren stehen nun vor der Herausforderung, dieser verschärften Bedrohungslage zu begegnen.

Ein erster Schritt besteht üblicherweise im Aufbau eines Systems für das Security Information and Event Management (SIEM), also einer Plattform, die sämtliche Ereignisse innerhalb einer Infrastruktur sammelt, korreliert und kategorisiert, um in Echtzeit potenzielle Bedrohungen zu erkennen. Unternehmen, die ein eigenes Security Operations Center (SOC) betreiben, sind hier im Vorteil. Doch viele Firmen können sich diesen Luxus nicht leisten oder finden keine Spezialisten, denn der Markt für SOC-Analysten ist leer gefegt.

Daher bringen sich zunehmend Angebote unter dem Begriff der Security Orchestration, Automation, and Response (SOAR) in Stellung. Deren Ziel ist es, die knappen Personalressourcen möglichst von manuellen Aufgaben zu befreien, indem sie Sicherheitsoperationen orchestrieren, wiederkehrende Aufgaben automatisieren und auf Sicherheitsvorfälle strukturiert und koordiniert reagieren. An dieser Stelle kommt nun Splunk ins Spiel.

Der Softwareanbieter, der inzwischen zu Cisco gehört, hat sich mit seiner gleichnamigen Plattform für Logging, Monitoring und Reporting auf die Analyse großer Mengen unstrukturierter Daten spezialisiert. Splunk Enterprise Security (ES) basiert auf dieser Plattform und adressiert als klassisches SIEM-System die Überwachung, Erkennung und Analyse von sicherheitsrelevanten Ereignissen. Als separates Produkt hat der Hersteller darüber hinaus Splunk SOAR im Angebot. Ursprünglich trug die Software den Namen Splunk Phantom, nach dessen früherem Anbieter Phantom Cyber, den Splunk im Jahr 2018 übernommen hatte. Der Begriff Phantom findet sich auch heute noch unter der Haube und an diversen Stellen der Onlinedokumentation. Optionale Apps sorgen auf Wunsche dafür, Daten aus Splunk Enterprise, der Splunk Cloud Platform oder auch aus den Systemen von Drittanbietern in eine SOAR-Instanz einzufügen und die Produkte herstellerunabhängig zu integrieren.

Der Hersteller betreibt Splunk SOAR (Cloud) als SaaS-Angebot und bietet alternativ Splunk SOAR (on-premises) zur in begrenztem Umfang kostenfreien Nutzung im eigenen Rechenzentrum an. Standardmäßig startet Splunk SOAR (on-premises) nach der Installation mit der integrierten Community-License. Diese ermöglicht das Kennenlernen der Umgebung und auch den produktiven Betrieb in einem Tenant mit 100 Aktionen pro Tag sowie maximal fünf Events in den Bearbeitungsstatus "New" oder "Open".

Wer diese Grenzen überwinden möchte, benötigt kostenpflichtige Lizenzen pro namentlich benanntem Benutzer. Beim Kauf als Einzelprodukt orientiert sich das Tarifmodell von Splunk SOAR an der Userzahl, also an der Anzahl der Konten in SOAR oder der Analystenarbeitsplätze. Jeder Benutzer, der sich an SOAR anmelden möchte, benötigt eine solche Lizenz. Dies gilt sowohl für lokale Konten innerhalb von SOAR als auch für Anwender, die sich per LDAP oder SAML2 über einen externen Identitätsprovider anmelden.

Splunk unterstützt die Installation von SOAR auf eigener Hardware sowie in einer eigenen Virtualisierungsinfrastruktur oder mit derselben Setuproutine alternativ auch in einer AWS-EC2-Instanz. Hierbei kommen Amazon Linux 2, Red Hat Enterprise Linux (RHEL) oder Oracle Linux infrage. Mit dem Schritt von Splunk SOAR 6.2.2 zu 6.3.0 hatte der Hersteller den Wechsel von CentOS zu Oracle Linux vollzogen, das sich nach dem Ende des Lebenszyklus von CentOS 7 als vollständig binär-kompatible Alternative zu RHEL empfiehlt.

Für den Zugriff auf das Webinterface eignen sich die aktuellen Browser Apple Safari, Google Chrome, Microsoft Edge oder Mozilla Firefox. Im Fall von RHEL unterstützt Splunk die älteren Versionen von 7.6 bis 7.9 sowie den aktuellen Entwicklungszweig der Hauptversionsnummer 8 und hier die jeweils aktuelle Nebenversionsnummer zum Erscheinen der Version von SOAR, für die vorliegende Version 6.3 von SOAR also RHEL 8.10.

Im Hinblick auf die Ressourcen zeigt sich SOAR genügsam. Für eine Testumgebung reichen bereits ein Prozessor mit vier Kernen sowie mindestens 8 GByte Hauptspeicher und 500 GByte Massenspeicher. Im produktiven Einsatz rät der Hersteller zu mindestens 16 bis 32 GByte Hauptspeicher sowie je 500 GByte Massenspeicher für das Basisverzeichnis und das Datenverzeichnis mitsamt der benötigten PostgreSQL-Datenbank. Splunk verweist darauf, dass der tatsächliche Speicherbedarf variiert und vom Umfang der Nutzung abhängt.

Im einfachsten Fall integriert die Installation im Kontext eines unprivilegierten Benutzerkontos alle zum Betrieb nötigen Komponenten. Alternativ unterstützt Splunk auch einen oder mehrere extern bereitgestellte Dienste, wie einen separaten PostgreSQL-Server, GlusterFS-Dateifreigaben und HAProxy zur Lastverteilung. Diese Komponenten bilden zusammen mit dem Message-Broker RabbitMQ und dem Netzwerkdienst Consul auch die Basis für den Betrieb als Cluster. Ein solcher benötigt neben den unterstützenden externen Diensten mindestens drei Instanzen von Splunk SOAR.

In größeren oder verteilten Umgebungen bindet der optionale Splunk Automation Broker weitere Systeme in separierten Netzen oder an entfernten Standorten an. Der Automation Broker benötigt keine eingehend offenen Ports, sondern nimmt seinerseits Verbindung zu Splunk SOAR auf. Ebenso optional ist die Anbindung der Splunk Mobile App, die aber laut Online-Dokumentation derzeit nur auf iOS-Geräten sowie ohne Zwei-Faktor-Authentifizierung funktioniert.

Im Rahmen unseres Tests haben wir auf externe Dienste, Clustering sowie die mobile App verzichtet und stattdessen eine einzelne virtuelle Maschine auf Basis von Oracle Linux 8.10 eingesetzt. Diese hatten wir entsprechend der Online-Dokumentation für die Installation von Splunk SOAR (on-premises) als unprivilegierter Benutzer vorbereitet.

Nachdem wir uns auf der Webseite von Splunk für ein kostenfreies Benutzerkonto registriert hatten, konnten wir im Downloadbereich ebenso kostenfrei das TAR-Archiv zur Installation herunterladen. Die Webseite lieferte uns dazu ein wget-Kommando, mit dem wir die Datei direkt auf unser Linux-System beförderten und extrahierten.

Vor der eigentlichen Installation führten wir das mitgelieferte Skript zur Vorbereitung aus, das sich um sämtliche nötigen Voraussetzungen kümmerte und dazu die von SOAR benötigen RPM-Pakete installierte, Dienste konfigurierte sowie den unprivilegierten Benutzer "phantom" einrichtete. In dessen Kontext führten wir schließlich das Skript zur Installation aus, das die Software in wenigen Minuten aufsetzte. Daraufhin konnten wir uns bereits per Browser mit dem Webinterface verbinden und uns mit dem integrierten Admin "soar_local_admin" und dem initialen Passwort "password" anmelden. Über den Benutzernamen rechts oben im Bild erreichten wir die Einstellungen des Accounts und änderten dessen Passwort.

Das Webinterface begrüßte uns mit dem Dashboard und zeigte zuoberst Werte zum Return on Invest (ROI). Hierfür errechnet die Software anhand gelöster Ereignisse und deren teilweise oder vollständig automatisierter Bearbeitung die potenziell von manueller Arbeit befreiten Vollzeitstellen (Full Time Equivalent, FTE) und die Ersparnis an Zeit und Geld.

Diese Parameter basieren auf in den Systemeinstellungen hinterlegten Werten für das Jahresgehalt eines Sicherheitsanalysten, den Arbeitsstunden pro Tag und einer durchschnittlichen Angabe in Minuten für die Dauer einer jeden Aktion, die ein Analyst im Tagesgeschäft durchführt. Wir erreichten die Parameter über das Dropdown-Menü oben links auf der Seite im Bereich "Administration / Company Settings / Dashboard".

Es kann sich beim ROI nur um eine grobe Abschätzung handeln, entsprechend konnten wir neben der Anpassung der Basiswerte die Anzeige der potenziellen Ersparnis im Dashboard hier auch komplett abschalten. Das Dashboard zeigt dann nur noch die gelösten Ereignisse mit ihrer Bearbeitungszeit und darunter in mehreren konfigurierbaren Widgets Daten zum aktuellen Zustand der Umgebung. Dies betrifft etwa die offenen Ereignisse mit ihrem Schweregrad, den Status der Verbindung zu angeschlossenen Systemen, statistische Daten zu eingehenden Daten sowie ausgeführten Playbooks und Aktionen. Dazu mussten wir das System jedoch erst einmal mit Leben füllen.

Zuvor navigierten wir zum Bereich "Administration / Company Settings / User Management", wo wir unter "Users" weitere lokale Konten anlegen und unter "Authentication" auch externe Quellen einbinden konnten. SOAR bringt hier die Provider LDAP und SAML2 mit. Über ersteren koppelten wir komplikationslos unser lokales AD. Die Lösung unterstützt dabei individuelle Distinguished Names (DN) als Suchbasis für Benutzer und Gruppen, ebenso automatisches Mapping von Gruppenzugehörigkeiten im AD auf Rollen sowie von externen Attributen auf Benutzerattribute innerhalb von SOAR.

Im Bereich "Roles & Permissions" bringt SOAR diverse vorgefertigte Rollen mit abgestuften Rechten für die Arbeit im System mit sowie auch die Möglichkeit, eigene Rollen zu konfigurieren. Grundsätzlich dürfen Benutzer im Rahmen ihrer jeweiligen Rolle jede verfügbare Aktion auf jedem Asset ausführen. Die granulare Kontrolle, die wir bei den "Asset Permissions" aktivieren konnten, erlaubt die Vergabe von Berechtigungen bis herunter auf einzelne Aktionen.

Auf übergeordneter Ebene erlaubt der Schalter unter "Administration / Product Settings / Multi-Tenancy", eine passende Lizenz vorausgesetzt, die Verwaltung mehrerer Kundenumgebungen in einer SOAR-Instanz. Die Software ist damit auch großen Umgebungen mit verteilten Zuständigkeiten gewachsen. Im Rahmen unseres Tests beließen wir es aber bei einfachen Berechtigungen und gestatteten unseren Benutzerkonten Zugriff auf alle Aktionen und Assets, die wir nun konfigurierten.

Genau wie Splunk ES lebt auch SOAR von einem umfangreichen Ökosystem an Apps, die sich um ein- und ausgehende Daten sowie grundsätzlich um alle Interaktionen mit anderen Systemen kümmern (Bild 1). Die Apps finden sich im hauseigenen Verzeichnis "Splunkbase" sowie auf der Plattform GitHub. Unter der Haube handelt es sich bei einer App um ein Python-Modul, das das API eines anderen Systems anspricht.

Derzeit finden sich über 350 Apps in der Splunkbase, mehrheitlich vom Anbieter selbst entwickelt und unterstützt, teils aber auch von der SOAR-Community beigesteuert. Wer Kenntnisse in Python 3 mitbringt, kann sich zudem an die Entwicklung eigener Apps begeben. Das ist jedoch nicht zwingend nötig, da die Apps bereits zahlreiche Hersteller und Anwendungsfälle abdecken, um etwa per HTTPS, SSH, SMTP, LDAP oder auch Windows Remote Management mit anderen Systemen zu interagieren.

Daten finden ihren Weg in SOAR per Push oder Pull. So bringt Splunk ES eine App mit, die Events nach konfigurierbaren Regeln vorfiltert und per Push an SOAR schickt. Umgekehrt liest SOAR per Pull Daten aus den Systemen von Drittanbietern wie etwa Elasticsearch ein, importiert CSV-Dateien, parst PDFs, E-Mails und Textdateien. Das System erfasst die Rohdaten und überführt sie ins Common Event Format (CEF).

Unter der Haube behandelt SOAR dazu jedes Ereignis als Container mit einem Label. Ein Container ist ein strukturiertes JSON-Objekt mit einem Label, das beliebige weitere JSON-Objekte enthalten kann, die SOAR als Artefakte bezeichnet. So versieht das System etwa aus einem SIEM importierte Meldungen zu verdächtigen Benutzeraktivitäten oder Webadressen mit dem Label "Incident". Ein solcher Container beinhaltet als Artefakt den Namen eines betroffenen Benutzers oder auch einen zu untersuchenden URL.

Zentraler Arbeitsbereich für einen Analysten ist die Übersicht der Events (Bild 2). Zur Einstufung von Ereignissen verwendet SOAR den Schweregrad mit den Stufen "informational", "low", "medium" und "high" sowie die Sensitivität der enthaltenen Informationen nach dem Traffic Light Protocol (TLP). Jedes Event zeigt in seiner Detailansicht die enthaltenen Artefakte sowie eine Zeitleiste mit einer Übersicht aller automatisierten oder von Analysten durchgeführten Vorgänge. Hierbei kann es sich um eine einzelne Aktion oder um ein Playbook, also eine komplexe Abfolge von Aktionen, handeln. Die Basis für beides bilden wiederum Apps.

Exemplarisch sei genannt, dass Apps etwa lokale Benutzerkonten wie auch in Azure oder AWS sperren und entsperren sowie verdächtige IP-Adressen, URLs oder E-Mail-Anhänge zur weiteren Untersuchung an Dienste wie VirusTotal und PhishTank übergeben. Apps steuern weiterhin Firewallsysteme und Netzwerkkomponenten verschiedener Hersteller sowie VMs in einer lokalen VMware-Infrastruktur in AWS EC2 oder Azure. Eine konkrete Konfiguration einer solchen App, also etwa die Verbindung zu einem AD, zu VMware, zu einer Cloudumgebung, einer Firewall oder auch zu einem Mailserver bezeichnet SOAR als Asset. Diese bilden in Verbindung mit den Apps und Playbooks das Rückgrat für die Orchestrierung und Automatisierung.

Für die Arbeit mit Playbooks bringt SOAR einen integrierten grafischen Editor als Low-Code-Lösung mit. Grundlegende Kenntnisse von JSON-Strukturen und Python sind nicht zwingend erforderlich, für komplexe Abläufe aber nützlich. Über 100 vorgefertigte Playbooks aus dem Community-Repository helfen beim Einstieg. Diese Playbooks konnten wir in unser lokales System kopieren und als Vorlage für eigene Playbooks für eigene Abläufe verwenden. So gelangten wir auch ohne Vorwissen nach kurzer Einarbeitungszeit zu praktischen Automatisierungen.

Hierzu haben wir mit dem integrierten Visual Playbook Editor exemplarisch Drehbücher entworfen, mit denen wir die Behandlung verdächtiger URLs und Benutzeraktivitäten ganz oder teilweise automatisieren wollten. Dazu begaben wir uns aber zunächst in den Bereich der Apps. Hier brachte SOAR von Haus aus bereits Apps von Splunk zum generischen Import von Ereignissen und Artefakten über REST-APIs, weiterhin für DNS- und Whois-Abfragen mit.

Zudem waren bereits Apps für die Dienste MaxMind und PhishTank an Bord. Ersterer bietet die Geolokation übergebener IP-Adressen, Letzterer eine Überprüfung der Reputation von URLs. Zusätzlich konfigurierten wir hier die von Splunk angebotenen Apps "AD LDAP" zur Integration in unseren lokalen Verzeichnisdienst, "SMTP" für den Versand von E-Mails sowie die App für eine "Palo Alto Networks Firewall". Zu jeder dieser Apps konfigurierten wir nun ein passendes Asset. Ein solches umfasst IP-Adresse oder Hostnamen eines Endpunkts in unserer Umgebung mitsamt den spezifischen Zugangsdaten zum Zugriff auf das jeweilige API.

So gerüstet machten wir uns im grafischen Editor an den Entwurf von Playbooks. Hier unterscheidet Splunk zwei Arten: Automations und Inputs. Letztere helfen dabei, oft benötigte Aktionen in wiederverwendbare Funktionen auszulagern und so umfangreiche Abläufe in kleinere Blöcke zu strukturieren. Nur "Automation"-Playbooks reagieren manuell oder automatisch getriggert unmittelbar auf Events und können dabei ihrerseits Playbooks vom Typ Input als Unterfunktion aufrufen.

Im Editor konnten wir bereits nach kurzer Einarbeitungszeit erste Abläufe automatisieren. Dazu mussten wir lediglich per Drag and Drop Bausteine aus dem linken Bereich der Ansicht auf die Arbeitsfläche ziehen. Dabei darf es sich um per App aufgerufene Aktionen, andere Playbooks, individuelle Codeblöcke sowie integrierte Werkzeuge von SOAR handeln. Zusätzlich kennt der Editor Filter, die nur auf ganz bestimmte Events reagieren, logische If-else-Entscheidungen, Formatierung von Daten oder auch Prompts, die Benutzer zur Interaktion auffordern.

Letztere erwiesen sich als besonders flexibel. So konnten wir auf diesem Weg alle Benutzer einer bestimmten Rolle oder auch einzelne Anwender innerhalb von SOAR zur Bearbeitung einer oder mehrerer Fragen direkt im Frontend von SOAR einbinden. Ferner konnten wir Unterstützung von anderen Benutzern außerhalb von SOAR anfragen, die keine Anmeldung am Webfrontend und somit auch keine Lizenz benötigen. Externen Usern teilt SOAR auf bis zu vier Kanälen mit, dass eine Frage auf ihre Antwort wartet, etwa per klassischer E-Mail oder mittels weiterer Apps auch per Benachrichtigung in Microsoft Teams oder Slack.

SOAR erzeugt dazu einen sicheren Link, optional mit SAML-Authentifizierung. Die Benutzer können die Fragen dann über eine separate Webseite beantworten. Die Software unterstützt verschiedene Typen von Antworten, Ja/Nein-Entscheidungen oder die Auswahl aus einem Wertebereich von 1 bis 100, einem benutzerdefinierten Wertbereich oder einer benutzerdefinierten Liste von Einträgen.

Diese Elemente nutzten wir exemplarisch, um die Reaktion auf Ereignisse zu automatisieren, die als Artefakt jeweils einen potenziell schädlichen URL enthielten. Unser Playbook liest dazu den URL aus dem Artefakt des Events ein und übergibt ihn in einer ersten Aktion an den Dienst PhishTank, um die Reputation zu prüfen. Abhängig vom Ergebnis behandelt eine Entscheidung das Event vollständig oder teilweise automatisch (Bild 3).

Meldet PhishTank den URL als bekannte Phishing-Seite, erhöht das Playbook den Schweregrad des Events per Utility auf "High", weist mit einer Aktion die Firewall an, den URL zu blockieren und schließt das Event automatisch. Meldet PhishTank die Seite dagegen als sicher, setzt das Playbook den Schweregrad auf "Low" und schließt das Event ohne weitere Aktion automatisch.

Kennt PhishTank den betreffenden URL nicht, setzt das Playbook den Schweregrad zunächst auf "Medium" und ein Prompt informiert per E-Mail externe Benutzer, die den URL manuell untersuchen und die Frage beantworten, ob es sich um Phishing handelt oder nicht. Je nach Rückmeldung blockiert SOAR anschließend wiederum automatisch den URL oder schließt das Event direkt. Einmal aktiviert, führte SOAR fortan dieses Playbook auf jedem neuen Event mit einem URL als Artefakt automatisch aus.

Auch bei der Bearbeitung aller potenziellen Vorfälle, die sich nicht ganz oder teilweise automatisieren lassen, bietet SOAR mit der Verwaltung von Events praktische Unterstützung. So dient die Ansicht der Events als Schaltzentrale, mit der ein oder mehrere Benutzer strukturiert an Ereignissen arbeiten. Dazu zeigt die Detailansicht eines jeden Events auf einer Zeitleiste sämtliche Vorgänge auf diesem Event (Bild 4). Benutzer können hier manuell einzelne Aktionen oder Playbooks starten, zusätzliche Informationen hinterlegen, sich gegenseitig Aufgaben zuweisen und den Status des Ereignisses ändern. Treten zahlreiche Events gleicher Art auf, fassen Cases diese zu einem Fall zusammen.

Darüber hinaus helfen Workbooks bei der strukturierten Bearbeitung. So konnten wir jedem Event eines oder mehrere Workbooks zuweisen. Ein solches umfasst jeweils eine Liste mit Standardaufgaben, die die Bearbeiter bei der Auswertung von Ereignissen oder Fällen befolgen sollen. Ab Werk bringt SOAR einige Workbooks mit, darunter eines für das Vorgehen nach NIST 800-61. Dabei handelt es sich um den Computer Security Incident Handling Guide der US-amerikanischen Sicherheitsbehörde.

Weitere Beispiele für Workbooks, etwa für den Umgang mit vermuteter Kompromittierung von Accounts, verdächtigen E-Mails oder Malwarebefall konnten wir direkt übernehmen, nach unserem Bedarf anpassen oder auch eigene Workbooks konfigurieren. Die einzelnen Teilaufgaben aus dem Workbook konnten wir dann innerhalb des jeweiligen Events SOAR-Benutzern zuweisen. Jeder Benutzer dokumentiert schließlich Beginn und Abschluss der Bearbeitung direkt im Event und kann dabei auch zusätzliche Informationen in Form von Notizen und Dateianhängen hinterlegen. So bündelt SOAR die komplette Bearbeitung von Ereignissen unter einer Oberfläche.

Splunk SOAR vereinfacht die Arbeit von IT-Security-Teams und SOC-Analysten. Mithilfe der zahlreichen Apps verbindet die Software die Systeme verschiedener Hersteller und erlaubt das Bearbeiten von Ereignissen unter einer Haube. Die besondere Stärke liegt dabei in der Automatisierung per Playbook, aber auch bei der manuellen Bearbeitung sorgt die Verwaltung von Events mithilfe der Workbooks für mehr Struktur im Arbeitsalltag. Je größer und heterogener eine Infrastruktur, desto besser vermag SOAR seine Vorteile auszuspielen – umso schneller gelangen Administratoren aber auch an die Grenzen der kostenfreien Community-Edition, die auf lediglich fünf offene und in Bearbeitung befindliche Ereignisse sowie maximal 100 Aktionen pro Tag limitiert ist.