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:
-
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) -
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) -
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