A playbook maps a Wazuh detection to an automated response — triage, threat-intel enrichment, ticketing, or a containment action (like blocking an IP). Enable the ones you want on the Playbooks page; each runs automatically on the alerts it matches.
Every alert that isn't filtered as noise is classified by severity and category and logged, so you always have a record — no enrichment and no case, just the audit trail. It's the catch-all so nothing falls through.
A test run evaluates a playbook against a sample alert and, if it matches, dispatches it in simulation — it reports what it would do and executes nothing against Wazuh. Use it to validate a playbook safely before arming it.
On the Playbooks page, use the on/off toggle on each card (admin only). Changes take effect immediately. A playbook shown dimmed with a chip isn't available on the selected environment's Wazuh version.
On the Playbooks page, use Manual response — block an IP or range: enter a single IP, a CIDR (…/24) or a range, choose the agent, and click Block now. Each IP is dropped individually (up to 256). This is available on Wazuh 4; on Wazuh 5 blocking is driven by a detection, so block the source from its alert instead.
A composite 0–100 score with a letter grade (A–F) across four dimensions — response readiness, alert-noise hygiene, detection coverage, and ingestion health. It's a heuristic indicator to track your posture over time and compare runs, not a compliance certification. The report explains what drives each sub-score and ties recommendations to the relevant playbooks.
On a Wazuh 5 environment, admins can drop high-volume findings before they reach triage — by rule id — from the Wazuh 5 noise suppression panel on the Playbooks page. Detection in Wazuh itself is untouched; a rule takes effect on the next collection cycle and can be toggled off at any time.
A few containment playbooks depend on platform capabilities that aren't available on Wazuh 5 agents yet. They run on Wazuh 4 today and stay dormant on Wazuh 5 — shown with the badge — until the platform supports them, at which point they light up automatically.
When a playbook opens a case, it's created in your configured ticketing integration (for example Jira). Enable and configure one on the Integrations page; without a ticketing integration the outcome is still recorded under Executions.
Un playbook asocia una detección de Wazuh a una respuesta automatizada — triage, enriquecimiento con threat-intel, ticketing o una acción de contención (como bloquear una IP). Habilita los que quieras en la página Playbooks; cada uno corre automáticamente sobre las alertas que matchea.
Toda alerta que no se filtra como ruido se clasifica por severidad y categoría y se registra, así siempre tienes el rastro — sin enriquecimiento ni caso, solo el registro de auditoría. Es el catch-all para que nada se escape.
Un test run evalúa un playbook contra una alerta de ejemplo y, si matchea, lo despacha en simulación — informa lo que haría y no ejecuta nada contra Wazuh. Sirve para validar un playbook de forma segura antes de armarlo.
En la página Playbooks, con el toggle on/off de cada card (solo admin). Los cambios aplican al instante. Un playbook atenuado con un chip no está disponible para la versión de Wazuh del entorno seleccionado.
En la página Playbooks, en Respuesta manual — bloquear una IP o rango: ingresa una IP sola, un CIDR (…/24) o un rango, elige el agente y haz clic en Bloquear ahora. Cada IP se bloquea por separado (hasta 256). Está disponible en Wazuh 4; en Wazuh 5 el bloqueo se dispara desde una detección, así que bloquea el origen desde su alerta.
Un score compuesto 0–100 con nota (A–F) sobre cuatro dimensiones — readiness de respuesta, higiene de ruido de alertas, cobertura de detección e ingestión. Es un indicador heurístico para seguir tu postura en el tiempo y comparar corridas, no una certificación. El reporte explica qué mueve cada sub-score y ata las recomendaciones a los playbooks relevantes.
En un entorno Wazuh 5, los admins pueden descartar findings de alto volumen antes de que lleguen a triage — por rule id — desde el panel Supresión de ruido Wazuh 5 en la página Playbooks. La detección en Wazuh queda intacta; la regla aplica en el próximo ciclo de colección y se puede apagar en cualquier momento.
Algunos playbooks de contención dependen de capacidades de plataforma que todavía no están en los agentes Wazuh 5. Corren en Wazuh 4 hoy y quedan latentes en Wazuh 5 — con el badge — hasta que la plataforma los soporte, momento en el que se activan solos.
Cuando un playbook abre un caso, se crea en la integración de ticketing configurada (por ejemplo Jira). Habilita y configura una en la página Integraciones; sin integración de ticketing el resultado igual queda registrado en Executions.
The SOAR watches your Wazuh environments, decides which detections deserve action, runs playbooks to respond, and records every outcome.
Beyond the built-ins you can add custom playbooks as portable { meta, workflow } bundles (admin only). The safest flow:
meta (below) and, in the workflow's first Code node, your action logic. Leave the library references as they are.What meta must contain
| Field | Req. | Value |
|---|---|---|
trigger_id | yes | Unique UPPER_SNAKE_CASE id (^[A-Z][A-Z0-9_]{1,49}$), e.g. ISOLATE_HOST. The stable routing key, not the display name. |
title | no | Display name in the Playbooks list (≤ 80 chars). Falls back to trigger_id. |
source_mode | yes | event (fired by an alert via match_query), pull (on demand), or manual. |
match_query | for event | The routing predicate (JSON) — below. An event playbook without a valid one never fires. |
wazuh_versions | no | Supported Wazuh majors, comma list (e.g. 4,5 or 4). Omit for all. |
action_tier / approval / priority | no | triage|act · auto|human · integer 0–1000 (higher runs first when several match). |
The match_query (routing predicate) — a declarative JSON predicate evaluated against the raw alert (no code):
{ "field": "rule.groups", "op": "contains", "value": "authentication_failures" }eq · in (value is an array) · contains · exists · regex{ "all": [ … ] } · { "any": [ … ] } · { "not": … }rule.id, rule.level, rule.groups, data.srcip, agent.id, …{ "any": [
{ "field": "rule.groups", "op": "contains", "value": "authentication_failures" },
{ "field": "rule.id", "op": "in", "value": ["5710", "5712", "5763"] }
] }
The rule ids/groups must be real in your ruleset — a made-up one never matches. When you need a criterion Wazuh doesn't ship, add a custom rule tagged with a group your predicate looks for.
What the workflow must contain (a normal n8n workflow export, with a few rules the importer enforces):
event playbook needs a “When Executed by Another Workflow” trigger so it can be dispatched.const alert = $input.first().json.normalized || $input.first().json;.dry_run — when alert.dry_run === true your action must simulate (change nothing). This is what makes Test run safe.What the importer checks — it validates before creating anything: meta + workflow present, a valid/unique trigger_id, a valid source_mode, a valid match_query (event playbooks must have one), the sub-workflow trigger, nodes/connections, and that every referenced library is installed. It also runs a safety scan (warns about direct Manager/Indexer calls that bypass dry-run, embedded credentials, or a workflow that never logs an outcome). Then Test run lets you paste a sample alert and see what it would do — the flow is import → test → arm.
El SOAR observa tus entornos Wazuh, decide qué detecciones merecen acción, corre playbooks para responder y registra cada resultado.
Además de los built-in puedes agregar playbooks custom como bundles portables { meta, workflow } (solo admin). El flujo más seguro:
meta (abajo) y, en el primer nodo Code del workflow, tu lógica de acción. Deja las referencias a las librerías como están.Qué debe contener meta
| Campo | Req. | Valor |
|---|---|---|
trigger_id | sí | Id único UPPER_SNAKE_CASE (^[A-Z][A-Z0-9_]{1,49}$), ej. ISOLATE_HOST. La clave estable de ruteo, no el nombre visible. |
title | no | Nombre visible en la lista de Playbooks (≤ 80 caracteres). Si falta, usa trigger_id. |
source_mode | sí | event (disparado por una alerta vía match_query), pull (on demand) o manual. |
match_query | para event | El predicado de ruteo (JSON) — abajo. Un playbook event sin uno válido nunca dispara. |
wazuh_versions | no | Majors de Wazuh soportados, lista separada por comas (ej. 4,5 o 4). Omitir = todas. |
action_tier / approval / priority | no | triage|act · auto|human · entero 0–1000 (mayor corre primero cuando matchean varios). |
El match_query (predicado de ruteo) — un predicado JSON declarativo que se evalúa contra la alerta cruda (sin código):
{ "field": "rule.groups", "op": "contains", "value": "authentication_failures" }eq · in (el valor es un array) · contains · exists · regex{ "all": [ … ] } · { "any": [ … ] } · { "not": … }rule.id, rule.level, rule.groups, data.srcip, agent.id, …{ "any": [
{ "field": "rule.groups", "op": "contains", "value": "authentication_failures" },
{ "field": "rule.id", "op": "in", "value": ["5710", "5712", "5763"] }
] }
Los rule ids/groups tienen que ser reales en tu ruleset — uno inventado nunca matchea. Cuando necesites un criterio que Wazuh no trae, agrega una regla custom etiquetada con un group que tu predicado busque.
Qué debe contener el workflow (un export normal de n8n, con algunas reglas que el importador valida):
event necesita un trigger “When Executed by Another Workflow” para poder despacharse.const alert = $input.first().json.normalized || $input.first().json;.dry_run — cuando alert.dry_run === true tu acción debe simular (no cambiar nada). Es lo que hace seguro al Test run.Qué valida el importador — valida antes de crear nada: meta + workflow presentes, un trigger_id válido/único, un source_mode válido, un match_query válido (los event deben tener uno), el trigger de sub-workflow, nodos/conexiones, y que toda librería referenciada esté instalada. También corre un escaneo de seguridad (avisa sobre llamadas directas al Manager/Indexer que saltean el dry-run, credenciales embebidas, o un workflow que nunca loguea un outcome). Después el Test run te deja pegar una alerta de ejemplo y ver qué haría — el flujo es importar → test → armar.