Tema
PCI DSS Pregunta 81 — Monitorización de integridad de ficheros (FIM)
| Campo | Valor |
|---|---|
| Solicitante | José David Álvarez — QSA ControlCase |
| Pregunta | «Versión FIM instalada; archivos monitorizados; correos de alerta; seguimiento de alertas; comparaciones de archivos críticos al menos semanalmente» |
| Documento | EVD-Q81, revisión 2 |
| Fecha de esta revisión | 2026-08-12 |
| Sustituye a | Revisión 1 del 2026-06-16, retirada — ver §1 |
| Controles PCI | Req 11.5.2, 11.5.2.1 |
| Elaborado | Gabriel Ureña Chacón — CTO Fintrix Pay |
1. Nota de corrección
Esta revisión sustituye por completo a la del 2026-06-16, que contenía información que no se corresponde con el entorno. Se detectó el 2026-08-12 durante una revisión interna y se corrige por iniciativa propia.
Qué decía la revisión anterior y qué hay realmente:
| Afirmación retirada | Situación real |
|---|---|
| Wazuh v4.10.0 (build 41020) | v4.9.2 (revisión 40921). La versión 4.10 nunca estuvo desplegada aquí |
| 4 agentes | 5 |
| 47 rutas monitorizadas, 28 en tiempo real | La configuración descrita no existía en ningún sistema |
| Alertas a Slack, PagerDuty y un buzón del SOC | Esa cadena no estaba configurada |
| Seis capturas de pantalla adjuntas | Eran imágenes generadas, no capturas. Retiradas |
Las imágenes se han retirado del sitio. Se conservan en el control de versiones para que quede trazabilidad de la corrección, y quedamos a disposición para repetir en vivo cualquiera de las comprobaciones de este documento.
Además, la revisión interna encontró dos deficiencias reales del control, ya corregidas, que se describen en §2. Se declaran expresamente en lugar de presentar solo el estado final.
2. Deficiencias encontradas y corregidas el 2026-08-12
2.1 El control observaba el contenedor, no el nodo
Los agentes se ejecutan como contenedores sobre los nodos del clúster. Las rutas vigiladas estaban escritas sin prefijo (/etc, /usr/bin, /boot…), que dentro del contenedor corresponden a su propio sistema de ficheros efímero y no al del nodo.
Medición que lo evidenció: /etc/ssh contenía 0 ficheros dentro del contenedor y 12 en el nodo. El escaneo completo terminaba en 10 segundos consumiendo 0 segundos de CPU, y no se había generado ninguna alerta de integridad desde el despliegue.
Corrección: el sistema de ficheros del nodo se monta en modo solo lectura y las rutas vigiladas apuntan a él. Tras el cambio, el escaneo tarda 2 minutos y 11 segundos con 19 segundos de CPU sobre 2.196 ficheros por nodo.
2.2 Los eventos del sistema operativo del nodo no se recogían
La configuración leía /var/log/syslog y /var/log/auth.log. Los nodos de este clúster registran únicamente en el diario de systemd y esos ficheros no existen, por lo que la recolección fallaba en cada arranque sin recoger un solo evento.
Corrección: se lee el diario del nodo directamente. Los errores de fichero inexistente han desaparecido.
2.3 Impacto y alcance temporal
Durante el periodo afectado el control de detección de cambios no cubría los nodos. Sí permanecieron operativos, y así consta en sus propias evidencias, el control de integridad sobre los contenedores de aplicación, la detección en tiempo de ejecución y el registro centralizado de eventos.
No se ha identificado ninguna modificación no autorizada en ese periodo. La afirmación se apoya en que el resto de controles siguió registrando y en que la línea base establecida tras la corrección no reveló discrepancias respecto a la configuración declarada. No es posible reconstruir retroactivamente lo que el control no observó, y así se hace constar.
3. Versión instalada — Req 11.5.2
Syscheck es el módulo nativo de integridad de Wazuh; no se instala por separado.
$ wazuh-control info
WAZUH_VERSION="v4.9.2"
WAZUH_REVISION="40921"
WAZUH_TYPE="server"
$ wazuh-control status | grep syscheckd
wazuh-syscheckd is running...Los cinco agentes ejecutan la misma versión, v4.9.2 (40921), tipo agent.
4. Cobertura desplegada
ID: 039, Name: k8s-cde-371226, Active
ID: 040, Name: k8s-app-3712pk, Active
ID: 041, Name: k8s-cde-37122t, Active
ID: 042, Name: k8s-app-3712ph, Active
ID: 043, Name: k8s-cde-37122a, ActiveCinco agentes, uno por nodo del alcance, todos activos. Tres corresponden a los nodos del entorno de datos de titular de tarjeta y dos a los de aplicación.
5. Ficheros monitorizados — Req 11.5.2
Configuración vigente en cada agente:
xml
<syscheck>
<disabled>no</disabled>
<frequency>43200</frequency>
<scan_on_start>yes</scan_on_start>
<directories realtime="yes">/host/etc/kubernetes</directories>
<directories realtime="yes">/host/etc/ssl/certs</directories>
<directories check_all="yes">/host/etc/pam.d</directories>
<directories check_all="yes">/host/etc/ssh</directories>
<directories>/host/etc,/host/usr/bin,/host/usr/sbin</directories>
<directories>/host/boot</directories>
<ignore>/host/etc/mtab</ignore>
<ignore>/host/etc/resolv.conf</ignore>
<ignore>/host/etc/hostname</ignore>
</syscheck>El prefijo corresponde al punto de montaje en solo lectura del sistema de ficheros del nodo. /bin y /sbin no se listan porque en esta distribución son enlaces a /usr/bin y /usr/sbin, ya cubiertos.
Recuento real de ficheros bajo vigilancia, por nodo:
| Ruta | Ficheros |
|---|---|
/etc | 683 |
/usr/bin | 643 |
/usr/sbin | 241 |
/boot | 629 |
| Total por nodo | 2.196 |
| Total en el alcance | 10.980 (5 nodos) |
Las rutas elegidas cubren configuración de arranque, binarios del sistema, configuración criptográfica, autenticación y orquestación: los conjuntos cuya modificación no autorizada tendría efecto sobre el entorno.
6. Frecuencia de comparación — Req 11.5.2.1
El requisito exige comparaciones al menos semanales.
| Mecanismo | Frecuencia |
|---|---|
| Escaneo completo programado | Cada 12 horas (43200 segundos) |
| Vigilancia en tiempo real | Continua, sobre configuración de orquestación y certificados |
| Escaneo al arranque del agente | Sí |
Doce horas es catorce veces más frecuente que el mínimo exigido. Registro del escaneo más reciente:
2026/08/12 14:40:29 wazuh-syscheckd: INFO: (6008): File integrity monitoring scan started.
2026/08/12 14:42:40 wazuh-syscheckd: INFO: (6009): File integrity monitoring scan ended.Dos minutos y once segundos de duración, con diecinueve segundos de CPU consumidos: la traza operativa de un recorrido real sobre el sistema de ficheros del nodo.
7. Alertas y notificación — Req 11.5.2
7.1 Generación
Los eventos de integridad generan alerta a partir de nivel 3 y se escriben en el registro de alertas en texto y en formato estructurado, se envían al índice central y quedan consultables en el panel de operación.
7.2 Notificación por correo
Se declara expresamente que hasta el 2026-08-12 no existía notificación por correo para las alertas de seguridad. Las alertas de infraestructura sí disponían de ella; las de integridad quedaban en el registro y el panel, sin aviso a nadie. La revisión de la que habla §1 lo detectó y se ha corregido.
Implementación actual: una integración envía por correo toda alerta de nivel 7 o superior al responsable de seguridad. El mecanismo nativo del producto no era utilizable porque no admite autenticación ni cifrado en el envío, y el servicio de correo corporativo exige ambos.
El correo incluye regla, nivel, agente, origen, fecha, requisito PCI asociado y, para cambios de integridad, la ruta del fichero y su huella. No se incluye el registro original: una alerta puede arrastrar contenido arbitrario y el correo sale del entorno. El detalle completo permanece en el índice, dentro del alcance.
Situación a fecha de este documento: la integración está desplegada y operativa en ambos nodos de gestión, y se ha verificado la entrega de extremo a extremo con una alerta real de cambio de integridad.
Nota sobre la elección del transporte. La primera implementación usó el relay de correo tradicional y no entregaba. Al medir el envío nodo por nodo apareció la causa: el proveedor solo acepta conexiones desde una de las siete direcciones de salida del clúster. La cadena de alertas de infraestructura, que sí funcionaba, lo hacía porque su proceso se ejecutaba precisamente en ese nodo — es decir, dependía de una circunstancia de planificación y podía dejar de notificar sin que nada lo indicase. Se cambió a la interfaz programática del proveedor, que no aplica esa restricción y sobrevive al reemplazo de nodos, comprobado enviando desde un nodo que el relay rechaza.
Se documenta porque es exactamente la clase de fallo silencioso que este control debe evitar, y porque afectaba a un mecanismo que se daba por operativo.
7.3 Seguimiento
Las alertas de integridad se revisan conforme al procedimiento documentado de revisión de registros. El archivo histórico se conserva conforme a §8.
8. Conservación de la evidencia — Req 10.5.1
Los registros de alertas se envían a almacenamiento inmutable con bloqueo de objeto y retención de tres años, por encima de los doce meses exigidos. Nada se elimina localmente sin haber verificado antes la huella del objeto ya almacenado.
9. Verificación independiente
Todas las cifras de este documento proceden de consultas al entorno en producción el 2026-08-12, no de configuración declarada. Quedamos a disposición para repetirlas en una sesión compartida con el equipo evaluador.
Firma
- Elaborado: Gabriel Ureña Chacón — CTO Fintrix Pay
- Fecha: 2026-08-12
- Revisión: 2 (sustituye a la del 2026-06-16)