SOC Automation

Wazuh SOC Automation — Three Tiers, Clear Boundaries

Not all Wazuh alerts need the same handling. ARIA applies three tiers of automation: deterministic close for known-benign patterns, AI triage for ambiguous events, and security engineer routing for confirmed threats and uncertain cases. Response actions are never automated.

Tier One — Deterministic Close Without AI

A meaningful fraction of Wazuh alerts in any environment are reliably benign: specific process executions by specific software, installer behavior from known vendors, scheduled task patterns that fire every day without exception. Routing these through an AI pipeline adds latency and cost without improving the outcome. ARIA closes these with deterministic bypass rules.

Bypass rules are narrow. They match on specific combinations: a Wazuh rule ID plus a process signature or parent process, within defined parameters. They are not machine-learned classifiers — they are explicit rules that a security engineer has reviewed and approved. When a new class of reliable false positive is identified, a bypass rule is added. These rules do not make inferences; they recognize known patterns and act on them.

Deterministic close is the highest-confidence path in the pipeline. The rule has been reviewed. The pattern has been confirmed as benign in context. No AI inference or probabilistic reasoning is involved. The alert is closed immediately with the rule match recorded in the trace.

Tier Two — AI Triage for Ambiguous Events

Events that are not covered by bypass rules go through ARIA's enrichment and triage pipeline. Enrichment runs first — threat intel lookups, alert history, identity context for cloud events — and the enriched package goes to an LLM for a structured verdict.

The AI triage stage handles the large middle of the alert distribution: events that are not reliably benign and not obviously threats. A PowerShell invocation that is unusual for this endpoint but has no threat intel matches and follows a benign parent process. A login from an unfamiliar location for a user who has just returned from a trip. An administrative action that is atypical but within the user's normal role scope. These events cannot be deterministically classified; they require reasoning about context.

The AI triage verdict is independently verified by a second model. Alerts where the two models agree and the evidence is sufficient route automatically: benign verdict → auto-close with trace; high-confidence threat → escalate with evidence package. Alerts where the verifier disputes the verdict or where evidence is insufficient route to a security engineer regardless of the triage conclusion.

Tier Three — Security Engineer Review

Alerts reach the security engineer queue in three cases: the triage verdict is uncertain (low confidence); the verifier disputed the triage verdict; or the evidence sufficiency check failed (required enrichment was not available). In all three cases, the engineer receives the full enrichment package — threat intel results, alert history, identity context, the triage verdict with its citations, and the verifier's objection if any.

The engineer's role is not to re-run the enrichment queries — that work is done. The engineer assesses whether the evidence and reasoning support the routing decision and determines what, if anything, should happen next. For confirmed threats, the engineer approves and directs the response. For alerts that turn out to be benign after review, the engineer closes them with a note that may inform whether a bypass rule is warranted.

The security engineer queue is also where escalations land when ARIA determines a confirmed threat with high confidence. In this case, the alert is not waiting for the engineer to prioritize it — the engineer is notified immediately with the full evidence package and a recommended response.

What Is Never Automated — Response Actions

Response actions — isolating a device, suspending an account, modifying a firewall rule, blocking network traffic — are approval-gated in every ARIA configuration. The AI pipeline can recommend a response action as part of an escalation, but the action does not execute until a security engineer explicitly approves it.

This constraint is architectural, not configurable. The reason is operational risk: a containment action that is wrong can be as damaging as the threat it was responding to. Isolating a production server during business hours, suspending a service account that other systems depend on, blocking a network path that legitimate traffic uses — these outcomes require human judgment about operational context that the AI pipeline cannot fully model.

Automation is appropriate for triage. It is not appropriate for response, at the confidence levels current AI systems reliably achieve in production security environments.

What ARIA automates in a Wazuh SOC:

  • Deterministic close for known-benign patterns via bypass rules
  • Enrichment: threat intel, alert history, identity context
  • Structured LLM triage with evidence citation
  • Independent verification via second model
  • Evidence sufficiency check before auto-close
  • Routing: auto-close, engineer queue, or immediate escalation
Common Questions
How does ARIA decide what to add as a bypass rule vs. letting AI handle it?
Bypass rules are added for specific Wazuh rule IDs combined with process signatures or parent processes that have been confirmed as reliably benign in context. The threshold is high: the pattern must have no meaningful true positive rate before a bypass rule is justified. Ambiguous patterns stay in the AI pipeline. A security engineer reviews bypass rules before they go live.
Can the evidence sufficiency check be tuned per client?
The sufficiency check applies based on alert type — for example, alerts involving public IP indicators require threat intelligence to be checked; cloud alerts require identity context. These requirements follow from the alert content, not from a per-client configuration. If a required enrichment source is not configured for a client, that alert will not auto-close on the AI verdict alone.
What happens if the AI pipeline is unavailable?
If the triage pipeline is unavailable, alerts are queued and do not auto-close. The fail behavior is conservative: no alert is automatically closed without a completed triage cycle. Alerts that have been waiting beyond a threshold are flagged for the security engineer.
Is there a way to configure ARIA to auto-respond to certain alert types?
Response actions are approval-gated as a platform constraint, not a configurable option. The AI pipeline can surface recommended responses as part of an escalation, but no response executes without explicit sign-off from a security engineer.

See ARIA in Practice

Book a free assessment to see how the pipeline handles your actual alert environment.

Book Free Assessment
No contract. No setup fee. Cancel anytime.

See Plans

Starting at $799/month. No long-term contracts required.

View Pricing