SIEM con Wazuh: criterios para evaluarlo en operación real

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

Tener Wazuh desplegado no equivale a operar un SIEM. La diferencia es operativa: un SIEM existe cuando los eventos de distintas fuentes se recolectan de forma consistente, se normalizan, se correlacionan y producen señales que alguien puede investigar y accionar. Si eso no ocurre, hay una consola con datos, no un sistema de detección.

Muchas organizaciones llegan a Wazuh por una necesidad concreta: visibilidad. El dolor suele repetirse. Eventos dispersos entre firewall, endpoints, servidores Linux y Windows, aplicaciones y servicios cloud. Correlación baja o inexistente, porque cada fuente se revisa por separado y solo cuando algo ya ocurrió. Cambios no autorizados que aparecen tarde, con el impacto ya en producción. Y la sensación de que la seguridad se gestiona por reacción, no por observación continua.

Wazuh cubre buena parte de ese espectro, pero conviene precisar qué espera el negocio de un SIEM y qué no resuelve por sí solo. El negocio espera detección temprana, trazabilidad, evidencia para investigar y reducción del tiempo entre el evento y la respuesta. No espera —ni debería— que el SIEM decida por sí mismo qué es un incidente, ni que reemplace controles preventivos, gestión de vulnerabilidades, hardening o gobierno de identidades. Un SIEM es una capa de observabilidad y correlación; su valor depende de la calidad de las fuentes, de las reglas y de quién interpreta las alertas.

Ese es el punto que separa "tener Wazuh" de "operar Wazuh como SIEM": la existencia de un proceso, no solo de una herramienta. Sin ese proceso, el resultado típico es un tablero que nadie mira con criterio y una cola de alertas que se acumula sin resolución.

Cómo funciona y qué señales técnicas conviene observar

A nivel operativo, los agentes y las fuentes remotas envían eventos al manager, este aplica decodificadores y reglas, y el resultado se indexa para consulta y correlación. Lo relevante para un responsable de operación no es repetir ese recorrido, sino identificar qué señales indican que el SIEM funciona y cuáles anticipan su degradación.

Señales de salud. La primera es la cobertura de fuentes: cuántos activos críticos reportan y cuántos no. Un agente silencioso no es un activo limpio, es un punto ciego. La segunda es el volumen y el ruido: si la proporción de alertas de baja utilidad crece, la capacidad de investigación se agota antes de llegar a lo importante. La tercera es la latencia de ingesta: eventos con retraso rompen la correlación temporal y hacen que una secuencia de ataque parezca hechos aislados. La cuarta es la integridad de reglas y decodificadores: cambios no versionados, reglas desactivadas sin registro o personalizaciones locales no documentadas generan detecciones inconsistentes entre entornos.

Señales de valor. Detección de cambios no autorizados en archivos críticos, cuentas privilegiadas, configuraciones de servicios expuestos o tareas programadas. Trazabilidad: poder reconstruir qué pasó, en qué orden, con qué identidad y desde qué origen. Correlación entre fuentes que por separado no dicen nada: un login fallido repetido en un servidor, seguido de una elevación de privilegios y una conexión saliente inusual es una historia; cada evento aislado, no. Y visibilidad de cumplimiento operativo: no como certificación, sino como evidencia de que los controles definidos se ejecutan.

Un criterio útil es medir el SIEM por lo que permite responder, no por lo que almacena. Si ante una alerta el equipo no puede reconstruir el contexto en minutos, el problema no es la herramienta, es el diseño de fuentes, reglas y retención.

Errores frecuentes, límites y buenas prácticas

El error más común es tratar Wazuh como un producto que se instala y queda operativo. Un SIEM requiere mantenimiento continuo: revisión de reglas, ajuste de umbrales, incorporación de nuevas fuentes y depuración de ruido. Sin ese ciclo, la detección se degrada en semanas.

El segundo es la cobertura desigual. Se conectan los servidores, pero no los endpoints, o se integran logs de aplicación sin normalizar, lo que produce eventos que no correlacionan. La cobertura debe priorizarse por criticidad del activo y valor investigativo del evento, no por facilidad de integración.

El tercero es confundir volumen con visibilidad. Más eventos no significa mejor detección; muchas veces significa más ruido y más tiempo perdido. La selección de fuentes y la calidad de las reglas importan más que la cantidad.

Entre los límites conviene ser explícito. Wazuh no reemplaza un EDR en capacidades de respuesta en endpoint, no sustituye la gestión de identidades ni el gobierno de accesos, y no convierte por sí solo una operación en cumplidora de normativas. En el contexto chileno, cuando se menciona la Ley 21.719, lo correcto es hablar de preparación, controles y trazabilidad: el SIEM aporta evidencia y visibilidad, pero el cumplimiento depende de un conjunto de medidas organizacionales y técnicas que exceden a la herramienta.

Tres buenas prácticas resultan transversales. Versionar reglas y decodificadores como se versiona código, con revisión antes de aplicar cambios en producción. Definir retención y ciclo de vida de los datos según necesidad investigativa y restricciones aplicables. Y establecer un proceso de triaje con responsables, tiempos y criterios de escalamiento, porque una alerta sin dueño es una alerta que no existe.

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

Antes de decidir si Wazuh encaja como SIEM en tu operación, conviene responder preguntas concretas. ¿Qué activos son críticos y cuáles ya reportan eventos? ¿Qué preguntas de seguridad necesitas responder y hoy no puedes? ¿Quién va a operar el SIEM, con qué dedicación y con qué nivel de especialización? ¿Qué retención necesitas y qué restricciones aplican a esos datos? ¿Cómo se integra el SIEM con los procesos existentes de incidentes, cambios y continuidad?

Si esas respuestas no están claras, la discusión sobre herramientas es prematura. Si están claras, la evaluación se vuelve medible: cobertura efectiva de fuentes críticas, tiempo medio de detección, proporción de alertas investigadas, capacidad de reconstruir eventos y consistencia de las reglas en el tiempo.

En ese marco, evaluar Wazuh como Servicio tiene sentido cuando la organización necesita operar el SIEM con criterio sin construir toda la capacidad internamente desde cero. No se trata de delegar la responsabilidad de seguridad, sino de asegurar que la recolección, correlación y mantenimiento de reglas ocurran con disciplina operativa.

Si estás revisando cómo encaja un SIEM basado en Wazuh en tu operación, conversemos sobre cómo evaluarlo con criterios reales y no solo con una demo.