Qué es Wazuh: arquitectura, casos de uso y comparación con SIEM comerciales

Wazuh es una plataforma open source de seguridad que combina SIEM, XDR ligero y gestión de cumplimiento en un único producto, con agentes desplegados en cada endpoint y una consola central que correlaciona, alerta y reporta. Nació como evolución de OSSEC, lo mantiene una empresa con sede en San José y oficinas en Madrid, y se ha convertido en el SIEM más usado en mid-market español y en administraciones públicas que quieren capacidad de detección sin licencia anual de cinco cifras.

Esta guía explica qué es Wazuh, cómo está construido por dentro, qué detecta de verdad, en qué se parece y se diferencia de Splunk, Sentinel o Elastic Security, cuándo encaja y cuándo no, y cómo se apoya en él el cumplimiento de NIS2, ENS, ISO 27001 y PCI DSS.

Qué es Wazuh

Wazuh es una plataforma de monitorización de seguridad de código abierto, gratuita en su versión core, que cubre detección de amenazas, integridad de ficheros, gestión de vulnerabilidades, evaluación de configuración y reporting de compliance sobre endpoints y servidores. Despliegas agentes ligeros en cada máquina (Windows, Linux, macOS, Solaris, AIX, contenedores), un servidor central recibe la telemetría, la correlaciona y la indexa, y un dashboard sobre OpenSearch presenta alertas y métricas.

Lo que aporta operativamente:

• Telemetría continua de endpoints: logs del sistema, integridad de ficheros, procesos, cambios en configuración, salida de comandos.
• Detección de amenazas mediante reglas, decoders, integración con MITRE ATT&CK e indicadores de compromiso.
• Gestión de vulnerabilidades comparando software instalado con bases de datos de CVE (NVD, vendor feeds).
• Auditoría de configuración contra benchmarks (CIS, PCI DSS, HIPAA).
• Capacidades de respuesta activa: ejecutar comandos, bloquear IPs, aislar hosts.
• Reporting de cumplimiento mapeado a marcos regulatorios habituales.

La diferencia esencial con un SIEM comercial no es la funcionalidad sino el modelo: con Wazuh no pagas licencia, pagas operación. Si la organización tiene equipo capaz de desplegar, ajustar y mantener la plataforma, el ahorro es significativo. Si no lo tiene, contratar un proveedor que opere Wazuh por la organización es la forma habitual de adoptarlo.

Arquitectura de Wazuh

Wazuh se estructura en cuatro componentes que pueden vivir en una sola máquina (despliegue all-in-one para PoCs o entornos pequeños) o repartirse en varias para escalar.

Wazuh Agent

Software ligero (en torno a 10-20 MB de RAM en operación) que se instala en cada activo monitorizado. Recoge logs del sistema, monitoriza ficheros (FIM), enumera software instalado, captura eventos de seguridad y los envía cifrados al manager. Soporta la mayoría de sistemas operativos modernos y se puede empaquetar con scripts para despliegue masivo (Ansible, Group Policy, Intune).

Wazuh Manager (o Wazuh Server)

El cerebro. Recibe los eventos de los agentes, los normaliza con decoders, los pasa por reglas, genera alertas y dispara respuestas activas si están configuradas. También sirve para gestionar agentes (registro, claves, actualizaciones) y para correlacionar eventos en ventanas temporales.

Wazuh Indexer

Capa de almacenamiento y búsqueda basada en OpenSearch (fork de Elasticsearch). Indexa todas las alertas y todos los eventos que el manager decide persistir, permite búsquedas full-text rápidas y soporta agregaciones para dashboards.

Wazuh Dashboard

Frontend basado en OpenSearch Dashboards (fork de Kibana). Presenta alertas en tiempo real, permite búsquedas ad-hoc, expone visualizaciones por compliance (NIS2, PCI DSS, HIPAA), gestiona agentes y configura reglas.

En despliegues medianos o grandes, lo habitual es separar manager (cluster activo-activo), indexer (cluster con shards y replicas) y dashboard, todo orquestado con Kubernetes o con instalación distribuida tradicional.

Qué detecta Wazuh

Las capacidades centrales que aportan valor en producción son:

• File Integrity Monitoring (FIM). Detecta cambios en ficheros y directorios sensibles (/etc/passwd, claves SSH, configuraciones de servicios, ficheros de aplicación). Genera alerta con detalles del cambio (qué proceso, qué usuario, qué hash antes y después).
• Log analysis. Procesa logs del sistema y de aplicaciones (auth, syslog, eventlog Windows, IIS, Apache, Nginx, bases de datos, firewall, AD). Decoders normalizan formatos, reglas detectan patrones de intrusión, fuerza bruta, actividad anómala.
• Rootkit y malware detection. Búsqueda de rootkits conocidos, ficheros sospechosos, procesos ocultos, hooks en kernel.
• Security Configuration Assessment (SCA). Auditoría periódica del endpoint contra benchmarks CIS y plantillas custom: parches al día, contraseñas robustas, servicios innecesarios, configuración de firewall.
• Vulnerability detection. Comparación del inventario de software con feeds de CVE (NVD, Microsoft, Red Hat, Ubuntu, Debian, Adobe). Reporte priorizado por severidad CVSS y estado del parcheo.
• MITRE ATT&CK mapping. Cada regla relevante incluye etiqueta a técnicas ATT&CK, lo que permite construir mapas de cobertura defensiva. Es la pieza que conecta Wazuh con threat hunting maduro.
• Cloud security. Integraciones nativas con AWS (CloudTrail, GuardDuty, S3 access logs), Azure (Activity Logs, Entra ID) y GCP (Audit Logs).
• Container security. Monitorización de Docker, Kubernetes y registros de contenedores.
• Active Response. Acciones automáticas predefinidas (bloquear IP en firewall, deshabilitar cuenta, ejecutar script forense) cuando una regla dispara.

La cobertura es amplia, pero no equivale en profundidad a un EDR puro como CrowdStrike Falcon o SentinelOne. Wazuh es muy fuerte en logs, FIM, compliance y vulnerabilidades; es razonable pero no top en respuesta automatizada en endpoint.

Wazuh frente a SIEM comerciales

Comparativa práctica con los nombres que más aparecen en RFP españoles.

Wazuh

• Modelo: open source, gratis. Pago opcional por soporte enterprise.
• Coste: cero en licencias, alto en operación interna o vía proveedor.
• Curva de aprendizaje: media-alta. Configurar reglas y decoders custom requiere experiencia.
• Mejor para: mid-market, administraciones, organizaciones con equipo técnico interno o partner que opere la plataforma.

Splunk Enterprise Security

• Modelo: comercial, licencia por GB ingestado o por workload.
• Coste: alto. Suele estar fuera de presupuesto para mid-market.
• Curva de aprendizaje: alta, SPL es un lenguaje propio.
• Mejor para: enterprise con presupuesto, casos complejos, alta personalización.

Microsoft Sentinel

• Modelo: cloud-native, pago por GB de ingesta y retención.
• Coste: variable, manejable si el stack ya está en Microsoft 365.
• Curva de aprendizaje: media. KQL es razonable para equipos con experiencia SQL.
• Mejor para: organizaciones con Azure / Microsoft 365 en producción.

Elastic Security

• Modelo: open core, alguna funcionalidad enterprise tras licencia.
• Coste: bajo en versión gratuita, sube con features comerciales.
• Curva de aprendizaje: alta si se monta sobre stack Elastic propio.
• Mejor para: equipos que ya operan Elastic para observabilidad y quieren añadir seguridad.

La elección rara vez se decide por capacidad técnica pura. Pesan más el coste total (licencia más operación), las integraciones nativas con el stack actual y la experiencia del equipo.

Casos de uso típicos en empresa española

Patrones de despliegue que vemos en mid-market y sector público:

• SOC interno con presupuesto ajustado. Wazuh + agentes en endpoints críticos + integración con firewalls. Reglas custom para los logs específicos de la organización. Cobertura suficiente para detectar fuerza bruta, exfiltración básica, alertas de FIM y compliance básico.
• Apoyo a SOC externalizado. Wazuh como plataforma sobre la que opera el MSSP. Permite mantener los datos en infraestructura del cliente y cambiar de proveedor sin perder histórico.
• Compliance NIS2 / ENS. Despliegue de Wazuh para cubrir requisitos de monitorización continua, gestión de vulnerabilidades y reporting de incidentes con coste razonable. Plantillas de compliance preconfiguradas aceleran auditoría.
• Infraestructura híbrida. Wazuh monitoriza on-premise + cloud (AWS, Azure, GCP) en una única consola, sin tener que migrar la operación al SIEM cloud del hyperscaler.
• Detección complementaria a EDR comercial. La organización tiene EDR (Defender for Endpoint, CrowdStrike) y suma Wazuh para FIM en servidores Linux, compliance y agregación de logs no-endpoint (firewall, switches, aplicaciones).

Despliegue y dimensionamiento

Tres modelos habituales según volumen.

All-in-one (PoC y pequeñas organizaciones)

Manager + indexer + dashboard en una única VM. Soporta hasta unos cientos de agentes con dimensionamiento adecuado. Útil para empezar, no recomendable para producción crítica.

Distribuido tradicional

Manager dedicado, indexer en cluster (3 nodos mínimo para alta disponibilidad), dashboard separado. Soporta miles de agentes. Es el patrón más común en organizaciones medianas.

Multi-cluster con manager federado

Varios managers en regiones o sitios distintos enviando alertas a un indexer central. Útil para organizaciones distribuidas geográficamente o con requisitos de soberanía del dato.

Para dimensionar, los puntos clave son: volumen de eventos por segundo (EPS) que generan los agentes, retención deseada (compliance suele exigir 6-12 meses), y número de agentes concurrentes. La documentación oficial publica matrices de dimensionamiento que conviene revisar antes del PoC.

Wazuh y compliance

Marcos donde Wazuh aporta evidencia directa con plantillas preconfiguradas:

• NIS2 (artículo 21). Detección de amenazas, gestión de vulnerabilidades, integridad de ficheros, monitorización continua. La plataforma documenta capacidad técnica para los puntos del artículo 21 que se traducen a operación.
• ENS (RD 311/2022). Wazuh cubre op.exp.7 (gestión de incidentes), op.exp.8 (registro de actividad), op.mon (monitorización), op.cont (continuidad de servicios) con plantillas alineadas a la categorización del sistema.
• ISO 27001:2022. Controles 8.15 (logging), 8.16 (monitorización de actividades), 8.7 (protección frente a malware), 8.8 (gestión de vulnerabilidades técnicas).
• PCI DSS v4.0. Req. 10 (logging y monitorización), req. 11.5 (FIM en componentes críticos), req. 6.3 (gestión de vulnerabilidades).
• HIPAA, GDPR, GLBA, NIST 800-53. Plantillas adicionales según sector.

Importante: tener Wazuh desplegado no equivale a estar conforme. La auditoría exige reglas activas, alertas atendidas, runbooks de respuesta, retención adecuada y procesos documentados. El producto es la herramienta; el cumplimiento es la operación.

Errores comunes en despliegues

Lo que vemos en revisiones de implementaciones existentes:

1. Despliegue all-in-one en producción crítica. Funciona hasta que crece el volumen y el indexer satura el disco. Conviene ir a distribuido en cuanto haya más de unos cientos de agentes.
2. Reglas por defecto sin tunear. Genera ruido enorme y los analistas dejan de mirar. Hay que ajustar al entorno: silenciar lo benigno, priorizar lo crítico, escribir decoders custom para aplicaciones propias.
3. No hay retención adecuada. Por defecto, los índices viejos se borran rápido. Para compliance se necesita retención típica de 6-12 meses, lo que requiere planificar capacidad de disco desde el principio.
4. Agentes sin estrategia de despliegue masivo. Instalar a mano en 500 hosts es inviable. Hay que usar GPO, MDM, Ansible, Puppet o Chef desde el día uno.
5. FIM mal configurado. Vigilar el sistema entero genera falsos positivos. Hay que listar carpetas críticas (/etc, /root/.ssh, configuraciones de aplicación) y dejar fuera las que cambian legítimamente todo el rato (/var/log, cachés).
6. Sin integración con la cadena de respuesta. Las alertas se quedan en el dashboard. Hay que exportar a ticketing (Jira, ServiceNow), notificar al equipo (Slack, Teams) y, si aplica, correlacionar en SOAR.
7. Alta disponibilidad olvidada. Manager o indexer en una sola máquina equivale a perder visibilidad cuando falla. Cluster activo-activo en producción seria.
8. Actualizaciones aplazadas. Wazuh evolúa rápido y las nuevas versiones traen reglas, decoders y mejoras de rendimiento. Quedarse en una versión vieja un año pierde detección.

Preguntas frecuentes

¿Wazuh es realmente gratis?

La versión core sí, sin coste de licencia y bajo licencia AGPLv3. Wazuh Inc. ofrece soporte enterprise de pago (SLA, asesoría, formación) que muchas empresas contratan al pasar a producción. La gran factura no es la herramienta, es el equipo o el partner que la opera.

¿Cubre Wazuh las funciones de un EDR completo?

Cubre buena parte (telemetría de endpoint, FIM, detección de procesos sospechosos, response activo) pero no equivale a un EDR top como CrowdStrike Falcon o SentinelOne en profundidad de telemetría, hooks en kernel, machine learning local o respuesta automática granular. Para empresas que necesitan EDR avanzado, lo habitual es combinar Wazuh (logs, compliance, FIM, vulnerability mgmt) con un EDR comercial.

¿Cuántos agentes soporta Wazuh?

Con dimensionamiento adecuado, decenas de miles. Casos públicos hablan de despliegues con más de 50.000 agentes operando contra clusters distribuidos. Para mid-market (cientos a unos miles de agentes), un cluster modesto basta.

¿Cómo se compara Wazuh con OSSEC?

Wazuh nació como fork de OSSEC y lo ha superado en casi todo: arquitectura distribuida, integración con OpenSearch, dashboard moderno, MITRE ATT&CK, vulnerability detection, cloud security. OSSEC sigue activo pero Wazuh es la opción mainstream actual.

¿Es Wazuh suficiente para compliance NIS2?

Es una pieza importante, no la única. Cubre detección, monitorización, gestión de vulnerabilidades y reporting. NIS2 exige además medidas organizativas (gobernanza, formación, gestión de proveedores, plan de continuidad) que no entran en el alcance de un SIEM. Wazuh aporta la evidencia técnica del artículo 21; el resto del cumplimiento se construye encima.

¿Puede un MSSP operar Wazuh por mi empresa?

Sí, es un modelo común. El cliente despliega Wazuh en su infraestructura (manteniendo soberanía del dato) y un proveedor de ciberseguridad gestionada asume operación 24/7: ajuste de reglas, atención de alertas, threat hunting periódico, reporting. Es la forma de adoptar Wazuh sin construir SOC interno.

Recursos relacionados

• Qué es un SIEM: el contexto en el que encaja Wazuh, comparado con Splunk, Sentinel, QRadar.
• Qué es un SOC: la función que opera Wazuh en el día a día.
• Qué es un EDR: la categoría adyacente a Wazuh, con la que se complementa en endpoints críticos.
• Qué es threat hunting: la disciplina proactiva que aprovecha la telemetría de Wazuh.
• Qué es un MDR: el servicio externalizado que muchas empresas contratan operando precisamente sobre Wazuh.
• Qué es un CVE: el sistema de identificación que usa Wazuh para vulnerability detection.

Wazuh en Secra

En Secra trabajamos con Wazuh en dos frentes: como auditoría (revisión de despliegues existentes, validación de cobertura de reglas frente a TTPs reales mediante purple team, propuesta de mejoras de tuning) y como apoyo en proyectos donde la organización quiere arrancar capacidad SIEM con coste razonable. Si tu organización está evaluando Wazuh como alternativa a un SIEM comercial o quieres validar la postura del Wazuh que ya tienes, escríbenos a través de contacto o consulta nuestros servicios de SIEM gestionado.