Le filtrage des résultats dans Microsoft Defender ne se résume pas à cocher des cases dans une interface graphique. La granularité disponible, notamment dans Defender for Endpoint et Defender EASM, repose sur des mécanismes qui conditionnent directement la pertinence des données remontées. Nous détaillons ici les points techniques à maîtriser pour exploiter efficacement ces filtres.
Network Protection en mode block : le prérequis que le filtrage web exige
Le Web Content Filtering de Defender ne fonctionne pleinement que si la Network Protection est configurée en mode block. En mode passive, le filtrage se limite à Microsoft Edge et n’intercepte rien sur les autres navigateurs ni sur les applications non-navigateur.
Cette contrainte a des conséquences directes sur le périmètre de détection. Un poste où la Network Protection reste en audit ou en passive laissera passer des requêtes sortantes depuis PowerShell, des clients API ou des navigateurs tiers sans qu’aucun événement de blocage ne soit généré.
Nous recommandons de vérifier ce paramètre avant toute tentative de tri dans les journaux de filtrage web. Sans mode block actif, les résultats affichés dans la console sont incomplets et donnent une fausse impression de sécurité.
Filtres d’inventaire Defender EASM : trier les ressources par état
L’écran d’inventaire de Defender EASM affiche par défaut uniquement les ressources à l’état Approuvé. Les ressources classées Candidat, Dépendance ou Nécessite une investigation restent masquées tant que le filtre par défaut n’est pas supprimé manuellement.
Ce comportement protège contre le bruit, mais il crée un angle mort si l’objectif est justement de passer en revue les nouvelles ressources détectées ou d’examiner un problème lié à un tiers. La suppression temporaire du filtre Approuvé permet d’accéder à la vue complète.
Combiner plusieurs filtres sans perdre en lisibilité
Defender EASM autorise l’empilement de filtres. Chaque filtre ajouté restreint le sous-ensemble de ressources affiché. Le piège courant consiste à empiler des critères contradictoires qui renvoient zéro résultat, sans message d’erreur explicite.
- Commencer par un filtre large (état + type de ressource), puis affiner avec des critères spécifiques comme le domaine ou la plage IP.
- Enregistrer les requêtes filtrées fréquemment utilisées pour éviter de reconstruire la chaîne de filtres à chaque session.
- Vérifier systématiquement que le filtre d’état par défaut (Approuvé) n’a pas été réappliqué automatiquement après un changement de vue.
Repérage avancé : filtrer les résultats de chasse avec le mode guidé
Le mode guidé du repérage avancé dans Defender XDR permet de construire des requêtes de chasse sans maîtriser le Kusto Query Language. L’interface propose de sélectionner un jeu de données, puis d’appliquer des filtres et conditions pour circonscrire les résultats.
Ce mode couvre les données des trente derniers jours. Il convient à l’extension d’enquêtes sur incidents, à la recherche de menaces ciblées et à l’analyse de données de sécurité sur des zones spécifiques.
Limites du mode guidé face au KQL natif
Le mode guidé facilite l’accès, mais il ne remplace pas le KQL pour les requêtes complexes. Les jointures entre tables, les agrégations conditionnelles et les projections personnalisées restent plus efficaces en KQL brut.
Pour un analyste qui filtre régulièrement les mêmes types d’événements, le mode guidé sert de point d’entrée avant de basculer en KQL dès que la complexité augmente. Alterner entre les deux modes dans un même onglet de requête est possible et permet de gagner du temps sur les filtres de base.
Déploiement du filtrage sur un parc managé : GPO, PowerShell, MDM
Le paramétrage du filtrage web et de la Network Protection ne se limite pas à la configuration locale. Microsoft documente trois canaux d’administration pour les parcs d’entreprise : Group Policy, PowerShell et MDM/CSP.
Sur un parc géré via Intune, les profils de configuration permettent de pousser le mode block de la Network Protection sur l’ensemble des postes sans intervention manuelle. Via GPO, le paramètre se trouve dans la stratégie de protection réseau sous la section Defender.
Vérifier l’application effective du filtrage
Pousser une configuration ne garantit pas son application. Plusieurs facteurs peuvent empêcher le filtrage de fonctionner comme prévu :
- Un antivirus tiers actif peut désactiver automatiquement certains composants de Defender, y compris la Network Protection.
- Le mode de compatibilité de Defender (passif ou actif) change radicalement le périmètre de filtrage disponible.
- Les exclusions configurées localement par un administrateur peuvent court-circuiter les règles de filtrage web poussées par GPO ou MDM.
- L’absence de connectivité au service cloud Defender empêche la mise à jour des catégories de filtrage web.
Nous observons que la majorité des écarts entre la politique de filtrage souhaitée et les résultats réellement filtrés proviennent d’un conflit entre un antivirus tiers et Defender en mode passif. Vérifier le mode de fonctionnement de Defender sur chaque poste reste la première étape de diagnostic.
Filtrage web au-delà du navigateur : applications et scripts
La protection web de Defender s’étend aux applications non-navigateur. Les requêtes HTTP sortantes émises par des scripts PowerShell, des outils en ligne de commande ou des applications desktop sont interceptées lorsque la Network Protection est en mode block.
Ce périmètre élargi change la nature même du filtrage. Il ne s’agit plus de bloquer l’accès à des sites web catégorisés, mais de contrôler les flux sortants de l’ensemble du poste. Les résultats de filtrage dans la console Defender reflètent alors un spectre bien plus large que la simple navigation.
Pour exploiter cette visibilité, le tri par source (navigateur, application, script) dans les journaux de la protection web permet d’isoler rapidement les flux suspects qui ne proviennent pas d’une navigation classique. Ce filtrage par origine reste sous-utilisé dans la plupart des déploiements que nous auditons, alors qu’il fournit les signaux les plus exploitables en cas d’exfiltration de données ou de communication avec un serveur de commande.
