Métricas de SOC: los indicadores que realmente mejoran la detección y respuesta

¿Cuál es el objetivo de la medición?

Antes de elegir un KPI, defina una decisión. Si la métrica sube o baja, ¿qué hará? Un tiempo de Triage alto puede justificar un cambio de cola, automatización o formación. Una tasa alta de falsos positivos justifica el ajuste. La falta de logs de un activo crítico requiere el tratamiento del Data Pipeline.

Separe entre Volumen, Eficiencia, Calidad, Cobertura y Resultado. El volumen describe cuánto trabajo entró; la eficiencia, cuánto tiempo y recursos se necesitaron; la calidad, si las decisiones fueron correctas; la cobertura, qué se puede detectar; el resultado, si se detuvo un ataque y si se repite.

Para cada métrica, defina un Propietario, una fuente de datos, una fórmula, una frecuencia, segmentaciones y límites de uso. Sin un diccionario de datos, dos gerentes pueden calcular “MTTR” de manera diferente.

Métricas de tiempo

Mean Time to Triage mide el tiempo desde la creación de un incidente hasta un contacto analítico significativo o el primer cambio, según la definición. Time to Assign mide el tiempo hasta el Propietario. Time to Contain mide el tiempo hasta una acción que detiene la propagación. Time to Close mide hasta el cierre administrativo. Estos son puntos diferentes y no deben confundirse.

MTTD — Mean Time to Detect — es más difícil de medir porque el tiempo de inicio del ataque no siempre se conoce. Se puede usar First Activity Time versus Created Time, pero hay que tener en cuenta que es una aproximación. MTTR es un término ambiguo: Respond, Remediate, Recover o Resolve. Escriba la palabra completa en cada informe.

Filtre por Severidad, tipo de Use Case, fuente de Detección, horas de trabajo, Propietario y activo. Un promedio general oculta incidentes de Alta lentitud dentro de un gran volumen de Bajas rápidas.

¿Por qué son importantes los percentiles?

El promedio se ve afectado por eventos atípicos. Si nueve incidentes se cerraron en una hora y uno después de cien horas, el promedio será de 10.9 horas, un dato que no describe la mayoría de los casos ni la cola. La mediana (P50) describe el caso intermedio; P90 muestra el tiempo por debajo del cual se cerraron el 90% de los casos.

Microsoft muestra ejemplos de KQL para calcular los percentiles de Time to Triage y Time to Closure de SecurityIncident. Para el equipo, se recomienda seguir al menos P50 y P90, e investigar el P90: ¿Se trata de una aprobación de TI, falta de Propietario, Data Gap o un proceso manual?

No compare percentiles entre períodos si la definición de CreatedTime, FirstModifiedTime o ClosedTime ha cambiado. Documente los cambios en el sistema y el Workflow.

Métricas de calidad de detección

La tasa de falsos positivos por sí sola no es suficiente, ya que un Benign Positive puede ser una detección correcta de una actividad autorizada. Es preferible clasificar: True Positive, Benign Positive, False Positive, Undetermined y Duplicate. Analice por Rule y no solo a nivel de SOC.

Mida también la Actionability: ¿En qué porcentaje de las Alerts existen Context y Entities que permiten la investigación? ¿Cuántos Tickets se cerraron sin pruebas? ¿Cuántos Incidents se reabrieron? ¿Cuántas escalaciones se devolvieron para completarlas? Estas métricas reflejan la calidad operativa.

Para Detection Engineering, añada Precision y Coverage cuando sea posible, pero tenga cuidado de calcular Recall sin Ground Truth. Purple Team, Simulation y pruebas Atómicas pueden proporcionar una verificación controlada de los Use Cases.

Métricas de cobertura y visibilidad

El SOC no puede detectar lo que no se recopila. Mida el porcentaje de activos críticos que envían logs, Freshness, volumen anómalo, fallos de Parsing, campos faltantes, Retention y Clock Sync. La disponibilidad de la fuente de datos debe ser un KPI operativo, no solo un problema de infraestructura.

Construya un Mapa de Cobertura frente a los Use Cases y MITRE ATT&CK: qué técnicas son relevantes para la organización, qué Data Sources son necesarios, qué Rules existen y cuándo se probaron. El número de técnicas “cubiertas” no es una prueba de calidad, pero ayuda a identificar brechas.

Mida también la Detection Debt: Rules sin Propietario, sin Test, sin documentación, sin Review o con Data Source modificado. Esta deuda aumenta el riesgo incluso si el panel muestra Alerts.

Métricas de carga y proceso

Haga un seguimiento del Backlog, Aging, Alerts por Analista, Incidents sin Propietario, tiempo de espera para equipos externos, tasa de Reasignación y horas de guardia. Una carga alta no es necesariamente un problema de personal; podría ser una Rule ruidosa o un Workflow innecesario.

No califique a los analistas por el número de Tickets cerrados. Esa métrica fomenta la elección de casos fáciles y el cierre rápido. Es preferible usar métricas grupales y combinar la revisión de la calidad, la complejidad, la documentación, la contribución al Tuning y la capacidad de identificar el Scope.

Mida la Estandarización: porcentaje de Incidents en los que se completaron las Tareas requeridas, se activó el Playbook, la Clasificación incluyó una justificación y se escribió la Línea de Tiempo. El objetivo no es crear un formulario, sino asegurar un mínimo profesional.

Métricas de impacto y mejora

El resultado importante es la reducción del impacto y la recurrencia. Mida el Time to Contain en eventos verificados, el número de activos afectados antes y después de la Detección, los eventos recurrentes de la misma Root Cause, las Recomendaciones implementadas y el tiempo para cerrar una brecha de Logging o Control.

La Revisión Post-Incidente debe generar Acciones medibles: nueva Rule, cambio de Política, formación, etiquetado de Activos o mejora de la copia de seguridad. Siga el porcentaje de Acciones completadas y verifique si el evento se repitió.

Se deben presentar a la dirección métricas conectadas con el riesgo: tiempo sin visibilidad en activos críticos, eventos Privileged, impacto del servicio y tiempo de recuperación, no solo el volumen de Alerts.

Scorecard mensual para un pequeño equipo SOC

Cómo evitar el Gaming

Para cada KPI, defina un Anti-Métrico. Si se mide el tiempo de cierre, verifique la tasa de reapertura y la calidad de la clasificación. Si se miden menos alertas, verifique la cobertura y las pruebas de detección. Si se miden menos falsos positivos, verifique que no se hayan producido detecciones perdidas.

Muestre tendencias y no un “puntaje único”. Un cambio grande requiere verificar la calidad de los datos: ¿La fuente dejó de enviar? ¿Cambió el Workflow? ¿Las actualizaciones de incidentes crean duplicados en la tabla? Microsoft advierte que cada Update de un Incident crea un nuevo registro en SecurityIncident, por lo que las Queries deben seleccionar el último registro.

Realice una revisión mensual en la que los analistas expliquen lo que las métricas no muestran. Una medición saludable genera preguntas, no solo un color verde.

Lista de verificación práctica

• ✓Para cada KPI existe una decisión que se supone que debe mejorar.
• ✓La fórmula y la fuente de datos están documentadas.
• ✓Uso P50/P90 y no solo la media.
• ✓MTTR está definido con la palabra completa.
• ✓Las métricas están segmentadas por Severidad y Use Case.
• ✓Las métricas de calidad y cobertura equilibran las métricas de velocidad.
• ✓Existe un Anti-Métrico para evitar el Gaming.
• ✓La calidad de los datos se verifica antes de las conclusiones.
• ✓El equipo realiza la revisión y genera acciones.

Errores comunes

• Medir solo el número de Alerts y Tickets.
• Comparar períodos con definiciones diferentes.
• Clasificar a los analistas por cantidad de cierres.
• Presentar el Promedio sin Percentiles.
• Ignorar incidentes sin Propietario y el Backlog.
• Reducir el ruido desactivando la Detección sin verificar la Cobertura.
• Mostrar un KPI verde cuando la fuente de logs dejó de enviar.

Resumen y CTA

Elija un mes y cree un Scorecard pequeño con P50/P90 Triage, Clasificación por Rule, disponibilidad de logs, Backlog y Time to Contain. Junto a cada métrica, escriba qué decisión se supone que debe generar. En el curso Cybersecurity & AI de HPI se practica la investigación y el SIEM, una base que permite comprender el significado detrás de las métricas y no solo mostrar un Dashboard.

Preguntas frecuentes