Règles ASR : diagnostiquer les audits, blocages et exclusions

Résumé opérationnel

Les événements ASR se trouvent dans Microsoft-Windows-Windows Defender/Operational. Les événements 1121, 1122 et 1129 correspondent respectivement au block, à l’audit et à l’override utilisateur en warn; 5007 signale une modification de configuration.

Le rapport ASR, la device timeline et Advanced Hunting enrichissent l’événement local avec la fréquence et la population. Les événements DeviceEvents peuvent être agrégés; le volume exact doit être interprété avec les limites de rétention et de throttling.

Je déploie une règle en Audit, traite les faux positifs, puis passe par groupes pilotes en Warn ou Block. Une exclusion porte un propriétaire, une justification, une date d’expiration et le périmètre le plus étroit possible.

Les événements ASR se trouvent dans Microsoft-Windows-Windows Defender/Operational. Les événements 1121, 1122 et 1129 correspondent respectivement au block, à l’audit et à l’override utilisateur en warn; 5007 signale une modification de configuration.

Symptôme, contexte et périmètre de l’incident

Je relève le GUID de la règle et traduis son action effective avec Get-MpPreference. Le nom convivial du portail ne suffit pas lorsque plusieurs profils ou GPO configurent le même GUID.

L’événement 1121 montre un block, 1122 un audit et 1129 un override en warn. L’événement 5007 indique une modification de configuration et aide à dater l’arrivée ou le remplacement d’une policy.

Le processus qui déclenche la règle n’est pas toujours le binaire que l’utilisateur voit. Je capture parent process, command line, fichier, hash, signer, utilisateur et origine du contenu avant de créer une exception.

• Microsoft Defender, ASR, Troubleshooting, Advanced Hunting
• Endpoint Lab — Policy, Engine, Event, Hunting
• Defender Antivirus actif ou mode supporté, télémétrie Defender disponible, GUID et action des règles inventoriés

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting des règles ASR, l’enquête suit le parcours Policy → Engine → Event → Hunting. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Capturer policies et Get-MpPreference, Identifier l’événement et le GUID et Reconstruire l’arbre de processus. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Application bloquée, Aucun événement en Audit et Action différente du portail » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Capturer policies et Get-MpPreference.
• Identifier l’événement et le GUID.
• Reconstruire l’arbre de processus.

Cartographie du flux à diagnostiquer

Je relève le GUID de la règle et traduis son action effective avec Get-MpPreference. Le nom convivial du portail ne suffit pas lorsque plusieurs profils ou GPO configurent le même GUID.

L’événement 1121 montre un block, 1122 un audit et 1129 un override en warn. L’événement 5007 indique une modification de configuration et aide à dater l’arrivée ou le remplacement d’une policy.

Le processus qui déclenche la règle n’est pas toujours le binaire que l’utilisateur voit. Je capture parent process, command line, fichier, hash, signer, utilisateur et origine du contenu avant de créer une exception.

État initial et prérequis de collecte

L’état initial de Troubleshooting des règles ASR doit couvrir Defender Antivirus actif ou mode supporté, télémétrie Defender disponible, GUID et action des règles inventoriés, applications métiers représentatives. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Policy, Engine, Event, Hunting sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• Defender Antivirus actif ou mode supporté
• télémétrie Defender disponible
• GUID et action des règles inventoriés
• applications métiers représentatives
• groupe Audit puis pilote
• processus d’exception
• requêtes Advanced Hunting validées

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting des règles ASR relie Policy, Engine, Event, Hunting. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Capturer policies et Get-MpPreference. Identifier l’événement et le GUID. Reconstruire l’arbre de processus. Mesurer la population dans Advanced Hunting. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Règle ASR légitime », « Policy non appliquée », « Autorité concurrente » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Capturer policies et Get-MpPreference.
• Identifier l’événement et le GUID.
• Reconstruire l’arbre de processus.
• Mesurer la population dans Advanced Hunting.
• Tester correction sans exclusion
• Créer une exception étroite si nécessaire
• Rejouer test positif et négatif

Investigation pas à pas

L’investigation suit l’ordre Policy → Engine → Event → Hunting. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting des règles ASR, les contrôles « Reproduire et horodater le symptôme », « Contrôler la première couche », « Corréler les preuves » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé de Troubleshooting des règles ASR

Je relève le GUID de la règle et traduis son action effective avec Get-MpPreference. Le nom convivial du portail ne suffit pas lorsque plusieurs profils ou GPO configurent le même GUID.

L’événement 1121 montre un block, 1122 un audit et 1129 un override en warn. L’événement 5007 indique une modification de configuration et aide à dater l’arrivée ou le remplacement d’une policy.

Le processus qui déclenche la règle n’est pas toujours le binaire que l’utilisateur voit. Je capture parent process, command line, fichier, hash, signer, utilisateur et origine du contenu avant de créer une exception.

• Defender Antivirus actif ou mode supporté
• télémétrie Defender disponible
• GUID et action des règles inventoriés
• applications métiers représentatives

Traitement, exploitation et cas limites de Troubleshooting des règles ASR

Advanced Hunting utilise DeviceEvents avec des ActionType commençant souvent par Asr. Je segmente par règle, device, file et initiating process au lieu de compter uniquement le nombre total d’événements.

Les exclusions ASR peuvent être globales ou liées à des règles selon les options disponibles. Une exclusion trop large peut neutraliser plusieurs contrôles; je préfère corriger l’application, sa signature, son chemin ou son comportement.

Une règle en audit ne bloque pas mais peut produire un volume élevé. Je définis une durée représentative incluant clôture mensuelle, mises à jour et tâches rares afin d’éviter un faux sentiment d’absence d’impact.

• Tester correction sans exclusion
• Créer une exception étroite si nécessaire
• Rejouer test positif et négatif

Lire les états propres à Troubleshooting des règles ASR

Warn permet un contournement utilisateur pour certaines règles et scénarios. Il sert de transition, pas de cible finale automatique. Les overrides sont analysés comme des demandes d’exception et non comme une preuve que le blocage est injustifié.

Les policies ASR peuvent venir d’Endpoint Security, d’une baseline, de Settings Catalog, de GPO ou de Configuration Manager. Je recherche les propriétaires concurrents et le résultat par setting avant de modifier la règle.

La validation rejoue l’action métier exacte avec la règle visée, contrôle l’événement local, la timeline et le reporting, puis vérifie qu’une action malveillante simulée reste bloquée selon le scénario officiel.

• Application bloquée — 1121 et process tree
• Aucun événement en Audit — Get-MpPreference et 5007
• Action différente du portail — Per-setting et GPO
• Trop de faux positifs — Hunting par application

Pilote et suivi opérationnel de Troubleshooting des règles ASR

Le pilote couvre le périmètre Microsoft Defender, ASR, Troubleshooting, Advanced Hunting et contrôle Capturer policies et Get-MpPreference. Identifier l’événement et le GUID. Reconstruire l’arbre de processus. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting des règles ASR.

Les cas d’échec « Application bloquée », « Aucun événement en Audit », « Action différente du portail » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne pas exclure un dossier utilisateur entier, corréler heure locale et UTC, conserver l’événement 5007, tester chaque règle séparément. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Capturer policies et Get-MpPreference. Identifier l’événement et le GUID. Reconstruire l’arbre de processus. Mesurer la population dans Advanced Hunting. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting des règles ASR, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids,AttackSurfaceReductionRules_Actions,AttackSurfaceReductionOnlyExclusions
  Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational';Id=1121,1122,1129,5007} -MaxEvents 200 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte ASR impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  $preference = Get-MpPreference
  [pscustomobject]@{
    RuleIds = $preference.AttackSurfaceReductionRules_Ids
    Actions = $preference.AttackSurfaceReductionRules_Actions
  }
  Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1121,1122} -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[10:12:05.102] Policy      RuleId=<RULE-GUID> Action=Block Source=Intune
[10:14:37.440] Defender    EventId=1121 RuleId=<RULE-GUID> Process=winword.exe
[10:14:37.441] Defender    Target=powershell.exe User=<USER>
[10:16:02.010] Intune      PerSetting=Succeeded Device=<DEVICE>
[10:18:11.772] Validation  SameRule=True SameAttempt=True

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment Application bloquée, Aucun événement en Audit, Action différente du portail, Trop de faux positifs. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Capturer policies et Get-MpPreference, Identifier l’événement et le GUID et Reconstruire l’arbre de processus sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Troubleshooting des règles ASR est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• Capturer policies et Get-MpPreference.
• Identifier l’événement et le GUID.
• Reconstruire l’arbre de processus.
• Mesurer la population dans Advanced Hunting.
• Tester correction sans exclusion
• Créer une exception étroite si nécessaire
• Rejouer test positif et négatif

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting des règles ASR restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Capturer policies et Get-MpPreference. Identifier l’événement et le GUID. Reconstruire l’arbre de processus. Mesurer la population dans Advanced Hunting. ainsi que les causes déjà écartées.