September 1, 2026
The Cost of Noisy Rules
A rule that fires 10,000 alerts daily is worse than no rule at all. Analysts learn to ignore it, and real threats buried in the noise go uninvestigated. Detection tuning is the discipline of reducing false positives while preserving true positive coverage. It is not a one-time task. It is an ongoing practice.
Systematic FP Reduction Workflow
Follow this process for every noisy rule: review a sample of recent alerts, identify the pattern causing false positives (specific users, IPs, service accounts, resource names), and add targeted exclusions. Never suppress alerts blindly. Understand why they fire before tuning them out.
Three Tuning Techniques
1. Add exclusion conditions in the events section. Filter out known-good activity directly in the rule logic:
not $e.principal.user.email_addresses in %approved_admins.email
2. Use data tables for dynamic allow-lists. Data tables let you maintain exclusion lists that update without modifying the rule itself. Add a service account to the table, and the rule immediately stops alerting on it.
3. Adjust match window and threshold. If 10 events in 15 minutes generates too much noise, try 20 in 15 minutes, or 10 in 5 minutes. Tune the threshold to the level where true positives consistently appear.
Before and After: A Tuning Example
Before (200 alerts/day, 80% false positive rate):
rule detect_admin_access_v1 {
meta:
severity = "HIGH"
description = "Detects admin resource access in GCP Cloud Audit logs"
events:
$e.metadata.event_type = "USER_RESOURCE_ACCESS"
$e.metadata.log_type = "GCP_CLOUDAUDIT"
$e.target.resource.name = /.*admin.*/
$e.principal.user.email_addresses = $user
match:
$user over 1h
outcome:
$access_count = count($e.metadata.id)
condition:
#e >= 1 and $access_count >= 1
}
After (5 alerts/day, 95%+ true positive rate):
rule detect_admin_access_v2 {
meta:
severity = "HIGH"
description = "Detects unauthorized admin resource access from non-corporate IPs"
events:
$e.metadata.event_type = "USER_RESOURCE_ACCESS"
$e.metadata.log_type = "GCP_CLOUDAUDIT"
$e.target.resource.name = /.*admin.*/
$e.principal.user.email_addresses = $user
// Data table lookups (STRING and CIDR)
not $user in %approved_admins.email
not $e.principal.ip in cidr %corporate_networks.cidr
match:
$user over 1h
outcome:
$access_count = count($e.metadata.id)
$resources = array_distinct($e.target.resource.name)
condition:
$access_count >= 3
}
What changed: two data table exclusions filter out approved administrators and corporate network IPs. The threshold increased from 1 to 3, eliminating one-off legitimate accesses. The outcome now captures distinct resource names, giving analysts immediate context about what was accessed.
Severity Tiering
Assign severity levels based on the expected response:
- CRITICAL: Pages someone immediately. Active compromise indicators only.
- HIGH: Reviewed same-day by an analyst.
- MEDIUM: Goes to a review queue for weekly triage.
- LOW / INFO: Used for trending and statistical analysis, not direct investigation.
Apply these tuning techniques to every detection rule you deploy. Each rule should be reviewed within its first week of production.
