Règles ASR avec Microsoft Defender : passer d’Audit à Block sans perturber la production

Pourquoi les règles ASR sont importantes

Les règles de réduction de la surface d’attaque, ou ASR, limitent des comportements fréquemment exploités par les attaquants : lancement de processus enfants depuis Office, exécution de contenu provenant du courriel, scripts obfusqués, vol d’identifiants dans LSASS, injection de code ou utilisation détournée de PsExec et WMI.

Elles complètent l’antivirus et l’EDR en bloquant une technique avant qu’elle ne produise une compromission. Leur efficacité dépend toutefois d’un déploiement méthodique : certaines applications métier utilisent des comportements qui ressemblent à ceux d’un logiciel malveillant.

Audit, Warn et Block : trois objectifs différents

Le mode Audit simule l’application de la règle et enregistre les événements sans interrompre l’utilisateur. Il ne fournit donc aucune protection active, mais il permet de mesurer l’impact réel de chaque règle dans l’environnement.

Le mode Warn applique la règle tout en permettant une dérogation temporaire lorsque la règle le prend en charge. Le mode Block empêche réellement l’action. Certaines règles, notamment la protection de LSASS et le blocage de l’injection de code par Office, ne prennent pas en charge Warn.

Préparer un déploiement par anneaux

Avant de toucher à la production, vérifiez que Microsoft Defender Antivirus est actif, que la protection en temps réel fonctionne et que la protection fournie par le cloud est disponible. Certaines règles et alertes en dépendent directement.

Créez ensuite des anneaux représentatifs : quelques postes TI, un groupe pilote comprenant les applications métier importantes, puis la production par vagues. Une période d’audit de deux à quatre semaines couvre généralement un cycle opérationnel utile, mais elle doit inclure les tâches mensuelles ou spécialisées pertinentes pour l’organisation.

• Anneau 0 : postes TI et appareils de laboratoire.
• Anneau 1 : utilisateurs pilotes de plusieurs services et applications.
• Anneau 2 : déploiement progressif en production.
• Anneau 3 : serveurs ou appareils sensibles évalués séparément.

Méthode 1 — Déployer les règles avec Microsoft Intune

Dans le centre d’administration Intune, accédez à Endpoint security, Attack surface reduction, puis créez une stratégie Attack Surface Reduction Rules pour Windows. Affectez-la à des groupes d’appareils plutôt qu’à des groupes d’utilisateurs.

Configurez d’abord les règles à évaluer en mode Audit. Évitez une stratégie monolithique appliquée immédiatement à tous les appareils : des profils distincts par anneau simplifient l’analyse, les exceptions et le passage progressif au mode Block.

• Créer un profil ASR-Audit-Pilot affecté uniquement aux appareils pilotes.
• Laisser les exclusions vides au départ afin d’observer les comportements réels.
• Analyser les événements dans Microsoft Defender XDR et recueillir les commentaires des utilisateurs pilotes.
• Créer ensuite un profil ASR-Block-Pilot, puis élargir son affectation par vagues.

Méthode 2 — Déployer les règles avec des GPO

Pour des appareils joints à un domaine Active Directory, ouvrez la console Gestion de stratégie de groupe et créez des GPO distinctes, par exemple MDE-ASR-Pilot-Audit, MDE-ASR-Pilot-Block et MDE-ASR-Production-Block. Liez chaque GPO uniquement à l’OU ou au groupe de sécurité correspondant à son anneau.

Dans l’éditeur de stratégie, ouvrez Configuration ordinateur, Modèles d’administration, Composants Windows, Microsoft Defender Antivirus, Microsoft Defender Exploit Guard, Réduction de la surface d’attaque. Activez Configurer les règles de réduction de la surface d’attaque, sélectionnez Afficher, puis entrez le GUID de chaque règle et la valeur 2 pour commencer en Audit.

Valider l’application de la GPO

Forcez l’actualisation sur un poste pilote, générez un rapport de stratégie, puis confirmez les règles reçues avec PowerShell. Le résultat associe chaque GUID à son action : 1 pour Block, 2 pour Audit, 5 pour Not configured et 6 pour Warn.

gpupdate /force
gpresult /h C:\Temp\gpresult-asr.html

$p = Get-MpPreference

0..([math]::Min(
    $p.AttackSurfaceReductionRules_Ids.Count,
    $p.AttackSurfaceReductionRules_Actions.Count
) - 1) | ForEach-Object {
    [pscustomobject]@{
        RuleId = $p.AttackSurfaceReductionRules_Ids[$_]
        Action = $p.AttackSurfaceReductionRules_Actions[$_]
    }
} | Format-Table -AutoSize

Mesurer les événements dans Microsoft Defender

Dans Microsoft Defender XDR, Advanced Hunting permet de voir les règles les plus actives, les appareils concernés et les processus à examiner. Les résultats doivent être interprétés avec prudence : la télémétrie ASR peut regrouper ou limiter certains événements répétitifs.

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize Events=count(), Devices=dcount(DeviceId) by ActionType
| order by Events desc

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| where ActionType endswith "Audited"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    InitiatingProcessAccountName, AdditionalFields
| order by Timestamp desc

Classer les événements avant de créer une exclusion

Chaque événement d’audit n’est pas automatiquement un faux positif. Il indique qu’une règle aurait bloqué un comportement. Il faut déterminer si ce comportement est attendu, nécessaire, correctement signé et limité à un chemin précis.

Une exclusion globale autorise le fichier ou le chemin pour toutes les règles ASR et peut supprimer la télémétrie associée. Utilisez-la en dernier recours. Une exclusion propre à une règle réduit davantage l’affaiblissement de la protection.

• Confirmer le processus parent, la ligne de commande et le compte utilisés.
• Reproduire l’action sur un appareil pilote lorsque c’est possible.
• Valider l’éditeur, le hachage, le chemin et la nécessité métier.
• Préférer un fichier précis à un dossier complet.
• Documenter le propriétaire, la justification et une date de révision.

Configurer les exclusions par GPO

Pour une exclusion globale, activez Exclure des fichiers et des chemins des règles de réduction de la surface d’attaque. Dans Afficher, utilisez le chemin complet comme nom de valeur et 0 comme valeur.

Avec les modèles administratifs Windows 24H2 ou ultérieurs, la stratégie Appliquer une liste d’exclusions à des règles ASR spécifiques permet une configuration plus ciblée. Utilisez le GUID de la règle comme nom de valeur et séparez plusieurs chemins par le caractère >. N’ajoutez ni guillemets, ni espaces superflus dans les valeurs GPO.

Règles qui exigent une attention particulière

• PsExec et WMI : testez avec soin les outils d’administration et Microsoft Configuration Manager, qui s’appuie fortement sur WMI.
• Processus enfants d’Office : vérifiez les macros, extensions et applications métier qui lancent PowerShell, cmd.exe ou d’autres exécutables.
• Protection de LSASS : elle peut produire beaucoup de bruit en Audit et ne prend pas en charge Warn. Un petit pilote en Block peut parfois être plus représentatif.
• Injection de code par Office : Warn n’est pas pris en charge et les possibilités d’exclusion sont limitées.
• Scripts et contenu téléchargé : confirmez les dépendances AMSI et la protection fournie par le cloud avant de conclure qu’une règle est inefficace.

Passer progressivement au mode Block

Commencez par la règle qui génère le moins d’événements inexpliqués. Passez-la de 2 à 1 sur l’anneau pilote, surveillez les incidents et les commentaires, puis élargissez le groupe. Répétez le cycle pour chaque règle ou petit ensemble cohérent.

Dans les GPO, évitez que les stratégies Audit et Block ciblent simultanément le même appareil. Dans Intune, vérifiez aussi les affectations et les conflits. Une seule source de configuration devrait être autoritaire pour une règle et un périmètre donnés.

• Audit : collecter et comprendre.
• Exclusions : limiter et documenter.
• Block pilote : valider en conditions réelles.
• Block production : élargir par vagues et surveiller.
• Révision : supprimer les exclusions devenues inutiles.

Les erreurs les plus courantes

• Activer toutes les règles en Block sur toute la production le même jour.
• Laisser Audit indéfiniment et considérer l’environnement comme protégé.
• Exclure un dossier entier dès le premier événement.
• Déployer la même règle avec Intune et des GPO sans stratégie de précédence claire.
• Ignorer les serveurs, les postes hors ligne ou les tâches mensuelles pendant le pilote.
• Mesurer uniquement le nombre d’événements sans analyser le contexte du processus.

Conclusion

Les règles ASR constituent l’un des contrôles les plus efficaces de Microsoft Defender pour réduire l’exposition aux techniques courantes. Leur déploiement ne devrait être ni brutal ni permanent en mode Audit.

La bonne approche consiste à observer, expliquer, exclure le strict nécessaire, bloquer sur un pilote, puis étendre progressivement. Intune et les GPO permettent tous deux cette démarche lorsqu’ils sont utilisés avec des anneaux clairs, une télémétrie exploitable et une gouvernance des exceptions.

• Microsoft — Configurer les règles et exclusions ASR ↗
• Microsoft — Référence des règles ASR et de leurs GUID ↗
• Microsoft — Guide de déploiement des règles ASR ↗