Why teams wire Wazuh alerts to automatic countermeasures
A SOC or platform team that already collects Wazuh alerts often wants certain high-confidence detections to act on their own, such as blocking a source IP or disabling an account, without waiting for an analyst to pick up the ticket. Wazuh active response is the mechanism for this: when a rule fires, the Wazuh server can run a predefined response script on the affected agent or on the server. The hard part is rarely the trigger itself. It is deciding which rules are safe to automate, understanding what a wrong block costs in production, and proving that the response fails safely when something unexpected happens.
Start with the rule inventory, not the response script. Each rule that might drive an automatic action needs a named owner, a documented false-positive history, and a clear statement of what the response will touch. A rule that fires on a single failed login from an internal jump host is a poor candidate for account disablement, even if its alert level is high. Review the rule's logic, the decoders feeding it, and the populations of users, hosts and networks it covers. Where a rule depends on a custom decoder or a tuned level, note that dependency, because an upgrade or a change to that rule can silently change what triggers the response.
Consider the cost of a wrong block before you enable anything. Blocking a source IP can cut off a payment processor, a monitoring probe, a patching server or an administrator working from a shared address. Disabling an account can lock out an on-call engineer during an incident. Write down, for each candidate response, which business services and identities would be affected, who must be told, and how the action is reversed. Reversal matters as much as the action: confirm that you can remove a block or re-enable an account from the Wazuh server, from the agent host, or from the target system, and that the person on duty knows how to do it without reading the code first.
Prove the failure mode in a non-production environment before any response runs against real endpoints. Test the trigger, the script execution on each agent operating system you run, the timeout and the cleanup path. Confirm what happens when the agent is offline, when the script returns an error, and when a response fires repeatedly for the same alert. Exact script names, parameters and supported response types depend on the Wazuh 4.14 line and on each agent's operating system, so confirm them against the current Wazuh documentation for your version and against the platforms in your own fleet before you rely on any of them.
Treat the automation policy as a controlled change. Record which rules are allowed to trigger which responses, who approved them, and when they were last tested. Review the list after each Wazuh patch release on the 4.14 line and after any change to agent groups, network design or identity sources, since those changes shift what a rule sees. An automatic countermeasure that was safe last quarter can become disruptive after an unrelated change, so the policy needs an owner and a review cadence, not just a configuration file.
Which Wazuh components an active response touches
An active response spans several Wazuh components, each with a different job. The server decides when a response fires, the endpoint carries it out, and the indexer and dashboard keep the record. Knowing which part does what tells you where to set policy, where to look when a response fails, and what your sources must provide.
Wazuh server decides when to respond
The Wazuh server analyzes agent data with decoders and rules, and it is the component that determines when an active response is triggered. Response logic is tied to rule matches, so the rules you rely on for a countermeasure must be tested and stable. Before go-live, confirm which rule IDs and alert levels are linked to each response and who approves changes to them.
Agent runs the action locally
The response action itself executes on the Wazuh agent installed on the affected endpoint, not on the server. This means a block or account change depends on the agent being online, supported on that operating system, and able to run the script. Check agent status, operating system coverage and execution permissions for every host that is meant to respond.
Central configuration, local execution
The server manages agent configuration remotely, so response settings are defined once on the server and pushed out to endpoints. The decision is central, but each endpoint applies the configuration and runs the action on its own host. Review how agent groups are structured, because a misassigned group can give a response to hosts that should never receive it.
Indexer stores the triggering alert
The Wazuh indexer stores the alert that caused a response, which gives you the event record behind each automated action. Retention and access to that index determine how long you can reconstruct why an IP was blocked or an account was disabled. Confirm retention settings and who can query the index before you depend on it for an audit trail.
Dashboard shows response history
The Wazuh dashboard is where operators review alerts and the history of responses that followed them. It is the practical place to check whether a countermeasure fired on the intended host and when. Decide which roles can view response activity and whether analysts can see enough context to judge a false positive.
Agentless sources need a server-side check
Agentless sources such as firewall syslog can produce alerts, but a response is only executed on an endpoint with a supported agent. A rule that fires on a firewall event may therefore trigger a server-side response only where the relevant agent is present, so it cannot assume an action on the source device. Confirm for each source which component would act, and test that path with your own devices.
How a rule match becomes an action on an endpoint
An active response is only as precise as the rule that fires it, so the chain from event to action is worth understanding step by step. An agent on the endpoint collects a log line, a file change or another monitored event and forwards it to the Wazuh server. The server applies decoders to extract named fields from the event, then evaluates the rules that match those fields. Each matching rule carries a rule ID and an alert level. If the rule matches and an active response is configured to trigger on that rule, the server selects a command definition and sends it to the target agent. The agent runs the command and reports the result back. Each stage can be checked separately, which makes troubleshooting far easier than treating the response as a black box.
The rule defines the blast radius. Three settings decide how far a response reaches: the rule ID that triggers it, the alert level threshold, and the agent group the response applies to. A shared or loosely written rule can fire on many hosts, and a low alert level can pull in events that were never meant to cause an action. Before enabling a response, list the agents in the target group, confirm which production systems they include, and review recent alerts for the rule to see how often it fires in normal operation. Test the rule against a non-production group first. Record who approved the rule-to-action mapping, because that mapping, not the command itself, determines what gets touched.
Responses can run on the agent where the event occurred or on other agents, and the difference matters for both effect and risk. A response on the originating agent acts where the suspicious activity happened, which is often the most direct containment step. A response that runs on the server or on a specified other agent acts somewhere else, such as a host that controls network access or a system that holds the relevant configuration. That path depends on network reachability and on the permissions the command needs on the target. The location options and their exact behavior vary by release, so confirm which options your Wazuh version supports, how each one behaves when the target agent is offline, and whether it needs elevated privileges on that host.
The outcome of every run should be verifiable. The agent records the executed command and its result, and the alert pipeline keeps the triggering event, so an investigator can connect cause and effect after the fact. Build the check into the operating procedure: confirm that the response ran on the intended agents, that the expected change took effect, and that nothing else changed. Decide in advance how a response is reversed, whether a separate command or a manual step, and test that reversal on a non-production host. Plan for the response to fire on a false positive, because the only safeguard against disrupting production is a rule set that has been tuned before the action is enabled.
Which responses to automate and which to keep for analysts
This table compares the main Wazuh active response classes by the rule confidence each needs, how easily it can be reversed, and the cost if it fires against legitimate activity. Read each row as a reason to move a response toward automatic or toward analyst confirmation, and use the scope and approval rows to limit blast radius before anything runs unattended.
| Response class | Rule confidence needed | Reversibility and blast radius |
|---|---|---|
| Alert-only notification | Low: suitable for broad or noisy rules where false positives are expected | Fully reversible; no change on the endpoint, cost is analyst time spent on noise |
| Time-limited network block on the agent | Moderate: the rule should target a specific, well-understood attack pattern | Reversible when the block expires; a wrong block can cut a legitimate service or admin session until it clears |
| Permanent or long-lived network block | High: confirm the source is not a load balancer, scanner, monitoring host or shared NAT address | Harder to reverse quietly; a block on a shared address can affect many users |
| Account disablement | High: the rule must tie the account to malicious activity, not a single failed login | Reversible by re-enabling, but service accounts and on-call access can break silently; confirm which accounts are excluded |
| Process or file quarantine | Very high: a false match can stop a business application or corrupt a working file | Partly reversible if the file is restored from a verified copy; confirm the restore path before enabling |
| Analyst-confirmed response | Any level: used where the cost of a wrong action exceeds the cost of a short delay | Reversibility follows the underlying action; adds delay and depends on analyst availability |
| Agent group scope | Set per group: start with a test group that has no production-critical workloads | Limits blast radius to the agents in the group; review group membership before each rule change |
| Approval model: fully automatic | Reserve for rules with proven low false-positive rates on your own traffic | Fastest containment, highest cost of error; review trigger history regularly |
Build sequence for safe active response rollout
This sequence moves Wazuh active response from an idea to a scoped, tested and reviewed control. Each step produces an artifact that the next step depends on, so a countermeasure reaches production only after its false positive history, exemptions and test results are on record.
Inventory candidate rules and false positive history
List every rule that could trigger a response, such as rules for repeated authentication failures or known malicious activity. For each rule, pull its alert history over the period your team can review and record how often it fired on legitimate activity, such as scheduled jobs, vulnerability scanners or administrators. The security team owns this inventory, and the platform team confirms rule identifiers. The rule list records rule ID, description, alert level, observed false positive count and the reviewer's decision. The step is done when every candidate rule has a recorded decision and a named owner.
Define response scope by agent group
Map each approved rule to the agent groups where its countermeasure may run. Agent groups let you attach the active response configuration to a defined set of endpoints, so membership should reflect environment and business role, such as development, staging or internet-facing web tier. Ask the platform owner to confirm group names and current membership on the Wazuh server before any response is attached. The output is a scope matrix that pairs each rule with its agent groups and the action it may trigger. The step closes when a reviewer can name every host a countermeasure could reach.
Create the exemption register for critical systems
Build an exemption list that keeps automated countermeasures away from hosts and accounts that must stay available. Include domain controllers, backup and monitoring servers, jump hosts, service accounts used by automation, and the administrator paths that responders need to reach the environment. Define each exemption by host identifier, account name or source address, and give each entry an owner and a stated reason. Security and infrastructure leads approve the register together. The exemption register is complete when every critical host and service account in the asset inventory is either listed or confirmed as excluded by design.
Configure active response in central configuration
Define the active response block and the rule-to-command mapping in the Wazuh server's centralized agent configuration for the groups set in the scope step. Confirm that the referenced scripts exist on each target operating system, because Linux, Windows and other agents use different script names, paths and permissions. A missing script causes the action to fail, so check it before any rule can fire. Record the configuration version and have a second person review the diff. The closing check is a per-operating-system script inventory showing that every target endpoint has the script with the expected permissions.
Test in a non-production agent group
Run the configured responses against a non-production agent group using replayed or simulated events that match the rules in scope. Replay captured log lines from earlier incidents or generate synthetic events on test hosts, then confirm that each rule fires and each action executes only where intended. Include a negative test in which an exempted host or account matches the trigger and must not be touched. Record each test with its input, expected result, observed result and tester. The test record is complete when every rule in scope has a passing case and every exemption has a passing negative case.
Enable one low-impact response first
Choose one rule and one low-impact countermeasure, such as a temporary block applied to a single non-critical agent group, and enable it in production with the same scope and exemptions tested earlier. Low impact means the action is reversible and its failure does not interrupt a business process. Submit the enabling change through your normal change process, with a named rollback step that removes the response from the group. Monitor alerts and agent logs for the observation period your change record defines. The step closes when the change record shows the response is active, reversible and under review.
Review logs of every executed action
Review the logs for every action the response executed and compare each one with the alert that triggered it. Check the active response entries on the agent, the matching alert on the server and the resulting system state, such as whether an address was blocked and whether it was released afterward. Look for actions against exempted hosts, repeated triggers from one rule and actions against legitimate users. Record each reviewed action in a response log review register with a verdict of correct, false positive or defect. The step is done when every executed action has a verdict and each false positive has an agreed fix to the rule or exemption.
Widen scope in controlled increments
Expand the response to additional rules and agent groups only after the previous stage has a clean review record. Each increment repeats the scope, exemption, test, change approval and log review steps for the new scope. Keep a written rollback for each rule and agent group so that any increment can be reversed quickly. The closing check is a dated scope register that shows which rules and groups are active, who approved each one and the review verdicts that justified each widening.
Safeguards that stop automation from locking out your own staff
Active response runs commands on endpoints without a person in the loop, so a bad rule or a compromised path can do real damage quickly. The cards below cover the controls that limit who can change automation, how the server and agents trust each other, what runs on endpoints, and how you stop everything fast when something goes wrong.
Restrict who changes active response
Limit write access to the active response configuration in ossec.conf, custom rules and decoders to a small named group of engineers, and keep dashboard roles for everyone else read-only. Review who holds administrator rights on the Wazuh server and dashboard, since anyone who can edit a rule can trigger a command on every matching agent. Confirm the change path for these files before go-live.
Protect the server and agent channel
Active response commands travel over the connection between the Wazuh server and each agent, so that channel must be authenticated and encrypted with the certificate and enrollment model your deployment uses. Check how agents are enrolled, who can register new agents, and how certificates are issued, rotated and revoked. Confirm the current procedure against the Wazuh documentation for your release line before relying on it.
Put response scripts under change control
Each script that active response executes on an endpoint should live in version control, be reviewed before deployment, and be verified against a recorded checksum on every agent. Without this check, a modified script on one host can run with the privileges of the agent and differ from what your team approved. Schedule a checksum comparison after each agent update or configuration push.
Keep downstream credentials off endpoints
Scripts that disable accounts or block addresses often need credentials for an identity provider or firewall. Do not store those secrets in plain text in scripts, configuration or environment files on endpoints, because anyone with local access to a host can read them. Prefer a central action path where the server or a separately protected service holds the secret, and confirm which option your platform supports.
Exempt privileged and recovery accounts
Do not automate disabling, locking or blocking actions against administrator accounts, domain controllers or backup service accounts unless an explicit exemption is documented, approved and tested. Build the exemption list from your directory and backup inventory, not from memory, and review it when accounts change. Test each rule against these accounts in a non-production environment before enabling it.
Log every automated action for audit
Make sure each active response execution, including the rule that triggered it, the target host and the outcome, is recorded in the Wazuh indexer so the action can be reviewed later. Build a dashboard view or saved search for these events and assign an owner who reviews them. Confirm retention settings for these records, since audit evidence is only useful if it is kept long enough.
Rehearse the break-glass shutdown
Document one procedure that disables active response across the deployment, including the configuration change, the agent restart or reload needed to take effect, and the named people allowed to run it. Test the procedure on a schedule and measure how long it takes to confirm that no new automated actions run. Keep a copy of the procedure outside the Wazuh server so it stays available if that server is affected.
What drives the effort of automating countermeasures
This table lists the factors that change how much work it takes to automate Wazuh active response countermeasures, and how to keep each one manageable. Read each row as a lever: the driver explains why effort grows, and the reduction column shows where to start. The main takeaway is that scope control, not tooling, usually sets the effort.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of rules being automated | Each rule that triggers an automated action needs its alert logic, false-positive history and rollback path checked. Rules with unproven tuning multiply review work. | Automate a small set of high-confidence rules first, such as repeated failed logins from one source, and add others only after several review cycles show stable alerts. |
| Operating systems and agent groups | Active response commands differ across Linux, Windows and other agent types, and each group may need its own script, permissions and tests. | Standardize agent groups by operating system and role, and reuse one reviewed response script where the platform allows it, testing each variant separately. |
| Firewall and identity system integrations | Blocking an IP on a firewall or disabling an account in an identity system needs separate credentials, API permissions and change processes owned by other teams. | Confirm the integration owner, service account scope and change window before build. Limit each credential to the single action it performs. |
| Approval workflow and exemption lists | Actions on production systems usually need approval rules, and every exemption (administrators, monitoring hosts, backup servers) must be defined and maintained. | Keep the approval path short for low-impact actions, and keep exemption lists in version control with a named owner and a scheduled review. |
| Number of environments | Lab, staging and production each need working copies of rules, scripts and integrations, plus tests that prove a response behaves the same way in each. | Test responses in lab and staging with simulated events, and promote only reviewed script and rule versions to production through the same path each time. |
| Compliance evidence per automated action | Auditors may ask which rule triggered an action, who approved it, what ran, and what was logged. Each automated action then needs traceable records. | Define the evidence set once, such as alert ID, script version, timestamp and result, and generate it the same way for every automated action. |
| Rule tuning maturity | Rules still generating frequent false positives force constant threshold changes, and every change to a triggering rule can change which responses run. | Tune rules in detection-only mode before enabling active response, and record each threshold change alongside the response it affects. |
How to test that active response works and fails safely
Testing active response should prove four things before any countermeasure touches a production system: the right trigger fires, the response lands only where intended, the way back works, and failure does not spread. Start with the happy path on a dedicated test agent. Generate a triggering event that matches a rule you intend to act on, then confirm the alert appears in the Wazuh dashboard with the expected rule ID and level, and that the active response command runs on the agent and produces the outcome you configured, such as a blocked source address or a disabled test account. Check the Wazuh server logs and the agent logs as well, because a response can fire on the server side while the agent never executes it.
The second layer tests exemptions, which matter more than most teams expect. Build a short list of hosts, service accounts, administrator addresses and monitoring sources that must never be blocked or disabled, then re-run the same triggering event against one of them. The response should not execute. Confirm the exemption works for the trigger path you actually use, since an exemption written for one rule or one agent group may not cover another. Also confirm the reverse: a host outside the exemption list should still receive the response. Verify the exemption syntax and the field names against your Wazuh 4.14 configuration and documentation, because active response settings differ between versions and small syntax errors can silently remove protection.
The third layer tests the rollback or unblock path, which is the test most often skipped. Run the response, then run the documented reversal: remove the blocked address, re-enable the account, or clear the temporary rule that the script added. Confirm the reversal reaches the same agent and leaves no residue, such as stale firewall rules or locked accounts that a later script cannot undo. Then test the global control. Disabling active response across the server should stop new executions, and the test should show that a fresh triggering event produces an alert but no command. Record how quickly the change takes effect on each agent group, because a setting that applies only after an agent restarts gives a false sense of control during an incident.
The final layer checks failure behavior. Simulate a script that exits with an error or hangs, and make an agent unreachable during a triggered response. The expected result is that the failure is logged on the server and the agent, that the alert pipeline keeps processing events, and that other agents continue to receive their responses. Confirm the behavior with your own script timeouts and error handling, not only with the defaults. Keep a test register with one row per test: the date, Wazuh version and component versions, the triggering event and its source, the expected alert and response, the observed result, the reviewer and any remediation. This register is the evidence you can show internal reviewers or an auditor, and it must be re-run after upgrades, rule changes and changes to exemption lists.
How active response differs by deployment model
In an all-in-one installation, the Wazuh server, indexer and dashboard run on one host, so every active response definition and its supporting scripts live in one place. Changes are quick to make, but the same host also carries the analysis workload, so a poorly scoped action can interrupt the monitoring you need during an incident. Plan the test path before you enable anything.
- Configuration: Define each response in the manager configuration on the host and keep a versioned copy of that file alongside any custom scripts.
- Testing: Use a non-production agent to trigger each rule and confirm the response runs once, reverses where expected and logs the outcome.
- Change control: Record each new trigger in a ticket with the rule identifier, the action and the rollback step, because no second node will catch a mistake.
- Lockout risk: Place administrator addresses, monitoring systems and service accounts on an allowlist so a block cannot cut off your own access.
Confirm in the 4.14 installation guide how the all-in-one install organizes the configuration and script directories and whether active response is enabled by default.
In a clustered deployment, several Wazuh server nodes share the analysis of agent events, so an active response definition must resolve the same way no matter which node processes an event. If one node carries a different configuration, a response may fire for some agents and silently fail for others. Treat the cluster as one configuration boundary and manage changes centrally.
- Configuration: Keep response definitions identical across nodes and deploy them through the same centrally managed process rather than editing each node by hand.
- Testing: Trigger the same rule from agents that connect to different nodes and compare the logs and outcomes on each node.
- Change control: Roll changes out one node at a time, with a defined check after each step and a documented way to revert.
- Ownership: Name who approves response changes, since a change made on one node can affect every agent that node serves.
Confirm in the 4.14 cluster documentation how configuration is synchronized between nodes, which node executes a response for a given agent event, and how the response reaches the agent when its connection moves between nodes.
Containers change where agents run, how long they live and which network address the server sees. An agent in a short-lived container may re-enroll after every restart, and traffic that passes through a load balancer or network address translation can hide the true source of an event. Both facts affect whether a block targets the right host or the right workload.
- Agent placement: Decide whether agents run on the node host, as sidecars or inside each workload, and document which option covers which event source.
- Network paths: Confirm the route from agent to server and from server back to the agent, including any network policies that could drop response traffic.
- Source addresses: Check what address the server records behind a proxy or load balancer, because a block on the wrong address can stop legitimate traffic.
- Version control: Pin container images to a specific 4.14 release and test upgrades in a staging cluster before production.
Confirm in the 4.14 Docker and Kubernetes documentation which agent images and deployment methods are supported, and how enrollment and source address handling behave in your cluster's networking model.
On networks without internet access, the external block lists and threat feeds that many response designs assume are not available. Responses must rely on indicators and lists held inside the network, and every update must arrive through an approved transfer path. The same restriction applies to vulnerability data, which the Wazuh offline repository supplies in place of the online Cyber Threat Intelligence platform.
- Configuration: Build response lists from internal sources such as your own asset inventory and approved indicators, and store them under change control.
- Testing: Run each response in an isolated lab that mirrors the production rule set before any transfer to the restricted network.
- Updates: Move lists, scripts and rule packages through a defined media or internal mirror process, and log each import with its approver.
- Dependencies: Track the offline vulnerability repository and offline installation files as separate dependencies with their own update schedule.
Confirm in the 4.14 offline installation guide which components need manual updates, how the offline vulnerability repository is refreshed and which active response features depend on outside connectivity.
What to monitor, review and document after go-live
A rollout is not finished when the first response fires correctly. Active response needs a named owner who reviews the log of executed responses every week while the rollout is still expanding, then on a cadence that the owner and security leadership agree in writing. Each entry should show the rule that triggered, the response that ran, the target agent, the timestamp and the outcome. Confirm where the log is stored on the Wazuh server and how long your retention policy keeps it, so that incident responders can reconstruct what automation did during an event. Reviewing the log also shows whether responses fire at the volume you expected, which is often the first sign that a rule is noisier than planned.
False positive responses need their own record. Each time a responder confirms that an action should not have run, note the rule ID, the agent, the action taken and whether it was reversed, such as an unblocked address or a re-enabled account. Review these records with the engineers who own the rules, because the fix may sit in the rule itself, its alert level, the conditions that trigger the response or the exemption list. Track counts by rule over time. A sudden rise after an application release or a directory change usually means the environment changed and the rule did not. Feed each confirmed case back into rule tuning, and retest the rule after every change so that a fix for one host does not weaken protection on the others.
Every 4.14 patch upgrade needs a repeat test of each active response. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026. Agent scripts and configuration can change between releases, so a response that worked before an upgrade may fail quietly afterward. For each response, trigger it on a test agent in every operating system group, then confirm that the script runs, the action takes effect and is reverted, and the log entry appears. Keep the exemption register current as hosts, service accounts and administrator accounts are added, renamed or retired. An exemption for a decommissioned server is harmless until its name is reused. Upgrade order across the indexer, server, dashboard and agents is covered on the upgrades page, so follow that sequence before running these tests.
Back up the Wazuh server configuration and custom rules on a schedule that matches how often they change, and keep copies outside the server. A backup is only useful after a restore has been tested on a separate system, so schedule that test and record the result. Documentation is the last safeguard. For each active response, record the owner, the approval path for changing it and the conditions under which it may run automatically. Write the break-glass procedure in full: who may disable active response globally or for one agent, the exact steps, who is notified, how the change is logged and how normal operation resumes. Store it where responders can reach it during an outage, and confirm with your security leadership that it matches the change process your organization already uses.
Questions teams ask before automating Wazuh responses
How much work is it to automate Wazuh active response?
The effort depends on how many response types you want, which endpoints they touch, and how many people must approve them. A single response, such as blocking a known-bad IP on one server group, is a small change. Automating account disabling or host isolation across mixed Linux and Windows fleets is much larger, because each response needs a tested script, a matching rule set, a rollback path and sign-off from the teams that own those systems. Ask any provider to break the work into rules, scripts, test runs and change approvals so you can see where the effort sits.
Can our own team set up Wazuh active response without a partner?
Often yes, if you already run Wazuh and have engineers who know its rules, decoders and agent configuration. Active response is part of the platform, so the core work is configuration and scripting, not new software. The harder part is usually the operational side: agreeing which alerts are safe to act on, testing against systems that look like production, and keeping the logic current through Wazuh upgrades. Be honest about whether your team has time for that testing and change control. A partner can do the build, the testing or both, under a written scope.
What does automated response need from our team?
You will need to supply four things. First, rule owners who can say which alerts are reliable enough to trigger an action. Second, change approvers who sign off on each response before it goes live and on any later edits. Third, test environments that resemble production closely enough to show what a block or account disable would break. Fourth, endpoint access, including agent permissions and the administrative accounts the scripts run under. Confirm early how your identity, network and endpoint teams will be involved, because delays in access are a common reason these projects slow down.
What drives the timeline for a Wazuh active response project?
Duration follows scope rather than a fixed template. The main drivers are the number of response actions, how many operating systems and agent groups they cover, how many alert rules need tuning first, and how long your change approval process takes. Test environment availability and whether you need to prove responses in a private lab before production also matter. Ask for a phased plan with clear checkpoints, so each response type can be approved, tested and released separately. Any date you are quoted should trace back to those inputs.
Should we automate blocking at all, or only alert?
Automated blocking is worth considering for narrow, high-confidence cases, such as a rule with a low false-positive history that targets a known malicious pattern. For broad or ambiguous detections, alerting plus a human decision is usually safer. A practical approach is to start in alert-only mode, review what would have fired for a period, and then enable actions one at a time. Decide in advance which actions are reversible, such as a temporary block, and which are not, such as disabling a business account. Make that decision with the system owners, not only the security team.
What happens if an active response fires against a production system?
The answer depends on how the response was designed. A well-scoped response has a defined trigger, a limited target, logging of what ran and when, and a documented way to reverse it. Without those, an overly broad rule can block a legitimate service or lock out staff. Before go-live, ask how each response is tested, who receives an alert when it fires, how quickly it can be undone, and which systems are excluded by design, such as domain controllers or backup servers. Those answers should appear in the written scope and in your runbook.
What should a written scope for Wazuh active response include?
Ask for a list of each response action with its trigger rule, target systems, and reversal method. Request the operating systems and agent groups in scope, the test approach and the environments used, and the change approval steps your team must complete. The scope should name who supplies rule owners, endpoint access and approvals, and what is delivered at each phase, including documentation and handover. Also ask how the work will be kept working after Wazuh upgrades on the 4.14 line, and whether ongoing support or testing is included. A quote should follow from that document.
How DeployOpen scopes, builds and hands over active response
DeployOpen plans Wazuh active response as a fixed-scope engagement inside your own infrastructure, starting with the rules and endpoints where automated countermeasures are safe to run. Each step is agreed in writing, tested before it reaches production, and documented so your team can operate and change it after handover.
How we scope
- Inventory which rules and alert levels may trigger responses, and which must only raise alerts for analysts.
- Map affected endpoints, agent groups and production systems that must never be blocked or disabled automatically.
- Agree in writing which active response commands, scripts and triggers are in scope, and which are excluded.
How we build
- Configure active response scripts and rule bindings in a lab or staging environment that mirrors your agent groups.
- Test each countermeasure against benign and simulated attack events, including rollback and unblock steps.
- Set allowlists and safeguards so administrative accounts, critical services and monitoring hosts cannot be isolated.
How we hand over
- Deliver written documentation covering each trigger, script, target group, expected effect and how to disable it.
- Walk your operations and security staff through testing results, rollback procedures and escalation paths.
- Provide a change record that lists every custom rule, script and configuration file, with versions and owners.
How we support
- Review active response behavior after each Wazuh 4.14 patch or upgrade, since rule and script changes can affect triggers.
- Retest custom countermeasures whenever your rules, endpoints or production systems change materially.
- Ongoing support is available as a retainer, with scope and response terms agreed in writing before work starts.
