Device Guard - Windows Defender Application Control

Autor: Mark Heitrink - vom 19.09.2019 - Kategorie(n): Anleitungen

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: Windows 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 könnt ihr siesm Artikel entnehmen:
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels 
 
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!! ;-)

 

 

(klicken zum vergrössern)

Ihr findet dann im Eventlog die Einträge in der Ereignisanzeige unter : Anwendungs- und Dienstprotokolle \ Microsoft \ Windows \ Codeintegrity \ Operational (Microsoft-Windows-CodeIntegrity/Operational)
 
Das war zum ersten Start schon alles. Wenn das gut aussieht, dann tauscht das Audit gegen das Blockieren.
 
Update des Rulsets, wenn sich etwas ändert
Das System muss erneut gescannt werden, entweder komplett, weil ihr weitere Hardware mit Treibern integrieren möchtet oder nur ein spezieller Pfad, von dem ihr wisst, daß sich dort die neu installierte  Software oder deren Update mit allen Dateien befindet. Es ist derselbe Befehl wie bei der ersten Erstellung aber eventuell auf einen Pfad reduziert:
 
New-CIPolicy -FilePath WDDG-Policy-Update.xml -Level FilePublisher -Fallback Hash -UserPEs -ScanPath "C:\Programme\MyBrandneueSoftware"
 
... falls ich es nicht gesagt habe ... es dauert ...
 
Jetzt muss das erzeugte XML in das vorhandene XML integriert werden (Audit oder Block) und dann muss die Regel neu erstellt werden. Die erzeugte p7b ist dann wieder nur Audit oder Block. Ich erzeuge im Beispiel ein Ruleset basierend auf das Block-XML 
 
copy WDDG-Policy.p7b WDDG-Policy-Backup.p7b
copy WDDG-Policy.xml WDDG-Policy-Backup.xml
Merge-CIPolicy WDDG-Policy-Update.xml,WDDG-Policy.xml -OutputFilePath New-WDDG-Policy-Update.xml
ConvertFrom-CIPolicy -XmlFilePath New-WDDG-Policy.xml -BinaryFilePath WDDG-Policy.p7b

 
Ob ihr es glaubt oder nicht, aber auch das dauert wieder ... 
 
Eure erzeugtes Ruleset landet bei der Übernahme der GPO unter %systemroot%\system32\CodeIntegrity\SiPolicy.p7b
 
Wenn ihr Device Guard wieder loswerden wollt, dann ist das nicht so einfach. Es gibt ein Powershell Script von Microsoft, mit dem ihr Testen könnt, ob eure Hardware überhaupt tauglich ist Device Guard zu nutzen und auch, um es zu deaktivieren und zu entfernen.
 
Device Guard and Credential Guard hardware readiness tool
https://www.microsoft.com/en-us/download/details.aspx?id=53337

Doku und Anleitung:
https://github.com/MicrosoftDocs/windows-itpro-docs/blob/master/windows/security/identity-protection/credential-guard/credential-guard-manage.md

Wenn der Client kein nativ englisches OS ist, dann wirft das Script raus, das es ein "Unkown OS" ist. Danke Microsoft. Ihr Deppen ... Im Github Artikel nennen sie die Lösung, diese ist aber nicht in die Version 3.6 eingeflossen. Vielleicht kommt die Korrekt in eine der nächsten. Ebenfalls meldet das Script in der Powershell die Version 3.4 statt 3.6. Das ist auch nur ein Text, den man ändern kann.

Ich habe 3 verschiedene Systeme probiert, 2 mal Blech und einmal Virtuell und bei einem liess sie Device Guard nur durch Neuinstallation entfernen.