Un SOC no debería evaluarse por la cantidad de alertas que procesa, sino por la calidad y velocidad con la que convierte señales de seguridad en decisiones. Para conseguirlo, las organizaciones necesitan un conjunto de métricas de SOC que permita observar detección, triaje, respuesta, calidad, carga de trabajo y mejora continua.
La tendencia actual es combinar indicadores clásicos como MTTD y MTTR con percentiles, cumplimiento de SLA, falsos positivos, cobertura de detecciones, esfuerzo de los analistas y resultados de automatización. Microsoft, Google Security Operations y otros fabricantes ya incorporan este enfoque en sus herramientas de operaciones de seguridad, mientras que el CCN-CERT ha señalado que el valor no está en acumular métricas, sino en utilizar las adecuadas para tomar decisiones.
Las métricas de SOC deben responder a cinco preguntas
Antes de crear un dashboard, conviene establecer qué necesita saber el responsable de seguridad. Un sistema de medición completo debería responder al menos a estas preguntas:
- ¿Detectamos las amenazas relevantes?
- ¿Cuánto tardamos en reconocerlas e investigarlas?
- ¿Cuánto tardamos en contener y resolver los incidentes?
- ¿La operación está generando demasiado ruido o trabajo manual?
- ¿Las mejoras introducidas están cambiando los resultados?
Estas preguntas permiten organizar los KPI en bloques y evitar un problema habitual: llenar el cuadro de mando con cifras que describen actividad pero no explican el rendimiento defensivo.
1. MTTD: Mean Time to Detect
El MTTD mide el tiempo desde que ocurre un evento relevante hasta que el SOC consigue detectarlo. Es un indicador central porque una amenaza no puede investigarse antes de que exista una señal que la haga visible.
Para que sea útil, debe segmentarse. El MTTD global puede combinar incidentes sencillos y ataques complejos, ocultando diferencias importantes. Una organización puede calcularlo por severidad, tipo de incidente, activo, fuente de logs o técnica de ataque.
También conviene guardar la distribución completa. La mediana indica el comportamiento central, mientras que P90 o P95 permiten observar la cola de incidentes que tarda más en detectarse.
2. MTTA: Mean Time to Acknowledge
El MTTA representa el tiempo que pasa desde la generación o detección de una alerta hasta que un analista la reconoce o se hace cargo de ella.
Esta métrica ayuda a diferenciar dos problemas: una detección lenta y una operación lenta. Si el sistema genera una alerta crítica inmediatamente pero nadie la revisa durante 40 minutos, mejorar la regla de detección no resolverá el cuello de botella.
El MTTA puede analizarse por turno, severidad, equipo, canal y día de la semana. Las diferencias entre franjas horarias pueden revelar problemas de cobertura o escalado.
3. Tiempo de triaje
El tiempo de triaje mide cuánto necesita el analista para decidir qué representa una alerta y qué tratamiento debe recibir. Es especialmente relevante en SOC con alto volumen.
Un tiempo de triaje elevado puede indicar falta de contexto, reglas demasiado genéricas, fuentes de inteligencia poco integradas o procesos manuales. Por eso no debería estudiarse solo como un KPI de velocidad: también es una pista sobre la calidad del flujo de investigación.
Microsoft Sentinel permite analizar tiempos de triaje por percentiles y por responsable, una práctica que ayuda a detectar tanto tendencias generales como casos atípicos.
4. MTTR: respuesta, contención y resolución
El término MTTR puede utilizarse con significados diferentes en función de la metodología. En un SOC debe definirse de forma explícita para saber si representa el tiempo hasta la primera acción de respuesta, la contención o la resolución completa.
La práctica más útil consiste en dividir el ciclo:
- Detección.
- Reconocimiento.
- Asignación.
- Investigación.
- Primera acción.
- Contención.
- Erradicación.
- Recuperación.
- Cierre.
De esta forma, una organización puede descubrir si la demora está en el análisis, en la autorización de acciones, en la coordinación con TI o en la recuperación del activo.
5. Porcentaje de falsos positivos
Un SOC puede recibir una enorme cantidad de alertas y seguir teniendo una visibilidad deficiente si una parte importante de las señales no son relevantes. El porcentaje de falsos positivos ayuda a cuantificar ese ruido.
Es recomendable analizarlo por regla de detección, producto, fuente de datos y tipo de alerta. Si una regla concreta genera una proporción anormal de falsos positivos, el equipo puede priorizar su ajuste.
La reducción del ruido no debe hacerse eliminando indiscriminadamente detecciones. El objetivo es aumentar la relación señal/ruido sin perder cobertura sobre amenazas importantes.
6. Precisión y fidelidad de las detecciones
Además del porcentaje de falsos positivos, el SOC puede estudiar la fidelidad de sus detecciones: qué proporción de las señales investigadas conduce a una actividad que requiere una acción de seguridad.
Este indicador es especialmente útil para priorizar ingeniería de detecciones. Una regla que genera pocas alertas pero casi siempre relevantes puede merecer un tratamiento diferente de otra que produce miles de señales y muy pocas investigaciones útiles.
El análisis debería combinar volumen, severidad, resultado de la investigación y esfuerzo requerido.
7. Cobertura de detección
La cobertura responde a una cuestión diferente: qué parte del entorno y de los escenarios de riesgo puede observar el SOC.
Un modelo práctico puede cruzar:
- Activos críticos.
- Fuentes de telemetría.
- Técnicas de ataque relevantes.
- Casos de uso de detección.
- Pruebas realizadas.
- Fecha de última revisión.
MITRE ATT&CK puede utilizarse como marco para organizar técnicas, pero la cobertura debe relacionarse con el contexto de cada organización. Una técnica marcada como cubierta no garantiza que exista una detección fiable en todos los sistemas donde podría aparecer.
8. Cumplimiento de SLA
El porcentaje de cumplimiento de SLA permite saber cuántos incidentes se gestionan dentro del tiempo acordado para cada nivel de criticidad.
Un dashboard puede mostrar el porcentaje de P1, P2, P3 y P4 atendidos a tiempo, junto con los incumplimientos y sus causas.
Este indicador es especialmente útil cuando el SOC trabaja con otras áreas. Si la investigación termina rápidamente pero la contención depende de un equipo externo, el SLA puede mostrar que el cuello de botella está fuera del SOC.
9. Backlog y antigüedad de incidentes
El número de casos abiertos es una métrica básica, pero debe complementarse con su antigüedad. Diez incidentes abiertos durante cinco minutos no representan la misma situación que diez incidentes abiertos durante varios días.
Por eso conviene medir:
- Incidentes abiertos.
- Incidentes sin asignar.
- Edad media.
- Edad de la alerta más antigua.
- Casos que superan el SLA.
- Backlog por severidad.
El análisis de la cola permite detectar acumulaciones antes de que se conviertan en un problema de servicio.
10. Horas de analista por incidente
Una métrica especialmente útil para gestión es el esfuerzo de analista por incidente. Dos organizaciones pueden tener el mismo MTTR y consumir cantidades muy diferentes de trabajo humano.
Registrar las horas invertidas permite detectar investigaciones que requieren demasiados pasos manuales, falta de integración entre herramientas o procesos que podrían convertirse en automatizaciones.
El indicador debe combinarse con complejidad y severidad. No es razonable comparar una investigación de ransomware con una alerta informativa de autenticación.
11. Eficacia de la automatización
La automatización debe medirse por el resultado que produce. Entre los indicadores posibles están el porcentaje de enriquecimientos automáticos, tiempo ahorrado, número de acciones ejecutadas por playbooks y porcentaje de casos que no requieren intervención manual.
También es importante medir excepciones y errores. Una automatización que reduce el tiempo de trabajo pero genera demasiados fallos puede trasladar el coste a otra fase del proceso.
Las plataformas SOAR están diseñadas precisamente para integrar herramientas y automatizar tareas repetitivas de los flujos de respuesta.
12. Reincidencia y mejora después del incidente
Un SOC maduro no termina su trabajo cuando cierra un incidente. Debe comprobar qué cambios se realizan después y si las mismas causas vuelven a aparecer.
Puede medirse el número de incidentes repetidos relacionados con una misma causa, el porcentaje de acciones correctivas completadas y el tiempo desde el cierre hasta la implantación de la mejora.
Este grupo de métricas conecta las operaciones diarias con la gestión del riesgo y la mejora continua.
Cómo crear un dashboard de métricas SOC
Un cuadro de mando útil puede estructurarse en cuatro niveles.
Nivel operativo
Alertas nuevas, incidentes abiertos, incidentes críticos, MTTA, tiempo de triaje y backlog.
Nivel de respuesta
MTTR, tiempo de contención, tiempo de resolución, SLA y escalados.
Nivel de calidad
Falsos positivos, fidelidad de detecciones, cobertura, reglas con mayor ruido y detecciones sin validar.
Nivel estratégico
Tendencias mensuales, esfuerzo por incidente, automatización, reincidencias y acciones correctivas.
Google Security Operations documenta dashboards específicos para visualizar señales, insights, actividad del SOC y KPIs. Sumo Logic también ofrece paneles de SOC con indicadores relacionados con detección, respuesta y remediación. El principio común es separar el volumen operativo de las métricas que ayudan a comprender el rendimiento.
Promedios frente a medianas y percentiles
Una de las mejoras más importantes que puede introducir un SOC es dejar de depender exclusivamente del promedio.
Supongamos que nueve incidentes se investigan en 10 minutos y uno tarda 10 horas. El promedio será muy superior al comportamiento de la mayoría de los casos. La mediana describirá mejor el centro de la distribución, mientras que P90 o P95 ayudarán a estudiar la cola lenta.
Por eso un dashboard puede mostrar MTTD, MTTA, triaje y cierre como mediana, P90 y P95. Microsoft Sentinel incluye precisamente vistas de percentiles para tiempos de triaje y cierre.
Qué métricas debería revisar un responsable del SOC cada semana
Una revisión semanal puede concentrarse en un conjunto reducido de indicadores:
- MTTD por severidad.
- MTTA de incidentes críticos.
- Mediana y P90 del tiempo de triaje.
- MTTR o tiempo de resolución por severidad.
- Porcentaje de falsos positivos.
- SLA incumplidos.
- Backlog y antigüedad.
- Horas de analista por incidente.
- Automatizaciones ejecutadas y tiempo ahorrado.
- Detecciones nuevas o ajustadas.
- Incidentes repetidos.
- Acciones correctivas pendientes.
El resto de métricas puede mantenerse disponible para investigación, pero no tiene por qué ocupar el mismo espacio en el panel ejecutivo.
La métrica más importante es la que desencadena una acción
Un KPI de SOC solo tiene valor si permite actuar. Si el MTTD aumenta, hay que investigar la cobertura, la telemetría o la lógica de detección. Si el triaje se ralentiza, hay que estudiar el contexto disponible y la carga de los analistas. Si suben los falsos positivos, conviene revisar las reglas. Si el MTTR crece, hay que localizar en qué fase se produce la demora.
Por eso la medición debe cerrar el círculo: dato → diagnóstico → acción → nueva medición.
Si quieres profundizar en el método completo, puedes consultar nuestra guía Cómo medir la eficacia de un SOC: métricas, KPIs y método paso a paso, que desarrolla el modelo de medición desde la detección hasta la mejora continua.
Conclusión
Las métricas de un SOC deben ofrecer una visión equilibrada entre velocidad, calidad, cobertura y esfuerzo. MTTD, MTTA y MTTR son fundamentales, pero no explican por sí solos la eficacia de las operaciones de seguridad. Deben acompañarse de falsos positivos, cobertura de detección, SLA, backlog, esfuerzo de analistas, automatización y reincidencia.
El resultado debe ser un cuadro de mando pequeño, consistente y accionable. Medir menos indicadores, pero conectarlos con decisiones concretas, suele proporcionar más información que acumular decenas de cifras sin contexto.
