Tu SOC no necesita más alertas, necesita menos

La primera métrica que pedimos al revisar un SOC no es la cobertura de reglas ni el tiempo de retención. Es cuántas alertas llegan por turno y cuántas se cierran como falso positivo.

Cuando la segunda cifra pasa del 90%, el problema ya no es de detección. Es que el equipo aprendió a cerrar sin mirar, y esa costumbre no distingue entre una alerta inútil y una buena.

El costo real de una alerta ruidosa

No es el minuto que toma cerrarla. Es que degrada la confianza en todo el resto. Un analista que descartó doscientas alertas idénticas esta semana va a descartar la doscientos uno sin leerla, y va a tener razón el 99,5% de las veces.

Una regla que genera falsos positivos no es una red de seguridad. Es entrenamiento para ignorar.

Qué hacemos primero

Antes de escribir una sola regla nueva, medimos:

• + Volumen por regla, ordenado de mayor a menor. Casi siempre el 80% del ruido sale de menos de diez reglas.
• + Tasa de cierre como falso positivo por regla, no agregada.
• + Tiempo desde que la alerta aparece hasta que alguien la toca de verdad.

Con eso en la mano, la conversación cambia: deja de ser «necesitamos más visibilidad» y pasa a ser «estas siete reglas hay que afinarlas o apagarlas».

Afinar no es apagar

La tentación es silenciar. Pero una regla apagada sin registro es una brecha de cobertura que nadie recuerda. Cada supresión debería quedar escrita: qué se suprime, por qué, quién lo aprobó y cuándo se revisa.

# Ejemplo de supresión documentada
supresion:
  regla: 5710              # sshd: intento de autenticación fallido
  alcance: 10.20.0.0/24    # solo el rango de escáneres internos
  motivo: "Escaneo autorizado semanal — ticket OPS-4412"
  aprobado_por: "jefatura-infra"
  revisar: 2026-12-01

¿Quieres que miremos tus números? Conversemos.