Qué mide de verdad un SOC 24/7 y cómo evaluar el tuyo
Los informes mensuales de un centro de operaciones suelen estar llenos de números grandes que no dicen nada. Estas son las pocas métricas que importan y las preguntas que deberías hacer en la próxima reunión.
El problema de los números grandes
Un informe típico de SOC abre con "12.4 millones de eventos procesados". Es un número impresionante y no significa nada: mide el volumen de la infraestructura, no la calidad de la vigilancia.
Lo mismo pasa con "3.200 alertas generadas". Puede indicar buena cobertura o puede indicar reglas mal ajustadas que están ahogando al analista. El número, solo, no distingue.
Las métricas que sí importan
Tiempo medio de detección
Cuánto pasa entre que algo ocurre y alguien lo nota. Es la métrica más honesta porque no se puede maquillar: o lo viste o no lo viste.
Ojo con cómo se calcula. Si el reloj arranca cuando la alerta llega al panel, estás midiendo la velocidad del analista, no la de la detección. Debe arrancar cuando ocurrió el evento.
Tiempo medio de respuesta
Del momento en que se confirma el incidente al momento en que está contenido. Aquí conviene separar dos cosas que suelen ir juntas en el informe: tiempo hasta la primera acción y tiempo hasta la contención completa. Un SOC puede reaccionar en minutos y tardar horas en contener si depende de que alguien de tu equipo apruebe cada paso.
Tasa de falsos positivos
Qué proporción de las alertas escaladas no era nada. Si es muy alta, tu equipo aprenderá a ignorarlas, y la alerta buena llegará al mismo lugar que las malas.
Si es cero, tampoco es buena señal: significa que las reglas están tan restringidas que probablemente se está escapando cosas.
Cobertura real
De todos tus sistemas, ¿cuántos están efectivamente monitorizados? No cuántos tienen agente instalado: cuántos envían datos utilizables ahora mismo.
Esta es la métrica que más sorpresas da. Un agente instalado hace ocho meses que dejó de reportar hace tres es un punto ciego con apariencia de cobertura.
Cinco preguntas para la próxima reunión
-
¿Cuál fue el último incidente real y cuánto tardamos en detectarlo? Si la respuesta es "no hemos tenido ninguno", pregunta cómo lo saben.
-
¿Cuántos sistemas dejaron de reportar este mes y durante cuánto tiempo? La respuesta honesta nunca es cero.
-
¿Qué pasa un domingo a las 3 de la mañana? Pide el nombre de quién responde, no el del turno.
-
¿Qué detectaríamos si un atacante entra con credenciales válidas? Es el escenario más común y el que menos alertas dispara, porque técnicamente no hay nada anómalo.
-
¿Cuándo fue el último simulacro y qué falló? Un SOC que nunca ha fallado un simulacro probablemente no ha hecho ninguno difícil.
Interno, externo o mixto
No hay una respuesta universal, pero sí un criterio útil:
Un equipo interno entiende tu negocio y sabe qué es raro para ti. Un servicio externo ve el mismo patrón de ataque en decenas de organizaciones y tiene la guardia continua que casi nadie puede sostener internamente.
El modelo que suele funcionar mejor combina ambos: vigilancia continua externa, criterio de negocio interno. Lo que rara vez funciona es externalizar la vigilancia y la decisión, porque las decisiones que importan durante un incidente son de negocio, no técnicas.
