ESAE – Enhanced Security Administrative Environment

Der ESAE Forest Design sieht wie folgt aus.

Mit den entsprechenden Komponenten lauten wie folgt:

Just-In-Time Administration

JIT ist ein Teil der ESAE Initiative und wurde im Windows Server 2016 vorgestellt. Es erlaubt, System Administratoren über einen zeitlich limitierten Zeitraum Benutzerrechte auf Ressourcen zu geben. Zusätzlich zu dem Feature Just-Enough-Administration (JEA), welches z.B. einschränken kann, welche vordefinierten Powershell cmdlets, parameter oder Module in der Powershell Session ausgefürt werden darf. Das Just In Time (JIT) hat zwei Ziele:

1. Minimierung des Zeitraumes, indem Benutzer länger als Notwendig erhöhte Privilegien besitzen
2. Vermeiden von permanenten Zuweisungen von erhöhten Rechten

A trusted forest / Shadow Principals and PIM Trust

Shadow Principals wurden im Windows Server 2016 neu eingeführt und werden im Bastion Forest erstellt. Shadow Principals spiegeln die Objekte in den Produktionsforest (Domain Admin Gruppe und Benutzer der IT Abteilung / IT User). Administrativer Zugriff zum Produktionsforest wird im Bastionsforrest verwaltet.

Dies reduziert in erheblichen Ausmaß pass-the-hash, pass-the-ticket, Kerberos Kompromitierungen, phising und viele mehr. Dieser Bastion Forest sollte von Anfang an aufgebaut werden, da eine sichere Authentifizierung sichergestellt sein muss. Ein Trust hat über PIM (Privileged Identity Management) zu erfolgen. Der PIM Trust ist ein One-Way Cross Forest Trust und etabliert eine Verbindung zwischen der produktiven Domäne hin zur Bastion Domäne. Man mus sicherstellen, dass die Namensauflösung zwischen diesen Domänen funktioniert.

Um ESAE vollständig zu implementieren, muss der Microsoft Identity Manager (MIM) eingesetzt werden. MIM wird dazu verwendet, um Workflows zu implementieren, damit Benutzer temporär priviligierten Zugriff in den Produktionsforest zu bekommen. Wenn man eine eigene Workflow Software hat, so kann man darauf verzichten.

Admin-Workstation

Eine der weiteren zentralen Komponente ist die Workstation, von der aus die Umgebung administriert werden soll. Wir klären zuerst einmal die Notwendigkeit des Schützen des privilegierten Zugriffes, In den meisten Unternehmen ist die Sicherheit der meisten Geschäftsressourcen von der Integrität der priviligierten Konten abhängig. Wir werden in der Schulung enstprechend Methoden des Microsoft Leitfadens anwenden, um eine möglichst geringe Angriffsfläche zu bieten. Dazu durchlaufen wir die einzelnen Hardening Prozesse und bieten Ihnen ein Referenzmodell an. Dazu werden wir im ersten Schritt ein separates Administratorkonto und Adminsitrator Workstations für Administrative Aufgaben einführern. Dies hilft zum einen schon mal gegen typische Internetrisiken (Phishingangriffe, Surfen im Web). Dies folgt strikt den Schritten des PAW Unterprogrammes. Des Weiteren werden mittels des LAPS eindeutige locale Administratorkennwörter für Server eingerichtet. Wichtig ist hierbei ebenso zu verstehen, dass das Konzept der Admin-Workstations ständig weiterentwickelt werden muss, da auch die Angriffsszenarien ständig weiterentwickelt werden.

Weitere Themenblöcke werden in diesem Zuge folgende Technologien sein.

LAPS

Im Rahmen der Schulung werden wir uns ebenfalls dem Thema Laps (Local Administrator Password Solution) kümmern. Laps bietet eine zentrale

Laps baut auf folgende Komponenten auf:

• Agent – Group Policy Client Side Extension (CSE) via MSI installiert
  • Event Logging
  • Zufallsgenerator für Passwörter
• Powershellmodule
• Active Directory – Zentralisierte Verwaltung

Die zentrale Grundlagen von Laps bilden die GPO Client side Extension (CSE) mit

• Überprüft, ob das Kennwort des lokalen Administratorkontos abgelaufen ist oder nicht
• Erzeugt das neue Passwort, wenn das alte Passwort abgelaufen ist oder vor dem Ablauf geändert werden muss
• Ändert das Passwort des Administratorkontos
• Gibt das Kennwort an das Kennwort Active Directory an und speichert es in einem vertraulichen Attribut mit dem Computerkonto in AD
• Meldet die nächste Ablaufzeit für Active Directory und speichert sie in einem vertraulichen Attribut mit Computerkonto in AD
• Passwort kann dann von AD von Benutzern gelesen werden, die dazu berechtigt sind
• Das Passwort kann von berechtigten Benutzern geändert werden

Monitoring SCOM

Im Rahmen dieser Schulung werden wir uns innerhalb kürzester Zeit den System Center Operations Manager anschauen. Hierbei werden wir den SCOM schnellstmöglich (per Skript) installieren und dann werden wir uns den besonerheiten des Security Monitorings widmen. Hierbei werden wir uns auf die Discoveries, den Regeln (z.B. App Locker Regeln, Domain Admin, Enterprise Admin, Schema Admin Gruppenänderungen uvm), den Unit Monitoren (z.B. UseLogonCredential reg key für Wdigest attacken, Fehlerhafte RDP Anmeldungen uvm) stürzen. Daneben gibt es ein entsprechende Event Collection, um den Reportinganforderungen (z.B. Security Log gelöscht EventID 1102, Powersploit use etc.) gerecht zu werden. Des Weiteren kümmern wir uns um das sogenannte Threat Hunting und die weitere Absicherung des System Center Operations Mangagers gegen lokale Angriffsszenarien.

AppLocker wurde in Windows 7 und Windows Server 2008 R2 eingeführt, welches beim Security hardening gerne hergenommen werden kann. Mittels AppLocker kann man steuern, welcher Benutzer oder Gruppe einzeone Applikationen ausführen kann. Applocker ermöglicht die Erstellung von Whitelists und Blacklists. Auch eine Kombination meherer Regeln ist möglich. Mittels Powershell Import-module applocker lässt sich somit administrieren. Über eine Liste der verfügbaren Commandlets können Sie sich mittels get-command *applocker* verschaffen. Für eine weitergehende Analyse können Sie eine Drittherstellersoftware herunterladen “Group Policy Help”. Mittels des Befehls get-sdmgphealth –computer können Sie Probleme bei Applicker-Regeln aufgrund falsch angewendeter Gruppenrichtlinien ausschließen.

In den bisherigen Windows Systemen wurden Passwörter in dem Local Security Authority (LSA) gespeichert. Somit waren diese im Hauptspeicher verfügbar. Mittels des Windows Defender Credential Guard eingeschaltet, wird dieser LSA Prozess nicht mehr direkt angesprochen, sondern nur noch mittels des “Isolated LSA Prozess” zugelassen. Wenn der Windows Defender Credential Guard eingeschaltet wird, wird eine Anmeldung über NTLMv1, MS-CHAPv2, Digest und CredSSP nicht mehr möglich. Somit funktioniert ein SSO auch nicht mehr mit diesen Verfahren. Ebenso wird die sogenannte “unconstrained Kerberos delegation or DES encrpytion” unterdrückt.

Aufgrund der Tatsache, dass der “Security Compliance Manager” von Microsoft abgekündigt wurde, werden wir uns dem “Security Configuration Toolkit” zuwenden. Das Security Configuration Toolkit besteht aus drei Hauptkomonenten:

• Policy-Analyzer-Tool
• LGPO-Tool
• Diverse Security Baselines

Zum patchen der ESAE Umgebung werden wir einen WSUS Server verwenden. Hierfür werden wir automatisiert einen WSUS Server bereitstellen, welcher nach Best Practices entsprechend automatisiert konfiguriert wird.

Ebenso basieren wir im Rahmen dieser Schulung auf einer Online Issuing CA mit einer Offline Root CA.