2026-07-15 · Team Fenrir

MDR vs EDR: las diferencias reales, contadas por operadores

EDR y MDR no compiten: uno es una herramienta, el otro es un servicio. El EDR es el agente que registra y bloquea en el endpoint; el MDR es quien vigila ese agente, lo interroga y responde — también a las 2 de la madrugada. Comprar un EDR te da telemetría y botones. Comprar un MDR significa que alguien pulsa esos botones. Veamos qué hace realmente cada uno, y por dónde pasa la frontera.

¿Qué es un EDR, en la práctica?

La categoría tiene fecha de nacimiento exacta: el 26 de julio de 2013, cuando el analista de Gartner Anton Chuvakin bautizó como “Endpoint Threat Detection & Response” las herramientas «centradas en detectar e investigar actividades sospechosas (y sus rastros)» en hosts y endpoints. La “T” se perdió por el camino; el oficio sigue siendo el mismo. Un EDR moderno hace cuatro cosas:

1. Registra — procesos lanzados, conexiones de red, cambios en ficheros y registro, comandos ejecutados. En continuo, en cada endpoint.
2. Detecta — reglas y análisis de comportamiento sobre esa telemetría: el PowerShell oculto, el proceso que toca cientos de ficheros en un minuto.
3. Permite investigar — la línea de tiempo de lo que pasó antes y después de la alerta, en qué máquina, con qué usuario.
4. Expone acciones de respuesta — aislar el host de la red, matar un proceso, poner un fichero en cuarentena.

Fíjate en el verbo: expone. Un EDR te entrega una cola de alertas y una botonera. No decide quién mira la cola, con qué prioridad, en cuánto tiempo — y no pulsa los botones por sí solo, salvo en los casos más nítidos.

¿Qué es un MDR, en la práctica?

Managed Detection & Response es la otra mitad del trabajo, entregada como servicio: alguien — fuera de tu empresa — monta la detección sobre tus endpoints y la opera. Monitorización continua, triaje de alertas, investigación, contención, caza proactiva de amenazas, tuning de reglas. Un MDR suele estar construido precisamente sobre un EDR (tuyo o del proveedor): el mismo sensor, pero con un turno de trabajo pegado.

Que el punto crítico sean las personas y no la tecnología lo confirma quien evalúa estos servicios: cuando MITRE Engenuity lanzó en 2021 sus ATT&CK Evaluations para servicios gestionados, citaba una encuesta preliminar en la que el 58% de las organizaciones dependía de servicios gestionados para su SOC — y aproximadamente la mitad no confiaba en las personas o la tecnología de su proveedor. De ahí el formato “closed book”: el proveedor no sabe qué adversario se va a emular, exactamente como en la realidad.

La diferencia de fondo está en el entregable. Un EDR te entrega software y telemetría. Un MDR te entrega un resultado: el incidente triado, contenido, explicado.

Ya tengo un EDR: ¿qué me falta?

Tres cosas, y ninguna es un módulo que se añada en el checkout.

Alguien que mire la cola. Un EDR sobre unas decenas de endpoints produce alertas cada día: verdaderas, falsas, y esa zona gris intermedia que cuesta tiempo. Sin un responsable del triaje — con tiempos definidos — la cola se convierte en ruido de fondo, y la alerta real se ahoga entre falsos positivos.

Alguien fuera de horario. Los atacantes eligen el momento: en los casos de ransomware analizados por Mandiant entre 2017 y 2019, el 76% de las ejecuciones ocurrió fuera del horario laboral — fines de semana, antes de las 8, después de las 18. No es casualidad: es el momento en que nadie mira la cola del EDR.

Alguien que apague el incendio, y cómo. La respuesta no es un botón sino un proceso: el NIST le dedicó la SP 800-61r3 (2025), que trata la respuesta a incidentes como un ciclo continuo — preparación, detección, respuesta, recuperación — dentro de la gestión del riesgo, no como un gesto aislado. Aislar el host correcto en el momento correcto, decidir si hace falta un reimage, reconstruir el vector de entrada: eso exige playbooks y manos entrenadas.

Y hay un cuarto punto, el más antipático: el EDR es un objetivo. MITRE ATT&CK cataloga como T1685 (Disable or Modify Tools, la antigua T1562.001) la práctica de los atacantes de desactivar, degradar o manipular precisamente las herramientas de seguridad — EDR incluido — para cegar la defensa. Un sensor que deja de hablar no envía alertas: es un silencio, y el silencio solo lo nota quien está escuchando.

¿Cuánto importa el tiempo, con números?

El dwell time — cuánto permanece un atacante en la red antes de ser descubierto — es la métrica que separa una molestia de un desastre. M-Trends 2025 (datos de 2024, más de 450.000 horas de investigaciones de Mandiant) dibuja este panorama:

• dwell time mediano global: 11 días;
• cuando la organización se da cuenta por sí sola: 10 días;
• cuando se entera porque alguien de fuera se lo notifica: 26 días;
• cuando es el propio atacante quien se anuncia (típicamente la nota de rescate): 5 días.

Lee la última línea por lo que es: en los peores casos, la “detección” es el ransomware presentándose. La diferencia entre 10 y 26 días es la diferencia entre tener una detección operada — por un equipo interno o por un MDR — y esperar a que otro se dé cuenta.

MDR, SOC, XDR: ¿cómo encajan las siglas?

Glosario de operador, sin marketing:

• EDR — herramienta. Sensor y actuador en el endpoint.
• XDR — herramienta. Como el EDR, pero extiende recolección y correlación a red, identidad, cloud, email.
• SOC — función. Las personas, los procesos y la tecnología que monitorizan y responden, en casa.
• MDR — servicio. Las funciones operativas de un SOC compradas fuera, normalmente sobre un stack predefinido del proveedor.

La pregunta “¿EDR o XDR?” va de qué recoges. La pregunta “¿SOC interno o MDR?” va de quién responde. Son dos ejes distintos, y confundirlos es la forma más rápida de comprar lo equivocado.

¿Cómo elijo entre EDR solo y MDR?

Tres preguntas honestas, antes de mirar cualquier tarifa:

1. ¿Quién hace triaje de una alerta crítica en 30 minutos, hoy? Un nombre y un apellido, no “el departamento de IT”.
2. ¿Quién lo hace el sábado a las 3 de la madrugada? (Relee el 76% de arriba.)
3. ¿Quién hace tuning de las reglas y caza amenazas cada semana? Un EDR nunca afinado grita, y a quien grita siempre se le deja de escuchar.

Si alguna respuesta es “nadie”, tu EDR es una caja negra: registrará perfectamente el incidente que nadie detuvo. Llegados ahí, las opciones son dos — construir la vigilancia (personas, turnos, playbooks) o comprarla como servicio.

Y si evalúas un MDR, dale la vuelta a la mesa con preguntas de operador: ¿qué acciones de respuesta está autorizado a ejecutar por su cuenta (¿aislamiento? ¿kill de proceso?) y cuáles requieren tu aprobación? ¿Qué tiempos de contención declara, medidos cómo? ¿La telemetría sigue siendo tuya si el contrato termina? ¿Y cómo demuestra la calidad de su detección — ha aceptado alguna vez una evaluación independiente a escenario ciego, como las ATT&CK Evaluations de MITRE Engenuity?

¿Y la IA, en todo esto?

Es la tercera forma de cubrir el turno de noche. El cuello de botella del MDR clásico son las personas — encontrarlas, formarlas, mantenerlas despiertas — y por eso nuestro enfoque en Fenrir MDR invierte el esquema: la IA hace detección, triaje y contención en autonomía graduada (por encima de un umbral de confianza actúa sola, con acciones reversibles; por debajo, pregunta), y el humano supervisa las decisiones de alto impacto. Los endpoints y los servidores acaban en la misma consola del SOC, correlacionados. El principio, sin embargo, no cambia, y es el punto de todo este artículo: la herramienta sin alguien — o algo — que la opere es solo telemetría bien archivada.