Credential Tiering ist eine essentielle Komponente in der identitätszentrierten Sicherheit und sollte keinesfalls unterschätzt werden. Tiering spielt eine entscheidende Rolle bei der Steigerung der Sicherheit einer IT-Umgebung. Die Implementierung von Credential Tiering etabliert einen robusten Schutz gegen potenzielle Sicherheitsverletzungen, welche dem gesamten Unternehmen schaden und die Grundprinzipien der Vertraulichkeit, Integrität und Verfügbarkeit gefährden könnten. Es ist zu betonen, dass Credential Tiering die grundlegenden Herausforderungen des Anmeldedaten-Diebstahls adressiert, die nicht einfach durch trendige Cloud-Lösungen oder toolbasierte Methoden ersetzt werden können.

Dieser erste Artikel einer zweiteiligen Serie erörtert die Bedeutung von Credential Tiering am Beispiel des Microsoft Credential Tier Modells. Der zweite Teil befasst sich mit der Implementierung, der Identifizierung von Tier-0-Objekten sowie der Messung und Visualisierung des Fortschritts bei der Implementierung einer Active Directory Credential Tier Umsetzung.

Warum sollte uns das interessieren?

Andy Robbins von SpecterOps machte während einer seiner Präsentationen Attacking and Defending Azure with BloodHound, eine Aussage, die Aufmerksamkeit verdient: “Seit über 20 Jahren werden immer wieder die gleichen oder ähnliche Tactics, Techniques und Procedures (TTP) eingesetzt, um Unternehmen zu kompromittieren, die Active Directory verwenden.” Warum ist dies immer wieder der Fall? Active Directory ist ein weit verbreiteter Identity Provider (IdP) und ist in fast allen IT-Umgebungen anzutreffen. Aufgrund seiner Beliebtheit und seines Alters sind Schwachstellen in diesem Dienst gut dokumentiert und manifestieren sich auf verschiedene Weise, einschliesslich legitimen Protokollmissbrauchs, falsche Konfigurationen, suboptimale Verwaltungspraktiken, Missbrauch von Berechtigungen, Vernachlässigung von Updates oder Härtungsempfehlungen und mehr.

Die Herausforderungen im Zusammenhang mit IdPs sind nicht nur bei Active Directory zu finden; andere IdPs wie AWS, Entra ID und GCP stehen vor ähnlichen Hürden. Grosse Unternehmen wie Google, Microsoft und Amazon scheinen die Schwierigkeiten beim sicheren Betrieb dieser Systeme auch nicht vollständig lösen zu können. Das einfache Hinzufügen weiterer Sicherheitstools löst die Ursache nicht wirklich. Stattdessen sollte der Fokus auf grundlegende Präventionsmethoden gelegt werden. In dem Blogbeitrag Defenders Mindset stellt John Lamberts fest: “Verteidiger denken in Listen. Angreifer denken in Graphen. Solange dies der Fall ist, gewinnen die Angreifer”. Dies unterstreicht die Notwendigkeit eines Perspektivwechsels und betont, wie wichtig es ist, die Taktiken des Gegners zu verstehen und einen proaktiven, strategischen Ansatz für die Sicherheit zu wählen. Ohne ein Umdenken bei der Sicherung von IT-Umgebungen werden wir immer wieder dieselben Diskussionen führen müssen, da die Gegner weiterhin dieselben Tactics, Techniques und Procedures anwenden, um IT-Umgebungen zu komprimittieren.

Eine äusserst wirksame Strategie zur Verbesserung der Sicherheit von Active Directory besteht darin, die vorhandenen Angriffspfade zu analysieren und die Auswirkungen ihrer Beseitigung zu bewerten. Detaillierte Einblicke in diesen Ansatz bieten die Artikel The Attack Path Management Manifesto von Andy Robbins und Attack Path Analysis – Gaining an Advantage Over Adversaries von mir. Es ist jedoch unerlässlich, einen Sicherheitsstandard für eine Active Directory-Umgebung zu erreichen. Andernfalls können entfernte Angriffspfade wieder auftauchen. Um einen definierten Zustand herzustellen, ist ein Sicherheitsmodell namens Credential Tiering unerlässlich. Im folgenden Kapitel wird das Konzept des Tiering und seine Bedeutung als grundlegendes Element zur Sicherung einer identitätszentrierten Umgebung wie Active Directory erläutert.

Was ist Credential Tiering?

Ein Tier-Modell ist ein Framework, das Identitäten und die Ressourcen, auf die sie zugreifen, auf der Grundlage ihres Wertes oder ihrer Bedeutung in verschiedene Tiers einteilt. Die Einteilung in Tiers erfordert die Implementierung von Sicherheitskontrollen, um die Trennung zwischen diesen Tiers aufrechtzuerhalten. Darüber hinaus definiert es Regeln für die Trennung, legt grundlegende Kontrollen fest, die vorhanden sein müssen, und erkennt die Möglichkeit zusätzlicher Kontrollen an. Je nach Umgebung gibt es verschiedene Arten von Tier-Modellen, z. B. für lokale Infrastruktur, Active Directory, Microsoft Cloud, AWS, geschäftskritische Anwendungen usw. Das grundlegende Konzept eines Tier-Modells stammt aus dem Bell-LaPadula-Sicherheitsmodell, das auf die Wahrung der Datenvertraulichkeit abzielt, und dem Biba-Modell, das sich auf die Datenintegrität konzentriert.

Eine ausführlichere Erklärung, ob Tiering hilfreich ist, findet sich in den folgenden beiden Artikeln, die 2012 und 2014 von Micosoft veröffentlicht wurden: Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques_English.pdf und Mitigating-Pass-the-Hash-Attackss-and-Other-Credential-Theft-Version-2.pdf. Diese Dokumente behandeln Angriffe auf Active Directory und bieten ganzheitliche Planungsstrategien, die in Kombination mit den Windows-Sicherheitsfunktionen eine effektivere Verteidigung gegen Angriffe auf Credential Theft ermöglichen. Die beiden Artikel sind sehr empfehlenswert. In dem einten Artikel aus dem Jahr 2014 erklärt Microsoft Tiering als eine Möglichkeit, um zu verhindern, dass eine gesamte IT-Umgebung durch den Verlust eines einzelnen Assets gefährdet wird. Dabei wird eine Analogie zu grossen Schiffen verwendet, die über Abteilungen verfügen, um den durch ein Leck verursachten Schaden zu begrenzen. Indem IT-Umgebungen in ähnlicher Weise konzipiert werden, kann der Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit eines oder mehrerer Assets eingedämmt und verhindert werden, dass der Rest der Umgebung in Mitleidenschaft gezogen wird. Im Anschluss an die Analogie wird das Containment-Modell vorgestellt und als Tiering Model Designed for Active Directory bezeichnet. In diesem Artikel bezeichnen wir das Modell als Microsoft Credential Tier-Modell. Dieses Modell hat drei Tiers von Verwaltungsrechten, aber in bestimmten Fällen können zusätzliche Tiers erforderlich sein. Zusätzliche Tiers müssen jedoch mit Bedacht hinzugefügt werden und sollten nicht zu unnötigen Tiering Verstössen führen.

• Tier-0 – Forest und Domain Administratoren: Direkte oder indirekte administrative Kontrolle über die Active Directory-Gesamtstruktur, Domänen oder Domänencontroller (DC). Dazu gehört auch der administrative Zugriff auf Speichergeräte, die Active Directory-Datenbankdateien enthalten.
• Tier-1 – Server-Administratoren: Direkte oder indirekte administrative Kontrolle über einen einzelnen oder mehrere Server, die nicht unter Tier-0 fallen. Geschäftskritische Server gehören ebenfalls zu dieser Ebene.
• Tier-2 – Workstation-Administratoren, Benutzeradministratoren, Helpdesk-Techniker: Direkte oder indirekte administrative Kontrolle über ein einzelnes oder mehrere Geräte und tägliche Benutzerkonten.

Das Modell zielt darauf ab, Angreifer daran zu hindern, mit gestohlenen Anmeldedaten höhere Privilegien zu erlangen. Microsoft beschreibt die folgenden Regeln für das Modell:

• Jede administrative Ressource, wie z. B. Gruppe, Konto, Server, Arbeitsstation, Active Directory-Objekt oder Anwendung, gehört nur zu einer Ebene.
• Mitarbeiter, die auf mehreren Tiers arbeiten, haben separate administrative Konten für jede Ebene, die sie benötigen. Jedes Konto, das auf mehr als eine Ebene zugreift, wird in mehrere Konten aufgeteilt, von denen jedes innerhalb einer Ebene bleibt. Diese Konten haben auch unterschiedliche Passwörter.
• Administratorkonten können keine Ressourcen höherer Tiers durch administrativen Zugriff kontrollieren, z. B. ACLs, Anwendungsagenten oder die Kontrolle von Dienstkonten. Konten, die eine höhere Ebene kontrollieren, können sich nicht bei Computern der niedrigeren Ebene anmelden, da dies die Anmeldedaten und Berechtigungen des Kontos offenlegen und gefährden könnte.
• Administratorkonten können Ressourcen der unteren Tiers entsprechend ihrer Rolle steuern, aber nur über Verwaltungsschnittstellen der höheren Ebene, die keine Anmeldeinformationen preisgeben. Beispielsweise können Domänen-Administratorkonten (Tier 0) Server-Admin-Active-Directory-Kontoobjekte (Tier 1) über Active-Directory-Verwaltungskonsolen auf einem Domänencontroller (Tier 0) verwalten.

In welchem Tier befinden sich meine IT-Lösungen?

Um eine Tier-Zuordnung vornehmen zu können, muss eine ganzheitliche Betrachtung jedes einzelnen Dienstes und jeder Active Directory-Berechtigung vorgenommen werden. Dabei muss immer die folgende Frage beantwortet werden: Ergibt sich ein Control-Up oder ein Exposure-Down Risiko? Ein Beispiel: Virtuelle Maschinen von Domänencontrollern werden von der Lösung System Center Configuration Manager (SCCM) verwaltet. SCCM wird von Tier-1-Administratoren verwaltet. Dies führt zu einem Control-Up-Risiko und damit zu einem Verstoss gegen das Tiering. Dieses Beispiel beschreibt das Paradigma der Abhängigkeitskette. Weitere vorgelagerte Risiken für einen Domänencontroller wären zum Beispiel:

• Verwaltungsagenten auf dem Server und Scheduled Tasks
• Ungepatchte Software-Schwachstellen, schwache Betriebssystemkonfiguration
• Backup- und Speicheradministratoren
• Baseboard Management Controllers (BMCs)
• Physischer Zugang und Administratoren virtueller Maschinen
• ACLs auf Active Directory objekte
• Host-Installationsmedien/Prozess
• Anwendungsadministrationsrollen (Domänen-/Enterprise-/Schema-Administratoren, Konto-/Server-Operatoren usw.)
• Hosts, auf denen vorgelagerte Administratoranmeldeinformationen offengelegt werden
• Erweiterungen der Security Boundary (Trusts zu anderen Verzeichnissen, Verwaltung duch Service Provider)

Und übersetzt in ein unfertigen Graphen. P.S.: Es ist eine wertvolle Übung, den unten stehenden Graphen zu erweitern, um die Abhängigkeitskette zu wichtigen IT-Komponenten zu veranschaulichen.

Alle oben identifizierten Upstream-Risiken können zu einer Downstream-Kontrolle aller Geschäftsdaten, Konten und Geräte führen, die direkt oder indirekt von Active Directory verwaltet werden. Basierend auf dieser Erkenntnis muss jede identifizierte Tiering-Verletzung angegangen werden. Es gibt verschiedene Möglichkeiten der Schadensbegrenzung:

Eine andere Möglichkeit, um Tiering-Verstösse zu eruieren, kann über folgende Methode erfolgen:

• Definieren des Anwendungsfalls: Ich möchte meinen Alltagslaptop benutzen, um mich mit meinem Domänenadministrator bei meinem Jump Server anzumelden und alle meine Domänencontroller zu verwalten.
• Zweitens, zeichnen des Anwendungsfalls: Ein Raster zeichnen mit den Tiers und den Entitäten, die für den Anwendungsfall erforderlich sind.
• Drittens, zeichnen der Verbindungen: user1 ist auf notebook1 angemeldet, user1 gibt das Passwort von admin1 auf notebook1 ein, um sich auf dem Server jumpserver1 anzumelden, von jumpserver1 aus wird admin1 benutzt, um DC1 zu verwalten.
• Viertens: Erkennen der Verstösse: Markieren und nummerieren der Grenzen, welche die Verbindung überschreiten.

Die folgende Zeichnung dient als Beispiel für den Anwendungsfall:

Die Zeichnung zeigt vier Tiering Violations:

• Erster und zweiter Verstoss: Anmeldedaten Exposure-Down Verstoss zu Tier 1 und Tier 2
• Dritter Verstoss: Verstoss gegen control-up Regel
• Vierter Verstoss: Verstoss gegen control-up Regel

Dies ist übrigens ein gängiges Verwaltungsmuster, auf das wir bei Assessments oder Red-Team-Einsätzen häufig stossen. Intern nennen wir den Server jumpserver1 credential harvester und er ist oft eines unserer Ziele. Zurück zum Thema, was wir tun können, um die Tiering Verstösse abzuschwächen. Von unseren fünf oben vorgestellten Optionen sollten wir uns für Option B entscheiden:

• Erstellen einer Privileged Access Workstation (PAW) in Tier 0 als f1t0paw01.
• A1 in Tier 0 als f1t00user1 neu erstellen.
• Erstellen eines dedizierten JMP-Servers in Tier 0 als f1t0jmp1. (Optional)
• Anmelden mit Benutzer f1t00user1 an der PAW und eine Verbindung zum Tier 0 Jumpserver f1t0jmp01 herstellen.
• Verwalten der Domänencontroller f1t0ads01 über den dedizierten Jumpserver f1t0jmp01 oder direkt von der PAW.

Jede Entität in einem Tiering sollte einer strengen Namenskonvention folgen. Dies bietet mehrere Vorteile, insbesondere im Hinblick fürs Auditieren. Nachfolgend ein Beispiel für Benutzerkonten:

Wenn keine der Optionen zur Risikominderung umgesetzt werden kann, sollten Analysen durchgeführt werden, um zu ermitteln, wie die Ausnutzung der Tiering-Verstösse erschwert oder zumindest Überwacht werden können. Wenn nichts machbar ist, sollte das Risiko formell akzeptiert werden und zusammen mit den möglichen Konsequenzen im Falle eines Vorfalls dokumentiert werden.

Wie sieht es mit den Risiken von Lateral Traversal aus?

Um die Bedrohung durch Laterale Traversal auf jedem Tier abzuschwächen, muss es spezielle privilegierte Benutzer geben, die für Verwaltungsaufgaben Zugriff auf Objekte erhalten. Ein Beispiel hierfür ist ein Serveradministrator, der Zugriff auf die Server und Dienste erhält, um regelmässige Wartungs- und Überwachungsaufgaben durchzuführen. Für die Verwaltung dieser Serveradministratoren wird jedoch auch ein privilegierter Zugang benötigt. Dieser Zugang wird von einem Tier-Administrator wahrgenommen. Ein weiteres Beispiel in Form eines Anwendungsfalls:

• Anwendungsfall: Ich bin user1 und habe die folgenden IT-Rollen in meinem Unternehmen: Tier1-Eigentümer, Server-Administrator, Verantwortlicher für Business App1

Um das Risiko von Lateral Traversal für user1 zu minimieren, sind mehrere Administratorenkonten erforderlich:

• Erstellen eines Tier 1 Administrators: f1t10user1
• Erstellen eines Tier 1 Server Administrators: f1t11user1
• Erstellen eines Tier 1 Mehrzweck Administrators für App1: f1t12user1 (d.h. ein Administrator mit erhöhten Rechten, der auf einige wenige Server beschränkt ist)

In diesem Fall sollte user1 drei verschiedene Administratorkonten haben. Eine Privileged Access Management (PAM) Lösung kann verwendet werden, um die Anzahl der dedizierten Administratorkonten zu minimieren. Allerdings stossen wir häufig auf PAM-Konfigurationen, die als kostspielige Security-by-Obscurity-Lösungen eingesetz werden. Sie implizieren oft, dass Benutzer zunächst einen separaten Genehmigungsprozess für die Zugriffsverwaltung durchlaufen haben, anschliessend aber unabhängig vom verwendeten Gerät vorübergehend erhöhte Berechtigungen erhalten können, ohne dass eine Multi-Faktor-Authentifizierung (MFA) oder ein Genehmigungsprozess erforderlich ist. Folglich ist es für PAM-Lösungen von entscheidender Bedeutung, dass sich die Implementierung an die oben beschriebenen Regeln hält, um Tieringverstösse zu vermeiden

Ist das alles, was das Tiering betrifft?

Natürlich gibt es noch weitere wesentliche Aspekte, die zu einer erfolgreichen Credential Tier-Implementierung beitragen. Dazu gehören beispielweise Security Boundaries, Privileged Access Workstation (PAW), Hardening, Access-Management sowie Automatisierung. Die folgende vereinfachte Credential Tiering Hierarchy of Needs orientiert sich an Maslows Hierarchy of Needs und der Incident Response Hierarchy of Needs. Sie skizziert die Phasen, die Unternehmen durchlaufen können, um den Diebstahl von Anmeldedaten für Angreifer zu erschweren. Die Fähigkeiten am unteren Ende der Hierarchie dienen als wesentliche Voraussetzung für die wirksame Umsetzung der darüber liegenden Fähigkeiten, einschliesslich derjenigen, die mit dem Credential-Tier-Modell verbunden sind.

Das neue Tiering-Modell von Microsoft

Laut Microsoft ersetzt das Enterprise Access Model das Active Directory-Tiering-Modell, das entwickelt wurde, um eine unbefugte Ausweitung von Berechtigungen in einer lokalen Windows Server Active Directory-Umgebung zu verhindern. Das Enterprise Access Model soll alle Elemente des Active Directory Credential Tier-Modells umfassen und gleichzeitig die Anforderungen an die Zugriffsverwaltung eines modernen Unternehmens erfüllen, einschliesslich lokaler, mehrerer Clouds, interner und externer Benutzerzugriffe und mehr. In dem neuen Modell entspricht die Control Plane dem Tier 0, während die Management Plane und die Data/Workload Plane dem Tier 1 entsprechen. Der Zugriff auf die Tiers in Tier 0 und Tier 1 sollte von Privileged Access Workstations (PAW) aus erfolgen, getrennt vom regulären Benutzerzugriff und App-Zugriff von Geräten in Tier 2. Nachzulesen in dem Artikel Securing Priviled Access. Zusammenfassend lässt sich sagen, dass sich nichts geändert hat, die Herausforderungen der Segregation sind identisch. Die Aufrechterhaltung einer sicheren Active-Directory-Umgebung ist eine Herausforderung, die Aufrechterhaltung einer sicheren Cloud-Umgebung ist noch schwieriger, je nach Komplexität der Umgebung. Der Artikel Microsoft Cloud Security – The Top-10 Riskiest Configurations beschreibt, was wir bei der Bewertung von Cloud-Umgebungen sehen. Die meisten der skizzierten Risiken können mit Credential Tiering angegangen werden.

Wo sollen wir anfangen?

Der zweite Artikel befasst sich mit dieser Frage. Der Artikel liefert Anhaltspunkte, wie der Übergang zu einer Umgebung mit mehreren Tiers aussehen kann. Ausserdem wird eine Methode zur Messung der Sicherheitsverbesserungen während dieses Prozesses vorgestellt.

Zusammenfassung

Um die Sicherheit in einer identitätszentrierten Umgebung zu erhöhen, ist Credential Tiering eine grundlegende Komponente. Es kann dazu beitragen, Sicherheitsverletzungen zu verhindern, die die Vertraulichkeit, Integrität oder Verfügbarkeit der gesamten Umgebung gefährden könnten. Es ist wichtig, die Bedeutung von Upstream-Risiken und ihre möglichen Auswirkungen auf die Downstream-Kontrollen zu berücksichtigen. Tiering ist ein dauerhaftes Konzept, das nicht einfach durch Cloud-Lösungen oder andere toolbasierte Methoden ersetzt werden kann. Daher ist es wichtig, den Wert von Tiering zu verstehen und es auf identitätszentrierte Lösungen anzuwenden. Die Implementierung von Tiering kann einen erheblichen Aufwand erfordern, da das Problem umfassend angegangen wird und mehrere Teams involviert werden müssen. Ein schrittweises Vorgehen, das sich zunächst auf die privilegiertesten Entitäten konzentriert, kann die Sicherheit jedoch erheblich verbessern und es einem Angreifer bereits erschweren, weitreichende Zugriffsrechte zu erlangen.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model
• https://en.wikipedia.org/wiki/Biba_Model
• https://en.wikipedia.org/wiki/Maslows_hierarchy_of_needs
• https://gist.github.com/m8r1us/c4e3af44062ee513fab01d20483a87c6
• https://github.com/swannman/ircapabilities
• https://learn.microsoft.com/en-us/security/privileged-access-workstations/overview
• https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
• https://medium.com/@johnlatwc/defenders-mindset-319854d10aaa
• https://posts.specterops.io/the-attack-path-management-manifesto-3a3b117f5e5
• https://www.microsoft.com/en-US/download/details.aspx?id=36036
• https://www.youtube.com/watch?v=GTR-K7urwBk