False Positive

One-liner: A security alert triggered by benign activity that is incorrectly flagged as malicious.

🎯 What Is It?

A false positive (FP) occurs when a security detection system (SIEM, IDS, antivirus, etc.) generates an alert for activity that appears suspicious but is actually legitimate. False positives waste analyst time, cause alert fatigue, and can lead to real threats being missed.

⚠️ The Problem with False Positives

Alert Fatigue

High FP Rate → Analyst Burnout → Missed True Threats

When SOC analysts face thousands of alerts daily, with 80%+ being false positives, they:

• Become desensitized to alerts
• Rush through investigations
• May dismiss genuine threats ("cry wolf" effect)
• Experience burnout and high turnover

Cost Impact

• Time: Each FP investigation = 10-30 minutes wasted
• Resources: Tier 1 analysts spend 50-70% of time on FPs
• Risk: True positives get buried in noise

🔍 Common Causes

✅ Reducing False Positives

1. Baseline Normal Behavior

Understand what's normal in your environment:

• Admin PowerShell usage patterns
• Expected file access patterns
• Regular maintenance windows
• Authorized scanning activities

2. Tune Detection Rules

Before: Alert on ANY PowerShell execution
After:  Alert on PowerShell + encoded command + no digital signature

3. Use Allowlists

• Allowlist known admin accounts
• Allowlist legitimate IPs/domains
• Allowlist approved software hashes

4. Add Context

• Correlate with Asset Inventory (is this a server admin?)
• Check time of day (off-hours vs. business hours)
• Enrich with threat intel

5. Tiered Alerting

Informational → Low → Medium → High → Critical

Not everything needs immediate escalation.

6. Continuous Feedback Loop

Analyst marks FP → Detection Engineer tunes rule → Deploy update

🆚 False Positive vs False Negative

Security Trade-off:

• Too sensitive → High FP rate → Alert fatigue
• Too lenient → High false negative rate → Missed attacks

Goal: Balance detection sensitivity with operational efficiency.

📊 Measuring FP Rate

Formula

FP Rate = (False Positives / Total Alerts) × 100

Industry Benchmarks

• Poor: 80%+ FP rate
• Average: 50-70% FP rate
• Good: 20-40% FP rate
• Excellent: <20% FP rate

Tracking

Week 1: 1000 alerts → 850 FPs (85%)
Tune rules...
Week 4: 600 alerts → 180 FPs (30%)

🛠️ Detection Engineering Approach

Example: Tuning a Brute Force Alert

Initial Rule (High FP):

Trigger: 1 failed login attempt

Tuned Rule (Low FP):

Trigger: 
  - 10+ failed login attempts
  - Within 5 minutes
  - From same source IP
  - Against multiple accounts
  - Outside business hours
  - AND source IP not in admin allowlist

🎤 Interview Angles

Q: How do you handle a high false positive rate in your SOC?

STAR Example:
Situation: Our SOC had an 80% FP rate on PowerShell execution alerts.
Task: Reduce FPs without missing real threats.
Action:

• Analyzed 2 weeks of FP alerts to find patterns
• Baselined legitimate admin PowerShell usage
• Tuned rule to require: encoded commands + network connection + unsigned
• Created allowlist for known admin scripts
  Result: Reduced FPs by 60%, detected 2 real Malware cases that would've been missed.

Q: What's worse—false positives or false negatives?

• False Negatives are objectively worse (missed breaches)
• BUT high false positives lead to alert fatigue, which causes false negatives to be missed
• Best approach: Tune aggressively to reduce FPs while validating detection coverage with Purple Teaming

🔗 Related Concepts

• Alert Triage — Where FPs are identified
• Detection Engineering — Responsible for tuning
• Detection Maturity Level Model — Measures detection quality
• Alerting and Detection Strategies Framework — Structured detection design
• SOC analysts — Impacted by FP rate