EDR, XDR, MDR : trois sigles, beaucoup de confusion entretenue par le marketing. L'EDR surveille vos postes ; le XDR corrèle plusieurs sources ; le MDR est le service humain qui exploite tout ça à votre place, 24/7. Ce guide se lit à deux niveaux : l'essentiel pour décider, puis un volet technique poussé — internals du capteur, MITRE Evaluations, ITDR, débat XDR natif/ouvert et comparatif à critères — pour celles et ceux qui doivent choisir et opérer.
Aucun capteur ne voit tout. EDR creuse l'hôte, NDR voit le réseau, SIEM agrège et corrèle. Chacun a son angle mort — et l'identité (ITDR) est devenue le pivot que les attaquants visent en priorité (vol de jeton, MFA contournée). Le XDR/MDR sert à recoller ces vues.
No single sensor sees everything. EDR drills into the host, NDR watches the network, SIEM aggregates and correlates. Each has a blind spot — and identity (ITDR) has become the pivot attackers target first (token theft, bypassed MFA). XDR/MDR exists to stitch these views back together.
La qualité d'un EDR se décide à la source de télémétrie, pas dans la brochure. Sous Windows : kernel callbacks, ETW et ETW-TI (Threat Intelligence), pilote minifilter pour le système de fichiers. Sous Linux : eBPF s'est imposé — il instrumente le noyau sans module noyau fragile (qui faisait tomber les serveurs à chaque mise à jour de kernel). Sous macOS : le framework EndpointSecurity, Apple ayant fermé l'accès aux extensions noyau. Le userland hooking (injection en espace utilisateur) reste contournable et en perte de vitesse. Deux exigences non négociables : la tamper protection (un agent qu'on peut tuer ne sert à rien) et un ML on-device pour la prévention même hors-ligne.
La qualité d'un EDR se joue à la source : kernel callbacks + ETW sous Windows, eBPF sous Linux (sans module noyau fragile), EndpointSecurity sous macOS. L'agent doit être inviolable (tamper protection) ; le gros de la corrélation et de la threat intel vit côté cloud. Le XDR élargit ce backend à l'identité, l'e-mail et le cloud.
An EDR's quality is decided at the source: kernel callbacks + ETW on Windows, eBPF on Linux (no fragile kernel module), EndpointSecurity on macOS. The agent must be tamper-proof; most correlation and threat intel live in the cloud. XDR extends that backend to identity, email and cloud.
L'EDR collecte sur l'hôte (processus, connexions, fichiers, registre) et applique une détection comportementale, là où l'antivirus de signatures ne voyait que du connu. Sa force : la réponse (isolement réseau, kill, rollback, live response/shell distant). Sa limite : il est aveugle hors de l'hôte — une attaque sur l'identité ou un SaaS lui échappe.
Déroulons une attaque sur l'hôte, de la macro piégée au ransomware, pour voir la télémétrie que l'EDR exploite à chaque étape.
| Étape | Télémétrie EDR | Détection / réponse |
|---|---|---|
| Exécution de macro | Processus enfant de WINWORD, ligne de commande | Détection comportementale, alerte |
| Injection de processus | API d'injection (CreateRemoteThread), mémoire RWX | Détection mémoire, kill possible |
| Vol d'identifiants | Accès à lsass.exe | Détection accès LSASS, blocage |
| Persistance / mouvement | Nouveau service, tâche planifiée, connexions | Alerte corrélée |
| Ransomware | I/O fichiers massif, suppression des shadow copies | Détection comportementale + rollback |
L'EDR voit toute la chaîne sur l'hôte. Mais si l'attaquant exécute en mémoire seule ou neutralise la collecte, c'est la qualité de la télémétrie noyau qui décide — exactement le terrain de la section suivante.
La détection EDR est un jeu du chat et de la souris. Les techniques d'évasion les plus courantes visent le hooking userland que certains EDR posent dans ntdll :
La plupart des techniques d'évasion visent le hooking userland. Un EDR qui ne repose que là-dessus est trivial à contourner ; ceux qui s'appuient sur la télémétrie noyau (kernel callbacks, ETW-TI, eBPF) relèvent fortement le coût d'évasion. C'est précisément ce que mesurent les MITRE Evaluations.
Most evasion techniques target userland hooking. An EDR relying solely on that is trivial to bypass; those built on kernel telemetry (kernel callbacks, ETW-TI, eBPF) sharply raise the cost of evasion. That's exactly what the MITRE Evaluations measure.
L'unhooking restaure les fonctions patchées ; les syscalls directs / indirects appellent le noyau sans passer par les API surveillées ; le BYOVD charge un driver signé vulnérable pour tuer l'EDR depuis le noyau ; l'AMSI bypass neutralise l'inspection des scripts ; l'EDR silencing coupe les communications de l'agent. Face à ça, les EDR matures s'appuient sur la télémétrie noyau (kernel callbacks, ETW-TI, eBPF) que l'évasion userland ne touche pas, la tamper protection, la blocklist de drivers (HVCI) et un heartbeat cloud — un agent silencieux devient lui-même un signal.
Pour sortir du marketing, le seul juge à peu près neutre est le MITRE ATT&CK Evaluations : un scénario d'attaque réel rejoué contre chaque produit. Ce qu'il faut lire — la visibilité (combien d'étapes vues), la nature des détections (telemetry brute vs analytic contextualisée), les tests de protection (blocage effectif) et surtout les changements de configuration en cours d'éval (un produit qu'on a dû reconfigurer pour « voir » n'est pas au même niveau). Méfiez-vous des « on a gagné l'éval » : MITRE ne classe pas, il expose des données brutes. Lisez le round vous-même.
Le XDR natif corrèle la télémétrie d'un seul éditeur (intégration serrée, valorisation rapide, mais verrouillage). Le XDR ouvert/hybride ingère vos sources existantes (souplesse, mais intégration à votre charge). À ne pas confondre avec le SIEM : le XDR est curé (télémétrie prête à l'emploi), le SIEM est ouvert (n'importe quel log, rétention de conformité) — ils sont complémentaires. Et l'angle décisif de 2025-2026 : l'identité. Le vol de jeton et le contournement MFA passent sous le radar d'un EDR endpoint-only ; c'est le rôle de l'ITDR (Identity Threat Detection & Response). Le schéma de la triade (en tête de guide) résume l'enjeu : aucun capteur ne voit tout.
Un MDR n'est pas un MSSP. La distinction qui change tout : un vrai MDR répond (il isole, il bloque, managed response), là où un MSSP se contente souvent de vous alerter. Les critères d'expert : autorité de réponse contractuelle, SLA de MTTD/MTTR engagés, threat hunting inclus, modèle co-managé possible, transparence (vous voyez leurs détections ?), et la nature ouverte ou fermée de la plateforme (Sophos Taegis, issu de Secureworks, est un MDR/XDR ouvert). Pour une organisation UE, la résidence des données et la juridiction du prestataire pèsent autant que les fonctionnalités.
Le bon choix n'est pas une question de budget mais de maturité et de criticité. Forte criticité + équipe peu mature = MDR (la zone PME typique). Équipe mature + faible criticité = EDR seul suffit. Le piège : construire un SOC qu'on ne tiendra pas faute d'analystes.
The right choice isn't about budget but about maturity and criticality. High criticality + low-maturity team = MDR (the typical SME zone). Mature team + low criticality = EDR alone is enough. The trap: building a SOC you can't staff.
Le bon arbitrage n'est pas budgétaire mais fonction de votre maturité et de votre criticité. Le piège classique : acheter un XDR puis le laisser sans surveillance 24/7 — dépense pure.
Critères qui décident : couverture OS, architecture du capteur (kernel/eBPF/ETW), actions de réponse, présence d'ITDR et de XDR natif, et l'offre MDR / résidence UE. (Les résultats MITRE se lisent à part, voir plus haut.)
| Solution | OS | Archi capteur | Réponse | ITDR / XDR | MDR / UE |
|---|---|---|---|---|---|
| CrowdStrike Falcon | Win / macOS / Linux | Léger, eBPF Linux | RTR (live shell), isolation, kill | Falcon Identity + XDR ouvert | Falcon Complete · cloud UE |
| SentinelOne Singularity | Win / macOS / Linux / K8s | Agent autonome, ML on-device, eBPF | Rollback ransomware, isolation | Singularity Identity + XDR | Vigilance MDR · datacenter UE |
| Microsoft Defender XDR | Win / macOS / Linux / mobile | ETW + eBPF (Linux) | Isolation, live response, auto-remédiation | Defender for Identity + XDR natif (E5) | Defender Experts · EU Data Boundary |
| Palo Alto Cortex (XDR/XSIAM) | Win / macOS / Linux | Agent + analytics cloud | Isolation, remédiation | XDR natif + XSIAM | Unit 42 MDR · régions UE |
| Sophos (Intercept X + Taegis) | Win / macOS / Linux | Intercept X + capteur | Isolation, rollback | Taegis XDR ouvert + ITDR | n°1 pure-play MDR · UE |
| Trend Vision One | Large (serveurs / cloud) | Agent + plateforme | Isolation, remédiation | XDR natif large (email, cloud, réseau) | MDR dispo · régions UE |
Lecture rapide : pour une PME sans SOC, l'angle Sophos (channel-first, n°1 du MDR pur depuis Secureworks) ou un MDR adossé à CrowdStrike/SentinelOne est souvent le plus pragmatique. Pour un parc déjà Microsoft 365 E5, Defender XDR est quasi gratuit à activer. Et le critère souveraineté (résidence UE, MSSP français) peut peser plus lourd que quelques points de fonctionnalité.
L'erreur n°1 reste l'outil qu'on n'exploite pas. Pour une PME, « EDR + MDR » bat presque toujours « construire un SIEM et recruter un SOC qu'on ne tiendra pas ». Arbitrer build vs buy, cadrer un appel d'offres MDR ou superviser un SOC externalisé : c'est précisément ce que j'accompagne.
EDR, XDR, MDR: three acronyms, plenty of marketing-fueled confusion. EDR watches endpoints; XDR correlates several sources; MDR is the human service that operates all of it for you, 24/7. This guide reads on two levels: the essentials to decide, then a deep technical part — sensor internals, MITRE Evaluations, ITDR, the native/open XDR debate and a criteria-based comparison — for those who must choose and operate.
Aucun capteur ne voit tout. EDR creuse l'hôte, NDR voit le réseau, SIEM agrège et corrèle. Chacun a son angle mort — et l'identité (ITDR) est devenue le pivot que les attaquants visent en priorité (vol de jeton, MFA contournée). Le XDR/MDR sert à recoller ces vues.
No single sensor sees everything. EDR drills into the host, NDR watches the network, SIEM aggregates and correlates. Each has a blind spot — and identity (ITDR) has become the pivot attackers target first (token theft, bypassed MFA). XDR/MDR exists to stitch these views back together.
An EDR's quality is decided at the telemetry source, not in the brochure. On Windows: kernel callbacks, ETW and ETW-TI (Threat Intelligence), a minifilter driver for the file system. On Linux: eBPF has won — it instruments the kernel without a fragile kernel module (which used to crash servers on every kernel update). On macOS: the EndpointSecurity framework, after Apple closed kernel extension access. Userland hooking remains bypassable and is fading. Two non-negotiables: tamper protection (an agent you can kill is useless) and on-device ML for prevention even offline.
La qualité d'un EDR se joue à la source : kernel callbacks + ETW sous Windows, eBPF sous Linux (sans module noyau fragile), EndpointSecurity sous macOS. L'agent doit être inviolable (tamper protection) ; le gros de la corrélation et de la threat intel vit côté cloud. Le XDR élargit ce backend à l'identité, l'e-mail et le cloud.
An EDR's quality is decided at the source: kernel callbacks + ETW on Windows, eBPF on Linux (no fragile kernel module), EndpointSecurity on macOS. The agent must be tamper-proof; most correlation and threat intel live in the cloud. XDR extends that backend to identity, email and cloud.
EDR collects on the host (processes, connections, files, registry) and applies behavioral detection, where signature antivirus only saw the known. Its strength: response (network isolation, kill, rollback, live response/remote shell). Its limit: it's blind off-host — an identity or SaaS attack slips past it.
Let's walk a host-level attack, from a booby-trapped macro to ransomware, to see the telemetry the EDR uses at each step.
| Stage | EDR telemetry | Detection / response |
|---|---|---|
| Macro execution | WINWORD child process, command line | Behavioral detection, alert |
| Process injection | Injection API (CreateRemoteThread), RWX memory | Memory detection, kill possible |
| Credential theft | Access to lsass.exe | LSASS access detection, block |
| Persistence / movement | New service, scheduled task, connections | Correlated alert |
| Ransomware | Massive file I/O, shadow copy deletion | Behavioral detection + rollback |
The EDR sees the whole chain on the host. But if the attacker runs in memory only or neutralizes collection, the quality of kernel telemetry is what decides — exactly the ground of the next section.
EDR detection is a cat-and-mouse game. The most common evasion techniques target the userland hooking that some EDRs place in ntdll:
La plupart des techniques d'évasion visent le hooking userland. Un EDR qui ne repose que là-dessus est trivial à contourner ; ceux qui s'appuient sur la télémétrie noyau (kernel callbacks, ETW-TI, eBPF) relèvent fortement le coût d'évasion. C'est précisément ce que mesurent les MITRE Evaluations.
Most evasion techniques target userland hooking. An EDR relying solely on that is trivial to bypass; those built on kernel telemetry (kernel callbacks, ETW-TI, eBPF) sharply raise the cost of evasion. That's exactly what the MITRE Evaluations measure.
Unhooking restores patched functions; direct / indirect syscalls call the kernel without going through monitored APIs; BYOVD loads a signed vulnerable driver to kill the EDR from the kernel; AMSI bypass neutralizes script inspection; EDR silencing cuts the agent's communications. Against this, mature EDRs rely on kernel telemetry (kernel callbacks, ETW-TI, eBPF) that userland evasion doesn't touch, on tamper protection, the driver blocklist (HVCI) and a cloud heartbeat — a silent agent becomes a signal in itself.
To cut through marketing, the only roughly neutral judge is the MITRE ATT&CK Evaluations: a real attack scenario replayed against each product. What to read — visibility (how many steps seen), the nature of detections (raw telemetry vs contextualized analytic), the protection tests (actual blocking) and above all the configuration changes made mid-eval (a product reconfigured to "see" isn't on the same footing). Beware "we won the eval": MITRE doesn't rank, it exposes raw data. Read the round yourself.
Native XDR correlates one vendor's telemetry (tight integration, fast time-to-value, but lock-in). Open/hybrid XDR ingests your existing sources (flexible, but integration is on you). Don't confuse it with the SIEM: XDR is curated (out-of-the-box telemetry), the SIEM is open (any log, compliance retention) — they're complementary. And the decisive 2025-2026 angle: identity. Token theft and MFA bypass go under the radar of an endpoint-only EDR; that's the role of ITDR (Identity Threat Detection & Response). The triad diagram (top of this guide) sums it up: no single sensor sees everything.
An MDR is not an MSSP. The distinction that changes everything: a real MDR responds (it isolates, it blocks, managed response), where an MSSP often just alerts you. Expert criteria: contractual response authority, committed MTTD/MTTR SLAs, included threat hunting, a possible co-managed model, transparency (do you see their detections?), and whether the platform is open or closed (Sophos Taegis, from Secureworks, is an open MDR/XDR). For an EU organization, data residency and the provider's jurisdiction weigh as much as features.
Le bon choix n'est pas une question de budget mais de maturité et de criticité. Forte criticité + équipe peu mature = MDR (la zone PME typique). Équipe mature + faible criticité = EDR seul suffit. Le piège : construire un SOC qu'on ne tiendra pas faute d'analystes.
The right choice isn't about budget but about maturity and criticality. High criticality + low-maturity team = MDR (the typical SME zone). Mature team + low criticality = EDR alone is enough. The trap: building a SOC you can't staff.
The right call isn't budgetary but a function of your maturity and criticality. The classic trap: buying an XDR then leaving it without 24/7 watch — pure waste.
Deciding criteria: OS coverage, sensor architecture (kernel/eBPF/ETW), response actions, presence of ITDR and native XDR, and the MDR / EU residency offer. (MITRE results are read separately, see above.)
| Solution | OS | Sensor arch | Response | ITDR / XDR | MDR / EU |
|---|---|---|---|---|---|
| CrowdStrike Falcon | Win / macOS / Linux | Lightweight, Linux eBPF | RTR (live shell), isolation, kill | Falcon Identity + open XDR | Falcon Complete · EU cloud |
| SentinelOne Singularity | Win / macOS / Linux / K8s | Autonomous agent, on-device ML, eBPF | Ransomware rollback, isolation | Singularity Identity + XDR | Vigilance MDR · EU datacenter |
| Microsoft Defender XDR | Win / macOS / Linux / mobile | ETW + eBPF (Linux) | Isolation, live response, auto-remediation | Defender for Identity + native XDR (E5) | Defender Experts · EU Data Boundary |
| Palo Alto Cortex (XDR/XSIAM) | Win / macOS / Linux | Agent + cloud analytics | Isolation, remediation | Native XDR + XSIAM | Unit 42 MDR · EU regions |
| Sophos (Intercept X + Taegis) | Win / macOS / Linux | Intercept X + sensor | Isolation, rollback | Open Taegis XDR + ITDR | #1 pure-play MDR · EU |
| Trend Vision One | Broad (servers / cloud) | Agent + platform | Isolation, remediation | Broad native XDR (email, cloud, network) | MDR available · EU regions |
Quick read: for an SME without a SOC, the Sophos angle (channel-first, #1 pure-play MDR since Secureworks) or an MDR backed by CrowdStrike/SentinelOne is often the most pragmatic. For an estate already on Microsoft 365 E5, Defender XDR is almost free to switch on. And the sovereignty criterion (EU residency, French MSSP) can outweigh a few feature points.
Mistake number one is still the unwatched tool. For an SME, "EDR + MDR" almost always beats "build a SIEM and hire a SOC you can't staff". Arbitrating build vs buy, scoping an MDR RFP or supervising an outsourced SOC: that's exactly what I help with.
La donnée est gratuite. Pour un avis sur l'impact réel sur votre parc et un plan de remédiation, on en parle.
Nous contacter →