[SD] #gopasswordless

In der Security Demopalooza adressiere ich #Security Themen, die in meiner täglichen Arbeit oft/öfter gefragt werden. Für eine Liste der bisher behandelten Themen besuche einfach die Übersichtsseite der Security Demopalooza.

Die größte Security-Bedrohung geht aktuell von gestohlenen bzw. übernommenen Identitäten aus. Es ist schlicht viel einfacher und damit billiger als „regulärer User“ zu kommen, als sich umständlich mit deutlich größerem Aufwand „irgendwie“ Zugriff auf die gewünschten Systeme zu verschaffen.

Diese Erkenntnis zeigt auch, dass insb. z.B. VPN/Firewall keine Sicherheitshürde (mehr) darstellt – zumindest nicht für zielgerichtete Angriffe.

Und dabei geht die größte Gefahr von geleakten oder erratenen Passwörtern aus – grade Anfang März 2019 hat Citrix hier leider für Aufsehen erregen und zugeben müssen, dass sie durch eine sog. Password Spray Attack kompromitiert worden sind.

Und das führt mich zu meiner These: „Wer seine Identitäten nicht (ausreichend) schützt, der darf gerne seine sonstigen Investitionen in Security an gemeinnützige Organisationen spenden, denn dort haben sie einen größeren Impact„.

Aber zurück zur Security Demopalooza: Um also das Thema #gopasswordless anzugehen sind drei wesentliche Schritte zu gehen:

1. Clientnutzung ohne Passwörter ermöglichen
2. Anmeldung an Diensten ohne Passwörtern ermöglichen
3. Identity Protection auf Basis der Detektion von Verhaltensanomalien

Starten wir mit 1.: Clientnutzung ohne Passwörter ermöglichen

Grade mit Windows 10 wird es sowohl dem Anwender, als auch dem IT Admin leicht gemacht auf klassische Passwörter zu verzichten.

Das Stichwort hier heißt „Windows Hello for Business“ und bedeutet, dass die (User) Authentifizierung sich einzig und allein gegen den TPM der verwendeten Maschine richtet mit dem Auftrag den TPM frei zu geben, so dass das dort gespeicherte Zertifikat mittels asynchroner Verschlüsselung an die Authenitifizierungsstelle (also idealer Weise Azure AD) geschickt werden kann. D.h., dass wir hier von einer starken – weil einerseits zertifikatsbasierten und andererseits über MFA („what you have“ [Maschine] und „what you are“ [Gesicht, Finger] bzw. „what you know“ [PIN]) geschützt ist.

Für besondere Nutzerkreise kann dies durch weitere Faktoren verstärkt werden, also in meinem Falle nutze ich Gesicht+verbundenes Telefon, mit der Fallbackmöglichkeit zu PIN. Da dies allerdings auch etwas Nutzerwissen/schulung voraussetzt ist es keine Empfehlung dies auf alle User anzuwenden. (=> GPO)

Weiter mit 2.: Anmeldung an Diensten ohne Passwörtern ermöglichen

Von der Consumer Variante der Microsoft Dienste, also den „Microsoft Accounts“ (fka „LiveID“, etc.), kennt ihr das bestimmt schon, dass man sich über die Authenticator App ohne Passwort an z.B. outlook.com anmelden kann:

Nach dem Auswählen der richtigen Vergleichszahl und dem Bestätigen durch Push auf „Genehmigen“ kann noch konfiguriert werden, dass z.B. mittels der im Mobilgerät verbauten biometrischen Sensoren (z.B. Finger) noch ein weiterer Faktor hinzukommt.

Auf genau die gleiche Art und Weise kann man sich auch bei AzureAD anmelden – heute schon! (leider noch public preview…)

Der Mechanismus ist sehr einfach, es wird dafür benötigt:

1. Azure AD
2. In Intune registrierte Geräte
3. Auf den Geräten die aktuelle Authenticator App (Android, iOS)

Um das Feature zu enablen muss nun nur noch ein simpler PowerShell Befehl gegen die AzureAD ausgeführt werden (AzureADPreview Modul notwendig!):

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‚{„AuthenticatorAppSignInPolicy“:{„Enabled“:true}}‘ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

…und schon geht’s los!

Schritt 3.: Identity Protection auf Basis der Detektion von Verhaltensanomalien

Neben dem Überflüssigmachen von Passworten (btw. grade frisch aus der Presse: die neue Baseline Security verzichtet nun auf Ablaufzeiten für Passworten, ganz nach der Microsoft/NIST Empfehlung aus dem Jahr 2016) ist es zwingend der nächste Schritt sich nicht auf vermeintlich sichere Dinge, insb. den Identitäten der User zu verlassen.

Die Empfehlung ohne zyklischen PW Reset auszukommen bedingt nämlich, dass man sehr genau im Blick behält, was die User tun und anhand von Verhaltensanomalien erkennt, dass ein Nutzer nicht der ist, der er (oder sie oder d) vorgibt zu sein.

Beispiel: Ein Mitarbeiter (und seine Kollegen) loggt sich immer Montags gegen 8:00h das erste Mal ein und typischer Weise Freitags um 13:00h ("Freitags um eins macht jeder seins...") das letzte Mal. Wenn dieser Account nun Samstags um 21:00h sich einloggt, dann ist das ein typischer "Indicator of Compromise" und sollte automatisch dazu führen, dass zusätzliche Sicherungsprozesse starten. 

D.h., dass auf Beobachtungen aus der Vergangenheit, Kenntnisse über aktuelle Angriffe, etc. eine Risikobewertung stattfinden muss auf die dann entweder automatisiert oder durch ein entsprechendes SOC reagiert werden kann.

Hierzu bietet sich an eine Kombination aus „Conditional Access“ und „Identity Protection->Sign-in Risk und User Risk“ zu verwenden.

Wer sich das mal näher anschauen möchte kann sich dies in dem sehr guten Ignite Video anschauen:

Du bist ein managed Microsoft Partner und hast Lust genau das bei deinen Kunden einzuführen und ggf. Richtung Managed Services auszubauen? Sprich uns an und lass es uns gemeinsam machen!