Hay una forma segura de que un incidente pase desapercibido: ahogarlo en diez mil alertas irrelevantes. No hace falta un atacante sofisticado; basta un SIEM mal afinado y un equipo agotado de mirar avisos que nunca eran nada. A eso se le llama fatiga de alertas, y es uno de los problemas más subestimados de la seguridad operativa.
Por qué más alertas es peor, no mejor
La intuición dice que mientras más vigiles y más te avise el sistema, más seguro estás. La realidad operativa es la contraria a partir de cierto punto. Cuando el 95% de las alertas no lleva a ninguna acción, el cerebro humano aprende a ignorarlas. Y el día que aparece la que sí importaba, llega al mismo buzón saturado que todas las demás. El ruido no solo molesta: entrena al equipo para no mirar.
De dónde sale el ruido
La fatiga casi nunca es culpa del analista. Suele venir de decisiones de configuración:
- Reglas de correlación mal afinadas que disparan con cualquier cosa.
- Todo marcado con severidad alta, así que nada es realmente prioritario.
- Falsos positivos conocidos que nadie suprimió.
- Alertas sin contexto: un evento aislado que no dice si es parte de algo mayor.
Cómo se decide qué merece despertar a alguien
La pregunta correcta no es "¿qué puedo alertar?", sino "¿qué merece que alguien actúe, y con qué urgencia?". Eso se resuelve por niveles: qué se registra para investigar después, qué se revisa en horario laboral, y qué de verdad despierta a alguien de madrugada. Un intento de login fallido no es lo mismo que una cadena —acceso inusual, luego escalamiento de privilegios, luego un volumen raro de datos saliendo—; esa correlación es la que convierte eventos sueltos en una señal accionable.
Encima de eso se suprime el ruido conocido y se enriquece cada alerta con contexto, para que quien la reciba pueda decidir en segundos, no reconstruir la historia desde cero.
El trade-off, dicho de frente
Afinar tiene un riesgo evidente: silenciar de más y perder una señal real. Por eso no es un ajuste que se hace una vez y se olvida —igual que los umbrales de monitoreo, se revisa con datos: qué se silenció, qué se escapó, qué llegó tarde. Es un equilibrio que se sostiene, no un interruptor.
El objetivo final es simple y exigente a la vez: que cuando algo suene, alguien lo mire de verdad —y sepa qué hacer, que es justo el terreno del runbook de respuesta. Diseñar y operar ese equilibrio es parte de nuestro NOC/SOC administrado.