Wazuh: qué observar antes de adoptarlo en tu operación

Cuando los eventos de seguridad están dispersos en servidores, endpoints y servicios en la nube, correlacionar lo que realmente importa se vuelve una tarea casi artesanal. Wazuh aparece en ese escenario como una alternativa de código abierto que muchos equipos TI evalúan para consolidar visibilidad, detectar cambios no autorizados y centralizar alertas. Pero antes de instalarlo o contratarlo, conviene entender qué es, cómo opera y qué implica mantenerlo en producción.

¿Qué es Wazuh y qué problema resuelve en una operación de TI?

Wazuh es una plataforma de seguridad de código abierto que combina capacidades de detección de intrusos en hosts (HIDS), monitoreo de integridad de archivos (FIM), análisis de logs y correlación de eventos. En la práctica, funciona como un SIEM ligero y como base para capacidades tipo XDR, dependiendo de cómo se integre con el resto de la infraestructura.

El problema que resuelve es concreto: en muchas organizaciones, los logs de autenticación, los cambios en archivos críticos y los eventos de red viven en silos. El equipo de TI revisa el firewall por un lado, el servidor de aplicaciones por otro y el directorio activo por separado. Cuando ocurre un incidente, reconstruir la secuencia de eventos toma horas o días.

Wazuh centraliza esa información en un solo lugar, aplica reglas para detectar comportamientos anómalos y genera alertas con contexto. Para un gerente TI, el valor no está en la herramienta en sí, sino en la capacidad de responder preguntas como: ¿quién modificó este archivo a las 3:00 AM? ¿Este intento de acceso fallido es parte de un patrón más amplio? ¿Hay un binario nuevo en un servidor de producción?

Cómo funciona Wazuh: componentes y flujo técnico

Wazuh tiene una arquitectura de cuatro componentes principales que conviene conocer antes de evaluar su adopción:

Agente: se instala en los servidores o endpoints que se quieren monitorear. Recopila información del sistema operativo, logs de aplicaciones, eventos de autenticación y cambios en archivos. También ejecuta escaneos de vulnerabilidades y detecta procesos o conexiones sospechosas.

Servidor Wazuh (manager): recibe los datos de los agentes, los analiza con reglas y genera alertas. Es el cerebro de la correlación: puede combinar eventos de múltiples agentes para detectar patrones que un solo host no revelaría.

Indexador (indexer): almacena y organiza los datos para que sean consultables. Es el componente que permite hacer búsquedas históricas y correlacionar eventos en el tiempo.

Dashboard: la interfaz visual donde el equipo de seguridad o TI revisa alertas, genera reportes y navega por los datos.

El flujo técnico es relativamente directo: el agente envía eventos al servidor, este los normaliza y los compara contra reglas, y si hay coincidencia genera una alerta que queda indexada y visible en el dashboard.

Una de las capacidades más relevantes para operaciones críticas es el monitoreo de integridad de archivos (FIM). Si un archivo de configuración de un servicio financiero o de un sistema de facturación cambia sin autorización, Wazuh puede alertar de inmediato, indicando qué archivo fue modificado, cuándo y por qué proceso. Esto es especialmente útil para detectar actividad maliciosa o errores de configuración que pasan desapercibidos.

Señales técnicas que conviene observar al evaluar Wazuh

Antes de decidir entre implementar Wazuh internamente o contratarlo como servicio, hay señales técnicas que determinan si la herramienta será útil o se convertirá en una fuente de ruido.

Consumo de recursos: Wazuh no es liviano. El agente tiene un impacto moderado en los hosts, pero el servidor y el indexador requieren planificación de capacidad. Si la operación maneja cientos de agentes, el almacenamiento y la memoria del indexador crecen rápido. Evaluar el volumen diario de eventos es clave para dimensionar correctamente.

Calidad de los logs: Wazuh depende de lo que recibe. Si los sistemas no generan logs estructurados o si los eventos de autenticación no están habilitados, la plataforma tendrá poca visibilidad. Antes de implementarla, conviene auditar qué fuentes de datos están disponibles y en qué formato.

Tuning de reglas: las reglas por defecto de Wazuh son un punto de partida, no una configuración final. Sin ajuste, el equipo recibirá alertas de bajo valor que rápidamente generan fatiga. El tuning requiere tiempo y conocimiento del entorno: lo que es anómalo en un servidor web puede ser normal en un servidor de base de datos.

Integración con la infraestructura existente: Wazuh puede integrarse con herramientas como TheHive, Elasticsearch o sistemas de ticketing, pero cada integración requiere configuración y mantenimiento. Evaluar qué se necesita realmente y qué se puede dejar para una segunda fase evita sobrecargar al equipo.

Errores frecuentes y límites al implementar Wazuh

Uno de los errores más comunes es implementar Wazuh y esperar que las alertas hablen por sí solas. Una alerta sin contexto —sin saber qué activos están expuestos, qué es normal en el entorno o qué procedimiento seguir— es ruido, no inteligencia. El valor aparece cuando el equipo define qué eventos son críticos y cómo responder ante ellos.

Otro error es tratar a Wazuh como un proyecto de instalación única. Las reglas se desactualizan, los logs cambian de formato, los sistemas se actualizan y el entorno evoluciona. Sin mantenimiento periódico, la plataforma pierde precisión y el equipo deja de confiar en sus alertas.

También es importante entender los límites. Wazuh no reemplaza un firewall, no gestiona identidades y no es una solución de cumplimiento normativo por sí sola. Puede aportar controles y trazabilidad —por ejemplo, evidencia de monitoreo de integridad o registro de eventos de acceso—, pero no garantiza cumplimiento de leyes como la Ley 21.719 en Chile. La herramienta apoya la preparación, pero el cumplimiento depende de un programa más amplio de controles, políticas y evidencia.

Criterio práctico para adoptar Wazuh en tu operación

La decisión de adoptar Wazuh no debería basarse solo en que es open source o en que tiene buena documentación. El criterio práctico es evaluar si el equipo tiene capacidad para operarlo: mantener las reglas actualizadas, dimensionar el almacenamiento, responder a las alertas y ajustar la configuración cuando cambia la infraestructura.

Si el equipo de TI ya está saturado con la operación diaria, implementar Wazuh internamente puede convertirse en una carga adicional. En ese escenario, evaluar una opción administrada tiene sentido: la plataforma se opera como servicio, con el proveedor responsable del mantenimiento, el tuning y la disponibilidad, mientras el equipo interno se enfoca en responder a las alertas y definir prioridades.

En Mister IT ofrecemos Wazuh como Servicio precisamente para organizaciones que necesitan visibilidad y correlación de eventos sin asumir la complejidad operativa de mantener la plataforma. La evaluación parte por entender el volumen de eventos, los activos críticos y las capacidades internas.

Si estás evaluando Wazuh para tu operación, el siguiente paso no es instalar un agente de prueba, sino definir qué preguntas necesitas responder con la herramienta. A partir de ahí, la decisión técnica se vuelve más clara.