Device Guard - Microsoft Defender Application Control

Er wurde mit 1507 als Device Guard eingeführt, mit der 1607 hat sich technisch einiges geändert. Die Änderungen findet ihr in der Liste der Voraussetzungen.

Lasst euch nicht verwirren: Microsoft Defender Application Control ist ein eigenes Produkt, aber auch eine Technik, die als Hauptbegriff in Kombination mit dem Device Guard verwendet wird und auftaucht ... ich bin verwirrt :-)

Reduziert auf das Wesentliche, ist der Device Guard eine Whitelist von Anwendungen für ein spezifisches System. Daraus ergibt sich auch der Haupteinsatzzweck des Windows Defender Device Guard:

Er ist eine Lösung gedacht für eine statische Umgebung. Er ist eine Lösung für ein definiertes System mit klarer Anwendungsliste oder in einem speziellen Scenario. Es sollte wenig Änderungen in der Liste der Anwendungen geben. Im Idealfall nicht mal Änderungen in den Versionen.

Wir können ihn gebrauchen für Produktionsmaschinen, Kiosks, Präsentations Rechner aber auch Serve rmit fixer Rolle, Domänen Controller, FileServer etc. alles was man prima "Imagen" kann, da auch Treiber Teil der Whitelist sind.

ShortTrack:
Man scannt ein System und alle hinterlegten Anwendungen/Treiber etc und das erzeugte Ruleset ist die Whitelist für dieses System. Die Übergabe und Anwendung des Regelwerks erfolgt per Gruppenrichtlinie (wer hätte es gedacht :-)

Es funktioniert auch in der Workgroup! Es braucht kein AD. Virtuelle Hyper-V Systeme der Generation 2 können es auch.

Voraussetzungen:

• 64Bit (!) Windows 10 Enterprise (auch LTSC)
• UEFI native, kein Legacy BIOS aktiviert
• SecureBoot aktiviert
• Virtualisierungs Erweiterung VT / VTx / AMD V
• TPM Chip 

Was wir NICHT (mehr) brauchen:

• Windows Feature - Isolated User Mode, der Name hat sich auch mindestens einmal geändert, aber dieser Modus, den wir für den sicheren geschlossenen Prozess benötigen ist jetzt fester Bestandteil des Windows 10 Betriebssystems. Er muss nicht mehr extra als Feature aktiviert werden. Er ist schon da.
• Hyper-V, Das System funktioniert jetzt ohne den Hyper-V als Feature Installation er kann direkt integriert werden, was den Einsatz vor allen in virtuellen Hyper-V Systemen vereinfacht. Man muss keine Nested Hyper-V Konfiguration bauen.

Erstellung des Rulesets: Erklärung für den Level und Alternativen

New-CIPolicy -FilePath WDDG-Policy-Audit.xml -Level FilePublisher -Fallback Hash -UserPEs
ConvertFrom-CIPolicy -XmlFilePath WDDG-Policy-Audit.xml -BinaryFilePath WDDG-Policy-Audit.p7b

... das dauert ... das dauert wirklich lange ... ehrlich ... auch auf ordentlicher Hardware ... auch, wenn es nur das OS mit ein paar Anwendungen ist ...man kann dem Scan des Ordner C:\Windows\SXS ganz lage zuschauen ... rechnet mal mit 30 Minuten plus ...

Per Default steht das Ruleset auf "Audit". Hebt euch das auf! Macht eine Kopie davon, das kann man zwischendurch immer mal gut gebrauchen, wenn es zu Fehlern kommt, die man nicht so schnell lösen kann. Dann ist die Anwendung von einem Regelwerk, das nur protokolliert, statt blockiert sehr hilfreich.

Umschalten auf Blockieren geschieht durch das entfernen des Audit Modes:

copy WDDG-Policy-Audit.xml WDDG-Policy.xml
Set-RuleOption -FilePath WDDG-Policy.xml -Option 3 -Delete
ConvertFrom-CIPolicy -XmlFilePath WDDG-Policy.xml -BinaryFilePath WDDG-Policy.p7b

... das dauert … Es ist mehr als nur das löschen einer Zeile im XML. Habe ich gesagt, das es dauert? 5-10 Minuten ...

Ihr habt jetzt 2 Rulesets, eines das nur auditiert (WDDG-Policy-Audit.p7b) und eines das Blockiert (WDDG-Policy.p7b). Zum Test könnt ihr jetzt als erstes die WDDG-Policy-Audit.p7b anwenden und schauen, was passiert.

Jetzt nur noch schnell 2 Richtlinien aktivieren:
Computerkonfiguration\Administrative Vorlagen\System\Device Guard
"Windows Defender-Anwendungssteuerung bereitstellen"
den Pfad zur *.p7b angeben. Dieser kann lokal oder im Netzwerk liegen.

Computerkonfiguration\Administrative Vorlagen\System\Device Guard
Virtualisierungsbasierte Sicherheit aktivieren

• Plattformsicherheitsstufe auswählen:
  Sicherer Start (Sicherer Start mit DMA geht nicht in Hyper-V Gen2 System)
• Virtualisierungsbasierter Schutz der Codeintegrität:
  Ohne Sperre aktiviert (Mit UEFI Sperre aktviert, dann muss man lokal am Rechner sein, wenn man DGuard abschalten möchte und die Taste "F3" beim Bootvorgang drücken)
• UEFI Speicherattribute nicht aktiviert
• CredentialGuard Konfiguration
  Ohne Sperre aktiviert (oder siehe oben)
• Sichere Startkonfiguration
  Nicht konfiguriert (SecureBoot ist schon im UEFI angeschaltet worden, zudem konnten 2 Systeme, virtuell und Blech, nicht mehr starten, wenn es über die GPO zusätzlich gesetzt wurde
  -> Lösung Neuinstallation!! ;-)