Was hat Jurassic Park* mit IT Security zu tun?

Update: jetzt auch den zweiten Teil lesen: Was hat Jurassic Park* mit IT Compliance zu tun?

Meinen aktuellen Security Overview Vortrag beginne ich mit folgender Frage:

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

Die meisten Menschen haben sich darüber meist keine wirklichen Gedanken gemacht – ich möchte hier meine Sicht darauf und was dies mit dem aktuellen Verhalten bei dem Thema IT Security zu tun hat darlegen.

Meine Antwort auf die obige Frage lautet:

Die Betreiber hatten eine Annahme, welche sie nicht ausreichend überprüft haben und sich darauf verlassen, dass diese Annahme zu jedem Zeitpunkt richtig ist.

Stephanus Schulte

Die Annahme, von der ich spreche, ist folgende:

„Wir haben die Dinos unfruchtbar gemacht!“

Die Wissenschaftler von Jurassic Park

Im Film (und auch im Buch btw.) wird dargelegt, dass die Betreiber des Parks viel dafür getan haben um ihr kostbarstes Gut – nämlich die einzelnen Dinos – zu schützen: sie haben schöne Gehege erbaut, diese mit vermeintlich ausreichenden Sicherungsmaßnahmen (insb. Wände/Wälle und Türen/Toren) ausgestattet und ihre Sensorik darauf ausgelegt zu überprüfen, dass auch ja die erwartete Anzahl an Dinos vorhanden ist.
Letzteres haben sie insb. dadurch gemacht, dass sie die Dinos gezählt haben und immer, wenn die erwartete Anzahl festgestellt worden ist, haben sie aufgehört zu zählen, denn es konnten ja gar nicht mehr als diese Anzahl sein.

Und genau dieses Vorgehen hat dazu geführt, dass die Story eskalieren konnte.

Wenn man die obige Beschreibung mal ohne das Wort „Dino“ liest, dann fällt einem auf, dass dieselbe Beschreibung auch sehr gut auf aktuelle IT Systeme passt:

Diese werden gerne durch Firewalls abgegrenzt, die Anti-Viren Lösungen schauen meist brav auf das was sie schon kennen (aka AV Pattern) und es wird nur wenig bis gar nicht darauf geachtet, wie viele Identitäten sich innerhalb des Netzwerks frei bewegen und ob all diese Identitäten auch tatsächlich dem entsprechen, was man bewusst „frei gelassen“ hat. Von der Überwachung der besonders großen Dinos – ähm, Admins – wird eh nicht viel gehalten! 😉

Wie können wir also sicherstellen (oder zumindest das Risko minimieren), dass unser Park Unternehmen der nächste Bestseller einer wahren Gegebenheit wird?

Und auf diese Frage gibt es eine klare Antwort und ein entsprechendes Vorgehen:

Man muss Dinge einfach mal anders machen!

Und das Vorgehen dazu heißt „Zero Trust„!

Und dies möchte ich nachfolgend darstellen (kein Anspruch auf Vollständigkeit, ich möchte hier Lust auf das Konzept machen und dazu aufrufen sich diesem zu nähern):

Die Idee hinter Zero-Trust bedeutet:

Traue nichts und niemandem und überprüfe zu jeder Zeit ob deine Annahme, dass alles in Ordnung ist, noch zutrifft, bzw. stelle sicher, dass jedes Objekt, jede Identität und jedes Verhalten nicht negativ ist und gehe immer davon aus, dass etwas passiert sein könnte.

Hätten die Betreiber des Jurassic Parks sich an dieses Konzept gehalten, dann wäre es vielleicht nicht zu dem spannenden Film/Buch gekommen.

Was heißt das nun für uns in der IT?
Dazu müssen wir uns zuerst die sog. Zero Trust Annahmen (Zero Trust Assertions) klar machen:

1. Das Netzwerk und jede Komponente werden immer als feindselig angenommen!
2. Externe und interne Bedrohungen gibt es im Netzwerk zu jeder Zeit! („Assume breach“)
3. Die Netzwerklokalität reicht nicht aus, um das Vertrauen in ein Netzwerk zu entscheiden. (VPN hilft nicht!)
4. Jedes Gerät, jeder Benutzer und jeder Netzwerkfluss wird authentifiziert und autorisiert.
5. Richtlinien müssen dynamisch sein und aus so vielen Datenquellen wie möglich berechnet werden.

Manch einer mag nun denken „Ja, aaaabbbeeerrr….. [wie sollen wir denn so arbeiten]“

Wenn der Schutz meines Netzwerks darauf basiert, dass die Firewall+DMZ, der Anti-Virus und mein Intrusion Detection System mich vor allen (typischen) Angriffen schützt – dann muss man offensichtlich umdenken und anders agieren.
D.h. wir benötigen dazu neue Mechanismen und Systeme, die ggf. aktuell noch gar nicht vorhanden sind und wo ich heute auch noch kein Personal habe, die sich damit auskennen:

1. User authentication
2. Device authentication
3. Trust score
4. Rules engine
5. Enforcement point

Hört sich jetzt erstmal ziemlich komplex und schwierig an – jedoch gibt es ein mächtiges Werkzeug innerhalb von Azure AD, mit dem ich diese Punkte sehr schnell als ersten Schritt umsetzen kann:

Conditional Access

Bei Conditional Access geht es darum, dass bei dem Zugriff auf eine Unternehmensresource Azure AD (AAD) als „Single point of authentication“ zwischengeschaltet ist – und dabei meine ich „single point“ und das heißt auch für alle anderen Web/Cloud Dienste, nicht nur die von Microsoft! Also auch Dinge wie AWS, Salesforce, Workday, Successfactors, etc, etc!

Wenn also AAD zwischengeschaltet ist, kann auf Basis der Eigenschaften eines Requests (Condition), also z.B. das „Wer“, „Womit [Device|App]“, „woher“ und zusätzlicher Sensorik und Wissen (aka Big Data) entschieden werden, wie ein Zugriffswunsch behandelt wird.

Beispiel 1:

Nehmen wir an die Assistenz der Geschäftsleitung greift von ihrem festen Arbeitsplatzrechner Montagsmorgens um 9:12h auf das Unternehmens Portal zu.

Als Conditions sehen wir in diesem Beispiel folgendes:

1. Wer: Max Mustermann (MM), FTE, Bereich HQ, Assistenz der GL, Mitglied der Gruppen A, B, C
2. Womit: IT managed Notebook, Compliance Status: grün, da alle Settings und Patchstand gemessen und bestätigt
3. Woher: internes Unternehmensnetzwerk
4. Zusätzliche Sensorik:
   1. MM hat in den letzten Wochen 47-mal auf diese Resource zugegriffen
   2. Andere in MMs Umfeld haben in den letzten Wochen 2931-mal auf diese Resource zugegriffen
   3. MM hat typischer Weise immer aus dem lokalen Netzwerk auf diese Resource zugegriffen
   4. MM hat meist Wochentags zwischen 8 und 17h auf diese Resource zugegriffen
   5. Es gibt keine anderen Indikatoren, dass MM nicht MM sein könnte

Damit kann der Zugriff auf diese Resource ohne weitere Hürde erlaubt werden.

Beispiel 2:

Wir nehmen die gleichen Conditions wie oben an, diesmal allerdings meldet sich MM vom Flughafen aus an:

Damit ändert sich insb. die Eigenschaft des „Woher“.
In diesem Fall könnte es sinnvoll sein eine zusätzliche Überprüfung einzubauen, ob MM auch MM ist und alles mit rechten Dingen zu geht.
Also könnte in diesem Fall eine zusätzliche Multi Factor Authentication mittels seines Firmenhandies stattfinden.

Beispiel 3:

Wir gehen wieder von den gleichen Conditions wie in Beispiel 1 aus – diesmal greift MM aber nicht auf das Unternehmensportal sondern auf den Draft des Geschäftsberichts zu, der nächste Woche in der Hauptversammlung präsentiert werden soll.

In diesem Fall würde es – da streng vertrauliche Informationen betroffen sind – zum einen Sinn ergeben ebenfalls den Zugriff über MFA zu verifizieren und zum anderen könnte es sinnhaft sein die Tätigkeiten von MM innerhalb dieser Informationen gesondert aufzuzeichnen um also ggf. Missbrauch und Manipulation vorzubeugen.
Hierzu kann die erweiterte Möglichkeit von einer sog. „Session Control“ genutzt werden, um u.a. auch z.B. den Download auch dann zu verhindern, wenn die Information in einem System enthalten ist, wo dies nicht mittels Boardmitteln möglich ist.

Beispiel 4 (optional):

Anstelle von Montagmorgen wird Samstagnacht um 22:46h auf den Domain Controler im Keller des HQ von MM zugegriffen. Und das ganze passiert über eine interne VPN IP, welche von einem IP Bereich der China zugeordnet ist, benutzt wird .

Hier ergeben sich gleich mehrere (für uns Menschen) offensichtliche Dinge:

1. MM hat noch nie auf den DC zugegriffen (warum auch? 😉 )
2. MM arbeitet in der Regel nicht Samstagsnachts.
3. MM hat sich seit Monaten nicht mehr aus China an VPN eingeloggt
4. Ggf. weil MM das Firmenhandy auch privat nutzen darf und Push Mails aktiviert sind ist der letzte „normale“ und erfolgreiche Login auf Unternehmensdaten 5min früher gewesen, bei dem Outlook Mobile eine automatisierte Mail erhalten hat. Dieser Zugriff erfolgte aus Frankfurt, wo MM wohnt.

Wenn ein Mensch diese Conditions sieht, dann ist es ziemlich offensichtlich, dass wir, bzw. das Unternehmen eine geleakte Identität hat und hier schnellstens eingegriffen werden muss.

Die Tools, die hier greifen würden, sind Microsoft Defender for Identity (MDI)in Verbindung mit Microsoft Defender for Office 365 (MDO). Der oben beschriebene Vorgang würde einen Alert in MDI auslösen, der idealerweise automatisiert dadurch behandelt würde, dass die Identität von MM eingeschränkt oder sogar komplett gesperrt würde und bei einem Menschen ein Alarm aufschlagen würde.

Fazit und next steps

In der heutigen, cloudifizierten Zeit muss Security anders gemacht werden als noch grade eben!
Die Tools dafür existieren und sollten besser jetzt als morgen (denn dann könnte es zu spät sein) in die Nutzung gebracht werden!
Und vor allem muss ein Umdenken stattfinden, denn Firewall und AV sind schon lange nicht mehr ausreichend, um ein Unternehmen effektiv vor gezielten (und das sind die gefährlichen) Angriffen zu schützen!
Hinzu kommt, dass durch neue Herangehensweisen auch Daten besser geschützt werden können und sollen.

Wie sehen also die Next Steps auf der Journey zu Zero Trust aus?

1. MFA & Conditional Access
2. Add all 3rd party apps to Azure AD
3. Priviledged Access Mgmt/ JEA+JRA
4. #gopasswordless, incl. WHFB, User/Session Risk, SSSO AAD
5. Device Baselines, Device Health, Device Risk using MDATP
6. Remove client side stored data (ODFB, SFB, EXO, CRM,…)
   Bzw.: Was hat das Aktenarchiv im Keller, was mein Fileshare nicht hat?
7. Shadow IT and App Managment using MCAS&MDATP

Und ja, natürlich ist das eine enorme Aufgabe – aber wie heißt es so schön: „Dies ist alternativlos!“

Sie benötigen Hilfe bei der Umsetzung?
Kein Problem, kommen sie auf ihren Microsoft Ansprechpartner zu und wir bringen sie mit dem besten für sie geeigneten Microsoft Partner zusammen, um dieses Thema ganzheitlich anzugehen!

Weiterführende Links:

• Zero-Trust Landing:
  https://aka.ms/zero-trust
• Zero-Trust Assessment:
  https://info.microsoft.com/ww-landing-Zero-Trust-Assessment.html
• Zero-Trust Blog:
  https://www.microsoft.com/security/blog/zero-trust/
• Zero-Trust @Microsoft: https://myignite.techcommunity.microsoft.com/sessions/83749

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