Intelligente Angriffserkennung? : Wie gut ist die Automatisierung heutiger SIEM-/SOAR-Systeme?

Von Kai-Oliver Detken, Bremen

Aufgrund der Vielzahl heutiger Schwachstellen und Angriffe ist es sinnvoll, Unternehmensnetze intern permanent auf Anomalien zu untersuchen. Um dabei nicht nur bekannte Muster, sondern beliebige Auffälligkeiten effizient erkennen zu können, müssen Systeme und Lösungen zum Sicherheitsmonitoring oder Security-Information- and -Event-Management (SIEM) „intelligenter“ werden. Gerade SIEM-Systeme der zweiten Generation werden häufig mit dem Attribut „künstliche Intelligenz“ (KI) beworben, die hier nach verschiedenen Ansätzen funktionieren kann (s. a. [1]):

• Statische Zeitreihenanalyse: Über Nutzerzahlen, Bandbreite et cetera wird über eine bestimmte Zeit hinweg ein Normalverhalten ermittelt und anschließend kontinuierlich mit dem Ist-Zustand verglichen, um signifikante Abweichungen zu erkennen. Zwar schont diese Technik Ressourcen, ist aber nur als Ergänzung zu statischen Regelwerken anwendbar.
• Statische Regelwerke: werden von Anbietern gepflegt und gegen dynamische Listen für verdächtige Objekte (IP-/URL-Adressen, Hashes etc.) abgeglichen. Während für die Regelwerke eine monatliche Aktualisierung genügt, sind die dynamischen Listen eher täglich auf dem neusten Stand zu halten.
• Verhaltensanalyse von Mitarbeitern und Endgeräten: Hierzu werden für einzelne Nutzeraktivitäten oder Entitäten (z. B. IP-Adressen, Serversysteme oder Applikationen) Modelle des Normalverhaltens mittels statistischer Analysen oder Lernverfahren erstellt. Davon resultierende Abweichungen werden als Anomalien (Vorfälle) gewichtet.

Statische Analysen

Statistische Zeitreihenanalysen sind in vielen kommerziellen Produkten und Open-Source-Bibliotheken zu finden, arbeiten aber nur auf vorab definierten Metriken und numerischen Werten. So könnte man beispielsweise festlegen, welcher Netzwerkverkehr normal ist (z. B. bis 500 Mbit/s), um dann bei Überschreitung dieses Wertes einen Alarm auszulösen – warum es zu einer Überschreitung kommt, wird dabei nicht hinterfragt.

Statische Regelwerke sind bei bekannten SIEM-Herstellern/-Lösungen, wie IBM QRadar SIEM, OSSEC, Tenable LCE oder McAfee Enterprise Security SIEM, integriert. Hier wird versucht Cyber-Threat-Intelligence umzusetzen, indem man Honeypots, statische Analysen über verschiedene Kunden sowie Postings im Darknet mit einbezieht. Hierbei ist daher eine permanente Anbindung des SIEM-Systems an die Kundensysteme notwendig. Logdaten werden teilweise zur Korrelation anderer Kundendaten mitverwendet, was nicht immer datenschutzkonform umgesetzt sein muss – das sollte man auf jeden Fall hinterfragen.

Bei der „intelligenten“ Verhaltensanalyse wird zunehmend auch sogenanntes maschinelles Lernen (ML) eingesetzt. Diese Technik kommt vor allem bei SIEM-Herstellern und -Lösungen der zweiten Generation, wie IBM QRadar UBA, LogRhythm UEBA, HPE ArcSight UBA, Splunk und DarkTrace Enterprise, zum Einsatz. Die verwendeten Lernverfahren nutzen dabei ausgewählte Metriken zu einzelnen Datenfeldern verschiedener Events (z. B. Authentifizierungsvorgänge und Aktivitäten in Applikationen), deren zeitliche Entwicklung und Korrelation betrachtet werden. So können die Systeme beispielsweise vermehrte Login-Versuche auf einer Datenbank erkennen.

Maschinelles Lernen

Im Bereich der Anomalie-Erkennung bei Intrusion-Detection-Systemen (IDS) kommen bereits seit Jahrzehnten ML-Techniken zum Einsatz. Waren es zunächst symbolische Verfahren, beispielsweise Support-Vector Machines, K-Nearest-Neighbour- oder Bayes’sche-Verfahren, werden jetzt auch vermehrt subsymbolische Deep-Learning-Verfahren – beispielsweise Generative Adversarial, Recurrent Neural oder Artificial Neural Networks oder hybride Kombinationen daraus – zur Analyse des Netzverkehrs und seines Verhaltens verwendet.

Zum Trainieren solcher Netze bei geringer Verfügbarkeit annotierter Testdaten kommen vermehrt auch sogenannte Active-Learning-Ansätze zum Einsatz, bei denen ein menschlicher Experte in wenigen Testfällen weitere Bewertungen vornimmt. Intrusion-Response-Systeme (IRS) reagieren dann auf solche gemeldeten Angriffe manuell (passiv) oder automatisch (aktiv) mit entsprechenden Maßnahmen.

Die Zuordnung von Angriffen zu erforderlichen Gegenmaßnahmen erfolgt entweder regelbasiert oder assoziativ unter Einbeziehung der durch die Maßnahmen beobachteten Systemänderungen. Da ein aktives System automatisch auf Ereignisse reagiert, bewirkt es in aller Regel eine kürzere Reaktionszeit und damit ein kleineres Zeitfenster, in dem ein Angreifer aktiv sein kann. Auf der anderen Seite kann es aber bei Fehlalarmen auch signifikante Kosten verursachen, sodass eine zuverlässige Angriffs-Erkennung Voraussetzung für den automatischen Einsatz eines IRS sein sollte.

Verstehen ist mehr als Sehen

Für das Verständnis eines Angriffs und dessen Meldung an Partnerakteure ist es wichtig, das Vorgehen des Angreifers zu verstehen. Die Root-Cause-Analysis ist eine Methodik zur Identifikation von initialen Ereignissen und deren kausalen und temporalen Beziehungen beziehungsweise Wirkketten zu auftretenden Fehlern – bisher kommt dieses Verfahren hauptsächlich im Qualitätsmanagement und im Safety-Bereich zum Einsatz.

Typischerweise konstruieren solche Techniken deterministische oder probabilistische Modelle, die auf dem zugrunde liegenden Domänen- oder Systemwissen und der Historie des beobachteten Systems aufbauen [2]. Mit deren Hilfe lässt sich dann die Verwundbarkeit eines Systems abschätzen – etwa mithilfe von Markov-Modellen oder simulationsbasierten Verfahren (z. B. Monte-Carlo-Simulation).

Maschinelles Lernen (ML) steckt aber nach wie vor in der praktischen Umsetzung in den Kinderschuhen. Bestehende Forschungsansätze gelangen oftmals nicht in die Praxis, weil eine semantische Lücke zwischen der Ausgabe von Systemen, die in der Regel auf der Basis einzelner Datensätze arbeiten, und den Erwartungen des Analysten besteht, der die Ausgabe verstehen muss.

Dies verdeutlicht auch Abbildung 1: Hier wird der gesamte Prozess zur Wahrnehmung einer Anomalie durch verschiedene Ebenen (Wahrnehmungs- bis Projektionsebene) unterteilt. Am Anfang stehen die Rohdaten, die erst einmal mit Zusatzinformationen (z. B. IP-/MAC-Adressen) angereichert werden müssen. Daraus folgt durch Deep-Learning-Algorithmen eine erste Anomalie-Erkennung, die parallel automatisiert auf Plausibilität überprüft wird. Anschließend erzeugt das System einen Vorfall oder Event und gibt diesen an weitere Algorithmen für kognitive Vorgänge weiter, damit am Ende ein Mensch über diesen Vorfall entscheiden kann.

Stellt der Analyst fest, dass es sich nicht um eine Anomalie handelt, sondern um eine bekannte Störung oder einen Ausnahmefall, kann er dies über einen Feedback-Mechanismus an die Anomalie Erkennung zurückgeben – dadurch wird bei dem nächsten ähnlichen Vorfall kein Event mehr erzeugt. Für diese menschliche Entscheidung muss jedoch ein Bezug zu den Ausgaben der Systeme hergestellt werden können, was nicht immer möglich ist. Daher bewirkt der ML-Einsatz erst einmal die vermehrte Ausgabe von Falschmeldungen (False Positives), da exakte Werte für Metriken nicht erkannt werden können und eine hohe Variabilität des realistischen, gutartigen Verkehrs existiert – beides erschwert das Auffinden stabiler Muster.

Mist rein, Mist raus

Hinzu kommt, dass oft keine guten Datensätze und solide Bewertungsmethodik vorhanden sind; auch reale Anwendungen zum Erkennen von Netzwerk-Anomalien fehlen bislang. Sicherheitsanalysten von Security-Operations-Centers (SOCs), die permanent mit Sicherheitsvorfällen zu tun haben, benötigen daher weitere Unterstützung bei der Korrelation von Daten aus heterogenen Quellen, um sich einen ganzheitlichen Überblick verschaffen zu können. Erst dann lassen sich etwa laterale Bewegungen und Bedrohungen zwischen verschiedenen Hosts erkennen.

Die Qualität der Datensätze ist also ein entscheidendes Kriterium bei der Anomalie-Erkennung. In den letzten Jahren haben Forscher begonnen, mehrere neue Datensätze zur Bewertung von IDS-/SIEM-Systemen zu veröffentlichen, darunter GureKDD (www.sc.ehu.es/acwaldap/gureKddcup/), UNSW-NB15 (https://research.unsw.edu.au/projects/unsw-nb15-dataset) und CICIDS (www.unb.ca/cic/datasets/ids-2017.html).

Die meisten Datensätze bestehen dabei aus PCAP-Rohdaten (mitgeschnittener Netzverkehr) und vorverarbeiteten Datensätzen. Dabei stellte sich die Frage, ob die erkannten Muster eines Netzwerks sich auch auf andere Netzwerke übertragen lassen. Dies wurde in der Forschung durch die Verwendung eines Datensatzes zum Trainieren und das Anwenden auf einen anderen Datensatz untersucht [3]. Die Ergebnisse zeigten allerdings, dass sich Muster eben nicht einfach auf andere Netze verallgemeinern lassen. Zusätzlich kamen SOC-Analysten zu dem Schluss, dass die meisten Alarme irrelevant sind und selbst relevante Alarme erst nach und nach zu Sicherheitsvorfällen werden.

SOAR – the Next-Generation SIEM?

Als weiterer Begriff von Sicherheitslösungen, die mit ML-Algorithmen arbeiten, kann Security-Orchestration,  Automation and -Response (SOAR) genannt werden [4,5]. SOAR kann man als eine Plattform betrachten, die verschiedene Sicherheitstools und -prozesse integriert – Gartner definiert dazu vier Hauptaufgaben:

• Sammeln von Sicherheitsbedrohungsdaten und -warnungen aus verschiedenen Quellen
• Ermöglichen von Analyse, Sichtung und Priorisierung von Vorfällen, sowohl automatisch als auch manuell mithilfe von Maschinen
• Definieren und Durchsetzen eines Standard-Workflows für die Reaktion auf Vorfälle
• Codierung von Vorfallanalyse- und Reaktionsverfahren in einem digitalen Workflow-Format, das die Automatisierung einiger oder aller Reaktionen auf Vorfälle ermöglicht

SOAR-Lösungen konzentrieren sich heute meist auf die Reaktion auf einen Vorfall und die Entscheidungsfindung, woraufhin die Reaktionsmaßnahmen auf der Grundlage einer Bewertung des Vorfalls, des Systemstatus und des Umgebungszustands automatisiert werden sollten. Die Erkennung von Vorfällen ist eine zentrale Aktivität, die Reaktionen auf Vorfälle auslöst – daher sollte eine SOAR-Lösung von einem Erkennungsmodul aus einem SIEM-System gespeist werden. SOAR-Lösungen werden teilweise als eigenständiges Tool entwickelt, während Gartner ihre Integration in die SIEM-Systeme der nächsten Generation vorschlägt (vgl. [5])

Folgende Szenarien lassen sich mit SOAR- oder Next-Generation-SIEM-Systemen erkennen beziehungsweise umsetzen:

• Bewältigung unbekannter Risiken durch Verfolgung von Insider-Angriffen
• User- and Entity-Behavior-Analytics (UEBA) – kompromittierte

Benutzer-Anmeldeinformationen, Kompromittierung privilegierter Benutzer, Überwachung exekutiver Vermögenswerte, Erkennung kompromittierter Systeme/Hosts/ Geräte, Missbrauch von Insiderzugängen, Erkennung von „Seitwärts-Bewegungen“ (Lateral Movements),Erkennung von Daten-Exfiltration, Kontosperrungen, Missbrauch von Dienstkonten

• Erkennung von Phishing-URLs
• Erkennung bösartiger URLs
• Erkennung von Netzwerk-Anomalien
• verdächtige E-Mail-Aktivitäten
• automatisierte Sicherheits-Playbooks: Zuordnung von Angriffen zu vordefinierten Richtlinien

Wenn ein Vorfall erkannt wird, erzeugt SOAR automatisch einen Alarm zur Untersuchung und benachrichtigt die Sicherheitsanalysten. Wird ein Vorfall bestätigt, leitet das System eine automatische Reaktion auf der Grundlage von Reaktionsplänen ein.

Abschließend kann man die Grenzen solcher SOAR-Sicherheitslösungen wie folgt zusammenfassen:

• Das Erkennen von Vorfällen ist szenariobasiert – die Erkennung von fortgeschrittenen Angriffen (z. B. APT) bleibt daher eine Herausforderung.
• Es werden zu viele Sicherheitswarnungen erzeugt.
• SOAR-Lösungen sind nur automatisiert und nicht „intelligent“.
• SOAR-Lösungen liefern keine Handlungsoptionen, die von Experten ausgewählt werden können.
• Es fehlt eine Interaktion zwischen Sicherheitsexperten und Erkennungs-/Reaktionstools.
• Erkennungs-/Reaktionstools werden nicht automatisch an Umweltveränderungen angepasst.
• Die Datenanalyse erfolgt nicht unter Wahrung der Privatsphäre.

Fazit

Vor, während und/oder nach einem Cyber-Angriff lassen sich Informationen über Techniken, Geräte, Netzwerke und Rechner von Angreifern und Opfern sammeln, speichern und analysieren. Es bleibt trotzdem schwierig den eigentlichen Angreifer und seine Beweggründe hinter einer Attacke zu identifizieren, da die Zuordnung dieser Daten problematisch ist. Neue Bemühungen im Bereich Threat-Intelligence stellen daher die Taktiken, Techniken und Prozeduren (TTP) eines Angriffs in den Vordergrund. Unterschiedliche Branchen und Organisationen haben damit begonnen, das Mitre ATT&CK Framework zu verwenden (https://attack.mitre.org), um TTPs von Angreifern verstehen zu können, wodurch sich wiederum Lücken in der eigenen Abwehr identifizieren lassen.

Um einen Vorfall ausreichend gut bewerten zu können, müssen allerdings Ausgabedaten existieren, die qualifizierte Datensätze und Detailwissen über das Normalverhalten des Firmennetzes umfassen. Das heißt, Informationen über Bedrohungen für die Informationssicherheit sind in einen spezifischen Kontext zu bringen, um Daten-Analysten zu unterstützen und zukünftige Situationen vorhersagen beziehungsweise fundierte Entscheidungen treffen zu können – diese Fähigkeit kann im Begriff Cyber-Threat-Intelligence (CTI) zusammengefasst werden.

Durch die in einer CTI-Prozesskette vorgesehene IT-Forensik lassen sich Anforderungen detaillierter definieren, sodass man beispielsweise über festgestellte Muster für einen bestimmten Schadcode Hinweise auf mögliche Angreifer und ihre Motivation ermitteln kann. Allerdings eignet sich der CTI-Ansatz, wenn er vom Menschen erzeugt wurde, nicht als Basis um Advanced Persistent Threats (APT) zu erkennen: Durch den Mangel an Vollständigkeit und Aktualität sowie die Mehrdeutigkeit von Events ist dies nicht möglich.

Um Schwachstellen in Herstellerlösungen grundsätzlich begrenzen zu können, ist es daher unumgänglich den Ansatz „Security by Design“ umzusetzen, der die IT-Sicherheit bereits im Entwicklungsprozess von Hard- und Software berücksichtigt – das erfordert nicht zuletzt den Einsatz von Verschlüsselung und Authentifizierung sowie die Isolation sicherheitsrelevanter Bereiche. Bei jedem Entwicklungsschritt ist dann die IT-Sicherheit immer wieder zu hinterfragen und zu testen, um letztlich ein Produkt auf den Markt zu bringen, das frei von Schwachstellen ist und sich damit robust gegenüber Angriffen verhält.

Leider wird dieser Ansatz immer noch nicht „gelebt“, da damit in der Regel eine Verzögerung des Markteintritts einhergeht. Es bleibt daher zu hoffen, dass immer mehr „intelligente“ Sicherheitssysteme wie SIEM und SOAR zum Einsatz kommen, um Angriffe rechtzeitig zu erkennen und verständliche Handlungsempfehlungen herauszugeben. Diese müssen allerdings erst noch ein ganzes Stück intelligenter werden, wie dieser Beitrag zu zeigen versucht hat, um tatsächlich eine ausreichende Wirksamkeit zu entfalten.

Prof. Dr.-Ing. Kai-Oliver Detken (detken@decoit.de) ist Geschäftsführer der DECOIT GmbH, doziert an der Hochschule Bremen und arbeitet als freier Autor im IT-Umfeld.

Literatur

[1] Bettina Weßelmann, Johannes Wiele, KI braucht Zuwendung, Über die Arbeit mit regelbasierter und anoma-liegestützter Bedrohungserkennung, 2019# 3, S. 70

[2] Marc Solé, Victor Muntés-Mulero, Annie Ibrahim Rana, Giovani Estrada, Survey on Models and Techniques for Root-Cause Analysis, Juli 2017, https://doi.org/10.48550/arXiv.1701.08546

[3] Felix Heine, Tim Laue, Carsten Kleiner, On the Evaluation and Deployment of Machine Learning Approaches for Intrusion Detection, in: Proceedings of the 2020 IEEE International Conference on Big Data, Special Session on Intelligent Data Mining, S. 4594, ISBN 978-1-7281- 6252-2, https://ieeexplore.ieee.org/document/9378479 (kostenpflichtig)

[4] Kai-Oliver Detken, Alles SIEM, oder was?, Netzwerk-Monitoring zur Sicherheitsüberwachung, 2021# 3, S.6

[5] Georgeta Toth, Schnellere Schlagzahl, Mehr Effizienz für mehr Sicherheit mit Security-Orchestration, -Automation and -Response (SOAR), 2022# 1, S.10