ESAE is dead – Long live SAE, oder Totgesagte leben länger? - TEAL Technology Consulting GmbH
2941
post-template-default,single,single-post,postid-2941,single-format-standard,bridge-core-2.7.6,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-26.1,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.6.0,vc_responsive

ESAE is dead – Long live SAE, oder Totgesagte leben länger?

Einige von euch haben sicher gesehen, dass Microsoft die Securing privileged access Dokumentation kurz vor Weihnachten aktualisiert hat. Einer der Artikel beginnt mit folgendem Bild:

Quelle: https://docs.microsoft.com/en-us/security/compass/esae-retirement

Auf den ersten Blick ist das verwirrend. Sind jetzt alle ESAE Bemühungen umsonst gewesen? Auch wir von TEAL basieren mit unseren Angeboten auf dem ESAE Modell, müssen wir nun alles neu machen? So viel vorweg, auch wenn Microsoft viele wichtige Punkte anders darstellt und ergänzt, die Grundprinzipien bleiben dieselben und wer eine sichere Infrastrukturumgebung betreiben möchte, kommt auch in Zukunft nicht an den klassischen ESAE Maßnahmen vorbei.

Kurz nach Veröffentlichung der neuen Dokumentation kam ein technischer Leiter von einem unserer Kunden auf uns zu und sagte:

„Nach dem Lesen der Artikel habe ich das Gefühl, dass ich etwas tun muss, allerdings stelle ich mir folgende Fragen:

    1. Laufen wir Gefahr, dass unsere jetzige [ESAE] Architektur durch Microsoft nicht mehr supportet wird?
    2. Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen [ESAE] Setup?
    3. Wie hoch ist der Aufwand, die neue Architektur umzusetzen”

Wir nehmen das zum Anlass, mit dem ersten Artikel im Jahr 2021 die (E) SAE Deep Dive Blogserie zu unterbrechen und werden auf die Fragen im Allgemeinen eingehen. Die letzten zwei Fragen können natürlich nur im Kontext der vorherrschenden Situation beim Kunden konkret beantwortet werden.

Doch bevor wir darauf eingehen, ist eine Begriffsbestimmung notwendig. Was genau ist ESAE für Microsoft?

Wie definiert Microsoft ESAE (in dem Retirement Artikel)?

In dem Artikel steht es schwarz auf weiß:

„The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is a legacy approach to provide a secure environment for Windows Server Active Directory (AD) administrators.“

ESAE wird also mehr oder weniger mit dem RED Forest Modell gleichgesetzt.

Wer unsere vergangenen Artikel gelesen hat, unsere Top 10 Maßnahmen Infografik kennt oder auch die zahlreichen anderen Seiten im Internet zu dem Thema ESAE liest, stellt fest, dass der Begriff ESAE für die meisten viel mehr bedeutet als „Red Forest“.

teal_infografik_topten

Für die Beantwortung der Fragen in diesem Blog Artikel werden wir die Definition aus dem ESAE Retirement Artikel verwenden.

ESAE Support

„Laufen wir Gefahr, dass unsere jetzige [ESAE] Architektur durch Microsoft nicht mehr supportet wird?“

Die direkte Antwort von Microsoft: „While not a mainstream recommendation, this architectural pattern is valid in a limited set of scenarios.

  • Isolated on-premises environments
  • Highly regulated environments
  • High level security assurance is mandated”

 

Es gibt also auch weiterhin valide Szenarien, in denen Microsoft das “klassische ESAE” Modell unterstützt. Auch interessant ist, dass Microsoft auch selbst weiterhin ein ESAE Setup betreibt.

Weiterhin möchten wir dazu ausführen, dass ESAE eine Architektur und kein Produkt ist. Insofern gibt und gab es noch nie einen Produktsupport im klassischen Sinne. Um die Frage also etwas ausführlicher zu beantworten, müssen wir uns anschauen, aus welchen Komponenten eine ESAE Architektur im Wesentlichen besteht.

Glücklicherweise nutzt die Architektur viele built-in Funktionalitäten der Betriebssysteme, weshalb die Liste erfreulich kurz ist:

ProduktSupport-Ende
Windows 10Rollierend 12 Monate seit dem letzten Update
Windows Server 201909.01.2029
Windows Server 2022Die nächste Version (voraussichtlich) Windows Server 2022 enthält weiterhin Active Directory, womit der Support bis 2032 gesichert sein sollte.
MIM 2016 SP2*13.01.2026
LAPS**N/A

 

*MIM kann für die Anforderung von Shadow Principal Rechten genutzt werden, man kann die höheren Rechte allerdings auch per Powershell anfordern, verliert dann allerdings die Möglichkeit von Approval Workflows.

**LAPS ist leider nicht auf der Product and Services Lifecycle Information Seite zu finden. Allerdings wurde die aktuelle Version 6.2 am 10.06.2020 veröffentlicht. Wir gehen daher davon aus, dass LAPS langfristig supportet wird.

Die Tabelle (inklusive langer Fußnoten 😊) bestätigt somit auch das, was Microsoft in dem Retirement Artikel sagt, man muss sich keine Sorgen machen.

Sicherheitsgewinn

„Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen [ESAE] Setup?“

Diese Frage ist, wie oben schon erwähnt, konkret nur im Kundenkontext zu beantworten. Freundlicherweise definiert Microsoft selbst im Artikel Measuring Success Erfolgskriterien:

Wir nehmen das zum Anlass, mit dem ersten Artikel im Jahr 2021 die (E) SAE Deep Dive Blogserie zu unterbrechen und werden auf die Fragen im Allgemeinen eingehen. Die letzten zwei Fragen können natürlich nur im Kontext der vorherrschenden Situation beim Kunden konkret beantwortet werden.

Doch bevor wir darauf eingehen, ist eine Begriffsbestimmung notwendig. Was genau ist ESAE für Microsoft?

Wie definiert Microsoft ESAE (in dem Retirement Artikel)?

In dem Artikel steht es schwarz auf weiß:

„The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is a legacy approach to provide a secure environment for Windows Server Active Directory (AD) administrators.“

ESAE wird also mehr oder weniger mit dem RED Forest Modell gleichgesetzt.

Wer unsere vergangenen Artikel gelesen hat, unsere Top 10 Maßnahmen Infografik kennt oder auch die zahlreichen anderen Seiten im Internet zu dem Thema ESAE liest, stellt fest, dass der Begriff ESAE für die meisten viel mehr bedeutet als „Red Forest“.

teal_infografik_topten

Für die Beantwortung der Fragen in diesem Blog Artikel werden wir die Definition aus dem ESAE Retirement Artikel verwenden.

ESAE Support

„Laufen wir Gefahr, dass unsere jetzige [ESAE] Architektur durch Microsoft nicht mehr supportet wird?“

Die direkte Antwort von Microsoft: „For customers that have already deployed this architecture, there is no urgency to retire an implementation if it’s being operated as designed and intended.“

Weiterhin möchten wir dazu ausführen, dass ESAE eine Architektur und kein Produkt ist. Insofern gibt und gab es noch nie einen Produktsupport im klassischen Sinne. Um die Frage also etwas ausführlicher zu beantworten, müssen wir uns anschauen, aus welchen Komponenten eine ESAE Architektur im Wesentlichen besteht.

Glücklicherweise nutzt die Architektur viele built-in Funktionalitäten der Betriebssysteme, weshalb die Liste erfreulich kurz ist:

ProduktSupport-Ende
Windows 10Rollierend 12 Monate seit dem letzten Update
Windows Server 201909.01.2029
Windows Server 2022Die nächste Version (voraussichtlich) Windows Server 2022 enthält weiterhin Active Directory, womit der Support bis 2032 gesichert sein sollte.
MIM 2016 SP2*13.01.2026
LAPS**N/A

 

*MIM kann für die Anforderung von Shadow Principal Rechten genutzt werden, man kann die höheren Rechte allerdings auch per Powershell anfordern, verliert dann allerdings die Möglichkeit von Approval Workflows.

**LAPS ist leider nicht auf der Product and Services Lifecycle Information Seite zu finden. Allerdings wurde die aktuelle Version 6.2 am 10.06.2020 veröffentlicht. Wir gehen daher davon aus, dass LAPS langfristig supportet wird.

Die Tabelle (inklusive langer Fußnoten 😊) bestätigt somit auch das, was Microsoft in dem Retirement Artikel sagt, man muss sich keine Sorgen machen.

Sicherheitsgewinn

„Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen [ESAE] Setup?“

Diese Frage ist, wie oben schon erwähnt, konkret nur im Kundenkontext zu beantworten. Freundlicherweise definiert Microsoft selbst im Artikel Measuring Success Erfolgskriterien:

„A successful strategy must address all the points attackers can use to intercept privileged access workflows including four distinct initiatives:

    • Privileged Access workflowelements of the privileged access workflow including underlying devices, operating systems, applications, and identities
    • Identity systemshosting the privileged accounts and the groups, and other artifacts that confer privilege on the accounts
    • User access workflowand authorized elevation paths that can lead to privileged access
    • Application interfaceswhere zero trust access policy is enforced and role-based access control (RBAC) is configured to grant privileges”

Nachfolgend gehen wir auf jede davon ein.

ESAE und Privileged Access Workflow & Identity Systems

Wenn man die Defintion aus dem Retirement Artikel

„provide a secure environment for Windows Server Active Directory (AD) administrators“

zu Grunde legt und der Absicherung der kompletten Privileged Access Plane gegenüberstellt, ist der Sicherheitsgewinn natürlich signifikant.

Quelle: https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model

Wir haben uns mal die Mühe gemacht und die original ESAE Dokumentation aus dem Jahr 2017 aus dem www.web.archive.org gekramt:

„Tier 0 – Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they are all effectively in control of each other.“

Wenn man also heute schon seine kompletten Tier 0 Systeme inklusive denen in der Cloud abgesichert hat, ist der Sicherheitsgewinn aus unserer Sicht gering. Wie weit fortgeschritten das Vorhaben ist, muss natürlich jeder für sich selbst bewerten. Aus unserer Erfahrung ist es aber ein intensiver Weg, alle Tier 0 Systeme zu identifizieren und abzusichern. Das bleibt aber auch im neuen Modell nicht aus und ist mindestens genauso komplex wie zuvor.

ESAE und User Access Workflow

Der Punkt ist leider ohne nähere Erläuterung seitens Microsoft nicht zu bewerten.

In dem Schaubild der „planes“ oben ist kein „authorized elevation path“ vom normalen User zu „privileged access“ zu erkennen. Aus unserer Sicht aus gutem Grund, da es den per Definition eigentlich nicht geben soll…

ESAE und Application Interfaces

Das ist aus unserer Sicht tatsächlich eine Neuerung gegenüber dem “klassischen Ansatz”. Zumindest in der Konsequenz, mit der es in der Zero Trust Dokumentation gefordert wird:

„This is the core of Zero Trust. Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network.“

Quelle: https://docs.microsoft.com/en-us/security/zero-trust/

Allerdings muss man die Praktikabilität des Punktes (in der geforderten Konsequenz) aus unserer Sicht hinterfragen. Sicher, es gibt heute Technologien wie Azure Conditional Access und Azure Application Proxy, mit denen man relativ leicht für einen Teil der Anwendungen eine Verifizierung der Requests auf Basis mehrerer Datenpunkte durchführen kann, bevor man einem Nutzer (oder einer App) Zugang gewährt. Allerdings, wenn man sich die Technologien genauer anschaut, wird man feststellen, dass die Story noch nicht rund ist.

Der Azure Application Proxy unterstützt z.B. nur Webapplikationen. Was aber macht man mit den ganzen (eingekauften) Applikationen, die einen eigenen Fat Client mitbringen? Da hilft dann wohl nur ein umfassendes App Modernisierungsprogramm…

In den anderen fünf Bereichen sieht es vermutlich ähnlich oder schlechter aus. Aus unserer Sicht wird es noch einige Zeit dauern, bis eine normale Firma Zero Trust großflächig einsetzen kann.

Aufwand

An dieser Stelle fällt es schwer, nicht zynisch zu werden. Auf der einen Seite ist ein Argument von Microsoft, dass der Aufbau des Red Forests zu lange dauert, auf der anderen Seite ist eines der Erfolgskriterien die Einführung eines Zero Trust Models auf allen technischen Ebenen des Unternehmens. So eine Einführung dauert je nach Unternehmen sicherlich mehrere Jahre.

Mit der jetzigen Dokumentation sehen wir uns derzeit nicht in der Lage, auch nur eine High Level Schätzung dafür zu machen. Grundsätzlich ist aber festzustellen, dass sowohl das alte ESAE Modell als auch die neue Architektur enorm zeitaufwändig sind und viel Kraft bei der Einführung kosten. Diese Anstrengungen müssen aber zwingend angegangen werden, man vergleiche z.B. den Schaden durch eine erfolgreiche Ransomware Attacke. IT Security sollte als eine konstante Investition in das Wissen der eigenen Belegschaft und der Absicherung der Infrastruktur gesehen werden. Es ist schlicht falsch, zu glauben, es kann einmalig ein hoher Betrag investiert werden und danach ist man „sicher“. Wie Microsoft selbst sagt, geht es darum, die Hürde möglichst hoch zu legen und es möglichst teuer und unattraktiv für die Angreifer zu machen.

Resumee

Es wäre leicht, zu behaupten, dass Microsoft die Architektur abändert, um sich auf lange Sicht des on-prem Active Directories zu entledigen und gleichzeitig das Cloud Geschäft anzukurbeln. Die Wahrheit liegt unserer Meinung nach dazwischen. Microsoft hat vollkommen recht, dass in Zukunft immer mehr Cloud Services genutzt werden und gerade alte legacy Architekturen immer wieder zu erfolgreichen Einbrüchen führen. Deswegen finden wir es richtig und konsequent, sich für die Zukunft alter Gewohnheiten zu entledigen und moderne und hochsichere Produkte und Arbeitsweisen zu implementieren.

Gleichzeitig ist die Realität bei den meisten Kunden aus unserer Sicht eine andere. Die wenigsten gewachsenen Strukturen können „einfach so“ auf eine Cloud-Only Strategie setzen und zentrale und wichtige legacy Applikationen modernisieren oder einfach austauschen. Gleiches gilt für ein seit Jahren gewachsenes Active Directory. Das kann man nicht einfach mal so nach Azure AD migrieren.

Versteht uns nicht falsch, dem Strategie Artikel können wir voll beipflichten. Das sind definitiv die richtigen strategischen Ziele, allerdings sind wir von der konkreten Umsetzungsbeschreibung im Security Rapid Modernization Plan enttäuscht. Der RAMP deckt nur die Privileged Access Plane ab (und auch nicht unbedingt vollständig).

Die anderen Ebenen werden gar nicht behandelt und auch von Zero Trust Einführung ist hier nichts mehr zu finden. Wenn man die Zero Trust Dokumentation liest, gibt es auch hier keine konkreten Handlungsbeschreibungen.

Zusammenfassend kann man aber sagen, dass Microsoft sehr wichtige Punkte anspricht und die Frage aufwirft, ob man mit den lokalen Gegebenheiten die jeweilige Umgebung vernünftig absichern kann. Klar ist, dass man sich mit dem Thema Security nachhaltig beschäftigen muss und seine Umgebung konsequent und iterativ verbessern muss. Ob mit oder ohne RED Forest, die meisten anderen Maßnahmen aus unserer TOP 10 Liste oder unserem Assessment sind nach wie vor valide und müssen betrachtet werden.

Quelle Titelbild: Adobe Stock/Nomad_Soul

LATEST POSTS