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.
Un antes y un después
El caso típico: un SIEM recién instalado que en su primera semana escupe unas 4,000 alertas diarias, casi todas marcadas "alta" por defecto. El analista, humano, empieza a cerrarlas en lote sin leerlas —y ahí ya se perdió la batalla. La afinación no fue magia: se suprimieron falsos positivos conocidos (un escáner de vulnerabilidades interno que disparaba "actividad sospechosa" todas las noches), se reservó la severidad alta para lo que de verdad exige acción inmediata, y se sustituyeron decenas de reglas de evento único por unas pocas de correlación. El volumen bajó a 30-40 alertas diarias que un humano sí puede revisar. Lo importante no es el número final, sino el cambio de contrato: de "avísame de todo" a "avísame de lo que merece que actúe".
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.
Preguntas frecuentes
help ¿Qué es la fatiga de alertas?
Es el desgaste que sufre un equipo de seguridad cuando recibe tantas alertas —muchas irrelevantes o falsos positivos— que deja de prestarles atención. El riesgo real es que, entre el ruido, se pase por alto la alerta que sí correspondía a un incidente. Más alertas no significa más protección; a partir de cierto punto, significa menos.
help ¿Cómo se decide qué alerta merece respuesta inmediata?
Combinando severidad, contexto y correlación: no es lo mismo un intento fallido de login que una cadena de eventos (acceso inusual + escalamiento de privilegios + exfiltración). Se definen niveles (qué se registra, qué se revisa en horario y qué despierta a alguien), se suprime el ruido conocido y se correlacionan eventos para que la alerta llegue con contexto, no aislada.
help ¿Silenciar alertas no es peligroso?
Silenciar sin criterio, sí. Pero afinar —suprimir falsos positivos conocidos y agrupar eventos relacionados— no es callar señales, es hacer que las señales reales se vean. El trade-off se administra con revisión continua: se mide qué se silenció y por qué, y se ajusta. El objetivo es que cuando algo suene, alguien de verdad lo mire.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →