Vérification des politiques App Control : WDAC au-delà du marqueur GPO

Qu’est-ce que la vérification des politiques App Control ?

La vérification des politiques App Control établit quelles politiques App Control for Business sont présentes sur un appareil Windows, comment elles y sont arrivées et si leur comportement observé correspond aux règles applicatives approuvées. Un objet de stratégie de groupe (GPO) contenant un chemin de déploiement décrit une intention de configuration. Il ne prouve pas que la cible a obtenu le binaire, chargé la version prévue ou appliqué la politique.

Pour une équipe Active Directory qui examine un constat relatif au déploiement de WDAC, le résultat utile est un dossier de preuves propre à chaque appareil. Identifiez la politique et le responsable de sa distribution, testez les processus requis en mode audit, examinez les règles proposées et approuvez l’application avec une procédure de récupération. Conservez les appareils injoignables et les mesures manquantes parmi les cas non résolus.

Ce guide utilise la documentation Microsoft Learn consultée le 4 octobre 2026 et l’implémentation du collecteur identifiée ci-dessous. Les commandes sont des exemples documentés destinés à un administrateur Windows autorisé ; elles n’ont pas été exécutées sur un parc Windows pour cet article. Aucun déploiement réussi, aucune couverture des appareils, aucune exposition à des CVE ni aucune conformité ANSSI ne sont revendiqués.

Notre guide de l’intégrité de la mémoire HVCI explique l’isolation en mémoire de l’intégrité du code noyau et la compatibilité des pilotes. Cette procédure vérifie les politiques d’autorisation des applications, leur format et leurs événements. Consignez les deux protections lorsque cela est pertinent, avec des preuves distinctes pour chacune.

Fonctionnement : le format de la politique doit correspondre à sa distribution

La procédure de déploiement par GPO de Microsoft prend en charge uniquement le format à politique unique. Son paramètre se trouve sous Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. Le paramètre activé indique un chemin de déploiement local ou UNC ; un partage doit être accessible aux comptes d’ordinateur. La procédure se termine par le redémarrage d’un ordinateur de test.

La même page demande aux administrateurs déployant une nouvelle politique de base signée avec l’intégrité de la mémoire activée d’utiliser un déploiement par script et de l’activer par un redémarrage. Ne remplacez pas cette instruction par une actualisation à chaud simplement parce qu’un outil d’administration la propose. La procédure par script de Microsoft identifie le cas concerné de Windows 11 antérieur à 24H2 et les copies requises aux emplacements système et EFI, suivies d’un redémarrage. Vérifiez la build cible et la procédure pertinente avant de choisir un mécanisme d’activation.

La vue d’ensemble du déploiement de Microsoft distingue le XML doté d’un PolicyID pour le format à politiques multiples du cas à politique unique. Elle décrit la conversion en binaire et le déploiement par MDM, Configuration Manager, scripts ou Group Policy. L’absence d’un marqueur GPO ne permet pas d’exclure ces autres méthodes de distribution.

Avant toute modification, créez un dossier pour chaque population pilote :

Ces champs constituent une proposition de dossier d’investigation, pas des mesures provenant d’un environnement client. Clarifiez les responsabilités manquantes avant d’émettre des changements : un administrateur doit pouvoir expliquer quelle source distribuera la version suivante et quel opérateur pourra la retirer.

Détection : inventorier la cible et corréler les événements

Étape 1 : identifier les politiques sur l’appareil pilote

La référence technique de CiTool documente --list-policies, avec l’alias -lp, comme listant les politiques actives ou inactives. CiTool est inclus à partir de Windows 11 22H2 et de Windows Server 2025. Sur une cible prise en charge, conservez la sortie complète :

CiTool --list-policies

La sortie documentée comprend Policy ID, Base Policy ID, le nom convivial, la version, l’état de signature, la présence du fichier et l’état d’activation. Comparez les identités et les versions avec l’artefact approuvé. La référence définit Is Currently Enforced comme indiquant si le fichier de politique est actif ; n’utilisez pas ce seul libellé pour déterminer si ses options de règles sont en mode Audit ou Enforcement.

Pour les systèmes où cet outil n’est pas disponible, utilisez la procédure de déploiement propre à l’OS et les artefacts de politique conservés. Une commande indisponible est une limite de l’inventaire, pas une preuve de l’absence d’App Control. Distinguez une collecte en échec d’un inventaire réussi qui ne contient pas la politique attendue.

Étape 2 : lire les journaux appropriés

Dans l’Observateur d’événements, examinez Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational et Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. La référence des événements de Microsoft documente les signaux suivants :

Le journal MSI and Script n’est pas disponible sur Windows Server Core. App Control ne journalise pas non plus habituellement chaque binaire autorisé. Des journaux silencieux ne constituent donc pas un inventaire complet de l’exécution ni une preuve que toutes les applications sont autorisées.

Conservez les détails des événements avec l’appareil, l’heure, l’identité de la politique lorsqu’elle est fournie, les options observées et le processus testé. Comparez l’observation de la politique chargée avec l’identité, la version et le mode prévus. Examinez les identifiants inattendus et expliquez tout changement de version avant d’attribuer une activité ultérieure au déploiement.

Étape 3 : tester les tâches requises en mode audit

Exécutez les processus autorisés d’installation, de démarrage, de mise à jour et d’administration sur le pilote. Demandez aux responsables applicatifs d’identifier les dépendances et les résultats attendus. Suivez ce qui a réellement été testé ; une machine inactive fournit peu de preuves de compatibilité. Conservez les lacunes de collecte et les limites de rétention des journaux avec l’examen.

Notre guide des règles Defender ASR via GPO compare les GUID, les actions et les exclusions des règles comportementales à la configuration des appareils. Ici, l’examen concerne l’identité et le format de la politique App Control ainsi que les décisions concernant les binaires et les scripts. Une observation de configuration ASR ne peut pas clore cette investigation App Control.

Remédiation : examiner les preuves d’audit avant l’application (Remediation)

Étape 1 : approuver un pilote récupérable

Désignez le responsable du déploiement, l’approbateur des règles applicatives et l’opérateur de récupération. Définissez les appareils qui entrent dans le pilote, les processus qui doivent réussir et les échecs qui arrêtent son extension. Posez explicitement les questions suivantes : quels format et méthode de distribution sont utilisés, les nouvelles bases signées sont-elles associées à l’intégrité de la mémoire, et qui approuve les exceptions et le retour arrière ?

Microsoft recommande des anneaux de déploiement et une évaluation en audit avant l’application dans sa vue d’ensemble du déploiement. Choisissez la méthode à partir du dossier OS/format/signature ci-dessus. Conservez les artefacts précédents et une procédure de récupération testée avant de distribuer la version candidate.

Étape 2 : générer des propositions, puis examiner chaque règle

Le processus fondé sur les événements d’audit de Microsoft nécessite une politique en mode audit déjà déployée. Exécutez sa commande documentée dans une session PowerShell élevée pour générer des règles candidates à partir des événements d’audit :

$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

Cet exemple produit le format à politiques multiples ; ce n’est pas un binaire à déployer via le paramètre GPO à politique unique. Examinez le XML généré et les avertissements. Ne conservez que les règles pour les applications, binaires et scripts approuvés, puis fusionnez-les dans la politique de base ou utilisez une politique supplémentaire autorisée. Les fichiers qui ne sont plus sur le disque ne reçoivent pas de règles générées automatiquement par ce processus.

Exécutez de nouveau les processus requis après le déploiement de la politique d’audit examinée. Maintenez l’interdiction des activités non autorisées ; un événement d’audit n’est pas une instruction de faire confiance à sa source. Examinez les événements inexpliqués et les avertissements non résolus avant de poursuivre.

Étape 3 : préparer l’artefact d’application

La procédure d’application de Microsoft part de politiques d’audit examinées. Elle copie le XML d’audit dans un fichier d’application distinct et permet facultativement de modifier l’identité de la politique pour un déploiement côte à côte. Décidez explicitement de remplacer la politique en place ou d’utiliser une nouvelle identité ; les relations avec les politiques supplémentaires doivent suivre ce choix.

Avec $EnforcedPolicyXML pointant vers la copie préparée, le changement de mode documenté est :

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

La même procédure recommande d’envisager les options 9 et 10 pour le premier anneau d’application : une option préalable au démarrage pour désactiver l’application pendant une session de démarrage et un repli en audit lorsqu’un pilote critique pour le démarrage est bloqué. Convertissez le XML examiné en binaire, appliquez le processus de signature requis et déployez avec la méthode prise en charge choisie. Conservez l’identité de l’artefact et le mode attendu dans le dossier de changement.

Après l’activation, répétez l’inventaire, l’examen de la politique chargée et les tests fonctionnels. Examinez les événements d’application au regard des attentes approuvées. N’engagez l’anneau suivant qu’après l’acceptation des preuves, des exceptions et de la préparation à la récupération par les personnes désignées ; la modification GPO elle-même n’est pas le critère de clôture.

Étape 4 : tester le retrait et la récupération

La procédure de suppression des politiques de Microsoft exige d’abord de désactiver la méthode de distribution afin d’éviter le redéploiement de la politique. Pour une politique de base signée, déployez un remplacement signé avec l’option 6, le même PolicyId, une version égale ou supérieure et une section UpdatePolicySigners. Signez-le avec un certificat figurant dans la section UpdatePolicySigners de la politique d’origine, puis redémarrez avant la suppression. Ne supposez pas qu’une suppression locale retire sans risque une politique de base signée.

Sur un système pris en charge, après avoir satisfait à ces prérequis, exécutez l’exemple de suppression documenté depuis une fenêtre de commande élevée :

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

Remplacez l’espace réservé par l’identifiant de politique approuvé. Les exigences de redémarrage varient selon la version de Windows et la signature de la politique ; utilisez la procédure liée pour la cible. La procédure opérationnelle doit également couvrir un appareil qui ne démarre plus, l’accès autorisé au firmware et la disponibilité des clés de récupération. Testez cette voie sur du matériel récupérable avant l’application.

Comment EtcSec détecte ce cas

L’etc-collector d’EtcSec inclut BP039_CCI_NOT_DEPLOYED. Au commit examiné 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, sa méthode Detect() dans bp039-cci-not-deployed.go parcourt chaque entrée collectée de GPOPolicies, en ignorant les objets de politique ou de paramètres manquants. Toute chaîne DeviceGuardConfigCIPolicyFilePath non vide renvoie nil, ce qui signifie l’absence de constat. Sinon, elle renvoie une sévérité Low, Count 1, y compris lorsqu’aucune politique n’a été collectée.

Cette branche vérifie un seul marqueur. Elle ne valide ni le fichier référencé, ni son format binaire, sa signature, sa version, son périmètre cible ou son état d’application. Une valeur positive dans une GPO sans rapport suffit à supprimer le constat ; le code ne calcule pas la stratégie résultante pour chaque appareil. Count 1 est un nombre de constats, pas un nombre d’ordinateurs non protégés.

Le fichier registrypol_parser.go examiné exige une clé contenant codeintegrity pour mapper ConfigCIPolicyFilePath. Le véritable paramètre GPO utilise la branche DeviceGuard, donc ce chemin ne renseigne pas le marqueur attendu. Séparément, CollectGPOPolicies dans smb/client.go insère un objet de politique même lorsque ses fichiers n’ont pas été lus avec succès. Un objet dans la map n’est donc pas une preuve de collecte réussie des paramètres.

Joignez à l’investigation l’inventaire indépendant des appareils, les artefacts de politique approuvés, les événements pertinents et les décisions d’examen des règles. Résolvez explicitement les échecs de collecte. Répondez à la question opérationnelle à partir de ces preuves et des critères d’acceptation convenus, au lieu de modifier une GPO uniquement pour faire taire un contrôle de marqueur.