Strong Authentication Methods

1.1 Einleitung

In unserem letzten Blog-Beitrag haben wir über das Thema „Adversary-in-the-Middle phishing attack“ gesprochen. In diesem Blog-Artikel erklären wir, welche ersten Schritte Sie vornehmen können, um den Zero-Trust-Ansatz für den Schutz der Identitäten in Microsoft 365 umzusetzen.

Der Zero-Trust-Ansatz ist dabei ein Sicherheitskonzept, das auf dem Prinzip „niemals vertrauen, immer überprüfen“ basiert. Dies bedeutet, dass jede Anfrage potenziell gefährlich ist und daher überprüft werden muss. Es wird somit keinem Netzwerk, Gerät oder Identität vertraut, nur weil dieses sich innerhalb oder außerhalb einer bestimmten Grenze befindet – wie zum Beispiel innerhalb eines Firmennetzwerks, hinter einer Firewall. Stattdessen muss jede Anfrage auf Basis von Faktoren wie Identität, Gerät, Standort, Anwendung und Daten validiert werden. Dies sind wichtige Schritte, um Ihre Identitäten vor Angriffen wie dem “Adversary-in-the-Middle phishing attack” zu schützen.

1.2 Was bedeutet “Zero Trust” im Kontext Identitäten?

Um die Sicherheit im Unternehmen zu steigern ist es wichtig alle Bestandteile mit dem Zero-Trust-Ansatz sauber zu betrachten. Angefangen mit den Identitäten, über die eingesetzten Endpunkte bis hin zur eigentlichen Infrastruktur. Die unten abgebildete Grafik verdeutlicht dabei, welche Bestandteile genau hinter dem Zero-Trust-Sicherheitsmodell stecken.

Abbildung 1: Zero-Trust-Overview [Quelle: https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview]

Im Kontext von Identitäten im Azure Active Directory (Azure AD) bedeutet Zero-Trust, dass man die Identität aller Benutzer*Innen verifizieren muss, bevor diese Identitäten Zugriff auf Ressourcen erhalten. Dabei kommen unter anderem verschiedene Mechanismen von Conditional Access zum Einsatz, wie zum Beispiel den „Strong Authentication Methods” und der „Identity Protection (Risk Based Conditional Access)”.

1.3 Was ist Conditional Access?

Es dürfte bekannt sein, dass die Identität im Azure AD eines der wichtigsten Glieder für die Arbeit mit Office 365 bildet, denn jeglicher Zugriff in die Umgebung erfolgt über eine Identität. Sollte diese Identität kompromittiert werden, kann dies schwerwiegende Folgen für die Organisation haben und zu erheblichen Schäden führen. Conditional Access ermöglicht es Ihnen, den Zugriff auf bestimmte Ressourcen oder Anwendungen von verschiedenen Faktoren abhängig zu machen. Zum Beispiel können Sie bei der Anmeldung voraussetzen, dass sich die Benutzer*Innen mit einem zweiten Faktor authentifizieren müssen (MFA), wenn sie von einem unbekannten Gerät aus, auf eine Ressource zuzugreifen versuchen. Des Weiteren können Sie den Zugriff auf bestimmte Anwendungen nur für definierte Gruppen oder Rollen genehmigen.

Abbildung 2: Conditional Access Overview

Die Funktion von Conditional Access und ihre Hauptbausteine lassen sich sehr gut an seinem Namen (auf Deutsch „Bedingter Zugriff“) ableiten. Die Funktion bildet sich aus drei Hauptkomponenten: Signal (Zugriff), Bedingung und Aktion.

• Das Signal beschreibt den Kontext der Anmeldung, wie beispielsweise die Identität der Benutzer*In, das Gerät, die Anwendung oder die IP-Adresse.
• Die Bedingung definiert die Regeln, die auf das Signal angewendet werden, um zu entscheiden, ob der Zugriff erlaubt, beziehungsweise verweigert wird. Diese kann beispielsweise definieren, dass alle Anmeldungen mit einem Windows Gerät, welche außerhalb des Firmennetzwerkes getätigt werden, von dieser Regel betroffen sind.
• Die Aktion wiederrum bestimmt das Ergebnis der Anmeldung, wie zum Beispiel einen zweiten Faktor bei der Anmeldung, Prüfung des Compliance Status bei der Anmeldung, Aufforderung auf ein Password Reset oder die Blockierung der Anmeldung.

Die Conditional Access Funktionsweise lässt sich noch besser veranschaulichen, indem wir eine Conditional Access Richtlinien, entsprechend einem gewünschten Use-Case, betrachten. In diesem Beispiel sieht das Szenario wie folgt aus:

• Use Case – Nur Personen mit einem von unserem Unternehmen verwalteten Gerät, welches unseren aktuellen Sicherheitsstandards entspricht, dürfen auf SharePoint Online Zugreifen.
• Signal – Jegliche Anmeldung an der Applikation „SharePoint Online“
• Bedingung – Keine weitere Spezifizierung. Gilt in diesem Beispiel für alle Anmeldungen an der Applikation, unabhängig davon, ob diese Anmeldung via Browser, Client App, Windows oder Mac, Firmennetzwerk oder aus dem Homeoffice o.ä. erfolgt.
• Aktion – Bei der Anmeldung auf den Compliance Status des Geräts überprüfen. Die Prüfung auf den Compliance

Anmerkung zum obigen Use-Case: Es gibt weitere Einstellungen, die mit in die Erstellung eines Regelsatzes für Condtional Access mit einfließen können, die im obigen Beispiel nicht unbedingt mit einbezogen sind. Bei den Azure Trust Einstellungen beispielsweise, hin zu einem anderen Tenant, ist es möglich dem Compliance Status einer Partner Organisation zu vertrauen. Dies würde den zweiten Teil der Aussage in „Aktion“ widersprechen. In einem solchen Fall kann dies Anhand der Bedingung korrigiert werden.

1.4 MFA (Multi-Faktor Authentifizierung) ist nicht gleich MFA

Mit dem Wissen wie Conditional Access funktioniert, lässt sich somit nun der Zero Trust Ansatz „niemals vertrauen, immer überprüfen“ umsetzen. Der erste Schritt ist dabei für jegliche Anmeldung, immer einen zweiten Faktor zu verlangen. Wie im letzten Blog Artikel „Adversary-in-the-Middle phishing attack“ gibt es aber auch hier Unterschiede in der Sicherheitsstufe: Methoden die von Angreifern abgefangen und missbraucht werden können (phishable) und dagegen resistente Methoden (non-phishable).

Microsoft 365 bietet zum aktuellen Stand die folgenden Methoden für die Authentifizierung:

• FIDO2-Sicherheitsschlüssel
• Microsoft Authenticator
• SMS
• Drittanbietersoftware-OATH-Token (z.B. den Google Authenticator)
• Sprachanruf
• E-Mail-OTP (Nur für Gäste)
• Zertifikatbasierte Anmeldung
• Windows Hello
• Compliance Status

Non-Phishable Authentication Methods (oder auch Strong Authentication Method) sind solche, die nicht von Angreifer kopiert oder gestohlen werden können. Diese Methoden basieren auf kryptographischen Verfahren, die eine starke Bindung zwischen dem Nutzer, dem Gerät und dem Dienst herstellen. Sie erfordern außerdem eine Nutzerinteraktion, die nicht automatisiert werden kann. Als Non-Phishable zählen dabei der FIDO2-Sicherheitsschlüssel, die Zertifikatbasierte Anmeldung, Windows Hello und der Compliance Status bei der Anmeldung.

Wir empfehlen als eines der einfachsten und zugleich sichersten Schritte die Kombination aus „Compliant Device“ Status sowie dem Microsoft Authenticator für alle Benutzer*Innen des Unternehmens einzuführen. Diese Kombination garantiert die Sicherheit der Identität, ohne zusätzliche Kosten für die Anschaffung von neuer Hardware o.ä. zu generieren, vorausgesetzt das alle Mitarbeiter*innen ein Handy besitzen.

1.5 MFA – Nur der Anfang 

Mit der Einführung von MFA für alle Benutzer*Innen, gehärtet durch die Ergänzung um den Compliance Status der Geräte, wäre somit der erste Schritt zum vollumfänglichen Zero Trust Ansatz genommen. Jedoch stehen noch die Endpunkte, die Daten und die Infrastruktur aus. Abbildung 3 verdeutlich nochmal, wie ein vollumfänglicher Zero Trust Ansatz aussehen könnte, wobei wir in diesem Blog-Beitrag nur Teile von den Identity Punkten betrachtet haben.

Auch ist es möglich die Conditional Access Richtlinien, um die Identity Protection Funktion zu erweitern und somit den Schutz der Identitäten in der Organisation, um eine weitere Stufe zu steigern. Mit Risk Based Conditional Acces ermöglichen wir, den Zugriff auf Ressourcen basierend auf dem Risiko der Zugriffsanfrage zu steuern. In diesem Fall kommen weiter Signale bei der Anmeldung hinzu, wie z.B. ein erhöhtes Anmelde-Risiko aufgrund Impossible Travel, die wir bei unseren Bedingungen in Conditional Access berücksichtigen können.

Abbildung 3: Zero-Trust-Ansatz [Quelle: https://learn.microsoft.com/en-us/microsoft-365/security/microsoft-365-zero-trust?view=o365-worldwide]

Tufan Avcu
Office 365 IT-Consultant

Wenn Sie Hilfe bei der Implementierung der oben vorgestellten Lösungen benötigen oder gerne ein Review der existierenden Umgebung hinsichtlich der Sicherheit und Identitätsschutz wünschen, dann zögern Sie nicht uns direkt und unverbindlich zu kontaktieren.

Hier geht es zu dem Beitrag “Adversary-in-the-Middle phishing attack”: https://www.sepago.de/blog/adversary-in-the-middle-aitm-attack/