App Control / WDAC Lite : listes d’autorisation pratiques pour tout le monde

Ce que « WDAC Lite » signifie réellement en pratique

« WDAC Lite » n’est pas un SKU officiel de Microsoft. C’est un terme de terrain pour une approche pragmatique de Windows Defender Application Control
(WDAC) où vous :

• Commencez en Audit, collectez des données d’exécution réelles, puis passez à l’application uniquement après.
• Privilégiez les règles basées sur le signataire/éditeur plutôt que des règles de hachage fragiles.
• Utilisez le Managed Installer (lorsque c’est possible) pour que votre pipeline de distribution logicielle devienne votre moteur de listes d’autorisation.
• Gardez la surface de la politique réduite : OS + canaux logiciels approuvés + un dispositif d’urgence contrôlé.
• Acceptez que la « liste d’autorisation » soit un processus, pas une configuration ponctuelle.

La partie « Lite » est philosophique : vous visez une couverture à 80 % qui bloque la majorité des malwares grand public et des outils drive‑by,
sans tenter de modéliser chaque script interne bizarre, chaque poste développeur aux cas limites, ou l’installateur 2003 de chaque éditeur.

WDAC est appliqué par Code Integrity dans le système. Si votre politique dit « non », c’est la fin de la discussion.
Vous ne pouvez pas amadouer le noyau. C’est bien. C’est aussi la raison pour laquelle vous avez besoin d’un plan de déploiement qui suppose que vous allez bloquer quelque chose d’important.

Faits intéressants et brève histoire

Un peu de contexte rend les choix de conception moins ésotériques et plus comme des cicatrices accumulées par l’expérience.

1. WDAC dérive de Device Guard (ère Windows 10), qui visait à utiliser la sécurité basée sur la virtualisation pour durcir l’exécution du code.
2. AppLocker est arrivé en premier et reste largement déployé, mais WDAC opère à un niveau plus bas (Code Integrity), ce qui change ce qui peut le contourner.
3. Les listes d’autorisation précèdent l’EDR moderne ; les anciens produits d’autorisation en entreprise étaient populaires parce que l’AV par signature était perdu d’avance à grande échelle.
4. Les recommandations de Microsoft ont évolué : de « verrouillez tout fermement » à des déploiements stagés plus pratiques avec des modèles audit-first.
5. Le code signé n’est pas automatiquement sûr ; des attaques sur la chaîne d’approvisionnement ont abusé de signatures valides, d’où la nécessité de restreindre la confiance (éditeur + produit) quand c’est possible.
6. PowerShell n’a pas toujours été l’outil d’admin par défaut ; à mesure qu’il est devenu omniprésent, le contrôle des scripts est devenu un moteur majeur du contrôle d’application moderne.
7. Les politiques CI peuvent être déployées de plusieurs manières (MDM/Intune, GPO, image système, outils locaux), et le mécanisme de livraison fait partie de votre histoire de fiabilité.
8. Les règles par hachage sont historiquement populaires parce qu’elles « fonctionnent » dans les pilotes—jusqu’au premier auto‑update qui fait exploser votre week‑end.
9. Managed Installer est un contrôle sociotechnique : il fonctionne mieux quand votre organisation utilise effectivement la distribution logicielle gérée plutôt que « exécuter l’EXE tout de suite ».

Modèle mental : ce qui est autorisé, ce qui est refusé, et pourquoi

WDAC concerne des décisions de confiance, pas des chemins de fichiers

Si vous avez vécu le contrôle basé sur les chemins, vous avez vu la tragédie : « N’autorisez que C:\Program Files\ » et soudain le malware vit dans
C:\Program Files\TotallyLegit\. WDAC est conçu pour utiliser des signaux d’identité plus forts :

• Règles éditeur/signature : « Autoriser les binaires signés par cet éditeur (éventuellement restreint au produit/version). »
• Règles de hachage : « Autoriser ce fichier exact. » Fiable et cassant. Comme un marteau en verre.
• Règles de chemin : existent, mais doivent être utilisées avec parcimonie et délibération.
• Managed Installer : « Autoriser ce qui est venu par ce canal d’installation. » Une façon d’intégrer l’outil de déploiement dans la confiance.

Le mode Audit n’est pas optionnel

Le mode Enforce est là où vous avez raison. Le mode Audit est là où vous apprenez. En audit, WDAC journalise ce qu’il aurait bloqué.
Ce sont les données dont vous avez besoin pour construire une liste d’autorisation qui correspond à la réalité, pas au diagramme d’architecture rêvé.

Il y a deux ennemis : le malware et votre propre parc

Le malware est opportuniste. Votre entreprise est… créative. Applications métier avec DLL non signées. Pilotes d’imprimante d’un fournisseur qui
pense que SHA1 est encore acceptable. Un outil « admin temporaire » devenu permanent il y a trois ans. WDAC gagne quand vous standardisez agressivement
les chemins d’exécution et la livraison logicielle.

Une citation pour rester lucide

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent attribuée dans les cercles opérationnels, courante en pensée fiabilité (popularisée par des leaders comme Gene Kranz).

Avec WDAC, « l’espoir » ressemble à : « Je pense que les outils helpdesk sont tous signés. » Ou : « Je suis sûr que le client VPN ne laissera pas un binaire non signé. »
Vous ne voulez pas découvrir la vérité en mode Enforce.

Blague #1 : La liste d’autorisation, c’est comme un régime — tout va bien jusqu’à ce que vous découvriez ce que vos utilisateurs considèrent comme « un en-cas ».

Construire une politique sans se rendre la vie impossible

Commencez avec une base défendable

Le modèle « WDAC Lite » qui fonctionne dans la plupart des entreprises :

• Autoriser les composants Microsoft Windows (binaires OS, outils inclus).
• Autoriser les signatures Microsoft des plateformes communes dont vous dépendez (Edge, composants Office) en fonction de votre parc.
• Autoriser votre canal logiciel géré (agent ConfigMgr/Intune en tant que Managed Installer, ou une chaîne d’installation interne signée).
• Autoriser les éditeurs tiers clés que vous utilisez réellement (VPN, EDR, agent de sauvegarde, assistance à distance).
• Bloquer l’exécution depuis des emplacements modifiables par l’utilisateur quand c’est possible (Downloads, Temp) en n’accordant pas la confiance là-bas.
• Conserver une procédure de secours opérationnellement réaliste (procédure d’échange de politique, accès de récupération).

Privilégiez les règles éditeur ; utilisez les hachages comme si vous payiez par hachage

Les règles éditeur survivent aux mises à jour. Les règles par hachage n’en survivent pas. Les règles par hachage restent utiles pour :

• Des exceptions à courte durée lors d’une réponse à incident.
• Des outils internes uniques qui ne seront jamais mis à jour (rare, mais réel).
• Corriger rapidement une panne critique pendant que vous négociez une version signée auprès d’un fournisseur.

Managed Installer : le super‑pouvoir « Lite »

Managed Installer est la chose la plus proche que WDAC ait d’un « faites‑en le problème de quelqu’un d’autre (en bien) ».
Si votre outil de déploiement est sain, vous pouvez dire : « Tout ce qui est installé par cet agent est approuvé. »
Alors votre liste d’autorisation devient un problème de gouvernance de déploiement, que les entreprises savent déjà traiter.

Cela impose aussi une discipline utile : si des utilisateurs installent des EXE au hasard depuis des e-mails, WDAC sanctionnera ce comportement.
Tant mieux. Vous payez pour le contrôle ; vous devriez obtenir le contrôle.

Concevez pour les changements continus, pas pour une journée parfaite

Votre politique va évoluer. De nouvelles imprimantes apparaissent. Une application critique met à jour. Un fournisseur fait pivoter des certificats.
Prévoyez :

• Un calendrier régulier de mise à jour de la politique.
• Une façon de collecter les journaux d’audit centralement.
• Un flux de travail d’exception clair (qui approuve, comment c’est encodé, et quand cela expire).
• Une histoire de rollback qui n’implique pas de réimager des postes.

Tâches pratiques (commandes, sorties, décisions)

Voici des choses que vous pouvez faire aujourd’hui sur une machine Windows pour comprendre ce qui se passe, valider des hypothèses et publier une politique plus sûre.
Les commandes utilisent PowerShell parce que c’est Windows, et la souffrance est traditionnelle.

Task 1: Confirm WDAC/App Control policy state

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -Property * | Format-List"
SecurityServicesConfigured : {1, 2}
SecurityServicesRunning    : {1, 2}
CodeIntegrityPolicyEnforcementStatus : 1
UsermodeCodeIntegrityPolicyEnforcementStatus : 1
VirtualizationBasedSecurityStatus : 2

Ce que cela signifie : Vous recherchez les champs d’application de la politique Code Integrity. Les valeurs d’état varient selon la build, mais « 1 » indique typiquement que l’application est activée pour cette dimension.

Décision : Si l’application est active, arrêtez de deviner et passez aux journaux d’événements pour voir ce qui est bloqué. Si l’application est désactivée, vous êtes en audit ou non déployé.

Task 2: Check if you’re in Audit or Enforced mode (from policy options)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root\Microsoft\Windows\CI -ClassName CI_ActivePolicy | Select-Object -ExpandProperty Policy | Format-List"
PolicyID   : {d1f4a6aa-1b6a-4e61-9f47-0e1b0d7c9d2a}
FriendlyName : Corp-WDAC-Base
Mode       : Audit
LastUpdate : 2/5/2026 9:12:44 AM

Ce que cela signifie : Cela affiche la politique active et si elle est en audit ou en application.

Décision : Si vous n’êtes pas encore en Audit, mettez‑y avant d’élargir la portée. Si vous appliquez déjà sur un pilote, bien — vous avez maintenant besoin d’un monitoring serré et d’un rollback.

Task 3: Pull WDAC audit/deny events fast (Code Integrity log)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:21:01 AM 3077 Information      Code Integrity determined that a process ... would have been prevented from running ...
2/5/2026 9:20:57 AM 3033 Warning          Code Integrity determined that a process ... did not meet the Store signing level requirements.

Ce que cela signifie : Les ID d’événement varient, mais vous recherchez « would have been prevented » (audit) et « prevented » (application). Le message inclut généralement le chemin du fichier, les informations de signature et les détails de la politique.

Décision : Identifiez les binaires bloqués les plus fréquents par fréquence et impact métier. Ne commencez pas par « autoriser tout ce qui est bloqué ». Commencez par « pourquoi cela s’exécute du tout ? »

Task 4: Filter events for a specific blocked executable

cr0x@server:~$ powershell -NoProfile -Command "$needle='AcmeUpdater.exe'; Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'} | Where-Object {$_.Message -like \"*$needle*\"} | Select-Object -First 5 TimeCreated,Id,Message | Format-List"
TimeCreated : 2/5/2026 9:10:11 AM
Id         : 3077
Message    : Code Integrity determined that a process (\Device\HarddiskVolume3\ProgramData\Acme\AcmeUpdater.exe) would have been prevented from running...

Ce que cela signifie : Vous avez trouvé la trace d’événements pour un binaire spécifique et où il se situe (ici : ProgramData, un emplacement d’« oups » courant).

Décision : S’il s’exécute depuis des emplacements modifiables par l’utilisateur ou par l’application, corrigez le chemin d’installation ou le packaging du fournisseur. Évitez les autorisations basées sur le chemin qui bénissent largement ProgramData.

Task 5: Check signature status of a binary

cr0x@server:~$ powershell -NoProfile -Command "Get-AuthenticodeSignature -FilePath 'C:\Program Files\Acme\AcmeClient.exe' | Format-List Status,StatusMessage,SignerCertificate"
Status        : Valid
StatusMessage : Signature verified.
SignerCertificate : [Subject]
  CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US

Ce que cela signifie : « Valid » est ce que vous voulez. « NotSigned » ou « UnknownError » explique la plupart des douleurs WDAC.

Décision : S’il est valide, préférez une règle éditeur. S’il n’est pas signé, ne vous précipitez pas pour l’autoriser — demandez pourquoi et si une build signée existe.

Task 6: Inspect certificate chain details to scope publisher rules safely

cr0x@server:~$ powershell -NoProfile -Command "$sig=Get-AuthenticodeSignature 'C:\Program Files\Acme\AcmeClient.exe'; $sig.SignerCertificate | Select-Object Subject,Issuer,NotBefore,NotAfter,Thumbprint | Format-List"
Subject    : CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US
Issuer     : CN=DigiCert EV Code Signing CA, O=DigiCert Inc, C=US
NotBefore  : 8/1/2025 12:00:00 AM
NotAfter   : 8/1/2027 11:59:59 PM
Thumbprint : 9F1A0C2B4D6E7F8899AABBCCDDEEFF0011223344

Ce que cela signifie : La rotation des certificats est réelle. Les empreintes expirent, les éditeurs changent d’AC. Restreindre à une empreinte est plus sûr que « autoriser tout signé », mais plus fragile qu’une règle éditeur.

Décision : Utilisez un cadrage éditeur/produit si possible. Utilisez les empreintes seulement lorsque vous devez contraindre un fournisseur dont les pratiques de signature sont problématiques.

Task 7: Export a WDAC policy to inspect it (XML view)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item -Path 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Destination $env:TEMP\ -Force; ConvertFrom-CIPolicy -BinaryFilePath $env:TEMP\SIPolicy.p7b -XmlFilePath $env:TEMP\SIPolicy.xml; Select-String -Path $env:TEMP\SIPolicy.xml -Pattern 'RuleOptions' -Context 0,5"
  <RuleOptions>
    <Option>Enabled:Audit Mode</Option>
    <Option>Enabled:Unsigned System Integrity Policy</Option>

Ce que cela signifie : Vous pouvez voir si le mode Audit est activé et d’autres options. (Le XML est verbeux ; vous ne vous souciez que de quelques réglages la plupart du temps.)

Décision : Confirmez que l’intention de la politique correspond à la réalité du déploiement. Si vous pensiez être en application alors que vous êtes en audit, votre « succès » est imaginaire.

Task 8: Create a baseline policy from a reference machine (starter move)

cr0x@server:~$ powershell -NoProfile -Command "New-CIPolicy -Level Publisher -FilePath C:\Temp\CorpBase.xml -UserPEs -ScanPath 'C:\Program Files','C:\Windows' -Fallback Hash"
Scanning files...
Found 18432 files to be scanned.
Creating policy...
Policy written to C:\Temp\CorpBase.xml

Ce que cela signifie : Vous avez généré une politique à partir de ce qui existe sur le disque. Le niveau Publisher tente de créer des règles signataires ; le fallback Hash récupère les éléments non signés.

Décision : Traitez ceci comme un brouillon. Supprimez le bazar, resserrez les autorisations larges, et ne déployez pas aveuglément ce qu’un scan a trouvé sur une seule machine.

Task 9: Merge multiple policies (because reality is multiple images and teams)

cr0x@server:~$ powershell -NoProfile -Command "Merge-CIPolicy -PolicyPaths C:\Temp\CorpBase.xml,C:\Temp\FinanceApps.xml -OutputFilePath C:\Temp\Merged.xml"
Merging 2 policies...
Merge completed successfully.

Ce que cela signifie : Vous avez consolidé des fragments de politique. C’est utile quand différentes équipes valident des listes d’autorisation distinctes.

Décision : Gardez la propriété claire : qui peut ajouter des signataires ? Si tout le monde peut, vous finirez par autoriser tout Internet via des règles éditeur excessivement larges « utiles ».

Task 10: Turn on Audit Mode explicitly in a policy (before rollout)

cr0x@server:~$ powershell -NoProfile -Command "Set-RuleOption -FilePath C:\Temp\Merged.xml -Option 3"
Updated policy rule options.

Ce que cela signifie : Les numéros d’option dépendent de l’outil/version, mais cela bascule couramment le mode Audit dans une politique CI.

Décision : Assurez‑vous d’un audit‑first pour un déploiement initial large. N’appliquez qu’après avoir réduit les principaux hits d’audit et validé les workflows critiques.

Task 11: Compile XML to binary policy (what endpoints actually consume)

cr0x@server:~$ powershell -NoProfile -Command "ConvertFrom-CIPolicy -XmlFilePath C:\Temp\Merged.xml -BinaryFilePath C:\Temp\SIPolicy.p7b"
Successfully converted C:\Temp\Merged.xml to C:\Temp\SIPolicy.p7b

Ce que cela signifie : La politique binaire est ce qui est déployé sur les endpoints.

Décision : Versionnez et signez vos artefacts de politique (au moins conservez des checksums). Traitez‑les comme de la config de production, pas « un fichier dans le dossier Downloads de quelqu’un ».

Task 12: Deploy policy locally for a pilot (carefully)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item C:\Temp\SIPolicy.p7b 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Force; gpupdate /force"
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Ce que cela signifie : Vous avez placé la politique là où Code Integrity regarde et actualisé la politique. Sur certains systèmes, un redémarrage peut être nécessaire pour un effet complet.

Décision : Faites cela uniquement sur des machines de labo/pilote avec accès de récupération. Votre plan de rollback devrait être « remplacer la politique par une connue bonne », pas « espérer que l’utilisateur ne redémarre pas ».

Task 13: Validate a suspected bypass vector: execution from user-writable paths

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl $env:USERPROFILE\Downloads | Select-Object -ExpandProperty Access | Select-Object IdentityReference,FileSystemRights,AccessControlType | Format-Table"
IdentityReference     FileSystemRights              AccessControlType
----------------     ----------------              -----------------
BUILTIN\Users        Modify, Synchronize           Allow

Ce que cela signifie : Les utilisateurs peuvent modifier Downloads. Si votre politique autorise accidentellement l’exécution là‑bas (via une règle de chemin large), vous vous êtes tiré une balle dans le pied.

Décision : Évitez les autorisations de chemin larges sur les emplacements modifiables par l’utilisateur. Utilisez des règles signataires et la confiance Managed Installer à la place.

Task 14: Find “most frequent” audit blocks (rough cut)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' | Where-Object {$_.Id -in 3076,3077,3033} | ForEach-Object { if ($_.Message -match '(\w:.*\.(exe|dll|ps1|msi))') { $matches[1] } } | Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Count,Name | Format-Table -Wrap"
Count Name
----- ----
  112 C:\ProgramData\VendorX\Updater.exe
   87 C:\Windows\Temp\printdriverinstall.exe
   55 C:\Users\jdoe\AppData\Local\Temp\7zS3A2.tmp\setup.exe

Ce que cela signifie : Les principaux éléments qui « auraient été bloqués ». ProgramData et Temp sont des récidivistes.

Décision : Traitez-les en changeant le déploiement (installation gérée), en mettant à jour les packages fournisseurs, ou en supprimant le logiciel. N’« autorisez pas Temp » par commodité. C’est comme ça que vous recevez des appels d’incident.

Blague #2 : Le moyen le plus rapide de découvrir des dépendances non documentées est d’activer l’application un vendredi. S’il vous plaît, ne le faites pas.

Mode d’emploi pour un diagnostic rapide

Quand quelque chose « ne s’exécute pas » après des changements WDAC/App Control, vous devez déterminer : est‑ce vraiment WDAC, qu’est‑ce qui a été bloqué exactement,
et quelle est la correction la plus étroite et la plus sûre.

Première étape : prouvez que c’est WDAC (et non EDR, AV, ou un installateur cassé)

• Vérifiez les événements Code Integrity Operational pour des messages récents « prevented » autour de l’heure de la défaillance.
• Si vous voyez des événements correspondant au chemin binaire et à l’horodatage, c’est WDAC. Si vous n’en voyez pas, arrêtez d’accuser WDAC et vérifiez les logs AppLocker/ASR/EDR.

Deuxième étape : classifiez le blocage

• Binaire non signé : courant avec les outils internes, fournisseurs legacy, DLL chargées secondairement.
• Signé mais non approuvé : règle signataire manquante, portée éditeur incorrecte, rotation de certificat.
• Lié aux scripts : PowerShell, WSH, actions MSI personnalisées, ou un hôte signé chargeant du contenu non signé.
• Mauvais emplacement : exécutable mis en place dans Temp/Downloads par un installateur/updater.

Troisième étape : décidez de la remédiation la moins dangereuse

1. Privilégiez le changement de chemin de livraison (installer correctement, arrêter d’exécuter depuis Temp) plutôt que d’élargir la confiance de la politique.
2. Privilégiez la règle éditeur (restreinte) plutôt que la règle de hachage.
3. Si vous devez utiliser un hachage, fixez une date d’expiration : suivez‑la et supprimez‑la après que le fournisseur ait corrigé ou reconditionné.
4. Validez sur un canary avant mise à jour large de la politique.

Points de blocage (ce qui vous ralentit)

• Si vous n’avez pas de collecte centralisée des logs CI, votre goulot d’étranglement est la visibilité, pas la rédaction de politique.
• Si vous continuez d’ajouter des exceptions par hachage, votre goulot est la chaîne d’approvisionnement logicielle (mises à jour sans signature prévisible).
• Si chaque unité métier a ses propres habitudes d’installation, votre goulot est la gouvernance. WDAC fera respecter la vérité que vous évitiez.

Trois mini-récits d’entreprise venant des opérations

Mini-récit 1 : La panne causée par une fausse hypothèse

Une entreprise de taille moyenne a basculé WDAC du mode audit vers l’application sur un petit ensemble de postes partagés « à faible risque ». L’hypothèse était simple :
les kiosques ne faisaient tourner qu’un navigateur et quelques applis fournisseur, et celles‑ci étaient « définitivement signées ».

Le lendemain matin, les kiosques étaient en ligne, mais l’impression était morte. Pas « parfois ». Morte. Les tickets ont afflué, et le support a fait ce que font les supports :
réinstaller le package d’imprimante. Cela a empiré, parce que l’installateur a décompressé des exécutables auxiliaires dans C:\Windows\Temp
et les a lancés depuis là. Ces auxiliaires n’étaient pas signés.

L’équipe avait des journaux d’audit, mais ils n’avaient examiné que les exécutables principaux. Ils n’avaient pas regardé la longue traîne : pilotes d’impression, processus auxiliaires,
et composants de mise à jour. Les logs CI étaient directs : les fichiers bloqués étaient précisément ceux que l’installateur avait placés dans Temp.

La correction n’a pas été « autoriser Temp ». La correction a été d’obtenir un package de pilote plus récent qui utilisait des composants signés et un emplacement de staging sain, puis d’ajouter une règle éditeur pour le fournisseur.
Ils ont aussi mis à jour la checklist du pilote : « impression et numérisation sont des workflows de première classe », parce que les utilisateurs considèrent ces fonctions comme basiques, pas comme des périphériques optionnels.

La vraie leçon : les hypothèses les plus dangereuses sont celles qui semblent ennuyeuses. « Les pilotes sont signés » semblait ennuyeux. C’était aussi faux.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une grande entreprise voulait accélérer le déploiement WDAC. L’équipe sécurité a proposé une optimisation :
« Autorisons tout le code signé par n’importe quel certificat chaînant jusqu’à une racine de confiance, puis bloquons le connu‑mauvais après. »
Cela semblait efficace. Cela a aussi réintroduit silencieusement le problème que la liste d’autorisation est censée résoudre.

Pendant quelques semaines, tout avait l’air parfait. Rien ne cassait. Les tableaux de bord étaient calmes. Puis une enquête IR a trouvé un outil d’accès à distance commercial
tournant sur plusieurs endpoints. L’outil était légitimement signé. La chaîne de signature était valide. Et parce que la politique disait effectivement « signé = approuvé »,
il s’est exécuté sans friction.

Personne n’avait « fait quelque chose de mal » au sens strict. L’optimisation fonctionnait comme prévu. C’est la conception qui posait problème.
Ils avaient construit un contrôle qui bloquait surtout le malware amateur et faisait peu contre l’écosystème d’outils signés à double usage.

La récupération a été douloureuse mais simple : ils ont resserré sur des règles éditeur pour les fournisseurs connus, activé Managed Installer pour le déploiement sanctionné,
et traité « signé mais non approuvé » comme non approuvé par défaut. L’erreur n’était pas technique. C’était une erreur de catégorie : confondre authenticité et autorisation.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation exécutait WDAC avec une discipline peu glamour : chaque changement de politique passait par un anneau canary, et chaque anneau avait un propriétaire
capable de dire « non » sans subir de retombées politiques. Ils conservaient aussi un artefact fallback connu‑bon et un script pour l’échanger.

Un fournisseur a poussé une mise à jour pour un client VPN. Les binaires étaient toujours signés, mais le fournisseur avait changé le certificat de signature et réorganisé la mise en place.
Les journaux d’audit ont immédiatement sauté dans l’anneau canary : la mise à jour casserait l’application.

Parce que l’équipe avait une routine, la réponse a été routinière : ouvrir un changement, ajouter une règle éditeur restreinte pour le nouveau signataire, valider sur canary, puis déployer.
Pas d’appel général. Pas de « autoriser temporairement tout ». Pas de rollback.

La partie ennuyeuse était la discipline d’anneau et l’hygiène des artefacts. Le résultat était excitant dans le meilleur sens : rien ne s’est passé.
En opérations, « rien ne s’est passé » est une fonctionnalité premium.

Erreurs courantes : symptômes → cause → correction

1) Symptom: “Random app won’t start; no obvious error”

Cause racine : WDAC bloque la création du processus. L’application peut échouer silencieusement ou afficher un dialogue générique « impossible d’exécuter ».

Correction : Vérifiez les logs Code Integrity Operational pour un événement de blocage correspondant à l’heure/au chemin. Ajoutez une règle signataire restreinte ou corrigez le packaging. Évitez la prolifération des hachages.

2) Symptom: “Everything works in audit, enforcement breaks multiple apps”

Cause racine : Vous avez ignoré le volume d’audit ou n’avez examiné que les « EXE principaux », pas les DLL, auxiliaires, pilotes et tâches de mise à jour.

Correction : En audit, agrégez et classez les événements par fréquence et criticité métier. Validez les workflows complets (impression, numérisation, VPN, assistance à distance, add‑ins Office).

3) Symptom: “An updater runs from ProgramData/Temp and gets blocked”

Cause racine : L’installateur du fournisseur place des exécutables dans des emplacements modifiables ; ces fichiers sont non signés ou non couverts par des règles.

Correction : Obtenez un package fournisseur corrigé, reconditionnez‑le, ou distribuez via Managed Installer afin que les binaires finaux soient approuvés. N’autorisez pas large Temp.

4) Symptom: “We keep adding hash rules every patch Tuesday”

Cause racine : Vous utilisez des règles de hachage pour des logiciels fréquemment mis à jour, ou votre méthode de génération de politique bascule par défaut sur des hachages à cause de composants non signés.

Correction : Passez aux règles éditeur quand c’est possible. Pour les composants non signés, poussez les fournisseurs/équipes internes à signer. N’utilisez les hachages que comme exceptions limitées dans le temps.

5) Symptom: “A signed tool is blocked even though it’s legitimate”

Cause racine : Vous avez autorisé une portée éditeur différente de celle du signataire réel du binaire ; rotation de certificat ou ligne produit différente utilisant un autre certificat.

Correction : Revérifiez les détails de la signature Authenticode. Ajoutez un nouveau signataire/règle éditeur restreinte au fournisseur/produit voulu.

6) Symptom: “Policy update didn’t change anything on endpoints”

Cause racine : Le mécanisme de déploiement n’a pas appliqué (sync MDM, GPO non mis à jour, mauvais emplacement de la politique), ou vous avez compilé/déployé le mauvais artefact.

Correction : Vérifiez la politique active via CIM, vérifiez que le fichier existe dans le chemin CodeIntegrity, confirmez l’heure de mise à jour. Traitez la politique comme une release versionnée.

7) Symptom: “Developers are furious; scripts and build tools are broken”

Cause racine : Vous avez appliqué une politique poste de travail aux endpoints développeurs sans modéliser les toolchains (compilateurs, gestionnaires de paquets, sorties de build locales).

Correction : Utilisez des anneaux/politiques séparés. Pour le dev, concentrez‑vous sur le blocage de l’exécution depuis des emplacements modifiables par l’utilisateur tout en autorisant les toolchains signés et les sources d’installation gérées. Et : signez vos outils internes.

8) Symptom: “We allowed ‘Microsoft’ broadly, and now a questionable tool runs”

Cause racine : Confiance trop large dans le code signé, combinée à des outils légitimes mais dangereux signés par des éditeurs réputés.

Correction : Resserrez la confiance aux éditeurs/produits explicites que vous ciblez. Utilisez des contrôles complémentaires (règles ASR, EDR) pour les outils à double usage. WDAC n’est pas votre unique garde‑fou.

Listes de contrôle / plan étape par étape

Déploiement étape par étape qui n’aboutit pas en larmes

1. Choisissez votre objectif : bloquer les binaires non approuvés dans l’espace utilisateur ; ne tentez pas de résoudre tous les cas limites de scripts le premier jour.
2. Mettez en place la visibilité : collectez centralement les événements Code Integrity. Si vous ne voyez pas, vous ne pouvez pas opérer.
3. Créez une image de référence : une machine propre avec le jeu d’apps standard. Générez une politique brouillon à partir de celle‑ci.
4. Normalisez la livraison logicielle : décidez ce qui compte comme « installation gérée » dans votre org et faites‑le respecter socialement et techniquement.
5. Activez le mode Audit à l’échelle du parc (ou un anneau large) : n’appliquez pas avant d’avoir vu au moins un cycle complet de patch.
6. Éliminez les principaux hits d’audit : corrigez le packaging, remplacez les logiciels, ajoutez des règles éditeur restreintes.
7. Définissez le workflow d’exception : qui approuve, combien de temps ça dure, quelles preuves sont requises (info de signature, propriétaire métier).
8. Anneau canary en application : petit anneau avec support rapide et accès de rollback. Validez des workflows critiques, pas seulement « les apps s’ouvrent ».
9. Anneaux progressifs : étendez l’application à des anneaux plus larges. Attendez‑vous à des douleurs différentes : applis financières, outils de centre d’appel, pilotes industriels.
10. Discipline de mise à jour de la politique : contrôle de changement, versionning, déploiement étagé, et revue des logs après changement.
11. Mesurez les résultats : comptez les exécutions non approuvées bloquées, les exceptions d’urgence, le temps de mitigation des blocages.
12. Gardez le dispositif de secours opérationnel : un rollback testé et un plan de récupération d’endpoint break‑glass.

Checklist de préparation avant l’application

• Les logs d’audit sont centralisés et interrogeables.
• Les principaux binaires bloqués sont compris (quels sont‑ils, qui les possède, pourquoi ils s’exécutent).
• Les workflows critiques sont testés bout à bout (VPN, impression, assistance à distance, installation logicielle, applis métier).
• Les artefacts de politique sont versionnés ; vous pouvez identifier ce qui est déployé sur un endpoint.
• La procédure de rollback est testée sur un appareil réel, pas seulement écrite dans un wiki.
• Le support sait comment rassembler les preuves d’événements CI et escalader avec des données utiles.

Checklist d’urgence « quelque chose est cassé »

• Identifiez si l’appareil affecté est en audit ou en application.
• Récupérez l’événement CI Operational qui référence le binaire bloqué.
• Vérifiez l’état de signature du binaire et si son emplacement est raisonnable.
• Si c’est critique pour le business, appliquez la correction temporaire la plus étroite (règle hachage avec expiration) pendant que vous poursuivez une règle éditeur durable ou une correction de packaging.
• Mettez à jour la politique sur le canary d’abord, puis déployez.

FAQ

1) Est‑ce que « WDAC Lite » affaiblit la sécurité ?

C’est une stratégie différente : déploiement stagé, confiance minimale nécessaire et survie opérationnelle. Une politique légèrement moins stricte mais effectivement appliquée bat une politique parfaite qui reste dans un PowerPoint.

2) Devrais‑je plutôt utiliser AppLocker ?

AppLocker peut être plus simple pour certains scénarios basés sur les chemins et les utilisateurs, mais l’application au niveau noyau de WDAC est plus difficile à contourner. En 2026, si vous partez de zéro pour des endpoints d’entreprise, WDAC est généralement meilleur à long terme.

3) Pourquoi ne pas autoriser tout ce qui est signé ?

Parce que « signé » signifie « authentique », pas « approuvé ». Beaucoup d’outils légitimes et signés sont aussi excellents pour les attaquants. N’autorisez que les éditeurs/produits que vous avez l’intention d’approuver, et traitez le reste comme non approuvé.

4) Quelle est la manière la plus rapide de réduire les exceptions ?

Managed Installer plus une distribution logicielle standard. Transformez le « EXE reçu par e‑mail » en « demande de logiciel dans le catalogue », et la politique devient stable.

5) Les règles de hachage sont‑elles acceptables ?

Oui, comme pansement temporaire ou pour des binaires statiques rares. Mais si vous utilisez des hachages pour Chrome/Teams/clients VPN, vous êtes sur un tapis roulant et vous êtes le hamster.

6) Comment gérer les fournisseurs qui livrent des composants non signés ?

D’abord, poussez pour des builds signés. Ensuite, envisagez de reconditionner et de contrôler où les composants résident et qui peut écrire là‑bas. Troisièmement, si vous devez autoriser du non signé, restreignez‑le fortement et traitez‑le comme une dette technique avec un propriétaire et une date d’expiration.

7) Que faire lorsqu’un certificat tourne et que des choses commencent à être bloquées ?

Confirmez avec l’inspection Authenticode et les événements CI. Ajoutez le nouveau signataire/éditeur à la politique en audit, validez sur canary, puis déployez. N’« autorisez temporairement tout signé » que si vous aimez ensuite retirer des autorisations temporaires (personne n’aime ça).

8) WDAC remplace‑t‑il l’EDR/AV ?

Non. WDAC est un contrôle préventif pour l’exécution. L’EDR offre détection, investigation, réponse et télémétrie. Vous voulez les deux : WDAC réduit ce qui peut s’exécuter ; l’EDR vous aide à comprendre ce qui a essayé.

9) Comment éviter de bloquer les outils internes des développeurs ?

Séparez les politiques par classe d’appareil (développeur vs utilisateur standard). Pour les postes de dev, autorisez les toolchains signés et les installations gérées, mais bloquez toujours les binaires inconnus depuis des chemins modifiables par l’utilisateur. Et : signez vos outils internes. Nous sommes en 2026.

10) Quelle est la partie la plus sous‑estimée des opérations WDAC ?

L’hygiène des logs et la propriété. Si personne ne possède les « principaux événements bloqués », la politique se transforme lentement en soupe d’exceptions, et vous commencerez à marchander avec votre propre baseline de sécurité.

Prochaines étapes pratiques

Si vous ne faites rien d’autre, faites ces trois choses dans cet ordre :

1. Activez le mode Audit pour un anneau significatif et collectez centralement les événements Code Integrity.
2. Corrigez les 10 principaux bloqueurs en changeant le packaging et le modèle de confiance (règles éditeur, installation gérée), pas en bénissant Temp.
3. Appliquez sur un anneau canary avec un artefact de rollback testé et une personne en astreinte capable de publier une mise à jour de politique.

WDAC Lite n’est pas synonyme de timidité. C’est être délibéré. Vous construisez un système qui dit « non » à la frontière du noyau.
C’est puissant, et le pouvoir se manie mieux avec un runbook qu’avec des impressions.