Medir la eficacia de un SOC no consiste en contar cuántas alertas recibe o cuántos incidentes cierra un equipo. Un Security Operations Center debe evaluarse por su capacidad para detectar señales relevantes, investigar con contexto, responder dentro de los tiempos adecuados y convertir cada incidente en una mejora operativa.
En 2026, los cuadros de mando de operaciones de seguridad incorporan cada vez más indicadores de detección, triaje, resolución, carga de trabajo y calidad de las alertas. Microsoft, por ejemplo, documenta métricas de incidentes como el tiempo medio de triaje y el tiempo medio de resolución, mientras que el CCN-CERT ha advertido recientemente de que acumular métricas no equivale necesariamente a disponer de información útil para mejorar un SOC.
Qué significa realmente medir la eficacia de un SOC
La eficacia de un SOC debe entenderse como la relación entre su capacidad operativa y el riesgo que consigue gestionar. Un SOC puede cerrar miles de tickets y, aun así, tener problemas graves si tarda demasiado en detectar ataques relevantes, genera demasiado ruido o carece de visibilidad sobre activos críticos.
Por eso conviene separar tres conceptos:
- Eficacia: capacidad para detectar, investigar, contener y resolver amenazas reales.
- Eficiencia: recursos, tiempo y esfuerzo necesarios para conseguir esos resultados.
- Resiliencia: capacidad de aprender de los incidentes y mejorar las defensas después de cada ciclo.
Un buen sistema de medición conecta estos tres niveles. No basta con saber que un incidente fue cerrado; hay que conocer cuánto tardó en detectarse, cuánto tiempo permaneció sin asignar, qué parte de la investigación fue manual, si hubo falsos positivos, qué activos estuvieron afectados y qué cambio se introdujo después para reducir la probabilidad de repetición.
1. MTTD: cuánto tarda el SOC en detectar una amenaza
El MTTD (Mean Time to Detect) mide el tiempo transcurrido entre la aparición de un evento de seguridad y su detección por el sistema o el equipo. Es uno de los indicadores básicos para conocer la capacidad de detección.
La fórmula conceptual es sencilla:
MTTD = tiempo total desde el evento hasta la detección / número de incidentes analizados
Sin embargo, el promedio puede ocultar valores extremos. Por eso es recomendable analizar también la mediana y percentiles como P90 o P95. Microsoft utiliza precisamente análisis por percentiles para estudiar tiempos de triaje y cierre en operaciones de seguridad.
Un SOC debería segmentar el MTTD por tipo de incidente, severidad, fuente de telemetría, activo afectado y técnica observada. El tiempo de detección de una alerta de phishing no necesariamente debe compararse con el de una intrusión contra una cuenta privilegiada.
2. MTTA: el tiempo hasta que alguien se hace cargo
El MTTA (Mean Time to Acknowledge) mide el intervalo entre la generación o detección de una alerta y el momento en que un analista la reconoce o asume su gestión.
Este indicador ayuda a encontrar cuellos de botella que no aparecen en el MTTD. Un SOC puede tener buenas capacidades de detección y, sin embargo, tardar demasiado en asignar las alertas importantes debido a una mala distribución de turnos, exceso de ruido o reglas de escalado poco claras.
Conviene medir el MTTA por horario, severidad, equipo y canal de entrada. Si las alertas críticas permanecen sin asignar durante periodos prolongados, el problema puede estar en el proceso operativo y no en la tecnología de detección.
3. MTTR: cuánto tarda la respuesta
El MTTR (Mean Time to Respond o Remediate, según la metodología utilizada) debe definirse con precisión antes de incorporarlo al cuadro de mando. En un SOC puede utilizarse para medir desde la detección hasta la primera acción de respuesta o desde la detección hasta la remediación completa.
Por eso una organización debe documentar exactamente qué marcas de tiempo intervienen. Microsoft distingue diferentes etapas de la respuesta y sus herramientas permiten estudiar el tiempo de triaje y el tiempo de resolución. La clave es no mezclar indicadores que empiezan y terminan en momentos diferentes.
Para tener una visión útil, un SOC puede registrar al menos:
- Tiempo hasta el reconocimiento.
- Tiempo hasta la asignación.
- Tiempo hasta la primera acción.
- Tiempo hasta la contención.
- Tiempo hasta la erradicación.
- Tiempo hasta la recuperación.
- Tiempo total hasta el cierre.
4. Porcentaje de falsos positivos
El volumen de alertas no dice por sí solo si un SOC está funcionando bien. Si una parte elevada de las alertas termina clasificada como falsa positiva, los analistas pueden dedicar una cantidad considerable de tiempo a investigar señales que no representan una amenaza.
El porcentaje puede calcularse como:
Falsos positivos (%) = alertas clasificadas como falsas positivas / alertas investigadas × 100
Este indicador debe analizarse por regla de detección. Un promedio global puede esconder una regla concreta que genera miles de eventos irrelevantes.
La solución tampoco consiste necesariamente en reducir el número de alertas. Una regla puede ser ruidosa porque está mal diseñada, porque falta contexto o porque el entorno ha cambiado. La corrección adecuada puede ser ajustar el umbral, añadir enriquecimiento, incorporar listas de permitidos o modificar el caso de uso.
5. Precisión de las detecciones y cobertura
Un SOC eficaz necesita medir qué amenazas importantes puede detectar y con qué calidad. Aquí conviene relacionar las reglas de detección con los riesgos y técnicas que realmente afectan a la organización.
La cobertura puede estudiarse mediante marcos como MITRE ATT&CK, pero no debería convertirse en una simple colección de casillas marcadas. Tener una regla asociada a una técnica no demuestra que la organización pueda detectarla en todos los escenarios relevantes.
Es más útil preguntar:
- ¿Qué activos críticos están cubiertos?
- ¿Qué fuentes de telemetría alimentan cada detección?
- ¿Qué técnicas relevantes carecen de visibilidad?
- ¿Qué detecciones han sido validadas mediante pruebas?
- ¿Cuánto tiempo lleva sin revisarse cada regla?
Google Security Operations y otras plataformas modernas ofrecen cuadros de mando para analizar señales, detecciones, telemetría y actividad del SOC, precisamente porque la medición necesita conectar los datos técnicos con la operación.
6. Tiempo de triaje y tiempo de cierre
El tiempo de triaje mide cuánto tarda el equipo en clasificar una alerta o incidente y decidir qué tratamiento necesita. Es especialmente útil en entornos con grandes volúmenes de señales.
Microsoft Sentinel incluye métricas de tiempo medio de triaje, tiempo medio de cierre y sus percentiles. Este enfoque permite identificar si el problema está en unos pocos casos extremadamente lentos o si todo el proceso se ha desplazado hacia tiempos más altos.
El análisis por percentiles es especialmente importante. Una mediana de 20 minutos puede parecer estable aunque el 10% de los incidentes tarde varias horas. Para gestión operativa, esa cola lenta puede ser precisamente la que más atención necesita.
7. Carga de trabajo por analista
La productividad de un SOC no debería medirse como una competición por cerrar el mayor número de tickets. Es preferible observar la carga y complejidad de los casos.
Algunos indicadores útiles son:
- Incidentes por analista y periodo.
- Horas de analista por incidente.
- Incidentes críticos por analista.
- Porcentaje de escalados entre niveles.
- Tiempo dedicado a tareas manuales repetitivas.
- Casos pendientes al final de cada turno.
Microsoft identifica las horas de analista por incidente e incidentes por analista como indicadores útiles para estudiar operaciones de SOC. La interpretación debe considerar siempre la complejidad: diez incidentes sencillos no equivalen a diez investigaciones forenses.
8. Automatización: medir qué trabajo realmente se ahorra
Cuando un SOC incorpora SOAR, automatizaciones o capacidades de IA, el KPI no debería ser simplemente el número de playbooks ejecutados. Lo importante es determinar qué parte del proceso se ha acelerado y si la automatización mantiene la calidad.
Por ejemplo, puede medirse:
- Porcentaje de alertas enriquecidas automáticamente.
- Tiempo ahorrado por automatización.
- Porcentaje de casos resueltos sin intervención manual.
- Acciones automáticas que requieren revisión posterior.
- Errores o excepciones producidos por los playbooks.
La automatización puede reducir tareas repetitivas como enriquecimiento, recopilación de contexto o notificaciones. IBM describe SOAR como una forma de integrar herramientas y automatizar tareas repetitivas dentro de los flujos de respuesta.
9. SLA y cumplimiento de tiempos
Un SOC necesita objetivos temporales asociados a la criticidad. No todos los incidentes deben tener el mismo tratamiento.
Un cuadro de mando puede mostrar el porcentaje de incidentes críticos atendidos dentro del SLA, el porcentaje de investigaciones que superan el tiempo objetivo y el número de incumplimientos por causa.
La causa es fundamental. Un SLA incumplido por falta de personal, por una fuente de logs caída, por una mala regla de asignación o por una investigación técnicamente compleja requiere acciones diferentes.
10. Cómo construir un cuadro de mando de SOC que sirva para tomar decisiones
Un dashboard eficaz debería comenzar con una pregunta empresarial o de riesgo y después seleccionar las métricas que permitan responderla. El CCN-CERT ha resumido esta idea al señalar que medir muchas cosas no significa necesariamente obtener información útil.
Una estructura práctica puede dividirse en cinco bloques:
- Detección: MTTD, cobertura, calidad de reglas y señales críticas.
- Triaje: MTTA, tiempo de triaje y volumen pendiente.
- Respuesta: MTTR, tiempo de contención y cumplimiento de SLA.
- Calidad: falsos positivos, reincidencias y precisión de detecciones.
- Operación: carga por analista, automatización y backlog.
La periodicidad también importa. Los indicadores operativos pueden revisarse diariamente, mientras que cobertura, calidad de detecciones y tendencias estratégicas suelen necesitar revisiones semanales o mensuales.
Qué errores evitar al medir la eficacia de un SOC
El primer error es convertir una métrica en un objetivo aislado. Si se exige únicamente cerrar más incidentes, puede aparecer un incentivo para cerrar casos rápidamente sin investigar suficientemente.
El segundo es comparar equipos sin normalizar la complejidad. El volumen de incidentes, el número de activos, el horario de cobertura y el nivel de automatización influyen en los resultados.
El tercero es usar únicamente promedios. La mediana y los percentiles ofrecen una visión más resistente a valores extremos.
El cuarto es medir actividad en lugar de resultados. Número de alertas, reglas creadas o tickets cerrados son datos operativos, pero no sustituyen a indicadores de detección, respuesta, calidad y reducción del riesgo.
Conclusión: la eficacia de un SOC se mide como un ciclo
La mejor forma de responder a cómo medir la eficacia de un SOC es pensar en un ciclo continuo: detectar, reconocer, investigar, contener, resolver y aprender. Cada fase debe tener indicadores claros y una relación explícita con una acción de mejora.
El objetivo final del cuadro de mando no es mostrar una pantalla llena de números. Es permitir que el responsable del SOC pueda responder preguntas concretas: dónde se está perdiendo tiempo, qué detecciones generan ruido, qué amenazas carecen de cobertura, qué tareas pueden automatizarse y qué cambios están mejorando realmente la operación.
Cuando las métricas se convierten en decisiones, el SOC deja de medirse por actividad y empieza a medirse por capacidad defensiva.
También puedes consultar más contenidos de ciberseguridad para ampliar esta metodología con otros aspectos de defensa y gestión del riesgo.
