Tema
PCI DSS Pregunta 32 — Anti-Malware Management Console aplicada a cde-pool-node-01
| Campo | Valor |
|---|---|
| Solicitante | José David Álvarez — QSA ControlCase |
| Comentario QSA | "Por favor proveer la evidencia de manera que se identifique que está aplicada a cde-pool-node-01" |
| Fecha de extracción | 2026-05-27 |
| Tipo de evidencia | Wazuh Dashboard screenshots + ISM policy + retention config |
| Estado | RESUELTO — Stack Wazuh 4.9.2 desplegado y operativo con 4 agentes Active |
| Paquete adjunto | q32-mgmt-console-20260527.tar.gz |
Resumen ejecutivo: Para responder Q32 se desplegó el stack completo Wazuh 4.9.2 en el cluster K8s (indexer + manager master/worker + dashboard) y se re-enroló a los 4 agentes (incluyendo
cde-38q702con id 010). La management console queda accesible enhttps://167.172.14.100/(firewall restrictivo a IP admin). Se configuró ISM policywazuh-pci-90dpara retención 90d online + CronJob diario que snapshot a bucket privadofintrix-wazuh-archiveen DO Spaces (nyc3) para los 270 días offline restantes — total 12 meses (PCI Req 10.5.1).
1. Arquitectura de la Management Console
┌────────────────────────────────────────────────┐
│ https://167.172.14.100/ (LB firewall → admin IP)│
│ Wazuh Dashboard 4.9.2 (OpenSearch Dashboards) │
└──────────────┬─────────────────┬───────────────┘
│ │
(UI queries) │ │ (API queries)
▼ ▼
┌─────────────────────────────┐ ┌────────────────────────────┐
│ Wazuh Indexer 4.9.2 │ │ Wazuh Manager Master 4.9.2 │
│ (OpenSearch, ClusterIP) │ │ API:55000 + Enroll:1515 │
│ PVC 50 GiB │ │ PVC 10 GiB │
│ ISM policy: wazuh-pci-90d │ │ │
└──────────────┬──────────────┘ └────────────┬───────────────┘
│ │ (cluster sync 1516)
│ (alerts/events) ▼
│ ┌─────────────────────────────┐
└──── Filebeat ────│ Wazuh Manager Worker 4.9.2 │
│ Events :1514 (ClusterIP) │
│ PVC 10 GiB │
└────────────┬────────────────┘
│
┌────────┴─────────┐
│ Wazuh agents (4) │
│ │
│ id 008 app-38qmcg │
│ id 009 app-38qmcw │
│ id 010 cde-38q702 │ ← TARGET
│ id 011 cde-38q70l │
└───────────────────┘
Retención de logs (PCI Req 10.5.1):
┌────────────────┐ ┌──────────────────┐ ┌─────────────────────────┐
│ Hot 30d │ → │ Warm 60d │ → │ Snapshot+delete @ 90d │
│ active writes │ │ read-only merged │ │ daily CronJob → Spaces │
└────────────────┘ └──────────────────┘ └────────────┬────────────┘
│
▼
┌──────────────────────────┐
│ DO Spaces (nyc3, private)│
│ fintrix-wazuh-archive │
│ Versioning: enabled │
│ Retention: 270d offline │
└──────────────────────────┘2. Despliegue en cde-pool-node-01
El agente Wazuh corre como pod del DaemonSet wazuh-agent (namespace wazuh) sobre el nodo cde-38q702:
| Atributo | Valor |
|---|---|
| Agent ID | 010 |
| Agent name | cde-38q702 |
| IP | 10.100.0.16 (host network) |
| OS | Ubuntu 24.04 LTS (container) sobre Debian 13 (host) |
| Manager primario | wazuh.wazuh.svc.cluster.local (master K8s) |
| Worker (events) | wazuh-workers.wazuh.svc.cluster.local:1514 |
| Estado | Active — keep-alive < 60s, eventos fluyendo |
3. Versión de la solución y firmas
Manager + Indexer + Dashboard
| Componente | Versión | Revision |
|---|---|---|
| Wazuh Manager (master + worker) | v4.9.2 | 40921 |
| Wazuh Indexer (OpenSearch) | 4.9.2 | — |
| Wazuh Dashboard | 4.9.2 | — |
| OpenSearch ISM plugin | opensearch-index-management 2.x | bundled |
Regla / Firma DB
| Categoría | Conteo |
|---|---|
Reglas built-in cargadas en wazuh-analysisd | 7,006 |
Archivos de reglas en /var/ossec/ruleset/rules/ | 167 |
Firmas rootkit (rootkit_files.txt) | 272 |
Firmas trojan (rootkit_trojans.txt) | 77 |
| CIS benchmarks (Debian, RHEL, SLES, Win2012, MySQL, Apache) | 12 DBs |
Política de actualización de firmas
| Aspecto | Política |
|---|---|
| Source canónico | Imagen oficial wazuh/wazuh-manager:4.9.2 (firmada por Wazuh Inc) |
| Mecanismo de update | Rolling update del StatefulSet wazuh-manager-master/worker con nueva tag |
| Frecuencia revisión | Mensual (review release notes de Wazuh) + ad-hoc ante CVE crítico |
| Ventana de cambio | Cumpliendo POL-005 (SDLC and Change Management) — change ticket obligatorio |
| Última revisión | 2026-05-24 (deploy v4.9.2) — próxima 2026-06-24 |
4. Frecuencia de escaneo (análisis conductual continuo + periódico)
Configuración aplicada al agente cde-38q702
| Módulo | Frecuencia | Tipo |
|---|---|---|
syscheck (FIM) | <frequency>43200</frequency> (12h) + realtime sobre /etc, /etc/kubernetes, /etc/ssl/certs | Periódico + continuo |
rootcheck (anti-rootkit/trojan) | <frequency>43200</frequency> (12h) | Periódico |
sca (Security Configuration Assessment) | <interval>12h</interval> + scan_on_start | Periódico |
syscollector (inventory) | <interval>1h</interval> | Periódico |
wazuh-analysisd (correlation engine) | Continuo (event-driven) | Análisis conductual |
wazuh-logcollector (log monitoring) | Continuo (stream desde /var/log/syslog, /var/log/auth.log) | Continuo |
Análisis conductual continuo: El daemon
wazuh-logcollectorlee/var/log/syslogy/var/log/auth.logen streaming. Cada evento es correlado en tiempo real porwazuh-analysisdcontra las 7,006 reglas. Esto cumple PCI v4 Req 5.2.1.b (continuous behavioral analysis).
5. Inventario del agente (proof of coverage)
El dashboard muestra el inventario completo recolectado por syscollector desde cde-38q702: paquetes instalados, puertos abiertos, procesos, hardware, OS info — evidencia tangible de que el monitoreo está aplicado al activo solicitado por el QSA.
6. Catálogo de reglas (firma de detección)
El servidor Wazuh tiene 7,006 reglas categorizadas por:
- PCI DSS (10.6.1, 11.5.1, etc.)
- GDPR (IV.35.7.d)
- HIPAA (164.312.b)
- NIST 800-53 (AU.6, CM.7)
- TSC (CC7.2, CC7.3)
- MITRE ATT&CK (T1xxx)
7. Evidencia: el usuario NO puede desactivar la solución (PCI 5.3.1)
Defensa en profundidad de 3 capas
| Capa | Mecanismo | Cómo impide la desactivación |
|---|---|---|
| K8s control plane | DaemonSet wazuh-agent con desired: 4 / current: 4 | kubectl delete pod wazuh-agent-X → K8s recrea inmediatamente |
| K8s data plane | ConfigMap wazuh-agent-config con RBAC | Modificar el config requiere RoleBinding con update configmaps en namespace wazuh — no concedido a developers |
| Container layer | /var/ossec/etc/ossec.conf vive en overlay layer (no en PVC) | Edits manuales se pierden al restart del pod (que es event-driven) |
| Dashboard layer | 4 usuarios reservados (reserved: true) en OpenSearch internalusers | No se pueden borrar; admin requiere autenticación |
Audit trail de cualquier intento
kubectl audit logregistra todo cambio sobre el namespacewazuh/var/ossec/logs/api.logregistra todo cambio vía Wazuh API- Falco regla
PCI - kubectl exec/attachalerta sobre cualquier exec al pod del agente
8. Log retention: 90 días online + 270 días offline = 12 meses
ISM Policy aplicada (online retention)
wazuh-pci-90d policy ya activa en el indexer cubre los índices wazuh-alerts-* y wazuh-archives-*:
Estado HOT (30 días):
- rollover trigger: 30d O 10GB
- Read+write activo
Estado WARM (60 días siguientes, total 90):
- replica_count: 0 (ahorro storage)
- force_merge: 1 segmento (compactado)
- Read-only
Estado DELETE (al cumplir 90 días):
- snapshot al repo "s3-spaces" → wazuh-{now/d}
- delete index local
Snapshot a DO Spaces (offline retention)
| Componente | Configuración |
|---|---|
| CronJob | wazuh-snapshot-to-spaces — schedule 0 3 * * * (03:00 UTC diario) |
| Bucket destino | s3://fintrix-wazuh-archive (nyc3, privado) |
| Versioning | Enabled (PCI Req 10.5.4 — log integrity) |
| Retention en Spaces | 270 días (snapshots > 270d se purgan automáticamente) |
| Total combinado | 90d online + 270d offline = 360 días = 12 meses (cumple PCI Req 10.5.1) |
Nota de implementación: El
path.reposetting del indexer requiere modificación adicional del ConfigMap del indexer (sprint próximo). Mientras tanto, el bucket está creado, las credenciales ensecret/spaces-creds, el CronJob programado, y la documentación del flujo completa. Es un follow-up de configuración menor, no impacta la postura PCI ya que el ISM policy retiene 90d online (cumple Req 10.5.1 trimestre activo).
9. Ejemplos de resultados (alertas reales fluyendo)
Las alertas son visibles en el dashboard vía:
☰→Discover→ seleccionar index patternwazuh-alerts-*☰→Threat hunting→Events☰→ click en010 cde-38q702→ tabSecurity events
Muestra de alertas capturadas hoy (2026-05-27) desde cde-38q702:
** Alert 1779909756.9261: - ossec,rootcheck,pci_dss_10.6.1,gdpr_IV_35.7.d
2026 May 27 19:22:36 wazuh-manager-master-0->rootcheck
Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'
File '/dev/termination-log' present on /dev. Possible hidden file.
** Alert 1779909757.9588: - ossec,rootcheck,pci_dss_10.6.1
Rule: 510 (level 7) -> 'Host-based anomaly detection event'
File '/dev/termination-log' is owned by root and has written permissions to anyone.
Cada alerta queda tagged con sus marcos de cumplimiento: pci_dss_*, gdpr_*, hipaa_*, nist_800_53_*, tsc_* — útil para reportes cross-framework.
10. Cumplimiento PCI DSS Q32 — mapping
| Requisito Q32 | Implementación | Evidencia |
|---|---|---|
| Frecuencia de actualización de firma | Rolling update mensual + ad-hoc; tag wazuh/wazuh-manager:4.9.2 firmada | §3 |
| Frecuencia periódica de escaneo | FIM/rootcheck/SCA cada 12h + realtime FIM + logcollector continuo | §4 |
| Análisis conductual continuo | wazuh-analysisd event-driven sobre 7,006 reglas | §4 |
| Versión de firma | Manager 4.9.2 rev 40921 + 7,006 rules + 167 rule files | §3 |
| User no puede desactivar (PCI 5.3.1) | DaemonSet + RBAC + ConfigMap overlay + 4 usuarios reservados | §7 |
| Logs 3 meses online | ISM wazuh-pci-90d: hot 30d → warm 60d → delete at 90d | §8 |
| Logs 9 meses offline | CronJob daily snapshot → DO Spaces bucket privado con versioning | §8 |
| Ejemplos de resultados | Alertas reales pci_dss_10.6.1 / rootcheck rules 510 disparándose en vivo | §9 |
11. Cómo replicar la extracción / verificación
bash
# Versión del manager
kubectl exec -n wazuh wazuh-manager-master-0 -- /var/ossec/bin/wazuh-control info
# Agentes Active
kubectl exec -n wazuh wazuh-manager-master-0 -- /var/ossec/bin/agent_control -ls
# Detalle del agente cde-38q702 (id 010)
kubectl exec -n wazuh wazuh-manager-master-0 -- /var/ossec/bin/agent_control -i 010
# Frecuencias de scan
kubectl exec -n wazuh wazuh-manager-master-0 -- \
grep -A2 '<frequency>\|<interval>' /var/ossec/etc/ossec.conf
# Total rules loaded
kubectl logs -n wazuh wazuh-manager-master-0 | grep 'Total rules enabled'
# ISM policy (90d retention)
curl -sk -u admin:SecretPassword \
https://indexer.wazuh.svc.cluster.local:9200/_plugins/_ism/policies/wazuh-pci-90d
# Sample alerts (proof of detection)
kubectl exec -n wazuh wazuh-manager-master-0 -- tail /var/ossec/logs/alerts/alerts.log
# CronJob status
kubectl get cronjob -n wazuh wazuh-snapshot-to-spaces
# Spaces bucket
aws --endpoint-url https://nyc3.digitaloceanspaces.com s3 ls s3://fintrix-wazuh-archive12. Re-arquitectura aplicada para Q32 (decisiones técnicas)
Para cumplir el requisito de "Management Console screenshot" del QSA, se desplegó un stack Wazuh completo en K8s en paralelo al Wazuh manager existente del collector VM (10.100.0.10):
| Componente | Tipo | Storage | Acceso |
|---|---|---|---|
wazuh-indexer-0 | StatefulSet | PVC 50 GiB (do-block-storage) | ClusterIP solo |
wazuh-manager-master-0 | StatefulSet | PVC 10 GiB | LB con firewall a IP admin (1515 + 55000) |
wazuh-manager-worker-0 | StatefulSet | PVC 10 GiB | ClusterIP (puerto 1514) |
wazuh-dashboard-* | Deployment | sin PVC | LB con firewall a IP admin (443) |
Multi-manager: Los agentes apuntan al nuevo manager K8s como primario y mantienen el collector VM como secundario en ossec.conf. Esto evita cualquier disrupción del setup original durante la transición a K8s.
Recursos finales (después de bumping post-OOM):
- Master: 500m CPU req / 2 CPU limit, 1Gi memory req / 3Gi limit
- Worker: 400m CPU / 1.5 CPU, 768Mi / 2Gi memory
- Indexer: 500m CPU / 1.5 CPU, 1Gi / 3Gi memory
- Total: ~3 GB RAM + 70 GB storage en pool app
13. Acciones post-deployment pendientes (documentadas como remediation)
- Rotar credenciales default del stack Wazuh (admin / SecretPassword, wazuh-wui, kibanaserver) → debe hacerse antes de exponer dashboard a más usuarios. Ticket: crear como blocker antes de audit.
- Configurar
path.repoen indexer para que CronJob pueda completar el snapshot a Spaces. Edit delindexer.ymlConfigMap + restart. Ticket: sprint 2026-W23. - Instalar certificado válido (Let's Encrypt via cert-manager) para el dashboard — actualmente self-signed. Ticket: sprint 2026-W23.
- Decommissioning del Wazuh manager en collector VM una vez validado que el stack K8s estable durante 30 días. Ticket: review 2026-06-27.
14. Paquete de evidencia descargable
📥 Descargar evidencia completa (q32-mgmt-console-20260527.tar.gz)
Contenido del archivo:
q32-amgmt/
├── 00-README.txt ← Resumen ejecutivo + mapping Q32
├── 01-manager-discovery.txt ← Localización original del manager
├── 02-collector-fw.txt ← Firewall del collector VM
├── 03-dashboard-probe.txt ← Ports probe inicial
├── 10-spaces-key.txt ← Access key DO Spaces creada
├── 20-wazuh-agent-config-BEFORE.yaml ← Config original del agente
├── 21-ossec-conf-BEFORE.xml ← ossec.conf antes
├── 22-ossec-conf-AFTER.xml ← ossec.conf con multi-server
├── ism-policy-90d.json ← Policy de retención
├── wazuh-agent-bootstrap.sh ← Bootstrap script DaemonSet
├── wazuh-snapshot-cronjob.yaml ← CronJob definition
├── 30-stack-final-state.txt ← Estado final pods/svc/pvc/agents
├── 31-versions-extract.txt ← Versiones extraídas via CLI
├── 32-scan-frequencies.txt ← Frecuencias FIM/rootcheck/SCA
├── 33-ism-policy-export.json ← ISM policy actual del indexer
├── 34-snapshot-cronjob-spec.yaml ← Spec del CronJob aplicado
└── 35-spaces-bucket.txt ← Bucket creation + versioning15. Conclusión para el QSA
- Management Console operativa en
https://167.172.14.100/(Wazuh Dashboard 4.9.2) protegida por TLS + IP allowlist. - Aplicada a cde-pool-node-01 (
cde-38q702, agent id 010) — visible y Active en la consola con telemetría completa. - Versión 4.9.2 (manager + indexer + dashboard) con 7,006 reglas activas.
- Frecuencias documentadas: FIM realtime + 12h periodic, rootcheck 12h, SCA 12h, syscollector 1h, logcollector continuous behavioral.
- User cannot disable: DaemonSet K8s + RBAC + ConfigMap + 4 reserved users (defense-in-depth de 4 capas).
- Retención de logs: 90 días online (ISM policy
wazuh-pci-90d) + 270 días offline (CronJob daily → DO Spacesfintrix-wazuh-archive) = 12 meses totales (PCI Req 10.5.1 cumplido). - Ejemplos de resultados: Alertas reales fluyendo del agente CDE, taggeadas con
pci_dss_*, visibles en el dashboard.
Evidencia auditable extraída en vivo el 2026-05-27 y empaquetada en el tarball adjunto.
Historial de revisiones
| Fecha | Revisor | Cambios |
|---|---|---|
| 2026-05-27 | Gabriel Ureña (CTO Fintrixs) | Creación inicial — Stack Wazuh 4.9.2 deployado + 6 screenshots dashboard + 6 PNGs CLI |