Wazuh and Shuffle SOAR integration

The integration works as a chain of five handoffs, and each one is a place where volume, delay or failure can enter. An alert is first written to the Wazuh indexer, which stores alerts as a searchable record. Before that happens, the Wazuh server analyzes data from agents with its decoders and rules, so the server decides what an alert is and how severe it is. The forwarding integration then posts matching alerts to a Shuffle webhook. Shuffle's backend queues each incoming request as an execution, and Orborus, the runtime component, polls the backend for jobs and starts a worker for each execution. The worker launches the app containers that do the enrichment, ticketing and active response steps. Before go-live, confirm with your own configuration which component the forwarder reads from and which backend address and port the webhook uses, and confirm that the network path from the Wazuh server to that port is open.

The level filter should sit at the source, in the forwarder's configuration, so that low-severity alerts never leave Wazuh. Filtering later, inside a Shuffle workflow, still pays for the webhook call, the queue entry and the worker startup for every alert that arrives. Shuffle's pricing counts app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Filtering at the source therefore reduces the number of executions that carry enrichment and ticketing actions, which matters for both queue depth and any licensing that depends on run volume. Set the threshold with the security team, record it in change control, and review it after the first weeks of live alerts, because a level that looks reasonable on paper can still flood a queue once a noisy rule is enabled.

The payload shape must be confirmed against a real test alert before any workflow is built. Generate a test alert from a known agent or a controlled rule, capture the full JSON that arrives at the webhook, and map each field the playbook needs, such as the rule identifier, rule level, agent name and agent identifier, into named workflow variables. Do not build branches from the field names in documentation alone, because a version change or a custom decoder can alter the structure. Keep the test alert and its captured payload as a fixture, so that a change in the Wazuh or Shuffle version can be checked against the same input. Plan for more than one Orborus node if you need workflows to keep running when a single runtime fails, since queued executions depend on a worker being started somewhere.

The return path to agents is the active response step, and it depends on two conditions. The target agent must be online when the action is sent, and the agent must be configured to accept the active response command that the playbook invokes. A playbook that does not check agent status will report success for a request that never reached the endpoint, so add a status check and define what happens when an agent is offline, such as opening a ticket for manual follow-up or retrying on a schedule you set. The credentials that the Shuffle app uses to call the Wazuh API are saved in Shuffle and encrypted in OpenSearch with the SHUFFLE_ENCRYPTION_MODIFIER secret, so record that secret in your key management process, because changing or losing it breaks every saved app authentication. Test each active response action on a non-production agent first and confirm both the result in Wazuh and the audit entry in Shuffle.

The topic brief sets a throughput target above 10 alerts per second, but none of the supplied facts show how a given Shuffle and Wazuh deployment performs at that rate. Treat the figure as a planning target to test, and do not accept it as a capacity guarantee. Before choosing server counts or an edition, replay alerts that match your production mix of levels, decoders and rule groups at the target rate. Record the Wazuh indexer ingest lag, the time from alert to workflow start, the depth of pending executions and the rate of failed runs. Repeat the test with the workflow you plan to run in production, because a playbook with several enrichment lookups costs far more per alert than a single forwarding step. Keep the results with the configuration that produced them so the sizing can be reproduced after upgrades.

Shuffle's configuration docs describe the high availability pattern that the throughput test must cover. They recommend an OpenSearch cluster for the document store, optional Memcached for a shared cache, NFS for shared files when you run several backends, the backend and frontend scaled across all servers, and more than one Orborus node so workflows keep running if one fails. Each element adds components to measure. Slow NFS can become the bottleneck for shared files, and every Orborus node needs network reach to the backend it polls. Decide early whether the test environment matches this topology, since a single-node result says little about a clustered production setup. Confirm with the vendor and your platform team which pieces must be sized together, and write down the failover behavior you expect when one Orborus node is stopped during a test run.

Alert supply is the other lever, and it sits on the Wazuh side. Wazuh server clustering spreads analysis load across nodes, which changes how quickly alerts reach the forwarding step, so the cluster layout belongs in the same test plan as the Shuffle environment. Filtering by alert level before the webhook reduces the number of workflow executions. Agree the threshold with your SOC, based on which levels already trigger a human response, and leave out low-value alerts that no playbook acts on. Review this list after each Wazuh update, since rule sets change over time. Keep a record of what was filtered out so that suppressed alerts remain searchable in the Wazuh indexer when an investigation needs them. Filtering shifts the sizing question from how much the platform can handle to which alerts deserve automated action.

High volume also changes the cost model. Shuffle's pricing article says licensing is based on one metric, app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. A playbook that calls an enrichment app several times per alert multiplies the metric, so the run count depends on how many app calls each alert triggers, and alert volume is only one input. Shuffle also states that all features are available in the open-source edition, while paid tiers differ in feature limits, scaling and support, and that limits between editions have been enforced since version 2.1.1. Ask for the current edition terms in writing, convert the run count from your measured test into an expected monthly figure, and use that figure in any quote for the scaled design.

Test the Wazuh to Shuffle chain in five separate checks, and agree the plan with the people who will sign off the playbooks before any playbook is approved. Each check isolates one link in the chain, so a failure points to a specific component. Testing only the final playbook end to end makes it hard to tell whether a missing ticket came from forwarding, branching, the enrichment call or the ticketing API. Write the expected result for every check before the test runs, and record who approved those expectations.

Start with the forwarding test. Send a known sample alert at each rule level you have configured for the webhook, and confirm that only the levels you intended start an execution in Shuffle. Include one alert just below each threshold, because off-by-one filter errors are common. Then test the playbook with the enrichment and ticketing endpoints replaced by mocks that log every request and return fixed success, timeout and error responses. This shows whether branches for failed enrichment and failed ticket creation behave as designed, without touching live systems or credentials.

The active response test runs on a non-production Wazuh agent. Use a harmless command, such as one that writes a marker file with a timestamp, and confirm that the agent receives it, runs it and reports the result back to the Wazuh server. Then run the rollback step and confirm it restores the agent to its prior state. Do not run this test against production endpoints. The failure test stops one Orborus node during active executions and confirms that in-flight and queued workflows finish on the remaining node or are retried according to your design. The load test runs at the target alert rate against an OpenSearch layout that matches production in node count, shard and replica settings, and storage. Ask your team to confirm which Shuffle release tag each environment uses, because the test results only apply to the version that was tested.

Keep three kinds of evidence. Export Shuffle execution logs for every test run, including skipped and failed executions. Keep sample alerts from the Wazuh indexer with their document IDs, so each execution can be traced to its source. Keep test records that state the date, the Shuffle and Wazuh 4.14 patch versions, the configuration used, the operator, the expected result, the actual result and any deviation. Store these in the same system as your change records, and set retention to match your audit and incident response requirements. Make passing these records a condition for playbook sign-off, and do not treat a clean demonstration as a substitute.