Unsere
Kontaktmöglichkeiten:

+49 (0)2225 988 0Montag bis Freitag9:00 bis 17:00 Uhr
FAQ die häufigsten
Fragen in der Übersicht
BWI GmbH
Auf dem Steinbüchel 22
53340 Meckenheim
Erkennung von Insider-Bedrohungen durch Realtime-Log-Analytics© Collage: BWI GmbH/ Oliver Kunkel /Adobe Stock/Ar_TH
TECH CORNER - DEEP DIVE Managed Cyber-Sicherheit von Pierre Rosengaft

Erkennung von Insider-Bedrohungen durch Realtime-Log-Analytics

5 min
30. Oktober 2023

Etwa 25 Prozent aller Bedrohungen der Cyber-Sicherheit sind auf Insider zurückzuführen. Die jährlichen Kosten von betroffenen Unternehmen sind seit 2020 um 34 Prozent auf etwa $15,4 Millionen angestiegen. Eine enorme Steigerung, die auf Abhilfe wartet.

Auch die Häufigkeit derartiger Vorfälle, so der 2022 Cost of Insider Threats Global Report des Ponemon Instituts, ist in den vergangenen Jahren um 45 Prozent auf etwa 6.800 Fälle gestiegen. Unternehmen sind im Durchschnitt 85 Tage damit beschäftigt, Insider-Vorfälle einzudämmen. Hier besteht also großes Potenzial für Systeme, die derartige Vorfälle in einem Unternehmen aufdecken können. Eine Insiderbedrohung liegt vor, wenn ein Mitarbeiter oder eine Partnerfirma die zugeteilten Berechtigungen missbraucht, um beispielsweise Schaden auf Systemen anzurichten oder Datendiebstahl zu begehen.

BWI Data Analytics Hackathon greift Bedrohung auf

Das Thema der Cyber-Bedrohung im Inneren wurde im Rahmen einer der Challenges des BWI Data Analytics Hackathon aufgegriffen. Die Aufgabenstellung lautete: “Wie kann ein Prototyp aussehen, der Insiderbedrohungen durch den Einsatz von Data Analytics aufdeckt?”.

Als Datengrundlage diente ein synthetischer Testdatensatz für Insider-Bedrohungen von Lindauer, Brian (2020) der Carnegie Mellon University, gesponsert von der DARPA. Während des Hackathons wurden innerhalb kürzester Zeit Prototypen zur Lösung einer Problemstellung durch den Einsatz von Data Analytics realisiert und präsentiert. Im Folgenden wird die Siegerlösung vorgestellt.

Infobox

Mit dem Data Analytics Hackathon kommt die BWI dem Wunsch der Bundeswehr nach, die gemeinsame Arbeit an IT-Lösungen voranzutreiben. Seit mittlerweile vier Jahren kommen Interessierte in der letzten Novemberwoche zusammen und tüfteln in Teams an Ideen, um die Streitkräfte und Deutschland nachhaltig zu schützen und zu stärken. Die Lösungen werden anschließend von einer Jury bewertet und gegebenenfalls von der BWI begleitet und weitergeführt.

Vorgehen: Datenanalyse und Dimensionen

Der Datensatz für die Insider-Bedrohungen enthält synthetisierte Log-Informationen für einen abgegrenzten Zeitraum. Er besteht aus protokollierten Informationen, wie das An- und Abstecken eines USB-Geräts an einen Computer oder die Webseitenaufrufe eines Nutzers. Mit diesem Ansatz wird die Hypothese aufgestellt, dass das Verhalten einer maliziösen Insider-Aktivität von dem Normalverhalten, dass einen Großteil der Datengrundlage darstellt, signifikant abweicht (Anomalie). Ein Beispiel hierfür ist ein Nutzer, der außerhalb der Bürozeiten einen USB-Stick an einen fremden Rechner ansteckt, um Daten zu entwenden.

Mit statistischen Verfahren lassen sich solche Anomalien in Daten erkennen. Zwei Ansätze sind Isolation-Forest [sklearn] und die Hauptkompontenanalyse (PCA). Für einen Hackathon üblich, wurden beide Ansätze ohne große Auseinandersetzung mit der Datengrundlage getestet. Die Erkenntnis war, dass sich ohne eine Auseinandersetzung mit der Fachdomäne und der Datengrundlage keine großen Mehrwerte aus der Analyse ziehen lassen.

Also zurück an das Zeichenbrett! Worauf kommt es hier aus Sicht eines Unternehmens an?

  • Insider sollen in Echtzeit aufgedeckt werden, um die Zeit der Eingrenzung zu reduzieren.
  • Es gibt begrenzte, aber flexible Kapazitäten, diesen Bedrohungen nachzugehen.
  • Mit der Eingrenzung beauftragte Mitarbeiter möchten die Bedrohungen in einem Dashboard dargestellt bekommen.
  • Der Datenschutz ist relevant: Es soll keine People Analytics durchgeführt werden.

Damit stellt sich die grundlegende Frage wie kann die Datengrundlage genutzt werden, um Insider aufzudecken? Bei dieser Betrachtung ist relevant, welche Daten zur Laufzeit der Realtime-Analyse zur Verfügung stehen werden. Bevor darauf eingegangen wird, erfolgt noch eine kurze Abgrenzung zu dem Thema Realtime: Aus Sicht der Datenverarbeitung ist eine Analyse in Realtime physikalisch gar nicht möglich. Die eigentliche Verarbeitung erfolgt aufgrund der Latenzen der beteiligten Komponenten höchstens in Near-Realtime. Der Begriff „Realtime-Analyse“, wie er hier verwendet wird, zeichnet sich vielmehr dadurch aus, dass aktuelle „Realtime-Daten“ für die Analyse verwendet werden, sobald diese in das System gelangen.

In dem Zusammenhang können zunächst drei mögliche Dimensionen identifiziert werden:

     1. Zeit: Die Aktivität findet außerhalb oder während der Bürozeiten statt.

     2. PC: Die Aktivität findet auf dem eigenen oder einem fremden PC statt.

     3. Aktivität:

          3.1 Die Aktivität ist der Besuch einer potenziell maliziösen Webseite.

          3.2 Die Aktivität ist das Anstecken eines USB-Sticks.

Dabei gilt: Eine anomale Dimension stellt noch keine Bedrohung dar. Mitarbeiter surfen auch außerhalb der Bürozeiten. Ein PC kann auch aufgrund von Urlaubsvertretung gewechselt werden. Auch die tägliche Arbeit kann die Nutzung von USB-Geräten erfordern. Aktivitäten werden also erst interessant, wenn mehrere Dimensionen eines Datenpunkts auffällig sind.

Realisierung als Realtime-Analytics-System

Im nächsten Schritt wurde ein System modelliert, dass die ermittelten Anforderungen und Ziele realisiert. Der Entwurf hierfür sah wie folgt aus:

© BWI GmbH /Pierre Rosengaft

Mit dem Ansatz wird ein Scoring-System realisiert. Jede identifizierte Dimension wird einzeln mit jedem Datenpunkt betrachtet und bewertet. Die Bewertungen werden im letzten Schritt zusammengeführt, um eine Aussage über die Aktivität insgesamt zu treffen. Durch Stream Processing wird jede Aktivität einzeln in Echtzeit bewertet, sobald sie in das System eintrifft.

Das Scoring wird über einen Dataflow realisiert, um sowohl die Streaming Daten einzubinden als auch ein Backtesting des Scoring-Systems auf Batch-Daten zu ermöglichen. Die Dimensionen werden für die Bewertung an ein Backend gesendet. Das Backend legt fest, wie hoch der Score für die einzelne Aktivität ausfällt. Es soll jedoch auch betrachtet werden, dass sich das Normalverhalten im Unternehmen im Laufe der Zeit ändern kann. Beispielsweise kann ein Standort in einer anderen Zeitzone eröffnet werden oder Mitarbeiter intern die Stelle wechseln.

Bewertung der Aktivitäten

Zunächst wird der Zeitpunkt betrachtet, an dem die Aktivität stattfindet. Mithilfe der Boxplots (siehe Abbildung unten) erfolgt die Darstellung der Aktivitäten auf der Zeitachse (heruntergebrochen auf Tage und Stunden).

© BWI GmbH /Pierre Rosengaft

Das Scoring-System ermittelt also, wie viele Aktivitäten an der Stunde eines Tages stattfinden.

Das Vorgehen ist für die Bewertung der Webseite ähnlich. Zur Erinnerung: Ziel ist es ein anomales Verhalten identifizieren. Daher werden beispielsweise keine statistischen Link-Listen eingesetzt. Derartige Link-Listen können jedoch als externes System in das Scoring-System einbezogen werden. Die Betrachtung hier zeigt alle besuchten Webseiten. Diese sind dann absteigend sortiert. So wird die am wenigsten angesteuerte Webseite als Aktivität mit dem höchsten Score versehen, während die am geringsten angesteuerte Website einen Score erzeugt, der gegen null geht.

Etwas aufregender ist die Betrachtung der Verbindung von USB-Geräten. Mit dem Scoring-System wird die Annahme getroffen, dass grundsätzlich jedes Einstecken eines USB-Geräts maliziös sein kann. Es gibt jedoch Nutzerrollen, die häufiger USB-Geräte einstecken. Das zeigt die folgende Abbildung:

Distribution of USB Device Connection © Pierre Rosengaft

Es ist zu erkennen, dass mehr als zwei Drittel aller USB-Verbindungen auf die Mitarbeiter von vier Rollen zurückzuführen sind. Für den Score bedeutet das: Verbindet ein Tradesman ein USB-Gerät wird das niedriger bewertet, als wenn ein VP ein USB-Gerät verbindet.

Besonders spannend wird die Bewertung der PC-Nutzung. An dieser Stelle findet auch die einzige Auswertung auf Nutzerebene statt. Um die PC-Nutzung einer Aktivität zu bewerten, wird eine Liste mit allen Nutzer-PC-Paaren gebildet. Taucht die Kombination aus Nutzer und PC einer Aktivität nicht in dieser Liste auf, dann hat der Nutzer den PC in der Vergangenheit noch nicht genutzt. Im Beispiel hier wird dies als maliziös betrachtet. Wie auch bei den USB-Verbindungen gibt es bei der PC-Nutzung tätigkeitsbedingt signifikante Unterschiede bei den Rollen. Die folgende Abbildung stellt das heraus:

Amount of unique PCs used per Role © Pierre Rosengaft

Es wird deutlich, dass sich IT Admins mit großem Abstand auf den meisten PCs anmelden. Für den Score bedeutet das: Eine Aktivität auf einem neuen PC wird als maliziös betrachtet. Der Score wird jedoch um einen rollenbezogenen Faktor reduziert.

Nutzerverhalten im Laufe der Zeit

Wie kann man bei alle dem berücksichtigen, dass sich die Daten im Laufe der Zeit ändern werden? Grundlegend kann man die Berechnung der hier ermittelten Faktoren auf einen Zeitraum der letzten n Tage beschränken. Hierfür wurde im Backend ein API-Endpunkt angelegt, der ad hoc die ermittelten Faktoren neu berechnet.

Mit dem letzten Schritt werden dann alle Scores addiert. Überschreitet der Gesamtwert des Scores einen Schwellwert, werden die Aktivitäten in einer Datenbank abgelegt und in einem Dashboard dargestellt. Dieses Dashboard gibt dem Bearbeiter einen Überblick über alle identifizierten Bedrohungen.

Fazit

Anhand eines Testdatensatzes kann gezeigt werden, wie ein prototypisches System für die Realtime-Erkennung von Insider-Bedrohungen aussehen kann. Das System betrachtet jede Aktivität als Einzelereignis und bewertet die Dimensionen der Daten mithilfe von simplen Scoring-Algorithmen, um letztlich einen Gesamtwert für den Score zu ermitteln. Da ausschließlich die Anomalität des Nutzerverhaltens bewertet wird, besteht für Akteure, die Kenntnis über das Bewertungsverfahren erlangen, die Möglichkeit, dieses gezielt zu umgehen. Eine Möglichkeit das System weiter zu härten ist die Einbindung von zusätzlichen Verfahren, die als externe System eingebunden werden, um auf den Score Einfluss zu nehmen. Ein Beispiel ist die Nutzung der bereits angesprochenen statischen Link Listen für gefährliche Webseiten oder der Einsatz von regelbasierten Intrusion-Detection-Systemen.

Wie kann man bei all dem berücksichtigen, dass sich die Daten im Laufe der Zeit ändern werden? Grundlegend kann man die Berechnung der hier genutzten Faktoren auf einen Zeitraum der letzten n Tage beschränken. Hierfür wurde im Backend ein API-Endpunkt angelegt, der ad hoc die verwendeten Verteilungen frisch berechnet.

Da jede Aktivität einzeln bewertet wird, sind die Anforderungen an den Durchsatz sehr hoch. Mit dem hier vorgestellten Prototyp ergibt sich ein Flaschenhals durch die Verwendung von synchronen REST-Anfragen für die Bewertung jeder Aktivität. Hier kann der Durchsatz erhöht werden, indem beispielsweise das System vollständig In-Memory realisiert wird. Die Implementierung als vollständiges In-Memory-System ist ebenso wie die ursprüngliche Variante auf Github zu finden. Die ermittelten Faktoren werden extern berechnet und in einem Redis Store abgelegt. Der Dataflow aktualisiert die In-Memory Faktoren regelmäßig mit dem Redis Store. Dieser Ansatz ist ist ähnlich zum Konzept eines sogenannten Feature Stores, der mittlerweile eine zentrale Rolle in Machine-Learning-Systemen einnimmt.

Autor: Pierre Rosengaft/Associate Expert - DevOps/MLOps

Pierre ist seit 2020 bei der BWI und arbeitet im Center of Excellence Software Engineering in der Abteilung Software Data Solutions & Analytics. Mit seiner Master-Thesis hat er einen Ansatz zur Gestaltung von Realtime Machine-Learning-Systemen auf der Cloud entwickelt. Aktuell arbeitet er an dem Aufbau einer Data Analytics und Big Data Platform auf der private Cloud der Bundeswehr (pCloudBW).

Das könnte Sie auch interessieren:
 

 
 BWI bereitet sich auf quantensichere Kryptographie vor

Post-Quanten-Kryptografie
2 min
16. April 2024

BWI bereitet sich auf quantensichere Kryptographie vor

#Bundeswehr

#Digitale Verteidigungsfähigkeit

In nicht allzu ferner Zukunft werden die ersten Quantencomputer auf den Markt kommen. Diese bedrohen die Sicherheit heutiger Public-Key-Verfahren, eingesetzt für asymmetrische Verschlüsselung und Signaturen. Im Bereich der Post-Quanten-Kryptographie…
2 min
16. April 2024
 
Schnellere Softwareentwicklung für die Bundeswehr – die „Platform42“ der BWI

Software Defined Defence
3 min
13. Februar 2024

Schnellere Softwareentwicklung für die Bundeswehr – die „Platform42“ der BWI

#Bundeswehr

#Digitale Verteidigungsfähigkeit

Digitalisierung wird für die Fähigkeitsentwicklung der deutschen Streitkräfte immer wichtiger – und immer drängender. Software kommt dabei eine besondere Bedeutung zu, da sich mit ihr Systeme schneller aktualisieren lassen. Eine neue Plattform der…
3 min
13. Februar 2024

Sie werden auf eine externe Seite weitergeleitet:

Akzeptieren
Ablehnen

Diese Einstellung kann in unseren Datenschutzhinweisen erneut konfiguriert werden. In den Cookie-Einstellungen können Sie ihre Einstellungen mit Wirkung auf die Zukunft wiederrufen.