Was hat Jurassic Park* mit IT Compliance zu tun?

Meinen aktuellen Compliance Overview Vortrag beginne ich mit folgender Frage:

Warum ist ein fiktives, multi-milliarden Dollar Projekt so phänomenal gescheitert?

[Nein, du hast kein Déjà-vu, das ist kein Glitch in der Matrix, Agent Smith ist nicht hinter dir her – wobei, vielleicht ja doch!?
Meine Story „Was hat Jurassic Park* mit IT Security zu tun?“ hat nämlich auch eine Compliance Seite und die beleuchte ich hier!]

?tl;tr / Executive Summary (Klick zum Öffnen)

Für die Eiligen unter euch (Achtung SPOILER!):
Jurassic Park ist u.a. wegen eines Insiders gescheitert, der für sein eigenes Heil die „Kronjuwelen“ verkauft hat – also ein „Insiderjob“.
Dagegen gibt es zwei Verteidigungsmöglichkeiten:

1. Auswirkungen von Datenextraktion minimieren
2. Insider*innen rechtzeitig und automatisiert erkennen, um Gegenmaßnahmen zu ergreifen

Und wer jetzt doch Lust auf den ganzen Artikel hat:

Bevor ich auf den „IT Compliance“ Teil eingehe, möchte ich kurz an den Plot des ersten Jurassic Park Films/Buchs erinnern:

Wissenschaftler haben aus Mücken, die vor Millionen Jahren in Bernstein eingeschlossen wurden, Dinoblut und damit Dino-DNA extrahiert und diese zum Klonen von Dinos verwendet.
Um damit ein Business aufzubauen wurde ein multi-milliarden $ Zoo/Park gebaut, um die Dinos der Menschheit zu präsentieren.

Zwei inhaltliche Stränge führten nun zum Versagen des Systems „Jurassic Park“:

1. Fehlerhafte Annahmen, vgl. Was hat Jurassic Park* mit IT Security zu tun?
2. Verrat und eigene Interessen eines Insiders – „Dennis Nedry“. Der ITler
   Dennis war unzufrieden und daher offen für Bestechung und die Weitergabe von Geschäftsgeheimnissen und sogar Geschäftsergebnissen/Prototypen in Form von Dino Eiern.

Im weiteren Verlauf des Films war es Dennis schlicht nicht mehr wichtig, dass das Unternehmen/Projekt überlebt, sondern das Einzige was zählte war sein persönlicher Gewinn (Geld).

In jedem Unternehmen existiert das Risiko, dass ein (unerkannter) Insider User wie Dennis existiert!

Stephanus

(Ich definiere „Insider“ als User*innen, die ein akutes oder zumindest latentes Risiko für das Unternehmen in sich tragen.)

Jetzt mag der erste Reflex sein: ja, gegen einen Insider konnte ja noch nicht mal die NSA was tun!

Stimmt, die NSA hatte offensichtlich keine Mechanismen eingesetzt, um Insider zu identifizieren.
Das heißt, um nicht selber Opfer zu werden, sollte das Thema „Insider Risk Management“ gestartet werden:

Bevor wir nun also Lösungen anstrengen, müssen wir uns überlegen

„was macht eigentlich eine ‚Insider*in‘ aus“?

1. Es ist eine legitime User*in der bereitgestellten (IT) Systeme
2. Vordergründig handelt es sich um eine verantwortungsvolle und loyale Mitarbeiter*in
3. Während der normalen Arbeitszeiten, aber in vermeintlich unbeobachteten Momenten werden Systeme manipuliert, Kolleg*innen und Kund*innen unterschwellig negativ beeinflusst, um in die Lage zu kommen Daten und Produkte unerlaubt zu extrahieren und ggf. den Geschäftsablauf zu stören

Wenn das o.g. „Nutzerprofil“ zugrunde gelegt wird, dann ist eine Insider*in ohne weitere Maßnahmen häufig erst dann zu erkennen, wenn es leider zu spät ist – so fern der Datendiebstahl/missbrauch überhaupt auffällt.

Ein aktuelles Beispiel ist ein ehemaliger Mitarbeiter von Intel, der zu Microsoft gewechselt ist und dort geheime Daten auf einem USB Stick mitgebracht hat. Solche Informationen zu nutzen verstößt gegen Microsoft Richtlinien und wurde daher schnell bekannt und es wurde entsprechend konsequent reagiert und Intel informiert. Leider ist eine derart schnelle Aufdeckung eher die Ausnahme, wenn nämlich Daten in Kanäle gelangen in denen Interesse an deren Verwertung besteht.

Daher heißt es, dass wir Dinge anders machen müssen- und da möchte ich zwei parallel mögliche Ideen verfolgen:

1. Auswirkungen von Datenextraktion minimieren
2. Insider*innen rechtzeitig und automatisiert erkennen, um Gegenmaßnahmen zu ergreifen

Fangen wir mit Punkt 1. an:

Auswirkungen von Datenextraktion minimieren

Damit extrahierte Daten „eingefangen“ und nach Erkennung der Gefahr unbrauchbar gemacht werden können, müssen diese vor der Extraktion klassifiziert und verschlüsselt werden.
Stichworte dazu: „Microsoft Information Protection“ (MIP), „Sensitivity Labels„, „Azure Information Protection“ (AIP) und Data Loss Prevention.
Zu Klassifizierung und Verschlüsselung habe ich schon mehrmals geschrieben und möchte ich hier auch gar nicht weiter vertiefen.
Ergänzend möchte ich allerdings noch hinzufügen, dass sich die Technologie mit Endpoint DLP und Azure Purview auch auf den Endpoint und die SQL Server (u.a.) weiterentwickelt hat.

Nur so viel zum Abschluss von Punkt 1.: wenn die sensitiven Dokumente korrekt gelabelt sind und damit im richtigen Moment auch über Rights Management verschlüsselt sind, dann können diese, sobald der Insider das Unternehmen verlassen hat, unbrauchbar gemacht werden, bzw. wenn seine Identität eh durch Austritt aus dem Unternehmen erloschen ist [ups, hat jemand daran gedacht die Identität zu deaktivieren???], dann hat sie* keinen Zugriff mehr auf die Inhalte, egal *WO* die Dokumente physikalisch liegen.

Kommen wir also zu Punkt 2., dem viel Wichtigeren:

Insider Risk Management

Alle Konzepte und Technologien hier zu vertiefen würde den Umfang des Blogposts sprengen, daher gehe ich nur auf die wichtigsten und spannendsten ein um unseren „Dennis“ einzubremsen:

Interessant ist, dass es tatsächlich mehrere Ansatzpunkte für die Erkennung von Insidern gibt, die sich alle auf eine Sache subsummieren lassen:

(leicht) verändertes Verhalten.

Bei Insidern lässt sich zum einen erkennen, dass sie sich verhalten wie ein „typischer Angreifer“, der bereits mit einer gekaperten Identität im Unternehmen unterwegs ist und zum anderen, dass sich ihr* Kommunikationsverhalten und auch die verwendete Sprache wandelt.

Bsp: Ein unzufriedener Mitarbeiter verändert auch das Wording hin zu stärkeren Ausdrücken, die vorher nicht verwendet worden sind:
„…mein schei** Chef…“

Oder sie* spricht nicht mehr von „wir haben…“, wenn es um Unternehmensthemen geht, sondern nur noch von „Contoso hat…“.

Abwehrmaßnahmen zu Punkt 1 kennen wir bereits aus der „Security“ und dort u.a. aus der Identity Protection und Microsoft Cloud App Security (z.B.: Mass download by a single user).
Diese Maßnahmen werden bei IRM noch zusätzlich erweitert um Signale bezogen auf den Inhalt.
Sprich z.B.: „hat der Mitarbeiter viele Downloads mit besonders schützenswertem Inhalt in kurzer Zeit durchgeführt“.

Zur Erkennung und Alarmierung von Punkt 2 gibt es die „Communication Compliance“ Mechanismen, die übrigens auch das Thema Mobbing adressieren können – insb. auch in Zeiten von vorgeschriebenem Homeoffice.

Kommen nun die Signale von beidem zusammen, dann ist mit sehr hoher Wahrscheinlichkeit eine Insider*in identifiziert worden.

Wie sieht das nun technisch aus?

Wie genau die einzelnen Bereiche sich verhalten, damit möchte ich hier gar nicht anfangen (Überblick, Alerts, Cases, Policies, Users, Notice Templates), sondern nur mal zeigen, wie ein detektierter Case aussehen würde:

Zu dem Thema gab es eine Ignite 2020 Session: An in-depth look at intelligently managing insider risks with Insider Risk Management | OD295 – YouTube.

Was lernen wir also aus dem Fall Jurassic Park?

In jedem Unternehmen gibt es einen „Dennis“ (nein, ich meine natürlich die Persona und nicht die Person oder den Namen! 😉 ).
Die Frage, die sich gestellt werden muss, ist: wie groß ist das Risiko und welches sind die RICHTIGEN (ersten) Schritte um dies einzudämmen!?

Meine Empfehlung lautet daher wie folgt:

1. Erstellen eines Konzeptes für eine hinreichende Datenklassifizierung. Ohne diese wird es nicht funktionieren und ohne wird auch das Thema DSGVO schwierig werden.
   Das ist also eine Maßnahme, die „eh gemacht werden muss“ bzw. eigentlich „eh schon gemacht worden sein sollte/müsste“.
   Pro Tipp: Hierbei können Microsoft Partner insb. auch unter zur Hilfenahme des „Compliance Workshops“ aus den bekannten Microsoft Cloud Acceleratoren unterstützen!
2. Basierend auf dem Konzept der Datenklassifizierung die Umsetzung für eine unterstützende und ggf. automatisierte Klassifizierung.
3. Da nun alle notwendigen Sensordaten für effektives Data Loss Prevention (DLP) aktiviert wurden, kann nun die vorhandene Labeling und Klassifizierungsstruktur genutzt werden um über ALLE Bereiche (Mail, Dateiablage, Endpunkt, Datenbanken, Cloud Apps) DLP zu aktivieren
4. Alle relevanten und Business (kritischen) Apps müssen über einen zentralen Authentification Point laufen. Sprich alle Anwendungen – in der Cloud oder on-prem, direkt oder über App Proxy – müssen an Azure AD angeschlossen werden, um diese zentral zu steuern und die Governance sicherzustellen.
5. Nachdem 4. gemacht worden ist kann über Microsoft Cloud App Security relevante Policies definiert werden, die die korrekte Klassifizierung und Verschlüsselung von Daten aber auch die Detektion von ungewöhnlichem und ungewolltem Verhalten steuern.
6. Und last but not least führen alle diese Maßnahmen unweigerlich dazu, dass ein System wie „Insider Risk Management“ eingeführt werden muss um aus der Masse der vorhandenen Daten relevante Insides und daraus folgend ggf. Cases zu erstellen und Insider zu identifizieren und unschädlich zu machen!
   

*“Jurassic Park“ ist geistiges Eigentum der Universal Pictures, siehe https://upig.de/micro/jurassic-park