Challenges of Insider Threat Detection – Whiteboard Wednesday [englischsprachiges Video]

Die Erkennung und Eindämmung von Bedrohungen durch Insider erfordern ein umfassendes Verständnis der Benutzer für ihre Unternehmensdaten und der Art und Weise, wie sie auf diese Daten zugreifen.

In unserem ersten Whiteboard Wednesday spricht Drew Schuil, Vice President of Global Product Strategy bei Imperva, über die Herausforderungen der Erkennung von Insiderbedrohungen und über Ansätze zum Schutz sensibler Daten und großer Datenspeicher vor fahrlässigen, kompromittierten und böswilligen Nutzern.

Videotranskription

Willkommen bei Whiteboard Wednesday. Mein Name ist Drew Schuil, Vice President of Global Product Strategy bei Imperva. Das heutige Thema ist die Herausforderung der Erkennung von Insiderbedrohungen, insbesondere wenn es um sensible Daten und große Datenspeicher geht, wie Datenbanken, Big-Data-Systeme und Dateiarchive.

Insiderbedrohungsprofile

Wir beginnen mit Insiderdrohungsprofilen. Ich habe schon drei [auf dem Whiteboard], kompromittiert, fahrlässig und böswillig.

• Werfen wir zunächst einen Blick auf kompromittiert. Hierauf liegt der Schwerpunkt des Großteils der Sicherheitsbranche. Denken Sie bei kompromittierten Benutzern an solche, die auf einen Phishing-Link geklickt haben oder deren Endgerät auf andere Weise mit Malware infiziert wurde, wodurch sich der Angreifer innerhalb des Netzwerks befindet. Vielleicht bewegt er sich durch die Hierarchieebene des Unternehmens, sammelt Informationen, versucht die Speicherorte sensibler Daten zu finden und weitere Anmeldedaten zu kompromittieren, um Zugriff auf diese Daten zu erlangen. Wenn man sich die Sicherheitslösungen anschaut, die Unternehmen heute implementieren – Endgerätsicherheit, Sandboxing, Anti-Phishing – richten sich viele der Sicherheitslösungen wirklich an diesen Anwendungsfall. Sie versuchen, kompromittierte Benutzer schnellstmöglich zu finden und unter Quarantäne zu stellen.
• Zwei weitere Benutzerprofile, die häufig übersehen werden, sind nachlässige oder fahrlässige Benutzer. Denken Sie an einen DBA, der einen legitimen Zugriff auf das Netzwerk hat, aber Abkürzungen verwendet, um seine Arbeit zu erledigen. Vielleicht will er den Änderungskontrollprozess nicht durchlaufen und nutzt ein Anwendungsdienstkonto statt seines benannten Kontos, um sich mit der Datenbank zu verbinden. So ist praktisch nicht mehr erkennbar, wer dieser Benutzer ist, da er ein anderes Konto verwendet. Oft sind sich Unternehmen dieses Verhaltens überhaupt nicht bewusst, weil der DBA Zugriff auf alle Bereiche hat. Es ist ein Bereich, in dem die Sicherheitsabteilung nicht unbedingt versteht, was vor sich geht oder was vor sich gehen sollte. Im Allgemeinen werden keine Anzeichen für unvorsichtiges Verhalten erkannt.
• Bei böswilligen Benutzern ist es ähnlich. Diese Benutzer haben legitime Anmeldedaten und sind in der Lage, sich für die Arbeit einzuloggen. Vielleicht werden sie jedoch erpresst. Unter Umständen nehmen sie Informationen zu ihrem nächsten Job mit. Ponemon meldet, dass 69 % der ausscheidenden Mitarbeiter angeben, Daten mitzunehmen. Es ist nicht immer jemand wie Edward Snowden, aber vielleicht jemand, der nur Daten mit zum nächsten Job nimmt, weil er denkt, einen Anspruch darauf zu haben.

Mit Blick auf die letzten beiden Kategorien [fahrlässig und böswillig] denke ich, dass es in der Sicherheitsbranche Verbesserungspotenzial gibt. Man muss neue Technologien und neue Ansätze nutzen, um alle drei Anwendungsfälle zu lösen, nicht nur das Bedrohungsprofil durch kompromittierte Benutzer.

Warum ist die Erkennung so schwierig?

Warum also ist die Erkennung so schwierig … warum haben wir dieses Problem noch nicht gelöst? Warum kommen diese immens großen Sicherheitsverletzungen weiterhin vor … 60, 80 oder sogar 100 Millionen Datensätze gleichzeitig? Das kommt übrigens aus einer Datenbank, nicht aus einer Tabelle auf einem Laptop, der an einem Flughafen vergessen wurde. Das kommt aus einem riesigen Datenrepository im Unternehmen.

• Ein Teil des Problems ist, dass diese Benutzer legitimen Zugriff haben. Sie sind im Netzwerk, sie arbeiten dort. Wenn wir uns das anschauen, geht es nicht unbedingt um IAM [Identity and Access Management] und nicht um Zugriffskontrolle. Es geht wirklich um die Erkennung nach der Anmeldung. Ich muss sehen können, was der Benutzer getan hat, nachdem er sich angemeldet hat, und ob dieses Verhalten normal ist oder nicht. Das ist eine der größten Herausforderungen: gutes und schlechtes Verhalten zu verstehen. Wir stehen vor Millionen und Abermillionen von Transaktionen in einer Datenbank oder Big-Data-Umgebung. Wie unterscheiden Sie gut von schlecht?
• Was sind also einige der Ansätze, die die Leute verfolgen? Heute senden sie die Informationen in einigen Fällen an den SOC. Vielleicht durch Routingprotokolle, für die sie Korrelationsregeln schreiben. Vielleicht haben sie andere Sicherheitsschichten innerhalb der Umgebung, die sie versuchen zusammenzufügen, um das Gesamtbild zu verstehen. Aber in den meisten Fällen haben sie kein sehr gutes Bild vom Verhalten nach der Anmeldung. Daher können Sie gutes und schlechtes Verhalten nicht verstehen und das Ergebnis ist eine Alarmüberlastung. Im Falle der [Sicherheitsverletzung im Fokus] hatten sie Informationen, die sie innerhalb der SOC-Umgebung an ihr SIEM geschickt hatten, aber sie waren nicht in der Lage, sie zu finden. Sie konnten nicht an die umsetzbaren Daten gelangen.
• Das letzte Problem – und ich denke eines der größten – ist, dass diese großen Unternehmen Dutzende, Hunderte oder Tausende von Anwendungen in der Umgebung haben, die alle verschiedenen Geschäftseinheiten und Geschäftsanforderungen dienen. Sie haben ein Team, das Sicherheitsteam, das für die Entschlüsselung von gutem und schlechtem Verhalten der Benutzer, Anwendungen und anderer innerhalb des Unternehmens, die auf Daten zugreifen, verantwortlich ist. Daher ist der Mangel an Kontext nicht durch prädiktive statische Richtlinien oder die Kommunikation mit den Geschäftseinheiten lösbar. Man muss wirklich etwas Fortschrittlicheres haben, um das Gute und Schlechte verstehen und so die Alarme zu sortieren und diesem Team einen gewissen Kontext geben zu können, damit sie tatsächlich eine Quarantäne erzwingen und einer Insiderbedrohung nachgehen können, sobald sie erkannt wird.

Die Identifizierung von Sicherheitsverletzungen erfordert ein Verständnis der Benutzer und Daten

Wir haben Benutzerprofile besprochen. Lassen Sie uns als nächstes über Daten sprechen. Meiner Meinung nach geht es bei den Herausforderungen bei der Erkennung von Insiderbedrohungen im Grunde um die Schnittstelle von Benutzern und Daten. An dieser Stelle geschehen normalerweise Sicherheitsverletzungen im Zusammenhang mit Insiderbedrohungen.

Der Verizon Data Breach Investigations Report, der jedes Jahr herausgegeben wird, hat gezeigt, dass es in vielen der Fälle, in denen wir sehr, sehr große Mengen von Daten durch die Forensik und die Analysen sehen, ein Insider war. Jemand innerhalb des Unternehmens – nochmals, ein kompromittierter, fahrlässiger oder böswilliger Benutzer.

Datenattribute und Benutzerattribute

Wenn wir anfangen, über Big Data, Datenbanken und Dateisysteme, insbesondere Datenbanken, zu sprechen, gibt es viel mehr zu beachten als nur die IP-Adresse und den Benutzernamen. Wir wollen mehr über diesen Benutzer erfahren, woher er kam, welche Art von Anwendung er benutzt, zu welcher Abteilung er gehört – wirklich den Kontext dieses Benutzers, während er mit Daten interagiert. Wenn wir uns mit einigen dieser anderen Dinge – z. B. Datenbanktabelle, Schema, SQL-Vorgang, der auf der Datenbank ausgeführt wurde – beschäftigen, entfernen wir uns immer mehr aus der Komfortzone des Sicherheitsteams, das für den Schutz der Daten verantwortlich ist.
Auch hier haben wir das Problem mit dem Kontext. Es gibt nicht nur Hunderte oder Tausende von Anwendungen. Wir haben jetzt eine andere Sprache, die für dieses Sicherheitsteam nicht sehr vertraut oder bequem ist. Wir beginnen, uns mit dieser Datenmenge zu befassen. Das Wichtigste ist wirklich die Art der Daten, die wir umfassend verstehen müssen, um einige der vorher erwähnten Herausforderungen überwinden zu können.

Maschinelles Lernen ist keine Magie

Was machen alle in der Branche? Wenn Sie an der RSA Conference oder einer Sicherheitsmesse teilgenommen bzw. mit einem Anbieter gesprochen haben, haben Sie wahrscheinlich etwas über maschinelles Lernen gehört, oder wie maschinelles Lernen oder User Behavior Analytics (UBA) bei der Lösung dieses Problems helfen werden. In einigen Fällen, in sehr eng abgesteckten Anwendungsfällen, werden gute Leistungen erreicht und die Sicherheit wird stark verbessert. Am wichtigsten ist jedoch, zu beachten, dass maschinelles Lernen keine Magie ist. Es gibt kein Zaubermittel, das für gute Ergebnisse sorgt, wenn wir maschinelles Lernen oder künstliche Intelligenz für einen Datensatz verwenden. Man muss sich genau auf die Probleme konzentrieren, die es zu lösen gilt. Das leitet den nächsten Abschnitt ein, die wichtigsten Anzeichen für Missbrauch.

Wichtigste Anzeichen für Missbrauch

Wir hier bei Imperva haben einen messerscharfen Ansatz entwickelt, um Dinge wie Dienstkontomissbrauch, Rechnerübernahme und übermäßigen Datenbank- oder Dateizugriff zu identifizieren. Dies schließt ein umfassendes Verständnis dessen mit ein, wie Benutzer mit den Daten interagieren. Der Schlüssel für eine effektivere Nutzung von maschinellem Lernen und die Lösung des Insiderproblems ist ein umfassendes Verständnis der Schnittstelle zwischen Benutzern und Daten.

Insiderbedrohungen: Im Trüben fischen

Wir haben über maschinelles Lernen und User Behavior Analytics gesprochen und ich bin kurz auf vordefinierte, statische Richtlinien eingegangen. Die Herausforderung bei diesem Ansatz ist, selbst bei sehr granularen Möglichkeiten Richtlinien festzulegen, sodass man bei Alarmen und Blockierungen in Echtzeit im Trüben fischt. Beim bisherigen Ansatz für Insiderbedrohungen ging es vor allem um die Compliance. Zum Beispiel hatten PCI und Compliance einen sehr enggesteckten Rahmen für das Ziel ihrer Suche. Tatsächlich war die Umgebung normalerweise stark kontrolliert und häufig vom Rest der Umgebung getrennt.

Denken wir bei Insiderbedrohungen in einer breiteren Umgebung mit einem größeren Datensatz an die DSGVO, wo es um personenbezogene Daten geht, die sich überall im Unternehmen befinden können. Das Problem ist jetzt viel schwieriger. Wir müssen jede einzelne Änderung der Richtlinie und Variante der Richtlinienerstellung vorhersehen. Hierbei ist die Herausforderung, dass Sie Hunderte oder Tausende von Richtlinien erstellen, die Sie in der sich ständig ändernden Anwendungsumgebung pflegen müssen. Dies ist eine betriebliche Herausforderung für Unternehmen.

Statische Richtlinien lassen sich nicht skalieren

Andererseits ist es ein Problem, dass Insiderbedrohungen häufig unerwartet auftreten. Wir denken nicht über alle möglichen Variablen einer Richtlinie nach, die erstellt werden müssten, um sie zu finden. Wenn wir uns das Datenbankbeispiel ansehen und warum statische Richtlinien sich nicht skalieren lassen, müssen wir verstehen, wer sich wie mit der Datenbank verbindet. Verwendet er SQL*Plus, Toad, Aqua Data Studio oder ein anderes Tool, um sich mit der Datenbank zu verbinden? Auf welche Daten greift er zu? Habe ich schon einmal eine Datenklassifizierung vorgenommen? Kenne ich überhaupt den Kontext dieser Daten, um eine Richtlinie schreiben zu können? Was machen die Peers? Tut diese Person etwas, was niemand sonst in der DBA- oder IT-Gruppe – bzw. der Finanzabteilung oder einer sonstigen Gruppe – tut? Lässt sich dies als Teil der Korrelation verwenden? Wie viele Daten werden normalerweise abgerufen? Falls man keine Baseline und kein umfassendes Verständnis von SQL hat, kann es schwierig sein, die Datenmenge, Abfrage oder die von der Datenbank zurückgesandte Zeilenanzahl zu verstehen.

Wann funktionieren sie normalerweise? Das scheint ein ziemlich grundlegendes Problem zu sein. Aber um Insiderbedrohungen erkennen zu können, muss ich anhand dieser fünf, sechs Beispiele [Wer verbindet sich mit der Datenbank? Wie verbindet er sich? Auf welche Daten greift er zu? Greifen seine Peers auf gleiche Weise darauf zu? Wie viele Daten werden abgerufen? Wann funktionieren sie normalerweise?] und vieler anderer sowie aller möglichen Änderungen eine Korrelation durchführen können. Es wird eine echte Herausforderung. Im nächsten Abschnitt besprechen wir maschinelles Lernen, sehr fokussiertes maschinelles Lernen, damit man sich keine Sorgen über die Erstellung und Pflege von Hunderten oder Tausenden prädiktiven, statischen Richtlinien muss.

Insiderbedrohungen mit Imperva Data Security erkennen

Ich habe die Schnittstelle zwischen Benutzern und Daten erwähnt und die Bedeutung eines umfassenden Verständnisses der Dateninteraktionen der Benutzer für die Lösung dieses Problems. Imperva Datensicherheit  verwendet maschinelles Lernen, um das Verständnis aller Variablen zu automatisieren, sowohl Benutzervariablen als auch Datenvariablen, um ein umfassendes Verständnis zu erlangen. So können wir das Kontextproblem lösen, False Positives erkennen und müssen keine statischen, vordefinierten Richtlinien mehr erstellen.

• In einem der ersten Schritte identifizieren wir die Benutzer- und Verbindungstypen. Was bedeutet das? Eine der größten Herausforderungen unserer Kunden im Datenbankbereich ist die Unterscheidung zwischen Anwendungsdienstkonten, die auf die Datenbank zugreifen, und interaktiven Benutzern oder privilegierten Benutzern wie DBAs, da sie andere Leistungen erbringen und unterschiedliche Verantwortlichkeiten haben. Wenn wir die verschiedenen Benutzer und einige Unternehmen verstehen, ist das ein großer Fortschritt. Ich arbeitete mit einer großen Zahlungsabwicklungsfirma zusammen, die ein Problem mit einer übermäßigen Anzahl von Legacy-Verbindungen in der Datenbank hatte. Man konnte die einzelnen Verbindungen und Benutzer nicht auseinanderhalten. Durch eine automatische Differenzierung anhand von Verhaltensstatistiken und Algorithmen kann man jedoch beispielsweise Dienstkonten erkennen, da sie aufgrund der Geschwindigkeit als anwendungsbasiert identifiziert werden können. Anhand der Differenzierung kann man auch sagen, dass es sich um einen DBA handelt, der sich mit der Datenbank verbindet.
• Sobald wir die Verbindungstypen verstanden haben, was für Unternehmen häufig ein großer Fortschritt ist, wollen wir den typischen Zweck des Kontos anhand der Art und Weise des Datenzugriffs bestimmen. Wir wissen bereits, dass es sich um ein Anwendungskonto handelt. Nun sehen wir, dass es auf Anwendungen mit sensiblen Daten zugreift. In der Regel handelt es im Namen von Benutzern, z. B. auf einem Gesundheitsportal, das mit der Anwendung interagiert und sensible personenbezogene Daten aktualisiert. Wir sehen bestimmte Datenbankvorgänge und SQL-Aufrufe. Wir erhalten bestimmte Tabellen in der Datenbank und können diese auf granularer Ebene einordnen. Bei einem umfassenden Verständnis der Daten geht es mir darum – nicht nur um die Verbindung, sondern auch mit welchen Daten die Vorgänge, im Wesentlichen die SQL-Vorgänge, durchgeführt werden. Es handelt sich also um eine dynamische Datenklassifizierung.
• Ebenso sehen wir, wie DBAs mit der Datenbank interagieren. Sie müssen die Leistung und die Verfügbarkeit beibehalten, daher greifen sie normalerweise auf Metadaten zu. DBA-Benutzer sollten nicht die gleichen Vorgänge in Tabellen durchführen wie Anwendungen. Mit Imperva Data Security werden DBAs entdeckt, die für einen längeren Zeitraum auf diese Daten zugreifen und so ein gutes Verhaltensprofil aufbauen, die plötzlich auf sensible Daten zugreifen, die laut Profil zu einer Anwendung gehören.

Ich hoffe, dass Ihnen die Sitzung gefallen hat. Ich hoffe, dass sie nützlich war. Schalten Sie zum nächsten Whiteboard Wednesday wieder ein.