EDR Windows - Pourquoi l'antivirus ne suffit plus à votre sécurité ?

Sur un parc Windows, un EDR Windows bien réglé ne sert pas seulement à lever des alertes : il aide à repérer un comportement suspect, à comprendre comment une attaque s’est propagée et à contenir l’incident avant qu’il ne s’étende. La différence avec un antivirus classique tient surtout à la profondeur de détection, à la corrélation des événements et à la capacité de réponse. Dans cet article, je vais aller à l’essentiel : ce que fait réellement un EDR sur Windows, comment le distinguer d’un antivirus ou d’un XDR, et quels points vérifier avant de le déployer.

Ce que fait vraiment un EDR sur Windows

Un EDR collecte de la télémétrie sur les processus, les connexions réseau, les modifications de fichiers, les scripts lancés et d’autres signaux système, puis il les corrèle pour faire ressortir une chaîne d’attaque. Sur Windows, c’est particulièrement utile parce que beaucoup d’incidents commencent petit: une macro, un script PowerShell, un téléchargement discret, puis une tentative de déplacement latéral ou d’élévation de privilèges.

La logique n’est pas de “tout enregistrer”, mais de faire apparaître ce qui mérite une enquête. Microsoft précise d’ailleurs que la détection EDR n’est pas conçue comme une solution de journalisation exhaustive; elle sert d’abord à détecter, investiguer et répondre. C’est un point important, parce que beaucoup d’équipes attendent d’un EDR le comportement d’un SIEM ou d’un outil de logs, alors que les objectifs ne sont pas les mêmes.

Détection en continu

Le premier apport concret, c’est la détection comportementale. Là où un antivirus classique cherche surtout des signatures connues ou des variantes proches, l’EDR s’intéresse à ce que fait réellement la machine: exécution suspecte d’un binaire, enchaînement inhabituel de commandes, accès anormal à des fichiers sensibles, création de persistence. Sur un poste Windows, cette lecture contextuelle fait souvent toute la différence entre une alerte ignorée et un incident réellement contenu.

Corrélation et enquête

L’autre force de l’EDR, c’est la mise en relation. Une alerte isolée peut paraître banale; plusieurs signaux faibles, rassemblés sur quelques minutes ou quelques heures, dessinent déjà un scénario plus clair. C’est là que les incidents prennent forme, avec une chronologie utile pour comprendre l’origine, la propagation et l’ampleur potentielle de l’attaque.

Réponse et confinement

Sur le terrain, la vraie valeur ne se mesure pas au nombre d’alertes, mais à la vitesse de réponse. Un EDR efficace permet d’isoler une machine, de mettre un fichier en quarantaine, de bloquer un comportement ou de guider l’analyste vers la bonne action. Sur Windows, cette capacité de réaction est essentielle, parce qu’une compromission qui reste quelques heures de trop peut transformer un poste de travail en point d’appui pour tout le réseau.

C’est précisément cette logique de contexte qui le distingue d’un simple moteur de signature, et c’est ce qui rend la comparaison avec l’antivirus indispensable.

Pourquoi un antivirus ne suffit plus seul

La bonne lecture, c’est la suivante: l’antivirus bloque les menaces connues ou fortement suspectes, tandis que l’EDR aide à voir l’attaque en train de se construire. Quand les deux sont bien articulés, la posture est plus solide. Quand on confond les deux, on se retrouve souvent avec beaucoup de bruit et peu de réponse.

En pratique, un antivirus seul peut encore convenir pour un usage très simple, mais dès qu’il faut investiguer un incident ou contenir un mouvement latéral, l’EDR devient la couche décisive. Et dès que l’attaque traverse le poste, l’identité et la messagerie, l’XDR commence à apporter de la valeur réelle.

Comment choisir entre protection native, EDR et XDR

Je conseille de partir du niveau d’exposition, pas du catalogue produit. Une petite structure sans équipe sécurité interne n’a pas besoin de la même profondeur qu’un groupe multi-sites avec serveurs métiers, postes d’administration et exigences de supervision en continu. Sur un parc Windows, la bonne question n’est pas “quel outil a le plus de fonctionnalités”, mais “quelle capacité de détection et de réponse est réellement exploitable par mon équipe”.

Lire aussi : Ransomware as a Service - Comment protéger votre entreprise ?

Plan 1 ou plan 2

Microsoft positionne Defender for Endpoint en deux plans. Le plan 1 donne le socle de protection: antimalware de nouvelle génération, contrôle de certaines surfaces d’attaque, protection réseau et web, ainsi que des actions manuelles de réponse. Le plan 2 ajoute ce que la plupart des équipes attendent d’un EDR complet: investigation automatisée, remédiation, threat and vulnerability management, renseignements sur les menaces, sandbox et Microsoft Threat Experts.

Pour les serveurs, il faut aussi garder un point de budget en tête: une licence distincte est requise par environnement d’exploitation. C’est un détail administratif, mais il évite de construire un déploiement sur une hypothèse de licence qui ne tient pas.

Si votre environnement Windows est déjà hybride, très réparti ou exposé à des attaques plus sophistiquées, l’XDR devient pertinent, parce qu’il relie les alertes du poste, de l’identité et de la messagerie. Sinon, un bon EDR bien opéré reste souvent le meilleur rapport complexité / valeur.

Ce qu’il faut vérifier avant le déploiement

Avant de généraliser, je vérifie toujours la version de Windows, l’état réel du moteur Defender, le mode d’onboarding et la façon dont les alertes seront traitées par l’équipe. Sur les serveurs, les règles sont un peu différentes et il vaut mieux les traiter séparément, plutôt que de les “faire suivre” le même chemin que les postes utilisateurs.

Microsoft indique que, sur Windows Server 2016 et les versions ultérieures, Microsoft Defender Antivirus est installé et fonctionnel par défaut; sur Windows Server 2012 R2, il s’installe lors de l’onboarding avec la solution unifiée moderne. Si vous gérez encore des serveurs plus anciens, je recommande aussi de contrôler vos ADMX et vos stratégies de groupe avant d’aller plus loin.

Une fois cette base validée, le déploiement devient beaucoup plus simple à opérer, parce qu’on sait exactement ce qui doit être visible, bloqué ou seulement surveillé.

Déployer et piloter au quotidien sans noyer l’équipe

Pour un déploiement propre, je préfère une montée en charge par lots: postes pilotes, postes administratifs, puis serveurs critiques. Les outils de pilotage les plus courants restent Intune, les stratégies de groupe, le portail Microsoft Defender et, selon l’existant, Configuration Manager. Dans un contexte français, cette approche progressive évite de déstabiliser des métiers qui dépendent fortement de leurs postes Windows.

1. Onboarder d’abord un petit périmètre représentatif, avec quelques postes utilisateurs et un ou deux serveurs non critiques.
2. Vérifier le mode réel de protection avec Get-MpComputerStatus et regarder la ligne AMRunningMode pour distinguer le mode normal, passif ou EDR en blocage.
3. Sur les serveurs, confirmer le service avec Get-Service -Name windefend ou sc query Windefend.
4. Éviter les exclusions trop larges, surtout si elles ont été héritées d’une ancienne politique antivirus.
5. Si un antivirus tiers reste en place, activer le mode blocage EDR quand le plan et la configuration le permettent: Microsoft le recommande justement dans ce scénario.
6. À partir de la version de plateforme 4.18.2202.X, cibler des groupes de machines précis via les CSP Intune plutôt que d’activer le réglage à l’aveugle sur tout le tenant.

Je recommande aussi de distinguer trois niveaux de traitement: alerte informative, alerte à investiguer, incident à contenir. Sans cette hiérarchie, l’équipe finit vite par traiter tout au même niveau, ce qui fatigue les analystes et ralentit la vraie réponse.

Plus la supervision monte, plus il devient intéressant d’utiliser la recherche avancée pour retrouver les comportements récurrents et bâtir des règles de détection sur des scénarios déjà observés.

Les erreurs que je vois le plus souvent

Les déploiements EDR échouent rarement à cause de la technologie elle-même. Ils échouent plutôt parce qu’on lui demande de compenser un manque de méthode, ou parce qu’on le configure comme un antivirus amélioré alors qu’il faut le penser comme une capacité d’enquête et de réponse.

• Confondre visibilité et journalisation exhaustive: un EDR n’est pas un outil de logs complet, et Microsoft le rappelle explicitement.
• Laisser les exclusions s’accumuler: chaque exception large réduit la valeur de détection et crée des angles morts.
• Oublier les serveurs: dans le parcours cybersécurité de l’ANSSI, l’EDR sur les serveurs est justement traité comme un point de contrôle utile pour la surveillance continue.
• Ne pas préparer le triage: sans règles de priorisation, les alertes s’empilent et l’équipe perd du temps sur des signaux mineurs.
• Activer le blocage sans vérifier la base cloud: le mode blocage EDR dépend d’une configuration propre, pas seulement d’un bouton activé dans la console.
• Conserver des stratégies héritées sans les relire: une ancienne GPO “Turn off Windows Defender” peut produire un effet différent de celui qu’on imagine après l’onboarding.

Je vois aussi un piège plus subtil: vouloir tout corriger par l’outil alors que le vrai problème est souvent organisationnel, avec peu de règles de réponse, pas assez de validation sur le terrain et des responsabilités floues entre poste, serveur et SOC.

En pratique, c’est cette partie opérationnelle qui fait la différence entre un EDR visible sur le papier et un EDR utile quand l’incident arrive vraiment.

Ce qu’un EDR bien réglé change réellement sur un parc Windows

Le meilleur résultat n’est pas “plus d’alertes”, mais moins de temps perdu à comprendre où commence l’attaque et où elle s’arrête. Sur un parc Windows, un EDR correctement onboardé permet de réduire le délai de détection, de prioriser les incidents qui comptent et de standardiser la réponse entre les postes utilisateurs, les machines d’administration et les serveurs.

Si je devais démarrer demain, je lancerais un pilote sur les machines à plus forte valeur, j’activerais l’onboarding et la vérification du mode de protection, puis j’élargirais au périmètre serveur avec des règles simples de triage. C’est cette discipline, plus que la marque de la solution, qui fait la différence entre une sécurité théorique et une vraie capacité de réponse.