App Control for Business (WDAC) ou AppLocker ?

L'antivirus demande : « ce fichier est-il connu comme malveillant ? ». Le contrôle des applications pose la question inverse : « ce fichier est-il connu comme sain ? ». Tout le reste est refusé. Cette inversion met en échec les malwares courants, la plupart des déposeurs de ransomware et l'essentiel de l'outillage qu'un attaquant aux commandes apporte sur un hôte, car rien de tout cela ne figure dans votre liste d'autorisation.

Windows propose deux technologies intégrées de liste d'autorisation. Ce guide explique quand utiliser l'une ou l'autre, puis déroule un déploiement réaliste d'App Control for Business (le nouveau nom de Windows Defender Application Control, WDAC).

App Control ou AppLocker

Microsoft présente App Control comme la frontière de sécurité et AppLocker comme un contrôle complémentaire. Si vous partez de zéro, commencez par App Control.

Étape 1 : choisir une stratégie de départ

Ne partez pas d'une page blanche. Windows fournit des stratégies de base d'exemple dans C:\Windows\schemas\CodeIntegrity\ExamplePolicies :

L'App Control Policy Wizard (un outil Microsoft gratuit) s'appuie sur ces modèles avec une interface graphique et constitue la façon la plus simple de démarrer. Tout ce qu'il fait peut aussi se faire avec le module PowerShell ConfigCI.

Étape 2 : ajouter vos logiciels et un programme d'installation géré

Une stratégie qui ne fait confiance qu'à Microsoft bloque toutes les applications tierces. Trois façons de l'étendre :

1. Règles d'éditeur pour les logiciels signés par des éditeurs de confiance (le moins de maintenance).
2. Programme d'installation géré (managed installer) : désignez Intune Management Extension ou Configuration Manager comme programme d'installation géré, et tout ce qu'il installe est automatiquement approuvé. C'est ainsi que la plupart des entreprises rendent App Control maintenable.
3. Règles de hash pour les outils internes non signés, régénérées à chaque version.

Analysez une machine de référence pour générer des règles couvrant ce qui y est installé :

New-CIPolicy -Level Publisher -Fallback Hash -UserPEs `
  -ScanPath "C:\Program Files" -FilePath .\ProgramFiles.xml
Merge-CIPolicy -PolicyPaths .\AllowMicrosoft.xml, .\ProgramFiles.xml -OutputFilePath .\Base.xml

Évitez les règles de chemin pour les emplacements accessibles en écriture par les utilisateurs. Par défaut, App Control n'honore les règles de chemin que si le chemin n'est accessible en écriture qu'aux administrateurs, ce qui est un bon garde-fou ; ne désactivez pas cette vérification.

Étape 3 : ajouter les règles de blocage

Les listes d'autorisation font confiance à Microsoft, et Microsoft signe des outils que les attaquants détournent (les binaires « living off the land »). Fusionnez :

• Les règles de blocage recommandées par Microsoft : une liste publiée de binaires signés capables de contourner le contrôle des applications (par exemple d'anciennes versions d'hôtes de script et de débogueurs). Incluez-les dans chaque stratégie.
• La liste de blocage des pilotes vulnérables de Microsoft : des pilotes signés connus pour être vulnérables. Elle est activée par défaut sur tous les appareils depuis Windows 11 22H2 (et appliquée dès que l'intégrité de la mémoire, Smart App Control ou le mode S est actif), mais la copie intégrée est mise à jour moins souvent que la liste téléchargeable de Microsoft ; incluez-la explicitement pour les anciennes versions et les serveurs.

Étape 4 : déployer en mode audit

Le mode audit correspond à l'option de règle 3. Vérifiez qu'elle est définie, attribuez un ID à la stratégie et convertissez-la en binaire :

Set-RuleOption -FilePath .\Base.xml -Option 3          # Enabled:Audit Mode
Set-RuleOption -FilePath .\Base.xml -Option 16         # Enabled:Update Policy No Reboot
Set-CIPolicyIdInfo -FilePath .\Base.xml -PolicyName "Corp Base" -ResetPolicyID
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Déployez-la avec Intune (Endpoint security > App Control for Business), Configuration Manager, la stratégie de groupe (System > Device Guard > Deploy Windows Defender Application Control, renommé pour App Control dans les ADMX récents ; format à stratégie unique seulement), ou localement avec CiTool sur Windows 11 22H2 et versions ultérieures :

CiTool.exe --update-policy .\Base.cip
CiTool.exe --list-policies

Étape 5 : lire les événements

Les événements d'intégrité du code se trouvent dans Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Les événements liés aux scripts et aux MSI se trouvent dans AppLocker > MSI and Script, même quand c'est App Control qui applique la stratégie.

Collectez quelques semaines d'événements 3076 sur le pilote. Vous pouvez générer une stratégie supplémentaire directement à partir du journal d'audit :

New-CIPolicy -Audit -Level Publisher -Fallback Hash -UserPEs -FilePath .\FromAudit.xml

Relisez ce résultat à la main. Des données d'audit issues d'une machine déjà compromise, ou sur laquelle un utilisateur a lancé un téléchargement quelconque, autoriseront sans broncher des choses dont vous ne voulez pas.

Étape 6 : appliquer, anneau par anneau

Retirez l'option 3 (Set-RuleOption -Option 3 -Delete), convertissez et déployez sur un premier anneau d'appareils informatiques, puis sur les utilisateurs pilotes, puis sur tout le monde. Conservez la stratégie d'audit pour les nouveaux membres d'un anneau jusqu'à ce que leurs événements soient propres.

Utilisez des stratégies supplémentaires (format à stratégies multiples, Windows 10 1903+) pour que les responsables d'applications puissent étendre la stratégie de base sans y toucher. Une fois la situation stable, signez la stratégie de base ; une stratégie signée ne peut être supprimée que par une mise à jour signée, ce qui empêche un attaquant disposant de droits d'administration de simplement l'effacer.

Quand AppLocker reste pertinent

• Règles par utilisateur sur des machines partagées (comptes du personnel sur des bornes face aux administrateurs).
• Gains rapides sur des systèmes hérités où vous ne pouvez pas encore déployer App Control : au minimum, bloquer l'exécution depuis %USERPROFILE%, %TEMP% et %APPDATA% pour les utilisateurs standard.

Si vous utilisez AppLocker, rappelez-vous que les règles par défaut autorisent tout ce qui se trouve sous %WINDIR% et %PROGRAMFILES%, et que certains sous-dossiers de C:\Windows (comme C:\Windows\Tasks et C:\Windows\Temp) sont accessibles en écriture aux utilisateurs standard. Ajoutez des règles de refus explicites pour ceux-ci ou utilisez des règles d'éditeur au lieu des chemins par défaut. AppLocker exige le service Application Identity (AppIDSvc) en démarrage automatique ; ses événements se trouvent sous AppLocker > EXE and DLL : 8003 (audit : serait bloqué) et 8004 (bloqué).

Get-AppLockerPolicy -Effective -Xml > effective.xml
Get-ChildItem C:\Users\Public -Recurse -Filter *.exe | Convert-Path |
  Test-AppLockerPolicy -XmlPolicy .\effective.xml -User Everyone

Liste de contrôle

• Technologie choisie : App Control comme socle, AppLocker uniquement là où il apporte quelque chose
• Stratégie de base issue d'un exemple Microsoft, plus les règles de blocage recommandées et la liste de blocage des pilotes
• Programme d'installation géré configuré pour votre outil de déploiement
• Mode audit sur un pilote, événements 3076 / 8028 examinés pendant au moins deux semaines
• Application anneau par anneau ; stratégies supplémentaires pour les responsables d'applications
• Stratégie de base signée une fois stable
• Événements 3077 transférés et assortis d'alertes

Le contrôle des applications est celui qui facilite la plupart des autres : il force PowerShell en mode de langage contraint, fait des règles ASR une deuxième ligne plutôt que la première, et transforme « un utilisateur a lancé quelque chose » en un événement journalisé et bloqué.