Credential Tiering - Umsetzung von Tier 0

Credential Tiering

Umsetzung von Tier 0

Marius Elmiger
von Marius Elmiger
am 14. Dezember 2023
Lesezeit: 23 Minuten

Keypoints

Methoden zur Umsetzung von Tier 0

  • Erstellung eines Umsetzungsplans ist wichtig
  • Tier 0 sollte zuerst umgesetzt werden
  • Eine Vielzahl von Tier 0-Objekten kann über das Active Directory identifiziert werden
  • Es existieren aber auch Tier 0-Objekte ausserhalb des Active Directory, Tier 0-Objekte sollten laufend evaluiert werden
  • Die Umsetzung von Tier 0 führt in der Regel nicht zu Ausfallzeiten
  • Die Schwierigkeit bei der Umsetzung von Tiering liegt vor allem in der bestehenden Verwaltungsroutine

IT-Projekte fangen oft gut an, enden aber leider manchmal mit einer mittelmässigen Lösung oder zu vielen Ausnahmen. Die Implementierung von Credential Tiering hingegen erfordert ein kontinuierliches Engagement, um die definierten Ziele zu erreichen und Ausnahmen zu minimieren. Eine gut definierte Implementierungsstrategie ist unerlässlich, ebenso wie die Entschlossenheit aller beteiligten Parteien, die Sicherheit eines kritischen IT-Dienstes wie Active Directory durch Credential Tiering merklich zu verbessern.

Dieser zweite Artikel einer zweiteiligen Serie bietet einen Leitfaden für den Übergang zu einer Active Directory Credential Tiering Umgebung mit Schwerpunkt auf Tier-0. Ausserdem wird eine Methode zur kontinuierlichen Messung der Sicherheitsverbesserungen vorgestellt. Die beschriebenen Methoden lassen sich auch auf andere identitätszentrierte Lösungen übertragen. Der folgende Abschnitt orientiert sich am Tiering-Modell von Microsoft, welches im ersten Teil beschrieben wird, und an unseren Erfahrungen mit der Implementierung sowie der Ausnutzung von nicht segregierten Umgebungen während unserer Engagements.

Der Plan

Bevor man sich kopfüber in die Umsetzung stürzt, kann es von Vorteil sein, einen Plan zu haben. Die Einführung von Credential Tiering ist oft ein umfangreiches Projekt, das einen detaillierten Überblick über die Strategie, die Ziele und die Aufgaben erfordert, um Credential-Tiering einzuführen. Ein Projektplan hilft dabei bei der Organisation der Ressourcen und des Risikomanagements und gewährleistet einen systematischen Ansatz bei der Umsetzung. Die folgenden grundlegenden Aspekte sollten zuerst beachtet werden:

  1. Alles beginnt mit einem Ziel. Ein Beispiel: Um den Diebstahl von Anmeldedaten privilegierter Entitäten zu erschweren, werden wir diese identifizieren, kategorisieren und durch Segmentierung schützen.
  2. Wenn die Aufmerksamkeit des höheren Managements noch fehlt, sollte jetzt damit begonnen werden, die Ziele des Credential Tiering vorzustellen, um die volle Unterstützung des Managements zu erhalten. Dies ist von entscheidender Bedeutung, um den IT-Mitarbeitern die Bedeutung des Projekts zu verdeutlichen und den Mindset-Change zu Unterstützen.
  3. Gibt es mehrere Active Directory-Forests mit gegenseitigen Vertrauensstellungen? Wenn ja, müssen potenzielle Verletzungen der Security-Boundaries zwischen den Forests in Betracht gezogen werden. Dies könnte die Implementierung eines Admin Forest erforderlich machen oder die Auswahl eines bestehenden Forests für die Verwaltung, was als nicht optimale Lösung angesehen werden könnte. In diesem Artikel gehen wir von einem Szenario mit einem einzigen Forest und einer einzigen Domäne aus.
  4. Um Tier-0 effektiv zu schützen, muss es von den anderen Tiers isoliert werden, um jegliche Control-up- oder Exposure-down-Risiken zu vermeiden. Wenn eine vollständige Trennung aus irgendeinem Grund nicht möglich ist, sollte ermittelt werden, welche Komponenten nicht in Tier-0 überführt werden können, da diese Komponenten ein vorgelagertes Risiko für Tier-0 darstellen.
  5. Entscheiden Sie, ob Sie Privileged Access Workstations (PAW) für alle Tiers oder z.B. nur für Tier-0 einführen. Definieren Sie die High-Level-Anforderungen für PAWs, zum Beispiel Remote Access.
  6. Es sollte ein RACI-Matrix für die Implementierungsphase und die Zeit nach der Migration erstellt werden.
  7. Es sollte mit der Erstellung des Tiering-Konzepts begonnen werden. Das Konzept sollte die endgültige Architektur der Lösung enthalten. Die neue Lösung hat Auswirkungen auf die bestehenden Active Directory Disaster Recovery (DR) und Incident Response (IR) Konzepte. Daher müssen sowohl das DR- als auch das IR-Konzept angepasst werden.
  8. Es sollte ein Zeitplan erstellt werden und genügend interne Ressourcen für das Projekt bereitgestellt werden. Es ist wichtig, dass ein interner Active Directory Engineer mindestens 80% seiner Zeit für die Implementierung aufwendet, da das Projekt über die Implementierung einer rein technischen Lösung hinausgeht und ein Umdenken erfordert, um Tiering-Verletzungen zu verstehen, anzugehen und dauerhaft zu beseitigen. Das ganze Unterfangen wäre umsonst, wenn sich die Mitarbeiter anschliessend nicht an die Regeln halten würden, wie das Active Directory in Übereinstimmung mit den definierten Tiering-Regeln zu verwalten ist.

Die genannten Aspekte könnten zu umfangreichen Diskussionen führen, bei denen einige Personen möglicherweise das gesamte Projekt in Frage stellen. Dies ist jedoch die erste Phase eines Bewusstseinswandels, den die Mitarbeiter durchlaufen werden. Wir empfehlen, die Herausforderungen zunächst in einem breiteren, vom Unternehmen losgelösten Kontext zu erläutern und insbesondere eine direkte Wahrscheinlichkeitsbewertung zu vermeiden. Die Problematik von komplexen Aussagen wie Wenn wir x nicht durchführen, haben wir Anzahl y direkte oder indirekte Angriffswege nach z lässt sich durch eine anschaulichere Darstellung deutlicher machen. Ein reales Szenario könnte beispielsweise zeigen, wie bestimmte Benutzer über ihr tägliches Benutzerkonto auf den Passwort-Vault eines Unternehmens zugreifen, in dem privilegierte Anmeldedaten von Active Directory enthalten sind. Das tägliche Benutzerkonto wird zusammen mit jeder Entität, die Administratorrechte für den Vault besitzt, zu einem indirekten Domain-Admin gemacht. Dadurch besteht das Risiko, dass Privilegien von einem beliebigen Tier auf Tier-0 eskaliert werden können. Sobald die grundlegenden Herausforderungen verstanden sind, kann die Diskussion auf die Unternehmensperspektive übergehen, um nuancierte Gespräche zu fördern. Der Fokus sollte konsequent auf der Trennung von administrativem Zugriff auf das Active Directory liegen, welches in vielen Unternehmen zu den wichtigsten Diensten gehört. Weitere Beispiele hierfür finden sich im ersten Teil Credential Tiering: The Value of Containment Part 1.

Alles beginnt mit Tier-0

Ein Haus braucht ein starkes Fundament, genau wie Tiering. Wenn Tier-0 kompromittiert wird, erhält der Angreifer die Kontrolle über alles, was von Active Directory kontrolliert wird. Aus diesem Grund sollte eine robuste Tier-0 an erster Stelle stehen. Die folgenden übergeordneten Implementierungsschritte können als Leitfaden dienen:

Von hier an beginnt die Uhr zu ticken. Die folgenden Schritte sollten zeitnah durchgeführt werden, um mögliche Manipulationen durch noch nicht überführte Tier-0-Entitäten während der Umstellung zu verhindern.

Identifizieren des Unbekannten

Die Identifizierung von Tier-0-Entitäten ist einer der ersten Schritte bei der Umsetzung von Tier-0, um die Auswirkungen von nicht segregierten Tier-0-Entitäten aufzuzeigen und den Übergang zu Tier-0 zu unterstützen. Um Tier-0-Entitäten schnell und effektiv zu identifizieren kann die Graph Theory verwenden werden. Gewisse Tools, welche die Graph Theory verwenden, haben bereits die nötige Logik implementiert und helfen bei einem Assessment von Abhängigkeitsbasierten Lösung wie Active Directory enorm. Das bekannteste Tool ist BloodHound von der Firma SpecterOps sowie Adalanche von Lars Karlslund. Der nachfolgende Ansatz kann für A1, A2, A3, A7, B2 und B10 verwendet werden.

BloodHound FOSS oder BloodHound CE vorbereiten

CREATE USER bloodhoundce SET PASSWORD 'bloodhoundce' CHANGE NOT REQUIRED SET STATUS Active SET HOME DATABASE bloodhoundce;
GRANT ROLE admin TO bloodhoundce

Neo4j Desktop Setup

SharpHound ausführen

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c DCOnly
SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c ComputerOnly

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c Session --Loop --Loopduration 04:00:00

Importieren der gesammelten Daten in BloodHound

Daten nach BloodHound importieren

Tier-0 Entitäten markieren

// Reset highvalue property
Match (u)
SET u.highvalue=false;

// Assign three new properties (Tiering) to all nodes
MATCH (u)
SET u.tier0 = false,
    u.tier1 = false,
    u.tier2 = false;

// Set the Tier-0 property to true for well known Tier-0 objects
UNWIND ["500","502","512","516","518","519","520","526","527","544","548","549","550","551","555","557","562","569","580"] as TierZeroRid MATCH (u) where u.objectid ENDS WITH "-"+TierZeroRid Set u.tier0=true;

// Find all domain objects and set the tier0 property
MATCH (u:Domain) SET u.tier0=true;

//Find all objects that allow unconstrained delegation and set the tier0 property
MATCH (u{unconstraineddelegation:true}) Set u.tier0=true;

//Find all objects that can directly or indirectly manipulate objects that have the property tier0 set to true
Match p=allshortestpaths((u)-[r:MemberOf|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GPLink|AddAllowedToAct|AllowedToAct|SQLAdmin|ReadGMSAPassword|HasSIDHistory|SyncLAPSPassword|AddSelf|WriteSPN|AddKeyCredentialLink|DCSync*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//Identify all entities with remote access to Tier-0 assets. These entities matter because they could become indirect Tier-0 administrators by escalating privileges on the target. For example, if a user can RDP to a client where a Tier-0 administrator is active, it might lead to compromising the Tier-0 accounts.
Match p2=allshortestpaths((u)-[r2:HasSession|CanRDP|CanPSRemote|ExecuteDCOM*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//OPTIONAL: Set all Tier-0 marked nodes as highvalue to have a better visibility in the BloodHound GUI (All Tier-0 objects will receive a diamond icon in BloodHound)
MATCH (u{tier0:true})
SET u.highvalue = true;

Kennzeichnung von Tier-0-Entitäten

Externe Tier-0-Dienste finden und kennzeichnen

Alle Tier-0-Entitäten, die direkt über Active Directory verwaltet werden, sollten nun automatisch identifiziert worden sein. Was fehlt, sind Anwendungen oder Dienste, die Tier-0-Objekte indirekt verwalten können, deren Zugriffsverwaltung aber von der externen Anwendung übernommen wird. Zum Beispiel Lösungen wie Backup (NetBackup, ARCserve, Veeam), Virtualisierung (ESX, Hyper-V), Überwachung (SCOM, Ivanti), Systemverwaltungssysteme (SCCM, Ivanti), Schwachstellen-Scanner (Nessus), AV (McAfee, Symantec, Defender), EDR (MDE, Tanium, CrowdStrike, SentinelOne), IAM (One identity, Sailpoint, NetIQ), SIEM (Splunk, Microsoft Sentinel, Qradar) usw. Diese Dienste verwenden häufig einen Agenten auf den Endpunkten oder Dienstkonten und verfügen über eine eigene Implementierung der rollenbasierten Zugriffskontrolle (RBAC). Um herauszufinden, wer Zugriff auf was hat, müssen daher zunächst die auf Tier-0-Systemen ausgeführten Dienste ermittelt und dann der Applikationsbesitzer der Lösung befragt werden. Darüber hinaus können Systemverwaltungstools oder Schwachstellen-Scanner bei der Identifizierung aktiver Dienste und Prozesse auf einem Tier-0-System helfen. Andernfalls kann auch die Ausführung eines einfachen PowerShell-Skripts auf einem identifizierten Tier-0-System helfen, mögliche Tier-0-relevante Dienste oder Prozesse zu erkennen:

# Get all running services and processes
$RunningServices = Get-Service | Select-Object @{Name="Type"; Expression={"Service"}}, Name, DisplayName, Status
$RunningProcesses = Get-Process | Select-Object @{Name="Type"; Expression={"Process"}}, Name, Id
# Combine and output to grid view
$RunningServices + $RunningProcesses | Out-GridView -Title "Running Services and Processes"

Nach der Identifizierung von Diensten oder Prozessen, die auf Tier-0-Servern laufen, sollte der Applikationsbesitzer in der Lage sein, die notwendigen Informationen darüber bereitzustellen, welche Benutzer über administrative Berechtigungen verfügen. Häufig werden in der Anwendung selbst AD-Gruppen oder AD-Benutzer verwendet. Die identifizierten AD-Objekte sollten als Tier-0 gekennzeichnet werden. Dazu kann die folgende Cypher-Query verwenden werden, um nach einem bestimmten samaccountname zu suchen und das Tier-0-Flag zu setzen:

// Example to set the tier0 and highvalue flag on the node with the samaccountname grp-TenableAdmin
MATCH (u) where toLower(u.samaccountname) = toLower("grp-TenableAdmin") Set u.tier0=true, u.highvalue = true

Neben der Kontaktaufnahme mit dem Applikationsbesitzer von Tier-0-Anwendungen ist es manchmal auch hilfreich, die Neo4j-Datenbank nach bekannten Diensten zu durchsuchen. Die folgende Abfrage kann dafür verwendet werden:

// Modify the following keywords with service terms to suit your specific environment
UNWIND ["nessus", "tenable", "sccm", "scom", "ivanti", "esx", "vmware", "mcafee", "symantec", "tanium", "splunk", "qradar", "netbackup", "arcserve", "veeam", "crowdstrike", "sentinelone", "sailpoint", "netiq"] AS word MATCH (n) WHERE toLower(n.name) CONTAINS toLower(word) OR 
toLower(n.description) CONTAINS toLower(word) OR 
any(x IN n.serviceprincipalnames WHERE toLower(x) CONTAINS toLower(word)) OR 
toLower(n.distinguishedname) CONTAINS toLower(word) 
RETURN word as keyword, LABELS(n)[1] as type, n.name, n.description, n.distinguishedname 
ORDER BY type

Suche nach möglichen Tier-0-Diensten in der Neo4j-Datenbank

Erstellung einer Liste der identifizierten Tier-0-Entitäten

Nach dem befolgen der oben beschriebenen Schritte sollten die meisten Tier-0-Entitäten identifiziert worden sein. Oftmals wird zur weiteren Planung das sehr “beliebte” Tool Excel verwendet. Über den Neo4j Browser kann eine csv-Datei generiert werden. Wenn der Datensatz zu gross sein sollte, kann der folgende Cypher-Query verwendet werden:

// Create a csv file with all Tier-0 entities
// Enable apoc.export.file.enabled=true in the neo4j.conf
// Will be saved to: C:\neo4j\Database\relate-data\dbmss\dbms-guid\import

CALL apoc.export.csv.query("Match (u) where u.tier0=true return distinct LABELS(u)[0] as type, u.name, u.enabled,u.description,u.objectid, u.distinguishedname order by type", 'all-tier0-entities.csv', {quotes: true, delimiter: ','});

Evaluierung und Fortschrittskontrolle

Während des Evaluierungsprozesses können unnötige Tier-0-Entitäten bereits entfernt werden. Entitäten, die neu erstellt oder migriert werden müssen, können entsprechend dem Implementierungszeitplans gekennzeichnet werden. Um Verbesserungen vor, während und nach der Einführung von Tier-0 zu verfolgen, kann das folgende Dashboard nützlich sein:

Messung, wie viele Entitäten einen Pfad zu Tier 0 haben

Die Abbildung zeigt, wie viele Entitäten eine direkte oder indirekte Verbindung zur Domäne Admin Gruppe oder anderen Tier-0-Entitäten haben. Der Prozentsatz muss je nach Grösse der Organisation angepasst werden. Die in der Demo dargestellte Umgebung hat insgesamt 2489 aktive Benutzerkonten. Daher sollte das Ziel für die Tier-0-Konten etwa 0,4 % bis 0,5 % betragen, je nach Grösse des Active Directory-Teams und der für die Tier-0-Trennung erforderlichen Dienstkonten.

Weiter unten im Dashboard wurden die Graph-Algorithmen der Closeness-Centrality und Degree-Centrality verwendet, um potenziell privilegierte Entitäten anzuzeigen.

Identifizierung privilegierter Entitäten mit Hilfe von Graph-Algorithmen

Der Degree-Centrality Algorithmus kann helfen, beliebte Knoten in einer Graph-Datenbank zu bestimmen. Der Algorithmus misst die Anzahl der eingehenden und ausgehenden Edges eines Nodes. Wenn Nodes eine hohe Anzahl von Edges, insbesondere von ausgehenden Edges, aufweisen, kann der Node bzw. die AD-Entität hoch privilegiert sein. Im Gegensatz dazu misst der Closeness-Centrality Algorithmus die durchschnittliche Entfernung eines Nodes zu allen anderen Nodes und erstellt eine Liste von Nodes, die Informationen effizient durch einen Graphen verbreiten können. Daher haben Nodes mit einem hohen Closeness-Wert die kürzesten Entfernungen zu allen anderen Knoten, was ein Hinweis darauf sein kann, dass eine Entität privilegiert sein kann. Weitere Informationen zu den beiden Algorithmen können unter der offiziellen Neo4j-Webseite oder in dem Papier Start thinking in graphs: using graphs to address critical attack paths in a Microsoft cloud tenant gefunden werden.

Um das obige Dashboard zu verwenden, muss die NeoDash-Anwendung installiert und das Dashboard, welches unter GitHub zu finden ist, importiert werden. NeoDash kann über die Neo4j Desktop-Anwendung aus der graph app gallery oder direkt von GitHub heruntergeladen werden. NeoDash funktioniert auch mit der Neo4j Community Edition.

Nächste Schritte

Tier-0 kann in der Regel ausnahmslos und ohne Ausfallzeiten eingeführt werden. Sie dauert, je nach technischem Wissen der Mitarbeiter, 6-12 Monate (Ausgenommen politische Debatten). Die Umsetzung von Tier-1 ist schwieriger und kann viel Zeit in Anspruch nehmen. Vielleicht kann nicht alles vollständig getrennt werden, aber wichtig ist die Priorisierung von privilegierten Tier-1-Administratoren und geschäftskritischen Anwendungen. Sie müssen von weniger wichtigen Tier-1-Ressourcen sowie Tier-2 getrennt und geschützt werden. Ein anderer Ansatz besteht darin, eine weiteres Tier hinzuzufügen. Das heisst, Tier-1 ist nur für IT- und geschäftskritische Lösungen gedacht. Tier-2 ist für die weniger kritischen Serveranwendungen, und Tier-3 ist für Client-Administratoren.

Ein Thema, welches in diesem Artikel nicht im Detail angesprochen wurde, aber für die Implementierung von Tiering unerlässlich ist, ist die Härtung der Systeme sowie die Zugriffsrichtlinien. Die Härtung sollte entweder den CIS- oder den Microsoft-Richtlinien folgen. Mein Kollege Michael Schneider hat ein Tool namens HardeningKitty geschrieben, mit welchem die Härtungsrichtlinien überprüft werden können. Noch wichtiger sind die Zugriffsrichtlinien, die den Tiering Zugriff erlauben oder verweigern. Der bevorzugte Weg ist die Verwendung von Authentication Policies and Authentication Policy Silos in Kombination mit Authentication Mechanism Assurance (AMA). Es reicht aber auch, nur mit SmarCards und Group Policies zu starten.

Fazit

Die Umsetzung von Tiering ist kein einfaches Unterfangen. Der Grund dafür liegt nicht primär in der technischen Schwierigkeit einer solchen Implementierung, sondern meist in der bestehenden Routine, wie ein Active Directory heute noch betrieben wird. Diese Routine zu ändern und Transparenz darüber zu schaffen, welche AD Objekte nun privilegiert sind und diese effektiv zu schützen, stellt für Organisationen immer noch eine Herausforderung dar. Tiering ist kein Tool, das man installieren kann, es ist eine klar definierte Art und Weise, wie ein Active Directory sicherer betrieben werden soll, es definiert einen Zustand anhand eines Regelwerks, das es einzuhalten gilt. Besitzt ein Active Directory kein Regelwerk welches die privilegierten Entitäten restriktiv schützt, ist das Active Directory der Gefahr der Komprimierung ausgesetzt. Vor allem die indirekten Tier-0 Berechtigungen wachsen in grösseren Unternehmen ohne Tiering ins Unermessliche, da immer mehr Tools angeschafft werden, die meist alle Server oder Clients und somit auch die Active Directory Domain Controller bzw. deren Administratoren betreffen. Die beiden Artikel Part-1 und Part-2 beschreiben die Herangehensweise an die Umsetzung von Tiering mit theoretischen und auch praktischen Beispielen um mit einer Tiering Umsetzung zu beginnen. Der Schwerpunkt beider Artikel lag hauptsächlich auf Active Directory, aber alle Identity-Provider Lösungen haben die gleichen Herausforderungen, so dass der vorgestellte Ansatz auch für andere Lösungen wie Microsoft Entra ID, Google Cloud Identity und AWS Identity verwendet werden kann, um privilegierte Entitäten effektiv schützen zu können.

Über den Autor

Marius Elmiger

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

Tags

Active Directory AD Artikel Assessment AWS Backup Beispiel Bewusstsein Block Browser CIS Cloud Dashboard Data Science Daten Excel Firewall Führung GitHub Google Hardening HardeningKitty Herausforderung Identity Michael Schneider Microsoft Nessus Password Passwort Policy Powershell Projekt Risiko Scan Science Sicherheit Springer Standard Tool Trust Vertrauen Virtualisierung VMware Webseite Windows Windows 10 Word

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×

Sie wollen mehr?

Weitere Artikel im Archiv

Microsoft Cloud Access Tokens

Microsoft Cloud Access Tokens

Marius Elmiger

Fremde Workloadidentitäten

Fremde Workloadidentitäten

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger

Hardware-Keylogger

Hardware-Keylogger

Marius Elmiger

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv