Playbook de SIEM: aplicabilidad en implementaciones con #Wazuh

Desde Segu-Info hace varios años implementamos Wazuh como solución SIEM/XDR Open Source en clientes de la región. Y, algo que aprendimos rápido es que la herramienta, por más completa que sea, necesita método: reglas sueltas no son detección, alertas dispersas no son incidentes. La diferencia entre un Wazuh productivo y uno que termina apagado por ruido suele estar en si hay (o no) un catálogo de casos de uso documentado, mapeado a MITRE ATT&CK, revisable y comunicable al cliente.

Por eso nos resultó útil el documento 2026 SIEM Use Case Engineering Playbook de Izzmier Izzuddin, difundido recientemente. Es un compendio gratuito de 100 casos de uso pensados para SIEM modernos, agnóstico de plataforma —los ejemplos están en KQL, SPL, Sigma y EQL— pero perfectamente traducible a Wazuh mediante reglas XML, decoders y grupos de agentes.

El playbook no es simplemente una lista de reglas; es una metodología completa que describe escenarios de amenazas realistas, identifica los logs requeridos, define bloques constructivos reutilizables, establece la lógica de detección y guía al analista desde la alerta hasta la contención.

El playbook se organiza en tres partes. 

La primera define una metodología de detection engineering para 2026: cada caso de uso no es un trigger aislado sino una cadena Use Case → Rule → Alert → Incident → Tuning. 

La segunda lista los 100 casos en 10 categorías: identidad y accesos, accesos privilegiados/AD/PAM, correo y BEC, endpoint y malware con Living-off-the-Land, ransomware, cloud/SaaS/OAuth/no humanos, API y web, red y threat intel, fuga de datos y seguridad de IA, y gobierno/criptografía. 

La tercera —la más extensa— desarrolla cada caso como blueprint: escenario, telemetría requerida, building blocks aplicables, lógica de detección, nombre de alerta e incidente, y pasos de triage.

Lo valioso del documento no es la lista —muchos casos ya están cubiertos en cualquier SOC maduro— sino dos aportes: un catálogo de 12 Building Blocks reutilizables (usuarios privilegiados, activos críticos, IOCs, identidades no humanas, permisos OAuth de alto riesgo) y la insistencia en que cada detección lleve contexto de entidad, de negocio y vía de respuesta documentada. Eso separa un SIEM operativo de un generador de ruido.

Para los equipos que ya operan Wazuh, el playbook se vuelve aprovechable en tres planos.

Contexto y mapeo de capacidades. Los 100 casos atraviesan superficies que Wazuh cubre nativamente, Windows Security, syslog, FIM, detección de vulnerabilidades, y otras que requieren extender la plataforma. Mapear cada caso a "qué decoder, qué fuente, qué módulo" da una foto muy clara de la cobertura real de cada implementación, que es la respuesta concreta a "¿qué estamos detectando hoy?". En nuestros clientes lo armamos como una matriz: caso del playbook, regla Wazuh activa, fuente de log, estado (activo, pendiente o no aplica). Solo ese ejercicio ya ordena.

Aplicaciones prácticas en distintos niveles. El playbook se presta a una adopción progresiva. En un primer nivel hay casos accionables sin tocar la arquitectura: brute force con éxito posterior, PowerShell lanzado desde Office, herramientas de seguridad deshabilitadas, indicadores de ransomware vía FIM masivo. Todo eso se traduce a reglas XML con decoders nativos. Un nivel más arriba, casos como C2 beaconing, DNS tunnelling o detección de webshells exigen sumar sensores complementarios —Zeek y Suricata para red, Osquery o Falco para host— centralizados en Wazuh.

En entornos híbridos, los casos de OAuth, MFA fatigue o conditional access modificado se cubren con los módulos oficiales de Wazuh para Microsoft 365, AWS y Google Workspace. Para equipos más maduros, los Building Blocks se materializan como CDB Lists y grupos de agentes, habilitando reglas y active responses diferenciados según la criticidad del activo.

Organización, capacitación y propuesta de valor. Quizás la contribución más subestimada del playbook sea organizativa. Cada blueprint incluye nombre de alerta, nombre de incidente y pasos de triage: insumo directo para armar SOPs estandarizados, catálogos de reglas por cliente y planes de capacitación segmentados por categoría. Y, sobre todo, da el vocabulario para comunicar valor: un reporte mensual con mapeo MITRE ATT&CK 2026 y un Use Case Coverage Score sobre los 100 casos del playbook eleva la conversación con el cliente desde "tenemos alertas" hacia "cubrimos X% del marco vigente".

Niveles de Implementación en Wazuh

Nivel 1: Activación Inmediata

Los casos de alta prevalencia en clientes PyME y enterprise son accionables de inmediato. El playbook identifica casos prioritarios como:

• UC-001: Múltiples fallos de login seguidos de éxito (EventID 4625+4624 de Windows, syslog SSH)
• UC-036: Office spawns PowerShell (Sysmon EventID 1)
• UC-046: Herramientas de seguridad deshabilitadas (Wazuh FIM + Windows 4688)
• UC-048-051: Indicadores de ransomware (cambios masivos en FIM, evento VSS 8222)
• UC-079-080: IPs/dominios maliciosos (integración Wazuh con VirusTotal/AbuseIPDB)

Por ejemplo, la detección de múltiples inicios de sesión fallidos seguidos de un acceso exitoso (UC-001) se resuelve de forma eficiente combinando los decodificadores de eventos del canal de seguridad de Windows (EventID 4625 y 4624) y Syslog en entornos Linux. De igual manera, comportamientos como la inhabilitación maliciosa de herramientas de seguridad en el endpoint (UC-046) o los precursores de actividad de ransomware (UC-048 al UC-051) pueden cubrirse habilitando el módulo de monitorización de integridad de archivos (FIM) de Wazuh en conjunto con la auditoría de ejecución de procesos nativa.

Estos casos pueden implementarse rápidamente aprovechando la telemetría que Wazuh ya recolecta de forma nativa.

Nivel 2: Integración de Sensores Open Source

Para casos que requieren telemetría que Wazuh no cubre por defecto, el playbook sugiere incorporar herramientas maduras de código abierto:

Herramientas complementarias

Al emplear Wazuh como orquestador central, la ingesta de telemetría de sistemas NIDS como Suricata o Zeek permite detectar escaneos de puertos internos (UC-082) o patrones de balizamiento C2 (UC-081). A nivel de host, integrar los resultados de Osquery o Falco facilita la identificación de la creación encubierta de servicios remotos (UC-020) y la inyección en la memoria LSASS (UC-045) al mapear su formato JSON contra reglas de alerta específicas.

Aquí aparecen escenarios como:Beaconing de C2 y patrones de comunicación anómalos

• DNS tunneling
• Escaneo interno de red
• Persistencia en endpoint (scheduled tasks, registry keys)
• Ejecución remota sospechosa

Esta integración amplía significativamente la cobertura sin incurrir en costos de licenciamiento comercial.

Nivel 3: Cobertura Cloud y SaaS

Los casos UC-056 a UC-068 (Cloud/OAuth/SaaS) y UC-087 a UC-096 (Data Leakage) requieren ingestión de logs desde plataformas cloud. Wazuh soporta esto mediante:

1. Módulo office365: Para Microsoft 365/Entra ID, cubriendo casos como MFA Fatigue (UC-003), reglas de reenvío de mail (UC-029), y modificación de Conditional Access (UC-063)
2. Custom integration vía AWS Lambda + Wazuh API: Para AWS CloudTrail/GuardDuty, detectando deshabilitación de logging (UC-064) o asignación de roles admin (UC-065)
3. Módulo Google Workspace (desde v4.6): Para casos como invitados agregados a workspace (UC-066) o modificación de políticas DLP (UC-068)

Estas detecciones requieren integración con Microsoft 365, Entra ID, AWS o Google Workspace, lo cual Wazuh soporta mediante módulos nativos o integraciones personalizadas.

Wazuh cubre esta superficie mediante sus módulos de integración. Al recolectar eventos de Microsoft 365 y Entra ID, es posible detectar intentos de fatiga de MFA (UC-003) y la alteración de políticas de acceso condicional (UC-063). Paralelamente, las integraciones con Google Workspace y AWS CloudTrail (vía configuraciones custom o nativas) habilitan la auditoría sobre la adición de usuarios invitados a espacios confidenciales (UC-066) o la deshabilitación fraudulenta del registro de auditoría en la nube (UC-064).

En este nivel, la aplicabilidad en Wazuh depende de la ingesta de logs externos:

• Abuso de MFA (fatiga de autenticación)
• Reglas de forwarding en correo
• Delegaciones indebidas de acceso
• Cambios en políticas de acceso condicional
• Asignación de roles administrativos en cloud

Nivel 4: Building Blocks como Activo de Servicio

El componente arquitectónico más valioso que aporta el playbook es la definición de doce Building Blocks. En lugar de generar reglas complejas y codificadas rígidamente para cada alerta, se propone crear bloques de contexto reutilizables, como "Usuarios Privilegiados" o "Activos Críticos".

• CDB Lists: "privileged_users.txt", "critical_assets.txt", "approved_scanners.txt"
• Grupos de agentes: "domain_controllers", "payment_systems" para aplicar reglas selectivas por criticidad
• Active Responses diferenciadas: Respuesta automática solo sobre activos críticos definidos

En Wazuh, esta abstracción técnica se logra mediante el uso extensivo de Listas CDB (Constant DataBase). Manteniendo archivos de texto actualizados (como privileged_users.txt), el motor de reglas puede consultar dinámicamente si la IP o el usuario asociado a un evento requiere elevar la severidad de la alerta. Adicionalmente, el uso de Agent groups permite segmentar Respuestas Activas, aislando un servidor únicamente si este ha sido previamente categorizado como crítico dentro de la topología de red.

Mantener estos building blocks actualizados se convierte en un entregable mensual medible con acta de revisión firmada.

Adoptar este nivel de rigor transforma la dinámica del monitoreo de seguridad. Permite abandonar la reactividad generada por el ruido de eventos aislados para pasar a una gestión táctica, en la que se demuestra madurez midiendo de forma objetiva qué porcentaje del framework MITRE ATT&CK se encuentra formalmente resguardado.

Una aclaración necesaria: el playbook no es un manual de Wazuh ni reemplaza la implementación. Lo que aporta es metodología: una forma de pensar la detección por casos de uso, con building blocks reutilizables, contexto de negocio y métricas de cobertura. Cualquier equipo que opere un SIEM —Wazuh, Splunk, Sentinel u otro— puede destilar valor del documento sin más esfuerzo que el de leerlo con criterio.

Para realidades latinoamericanas, donde los presupuestos son acotados y los equipos suelen ser pequeños, buena parte del catálogo es aplicable con lo que ya tenemos instalado, y el resto se cubre con sensores open source maduros sin costos de licencia. Vale la pena descargarlo, leerlo entero y usarlo como check de madurez sobre cada implementación. No reemplaza experiencia ni ingeniería, pero ordena —y ordenar es, muchas veces, el primer paso para detectar mejor—.

El documento no reemplaza la implementación de Wazuh, sino que la complementa con una metodología probada. Su mayor valor para organizaciones que operan Wazuh es triple: proporciona vocabulario común para comunicar valor de seguridad, ofrece estructura para escalar detecciones de forma consistente, y establece métricas objetivas de cobertura de detección.

Agradecemos a Izzmier Izzuddin por la compilación y la difusión del material.

Por Segu-Info

Suscríbete a nuestro Boletín