Agent skill

performing-false-positive-reduction-in-siem

Perform systematic SIEM false positive reduction through rule tuning, threshold adjustment, correlation refinement, and threat intelligence enrichment to combat alert fatigue.

View SKILL.md on GitHub Repository
Stars 0
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/autohandai/community-skills/tree/main/performing-false-positive-reduction-in-siem

SKILL.md

Performing False Positive Reduction in SIEM

Overview

False positive alerts are non-malicious events that trigger security rules, overwhelming SOC analysts with noise. Studies show that up to 45% of SIEM alerts are false positives, and a typical SOC analyst can only investigate 20-25 alerts per shift effectively. Reducing false positives requires systematic tuning across thresholds, correlation logic, allowlists, enrichment, and continuous validation. SIEM rules should be reviewed on a quarterly cycle at minimum.

False Positive Reduction Techniques

1. Identify the Noisiest Rules

spl
# Splunk - Top 10 noisiest correlation searches
index=notable
| stats count by rule_name
| sort -count
| head 10
| eval pct=round(count / total * 100, 1)
spl
# False positive rate per rule
index=notable
| stats count as total
    count(eval(status_label="Closed - False Positive")) as false_positives
    count(eval(status_label="Closed - True Positive")) as true_positives
    by rule_name
| eval fp_rate=round(false_positives / total * 100, 1)
| sort -fp_rate
| where total > 10

2. Threshold Tuning

spl
# Before: Too sensitive - fires on 5 failed logins
index=wineventlog EventCode=4625
| stats count by src_ip
| where count > 5

# After: Tuned - requires 20+ failures across 3+ accounts in 10 minutes
index=wineventlog EventCode=4625
| bin _time span=10m
| stats count dc(TargetUserName) as unique_accounts by src_ip, _time
| where count > 20 AND unique_accounts > 3

3. Allowlist/Exclusion Management

spl
# Create allowlist lookup for known benign sources
| inputlookup fp_allowlist.csv
| fields src_ip, reason, approved_by, expiry_date

# Apply allowlist in detection rule
index=wineventlog EventCode=4625
| lookup fp_allowlist src_ip OUTPUT reason as allowlisted_reason
| where isnull(allowlisted_reason)
| stats count dc(TargetUserName) as unique_accounts by src_ip
| where count > 20 AND unique_accounts > 3

4. Correlation Enhancement

spl
# Before: Single-event detection (noisy)
index=wineventlog EventCode=4688 New_Process_Name="*powershell.exe"
| eval severity="medium"

# After: Multi-signal correlation (precise)
index=wineventlog EventCode=4688 New_Process_Name="*powershell.exe"
| join src_ip type=left [
    search index=wineventlog EventCode=4625
    | stats count as failed_logins by src_ip
]
| join Computer type=left [
    search index=sysmon EventCode=3
    | stats dc(DestinationIp) as unique_external_connections by Computer
    | where unique_external_connections > 10
]
| where isnotnull(failed_logins) OR unique_external_connections > 10
| eval severity=case(
    failed_logins > 10 AND unique_external_connections > 10, "critical",
    failed_logins > 5 OR unique_external_connections > 5, "high",
    true(), "medium"
)

5. Time-Based Exclusions

spl
# Exclude known maintenance windows
| eval hour=strftime(_time, "%H")
| eval day=strftime(_time, "%A")
| where NOT (hour >= "02" AND hour <= "04" AND day="Sunday")

# Exclude known batch job schedules
| lookup scheduled_tasks_allowlist process_name, schedule_time
    OUTPUT is_scheduled
| where isnull(is_scheduled)

6. Behavioral Baseline Integration

spl
# Build baseline for user login patterns
index=wineventlog EventCode=4624
| bin _time span=1h
| stats count as logins dc(Computer) as unique_hosts by TargetUserName, _time
| eventstats avg(logins) as avg_logins stdev(logins) as stdev_logins
    avg(unique_hosts) as avg_hosts stdev(unique_hosts) as stdev_hosts
    by TargetUserName
| where logins > (avg_logins + 3 * stdev_logins)
    OR unique_hosts > (avg_hosts + 3 * stdev_hosts)

7. Threat Intelligence Filtering

spl
# Only alert when destination matches known threat intelligence
index=firewall action=allowed direction=outbound
| lookup ip_threat_intel_lookup ip as dest_ip OUTPUT threat_type, confidence
| where isnotnull(threat_type) AND confidence > 70
# This eliminates FPs from flagging connections to benign IPs

Tuning Process Framework

Step 1: Identify (Weekly)

  • Pull top 10 rules by alert volume
  • Calculate FP rate for each
  • Identify rules with FP rate > 30%

Step 2: Analyze (Weekly)

  • Sample 20 false positives per rule
  • Categorize root cause of each FP
  • Identify common patterns

Step 3: Tune (Bi-weekly)

  • Adjust thresholds based on baseline data
  • Add allowlist entries for benign patterns
  • Enhance correlation logic
  • Add enrichment context

Step 4: Validate (Monthly)

  • Run Atomic Red Team tests to verify true positives still trigger
  • Calculate new FP rate after tuning
  • Document tuning rationale
  • Review with detection engineering team

Step 5: Report (Quarterly)

  • FP reduction metrics per rule
  • Overall alert volume trends
  • Analyst productivity improvements
  • Rules retired or replaced

Validation Testing

bash
# Run Atomic Red Team test after tuning to confirm detection still works
# Example: Test brute force detection after threshold adjustment
Invoke-AtomicTest T1110.001 -TestNumbers 1
spl
# Verify detection still triggers after tuning
index=notable rule_name="Brute Force Detection"
earliest=-24h
| stats count
| where count > 0

FP Reduction Metrics

Metric Formula Target
False Positive Rate FP / (FP + TP) * 100 < 20%
Alert Volume Reduction (Old Volume - New Volume) / Old Volume * 100 30-50% per quarter
Mean Triage Time Total triage time / Total alerts < 8 minutes
Rule Precision TP / (TP + FP) > 0.80
Analyst Satisfaction Survey score > 4/5

References

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

autohandai/community-skills

mapping-mitre-attack-techniques

Maps observed adversary behaviors, security alerts, and detection rules to MITRE ATT&CK techniques and sub-techniques to quantify detection coverage and guide control prioritization. Use when building an ATT&CK-based coverage heatmap, tagging SIEM alerts with technique IDs, aligning security controls to adversary playbooks, or reporting threat exposure to executives. Activates for requests involving ATT&CK Navigator, Sigma rules, MITRE D3FEND, or coverage gap analysis.

0 0
Explore
autohandai/community-skills

hunting-for-spearphishing-indicators

Hunt for spearphishing campaign indicators across email logs, endpoint telemetry, and network data to detect targeted email attacks.

0 0
Explore
autohandai/community-skills

analyzing-malicious-url-with-urlscan

URLScan.io is a free service for scanning and analyzing suspicious URLs. It captures screenshots, DOM content, HTTP transactions, JavaScript behavior, and network connections of web pages in an isolat

0 0
Explore
autohandai/community-skills

implementing-zero-standing-privilege-with-cyberark

Deploy CyberArk Secure Cloud Access to eliminate standing privileges in hybrid and multi-cloud environments using just-in-time access with time, entitlement, and approval controls.

0 0
Explore
autohandai/community-skills

implementing-pam-for-database-access

Deploy privileged access management for database systems including Oracle, SQL Server, PostgreSQL, and MySQL. Covers session proxy configuration, credential vaulting, query auditing, dynamic credentia

0 0
Explore
autohandai/community-skills

detecting-t1003-credential-dumping-with-edr

Detect OS credential dumping techniques targeting LSASS memory, SAM database, NTDS.dit, and cached credentials using EDR telemetry, Sysmon process access monitoring, and Windows security event correlation.

0 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results