Funnel of Fidelity — From Collection to Investigation

Jared Atkinson’s Funnel of Fidelity frames detection engineering as a pipeline optimization problem. Every stage of the funnel has a cost — engineering time, compute cost, analyst time — and the goal is to maximize threat signal while minimizing cost at each stage.

The Funnel

    Telemetry collected
    (billions of events/day)
           │
           ▼
    ██████████████████████████████  ← All events
           │ detection rules filter
           ▼
    ██████                          ← Candidate alerts (~0.1% of events)
           │ analyst triage
           ▼
    ████                            ← True positives (~10% of alerts)
           │ investigation
           ▼
    ██                              ← Confirmed incidents + response

Each stage narrows the volume but increases the human investment per event:

Why FP Rate Matters More Than Detection Rate

Scenario A: Detection rate 90%, FP rate 80%

• 100 real attacks per day → 90 detected
• 90 alerts are true positives, 360 alerts are false positives = 450 total alerts
• Analyst processes 450 alerts/day

Scenario B: Detection rate 80%, FP rate 20%

• 100 real attacks per day → 80 detected
• 80 alerts are true positives, 20 alerts are false positives = 100 total alerts
• Analyst processes 100 alerts/day

Scenario B misses 10 more real attacks but allows analysts to process 4.5× fewer alerts. Analysts spend more time per alert (better investigation) and have headroom to improve the detection program. Scenario A produces alert fatigue and analyst burnout — leading to real threats being missed in the queue.

Optimizing Each Funnel Stage

Collect: Collect what you need, not everything

Storing every packet, every log, every event is expensive and creates noise at the detect stage. Target your collection:

• High-value, low-volume: Windows Security Events (4688, 4624, 4625) — always collect
• High-value, high-volume: DNS queries — collect, but may need sampling for cost
• Low-value, high-volume: HTTP 200 responses to well-known CDNs — consider filtering at collection
• High-value, episodic: Packet captures — capture on demand during incidents, not always

Detect: Rules that fire at the right rate

A rule that fires on every process creation is useless (too much volume). A rule that fires once a year may be misconfigured (never fires). Target rule design:

• High-value rules: Fire rarely (< 5 times/day per environment), near-certain TP
• Medium-value rules: Fire weekly, require triage to distinguish TP from FP
• Feed-based rules: Fire frequently, automatically enriched with threat intel, suppressed if no TI match

Triage: Analyst automation

Triage automation reduces the analyst tax:

• Auto-enrichment: Append threat intel, asset criticality, user risk score to every alert
• Auto-close: Rules with near-zero TP rate in your environment can be auto-closed pending review
• SOAR playbooks: For predictable FP patterns, automate the resolution steps
• Alert dedup: Suppress repeat alerts from the same entity within a time window

Investigate: Reserve for confirmed TPs

If analysts spend time investigating FPs, you’re wasting your most expensive resource. The goal: analysts should spend ≥80% of investigation time on confirmed true positives.