Detection Engineering — Rule Tuning Proposals

Rule Tuning Suppression Proposals Wazuh Human Approval Required Evidence-Backed

The Problem: Rules That Cry Wolf

A detection rule that fires on legitimate activity does not protect anyone — it trains the people reviewing alerts to treat that rule as noise. When a security team is reviewing hundreds of alerts per week, the ones they have learned to ignore are the ones an attacker will exploit. A well-calibrated rule set is not a one-time configuration task. It requires ongoing observation of what fires on real traffic and deliberate decisions about what to suppress.

Most organizations running a SIEM or Wazuh deployment do not have a full-time detection engineer reviewing rule performance. The alerts accumulate, the false positive rate stays high, and the highest-severity findings get buried in the queue. ARIA's detection engineering capability is built to surface the tuning opportunities that would normally go unaddressed.

How ARIA Identifies Tuning Candidates

Signal observation

Every alert that ARIA triages carries a disposition: the case was benign, or it wasn't. Over time, ARIA tracks which (tenant, rule_id) pairs accumulate consistent benign closes. A rule that fires repeatedly and closes benign in every instance is a candidate for investigation — not automatic suppression, but a signal that something is worth examining.

Pattern extraction

For a candidate rule, ARIA examines the field values across all the benign-closed cases: which processes triggered it, which hosts, which user accounts, what the command-line arguments look like. It identifies whether there is a common structure — a specific process name, a specific argument pattern, a specific source host — that distinguishes the legitimate activity from what the rule is intended to catch.

Proposal generation

If the pattern is specific enough — a narrow condition that would suppress the known-benign cases without hollowing out the rule's coverage for genuine threats — ARIA generates a suppression proposal. The proposal includes the proposed suppression condition, the list of cases it would have suppressed, and the evidence behind the pattern. It does not include any speculation about what the correct suppression should be.

Security engineer review

The proposal appears in the ARIA portal for security engineer review. The engineer reads the evidence, evaluates whether the proposed suppression is appropriately scoped, and approves or rejects it. Rejected proposals are logged with the engineer's reasoning. Approved proposals are applied to the rule configuration. The engineer can also modify the proposed condition before approving.

Application and monitoring

An approved suppression is applied to the relevant rule. ARIA continues monitoring: if the suppressed condition later appears in a context associated with an active threat, ARIA flags the potential coverage gap. A suppression that was safe when applied may need revisiting as the threat landscape changes.

What ARIA Does Not Do

Hard limits on the detection engineering pipeline

ARIA does not apply suppression rules automatically. Every proposal requires security engineer approval before it takes effect.
ARIA does not write new detection rules. The detection engineering capability is scoped to tuning existing rules — proposing suppressions for known-benign patterns — not authoring new logic.
ARIA does not generate proposals without a clear pattern. If the benign cases for a rule do not share a specific, narrow field pattern, no proposal is generated. Ambiguous cases are surfaced for manual review rather than producing a low-confidence proposal.
Proposals are not acted on by any automated system. They sit in the review queue until a security engineer explicitly approves or rejects them.

The Security Engineer's Role

Detection engineering is an area where automation supports human judgment — it does not replace it. ARIA handles the observational work: tracking which rules fire, correlating the field values across cases, identifying candidate patterns. The security engineer brings the judgment that automation cannot: whether a proposed suppression is genuinely safe for this environment, whether it matches a behavior that has an attack-relevant variant, and whether the evidence is sufficient to act on.

A proposal that ARIA rates as high-confidence may still be wrong. The engineer's review is the control that catches cases where the pattern ARIA identified is coincidental rather than structural. Rejection is a valid outcome — and a useful signal that feeds back into how ARIA frames future proposals for that rule.

Endpoint DetectionThe Wazuh rules being tuned

All Use CasesEmail, identity, endpoint, cloud

How ARIA WorksThe full triage pipeline

SaaS CompaniesDetection maturity for SOC 2 audit evidence

Common Questions

How long does it take before ARIA generates a first proposal?

ARIA needs a baseline of triage history for a given (tenant, rule_id) pair before it can identify a reliable pattern. There is no fixed threshold — the time depends on how frequently the rule fires and how consistent the benign disposition pattern is. Rules that fire multiple times per day and consistently close benign will accumulate a pattern faster than rules that fire infrequently. The detection engineering agent runs its analysis nightly and surfaces proposals when the evidence crosses a confidence threshold. There is no accelerated timeline for new deployments.

What happens if an approved suppression later turns out to suppress a real threat?

A suppression that was appropriate when applied can become a coverage gap as attacker techniques evolve. ARIA monitors applied suppressions against new alert data — if an alert that would be suppressed appears in a context associated with an active threat investigation, ARIA flags the potential conflict to the reviewing engineer. Suppressions can be reverted at any time through the ARIA portal. The audit trail records when each suppression was approved, by whom, and what evidence it was based on — providing a record for any retrospective review.

Can ARIA tune rules in other SIEMs beyond Wazuh?

The current detection engineering capability is built around the Wazuh rule and alert schema. Rules from other SIEM sources that flow through Wazuh and carry a mapped rule ID are candidates for tuning proposals. Rules from SIEM platforms with a distinct schema — separate Elasticsearch indices, different field naming — are not currently in scope for automated tuning proposals. The underlying mechanism (observing benign dispositions, extracting field patterns, proposing suppressions) is not Wazuh-specific, and extending it to other platforms is on the roadmap.

Is the security engineer expected to have detection engineering expertise to review proposals?

Proposals are written to be legible without deep detection engineering expertise. Each proposal includes the rule that fired, a plain-language description of what pattern was observed, the list of specific cases it would suppress, and the proposed condition in structured form. A security engineer reviewing escalations from ARIA — who understands the environment and the typical activity pattern for their users and hosts — has the context needed to evaluate whether a proposed suppression is reasonable. For proposals involving nuanced rule logic, the ARIA portal provides the full evidence set for a more detailed review.

Rule Tuning, Backed by Evidence