Das ESAE-Modell im Einsatz – Teil 5: Die ESAE-Architektur von Microsoft

Welche Änderungen gibt es bei den Empfehlungen für das Enhanced Secure Administration Environment (ESAE)? Und welche Herausforderungen ergeben sich hierbei? Das wird in diesem Teil der ESAE-Blogserie beleuchtet.

Ein Gastbeitrag der TEAL Technology Consulting

Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie alle Teile nacheinander lesen.

Das bietet dieser Teil der ESAE-Serie:

Die ESAE-Maßnahmen beleuchtet

Wir beschäftigen uns seit unserer Firmen-Gründung intensiv mit Microsoft Active Directory Security Projekten. Wir konnten bei mehreren Kunden und Vorträgen aufzeigen, wie Betriebsprozesse und die Architektur einer Microsoft-Infrastruktur angepasst werden können, um beispielsweise Pass the Ticket / Pass the Hash Attacken zu mitigieren.

Unsere Empfehlungen basieren auf den öffentlich verfügbaren Informationen zum Microsoft-eigenen Offering ESAE – Enhanced Secure Administration Environment, über das wir unter anderem in dieser ESAE-Blogserie schreiben.

Die öffentlich verfügbaren Informationen sind unter dem Stichwort „Securing Privileged Access” zu finden. Das denken wir darüber:

Was veränderte sich?

Auf den ersten Blick fällt auf, dass Microsoft beim Umsetzungsweg stärker als früher die Beschreibung des Zielzustands in den Vordergrund rückt. Es wird deutlich, dass Quick-Wins schnell umgesetzt werden sollen, was sich in den folgenden drei Phasen wiederspiegelt:

    • Phase 1: First 30 days – Quick Wins with meaningful positive Impact
    • Phase 2: 90 days – Significant incremental Improvements
    • Phase 3: Ongoing security improvement and sustainment

Phase 1

In der ersten Phase werden vor allem Quick-Wins wie LAPS zum lokalen Passwort-Management, dedizierte Admin-Devices (PAWs) zur Administration und eine Kontenttrennung eingeführt.

Was allerdings auffällt: Es soll bereits in den ersten 30 Tagen ein Cloud-Service (Azure ATP – Advanced Thread Protection) eingeführt werden.

ESAE Modell Microsoft (Bild: Microsoft)

Mit Azure ATP werden Informationen aus der lokalen Infrastruktur an den Service gesendet und dort nach Auffälligkeiten analysiert. Es werden zum Beispiel Benutzer-, Geräte- und Ressourcen-Verhalten überwacht und Auffälligkeiten sofort über einen Feed reported bzw. selbständig gelöst (sofern das gewünscht ist). Der große Vorteil ist hierbei, dass man somit von Beginn an ein starkes Werkzeug hat, um überhaupt zu erkennen, ob man gerade angegriffen wird oder nicht.

ATP ist einzeln oder als Teil der Enterprise Mobility + Security E5 Suite lizenzierbar.

Hindernisse beim Einsatz von Azure ATP

Um Azure ATP verwenden zu können, benötigt ein Unternehmen einen funktionierenden Azure Tenant und muss konstant Daten in die Cloud senden. Das kann aus unserer Sicht problematisch für Unternehmen sein, die entweder noch gar keine Cloud-Dienste nutzen oder ggf. zunächst mit Datenschutz-Verantwortlichen und Betriebsräten abstimmen müssen, was synchronisiert werden darf.

Gerade in großen Unternehmen ist es in den seltensten Fällen möglich, neue Services innerhalb von 30 Tagen einzuführen. Des Weiteren muss ein solcher Cloud-Dienst auch in die Budget-Planung passen. Zumeist finden Budget-Planungen gegen Ende eines Jahres statt, und der Einsatz der Enterprise Mobility und Security E5 Suite ist zu diesem Zeitpunkt eventuell noch gar nicht geplant. Diese Mehrkosten müssen ebenfalls zunächst genehmigt werden, bevor man in die Umsetzung gehen kann.

Dienste wie Azure ATP bieten jedoch einen großen Mehrwert. Sie sollten definitiv in die langfristige Planung mit aufgenommen werden!

Phase 2

In den nächsten 90 Tagen sollen weitere Maßnahmen zur Absicherung eingeführt werden. Auch hier sind weitere Cloud-Dienste mit im Scope.

ESAE Modell Microsoft (Bild: Microsoft)

Mit Azure AD Identity Protection und Azure ATP Lateral Movement Vulnerability Detection werden zwei Dienste eingeführt, die ebenfalls den Schwerpunkt auf die Erkennung von Anomalien legen. Das macht durchaus Sinn.

Wir haben mal einen Microsoft Security PFE gefragt, was aus seiner Sicht die wichtigsten drei Maßnahmen bei einem ESAE-Projekt sind. Seine Antwort: Detection, Detection und Detection. Nur wenn man überhaupt erkennen kann, dass man angegriffen wird, kann man auch darauf reagieren.

Die Aussage stimmt ohne Weiteres. Wir haben bei unseren Kunden-Assessments allerdings immer wieder festgestellt, dass in den meisten Umgebungen keine oder eine veraltete Security Baseline umgesetzt ist. Das fängt bei ungepatchten und teils in die Jahre gekommenen Systemen an, geht weiter über nicht umgesetzte Systemhärtungen, und endet bei einer fehlenden Kontentrennung.

Für solche Umgebungen halten wir es für zielführender, diese rudimentären Missstände zuerst zu beseitigen, bevor man sich mit der Einführung neuer Services beschäftigt.

Die Just in Time Privileges und das Admin Forest Modell

Des Weiteren sollte in solchen Situationen die Just in Time Privileges eingeführt werden. Hier verweist Microsoft auf den MIM/PAM for ADDS und Azure PIM für Azure AD. Auch hier steht klar die Nutzung von Azure-Services im Fokus.

Vor dem Update wird an dieser Stelle ein dedizierter Admin Forest und die Nutzung von Shadow Principal Objects empfohlen (was wir im dritten Teil unserer Blogserie beschrieben haben).

Es stellt sich erneut die Frage: Was macht ein Kunde, der kein Azure im Einsatz hat und ggf. auch nicht einsetzen will? Wenn man tiefer in die neue Microsoft-Dokumentation schaut, findet sich das Admin Forest Modell.

ESAE Modell Microsoft Architektur (Bild: Microsoft)

Aus unserer Sicht macht es in gewissen Szenarien nach wie vor Sinn, einen dedizierten Admin Forest aufzubauen und eben nicht ausschließlich Cloud-Dienste zu benutzen.

Phase 3

In der letzten Phase soll ein kontinuierlicher Security-Prozess, welcher die eingeführten Controls bewertet und ggf. anpasst, eingeführt werden.

ESAE Modell Microsoft Architektur (Bild: Microsoft)

Gerade Themen wie SIEM-Usecases sind enorm wichtig und können ebenfalls helfen, Angriffe zu erkennen. Daneben steht ab hier dann auch die Absicherung der eingesetzten Services durch GPOs und andere Konfigurationen im Vordergrund.

Wie oben bereits erwähnt, ist es aus unserer Sicht notwendig, so früh wie möglich eine gute Security Baseline umzusetzen und gerade vernünftig geplante GPOs gehören hier mit dazu. Grundlage dafür können die Security Baseline Vorlagen von Microsoft , oder diverse Best-Practice-Empfehlungen von Sicherheitsbehörden und Experten sein.

Fazit

In der Dokumentation wird der Eindruck erweckt, dass nach den ersten 120 Tagen bereits signifikante Ergebnisse erzielt werden können. Das stimmt! Doch das erfordert – besonders in Enterprise-Umgebungen – den Einsatz von nicht unerheblichen, finanziellen und personellen Ressourcen. Des Weiteren werden verstärkt Cloud-Dienste zur Erkennung von Angriffen genutzt, was nicht in allen Organisationen gewünscht ist.

Bei den meisten Kunden, die wir bisher gesehen haben, ist keine flächendeckende Security Baseline ausgerollt. Das Patch Management ist zum Teil etwas löchrig. Und Dinge wie regelmäßige Passwort-Wechsel, Kontentrennung etc. sind meist nicht in Gänze vorhanden. Außerdem muss meistens noch das Bewusstsein geweckt werden, warum die ganzen Maßnahmen eingeführt werden sollten. Ein AD-Security-Projekt steht und fällt unserer Meinung nach damit, ob man das Betriebsteam und das Management überzeugen kann, neue Arbeitsweisen einzuführen und zu verwenden.


Hinweis: Lesen Sie auch den derzeit letzten Teil der ESAE-Serie!


Über den Autor

Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.

Schreibe einen Kommentar