ESAE is dead – Long live SAE, oder Totgesagte leben länger?
2941
post-template-default,single,single-post,postid-2941,single-format-standard,bridge-core-3.0.1,,no_animation_on_touch,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-28.7,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.9.0,vc_responsive

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

Beitragsupdate:

Als wir Anfang 2021 einen Blogpost zum Thema Enhanced Security Admin Environment (ESAE) Retirement veröffentlicht haben, konnten wir noch nicht wissen, dass dies einer der meistgelesenen Artikel werden sollte. Grund genug ein Jahr später die Situation erneut zu bewerten und unsere aktuelle Sicht wiederzugeben.

Die Dokumentation hat sich seitdem nicht grundlegend verändert, Microsoft beschreibt das Vorgehen wie folgt – Securing privileged access. Nach wie vor gibt es folgendes Bild, das suggeriert, dass das „alte“ ESAE Modell ausgedient hat und in Rente geschickt wird.

Microsoft Retired Teal - Enhanced Security Admin Environment ESAE

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 bis heute 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 gab es viel Aufregung und Kunden hatten Angst, dass bereits getätigte Investitionen umsonst waren. Zusammenfassend sehen wir drei Kernfragen:

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

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“.

Top Ten Teal - Enhanced Security Admin Environment ESAE

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 on-prem [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 202213.10.2031
MIM 2016 SP2*13.01.2026
LAPS**N/A
ProduktSupport-Ende
Windows 10Rollierend 12 Monate seit dem letzten Update
Windows Server 201909.01.2029
Windows Server 202213.10.2031
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 workflow elements of the privileged access workflow including underlying devices, operating systems, applications, and identities
    • Identity systems hosting the privileged accounts and the groups, and other artifacts that confer privilege on the accounts
    • User access workflow and authorized elevation paths that can lead to privileged access
    • Application interfaces where 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.

Privileged Access Teal - Enhanced Security Admin Environment ESAE

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.“

Zero Trust Security Teal - Enhanced Security Admin Environment ESAE

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.

Letztendlich beobachten wir eine hybride Strategie. Keiner unserer Kunden hat bislang den Weg zu 100% in die Cloud geschafft. Gleichzeitig werden aber immer mehr Workloads in der Cloud abgebildet. Da ist nur konsequent, den Blick auch auf die Cloud Produkte zu richten. Diese können genutzt werden um die eigene Cloud Instanz abzusichern, aber gleichzeitig auch on-prem Umgebungen sicherer machen. Wir sehen immer mehr, dass Kunden beispielsweise Cloud PAWs oder Services wie Azure sentinel nutzen um z.B. SPLUNK zu ersetzen. Das kann sinnvoll sein und bietet jede Menge neue Möglichkeiten eine Umgebung besser abzusichern.

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 und können künftig ggf. mit Cloud Lösungen erweitert werden.

Quelle Titelbild: Adobe Stock/Nomad_Soul

LATEST POSTS

  • 24 Monate nach der Gründung von TEAL heißt es, eine Zwischenbilanz zu ziehen und einmal DANKE zu sagen. Danke an unsere Kunden und danke an unser Team. Es macht wirklich Spaß...

  • Wir feiern in diesem Monat mit unserem Team fünf Jahre TEAL. Fünf Jahre vollgepackt mit stetig weiterentwickeltem Know-How bei der Kundenarbeit, internen Projekten und kontinuierlichem Wachstum des Unternehmens. Mit einem steig wachsenden Team und großartigen Kundenprojekten, haben wir uns in...

  • Unser Blog-Beitrag für diesen Monat beschäftigt sich mit einem Thema, das nicht direkt mit Informationssicherheit zu tun hat. Dennoch darf dieses Thema nicht unterschätzt und vernachlässigt werden. Es geht um die automatisierte Installation von Windows Server im Unternehmen. Das hört sich erst ...