Tuning en Wazuh: cuándo una alerta útil se convierte en ruido

Una alerta de Wazuh no nace siendo ruido. Se convierte en ruido. Y lo hace de forma gradual, mientras el equipo sigue mirando el dashboard con la misma expectativa del primer día. El problema no es que Wazuh alerte demasiado: es que la operación deja de distinguir qué alerta merece una acción y cuál solo ocupa espacio. Cuando esa distinción se pierde, el SIEM sigue funcionando técnicamente, pero la función de seguridad se degrada.

Este artículo no trata sobre qué es Wazuh ni sobre cómo adoptarlo. Trata sobre el momento en que una regla que alguna vez fue útil deja de aportar y empieza a consumir atención. Ese es el territorio del tuning de reglas y alertas: un trabajo de calibración continua, no una configuración única.

Qué implica el tuning de reglas y alertas en una operación real

En Wazuh, una alerta es el resultado de un evento que coincidió con una regla, superó un umbral y llegó al nivel configurado. El tuning actúa sobre esas tres capas: qué eventos se decodifican, qué reglas los evalúan y qué severidad se asigna. Ajustar una regla no es solo subir o bajar un umbral; es decidir qué comportamiento del entorno merece atención humana.

El síntoma típico de una operación sin tuning sostenido es conocido: cientos o miles de alertas diarias, la mayoría de nivel bajo o medio, con un porcentaje pequeño que realmente corresponde a algo accionable. El equipo empieza a filtrar mentalmente, luego a ignorar por costumbre, y termina revisando el dashboard solo cuando algo ya ocurrió. La alerta útil no desapareció: quedó sepultada.

Hay un matiz importante para gerentes TI: el ruido no es solo un problema de comodidad, es un problema de trazabilidad. Si no se puede reconstruir por qué una alerta se disparó, qué regla la generó y qué se hizo con ella, la capacidad de investigar un incidente se reduce. Y si además hay que prepararse para exigencias de trazabilidad —por ejemplo, en el contexto de la Ley 21.719—, un repositorio de alertas sin criterio de calibración es un pasivo, no un activo.

Cómo se degrada la señal: qué observar antes de tocar una regla

Antes de ajustar, conviene diagnosticar. Estas señales suelen indicar que el tuning está pendiente:

• Volumen desproporcionado por regla. Una o dos reglas concentran la mayor parte de las alertas. Si el top de reglas disparadas coincide con las de menor severidad, hay un desbalance claro.
• Recurrencia sin variación. La misma alerta, del mismo host, con el mismo patrón, todos los días a la misma hora. Puede ser un comportamiento legítimo mal clasificado o un problema real que nadie atiende. Ambas cosas son malas señales.
• Falsos positivos recurrentes. El equipo ya sabe que "esa alerta siempre es falsa". Cuando ese conocimiento vive solo en la cabeza de una persona, no hay tuning: hay costumbre.
• Reglas que disparan sin contexto. Una regla que alerta sobre un comando, una conexión o un cambio de archivo sin considerar el activo, el horario, el usuario o el rol del sistema genera ruido estructural.
• Cambios no autorizados en la configuración de reglas. Modificaciones en local_rules.xml, en decoders o en umbrales que no pasaron por revisión. Un silenciamiento informal puede estar ocultando detección relevante.
• Alertas que nadie cierra. Si el ciclo de vida de una alerta no tiene estado final (investigada, descartada, escalada), no hay forma de saber si el tuning funcionó.

Observar estas señales durante dos o tres semanas suele bastar para identificar dónde está el problema. No hace falta instrumentar nada exótico: los propios dashboards y el histórico de alertas de Wazuh entregan la materia prima.

Errores frecuentes y límites al ajustar reglas y umbrales

El tuning mal ejecutado es tan problemático como la ausencia de tuning. Los errores más comunes:

Silenciar en lugar de calibrar. Bajar el nivel de una regla a cero o excluirla del dashboard resuelve el síntoma y elimina la detección. Si esa regla cubría una técnica de ataque o un cambio relevante, la operación queda ciega sin saberlo.

Ajustar sin línea base. Modificar umbrales sin haber medido el comportamiento normal del entorno convierte el tuning en intuición. Sin línea base no hay forma de saber si el cambio mejoró o empeoró la señal.

Perder trazabilidad de los cambios. Cada ajuste de regla debería quedar registrado: qué se cambió, por qué, quién lo aprobó y qué efecto se esperaba. Sin ese registro, el siguiente analista hereda un conjunto de reglas que no entiende.

Confundir severidad con prioridad. Una regla de nivel alto que dispara cien veces al día no es prioritaria: es ruido con etiqueta de urgencia. La prioridad operacional depende del contexto del activo, no solo del nivel asignado.

Tuning de una sola vez. El entorno cambia: nuevos servicios, nuevos hosts, nuevas versiones. Un tuning cerrado hace seis meses probablemente ya no refleja la operación actual.

No distinguir entre "no accionable" y "no relevante". Hay alertas que no requieren acción inmediata pero sí registro y revisión periódica. Confundirlas con ruido puro lleva a eliminarlas cuando deberían conservarse con otro tratamiento.

El límite práctico es claro: el tuning no elimina la incertidumbre. Puede reducir el volumen, mejorar la correlación y hacer visible lo que importa, pero no convierte a Wazuh en un sistema que decide por el equipo. La decisión de qué es relevante sigue siendo humana y contextual.

Criterio práctico para decidir si una alerta sigue siendo útil

Una forma operativa de abordar cada alerta problemática es aplicar una secuencia de decisión:

1. Evaluar. ¿La alerta corresponde a un comportamiento que, si fuera malicioso, requeriría acción? Si la respuesta es no, la regla probablemente está mal diseñada o mal ubicada.
2. Ajustar. Si el comportamiento es relevante pero el volumen es alto, ajustar el umbral, la frecuencia o la correlación con otros eventos antes de considerar silenciarla.
3. Silenciar con criterio. Si el comportamiento es legítimo y conocido, silenciar de forma acotada: por host, por usuario, por ventana horaria. Nunca silenciar la regla completa si cubre otros escenarios.
4. Escalar. Si la alerta es recurrente y no se resuelve con tuning, probablemente hay un problema de fondo —configuración, parcheo, higiene operacional— que debe escalar a otra área, no al SIEM.
5. Reescribir. Cuando la regla original ya no representa el riesgo actual, reescribirla con contexto: activo, criticidad, horario, identidad.

Un ejemplo genérico ayuda a aterrizar el criterio. Si una regla dispara de forma recurrente sobre un proceso legítimo en un servidor específico, el ajuste razonable no es desactivarla globalmente, sino acotar su alcance: excluir ese host o esa ventana horaria mediante una regla hija que herede la original y añada la condición de contexto. Así se conserva la detección para el resto del entorno y se elimina el ruido del caso conocido. El mismo principio aplica a umbrales de frecuencia: en lugar de bajar el nivel de severidad para toda la regla, se puede ajustar el número de ocurrencias necesarias para disparar, manteniendo la alerta para patrones anómalos.

Sostener el tuning en el tiempo requiere tres cosas: un responsable claro, una revisión periódica (mensual o trimestral según el volumen) y un registro de cambios. Sin esos tres elementos, el tuning vuelve a degradarse en pocas semanas.

Vale la pena diferenciar este trabajo del que se hace sobre componentes específicos. El tuning de reglas y alertas es transversal; el de FIM, por ejemplo, tiene su propio conjunto de decisiones sobre rutas, frecuencia y ruido esperado. Comparten principios, pero no se resuelven con el mismo ajuste.

Cómo evaluar este criterio en tu operación actual

Si al leer esto reconoce más de dos señales de degradación en su entorno, el punto de partida no es tocar reglas: es medir. Durante dos o tres semanas, registrar qué reglas disparan más, cuáles se cierran sin acción y cuáles se investigan. Ese registro es la línea base sobre la que se decide qué ajustar.

Cuando la operación no tiene capacidad interna para sostener ese ciclo —o cuando el equipo ya está absorbido por otras prioridades—, evaluar un esquema gestionado tiene sentido. Wazuh como Servicio permite delegar la operación del SIEM manteniendo visibilidad y control sobre las decisiones de calibración, con revisión periódica de reglas y alertas como parte del servicio. No reemplaza el criterio del equipo interno, pero sí libera la carga operativa que hoy impide ejercerlo.

La pregunta útil no es "¿cuántas alertas tengo?", sino "¿cuántas de mis alertas cambiaron una decisión en las últimas semanas?". Si la respuesta es baja, el tuning está pendiente.