Wazuh FIM: observar cambios no autorizados sin ruido

Tener FIM activado en Wazuh no equivale a tener visibilidad útil sobre cambios no autorizados. La diferencia es operativa: qué rutas se vigilan, cómo se interpreta cada evento, qué se considera cambio legítimo y qué volumen de alertas puede absorber el equipo sin degradar su capacidad de respuesta. Este artículo se centra en ese tramo, no en la adopción de la plataforma ni en su arquitectura interna.

Qué implica observar cambios no autorizados con FIM en Wazuh

FIM (File Integrity Monitoring) en Wazuh compara el estado de archivos y directorios contra una línea base y emite eventos cuando detecta modificaciones en atributos como contenido, permisos, propietario, grupo, tamaño o marcas de tiempo. En un entorno empresarial, esa mecánica se traduce en una pregunta concreta: ¿este cambio fue autorizado, esperado y trazable, o no?

La respuesta no la entrega el evento por sí solo. Un mismo evento —modificación de un archivo de configuración, alta de un binario, cambio de permisos en un directorio compartido— puede ser rutina de despliegue, actividad de un proveedor, tarea de mantenimiento o acción no autorizada. FIM aporta la evidencia del cambio; el criterio operacional aporta la clasificación.

El foco se desplaza desde "¿está FIM habilitado?" hacia "¿qué decisiones toma el equipo cuando FIM reporta?". Observar cambios no autorizados implica tres capacidades sostenidas en el tiempo:

• Cobertura deliberada: saber qué se vigila y por qué, no solo qué quedó incluido por defecto.
• Contexto suficiente: poder reconstruir quién, cuándo y en qué host ocurrió el cambio.
• Capacidad de respuesta: que el volumen de eventos permita investigar los relevantes sin ahogar al equipo.

Cuando falta cualquiera de las tres, FIM se convierte en una fuente de eventos que se acumulan sin resolverse. Ese es el dolor operacional real: no la ausencia de datos, sino la ausencia de señal accionable.

Qué señales técnicas conviene observar y cómo leer un evento de cambio

Un evento FIM de Wazuh contiene más información que el simple "archivo modificado". Leerlo con criterio operacional significa revisar cuatro dimensiones.

Ruta y criticidad del activo. No todas las rutas pesan igual. Un cambio en /etc/ de un servidor de producción, en un directorio de aplicación con lógica de negocio o en rutas donde residen claves y credenciales tiene un peso distinto al de un archivo temporal o de caché. La primera decisión operacional es clasificar rutas por criticidad antes de que llegue el evento, no después.

Atributos modificados. Wazuh distingue entre cambios de contenido, permisos, propietario, grupo y metadatos. Un cambio de permisos que amplía accesos es cualitativamente distinto a una modificación de contenido en un archivo de log. La combinación de atributos suele ser más informativa que el evento aislado.

Contexto del host. El mismo cambio en un servidor expuesto, en un equipo de escritorio o en un nodo de base de datos implica riesgos distintos. El host aporta el marco de exposición y ayuda a priorizar.

Momento del cambio. Cambios fuera de horario de mantenimiento, durante un despliegue conocido o en paralelo a una ventana de cambios autorizada tienen lecturas diferentes. Correlacionar el evento con el calendario operacional reduce falsos positivos sin apagar la detección.

Leer un evento FIM con estas cuatro dimensiones permite pasar de "hubo un cambio" a "hubo un cambio en un activo crítico, con atributos sensibles, en un host expuesto y fuera de ventana autorizada". Esa frase es operable; la primera no.

Por qué FIM genera ruido y qué errores frecuentes lo producen

El ruido en FIM casi nunca proviene de la herramienta, sino de decisiones de configuración y operación que se toman una vez y no se revisan. Los patrones más frecuentes:

Sobrecobertura sin criterio. Vigilar directorios completos "por si acaso" —rutas de sistema, directorios de aplicaciones, volúmenes de datos— genera volúmenes que ningún equipo puede revisar. La cobertura amplia sin clasificación previa produce eventos que se archivan sin análisis, lo que equivale a no tener FIM para efectos de detección.

Cambios legítimos no clasificados. Despliegues, actualizaciones de paquetes, rotación de logs, tareas de backup y procesos de aplicaciones modifican archivos de forma esperada. Si esos cambios no están identificados como legítimos y excluidos o etiquetados, cada ciclo operativo normal genera una ráfaga de alertas que compite con las que sí importan.

Ausencia de criterio de priorización. Cuando todos los eventos llegan con el mismo peso, el equipo termina priorizando por volumen o por costumbre, no por riesgo. Sin una noción de criticidad por ruta, host y atributo, la cola de eventos crece más rápido de lo que se resuelve.

Falta de revisión periódica. Las rutas críticas cambian: aparecen nuevos servicios, se retiran otros, se modifican permisos de forma legítima. Una configuración FIM que no se revisa acumula desajustes entre lo que se vigila y lo que realmente importa.

Confundir detección con investigación. FIM detecta; no investiga. Si el equipo no tiene un procedimiento para tomar un evento, validar si el cambio fue autorizado y cerrarlo con una conclusión, el sistema produce registros pero no reduce incertidumbre.

El efecto acumulado es el mismo: el equipo deja de mirar FIM porque aprendió que casi todo lo que reporta es ruido. En ese punto, un cambio no autorizado real pasa desapercibido entre eventos que nadie revisa.

Buenas prácticas y límites para mantener la señal útil

Mantener FIM como fuente de señal útil requiere decisiones sostenidas, no una configuración única.

Ajustar el alcance por criticidad, no por completitud. Es preferible vigilar pocas rutas con criterio claro que muchas sin clasificación. La cobertura se amplía cuando el equipo puede absorberla, no antes.

Clasificar rutas y hosts antes de activar reglas. Definir qué es crítico, qué es operativo y qué es descartable permite asignar prioridades desde el diseño y no en caliente.

Documentar los cambios legítimos. Ventanas de despliegue, tareas programadas y procesos conocidos que modifican archivos deben estar identificados. Esto no elimina la detección: la contextualiza.

Revisar la configuración con periodicidad. Una revisión trimestral de rutas vigiladas, exclusiones y reglas evita que la configuración se desalinee de la operación real.

Definir un procedimiento de cierre. Cada evento relevante debería terminar en una conclusión: cambio autorizado, cambio no autorizado, falso positivo o pendiente de investigación. Sin cierre, el evento se acumula.

Reconocer los límites del propio FIM. FIM observa cambios en archivos y atributos; no interpreta intención, no reemplaza controles de acceso, no cubre actividad que no toca el sistema de archivos y no sustituye la correlación con otras fuentes. Presentarlo como una capacidad total de detección de cambios no autorizados es un error de expectativas que suele terminar en desuso.

En organizaciones que se preparan para exigencias de trazabilidad —por ejemplo, frente a marcos normativos como la Ley 21.719—, FIM aporta evidencia de cambios sobre activos relevantes. Eso contribuye a la preparación y a la trazabilidad, pero no constituye por sí solo una garantía de cumplimiento.

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

Antes de ampliar cobertura o sumar rutas, conviene responder algunas preguntas operacionales:

• ¿Qué rutas y hosts son críticos para la operación y para la seguridad, y están efectivamente cubiertos?
• ¿El equipo puede explicar, para un evento reciente, si el cambio fue autorizado o no?
• ¿Cuántos eventos FIM se generan por semana y cuántos se cierran con conclusión?
• ¿Existen cambios legítimos recurrentes que aún no están clasificados?
• ¿Hay un procedimiento definido para investigar y cerrar un evento?

Si la mayoría de las respuestas apunta a incertidumbre, el problema no es la herramienta: es el criterio operacional con el que se configura y se lee. Ahí suele tener sentido apoyarse en un esquema gestionado. Wazuh como Servicio permite operar FIM con alcance definido, revisión periódica y un procedimiento de cierre, en lugar de acumular eventos sin resolución.

El objetivo no es vigilar más, sino que cada evento que llega tenga una razón para ser revisado y una vía para cerrarse. Cuando eso ocurre, FIM deja de ser una fuente de ruido y pasa a ser una capacidad real de observación de cambios no autorizados.