Der Inside-Out-Sicherheits Blog - Der Inside-Out-Sicherheits Blog

Abweichende Verhaltensweisen mit Analysen des Nutzerverhaltens definieren

Geschrieben von Matt Radolec | Jan 23, 2018 7:19:00 AM

Seit über zehn Jahren sind Sicherheitsleitstellen und Analysten mit sogenannten „Indicators of Compromise“ (IoC = eine Liste von Daten über Bedrohungen), schwellenbasierten Anzeichen von Angriffen oder Angriffsversuchen beschäftigt und versuchen, mit dem sich ständig ändernden Bedrohungsumfeld Schritt zu halten. Es ist ein aussichtsloses Unterfangen.

Zur selben Zeit wurden Angreifer noch effektiver darin, ihre Aktivitäten zu verbergen. Eine als Steganografie bekannte Cloaking-Methode hat herkömmliche Signatur- und schwellenbasierte Erkennungsmaßnahmen praktisch unbrauchbar gemacht.

Angesichts dessen hat die Sicherheitsbranche eine neue Nachfrage nach User Behavior Analytics (UBA = Analysen des Nutzerverhaltens) identifiziert, die nach Aktivitätsmustern und mathematisch signifikanten Abweichungen von Nutzerverhalten (Nutzung von Apps, Aktivitäten beim Suchen von Dateien) aus historischen Daten suchen.

Ich werde oft gefragt, was UBA von traditionellen SIEM-basierten Ansätzen unterscheidet.

Kenne Deine Verhaltenshistorie

Meiner Meinung nach liegt die Antwort in der Historie! Vielleicht kennen Sie das Sprichwort: Jene, die sich der Vergangenheit nicht erinnern, sind verdammt, sie zu wiederholen?  Das trifft auf einen reinen SIEM-basierten Ansatz zu, der nach aktuellen Ereignissen Ausschau hält: gelöschte oder kopierte Dateien, fehlgeschlagene Logins, Malware-Signaturen oder übermäßig viele Verbindungsanfragen von einer IP-Adresse.

Natürlich müssen Sie nach unbearbeiteten Ereignissen Ausschau halten, aber ohne Kontext sind SIEM-basierte Statistiken und Snapshots ein unzuverlässiges Signal darüber, was eigentlich passiert. Wir sprechen von „Falschmeldungen“, wenn ein SIEM-System scheinbar eine Benachrichtigung anzeigt, obwohl es keine gibt. Irgendwann werden Sie kontinuierlich denselben falschen Hinweisen hinterherjagen, oder schlimmer noch, sie alle ignorieren — „tote Leitung“.

Wie viele Dateien sind zu viel, wenn ein Benutzer sie löscht oder kopiert? Wie viele fehlgeschlagene Logins sind ungewöhnlich für diesen bestimmten Benutzer? Wann ist es verdächtig, wenn ein Benutzer auf einen selten benutzten Ordner zugreift?

Die maßgebliche Entscheidung, die bei einer Ereignisbenachrichtigung getroffen werden muss, liegt in dem richtigen Schwellenwert zur Trennung von normal und anormal.

Oft gibt es dutzende, wenn nicht gar hunderte oder tausende von Anwendungen und Benutzerzugriffen, für die jeweils ein bestimmter Zweck sowie Schwellenwerte, Signaturen und Benachrichtigungen konfiguriert und überwacht werden müssen. Ein Brute-Force-Ansatz führt zu Regeln, die nicht auf historischen Daten beruhen, sondern auf Ad-hoc-Einstellungen, die sich richtig anfühlen, die endlos lange Berichte und blinkende Dashboards generieren, aus denen ein Mitarbeiter-Team „Falschmeldungen“ herausfiltern muss.

Dieses Dilemma, wie ein Schwellenwert festzulegen ist, hat Sicherheitsforscher zu einem statistischen Ansatz gebracht, bei dem Schwellenwerte auf einer Analyse des tatsächlichen Nutzerverhaltens basiert.

Die entscheidende Unterschied zwischen UPA und Überwachungsmethoden, die auf statistischen Schwellenwerten beruhen, liegt darin, dass die Entscheidung zum Auslösen stattdessen von mathematischen Modellen und statistischen Analysen geleitet wird, bei der echte Abweichungen besser erkannt werden können und „Falschmeldungen“ letztlich reduziert werden. Nachfolgend einige Beispiele für Verhaltensbenachrichtigungen:

  • Eine Benachrichtigung erfolgt, wenn ein Benutzer auf Daten zugreift, auf die er zu diesem für ihn unüblichen Zeitpunkt (z.B. 4 Uhr Sonntagfrüh) bisher nur selten zugegriffen hat, und dann E-Mails an einen ISP in Kroatien sendet
  • Eine Benachrichtigung erfolgt, wenn ein Benutzer im Laufe der Zeit ein Muster für fehlgeschlagene Login-Ereignisse aufweist, das außerhalb des normalen Verhaltens liegt
  • Eine Benachrichtigung erfolgt, wenn ein Benutzer Dateien aus dem Homeverzeichnis eines anderen Benutzers kopiert und diese Dateien anschließend auf einen USB verschiebt

Ein einfaches UBA-Beispiel

Der Grund, weshalb UBA so effektiv ist, liegt darin, dass es nicht nur von signatur oder statischen schwellenbasierten Analysen abhängt.

Verdeutlichen wir das an einem Beispiel.

Bei Acme Inc. wurde das Sicherheitsteam gebeten, die E-Mail-Aktivität für alle 1.000 Mitarbeiter zu überwachen. Unmöglich, oder?

Wir können den Kern des Problems nachvollziehen, wenn wir uns nur auf 5 Benutzer (0,5 Prozent aller Benutzer) konzentrieren. Zuerst wenden wir traditionellen Analysen an und prüfen ihre E-Mail-Aktivität (unten) über den Zeitraum von einer Woche.

Benutzer Montag Dienstag Mittwoch Donnerstag Freitag
Andreas 10 8 30 15 13
Monika 15 29 55 33 90
Robert 35 6 7 15 16
Stefan 2 5 4 9 15
Ingo 9 1 3 5 0

Anhand dieses Berichts könnten Sie entscheiden, die Benutzer zu untersuchen, welche die meisten E-Mails versendet haben, richtig?

Sie werden schnell lernen, dass Monika, die 90 E-Mails am Freitag gesendet hat, zum Marketingteam gehört und ihre Leistung darauf basiert, wie vielen Kunden Sie täglich E-Mails sendet. Falsches Signal!

Sie entscheiden sich daraufhin, den Durchschnitt aller Benutzer für jeden Tag zu zugrunde zu legen. Sie erstellen eine statistische Alarmschwelle, sobald der Benutzer an diesem Tag durchschnittlich mehr E-Mails versendet.  Für die oben festgelegten Daten liegt der Durchschnittswert gesendeter E-Mails von einem Benutzer bei 17.

Wenn sie eine Benachrichtigung erstellt hätten, die immer ausgegeben wird, wenn ein Benutzer mehr als 17 E-Mails pro Tag sendet, dann würden Sie während dieses Zeitraums 6 Benachrichtigungen erhalten. Vier dieser Benachrichtigungen würden Sie direkt zu Monika führen, die Königin der E-Mails.

Benutzer Montag Dienstag Mittwoch Donnerstag Freitag
Andreas 10 8 30 15 13
Monika 15 29 55 33 90
Robert 35 6 7 15 16
Stefan 2 5 4 9 15
Ingo 9 1 3 5 0

Dieser Schwellenwert ist offensichtlich zu sensibel. Sie brauchen eine andere Strategie und keinen Durchschnittswert für alle Benutzer an einem bestimmten Tag — die vertikale Spalte.

Der Algorithmus zur Erkennung von Anomalien von UBA untersucht jeden Benutzer, jeden Tag und zeichnet Informationen über ihre Aktivitäten auf. Diese historischen Daten, die nach Tag, Uhrzeit und anderen Dimensionen aufgeteilt sind, werden im System gespeichert, sodaß Statistiken erstellt werden können.

Betrachten Sie das UBA-Tool als dasjenige, das die Berichte ausführt und die Mittelwerte und Standardabweichungen für jeden Benutzer ermittelt und diese mit ihren Kollegen vergleicht und im Laufe der Zeit nur die Benutzer und Aktivitäten erfasst, die „aus der Masse herausragen“. Im Laufe der Zeit ermittelt UBA außerdem dynamisch  Mittelwerte, Standardabweichungen und andere Statistiken, sodass sie mögliche Veränderungen historischer Trends widergeben.

Hier eine mögliche Verhaltensregel als Beispiel: Benachrichtigung erfolgt, wenn ein Benutzer von seinem üblichen Verhalten beim Senden von E-Mails abweicht.

Genauer gesagt könnte man formulieren: „Benachrichtigung erfolgt, wenn ein Benutzer zwei oder mehrere Standardabweichungen von seinem Mittelwert aufweist“.

Wenn wir diese Regel annehmen, analysieren wir die horizontalen Zeilen — in diesem Fall habe ich einen herkömmlichen Online-Statistikfunktion verwendet — der zwei Benachrichtigungen ausgegeben hat, jedoch keine für Monika.

Benutzer Montag Dienstag Mittwoch Donnerstag Freitag Durchschnitt STDDEV AVG + 2SD
Andreas 10 8 30 15 13 15 7 29
Monika 15 29 55 33 90 44 24 92
Robert 35 6 7 15 16 16 10 35
Stefan 2 5 4 9 15 7 4 15
Ingo 9 1 3 5 0 4 3 9

Offensichtlich wird das in der Praxis nicht gemacht – es gibt bessere Statistiktests und es können aussagekräftigere Analysen durchgeführt werden.

Der entscheidende Punkt liegt darin, dass UBA durch die Suche nach Benutzern oder einer Benutzergruppe, sagen wir dieselbe Active Directory-Gruppe, echte Abweichungen präziser finden und eskalieren kann.