NDR: So funktioniert Anomalieerkennung auch bei Eigenentwicklungen

Bei der Anomaly Detection kommt es vor allem auf ein strukturiertes Vorgehen an. Unsere Schritt-für-Schritt-Anleitung hilft Unternehmen, auch in eigenentwickelter Software verdächtige Verhaltensweisen von Angreifern zu erkennen und dabei False Positives zu vermeiden.

Heutige Cyber-Angriffe laufen oft mittels einer Kombination aus unterschiedlichen Taktiken und Techniken ab. Eine wichtige Schutzmassnahme ist die aktive Überwachung der Systeme und Applikationen, bei denen nach Anomalien gesucht wird, die auf einen Angreifer hindeuten. Grundlage dafür ist das Verständnis der TTP (Tactics, Techniques and Procedures): Die Taktiken beschreiben das Verhalten des Angreifers – etwa den Versuch, sich Zugang zum Firmennetzwerk zu verschaffen. Die Techniken zeigen detailliert auf, wie er seine Taktik umsetzt, beispielsweise Phishing. Und die Prozeduren liefern eine ausführliche Beschreibung der Techniken – etwa die geplante Reihenfolge oder die Phasen der Phishing-Attacke.

Allerdings deutet nicht jede Anomalie zwangsläufig auf einen Angriff hin. So kommt es immer wieder vor, dass das Anomaly Detection System einen Fehlalarm (False Positive) auslöst – etwa, weil ein Programm irrtümlich als Schadsoftware identifiziert wurde. Die grosse Herausforderung bei der Anomaly Detection besteht deshalb darin, möglichst wenige False Positives zu generieren und dabei den Angriff trotzdem zu erkennen. Es kommt daher darauf an, klar zu definieren, welche Art von Angriff erkannt werden soll. Dies ist besonders schwierig bei Eigenentwicklungen, für die es keine standardisierten Sicherheitslösungen gibt wie zum Beispiel selbstentwickelte Buchungstools für Hotels, Logistiksoftware von Transportunternehmen oder massgeschneiderte Bankensoftware. Wie erkennt man automatisiert und skalierbar Angriffe auf individuelle Lösungen?

In diesem Blog-Post möchte ich euch das von uns entwickelte Grundkonzept vorstellen, nach dem sich die Anomaly Detection in Business-Anwendungen, auch in Eigenentwicklungen, strukturiert durchführen lässt. Bei Exeon nutzen wir als Grundlage dafür unsere eigene Lösung ExeonTrace.

1. Aufbauen einer Testumgebung:
   Aus Sicherheitsgründen sollte die Testumgebung unabhängig von der produktiven Umgebung sein.
2. Definieren des Angriffsszenarios:
   Wichtig ist, mit allen Stakeholdern – Business-Verantwortlichen, CISO, Administratoren und Analysten – ein gemeinsames Ziel festzulegen. Dazu gehören die Definition des Angriffsszenarios, das erkannt werden soll – etwa ein unberechtigter Zugriff auf Kundendaten in der Buchhaltungssoftware – sowie die Definition des Zeitpunkts, ab dem eine entsprechende Warnung erfolgen muss.
3. Aktivierung der Logs und ihre Einbindung in ein Anomaly Detection System wie ExeonTrace:
   Entscheidend ist, dass sich die Ereignisse aufzeichnen und abspeichern lassen.
4. Ausführen einer Attacke und Aufzeichnen des Angriffsablaufs:
   Es wird genau durchgespielt, wie sich der Angreifer verhalten könnte – etwa mit gestohlenen Zugriffsinformationen auf Daten zugreifen oder eine Schadsoftware ausführen. Auf diese Weise lässt sich nachvollziehen, was konkret passieren kann.
5. Analyse der Aufzeichnung auf Detektionsmöglichkeiten und Muster:
   In diesem Schritt werden alle Logs ausgewertet. Dadurch wird ersichtlich, welche Logs durch einen Angriff generiert wurden, beziehungsweise welche Datenattribute auf einen Angriff hinweisen, weil sie ein verdächtiges Verhalten zeigen – etwa den Zugriff aus einem Endpunkt im Internet.
6. Erstellen/Konfigurieren des XLogs Analyzers, um das gewünschte Muster zu erkennen:
   Jetzt wird die Analyse in Form von Regeln abstrahiert. Ein Machine-Learning-gestützter Algorithmus versucht dabei, das gesuchte Muster zu finden, das auf einen Angriff hindeutet – etwa den unberechtigten Zugriff auf eine Datei, die sensible Daten enthält.
7. Erneutes Ausführen des Angriffs beziehungsweise Log Replay zum Testen des neuen Analyzers (True Positive Testing):
   Nach der Ausführung des Angriffs ermöglicht das System eine erneute Analyse der erkannten Anomalien. Wenn die Detektion erfolgreich war, geht es weiter zu Schritt 8. Alternativ dazu lassen sich die Anomalien mithilfe der Funktion Log Replay noch einmal abspielen und analysieren. Funktioniert die Erkennung der Anomalie in der Testumgebung nicht, muss der Angriff erneut ausgeführt werden (Schritt 4).
8. Testen des Analyzers anhand von realen Daten, um die False-Positive-Quote zu ermitteln (False Positive Testing):
   Damit nicht permanent Benachrichtigungen und Warnungen eingehen, wird der neue Analyzer noch nicht scharfgestellt. Es geht zunächst darum, die Anomalieerkennung zu testen, indem analysiert wird, wie viele Fehlalarme erkannt worden sind. Bei einer hohen Anzahl von False Positives ist ein Wechsel zurück in die Testumgebung notwendig und die grundlegende Detektionslogik muss überarbeitet werden. Wenn alle Mitarbeitenden im Home-Office sind und sich daher ihre Client IPs im VPN Range befinden, kann es zum Beispiel sinnvoll sein, diese gesondert zu behandeln.
9. Erstellen eines Runbooks für Analysten und Administratoren:
   Das Runbook zeigt die wichtigsten Schritte für die IT-Verantwortlichen auf. Wie müssen sie vorgehen, wenn eine Anomalie erkannt wurde? Wer muss was abklären? Wer muss das Thema eskalieren? Und wer muss wie reagieren, wenn es tatsächlich zu einem Angriff kommt? Vor dem Scharfschalten der Produktivumgebung sollte ausserdem die Art des Angriffs genau dokumentiert werden.
10. Ausrollen in den produktiven Betrieb:
    Jetzt geht es darum, alle Beteiligten – CISO, Admins, sowie das SOC (Security Operation Center) beziehungsweise die Analysten – über die neuesten Erkenntnisse zu informieren und sie zu schulen. Wichtig ist auch, das Runbook entsprechend zu aktualisieren.
11. False Positive Rate regelmässig überwachen und gegebenenfalls den Analyzer überarbeiten:
    Hier geht es nicht nur um den Überblick, wie viele False Positives generiert wurden, es kommt auch darauf an, aufzuzeigen ob die Anomalieerkennung wirtschaftlich arbeitet, indem die Erfolgsrate mit dem Aufwand in Relation gesetzt wird. Unter Umständen muss die Software überarbeitet, gewartet und optimiert werden.