SIEM Wazuh: cómo evaluar su rol real en tu operación

Cuando un equipo de TI busca "SIEM Wazuh" suele estar en un punto intermedio: ya escuchó que Wazuh puede funcionar como SIEM, ya tiene agentes desplegados o está evaluando hacerlo, pero no tiene claro qué significa eso en la práctica diaria. No es una pregunta de arquitectura ni de instalación. Es una pregunta operativa: ¿qué debería ver si Wazuh está cumpliendo el rol de SIEM en mi entorno, y qué debería preocuparme si no lo está?

Este artículo aborda esa capa específica: el comportamiento de Wazuh como sistema de correlación y detección, las señales que conviene monitorear y los errores que aparecen con más frecuencia cuando se opera como SIEM en producción.

Qué implica usar Wazuh como SIEM en una operación empresarial

Wazuh combina capacidades de detección de intrusiones, monitoreo de integridad de archivos, evaluación de configuración y análisis de logs. En su rol SIEM, el foco se desplaza hacia la recolección centralizada de eventos, la correlación mediante reglas y la generación de alertas accionables.

El valor no está en tener agentes instalados, sino en que los eventos que llegan desde endpoints, servidores, firewalls, aplicaciones y servicios cloud se conviertan en señales útiles. Si esa conversión no ocurre, el resultado es predecible: mucho volumen de datos, poca capacidad de respuesta y una sensación difusa de que "hay visibilidad" cuando en realidad solo hay acumulación.

El dolor operacional que Wazuh como SIEM debería atacar es concreto:

• Eventos dispersos en múltiples consolas y formatos que nadie correlaciona.
• Baja correlación entre lo que pasa en un endpoint y lo que pasa en la red o en una aplicación.
• Cambios no autorizados en configuraciones críticas que se detectan tarde o nunca.
• Falta de visibilidad sobre actividad que, vista en conjunto, indicaría un incidente.

Si tu operación no tiene esos problemas identificados, probablemente Wazuh como SIEM no sea la prioridad. Si los tiene, la pregunta correcta no es "¿Wazuh sirve como SIEM?" sino "¿qué señales me dicen si está sirviendo en mi caso?".

Cómo se comporta Wazuh en la capa SIEM: correlación, reglas y señales observables

Wazuh recibe eventos, los decodifica, los evalúa contra reglas y genera alertas cuando se cumplen condiciones definidas. Lo que importa en operación es qué observar para saber si esa cadena está funcionando.

Cobertura de fuentes. No basta con tener agentes. Hay que verificar qué tipos de eventos están llegando realmente: autenticación, cambios de archivos críticos, ejecución de procesos, eventos de red, logs de aplicaciones, actividad en servicios cloud. Una cobertura parcial genera puntos ciegos que no se notan hasta que ocurre un incidente en la zona no cubierta.

Calidad y mantenimiento de reglas. Las reglas por defecto cubren escenarios comunes, pero cada entorno tiene particularidades. Reglas mal ajustadas producen dos efectos opuestos y ambos dañinos: ruido excesivo que satura al equipo, o silencio que oculta actividad relevante. La revisión periódica de reglas no es opcional si se espera que el SIEM aporte.

Nivel de ruido. Un indicador práctico: ¿qué proporción de alertas termina siendo descartada sin acción? Si la mayoría se ignora, el SIEM está fallando en su función de priorización, aunque técnicamente esté "funcionando".

Latencia de detección. Desde que ocurre un evento hasta que aparece como alerta accionable, ¿cuánto pasa? En entornos con alto volumen, la latencia puede crecer sin que nadie lo note hasta que se necesita investigar un incidente y los datos ya no están disponibles o llegan tarde.

Trazabilidad de cambios. Wazuh puede monitorear integridad de archivos y configuraciones. La señal a observar es si esos cambios quedan registrados con contexto suficiente para saber qué cambió, cuándo y desde dónde. Sin eso, la trazabilidad es nominal.

Correlación efectiva. Más allá de alertas individuales, ¿el sistema genera señales que combinan eventos de distintas fuentes? Por ejemplo, un intento de autenticación fallido seguido de un cambio de configuración en el mismo host. Si todo se ve como eventos aislados, la capa de correlación no está aportando.

Estas señales no se leen una vez. Se revisan como parte de la operación, igual que se revisa la salud de cualquier componente crítico. Comprender cómo se conectan los componentes internos —agente, manager, indexer y dashboard— ayuda a interpretar estas señales, aunque ese flujo corresponde a un análisis de arquitectura distinto al foco operativo de este artículo.

Errores frecuentes y límites al operar Wazuh como SIEM

La mayoría de los problemas no vienen de fallas técnicas de Wazuh, sino de expectativas mal calibradas y de falta de mantenimiento operativo.

Esperar detección automática sin ajuste. Wazuh no conoce tu entorno. Las reglas genéricas no distinguen entre actividad normal de tu negocio y actividad sospechosa. Sin ajuste, el equipo termina ignorando alertas o apagándolas.

Integrar fuentes a medias. Conectar un firewall pero no sus reglas relevantes, o recolectar logs de aplicación sin decodificarlos correctamente, produce datos que ocupan espacio pero no generan detección.

No definir criterios de priorización. Un SIEM que trata todas las alertas igual no ayuda a decidir. Sin criterios de severidad alineados con el riesgo real de cada activo, la cola de alertas se vuelve inmanejable.

Operar sin revisión periódica. Las reglas, la cobertura y los umbrales envejecen. Lo que funcionaba hace seis meses puede estar generando ruido o dejando pasar eventos que antes no existían.

Confundir SIEM con cumplimiento. Tener Wazuh recolectando eventos no equivale a cumplir una norma. Ayuda a tener trazabilidad y controles, pero la preparación para marcos como la Ley 21.719 requiere además políticas, procedimientos y evidencia sostenida en el tiempo. Wazuh puede aportar a esa trazabilidad; no la reemplaza.

Subestimar el costo operativo. Un SIEM requiere alguien que lo mire, lo ajuste y lo mantenga. Si no hay ese rol definido, el sistema se degrada silenciosamente.

Sobre los límites: Wazuh no sustituye a un equipo de respuesta a incidentes, ni al análisis forense profundo, ni a controles de red. Es una capa de visibilidad y detección que se integra con el resto de la operación.

Criterio práctico para evaluarlo en una operación real

Antes de decidir si Wazuh como SIEM tiene sentido en tu entorno, conviene responder algunas preguntas concretas:

1. ¿Qué eventos necesito ver y hoy no veo? Si no hay una lista clara, el proyecto empieza sin dirección.
2. ¿Quién va a operar el SIEM? No el que lo instala, sino el que revisa alertas, ajusta reglas y mantiene la cobertura.
3. ¿Qué haría mi equipo con una alerta crítica a las 3 AM? Si no hay respuesta definida, la detección no se traduce en acción.
4. ¿Cómo voy a medir si está funcionando? Cobertura de fuentes, tiempo de detección, proporción de alertas accionables, cambios detectados. Sin métricas, no hay evaluación posible.
5. ¿Qué pasa si no lo hago? Si la respuesta es "nada cambia", probablemente no sea la prioridad ahora.

Si las respuestas apuntan a que necesitas visibilidad centralizada, correlación y trazabilidad de cambios, y tienes o puedes asignar capacidad operativa para sostenerlo, Wazuh es una opción razonable. Si esperas que funcione solo, o que reemplace controles que no existen, la evaluación va a terminar en frustración.

Para equipos que prefieren no cargar con la operación completa, Wazuh como Servicio permite mantener la capa de detección y correlación sin asumir toda la carga de administración interna. Es una decisión de modelo operativo, no solo técnica.