Was ist ein SOAR?
Vollautomatisch böse Hacker mit Laserstrahlen abschießen? Ja, so ungefähr!
Diese Erklärung bringt Licht ins Dunkle.
Starten wir!
Was ist ein SOAR?
Ein SOAR (Security Orchestration Automation and Responses) ist ein Automatisierungstool für IT-Sicherheitsvorfälle. Ein SOAR nutzt „Playbooks“, welche (Low-Code) Skripte sind, die Eingaben verwenden und diese verarbeiten.
Die Playbooks ermöglichen Wenn-Dann-Verzweigungen, Schleifen, Benachrichtigungen, Integration mit Third-Party-Services, Meldeketten und vieles mehr. Eingaben erhält das SOAR von einer SIEM-Software (Security information and event management).
Ein SIEM sammelt Logdateien von Mitarbeiter-Computer und Servern. Diese Logdateien können Hacking-Versuche, Lastspitzen, Fehlermeldungen und mehr beinhalten.
Das SIEM bestimmt und filtert die für das Unternehmen relevante Vorfälle und Ereignisse. Das SOAR arbeitet die Vorfälle (voll automatisch) ab, konfiguriert Systeme, meldet Ereignisse an die zuständigen Personen, baut neue Sicherheitsbarrieren auf.
Warum eine SOAR nutzen?
Viele Prozesse und Aufgaben in der IT-Sicherheit sind monoton und langweilig – das Grundrauschen.
Diese Events soll ein SIEM erkennen und eine SOAR erledigen. Kein IT-Security-Profi hat Interesse, 3000 Mal den gleichen Bericht zu schreiben oder für jeden Patch eine neue Benachrichtigung zu veröffentlichen.
Steffen Lippke
Die meisten Unternehmen ohne SOAR bearbeiten jeden Tag das Grundrauschen und können sich nicht um die Ursachen kümmern. Komplexe Vorfälle und Beratung für sichere Systeme sollte der Hauptfokus für die IT-Sicherheitsabteilung sein.
Anwendungen für SOAR
Typische Beispiele sind die folgenden:
#1 Spam-E-Mail mit Anhang
Das SOAR untersucht den Anhang mit einem Antivirus-Programme, blockiert die Auslieferung zum Sender und benachrichtigt das CERT. Ein Antivirus-Programm kann die Datei auf Malware-Signaturen untersuchen und dem Playbook eine Aktion (Quarantäne, Löschen, Benachrichtigung, Weitersenden) zurückmelden.
#2 Brute-Force-Angriff behandeln
Das SOAR spricht die API der Firewall an, um diese so zu verändern, dass der Server den Port XY blocken soll. Einen Service starten, stoppen und konfigurieren ist die Hauptaufgabe eines SOARs. Dazu verwendet das Playbook Endpunkte. Ein SOAR in der Low-Code-Version bietet Drag-und-Drop-Bausteine an, welche neue Services hinzufügen.
#3 Ungewöhnliche Logs auf einem Produktiv-Server
Das SOAR benachrichtigt den zuständigen Administrator. Nicht jeder ungewöhnliche Logeintrag ist auf einen Hacker zurückzuführen. In den meisten Fällen hat ein Administrator Mist produziert oder ein DAU war am Werk (Dümmster anzunehmende User).
#4 Auslastung von 100 % am Server 1h+
Das SOAR startet einen Antivirus-Scan über den ganzen Server. Eine Last auf einem Server könnte bedeuten, dass eine Ransomware versucht alle Dateien auf dem Computer zu verschlüsseln. Eine hohe Last könnte auch andere Gründe haben – sicher ist sicher.
#5 Sammler von Patch-Benachrichtigungen
Das SOAR sendet dem zuständigen Administrator (und seinem Chef) eine Mail mit allen relevanten Patching-Informationen.
Manche Lücken in Softwares (Exploits und Zero-Day-Bugs) sind so gravierend, dass ein Patching in wenigen Minuten erfolgen sollte. Wenn ein Exploit öffentlich bekannt ist, finden Angriffe unmittelbar (per Automation) der Kriminellen statt.
6 Mythen über SOAR – Die Auflösung
Einige (absichtlich) dumme Verkäufer und naive SOAR-Neukunden haben falsche Vorstellungen, von der Leistung eines SOARs. Viele Hochglanzbroschüren werben mit grenzenloser Automatisierung, Vereinfachung, Reduzierung von Personalkosten und mehr…
- Stimmt das?
- Was sind falsche Annahmen?
Diese sechs Mythen solltest Du aus Deinem Kopf radieren:
#1 Kein IT-Sicherheitspersonal mehr notwendig
Wenn „Berater“ aka Verkäufer behaupten, dass die Einführung eines SOAR den Bedarf von IT-Sicherheitspersonal halbiert, dann handelt es sich um einen trockenen Theoretiker oder geschickten Lügner.
Das Sicherheitspersonal muss ein SOAR erst einmal konfigurieren und neue Playbooks erstellen. Zu dem SOAR käuft sich der Kunde weitere APIs, Sandboxes, Firewalls, Antivirus-Programme und mehr, welche wiederum Konfigurationsaufwand bedeuten.
Dabei handelt es sich um Low-Code oder je nach Fall um richtige Programmierung. Das ist sehr zeitintensiv. Sobald 100 % der vorherigen Arbeit automatisiert ist, kämpft das IT-Sicherheitspersonal mit dem nächsten Vorfall …
#2 Vollständige Abdeckung
Ein SOAR deckt nur die Fälle ab, für die das IT-Sicherheitspersonal auch Playbooks geschrieben und aktiviert hat.
Oft bildet ein Playbook eine Form von Geschäftsprozess ab bzw. den bekannten Standardfall ab. Wenn ein Vorfall über „den Standard“ hinausgeht, dann muss das IT-Sicherheitspersonal Hand anlegen. Jede Konfigurations-, Umgebungs- oder Anforderungsänderung zieht eine Änderung im Playbook hinter sich: Handarbeit.
#3 Automatisierung spart immer Geld
Eine Automatisierung kann zu einem riesigen, vollautomatischen Schaden führen:
Stelle Dir vor, Du programmierst ein Skript, welches Spam-Mails direkt vom Mail-Gateway löscht. Der Sender schreibt eine Mail, die das Mail-Gateway als schädlich klassifiziert. Weil der Sender am selben Tag seinen Laptop verliert und das Backup vergessen hat, dann ist die „Geld-sparende“ Automatisierung ein Geldverbrennungsofen.
Ein anderer Fall ist eine perfekt abgestimmte Backup-Automatisierung, welche früher gut funktioniert hat. Wegen einer neuen Anforderung musst der Administrator die Umgebung verändern. Der Backup-Service erstellt 100 Terabytes an Backups auf den falschen Server und der Administrator muss mit viel Handarbeit im Nachgang die Backups auf die richtigen Server verteilen.
Ein solches Szenario tritt auch auf, wenn eine API ihre Schnittstellen ändern, dann muss händisch oder mit einem neuen Extra-Skript nachgeholfen werden
#4 Automatisierung ist immer automatisch
Einige Playbooks sehen menschliche Entscheider und manuelle Arbeitsschritte vor. Der Mensch muss innerhalb der Playbook-Ausführung gemachte Änderungen zurückmelden oder eine Entscheidung treffen. Das Playbook verarbeitet Ereignisse im Millisekundenbereich, während menschliche Entscheider lahm sind:
- machen gerade Pause
- haben Wichtigeres zu tun
- sind in einem Meeting
- haben 3 Wochen Urlaub
- es ist ja schon Freitag um 14:43 …
Die Automatisierung ermöglicht dem Personal, auf mehr Vorfälle zu reagieren. Oft automatisiert das Team nur die Spitze des Eisbergs, bevor das Personal eine freien Blick auf noch mehr unentdeckter Vorfälle und Probleme erhält …
#5 Immer funktionsfähig und verfügbar
Menschen schreiben Playbooks.
Menschen machen Fehler.
Also sind Playbooks mit Fehlern behaftet.
Egal wie gut der Programmierer war, irgendeinen Edge-Case hat dieser nicht beachtet oder die Anforderungen und die Umgebung ändert sich. Das schöne Playbook ist jetzt wertlos.
Nix ist automatisiert.
Nix ist immer verfügbar.
Nix funktioniert.
#6 SOAR ohne SIEM
Einige Hersteller von SOAR bauen ein SIEM ein, um ein vollständiges Standalone-Tool zu haben.
Sinnvoller ist es SIEM vom SOAR inhaltlich und programmatisch zu trennen, weil nicht jedes Ereignis in einem SOAR verarbeitungswürdig ist. Ein SIEM sollte als rein informatives Tools genutzt werden, während ein SOAR eine Umsetzung durchführt.
Oft reicht der Führung, dem Administrator oder dem CERT-Team die Information aus:
Z. B. ein Server läuft auf einem Kapazitätslimit, dann kann der Analyst ein Playbook manuell starten oder nicht, um diesen entgegenzuwirken.
