ESAE Serie Teil 1 - Einleitung - TEAL Technology Consulting GmbH
523
post-template-default,single,single-post,postid-523,single-format-standard,bridge-core-3.1.4,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.3,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-7.5,vc_responsive

ESAE Serie Teil 1 – Einleitung

In der Blog Kategorie „Secure Administration Environment” möchten wir unsere Erfahrungen von Kundenprojekten rund um Microsofts Enhanced Security Administration Environment (ESAE) wiedergeben, sodass andere von unseren Erfahrungen lernen können und nicht über die gleichen Probleme stolpern wie wir.

Den Anfang machen wird eine Serie über ein sehr spannendes Thema, welches wir für einen global tätigen Versicherer in den letzten Monaten bearbeiten durften: Den kompletten Aufbau einer von ESAE inspirierten Umgebung.

In diesem ersten Artikel der Serie möchten wir erklären, worum es sich dabei handelt und warum man es braucht und aus welchen Komponenten die Umgebung besteht. In weiteren Artikeln werden wir einzelne Komponenten näher beleuchten, um im letzten Artikel unsere praktischen Erfahrungen und unseren Umgang mit den Stolpersteinen zusammenzufassen.

ESAE ist ein Design Approach von Microsoft (ESAE Dokumentation von Microsoft) um Credential Theft und Pass the Hash \ Pass the Ticket Angriffe zu erschweren bzw. deren Auswirkung zu reduzieren. Zu den Themen Credential Theft, Pass the Hash \ Pass the Ticket gibt es ganze Blogserien und Whitepaper (http://adsecurity.org/ und Microsoft Whitepaper), weshalb wir uns auf eine kurze Zusammenfassung beschränken und weiterführende Themen verlinken.

Das Problem:

Aufgrund der Art und Weise, wie Windows und Active Directory funktionieren, gibt es eine Reihe von Möglichkeiten für Angreifer, Passwörter oder deren Hashes auszulesen und weiterzuverwenden. Alles, was dazu nötig ist, sind Adminrechte auf einer Workstation und frei zugängliche Tools wie z.B. Mimikatz (Github und BlueHat Vortrag (English)).

Adminrechte können z.B. über einen Phishing Angriff oder einen Social Engineering Angriff erbeutet werden. Allein im Jahr 2016 wurden laut der Studie „Wombat Security State of the Phish 2017″ 76% aller Organisationen Opfer von Phishing Angriffen. Gerade bei größeren Organisationen ist die Wahrscheinlichkeit groß, dass früher oder später ein Angreifer Erfolg hat.

Im nächsten Schritt versucht der Angreifer sich im Netzwerk auszubreiten. Früher mussten sich Angreifer zeitaufwändig mittels Trial und Error durch das Netzwerk bewegen, um irgendwann privilegierte Konten zu erbeuten. Heute gibt es Tools wie Bloodhound (Github und – DEF CON 24 Vortrag (Englisch)), die innerhalb von wenigen Minuten den Weg vom erbeuteten Rechner zum Domain Admin Konto (oder jedem beliebigen anderen) aufzeigen.

Ich empfehle jedem, die verlinkten Vorträge anzuschauen. Es wird Augen öffnen!

Die (ESAE) Lösung:

Wie oben schon gesagt ist ESAE keine einzelne Technik, kein Tool oder Service, der all diese Probleme löst, sondern eine Reihe von Techniken, Tools und Arbeitsweisen, die es einem Angreifer erschweren, hochprivilegierte Konten zu erbeuten und damit Schaden anzurichten.

Kern der Lösung ist es, die IT Services und Systeme anhand des Schutzbedarfs in verschiedene Klassen bzw. englisch Tiers zu unterteilen und die Adminkonten für die Tiers mit hohem Schutzbedarf in einen eigenen Administrationsforest auszulagern.

Wenn man sich die Microsoft Dokumentation betrachtet, werden die Systeme wie folgt in die Tiers einsortiert:

Tier 0: Enterprise Identity Systeme, wie Active Directory, PAM Systeme, ADFS.

Tier 1: Enterprise Anwendungen, wie Email, Kollaboration und sonstige Line of Business Applications.

Tier 2: Workstations

Diese Einteilung muss natürlich mit einer Prise Salz genossen werden. Jede Firma hat das ein oder andere höchst schützenwerte System, welches nicht in obige Definition für Tier 0 fällt. Diese Systeme können und sollten natürlich genauso geschützt werden.

Per se haben die Admin-Konten jedoch keine stehenden Administrationsrechte. Diese müssen über eine Just in Time Privilege Access Management (PAM) Lösung für einen definierten Zeitraum angefordert werden. Weiterhin kann die Umgebung nur mit gehärteten Privilege Access Workstations (PAWs) administriert werden.

Da die Einleitung doch etwas länger als erwartet geworden ist, machen wir hier einen Cut und stellen das konkrete Kundenszenario und die gewählte Architektur im nächsten Blogartikel vor.

Bildquelle: freepik.com

LATEST POSTS

  • Die Künstliche Intelligenz (KI) ist ein faszinierendes und immer wieder viel diskutiertes Thema in der heutigen Technologie- und Informationsgesellschaft. Egal ob in der Wissenschaft, der Industrie oder im Alltag, die Möglichkeiten...

  • Nein, im zweiten Teil werden wir nicht noch ein Interview mit ChatGPT führen und über dessen Fähigkeiten staunen. Diesmal betrachten wir die Entwicklung und Möglichkeiten von KI im Allgemeinen und wagen einen Ausblick in die Zukunft, die in der IT-Welt...

  • Die Geschwindigkeit der Weiterentwicklung und Ausbreitung von KI-Technologie ist inzwischen enorm gestiegen. Allein in den wenigen Wochen seit dem letzten Blog zu diesem Thema...