Skip to content
Security & Trust

Elastic now grades its detection rules monthly on noise, speed and threat fit

385 of 1,781 prebuilt rules are tagged Recommended; 61.8% are deliberately left untagged.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Elastic now grades its detection rules monthly on noise, speed and threat fit
In brief
  • Elastic Security Labs now tags its prebuilt SIEM detection rules for noise, speed and threat focus. The tags are recalculated monthly from 30 days of fleet telemetry.
  • Of 1,781 rules in scope, 385 are tagged Recommended, 296 Aggressive and 1,100 are deliberately untagged. The labels reflect Elastic's own thresholds and fleet.
  • Ask your team which enabled rules are noisy or slow, who reviews rule changes, and how often those judgments are refreshed.

Many teams treat a detection rule like a purchase. You switch it on and assume it works. Elastic Security Labs describes something closer to a staff review. A rule has a track record, and that record changes over time. The lesson here is that rule quality is measured continuously, not fixed at install.

What Elastic changed

Elastic has added operational tags to its prebuilt SIEM detection rules. A SIEM is the system that collects security logs and raises alerts. The new tags are Noise, Performance, Threat and Profile.

Older rule metadata says what a rule detects. The new tags say how a rule behaves in production.

Each month, Elastic's software looks back over 30 days of data from customer deployments. It scores every prebuilt rule. It then opens a draft pull request on the elastic/detection-rules repository. Elastic's Threat Command team reviews that request before anything merges. Software drafts the changes; people decide whether they go in.

How the scoring works

The Noise tag starts from an average. Elastic counts alerts per environment, using only the days the rule actually fired. The internal metric is called global_noise. This keeps one very busy customer from skewing the result.

Rules that reach the 85th percentile or higher for their platform are marked Noise: High. Elastic also marks a rule High if its alert density is extreme, or if a new rule is loud in its first 60 days.

Percentile cuts are set separately for platforms such as Windows, AWS and Okta. Elastic says what counts as noisy differs across environments.

The Performance tag uses fixed limits instead. A rule is Fast only if four conditions hold. Its average run is 400 milliseconds or less. Its 95th-percentile run is under one second. It has no 30-second runs. It has been sampled in at least five environments. A rule averaging five seconds or more is Very Slow.

The Profile tag combines severity, noise, speed and threat match into one score. Recommended needs a score of 7 or higher. Two gates apply on top. Any rule with Noise: High becomes Aggressive, whatever its score. Low-severity rules cannot be Recommended.

Aggressive marks rules that are High noise or that score low. It does not mean a rule is bad. Check the Noise and Performance tags before enabling one, and use suppression where needed.

385 of 1,781 (21.6%)
Rules tagged Profile: Recommended
Source: Elastic Security Labs (October 5, 2026)
296 of 1,781 (16.6%)
Rules tagged Profile: Aggressive
Source: Elastic Security Labs (October 5, 2026)
1,100 (61.8%)
Rules deliberately left untagged
Source: Elastic Security Labs (October 5, 2026)

The empty tags carry information too

Two design choices stand out. First, a new rule is Noise: Unknown for its first 60 days if it has too little signal. A quiet new rule may simply be switched on in few places. So Elastic holds back the Low label. Performance: Unknown works the same way. It applies with fewer than 50 executions or fewer than three environments sampled.

Second, most rules get no Profile tag at all. Elastic says this is intentional. A single label would hide the tradeoffs in these rules. Elastic adds that some of its most targeted detections sit in this group. They need more testing in your own environment before a broad rollout.

A score that admits it lacks data is more useful than one that always answers. Executives can ask the same of any security dashboard.

Where AI sits, and where it does not

The scoring is deterministic. That means code applies fixed rules. Elastic uses large language models in one place only. When its heuristic catalog has no match for the Threat tag, a model suggests candidates.

Elastic filters those suggestions against its managed catalog. It caps them at five tags per rule. Human review gates the result. The model can only pick from the approved list.

This is a useful pattern. The model handles judgment about what a rule does. Code handles thresholds and arithmetic. Elastic also leaves manually curated tags alone, such as a Cobalt Strike label.

Limits to keep in mind

The tags come from telemetry that Elastic users choose to share. The percentiles and thresholds reflect Elastic's fleet and Elastic's choices.

A rule that is quiet across that fleet can still be noisy in your environment. Elastic itself says Recommended means rules it believes are safe to enable broadly.

The 1,781 count excludes building block, machine learning, deprecated, promotion and threat intelligence rules. Elastic calls its figures a point-in-time snapshot.

Questions to put to your security team

Which of our enabled rules are noisy, and which are slow? When did someone last check? Who approves rule changes, and is one person accountable for each?

If we use Elastic, do we start with Recommended rules? Do we treat Noise: Unknown as a watch item for a release cycle or two, as Elastic advises? If we use another SIEM, does the vendor publish similar measures?

A rule that fires all day wastes an analyst's time. A rule with no measurements is hard to defend. Ask for the track record, not just the install.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Elastic Security Labs.

Share this insight