In der aktuellen, globalen Situation kommt oft die Frage danach „wie kann ich meine spezifische Situation gegen globale Bedrohungen reduzieren?“.

Neben den Dingen, die ich zum Beispiel schon in meinem Beitrag „kein Mitleid mit Ransomware“ beschrieben habe, gibt es noch einen weiteren sehr einfachen Weg die generelle Bedrohung „meiner“ Services zu reduzieren und diesen möchte ich hier aufzeigen.

Damit das bestmöglich funktioniert muss ich auch kurz auf die Voraussetzungen eingehen – auch im Wissen, dass das bei den wenigsten Leser*innen heute schon so vorhanden ist. Das heißt meine Hoffnung ist auch, dass dies in Zukunft besser wird.

Voraussetzungen

Die Basis meiner Idee ist, dass Zugriffe von außerhalb der erwarteten Länder/Regionen entweder erschwert (Stichwort Multifaktor Authentifizierung [MFA]) oder komplett unterbunden werden.

Damit das funktionieren kann müssen alle (relevanten) Dienste über einen zentralen „single Point of Authentication“ erreichbar gemacht werden und alle weiteren Möglichkeiten entsprechend eingedämmt sein.

Der „single Point of Authentication“ muss in meinen Augen Microsoft Azure AD sein. An diesen zentralen Anlaufpunkt können die meisten Anwendungen und (SaaS) Apps – auch on-premises, zum Beispiel unter zur Hilfenahme von Azure AD App Proxy – angebunden werden.

Neben der nachfolgenden Idee für diesen Blogpost kommen damit automatisch noch weitere Benefits zum Tragen, auf die ich außer dieser Liste nicht näher eingehen möchte:

1. Pre-Authentication bevor ein User überhaupt ein Netzwerkpaket an einen Dienst schicken kann -> wäre für Log4J ganz hilfreich gewesen! ? [und ja, ist für Webseiten natürlich nicht hilfreich, aber für Line of Business Apps (LOBs) schon!]
2. MFA auch für Apps, die sonst kein MFA bieten
3. Single Sign On (SSO)
4. Self Service Password Reset (ohne Passwort wäre natürlich noch schöner)
5. User Readiness für alle Authentications
6. …ich habe bestimmt noch welche vergessen

Einfache Verringerung durch Einschränkung der Erreichbarkeit auf Basis des Landes/Region einer Authentifizierungsanfrage

Innerhalb von Azure AD gibt es das Prinzip des „Conditional Access“ / „Bedingter Zugriff“. Dort können Bedingungen konfiguriert werden, welche für eine erfolgreiche Authentication notwendig sind, zum Beispiel „hat die* User*in sich per MFA überprüfen lassen“.

Eine weitere Bedingung kann die Lokalität sein und genau darauf möchte ich hier setzen.

*WICHTIG*: Lokalität sollte nur als „soft“ angesehen werden, da es genügend Möglichkeiten gibt dies zu „spoofen“, also vorzutäuschen. Damit kann also nur die Angriffsfläche verkleinert werden und muss durch weitere Maßnahmen flankiert werden!

Idee

Die Idee ist also wie folgt:

Es werden vier (eventuell sogar fünf) Listen mit Ländern/IPs erstellt:

1. Die festen IPs aller Internet Breakouts aller eigener Standorte
2. Alle Länder, aus denen eine hohe Wahrscheinlichkeit einer gerechtfertigten Anfrage existieren, also insbesondere alle Länder, in denen sich Branches/Offices befinden. Das mag im Einzelfall vielleicht sogar nur „Deutschland“ sein.
3. Alle Länder, aus denen eine niedrige Wahrscheinlichkeit einer gerechtfertigten Anfrage existieren. Wenn zum Beispiel in 2. nur Deutschland steht, dann wären die Anrainer von Deutschland ein guter Start, gegebenen Falls noch angereichert mit typischen Urlaubsländern oder Ländern von Zulieferern, zum Beispiel Österreich, Schweiz, BeNeLux, Frankreich, Italien, Spanien, USA
4. Alle Länder, von denen man sicher ausgeht, dass aller Wahrscheinlichkeit nach keine gerechtfertigten Anfragen kommen, zum Beispiel: Nord Korea, Belarus, Iran, etc.
5. Optional: eine Liste mit „sonstigen“ Ländern, hängt von der individuellen Architektur ab

Die geneigte Leser*in wird sich bei dieser Liste vielleicht an das Zonenmodell des Internet Explorers (ganz korrekt: von Windows) erinnern – und das ist beabsichtigt, da es letztlich den gleichen Zweck verfolgt.
Zur Erinnerung es gab „local Intranet“ (oben 1.), „Trusted Sites“ (2.), „restricted Sites“ (4.; ich nenne sie der Einheitlichkeit halber „untrusted“) und „Internet“ (3. und 5.).

In Azure AD könnte es dann so aussehen:

Und nun kommt der Clou an der ganzen Sache: die Conditional Access (CA) Regeln.

Regeln für den bedingten Zugriff

Wir fangen mit der einfachsten und zugleich wichtigsten Regel an:

“Block Access from untrusted Sites“ (4.):

Ziel der Regel ist alle Zugriffe von unseren als „untrusted“ definierten Ländern zu unterbinden.

Hierfür muss in Conditional Access folgende Policy eingestellt werden – wobei ich davon ausgehe, dass CA Regeln grundsätzlich bekannt sind:

1. Alle Nutzer – exklusive Break Glass, etc.
2. Alle Anwendungen
3. Conditions->Locations->Include->Untrusted Sites
4. Grant: Block access

Restricted Access from “Internet”/”all other countries” (3./5.)

Da wir davon ausgehen müssen, dass User*innen gelegentlich von ungewöhnliche(re)n Ländern aus zugreifen wollen, sollten wir uns um diesen seltenen Fall kümmern, diesen aber entsprechend zusätzlich absichern:

1. Alle Nutzer – exklusive Break Glass, etc.
2. Alle Anwendungen
3. Conditions->Locations->Include->Internet
4. Grant:
   1. Require MFA
   2. Require Compliant Device (=> aka “managed device”)

Zugriff vom lokalen Intranet und von vertrauenswürdigen Ländern zulassen (1./2.)

Das Schöne ist, dass wir hierfür nichts weiter tun müssen, denn durch die Behandlung der Ausnahmen müssen wir die „normalen“ Zugriffe nicht weiter einschränken.

Dies kann man natürlich gerne machen, je nach Geschmack könnte dies bedeuten, dass ich z.B. auf MFA oder auf compliant Device prüfe, aber nicht beides erzwinge.

Überprüfen der Zugriffe

Wer sich vorher oder natürlich noch besser kontinuierlich damit beschäftigen möchte, woher die Zugriffe auf die eigenen Systeme kommen, der kann hier an unterschiedlichen Stellen aktiv werden und sich dies anzeigen lassen:

Im Azure AD

In den „Sign-in“ Logs erhält man in der Spalte „Location“ den geschätzten Ort. Geschätzt deswegen, weil diese Information auf der verwendeten IP Adresse und der Zuordnung der IP Adressen auf Provider und deren Access-Points beruhen. Dies muss nicht in jedem Fall genau sein!

Microsoft Graph

Der Microsoft Graph als API für den Zugriff auf Daten kann natürlich auch genutzt werden und hier ein gewisser Automatismus und Export für die Daten etabliert werden.

Die Beschreibung der Schnittstelle findet ihr unter: List signIns – Microsoft Graph v1.0 | Microsoft Docs

Microsoft Defender for Cloud Apps

In Microsoft Defender for Cloud Apps lassen sich Zugriffe über Investigate->Activity Log analysieren. Das Schöne ist, dass es hierfür schon vorbereitete Queries gibt:

1. Failed log in
2. Successful log in

Natürlich kann man sich auch eine eigene Query für beides zusammen erstellen.

Hier die Ansicht aus meinem Testtenant und wie man unschwer erkennen kann gab es Zugriffe aus den USA, der Ukraine, Hong Kong und den Niederlanden.
Anhand dieser Infos kann ich dann basierend auf meiner Architektur sehr schnell entscheiden, ob ich z.B. Hong Kong in meinen Listen von z.B. „Internet“ zu „Trusted“ bewegen möchte, oder doch lieber ab sofort als „Untrusted“ zählen möchte.

Und der Vollständigkeit halber natürlich noch der Blick auf die Successful Log ins:

Fazit

Diese Herangehensweise ermöglicht es auf einfachstem Weg die Sicherheit der gesamten Infrastruktur und Apps sofort und ohne zusätzliche Kosten zu erhöhen.

Die Listen der entsprechenden Länder lässt sich bei Bedarf (z.B. aktuelle globale Bedrohungslage) sehr schnell anpassen.

Herausfordernd ist es natürlich für multi-nationale Konzerne, die über den gesamten Globus verteilt sind und wo eine derartige Klassifizierung der Zugriffe nicht möglich ist.