Purple › Module 3 › Lesson 3
False Positive Cost
False positive cost literacy names alert fatigue, tuning tradeoffs, and baseline noise — quantify FP impact on YOUR $PURPLE_LAB before deploying broad rules.
Visual · t35_false_positive_cost
False positive cost literacy. $PURPLE_LAB only. Original Cyberlium.
Opening
Every false alert steals analyst minutes — literacy teaches FP cost so detection engineers tune precisely on lab baselines you document.
False positives waste SOC triage time, erode trust in detection programs, and hide true positives in noise. Cost scales with alert volume — one FP per day is manageable; fifty per hour burns the team. Tuning adds specificity — parent process filters, path exclusions, frequency thresholds — validated against lab baselines before production. Cyberlium writes FP cost notes on YOUR $PURPLE_LAB — estimate triage minutes per FP and one tuning action for a fictional noisy rule. Next: DE Basics Lab.
1. False positive cost factors (named)
Triage time: minutes per alert × analyst hourly cost × daily volume. Trust erosion: analysts disable or ignore rules after repeated FPs. Missed true positives: noise hides real incidents in alert queues. Tuning cost: engineer hours to refine rule logic and re-test.
On $PURPLE_LAB, write FP row — rule name, estimated daily FPs, triage minutes, one tuning action.
Command guide
Try these commands — False positive cost factors (named)
═══ LINUX / macOS (Terminal Practice) ═══
Check system state and user context
Command — copy this
id whoami uname -a
Inspect network sockets listening for connections
Command — copy this
ss -tuln 2>/dev/null || netstat -tuln
Audit active processes
Command — copy this
ps aux | grep -v "\[" | head -15
═══ WINDOWS (POWERSHELL) ═══ Query user identity and system information
Command — copy this
whoami /all Get-ComputerInfo | Select-Object CsName, OsName, OsVersion
Primary tools to practice this lesson: grep, python3. Reference sites: Sigma false positives (https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide); Splunk tuning (https://docs.splunk.com/Documentation/ES); MITRE T1110 (https://attack.mitre.org/techniques/T1110/). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why FP literacy prevents alert storms
Broad rules — 'any PowerShell execution' — flood SOCs. Untested deploys without baseline comparison cause production incidents. Purple exercises measure FP rate on lab hosts before rollout.
Students quantify lab FP cost on notes — production tuning follows SOC metrics and executive reporting.
3. Lab boundary
Forbidden: deploying untested broad rules to production to 'maximize detection.' Allowed: false positive cost card — FP estimate and tuning action on $PURPLE_LAB fictional rule.
Ship: false positive cost card for YOUR lab rule. Next: DE Basics Lab.
4. What you ship: false positive cost card for $PURPLE_LAB
FP estimate, triage cost, tuning action. $PURPLE_LAB named. chmod 600.
5. What you record before the next lesson
Date. False positive cost card. $PURPLE_LAB named. File t35-m03-l03-false-positive-cost.txt chmod 600.
6. Wrong vs right: stranger networks vs YOUR purple lab
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
Deploy broad rule without baseline test. Ignore FP rate because 'more alerts is safer.'
Right
Write false positive cost card for YOUR $PURPLE_LAB. Next: DE Basics Lab.
Mission: quantify FP cost on YOUR lab rule
1) Estimate triage minutes per false alert. 2) Write FP row for one fictional noisy rule. 3) Propose one tuning action with rationale. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Baseline before deploy — know normal noise on lab hosts before you add signal.
Knowledge Check
APPLY: False positive cost primarily includes:
Multiple choice
Knowledge Check
APPLY: True or False: Broad untested rules can cause alert storms that hide real incidents.
True or False
Knowledge Check
APPLY: False positive literacy on Cyberlium uses:
Multiple choice