MDR ≠ alertar. Un proveedor MDR serio asume la contención asistida del incidente (aislar endpoint, revocar credenciales, bloquear C2) y coordina con TI hasta cierre. Si solo te avisan por correo, no es MDR — es vigilancia.
Qué es MDR
MDR (Managed Detection and Response) es un servicio gestionado 24×7 que combina tecnología de detección extendida —EDR, XDR, SIEM, NDR— con analistas humanos que monitorizan, investigan y responden a incidentes en nombre del cliente. A diferencia de un SOC tradicional, el MDR pone el foco en respuesta operativa hasta el cierre del incidente, no solo en alertar.
Por qué importa
Una organización que despliega EDR de gama alta sin equipo para operarlo recibe miles de alertas al mes y termina apagando el sistema o ignorándolo. El MDR resuelve ese hueco: el proveedor aporta el equipo, los playbooks, la telemetría enriquecida y el SLA de respuesta. Para compradores B2B regulados, MDR es habitualmente la opción más rentable frente a construir un SOC interno con turnos 24×7, salarios competitivos y rotación de analistas. Bajo marcos como NIS2, DORA e ISO 27001:2022, el MDR aporta evidencia continua de detección, respuesta y mejora.
Puntos clave
La base tecnológica suele ser EDR (CrowdStrike, Microsoft Defender for Endpoint, SentinelOne, etc.) ampliada con XDR (identidad, M365, red, cloud). Cada vez más MDR son BYO-EDR: el cliente conserva su licencia y el MDR opera encima.
Los SLAs típicos miden tiempo de detección (MTTD), tiempo de contención (MTTC) y notificación al cliente. Un buen MDR comprometerá MTTD ≤ 15 minutos en alertas críticas y notificación ≤ 1 hora ante incidente confirmado.
MDR encaja con marcos cuantitativos modernos: priorización por EPSS y KEV, hunting basado en MITRE ATT&CK, automatización con SOAR. La diferencia con un MSSP genérico es el peso del análisis humano.
Bajo NIS2 y DORA, la evidencia de detección, respuesta y notificación en plazo es exigible. Un MDR documentado produce justo ese tipo de evidencia continua, lo que reduce esfuerzo de auditoría frente a improvisar la operación cada vez.
Confusión habitual: MDR no sustituye a la respuesta forense profunda. Tras un incidente grave, el MDR contiene y entrega evidencias; el DFIR investiga causa raíz, alcance lateral y produce informe ejecutivo.
Ejemplo: cómo aterriza un MDR enterprise sobre una flota Windows + M365
Una empresa mediana con 600 endpoints Windows y operación crítica en Microsoft 365 contrata un MDR sobre su Microsoft Defender for Endpoint existente. El proveedor incorpora la telemetría Defender + Defender for Identity + Defender for Cloud Apps a su plataforma XDR, despliega casos de uso ajustados al sector y valida cada uno con falsos positivos controlados antes de poner los SLAs en vigor.
Tres meses después, el MDR detecta a las 3:14 una cadena anómala: explorer.exe lanzando mshta.exe con argumentos remotos contra un dominio recién registrado. La consulta KQL automatizada correlaciona con un intento de OAuth abusivo en el tenant M365 minutos antes. El analista L2 aísla el endpoint en 6 minutos, revoca todas las sesiones del usuario en identidad, abre incidente con el cliente y coordina la rotación de credenciales. La evidencia queda recogida con timestamps trazables para la auditoría NIS2 del siguiente trimestre.
Errores habituales
- Comprar MDR pensando que el proveedor también va a gestionar todos los falsos positivos sin afinar. El MDR depende del contexto del cliente. Un onboarding sin diálogo con TI deja al MDR generando ruido durante meses.
- Confundir MDR con MSSP genérico. Un MSSP puede ser muy bueno, pero su foco suele ser visibilidad y reporting. El MDR centra el contrato en respuesta gestionada y SLAs de contención.
- No pedir SLAs en lenguaje claro. MTTD y MTTC deben aparecer en el contrato con definición precisa y consecuencias claras si se incumplen. Sin eso, el MDR es marketing.
- Externalizar el MDR y dejar de hacer hunting interno. El mejor resultado se obtiene cuando el equipo del cliente sigue haciendo hipótesis y el MDR las ejecuta o valida, no cuando el cliente desaparece de la operación.
- No prever el plan de salida. Si terminas el contrato MDR, ¿qué documentación se queda contigo? Casos de uso, playbooks, integraciones, lecciones aprendidas. Negocia eso desde el contrato.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿En qué se diferencia MDR de un SOC interno?
Un SOC interno requiere construir turnos 24×7, contratar analistas L1-L3, mantener herramientas y casos de uso, y gestionar la rotación. El MDR externaliza esa operación con un coste predecible y SLA contractual. Para muchas empresas medianas, el MDR llega a operación productiva en 4-8 semanas, mientras que un SOC interno tarda 9-18 meses en madurar y exige inversión inicial alta.
¿Cuál es la diferencia entre MDR y MSSP?
Un MSSP (Managed Security Service Provider) es el paraguas amplio: gestiona SOC, MDR, vulnerabilidades, CTI y respuesta. Un MDR específicamente se centra en detección y respuesta con SLAs de contención. Muchos MSSP enterprise incluyen MDR dentro de su catálogo. La diferencia real está en el contrato: ¿el proveedor solo alerta o también contiene?
¿Necesito tener EDR antes de contratar MDR?
Lo habitual es sí. La mayoría de proveedores MDR exigen tecnología base de detección (EDR, XDR, SIEM) sobre la que operar. Algunos MDR enterprise incluyen el despliegue de su propio EDR como parte del contrato. Si tu organización no tiene EDR aún, el MDR puede aportarlo y dejar la operación lista en pocas semanas.
¿Qué SLAs son razonables en un contrato MDR?
Para alertas críticas, tiempo de detección ≤ 15 minutos y notificación al cliente del incidente confirmado ≤ 1 hora. Para alta severidad, ≤ 30 minutos de detección y ≤ 2 horas de notificación. El tiempo de contención varía según el alcance, pero un MDR serio comprometerá aislamiento del endpoint en ≤ 30 minutos. Si el proveedor no firma SLAs específicos, sospecha.
¿Sirve un MDR como evidencia para NIS2 o DORA?
Sí, es una de sus aportaciones más valiosas. NIS2 (artículo 21.2) y DORA (artículos 9-10) exigen capacidad real de gestión de incidentes y notificación en plazo. Un MDR documentado produce registros trazables de detección, contención, comunicaciones y lecciones aprendidas, justo el tipo de evidencia continua que el auditor o supervisor espera ver.