Dejar Wazuh es una decisión de operación, no una comparativa de funciones. La licencia es gratis y el contenido de detección es tuyo, así que lo que pones en la balanza es capacidad de servidor más horas de ingeniería frente a una suscripción. Responde primero a unas preguntas —quién lo mantiene hoy, cuántas de tus reglas propias disparan, qué retención estás obligado a guardar— y la decisión sale sola.
¿Qué te cuesta de verdad operar Wazuh?
Un despliegue tiene cuatro partes, según la documentación de componentes: el agente en cada endpoint, el servidor, el indexador y el panel. Tres corren sobre infraestructura que tú dimensionas, parcheas, respaldas y actualizas.
Las cifras publicadas dan un suelo. Wazuh recomienda 16 GB de RAM y 8 núcleos para el indexador (mínimo 4 GB y 2 núcleos) y 4 GB con 8 núcleos para el servidor (mínimo 2 GB y 2 núcleos). El almacenamiento crece con la retención, no con el número de equipos: el ejemplo de la propia guía sitúa 80 puestos, 10 servidores y 10 dispositivos de red en unos 231 GB para 90 días de alertas (1,5 GB por puesto, 3,7 GB por servidor, 7,4 GB por dispositivo). Guarda un año y hace falta cuatro veces el disco.
La capacidad tampoco se revisa una vez. El servidor expone dos ficheros de estado —/var/ossec/var/run/wazuh-analysisd.state para eventos descartados y wazuh-remoted.state para mensajes de agente perdidos— y cuando suben de cero la respuesta documentada es añadir nodos al clúster. Alguien tiene que mirarlos.
Las actualizaciones son el coste que más se infravalora. La guía de actualización exige que todos los componentes centrales tengan la misma versión, incluido el nivel de parche, y que el manager vaya igual o por delante de los agentes: una ventana de mantenimiento sobre tres servicios. El indexador, además, sigue a OpenSearch y no a Elasticsearch: la 4.12.0 lo llevó a OpenSearch 2.19.1, y esas notas avisan de que después no se puede volver atrás. La rama actual es la 4.14.x (4.14.8, del 23 de septiembre de 2026).
El ajuste tampoco termina. Tus detecciones viven en local_decoder.xml y local_rules.xml, con IDs reservados en el rango 100000-120000, y ese conocimiento suele estar en una sola cabeza.
¿Qué pierdes si te vas?
Cinco cosas se van con la migración, y todas son reales. La licencia gratuita: Wazuh se describe como una plataforma de seguridad libre y de código abierto que unifica capacidades XDR y SIEM, y cualquier producto comercial cambia ese cero por un precio por endpoint o por entorno. El acceso directo al almacén: con tu indexador consultas los índices tú mismo. Tus decodificadores: los decoders XML que escribiste para un cortafuegos, un TPV o un equipo industrial no se trasladan; confirma que el producto nuevo parsea esas fuentes antes de migrar. La configuración como ficheros: ossec.conf, las reglas y los grupos de agentes viven en control de versiones y se revisan como código, no en una consola. Leer cada regla que dispara: con un catálogo mantenido dependes del contenido de otro, que es lo que pagas, y sigue siendo una cesión.
¿Qué operas tú y qué opera un producto gestionado?
Wazuh publica ese reparto para su propio servicio alojado, y sirve de plantilla para cualquier SIEM gestionado. La documentación de Wazuh Cloud dice que Wazuh se encarga del alojamiento, el mantenimiento, el escalado, la alta disponibilidad, la seguridad de la plataforma y las actualizaciones de versión, mientras tú sigues con agentes, reglas propias, integraciones, control de acceso y respuesta a incidentes.
| Tarea | Wazuh autogestionado | Producto gestionado (incluido Wazuh Cloud) |
|---|---|---|
| Alojar los componentes centrales | Los dimensionas y mantienes tú. | El proveedor los aloja y mantiene. |
| Escalado y alta disponibilidad | Añades nodos cuando hay pérdidas. | El proveedor monitoriza, escala y da HA. |
| Actualizaciones de versión | Tú, a la vez en todos, en ventana. | El proveedor las publica. |
| Parcheo de sistema operativo | Tuyo, incluidos los hosts del indexador. | El proveedor asegura la plataforma. |
| Retención y disco | Tu factura de almacenamiento, según alertas por segundo. | En la suscripción; mira el techo y el exceso. |
| Despliegue y configuración de agentes | Tuyo. | Sigue siendo tuyo. |
| Detecciones propias e integraciones | Tuyas, en XML. | Siguen siendo tuyas, en el formato del producto. |
| Control de acceso de tus usuarios | Tuyo. | Sigue siendo tuyo. |
| Triaje y respuesta a incidentes | Tuyos. | Tuyos, salvo que contrates un servicio monitorizado. |
Lee la columna de la derecha dos veces: un producto gestionado cambia quién opera la fontanería, no quién hace que las detecciones encajen contigo. Nuestra alternativa a Wazuh traza la misma línea fila por fila.
¿Qué preguntas conviene responder antes de decidir?
- ¿Quién mantiene el despliegue, con nombre y apellidos? Si la respuesta es «quien tenga un hueco», el problema es de propiedad y no de herramienta.
- ¿Cuántas de tus reglas propias disparan de verdad? Cuenta los IDs distintos en el índice de alertas de los últimos 90 días, separando los tuyos del rango 100000 de los de la comunidad. Casi siempre son muchos menos que las reglas de los ficheros.
- ¿De qué fuentes de log dependes? Lista las que llevan 90 días sin generar una alerta ni aparecer en una búsqueda: quitarlas cambia tus cuentas de almacenamiento igual.
- ¿Qué retención necesitas de verdad, y para qué? La evidencia de auditoría puede ir a almacenamiento frío; solo la ventana de investigación tiene que ser buscable, y es la que marca el coste del indexador y el precio de una suscripción de SIEM y búsqueda.
- ¿Necesitas respuesta en endpoint o solo detección? La respuesta activa de Wazuh ejecuta scripts en el host lanzados por reglas. Aislar, matar un proceso o poner en cuarentena desde una consola con aprobación es otro requisito: mira qué cubre un módulo EDR.
- ¿Dónde empiezan tus incidentes? Si la mayoría arrancan en Microsoft 365 o Google Workspace, un SIEM centrado en agentes de host tiene el centro de gravedad equivocado.
- ¿Qué se rompe si el SIEM no está disponible un día? Si nada urgente, no necesitas un indexador multinodo en ninguno de los dos escenarios que comparas.
- ¿Cuánto cuesta al mes lo que tienes hoy, en horas? Actualizaciones, ajuste, crecimiento de disco y problemas de agentes a coste real, más la factura de servidores. Sin ese número no sabes si un precio por endpoint es caro. Y pregunta al proveedor nuevo si puedes exportar detecciones y eventos en bruto, en qué formato y hasta cuándo.
¿Cómo se hace una convivencia, semana a semana?
Tener las dos plataformas en paralelo es la única forma de responder a la paridad con datos. Seis semanas es realista para unos cientos de endpoints:
Semana 0 — línea base. Anota alertas al día por ID de regla, fuentes de log activas, agentes desconectados hace más de una semana y tu tasa de falsos positivos. Sin eso no sabrás si el sustituto es mejor o solo distinto.
Semana 1 — ingesta doble en un piloto. De veinte a cuarenta endpoints que cubran cada sistema operativo y cada rol, incluido un servidor ruidoso. Agente nuevo junto al de Wazuh, las mismas fuentes syslog a los dos colectores y nada apagado.
Semana 2 — paridad de detección. Por cada regla que disparó en la línea base, marca el producto nuevo como cubierto, cubierto de otra forma o no cubierto. La lista de «no cubierto» es el dato que decide.
Semana 3 — ruido. Ajusta los falsos positivos del piloto comparando contra tu Wazuh ya ajustado, no contra una instalación recién hecha.
Semana 4 — respuesta y permisos. Lleva un incidente de principio a fin: alerta, triaje, contención, cierre. Comprueba quién puede aislar un equipo y si hay paso de aprobación.
Semana 5 — corte del enrutado. Las guardias y los tickets pasan al producto nuevo mientras Wazuh sigue ingiriendo en silencio. Define antes el criterio de marcha atrás: una clase de detección perdida, un hueco de ingesta superior a los minutos acordados o falsos positivos sobre el umbral.
Semana 6 y siguientes — cierre. Mantén Wazuh en solo lectura hasta que expire tu obligación de retención, y restaura una copia del indexador y búscala antes de borrar nada. No alargues la convivencia: dos agentes en un endpoint son dos juegos de exclusiones y el doble de CPU.
¿Cuándo conviene quedarse en Wazuh?
Quedarse es lo correcto más veces de lo que admite una comparativa. Quédate si hay un técnico que lo mantiene con horas asignadas y otra persona puede cogerlo. Quédate si tus casos de uso son recogida de logs, integridad de ficheros, evaluación de configuración e informes de cumplimiento: el terreno para el que se construyó Wazuh. Quédate si tienes decoders para fuentes que ningún parser comercial entiende. Quédate si tu volumen cabe en un solo nodo de indexador, porque ahí autogestionar sale barato.
Múdate si nadie lo mantiene y las actualizaciones se retrasan, si las alertas nunca se han ajustado, o si necesitas contención de endpoint, protección de correo y señales de identidad en el mismo sitio: el hueco que cierra un SIEM para equipos pequeños cuando no hay analista.
Hay una opción intermedia que se salta mucha gente: Wazuh Cloud conserva tu conjunto de reglas, tu agente y tu conocimiento, y mueve solo la infraestructura. Si lo que te pesa es el clúster y no el producto, ese cambio es mucho menor que una migración.
Haz las cuentas primero. Quien se arrepiente de esta decisión comparó un precio de licencia con un precio de suscripción y dejó las horas fuera de las dos columnas.