Microsoft Defender XDR change la manière dont les alertes de prévention de la perte de données (DLP, Data Loss Prevention) issues de Microsoft Purview sont traitées dans la file d'incidents. À partir du 12 octobre, une règle de tuning intégrée reclassera automatiquement ces alertes en « comportements » plutôt qu'en alertes classiques. Pour les administrateurs qui pilotent leur SOC depuis le portail Defender XDR, ce changement modifie directement le volume et la visibilité des signaux DLP au quotidien.
Ce qui change le 12 octobre
Microsoft a communiqué ce changement via le message center sous l'identifiant MC1465771. Il introduit une nouvelle règle de tuning intégrée nommée Set-As-Behavior - Data Loss Prevention (DLP) Alerts, activée par défaut.
L'objectif affiché par Microsoft est double :
- Réduire le volume d'alertes affichées dans Microsoft Defender XDR, un point de friction récurrent pour les équipes SOC noyées sous les signaux à faible priorité.
- Préserver l'intégralité des données d'investigation DLP, désormais accessibles via Advanced Hunting et le portail Microsoft Purview.
Concrètement, les alertes DLP ne disparaissent pas : elles changent de statut et de canal d'exposition.
Changement activé par défaut
La règle Set-As-Behavior - Data Loss Prevention (DLP) Alerts s'applique automatiquement à tous les tenants concernés à partir du 12 octobre, sans action requise. Si vos playbooks SOC ou vos automatisations dépendent de la présence des alertes DLP dans la file d'incidents Defender XDR, testez l'impact avant la bascule.
Comportements vs alertes : ce que ça change réellement
Dans le modèle de détection unifié de Microsoft Defender XDR, un comportement (behavior) est un signal enrichi qui reste consultable en investigation mais qui ne génère plus systématiquement un incident visible dans la file principale. C'est le mécanisme déjà utilisé pour d'autres catégories de détections à faible criticité ou à fort volume.
Appliqué aux alertes DLP, ce mécanisme signifie que :
- Les événements DLP ne remontent plus automatiquement dans la file d'incidents de Defender XDR.
- Les signaux restent interrogeables dans les tables BehaviorInfo et BehaviorEntities via Advanced Hunting.
- Les alertes DLP continuent d'apparaître normalement dans le portail Microsoft Purview, sans perte de données côté conformité.
Ce découplage entre « visibilité dans Defender XDR » et « disponibilité de la donnée brute » est la logique centrale à retenir : rien n'est supprimé, mais le point d'entrée par défaut change.
Où retrouver les signaux DLP après la bascule
| Emplacement | Avant le 12 octobre | Après le 12 octobre |
|---|---|---|
| File d’incidents Defender XDR | Alertes DLP visibles par défaut | Alertes DLP absentes par défaut (règle activée) |
| Advanced Hunting | Table AlertInfo classique | Tables BehaviorInfo et BehaviorEntities |
| Portail Microsoft Purview | Alertes DLP disponibles | Alertes DLP toujours disponibles, sans changement |
| Automatisations / SOAR branchées sur les incidents | Déclenchement sur alertes DLP | Aucun déclenchement tant que la règle reste active |
Ce tableau met en évidence le point de vigilance principal : toute intégration tierce (SIEM, SOAR, Logic Apps, Power Automate) qui consomme la file d'incidents Defender XDR pour ses règles DLP doit être revue avant le 12 octobre.
Conserver les alertes DLP dans la file d'incidents
Si votre organisation préfère conserver le comportement historique — alertes DLP visibles et actionnables directement dans la file d'incidents Defender XDR — la règle de tuning peut être désactivée manuellement.
Ouvrir les paramètres de tuning des alertes
Dans le portail Microsoft Defender, allez dans Settings > Microsoft Defender XDR > Alert tuning.
Localiser la règle intégrée
Recherchez la règle nommée Set-As-Behavior - Data Loss Prevention (DLP) Alerts dans la liste des règles de tuning.
Désactiver la règle
Basculez la règle sur Désactivée. Les nouvelles alertes DLP recommenceront à apparaître comme des alertes standard dans la file d'incidents.
Documenter la décision
Consignez ce choix dans votre documentation de gouvernance sécurité : cette règle est susceptible d'être réévaluée par Microsoft lors de futures mises à jour de plateforme, il faut donc pouvoir tracer pourquoi elle a été désactivée.
Impact au niveau du tenant
Cette règle s'applique à l'échelle du tenant complet, pas par workload ni par périmètre RBAC. La désactiver réintroduit potentiellement un volume important d'alertes dans la file d'incidents partagée par toutes les équipes SOC. Évaluez l'impact sur vos SLA de triage avant de basculer en production.
Mise en œuvre : auditer les signaux DLP après la bascule
Que vous laissiez la règle activée ou non, il est utile de vérifier que les données DLP restent bien exploitables. Deux angles complémentaires : la requête Advanced Hunting côté Defender XDR, et l'extraction native côté Microsoft Purview via PowerShell.
Requête Advanced Hunting (KQL)
Cette requête interroge les tables BehaviorInfo et BehaviorEntities pour retrouver les signaux DLP transformés en comportements. Adaptez les noms de colonnes filtrantes en fonction du schéma affiché dans l'onglet Schema d'Advanced Hunting sur votre tenant, ce schéma pouvant évoluer.
1BehaviorInfo2| where ServiceSource has "Data Loss Prevention" or Categories has "Dlp"3| project Timestamp, BehaviorId, Title, Categories, ServiceSource, Severity4| join kind=inner (5 BehaviorEntities6 | project BehaviorId, EntityType, AccountUpn, DeviceName7) on BehaviorId8| order by Timestamp descCette requête permet de confirmer que les signaux DLP continuent bien de remonter côté Advanced Hunting après la bascule, même s'ils n'apparaissent plus dans la file d'incidents.
Extraction des incidents DLP côté Microsoft Purview (PowerShell)
Ce script utilise le module ExchangeOnlineManagement (qui embarque la connexion au centre de conformité Microsoft Purview) pour extraire les incidents DLP directement à la source, indépendamment de leur statut dans Defender XDR.
Prérequis :
- Module
ExchangeOnlineManagementen version 3.x ou supérieure. - Rôle Compliance Administrator ou View-Only DLP Compliance Management (principe du moindre privilège : privilégier le rôle en lecture seule si aucune action corrective n'est nécessaire).
1# Installation du module si nécessaire2Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser -Force3 4# Connexion au centre de conformité Microsoft Purview5Connect-IPPSSession -UserPrincipalName "admin@contoso.com"6 7# Définition de la fenêtre d'analyse (7 derniers jours)8$dateDebut = (Get-Date).AddDays(-7)9$dateFin = Get-Date10 11# Récupération du rapport détaillé des incidents DLP12$incidentsDlp = Get-DlpIncidentDetailReport -StartDate $dateDebut -EndDate $dateFin13 14# Affichage synthétique pour vérification rapide15$incidentsDlp |16 Select-Object IncidentReceivedTime, PolicyName, RuleName, Severity, Workload |17 Sort-Object IncidentReceivedTime -Descending |18 Format-Table -AutoSize19 20# Export CSV pour archivage et preuve d'audit21$cheminExport = "C:\Rapports\DLP_Incidents_$(Get-Date -Format 'yyyyMMdd').csv"22$incidentsDlp | Export-Csv -Path $cheminExport -NoTypeInformation -Encoding UTF823 24Write-Host "Rapport exporté vers $cheminExport" -ForegroundColor GreenCe script produit en sortie un tableau consolidé à l'écran ainsi qu'un fichier CSV horodaté, exploitable pour prouver que la couverture DLP reste intacte côté conformité, indépendamment du statut de la règle de tuning dans Defender XDR.
Dépannage : erreurs courantes
- La règle de tuning n'apparaît pas dans la liste : vérifiez que vous disposez du rôle Security Administrator ou équivalent dans Microsoft Defender XDR ; l'accès à
Settings > Microsoft Defender XDR > Alert tuningnécessite des permissions d'administration de la sécurité. Connect-IPPSSessionéchoue avec une erreur d'authentification : confirmez que le moduleExchangeOnlineManagementest à jour et que l'authentification moderne (MFA) est correctement configurée pour le compte utilisé.- Aucun résultat dans BehaviorInfo malgré des politiques DLP actives : le délai de propagation des signaux vers Advanced Hunting peut atteindre plusieurs heures après un événement DLP ; relancez la requête après un délai raisonnable avant de conclure à une perte de données.
Get-DlpIncidentDetailReportretourne un jeu de données vide : vérifiez que la fenêtre-StartDate/-EndDatecouvre bien une période où des règles DLP ont été déclenchées, et que le rôle attribué inclut l'accès aux rapports DLP.
Ce qu'il faut retenir
Ce changement ne supprime aucune donnée : il redistribue simplement où et comment les alertes DLP sont exposées par défaut dans l'écosystème Microsoft Defender XDR et Microsoft Purview. Trois actions concrètes avant le 12 octobre :
- Auditez vos automatisations connectées à la file d'incidents Defender XDR pour vérifier qu'aucune ne dépend exclusivement des alertes DLP.
- Décidez en amont si votre organisation conserve le comportement par défaut (comportements, faible bruit) ou désactive la règle Set-As-Behavior - Data Loss Prevention (DLP) Alerts pour garder les alertes DLP visibles dans la file d'incidents.
- Mettez en place une supervision de secours via Advanced Hunting ou l'extraction PowerShell côté Purview, pour ne jamais dépendre d'un seul canal de visibilité sur vos signaux DLP.
Si votre SOC traite un volume élevé d'alertes DLP à faible priorité, laisser la règle activée réduit mécaniquement la charge de triage. À l'inverse, si les alertes DLP sont critiques dans vos workflows de réponse à incident, la désactivation manuelle reste la voie la plus sûre.
