01MDR, MSSP, SOC-as-a-Service: qué distingue a los términos
Managed Detection & Response designa funciones SOC prestadas en remoto y dirigidas por analistas: supervisión continua, investigación y contención activa de amenazas; así lo recogen también casas de analistas como Gartner en sus Market Guides. Los Managed Security Service Providers (MSSP) clásicos, en cambio, operan sobre todo infraestructura de seguridad, supervisan eventos y remiten las alertas al equipo interno; la respuesta propiamente dicha suele quedar en manos del cliente. «SOC-as-a-Service» se utiliza de forma poco homogénea en el mercado y suele referirse a un Security Operations Center externo por suscripción, con plataforma y personal incluidos; en la práctica se solapa en gran medida con el MDR. Lo decisivo, por tanto, no es la etiqueta, sino la capacidad garantizada por contrato: ¿quién detecta, quién investiga y quién está autorizado a intervenir?
02Componentes del servicio: monitorización, triaje, respuesta, threat hunting
El núcleo de todo servicio MDR es la supervisión 24/7 de la telemetría procedente de endpoints (EDR), identidades, red y nube, a menudo sobre un stack tecnológico predefinido por el proveedor. En el triaje, los analistas —apoyados por la automatización— separan los incidentes reales de los falsos positivos, priorizan según la gravedad y enriquecen las alertas con contexto y threat intelligence. La respuesta activa es lo que distingue al MDR de la mera generación de alertas: dentro del marco acordado, el proveedor puede contener las amenazas por sí mismo, por ejemplo aislando hosts comprometidos, bloqueando cuentas o finalizando procesos maliciosos. El threat hunting complementa la detección basada en alertas con la búsqueda, guiada por hipótesis, de actividad de atacantes que las reglas de detección existentes aún no cubren.
03MTTD, MTTR y qué dicen realmente estas métricas
El Mean Time to Detect (MTTD) mide el tiempo desde el inicio de una actividad de ataque hasta su detección; el Mean Time to Respond (MTTR), el tiempo hasta la respuesta o la contención; como complemento se utilizan el Mean Time to Acknowledge (MTTA) y el Mean Time to Contain (MTTC). Los valores solo resultan significativos por clase de gravedad y a lo largo del tiempo: las cifras promediadas sobre todos los incidentes ocultan valores atípicos y diferencias de prioridad. Importante para los contratos: un MTTD garantizado difícilmente puede prometerse con seriedad, porque el punto de inicio de un ataque es por naturaleza desconocido; por ello, los SLA suelen definir tiempos de reacción y de notificación a partir de la recepción de la alerta. Exija al proveedor métricas definidas con transparencia, que dejen claro cuándo arranca el reloj y cuándo se detiene.
04Onboarding: conexión de logs, casos de uso, runbooks
La calidad de un servicio MDR se decide en gran medida en el onboarding. Al principio está la conexión de las fuentes de telemetría y de logs, priorizadas según su valor de detección; típicamente servicios de identidad, endpoints, componentes de red y servicios en la nube. El estándar mínimo del BSI para el registro y la detección de ciberataques (versión 2.1, 2024) se dirige a la administración federal alemana, pero ofrece también a otras organizaciones una orientación fundada sobre qué eventos deberían registrarse. Sobre esa base se define un catálogo de casos de uso, con frecuencia estructurado según las tácticas y técnicas de MITRE ATT&CK, que se ajusta al entorno en una fase de tuning. Finalmente, los runbooks establecen para cada escenario quién puede hacer qué: qué medidas de contención ejecuta el proveedor de forma autónoma, cuándo se escala y quién debe estar localizable en el lado del cliente.
05Criterios de SLA y de selección
Los puntos centrales del SLA son los tiempos de reacción y de notificación por nivel de gravedad, la disponibilidad permanente, vías de escalado definidas y un sistema de informes con métricas trazables. Compruebe además el lugar de tratamiento de los datos y su encuadre en materia de protección de datos, la compatibilidad con su stack tecnológico existente y la portabilidad de los contenidos de detección, los datos de log y el historial de casos en caso de salida. Para las entidades dentro del ámbito de aplicación de NIS2 se añade el apoyo en las obligaciones de notificación: el artículo 23 de la Directiva (UE) 2022/2555 exige una alerta temprana en un plazo de 24 horas y una notificación en un plazo de 72 horas desde que se tiene conocimiento de un incidente de seguridad significativo, así como un informe final a más tardar un mes después de la notificación. El proveedor debe preparar sus hallazgos con la rapidez y la estructura necesarias para que esos plazos sean viables; la obligación de notificar sigue recayendo en la entidad afectada.
06Make or buy: SOC propio, MDR o modelo co-gestionado
Un SOC propio 24/7 exige un funcionamiento por turnos continuo, detection engineering permanente y formación constante: esfuerzos que, dada la escasez de especialistas, solo una parte de las organizaciones puede sostener de forma duradera. El MDR, en cambio, aporta un salto de madurez rápido con costes planificables, pero reduce el control directo sobre la lógica de detección y la priorización. Como vía intermedia se han consolidado los modelos co-gestionados, en los que la organización conserva la soberanía sobre el SIEM o la plataforma de datos y el proveedor aporta el análisis y la respuesta 24/7. Con independencia del modelo: NIST SP 800-61 Rev. 3 (2025) ancla la respuesta a incidentes como parte de la gestión global del riesgo cibernético; la gobernanza, la comunicación de crisis y la reanudación de la actividad siguen siendo tareas internas incluso con MDR.
