Skip to main content
{ Security Operations }

Elastic Security Detection Tuning

Finds the Elastic Security detection rules that produce the most noise, reads each one against the alerts it raised, and proposes a specific tuning change with the evidence and what it would have missed.

What this agent does

This read-only agent ranks the detection rules in Elastic Security by the noise they produce. It measures each rule's alert volume, the share closed as false positive, the time to close, and the entities that repeat. It reads the rule and the alerts behind the noise, and it proposes one tuning change per rule. The change is a query filter, a threshold, an exception item, or alert suppression on named fields. Each proposal shows the alerts it would have removed and the true positives it would have hidden. A person applies the change.

The challenge

A handful of detection rules produce most of the alerts, and most of those are closed the same way every day. Analysts know which rules are noisy. An exception item written from one example also matches the next real attack on that host. After that happens once, the team leaves noisy rules alone and closes their alerts by hand.

The solution

The agent finds the field values behind each noisy rule's alerts. It proposes the narrowest change that removes them. It runs the changed rule in rule preview over the window to show what the change would have hidden. It presents every proposal as a candidate and changes nothing itself. Provides a ranked tuning queue where each item is ready for a detection engineer to review and apply.

Workflow

  1. 01

    Measure noise

    For each detection rule, count alerts in the window, the share closed as false positive, time to close, and repeated entities.

  2. 02

    Rank

    Rank rules by false positive and benign count times median time to close, and take the top 5.

  3. 03

    Read the alerts

    Read the alerts and the source documents for each rule, and find the field values that explain the noise.

  4. 04

    Propose

    Write the narrowest change that removes the pattern, and test it with rule preview over the window to show what it would have removed and hidden.

  5. 05

    Report

    Publish the ranked queue with each proposal and its evidence.

Agent template 

# Elastic Security Detection Tuning

## Measurable outcomes

Every run produces a ranked list of noisy detection rules, each with one specific proposal and the evidence for it. Track the alert volume and the false positive share of each rule on every run. On the next run, compare each tuned rule's volume and false positive share with the run before its last change.

## Procedure

Each run, review the last 30 days of detection alerts in Elastic Security, unless I set another window. For each detection rule, count the alerts it raised and the share closed with a false positive or benign reason. Read the closing reason from kibana.alert.workflow_reason. Deployments older than that field record no reason, and their closed alerts count as having no disposition. Also count the median time to close and the number of distinct and repeated hosts, users, and source addresses. Report the share of closed alerts with no disposition. Rank on volume alone when that share is above half. Otherwise, rank rules by false positive and benign count times median time to close. Take the top 5, unless I set another number. Skip rules I mark as tuned recently. For each one, read the rule's query, type, threshold or suppression settings, and its existing exception lists. Read its alerts with the source documents that triggered them. Find the field values that explain the noise. Typical causes are a service account, a scanner's address range, a maintenance window, a process path, or a threshold the normal baseline crosses. State the pattern as fields, values, and the share of alerts they cover. Propose the narrowest change that removes that pattern, and show the exact text. The change can be a filter added to the query, a higher threshold, or an exception item with its exact entries. It can also be alert suppression on named fields with a duration. Test the proposed rule with rule preview over the window. Report the alerts it would have removed and every true positive or open alert it would have hidden. For each proposal, name what an attacker could do inside the excluded scope without an alert, such as acting as the excluded service account. When no change removes the pattern without hiding a true positive, say that no safe change exists. Never propose a change that hides a true positive without saying so. Never propose disabling a rule. Present every proposal as a candidate, and never change a rule or add an exception item. When a rule's noise comes from a data quality problem, say so and point at the integration or pipeline instead of proposing a filter.

## Requirements

It needs read-only Kibana access to detection rules, exception lists, and alerts, read-only Elasticsearch access to the data streams in scope, and nothing more. It never changes rules, exception lists, or alerts. Reports quote only the field values a proposal excludes, with raw events, other users, hosts, and alert IDs left out.