Por qué se confunden los tres términos
EDR, XDR y MDR suenan a tres versiones del mismo producto. No lo son. Dos describen tecnología y uno describe personas. Los fabricantes aumentan la confusión al vender los tres bajo una misma marca. Así, una empresa puede creer que ha comprado detección y respuesta cuando ha comprado un software que detecta y nadie que responda.
La diferencia pesa sobre todo en las empresas que tienen que demostrar que su seguridad funciona. Un auditor de ISO 27001 o del ENS no pregunta qué siglas has comprado. Pregunta si se detecta la actividad sospechosa, si alguien la revisa y qué pasó después. Una herramienta puede responder a la primera pregunta. Solo un proceso con personas detrás responde a las otras dos.
También conviene separar los tres del antivirus tradicional. El antivirus compara los ficheros con firmas maliciosas conocidas y bloquea las coincidencias. Sigue siendo útil, pero los atacantes evitan cada vez más dejar malware reconocible. Usan herramientas legítimas de administración, credenciales robadas y scripts que se ejecutan en memoria. Para detectar eso hay que vigilar el comportamiento, y ahí empieza el EDR.
Qué hace un EDR y qué no puede ver
EDR significa detección y respuesta en endpoints (endpoint detection and response). Es un agente que se instala en portátiles, equipos de sobremesa y servidores, registra lo que ocurre en cada dispositivo y reacciona cuando esa actividad parece maliciosa.
Telemetría, detección por comportamiento y acciones de respuesta
El agente recoge telemetría de forma continua: procesos iniciados y sus procesos padre, líneas de comandos, cambios en ficheros, conexiones de red, cambios en el registro e inicios de sesión. Las reglas de detección y los modelos de comportamiento buscan patrones que las firmas no ven. Por ejemplo, un documento de ofimática que abre una consola de comandos, una herramienta que lee credenciales de la memoria o un proceso que cifra cientos de ficheros en pocos segundos.
Cuando detecta algo, el agente puede actuar. Las acciones habituales son:
- terminar un proceso;
- poner un fichero en cuarentena;
- aislar el equipo de la red manteniendo abierto el canal con la consola de seguridad;
- en algunos productos, revertir los cambios hechos por un ransomware.
La telemetría permite además a un analista reconstruir lo que pasó antes y después de la alerta, de modo que un aviso aislado se convierte en una investigación.
Los puntos ciegos
El EDR ve lo que ocurre en los dispositivos donde corre su agente, y solo ahí. Varias vías de ataque habituales quedan fuera de esa vista. Un atacante que entra en Microsoft 365 o Google Workspace con credenciales robadas nunca toca un equipo gestionado. Un correo de phishing que captura una contraseña con una página de inicio de sesión falsa no deja nada en el portátil. Los móviles personales, los equipos de colaboradores externos sin gestionar, los equipos de red y muchas aplicaciones SaaS no llevan agente.
Hay además un problema de cobertura que no tiene nada que ver con los atacantes. Los agentes se desinstalan, dejan de actualizarse o nunca llegan a desplegarse en el servidor que alguien montó el mes pasado. Una consola de EDR con 180 equipos en verde no dice nada de los veinte que deberían estar y no están. Cruzar la cobertura de agentes con el inventario de activos es de lo primero que conviene revisar, y de lo primero que pregunta un auditor.
Qué añade un XDR
XDR significa detección y respuesta extendidas (extended detection and response). Aplica el modelo del EDR a más fuentes: correo, identidad, red, cargas de trabajo en la nube y aplicaciones SaaS, además de los endpoints.
Correlación entre fuentes
El valor del XDR es la correlación. Cada fuente por separado genera alertas que parecen menores. Un usuario inicia sesión desde un país inusual. La misma cuenta crea una regla de reenvío de correo. Una hora después, el portátil de un compañero abre un adjunto de ese buzón y lanza un script. Por separado, cada evento podría pasar desapercibido. Unidos en un solo incidente, describen una cuenta comprometida que se extiende dentro de la empresa.
Las plataformas XDR también amplían las acciones de respuesta más allá del equipo: deshabilitar una cuenta, revocar las sesiones activas, borrar un correo malicioso de todos los buzones que lo recibieron o bloquear un dominio. Esa amplitud es lo que permite contener un ataque que pasa de la identidad al correo y del correo al endpoint.
XDR nativo y XDR abierto
Los productos se dividen, a grandes rasgos, en dos familias. El XDR nativo viene de un único fabricante y correlaciona sus propios sensores de endpoint, correo, identidad y nube, lo que facilita la integración pero te ata a un ecosistema. El XDR abierto ingiere datos de herramientas de fabricantes distintos, lo que encaja con empresas que ya tienen un entorno mixto pero exige más trabajo de ajuste.
Ninguno es mejor en abstracto. La elección depende de lo que ya tienes y de quién va a mantener las integraciones y las reglas de detección con el tiempo.
Dónde encaja un SIEM
Un SIEM (gestión de información y eventos de seguridad) recoge y almacena registros de casi cualquier fuente, los normaliza, aplica reglas de correlación y los conserva para la investigación y el cumplimiento. XDR y SIEM se solapan, y por eso los fabricantes los mezclan cada vez más, pero su centro de gravedad es distinto.
El XDR está pensado para detectar y responder rápido en las fuentes que integra a fondo. El SIEM está pensado para la amplitud y la conservación: registros de cortafuegos, de aplicaciones, de acceso a bases de datos, de auditoría en la nube y de sistemas propios, guardados durante meses y consultables. Muchas organizaciones usan los dos. El XDR detecta y responde en endpoints, correo e identidad, y el SIEM guarda el registro amplio del que dependen las auditorías, las investigaciones y las notificaciones de incidentes.
Qué es un MDR
MDR significa detección y respuesta gestionadas (managed detection and response). No es una categoría de producto en el mismo sentido que EDR o XDR. Es un servicio: un equipo de analistas que opera la tecnología de detección en tu nombre, vigila las alertas, las investiga y actúa.
Triaje, investigación, contención e informe
Un proveedor de MDR recibe las alertas que generan tus herramientas, un volumen que crece rápido en cuanto se conectan las fuentes de identidad, correo y nube además de los endpoints. Los analistas las clasifican para separar los falsos positivos de la actividad real e investigan las que importan con la telemetría. Después ejecutan las acciones de respuesta acordadas: aislar un equipo, deshabilitar una cuenta, bloquear una dirección. Por último, informan de qué pasó, qué hicieron y qué te queda por corregir.
Algunos proveedores aportan su propia tecnología; otros operan las herramientas que ya tienes. Los dos modelos funcionan. Lo que cambia es quién controla la configuración y de quién dependes si cambias de proveedor.
Qué preguntar a un proveedor
El contrato define qué significa MDR en la práctica, así que conviene leerlo con atención. Las preguntas que distinguen una oferta de otra son concretas:
- Horario de cobertura. ¿El servicio está atendido las 24 horas, en horario laboral o con un técnico de guardia fuera de él?
- Capacidad de respuesta. ¿Qué acciones pueden ejecutar los analistas sin consultarte y cuáles necesitan tu aprobación?
- Escalado. ¿En cuánto tiempo llega un incidente confirmado a una persona concreta de tu empresa, y por qué canal?
- Informes. ¿Qué recibes cada mes y sirve como evidencia de auditoría?
- Fuentes. ¿Qué fuentes de datos incluye el precio y cuáles se cobran aparte?
Dos ofertas pueden venderse como MDR y ser servicios muy distintos. Una vigila solo endpoints, en horario de oficina y sin autoridad para aislar un equipo. La otra cubre identidad y correo a todas horas y contiene un incidente a las tres de la madrugada.
La alerta que nadie lee
El fallo más frecuente en pequeñas y medianas empresas no es que falte una herramienta. Es una herramienta que funciona, genera la alerta correcta y la envía a un sitio donde nadie mira.
Una secuencia típica es esta:
- Un viernes por la tarde, el EDR detecta una herramienta de robo de credenciales en un portátil de finanzas. No aísla nada, porque el aislamiento automático se desactivó después de que una vez desconectara al director general en plena reunión.
- La alerta llega a un buzón compartido.
- Durante el fin de semana, el atacante usa las credenciales robadas para entrar en el correo, crea una regla de reenvío y envía a tres clientes facturas con los datos bancarios cambiados.
- El lunes por la mañana, alguien abre el buzón compartido, encuentra cuarenta alertas y empieza por la más reciente.
Todas las piezas de esa historia estaban presentes. El EDR detectó bien. Los registros existían. Faltaba una persona cuyo trabajo fuera leer la alerta en minutos, relacionarla con la actividad de identidad y deshabilitar la cuenta. Ese es el hueco que un MDR existe para cubrir, y el que examina un auditor cuando pregunta quién revisa las alertas y con qué rapidez.
El ejemplo no es un argumento a favor de un producto concreto. Es un argumento para decidir de forma explícita quién responde, en qué horario y con qué autoridad, y para dejar esa decisión por escrito. Si la respuesta es una persona interna, el plan tiene que cubrir vacaciones, bajas y noches. Si es un proveedor, tiene que decirlo el contrato. La página temática de SOC y monitorización reúne nuestros otros artículos sobre cómo operar la detección y la respuesta.
Qué esperan ISO 27001 y el ENS
Ningún marco menciona EDR, XDR ni MDR. Los dos describen resultados que estas herramientas y servicios ayudan a conseguir, y los dos esperan evidencias de que el resultado se alcanza en la práctica, no solo en el papel.
ISO 27001
El anexo A de ISO 27001 incluye varios controles que la monitorización cubre de forma directa:
- El control 8.7 exige protección frente a malware.
- El control 8.15 exige que se generen, almacenen, protejan y analicen registros de actividades, excepciones, fallos y otros eventos relevantes.
- El control 8.16 exige monitorizar redes, sistemas y aplicaciones en busca de comportamientos anómalos y tomar las medidas adecuadas para evaluar posibles incidentes.
- Los controles 5.25 y 5.26 exigen evaluar los eventos de seguridad y responder a los incidentes según procedimientos documentados.
Un EDR por sí solo cubre buena parte del 8.7 y una parte del 8.16. El resto depende de lo que pasa después de la alerta: quién la evalúa, cómo se registra la decisión y cómo se ejecuta la respuesta. Ahí es donde flaquean muchas empresas certificadas, porque el procedimiento existe como documento mientras las alertas se acumulan sin leer.
El ENS
El ENS, regulado por el Real Decreto 311/2022, es más concreto. Su artículo 10 convierte la vigilancia continua en un principio básico, para detectar actividades anómalas y responder a tiempo. El anexo II fija después las medidas:
- op.exp.6 exige protección frente a código dañino en todos los equipos (puestos de usuario, servidores y elementos perimetrales), y añade desde categoría MEDIA el escaneo periódico de todo el sistema.
- op.mon.1 exige herramientas de detección o prevención de intrusión en todas las categorías, con refuerzos en MEDIA y ALTA.
La medida op.mon.3, vigilancia, es donde más se separan las categorías:
- En todas, exige un sistema automático de recolección de eventos de seguridad.
- En MEDIA, añade la correlación de eventos y soluciones que determinen la superficie de exposición a vulnerabilidades y deficiencias de configuración.
- En ALTA, añade, entre otros refuerzos, sistemas de detección de amenazas avanzadas y comportamientos anómalos.
En la práctica, un sistema de categoría MEDIA necesita algo que correlacione eventos de varias fuentes, que es el trabajo de un SIEM o de una plataforma XDR, no de un agente de endpoint por sí solo. El CCN publica un mapeo entre ISO 27001 y el ENS que vincula el control 8.7 con op.exp.6.
Las evidencias que pide un auditor
Los auditores de los dos marcos piden cosas parecidas:
- una lista de equipos con el agente instalado, conciliada con el inventario de activos;
- la configuración de la detección y de la respuesta automática;
- una muestra de alertas con la hora en que se revisó cada una y la decisión tomada;
- el registro de incidentes que enlaza alertas, incidentes y acciones;
- la configuración de conservación de registros y la prueba de que están protegidos frente a manipulaciones;
- los informes del proveedor de MDR, si lo hay.
La pregunta de fondo es siempre si la monitorización descrita en las políticas ocurre de verdad. Nuestro artículo sobre qué evalúa una auditoría de certificación explica por qué un control documentado y un control que funciona se juzgan de forma distinta. En el caso del ENS, estas medidas tienen que seguir funcionando entre auditorías; mantener la certificación ENS repasa qué revisa el auditor de esos dos años.
Cómo elegir la capa adecuada para tu tamaño
No hay una combinación correcta para todas las empresas. Cuatro preguntas suelen resolverlo.
¿Cuántos equipos y de qué tipo? Una empresa con cuarenta portátiles y todo lo demás en SaaS necesita más cobertura de identidad y correo que de servidores. Una empresa con servidores propios e infraestructura de producción necesita EDR en esos servidores tanto como en los portátiles. La gestión de dispositivos también cuenta, porque un agente solo se puede desplegar y mantener sano en equipos gestionados. Nuestro artículo sobre qué puede ver tu empresa con un MDM cubre esa capa.
¿Cuánto del negocio está en la nube y en SaaS? Cuanta más actividad crítica pasa por Microsoft 365, Google Workspace, AWS, Azure o aplicaciones de negocio, más deja sin cubrir un enfoque solo de endpoints. Es también donde más aporta la correlación entre identidad, correo y nube.
¿Quién va a revisar las alertas? Suele ser la pregunta decisiva. Una empresa sin equipo de seguridad, o con una sola persona que además lleva sistemas, no puede leer alertas a todas horas. Comprar una plataforma XDR más potente sin nadie que la opere aumenta el número de alertas que nadie lee.
¿Qué exigen tus marcos? Un sistema ENS de categoría MEDIA necesita correlación de eventos, lo que apunta a una capa SIEM o XDR. ISO 27001 deja libre el método, pero espera monitorización de comportamientos anómalos y una respuesta documentada. Los cuestionarios de seguridad de los clientes también pueden preguntar directamente si los equipos tienen EDR y si las alertas se vigilan de forma continua, y la respuesta tiene que coincidir con lo que de verdad cubren el contrato o el equipo.
Cómo los combina Qalea
Qalea trata la monitorización como una capa que está debajo de todo el programa de seguridad, no como una compra aparte. El EDR funciona en los equipos de los empleados, un SIEM recoge y correlaciona los eventos de seguridad y un SOC revisa las alertas y responde.
Como en Qalea la monitorización y el cumplimiento funcionan juntos, lo que produce esa capa es la evidencia que necesitan los controles relacionados: la cobertura de agentes frente al inventario de equipos, las alertas revisadas, el registro de incidentes y los registros de monitorización para controles como el 8.16 de ISO 27001 y op.mon.3 del ENS. La idea es la misma con la que empezaba este artículo. La tecnología de detección es necesaria, pero lo que comprueba un auditor, un cliente o un atacante es si alguien actúa sobre ella. Una plataforma de cumplimiento sin seguridad operada no puede responder a esa pregunta.
