App-Control-Richtlinien pruefen: WDAC jenseits eines GPO-Markers

Was bedeutet die Verifikation von App-Control-Richtlinien?

Die Verifikation von App-Control-Richtlinien stellt fest, welche App Control for Business-Richtlinien auf einem Windows-Gerät vorhanden sind, wie sie dorthin gelangt sind und ob ihr beobachtetes Verhalten den genehmigten Anwendungsregeln entspricht. Ein Gruppenrichtlinienobjekt (GPO) mit einem Bereitstellungspfad beschreibt die beabsichtigte Konfiguration. Es belegt nicht, dass das Zielgerät die Binärdatei erhalten, die vorgesehene Version geladen oder sie durchgesetzt hat.

Für ein Active Directory-Team, das einen Befund zur WDAC-Bereitstellung untersucht, ist ein gerätespezifischer Nachweis das sinnvolle Ergebnis. Identifizieren Sie die Richtlinie und den Verantwortlichen für ihre Verteilung, testen Sie erforderliche Arbeitsabläufe im Überwachungsmodus, prüfen Sie vorgeschlagene Regeln und genehmigen Sie die Durchsetzung mit einem Wiederherstellungsweg. Halten Sie nicht erreichbare Geräte und fehlende Messungen als offene Fälle sichtbar.

Dieser Leitfaden verwendet Microsoft Learn-Dokumentation, die am 4. Oktober 2026 geprüft wurde, sowie die unten bezeichnete Collector-Implementierung. Die Befehle sind dokumentierte Beispiele für einen autorisierten Windows-Administrator; sie wurden für diesen Artikel nicht in einer Windows-Umgebung ausgeführt. Es werden weder ein erfolgreicher Rollout noch eine vollständige Endpunktabdeckung, eine CVE-Exposition oder ANSSI-Konformität behauptet.

Unser Leitfaden zur HVCI-Speicherintegrität erklärt die Isolation der Kernel-Codeintegrität im Arbeitsspeicher und die Treiberkompatibilität. Dieses Verfahren prüft Richtlinien zur Anwendungsautorisierung, ihr Format und ihre Ereignisse. Erfassen Sie gegebenenfalls beide Schutzmechanismen mit getrennten Nachweisen.

Funktionsweise: Richtlinienformat und Verteilung müssen übereinstimmen

Microsofts Verfahren zur GPO-Bereitstellung unterstützt ausschließlich das Single-Policy-Format. Die Einstellung liegt unter Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. Die aktivierte Einstellung benennt einen lokalen oder UNC-Bereitstellungspfad; eine Freigabe muss für die Computerkonten zugänglich sein. Das Verfahren endet mit einem Neustart des Testcomputers.

Dieselbe Seite weist Administratoren, die eine neue signierte Basisrichtlinie bei aktivierter Speicherintegrität bereitstellen, an, die Skriptbereitstellung zu verwenden und sie durch einen Neustart zu aktivieren. Ersetzen Sie diese Anweisung nicht durch eine Aktualisierung im laufenden Betrieb, nur weil ein Verwaltungswerkzeug diese anbietet. Microsofts Skriptverfahren benennt den betroffenen Windows 11-Fall vor 24H2 und das erforderliche Kopieren an System- und EFI-Speicherorte mit anschließendem Neustart. Prüfen Sie den Build des Zielgeräts und das zugehörige Verfahren, bevor Sie einen Aktivierungsmechanismus wählen.

Microsofts Bereitstellungsübersicht unterscheidet XML mit einer PolicyID für das Multiple-Policy-Format vom Single-Policy-Fall. Sie beschreibt die Konvertierung in eine Binärdatei und die Bereitstellung über MDM, Configuration Manager, Skripte oder Gruppenrichtlinien. Ein fehlender GPO-Marker kann diese anderen Verteilungswege nicht ausschließen.

Erstellen Sie vor jeder Änderung einen Datensatz für jede Pilotgruppe:

Diese Felder bilden einen vorgeschlagenen Untersuchungsdatensatz, keine Messungen aus einer Kundenumgebung. Klären Sie fehlende Zuständigkeiten, bevor Sie Änderungen veranlassen: Ein Administrator sollte erklären können, welche Quelle die nächste Version verteilt und welcher Betreiber sie zurückziehen kann.

Erkennung: Zielgerät inventarisieren und Ereignisse korrelieren

Schritt 1: Richtlinien auf dem Pilotgerät identifizieren

Die technische CiTool-Referenz dokumentiert --list-policies mit dem Alias -lp als Auflistung aktiver und inaktiver Richtlinien. CiTool ist ab Windows 11 22H2 und Windows Server 2025 enthalten. Bewahren Sie auf einem unterstützten Zielgerät die vollständige Ausgabe auf:

CiTool --list-policies

Die dokumentierte Ausgabe enthält Policy ID, Base Policy ID, Anzeigename, Version, Signaturstatus, Dateivorhandensein und Aktivierungsstatus. Vergleichen Sie Identitäten und Versionen mit dem genehmigten Artefakt. Die Referenz definiert Is Currently Enforced als Angabe, ob die Richtliniendatei aktiv ist; verwenden Sie diese Bezeichnung allein nicht, um zu entscheiden, ob ihre Regeloptionen im Überwachungs- oder Durchsetzungsmodus stehen.

Für Systeme außerhalb der Verfügbarkeit dieses Werkzeugs verwenden Sie das entsprechende betriebssystemspezifische Bereitstellungsverfahren und die aufbewahrten Richtlinienartefakte. Ein nicht verfügbarer Befehl ist eine Einschränkung der Inventarisierung, kein Beleg für das Fehlen von App Control. Unterscheiden Sie eine fehlgeschlagene Erfassung von einer erfolgreichen Inventarisierung, bei der die erwartete Richtlinie nicht vorhanden ist.

Schritt 2: Die richtigen Protokolle lesen

Prüfen Sie in der Ereignisanzeige Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational sowie Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. Microsofts Ereignisreferenz dokumentiert diese Signale:

Das Protokoll MSI and Script ist auf Windows Server Core nicht verfügbar. App Control protokolliert außerdem gewöhnlich nicht jede erlaubte Binärdatei. Daher sind stille Protokolle weder ein vollständiges Ausführungsinventar noch ein Beleg dafür, dass alle Anwendungen autorisiert sind.

Bewahren Sie Ereignisdetails mit Gerät, Zeitpunkt, Richtlinienidentität, soweit angegeben, beobachteten Optionen und ausgeübtem Arbeitsablauf auf. Vergleichen Sie die Beobachtung der geladenen Richtlinie mit der vorgesehenen Identität, Version und Betriebsart. Untersuchen Sie unerwartete IDs und erklären Sie jede Versionsänderung, bevor Sie spätere Aktivitäten dem Rollout zuschreiben.

Schritt 3: Erforderliche Arbeiten im Überwachungsmodus ausführen

Führen Sie autorisierte Installations-, Start-, Aktualisierungs- und Verwaltungsabläufe im Piloten aus. Bitten Sie Anwendungsverantwortliche, Abhängigkeiten und erwartete Ergebnisse zu benennen. Dokumentieren Sie, was tatsächlich ausgeführt wurde; ein untätiges Gerät liefert wenig Kompatibilitätsnachweise. Bewahren Sie Erfassungslücken und Grenzen der Protokollaufbewahrung zusammen mit der Prüfung auf.

Unser Leitfaden zu Defender-ASR-Regeln per GPO vergleicht GUIDs von Verhaltensregeln, Aktionen und Ausnahmen mit der Endpunktkonfiguration. Hier betrifft die Prüfung die Identität und das Format von App-Control-Richtlinien sowie Entscheidungen über Binärdateien und Skripte. Eine Beobachtung der ASR-Konfiguration kann diese App-Control-Untersuchung nicht abschließen.

Abhilfe: Überwachungsnachweise vor der Durchsetzung prüfen (Remediation)

Schritt 1: Einen wiederherstellbaren Piloten genehmigen

Benennen Sie den Bereitstellungsverantwortlichen, den Genehmiger der Anwendungsregeln und den Wiederherstellungsverantwortlichen. Legen Sie fest, welche Geräte am Piloten teilnehmen, welche Arbeitsabläufe erfolgreich sein müssen und welche Fehler die Ausweitung stoppen. Fragen Sie ausdrücklich: Welches Format und welcher Verteilungsweg werden verwendet, werden neue signierte Basisrichtlinien mit Speicherintegrität kombiniert und wer genehmigt Ausnahmen und Rollback?

Microsoft empfiehlt in seiner Bereitstellungsübersicht Bereitstellungsringe und eine Bewertung im Überwachungsmodus vor der Durchsetzung. Wählen Sie die Methode anhand des oben beschriebenen Datensatzes zu Betriebssystem, Format und Signatur. Bewahren Sie die bisherigen Artefakte und ein getestetes Wiederherstellungshandbuch auf, bevor Sie den Kandidaten verteilen.

Schritt 2: Kandidaten erzeugen, dann jede Regel prüfen

Microsofts Arbeitsablauf für Überwachungsereignisse setzt eine bereits bereitgestellte Richtlinie im Überwachungsmodus voraus. Führen Sie den dort dokumentierten Befehl in einer PowerShell-Sitzung mit erhöhten Rechten aus, um aus Überwachungsereignissen Regelkandidaten zu erzeugen:

$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings

Dieses Beispiel erzeugt das Multiple-Policy-Format; es ist keine Binärdatei zur Bereitstellung über die Single-Policy-GPO-Einstellung. Prüfen Sie die erzeugte XML-Datei und die Warnungen. Behalten Sie nur Regeln für genehmigte Anwendungen, Binärdateien und Skripte bei und führen Sie sie anschließend mit der Basis zusammen oder verwenden Sie eine zulässige ergänzende Richtlinie. Für Dateien, die nicht mehr auf dem Datenträger liegen, erzeugt dieses Verfahren keine automatischen Regeln.

Führen Sie die erforderlichen Arbeitsabläufe erneut aus, nachdem die geprüfte Überwachungsrichtlinie bereitgestellt wurde. Lassen Sie unzulässige Aktivitäten weiterhin unzulässig; ein Überwachungsereignis ist keine Anweisung, seiner Quelle zu vertrauen. Untersuchen Sie unerklärte Ereignisse und offene Warnungen, bevor Sie fortfahren.

Schritt 3: Das Artefakt für die Durchsetzung vorbereiten

Microsofts Durchsetzungsverfahren geht von geprüften Überwachungsrichtlinien aus. Es kopiert die Überwachungs-XML in eine separate Durchsetzungsdatei und ändert optional die Richtlinienidentität für eine parallele Bereitstellung. Entscheiden Sie bewusst, ob Sie die vorhandene Richtlinie ersetzen oder eine neue Identität verwenden; die Beziehungen ergänzender Richtlinien müssen dieser Entscheidung folgen.

Wenn $EnforcedPolicyXML auf die vorbereitete Kopie verweist, lautet die dokumentierte Änderung der Betriebsart:

Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

Dasselbe Verfahren empfiehlt, die Optionen 9 und 10 für den ersten Durchsetzungsring in Betracht zu ziehen: eine Option vor dem Systemstart, die die Durchsetzung für eine einzige Startsitzung deaktiviert, und einen Rückfall in den Überwachungsmodus, wenn ein startkritischer Treiber blockiert wird. Konvertieren Sie die geprüfte XML-Datei in eine Binärdatei, wenden Sie den erforderlichen Signierungsprozess an und stellen Sie sie mit der gewählten unterstützten Methode bereit. Halten Sie die Artefaktidentität und die erwartete Betriebsart im Änderungsdatensatz fest.

Wiederholen Sie nach der Aktivierung die Inventarisierung, die Prüfung der geladenen Richtlinie und die Funktionstests. Prüfen Sie Durchsetzungsereignisse gegen die genehmigten Erwartungen. Gehen Sie erst zum nächsten Ring über, wenn benannte Prüfer die Nachweise, Ausnahmen und Wiederherstellungsbereitschaft akzeptieren; die GPO-Änderung selbst ist kein Abschlusskriterium.

Schritt 4: Rücknahme und Wiederherstellung testen

Microsofts Verfahren zum Entfernen von Richtlinien verlangt zunächst, den Verteilungsweg zu deaktivieren, damit die Richtlinie nicht erneut bereitgestellt wird. Stellen Sie für eine signierte Basis eine signierte Ersatzrichtlinie mit Option 6, derselben PolicyId, einer gleichen oder höheren Version und einem Abschnitt UpdatePolicySigners bereit. Signieren Sie sie mit einem Zertifikat, das im Abschnitt UpdatePolicySigners der ursprünglichen Richtlinie aufgeführt ist, und starten Sie vor dem Entfernen neu. Gehen Sie nicht davon aus, dass ein lokales Löschen eine signierte Basis sicher zurückzieht.

Führen Sie auf einem unterstützten System nach Erfüllung dieser Voraussetzungen das dokumentierte Entfernungsbeispiel in einem Befehlsfenster mit erhöhten Rechten aus:

CiTool.exe -rp "{PolicyId GUID}" -json

Ersetzen Sie den Platzhalter durch die genehmigte Richtlinien-ID. Neustartanforderungen variieren je nach Windows-Version und Richtliniensignatur; verwenden Sie das verlinkte Verfahren für das Zielgerät. Das Handbuch muss auch ein nicht startfähiges Gerät, autorisierten Firmwarezugriff und die Verfügbarkeit des Wiederherstellungsschlüssels abdecken. Testen Sie diesen Weg vor der Durchsetzung auf wiederherstellbarer Hardware.

Wie EtcSec dies erkennt

EtcSecs etc-collector enthält BP039_CCI_NOT_DEPLOYED. Beim geprüften Commit 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85 durchläuft dessen Detect() in bp039-cci-not-deployed.go jeden erfassten GPOPolicies-Eintrag und überspringt fehlende Richtlinien- oder Einstellungsobjekte. Jede nicht leere Zeichenfolge DeviceGuardConfigCIPolicyFilePath führt zur Rückgabe von nil, also keinem Befund. Andernfalls meldet es Schweregrad Low, Count 1, auch wenn keine Richtlinien erfasst wurden.

Dieser Zweig prüft einen einzigen Marker. Er validiert weder die referenzierte Datei noch ihr Binärformat, ihre Signatur, Version, ihren Zielbereich oder ihren Durchsetzungszustand. Ein positiver Wert in einer nicht zugehörigen GPO genügt, um den Befund zu unterdrücken; der Code berechnet nicht die resultierende Richtlinie für jedes Gerät. Count 1 ist die Anzahl von Befunden, keine Anzahl ungeschützter Computer.

Die geprüfte Datei registrypol_parser.go verlangt einen Schlüssel, der codeintegrity enthält, um ConfigCIPolicyFilePath zuzuordnen. Die tatsächliche GPO-Einstellung verwendet den Zweig DeviceGuard, sodass dieser Pfad den erwarteten Marker nicht befüllt. Unabhängig davon fügt CollectGPOPolicies in smb/client.go auch dann ein Richtlinienobjekt ein, wenn dessen Dateien nicht erfolgreich gelesen wurden. Ein Objekt in der Map ist daher kein Beleg für eine erfolgreiche Erfassung der Einstellungen.

Fügen Sie der Untersuchung das unabhängige Geräteinventar, genehmigte Richtlinienartefakte, relevante Ereignisse und Entscheidungen zur Regelprüfung bei. Klären Sie Erfassungsfehler ausdrücklich. Schließen Sie die operative Frage anhand dieser Nachweise und der vereinbarten Akzeptanzkriterien ab, statt eine GPO allein zu ändern, um eine Markerprüfung zum Schweigen zu bringen.