Qué es un MDR (Managed Detection and Response): qué incluye y diferencias con SOC, MSSP y EDR

Un MDR (Managed Detection and Response) es un servicio externalizado en el que un proveedor especializado se encarga 24/7 de detectar, investigar y contener amenazas en la infraestructura del cliente, combinando tecnología (EDR, SIEM, XDR), analistas de seguridad y procesos de respuesta a incidentes. Es la forma en que muchas empresas medianas obtienen capacidad real de SOC sin construir uno desde cero, y la categoría que más ha crecido en ciberseguridad gestionada los últimos años.

Esta guía explica qué es un MDR, qué incluye exactamente un servicio MDR maduro, en qué se diferencia de un SOC interno, de un MSSP, de un EDR y de un XDR, qué tipos de empresa lo necesitan de verdad y cómo encaja con NIS2 y DORA.

Qué es un MDR

Un MDR es un servicio gestionado que combina herramientas de detección (EDR/XDR), monitorización 24/7, analistas de SOC, threat hunting y respuesta a incidentes en un único contrato. El proveedor despliega o se conecta a la tecnología del cliente, recibe la telemetría, detecta amenazas, investiga las alertas y ejecuta respuesta inicial (aislar endpoint, bloquear IoC, escalar a IR).

Lo que aporta operativamente:

• Detección continua sin que el cliente tenga que montar y mantener un SOC propio.
• Reducción del MTTD/MTTR (mean time to detect / respond) gracias al equipo dedicado.
• Threat hunting proactivo, no sólo reactivo a alertas.
• Respuesta inicial automatizada o asistida (aislar host, matar procesos, contener movimiento lateral) sin esperar al equipo del cliente.
• Reporting periódico para compliance y dirección.

Lo que no es un MDR: ni un IT support, ni una consultoría, ni reemplaza al equipo de TI/seguridad del cliente. El MDR detecta y contiene; la remediación profunda (parcheo, cambios de configuración, decisiones organizativas) sigue requiriendo al cliente.

Qué incluye un servicio MDR maduro

Un servicio MDR serio cubre, como mínimo, estos seis bloques:

1. Despliegue y operación de tecnología de detección. Normalmente un EDR del propio proveedor o uno que el cliente ya tenga (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Bitdefender), complementado con telemetría de red, identidad y cloud. Más detalle en la guía de qué es un EDR.
2. Monitorización 24/7 por analistas humanos. Turnos cubriendo todas las franjas, no sólo automatización. Los proveedores serios publican el SLA de tiempo medio de respuesta a alertas críticas (suele estar entre 5 y 15 minutos).
3. Triage e investigación. Cada alerta entra en una cola, se contextualiza con telemetría histórica y se decide si es benigna, sospechosa o confirmada. Lo que escala al cliente ya viene investigado.
4. Threat hunting proactivo. Búsqueda periódica de patrones de TTPs (técnicas del MITRE ATT&CK) en la telemetría almacenada, incluso en ausencia de alertas. Es la diferencia entre un MDR maduro y un servicio de "vigilancia de alertas". Más sobre la disciplina en la guía de threat hunting.
5. Respuesta automatizada o asistida. Acciones predefinidas (aislar host, matar proceso, bloquear hash, expulsar sesión) que el proveedor ejecuta directamente o con autorización del cliente.
6. Reporting y comunicación. Informe mensual o trimestral de actividad, alertas escaladas, KPIs (MTTD, MTTR, número de incidentes por categoría), recomendaciones derivadas.

Los proveedores top añaden además: forense post-incidente, integración con SOAR, respuesta a incidentes (IR retainer), asesoramiento estratégico y, en algunos casos, garantías financieras (warranty) en caso de breach.

Cómo funciona el flujo operativo

El día a día de un MDR sigue siempre los mismos pasos:

1. Telemetría. Los agentes EDR, los logs de red, los eventos de identidad (Active Directory, Entra ID, Okta) y la telemetría cloud (CloudTrail, Azure activity logs, GCP audit logs) se envían a la plataforma del proveedor.
2. Detección. Reglas, modelos ML y firmas mapean cada evento a técnicas conocidas. La plataforma agrupa eventos relacionados en incidents.
3. Triage por L1/L2. El analista valida si el incidente es real, descarta falsos positivos, enriquece con context (¿es este host crítico? ¿hay movimiento lateral?).
4. Contención. Si se confirma actividad maliciosa, el analista ejecuta acciones de respuesta o pide autorización al cliente.
5. Comunicación. Llamada o ticket al cliente con resumen ejecutable: qué ha pasado, qué se ha contenido, qué acciones quedan.
6. Hunting periódico. Fuera del flujo de alerta, el equipo lanza queries proactivas buscando TTPs específicos según threat intelligence reciente.
7. Reporting. Informe consolidado con la actividad del periodo.

La promesa central del MDR es que el cliente recibe pocos correos, casi todos accionables, en lugar de miles de alertas crudas que tendría que filtrar internamente.

MDR, SOC interno, MSSP, EDR, XDR y SIEMaaS

Categoría con muchos solapes. Diferencias prácticas:

SOC interno

• Qué cubre: equipo propio más tecnología propia, en 8x5 o 24x7.
• Diferencia clave con MDR: construido y operado por el cliente. Mayor coste fijo y máximo control.

MSSP (Managed Security Service Provider)

• Qué cubre: operación de firewalls, IDS, antivirus, parcheo y cumplimiento.
• Diferencia clave con MDR: mucho más amplio en tecnología, menos profundo en detección y respuesta.

EDR managed

• Qué cubre: sólo el agente de endpoint y su consola.
• Diferencia clave con MDR: el MDR usa el EDR como una de sus fuentes; el EDR managed se queda en el endpoint.

XDR (Extended Detection and Response)

• Qué cubre: plataforma que correlaciona endpoint, red, identidad y cloud.
• Diferencia clave con MDR: el XDR es la tecnología; el MDR es el servicio que la opera.

SIEM as a service

• Qué cubre: plataforma SIEM gestionada (ingesta, queries, alertas).
• Diferencia clave con MDR: el SIEMaaS entrega plataforma; el MDR entrega además analistas y respuesta.

MDR

• Qué cubre: EDR o XDR más analistas 24/7, threat hunting y respuesta inicial a incidentes.
• Diferencia clave: categoría que une tecnología y operación humana en un solo contrato.

Para una empresa que dispone ya de un SIEM y un SOC maduros, el MDR puede ser redundante. Para una empresa sin SOC, el MDR es probablemente la forma más eficiente de obtener detección 24/7.

Cuándo tiene sentido un MDR

No todas las empresas necesitan MDR. Las señales que indican que sí:

• No hay SOC interno y construirlo costaría más que externalizarlo.
• El equipo de IT/seguridad no cubre 24/7. Un atacante actúa muchas veces fuera de horario laboral, y aquí es donde el MDR aporta diferencia clara.
• Hay obligación regulatoria de monitorización continua (NIS2, DORA, ENS Alta).
• El stack es heterogéneo (cloud múltiple, endpoints variados, identidad federada) y unificar la detección internamente sería caro.
• Crece la superficie de ataque más rápido que el equipo. Empresas en crecimiento que multiplican empleados, dispositivos y aplicaciones cloud sin ampliar seguridad al mismo ritmo.

Las señales contrarias:

• Empresa muy pequeña sin activos críticos ni regulación, con superficie limitada. Un EDR estándar bien configurado puede bastar.
• Empresa con SOC interno maduro y equipo dedicado. El MDR pasa a ser un complemento concreto (servicios gestionados de hunting o IR), no un servicio principal.
• Sector con requisito explícito de SOC interno (ciertas entidades financieras, infraestructura crítica nacional) donde la externalización está limitada.

Proveedores principales en el mercado

Los nombres que aparecen con más frecuencia:

• CrowdStrike Falcon Complete. MDR construido sobre Falcon EDR. Top de mercado en detección y respuesta.
• SentinelOne Vigilance / Vigilance Respond. MDR sobre el EDR Singularity, con énfasis en automatización.
• Sophos MDR. Apoyado en Sophos Intercept X. Buena adopción en pyme y mid-market.
• Microsoft Defender Experts for XDR. MDR de Microsoft sobre Defender XDR. Razonable si todo el stack ya es Microsoft.
• Arctic Wolf. Operación tipo "concierge", multi-vendor en EDR.
• Red Canary. Especialista histórico en detección, integra con varios EDR.
• Bitdefender MDR. Sobre GravityZone, fuerte presencia en Europa.
• eSentire. MDR enterprise con XDR propio (Atlas).
• Trustwave, Secureworks, Rapid7 MDR. Otras opciones consolidadas.

En el mercado español, además de los globales, operan proveedores locales con MDR ajustados a sectores regulados (banca, energía, sector público). La elección depende de cobertura horaria, idioma del SOC, tecnología subyacente, integración con el stack del cliente y experiencia en el sector.

MDR y compliance

Marcos donde el MDR aporta evidencia o cubre requisitos directamente:

• NIS2 (artículo 21). Pide medidas técnicas y organizativas de detección y respuesta a incidentes. El contrato MDR documenta capacidades 24/7, SLAs, procesos de notificación. La obligación de notificar incidentes en 24/72 horas se apoya operativamente en la capacidad de detección.
• DORA (artículo 17 y 28). Exige a entidades financieras procesos de detección, respuesta y reporting de incidentes ICT. La externalización a MDR debe cumplir las reglas del artículo 28 sobre proveedores ICT críticos (due diligence, contratos formales, monitorización del proveedor).
• ENS (RD 311/2022, op.exp.7 y op.mon.x). Sistema de detección, monitorización y registro de actividad. El MDR se encaja en el cuadro de medidas operativas.
• ISO 27001:2022 (controles 8.16, 5.24-5.26). Monitorización de actividad, gestión de incidentes, planificación de respuesta.
• PCI DSS v4.0 (req. 10 y 12.10). Logging y monitorización continua, plan de respuesta a incidentes.

Importante: externalizar a un MDR no exonera al cliente de la responsabilidad regulatoria. La debida diligencia sobre el proveedor, el contrato (SLAs, derechos de auditoría, ubicación de datos, notificación) y la supervisión del servicio siguen siendo del cliente.

Preguntas frecuentes

¿En qué se diferencia un MDR de un SOC?

El SOC es la función (equipo + tecnología + procesos para detectar y responder a incidentes). El MDR es una forma de consumir esa función como servicio externalizado. Una empresa puede tener SOC interno, contratar MDR, o combinar ambos (MDR fuera de horario, SOC interno en horario laboral).

¿Qué tamaño mínimo de empresa justifica un MDR?

No hay umbral fijo, pero suele ser razonable a partir de 100-150 empleados, o antes si hay obligaciones de NIS2/DORA, datos sensibles regulados (sanidad, financiero) o exposición alta (e-commerce, SaaS B2B). Por debajo, un EDR bien configurado más buena gestión de vulnerabilidades CVE puede ser suficiente.

¿Puede un MDR responder de forma autónoma sin autorización del cliente?

Depende del modelo contratado. La mayoría de MDR ofrecen dos modos: respuesta automatizada autorizada (acciones predefinidas como aislar un host se ejecutan sin pedir permiso para ganar tiempo) y respuesta supervisada (toda acción requiere visto bueno). El primer modo reduce drásticamente el MTTR; el segundo da máximo control. Para incidentes graves, lo habitual es haber pactado de antemano qué se puede hacer sin esperar.

¿El MDR cubre respuesta a incidentes (IR) completa?

Cubre la respuesta inicial: contención, aislamiento, investigación. Para un IR completo (forense detallado, comunicación con autoridades, recovery, lecciones aprendidas) suelen ofrecer un retainer adicional o derivar a un equipo IR especializado. Es importante revisar el contrato: muchos MDR cubren "X horas de IR incluido" y a partir de ahí facturan aparte.

¿Qué pasa con los datos del cliente en un MDR?

El proveedor procesa telemetría sensible (procesos, conexiones, identidades, ficheros). El contrato debe especificar ubicación de los datos (dentro de la UE para NIS2/DORA), retención, acceso por personal del proveedor, subcontratación y derechos del cliente sobre la información. Es un punto crítico para auditoría y para DPA en marco RGPD.

¿Un MDR sustituye a un pentesting?

No. El MDR detecta y responde a ataques en curso. El pentesting busca vulnerabilidades antes de que sean explotadas. Son controles complementarios: el pentesting reduce la superficie ofensiva, el MDR reacciona cuando algo se cuela. Empresas maduras combinan ambos.

Recursos relacionados

• Qué es un SOC: la función que el MDR proporciona como servicio.
• Qué es un SIEM: la tecnología de correlación que muchos MDR utilizan internamente.
• Qué es un EDR: la fuente principal de telemetría de un MDR moderno.
• Qué es threat hunting: la disciplina proactiva que un buen MDR debe aportar.
• Cómo cumplir NIS2 en España: el marco regulatorio que está acelerando la adopción de MDR en empresas medianas.
• DORA cumplimiento: requisitos específicos de detección y respuesta para entidades financieras.

MDR en Secra

En Secra ayudamos a empresas que están evaluando externalizar detección y respuesta o que ya tienen un MDR y quieren validar el servicio. El alcance habitual incluye análisis de la propuesta técnica del proveedor (cobertura real, telemetría incluida, SLAs), revisión de contratos desde la óptica NIS2/DORA, ejercicios de purple team para verificar capacidad de detección del MDR ante TTPs reales y propuesta de mejoras en el modelo operativo. Si quieres apoyo en la decisión o en la auditoría del servicio, escríbenos a través de contacto o consulta nuestros servicios gestionados.