[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEY61TQMN91JQPCZ4EJ4G9":3,"skill-same:01M6AEY61TQMN91JQPCZ4EJ4G9":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":70,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6AEY61TQMN91JQPCZ4EJ4G9","implementing-alert-fatigue-reduction",null,"Implements strategies to reduce SOC alert fatigue by tuning detection rules, consolidating duplicate alerts, implementing risk-based alerting, and measuring alert quality metrics to maintain analyst effectiveness and prevent critical alert dismissal. Use when SOC teams face overwhelming alert volumes, high false positive rates, or declining analyst performance.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-alert-fatigue-reduction\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"implementing alert fatigue reduction","detection","false-positive","risk-based-alerting","tuning","alert-fatigue","t1566","risk","t1078","performance","detection-engineering","soc","engineering","alerting","metrics","teams","siem","cybersecurity","2026-11-10 10:12:30",false,"---\nname: implementing-alert-fatigue-reduction\ndescription: 'Implements strategies to reduce SOC alert fatigue by tuning detection\n  rules, consolidating duplicate alerts, implementing risk-based alerting, and measuring\n  alert quality metrics to maintain analyst effectiveness and prevent critical alert\n  dismissal. Use when SOC teams face overwhelming alert volumes, high false positive\n  rates, or declining analyst performance.\n\n  '\ndomain: cybersecurity\nsubdomain: soc-operations\ntags:\n- soc\n- alert-fatigue\n- tuning\n- risk-based-alerting\n- false-positive\n- siem\n- detection-engineering\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\n- DE.AE-02\n- RS.MA-01\n- DE.AE-06\nmitre_attack:\n- T1078\n- T1685.002\n- T1685.005\n- T1566\n- T0816\n---\n# Implementing Alert Fatigue Reduction\n\n## When to Use\n\nUse this skill when:\n- SOC analysts face more alerts than they can reasonably investigate (>100 alerts\u002Fanalyst\u002Fshift)\n- False positive rates exceed 70% on key detection rules\n- True positives are being missed or dismissed due to alert volume\n- Management reports declining analyst morale or increasing turnover related to workload\n\n**Do not use** to justify disabling detection rules without analysis — reducing alerts must not create detection blind spots.\n\n## Prerequisites\n\n- SIEM with 90+ days of alert disposition data (true positive, false positive, benign)\n- Alert metrics: volume, disposition rate, MTTD, MTTR per rule\n- Detection engineering resources for rule tuning and testing\n- Splunk ES with risk-based alerting (RBA) capability or equivalent\n- Baseline analyst capacity metrics (alerts per analyst per shift)\n\n## Workflow\n\n### Step 1: Measure Current Alert Quality\n\nQuantify the problem before making changes:\n\n```spl\n--- Alert volume and disposition analysis (last 90 days)\nindex=notable earliest=-90d\n| stats count AS total_alerts,\n        sum(eval(if(status_label=\"Resolved - True Positive\", 1, 0))) AS true_positives,\n        sum(eval(if(status_label=\"Resolved - False Positive\", 1, 0))) AS false_positives,\n        sum(eval(if(status_label=\"Resolved - Benign\", 1, 0))) AS benign,\n        sum(eval(if(status_label=\"New\" OR status_label=\"In Progress\", 1, 0))) AS unresolved\n  by rule_name\n| eval fp_rate = round(false_positives \u002F total_alerts * 100, 1)\n| eval tp_rate = round(true_positives \u002F total_alerts * 100, 1)\n| eval signal_to_noise = round(true_positives \u002F (false_positives + 0.01), 2)\n| sort - total_alerts\n| table rule_name, total_alerts, true_positives, false_positives, benign, fp_rate, tp_rate, signal_to_noise\n\n--- Top 10 noisiest rules (candidates for tuning)\n| search fp_rate > 70 OR total_alerts > 1000\n| sort - false_positives\n| head 10\n```\n\n**Daily alert volume per analyst:**\n```spl\nindex=notable earliest=-30d\n| bin _time span=1d\n| stats count AS daily_alerts by _time\n| stats avg(daily_alerts) AS avg_daily, max(daily_alerts) AS peak_daily,\n        stdev(daily_alerts) AS stdev_daily\n| eval alerts_per_analyst = round(avg_daily \u002F 6, 0)  --- 6 analysts per shift\n| eval capacity_status = case(\n    alerts_per_analyst > 100, \"CRITICAL — Exceeds analyst capacity\",\n    alerts_per_analyst > 50, \"WARNING — Approaching capacity limits\",\n    1=1, \"HEALTHY — Within manageable range\"\n  )\n```\n\n### Step 2: Implement Risk-Based Alerting (RBA)\n\nConvert threshold-based alerts to risk scoring in Splunk ES:\n\n```spl\n--- Instead of generating an alert for every failed login, contribute risk\n--- Risk Rule: Failed Authentication (contributes to risk score, no alert)\nindex=wineventlog EventCode=4625\n| stats count by src_ip, TargetUserName, ComputerName\n| where count > 5\n| eval risk_score = case(\n    count > 50, 40,\n    count > 20, 25,\n    count > 10, 15,\n    count > 5, 5\n  )\n| eval risk_object = src_ip\n| eval risk_object_type = \"system\"\n| eval risk_message = count.\" failed logins from \".src_ip.\" targeting \".TargetUserName\n| collect index=risk\n```\n\n```spl\n--- Risk Rule: Successful Login After Failures (additive risk)\nindex=wineventlog EventCode=4624 Logon_Type=3\n| lookup risk_scores src_ip AS src_ip OUTPUT total_risk\n| where total_risk > 0\n| eval risk_score = 30\n| eval risk_message = \"Successful login after \".total_risk.\" risk points from \".src_ip\n| collect index=risk\n```\n\n```spl\n--- Risk Threshold Alert: Only alert when cumulative risk exceeds threshold\nindex=risk earliest=-24h\n| stats sum(risk_score) AS total_risk, values(risk_message) AS risk_events,\n        dc(source) AS contributing_rules by risk_object\n| where total_risk >= 75\n| eval urgency = case(\n    total_risk >= 150, \"critical\",\n    total_risk >= 100, \"high\",\n    total_risk >= 75, \"medium\"\n  )\n--- This single alert replaces 10+ individual threshold alerts\n```\n\n**Before RBA vs After RBA comparison:**\n```\nBEFORE RBA:\n  Rule: \"Failed Login > 5\"         → 847 alerts\u002Fday  (FP rate: 92%)\n  Rule: \"Suspicious Process\"       → 234 alerts\u002Fday  (FP rate: 78%)\n  Rule: \"Network Anomaly\"          → 156 alerts\u002Fday  (FP rate: 85%)\n  Total: 1,237 alerts\u002Fday\n\nAFTER RBA:\n  Risk aggregation alerts           → 23 alerts\u002Fday   (FP rate: 18%)\n  Each alert contains full context from multiple risk contributions\n  Reduction: 98% fewer alerts with HIGHER true positive rate\n```\n\n### Step 3: Tune High-Volume False Positive Rules\n\nSystematically tune the noisiest rules:\n\n```spl\n--- Identify common false positive patterns\nindex=notable rule_name=\"Suspicious PowerShell Execution\" status_label=\"Resolved - False Positive\"\nearliest=-90d\n| stats count by src, dest, user, CommandLine\n| sort - count\n| head 20\n--- Reveals: SCCM client generating 80% of false positives\n```\n\nApply tuning:\n\n```spl\n--- Original rule (generating false positives)\nindex=sysmon EventCode=1 Image=\"*\\\\powershell.exe\"\n  (CommandLine=\"*-enc*\" OR CommandLine=\"*-encodedcommand*\" OR CommandLine=\"*invoke-expression*\")\n| where count > 0\n\n--- Tuned rule (excluding known legitimate sources)\nindex=sysmon EventCode=1 Image=\"*\\\\powershell.exe\"\n  (CommandLine=\"*-enc*\" OR CommandLine=\"*-encodedcommand*\" OR CommandLine=\"*invoke-expression*\")\n  NOT [| inputlookup powershell_whitelist.csv | fields CommandLine_pattern]\n  NOT (ParentImage=\"*\\\\ccmexec.exe\" OR ParentImage=\"*\\\\sccm*\")\n  NOT (User=\"SYSTEM\" AND ParentImage=\"*\\\\services.exe\" AND\n       CommandLine=\"*Microsoft\\\\ConfigMgr*\")\n| where count > 0\n```\n\nDocument tuning decisions:\n```yaml\nrule_name: Suspicious PowerShell Execution\ntuning_date: 2024-03-15\noriginal_fp_rate: 78%\ntuned_fp_rate: 22%\nexclusions_added:\n  - ParentImage containing ccmexec.exe (SCCM client)\n  - User=SYSTEM with ConfigMgr in CommandLine\n  - Scheduled task: Windows Update PowerShell module\nalerts_reduced: ~180\u002Fday eliminated\ndetection_impact: None — exclusions verified against ATT&CK test cases\napproved_by: detection_engineering_lead\n```\n\n### Step 4: Implement Alert Consolidation\n\nGroup related alerts into single incidents:\n\n```spl\n--- Consolidate alerts by source IP within time window\nindex=notable earliest=-1h\n| sort _time\n| dedup src, rule_name span=300\n| stats count AS alert_count, values(rule_name) AS related_rules,\n        earliest(_time) AS first_alert, latest(_time) AS last_alert\n  by src\n| where alert_count > 3\n| eval consolidated_alert = src.\" triggered \".alert_count.\" related alerts: \".mvjoin(related_rules, \", \")\n```\n\n**Splunk ES Notable Event Suppression:**\n```spl\n--- Suppress duplicate alerts for the same source\u002Fdest pair within 1 hour\n| notable\n| dedup src, dest, rule_name span=3600\n```\n\n### Step 5: Implement Tiered Alert Routing\n\nRoute alerts based on confidence and severity:\n\n```\nALERT ROUTING STRATEGY\n━━━━━━━━━━━━━━━━━━━━━\nTier 1 (Automated):\n  - Risk score \u003C 30: Auto-close with enrichment data logged\n  - Known false positive patterns: Auto-suppress (reviewed quarterly)\n  - Informational alerts: Route to dashboard only (no queue)\n\nTier 2 (Analyst Review):\n  - Risk score 30-75: Standard triage queue\n  - Medium confidence alerts: Analyst decision required\n  - Enriched with automated context (VT, AbuseIPDB, asset info)\n\nTier 3 (Priority Investigation):\n  - Risk score > 75: Immediate investigation\n  - Deception alerts: Auto-escalate (zero false positive)\n  - Known malware detection: Auto-contain + analyst review\n```\n\nImplement in Splunk:\n```spl\nindex=notable\n| eval routing = case(\n    urgency=\"critical\" OR source=\"deception\", \"TIER3_IMMEDIATE\",\n    urgency=\"high\" AND risk_score > 75, \"TIER3_IMMEDIATE\",\n    urgency=\"high\" OR urgency=\"medium\", \"TIER2_STANDARD\",\n    urgency=\"low\" AND fp_rate > 80, \"TIER1_AUTO_CLOSE\",\n    1=1, \"TIER2_STANDARD\"\n  )\n| where routing != \"TIER1_AUTO_CLOSE\"  --- Auto-closed alerts removed from queue\n```\n\n### Step 6: Measure Improvement and Maintain\n\nTrack alert fatigue metrics over time:\n\n```spl\n--- Weekly alert quality trend\nindex=notable earliest=-90d\n| bin _time span=1w\n| stats count AS total,\n        sum(eval(if(status_label=\"Resolved - True Positive\", 1, 0))) AS tp,\n        sum(eval(if(status_label=\"Resolved - False Positive\", 1, 0))) AS fp\n  by _time\n| eval tp_rate = round(tp \u002F total * 100, 1)\n| eval fp_rate = round(fp \u002F total * 100, 1)\n| eval alerts_per_analyst = round(total \u002F 42, 0)  --- 6 analysts * 7 days\n| table _time, total, tp, fp, tp_rate, fp_rate, alerts_per_analyst\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|-----------|\n| **Alert Fatigue** | Cognitive overload from excessive alert volumes leading analysts to dismiss or ignore valid alerts |\n| **Risk-Based Alerting (RBA)** | Detection approach aggregating risk contributions from multiple events before generating a single high-context alert |\n| **Signal-to-Noise Ratio** | Ratio of true positive alerts to false positives — higher ratio indicates better alert quality |\n| **False Positive Rate** | Percentage of alerts classified as benign after investigation — target \u003C30% for production rules |\n| **Alert Consolidation** | Grouping related alerts from the same source\u002Fcampaign into a single investigation unit |\n| **Detection Tuning** | Process of refining rule logic to exclude known benign patterns while maintaining true positive detection |\n\n## Tools & Systems\n\n- **Splunk ES Risk-Based Alerting**: Framework converting individual detections into cumulative risk scores per entity\n- **Splunk ES Adaptive Response**: Actions that can auto-close, suppress, or route alerts based on enrichment results\n- **Elastic Detection Rules**: Built-in severity and risk score assignment with exception lists for tuning\n- **Chronicle SOAR**: Google's SOAR platform with automated alert deduplication and grouping capabilities\n- **Tines**: No-code SOAR platform enabling custom alert routing and automated enrichment workflows\n\n## Common Scenarios\n\n- **Post-RBA Implementation**: Convert 15 threshold alerts into risk contributions, reducing daily volume by 85%\n- **Quarterly Tuning Cycle**: Review top 20 noisiest rules, apply exclusions, measure FP rate improvement\n- **New Tool Deployment**: After deploying new EDR, tune initial detection rules to baseline the environment\n- **Analyst Capacity Planning**: Calculate optimal alert-to-analyst ratio (target 40-60 alerts\u002Fanalyst\u002Fshift)\n- **Compliance Balance**: Maintain detection coverage for compliance while reducing operational alert volume\n\n## Output Format\n\n```\nALERT FATIGUE REDUCTION REPORT — Q1 2024\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nBefore (January 2024):\n  Daily Alert Volume:     1,847\n  Alerts\u002FAnalyst\u002FShift:   154\n  False Positive Rate:    82%\n  True Positive Rate:     8%\n  Signal-to-Noise:        0.10\n  Analyst Morale:         Low (2 resignations in Q4)\n\nAfter (March 2024):\n  Daily Alert Volume:     287 (-84%)\n  Alerts\u002FAnalyst\u002FShift:   24\n  False Positive Rate:    23% (-72% improvement)\n  True Positive Rate:     41% (+413% improvement)\n  Signal-to-Noise:        1.78\n\nChanges Implemented:\n  [1] Risk-Based Alerting deployed (15 rules converted)       -1,200 alerts\u002Fday\n  [2] Top 10 noisy rules tuned with exclusion lists           -280 alerts\u002Fday\n  [3] Alert consolidation (5-min dedup window)                -80 alerts\u002Fday\n  [4] Tier 1 auto-close for low-confidence alerts             -N\u002FA (removed from queue)\n\nDetection Coverage Impact: NONE — ATT&CK coverage maintained at 67%\nTrue Positive Detection Rate: IMPROVED — 12 additional true positives caught per week\n```\n","# Implementing Alert Fatigue Reduction\n\n## When to Use\n\nUse this skill when:\n- SOC analysts face more alerts than they can reasonably investigate (>100 alerts\u002Fanalyst\u002Fshift)\n- False positive rates exceed 70% on key detection rules\n- True positives are being missed or dismissed due to alert volume\n- Management reports declining analyst morale or increasing turnover related to workload\n\n**Do not use** to justify disabling detection rules without analysis — reducing alerts must not create detection blind spots.\n\n## Prerequisites\n\n- SIEM with 90+ days of alert disposition data (true positive, false positive, benign)\n- Alert metrics: volume, disposition rate, MTTD, MTTR per rule\n- Detection engineering resources for rule tuning and testing\n- Splunk ES with risk-based alerting (RBA) capability or equivalent\n- Baseline analyst capacity metrics (alerts per analyst per shift)\n\n## Workflow\n\n### Step 1: Measure Current Alert Quality\n\nQuantify the problem before making changes:\n\n```spl\n--- Alert volume and disposition analysis (last 90 days)\nindex=notable earliest=-90d\n| stats count AS total_alerts,\n        sum(eval(if(status_label=\"Resolved - True Positive\", 1, 0))) AS true_positives,\n        sum(eval(if(status_label=\"Resolved - False Positive\", 1, 0))) AS false_positives,\n        sum(eval(if(status_label=\"Resolved - Benign\", 1, 0))) AS benign,\n        sum(eval(if(status_label=\"New\" OR status_label=\"In Progress\", 1, 0))) AS unresolved\n  by rule_name\n| eval fp_rate = round(false_positives \u002F total_alerts * 100, 1)\n| eval tp_rate = round(true_positives \u002F total_alerts * 100, 1)\n| eval signal_to_noise = round(true_positives \u002F (false_positives + 0.01), 2)\n| sort - total_alerts\n| table rule_name, total_alerts, true_positives, false_positives, benign, fp_rate, tp_rate, signal_to_noise\n\n--- Top 10 noisiest rules (candidates for tuning)\n| search fp_rate > 70 OR total_alerts > 1000\n| sort - false_positives\n| head 10\n```\n\n**Daily alert volume per analyst:**\n```spl\nindex=notable earliest=-30d\n| bin _time span=1d\n| stats count AS daily_alerts by _time\n| stats avg(daily_alerts) AS avg_daily, max(daily_alerts) AS peak_daily,\n        stdev(daily_alerts) AS stdev_daily\n| eval alerts_per_analyst = round(avg_daily \u002F 6, 0)  --- 6 analysts per shift\n| eval capacity_status = case(\n    alerts_per_analyst > 100, \"CRITICAL — Exceeds analyst capacity\",\n    alerts_per_analyst > 50, \"WARNING — Approaching capacity limits\",\n    1=1, \"HEALTHY — Within manageable range\"\n  )\n```\n\n### Step 2: Implement Risk-Based Alerting (RBA)\n\nConvert threshold-based alerts to risk scoring in Splunk ES:\n\n```spl\n--- Instead of generating an alert for every failed login, contribute risk\n--- Risk Rule: Failed Authentication (contributes to risk score, no alert)\nindex=wineventlog EventCode=4625\n| stats count by src_ip, TargetUserName, ComputerName\n| where count > 5\n| eval risk_score = case(\n    count > 50, 40,\n    count > 20, 25,\n    count > 10, 15,\n    count > 5, 5\n  )\n| eval risk_object = src_ip\n| eval risk_object_type = \"system\"\n| eval risk_message = count.\" failed logins from \".src_ip.\" targeting \".TargetUserName\n| collect index=risk\n```\n\n```spl\n--- Risk Rule: Successful Login After Failures (additive risk)\nindex=wineventlog EventCode=4624 Logon_Type=3\n| lookup risk_scores src_ip AS src_ip OUTPUT total_risk\n| where total_risk > 0\n| eval risk_score = 30\n| eval risk_message = \"Successful login after \".total_risk.\" risk points from \".src_ip\n| collect index=risk\n```\n\n```spl\n--- Risk Threshold Alert: Only alert when cumulative risk exceeds threshold\nindex=risk earliest=-24h\n| stats sum(risk_score) AS total_risk, values(risk_message) AS risk_events,\n        dc(source) AS contributing_rules by risk_object\n| where total_risk >= 75\n| eval urgency = case(\n    total_risk >= 150, \"critical\",\n    total_risk >= 100, \"high\",\n    total_risk >= 75, \"medium\"\n  )\n--- This single alert replaces 10+ individual threshold alerts\n```\n\n**Before RBA vs After RBA comparison:**\n```\nBEFORE RBA:\n  Rule: \"Failed Login > 5\"         → 847 alerts\u002Fday  (FP rate: 92%)\n  Rule: \"Suspicious Process\"       → 234 alerts\u002Fday  (FP rate: 78%)\n  Rule: \"Network Anomaly\"          → 156 alerts\u002Fday  (FP rate: 85%)\n  Total: 1,237 alerts\u002Fday\n\nAFTER RBA:\n  Risk aggregation alerts           → 23 alerts\u002Fday   (FP rate: 18%)\n  Each alert contains full context from multiple risk contributions\n  Reduction: 98% fewer alerts with HIGHER true positive rate\n```\n\n### Step 3: Tune High-Volume False Positive Rules\n\nSystematically tune the noisiest rules:\n\n```spl\n--- Identify common false positive patterns\nindex=notable rule_name=\"Suspicious PowerShell Execution\" status_label=\"Resolved - False Positive\"\nearliest=-90d\n| stats count by src, dest, user, CommandLine\n| sort - count\n| head 20\n--- Reveals: SCCM client generating 80% of false positives\n```\n\nApply tuning:\n\n```spl\n--- Original rule (generating false positives)\nindex=sysmon EventCode=1 Image=\"*\\\\powershell.exe\"\n  (CommandLine=\"*-enc*\" OR CommandLine=\"*-encodedcommand*\" OR CommandLine=\"*invoke-expression*\")\n| where count > 0\n\n--- Tuned rule (excluding known legitimate sources)\nindex=sysmon EventCode=1 Image=\"*\\\\powershell.exe\"\n  (CommandLine=\"*-enc*\" OR CommandLine=\"*-encodedcommand*\" OR CommandLine=\"*invoke-expression*\")\n  NOT [| inputlookup powershell_whitelist.csv | fields CommandLine_pattern]\n  NOT (ParentImage=\"*\\\\ccmexec.exe\" OR ParentImage=\"*\\\\sccm*\")\n  NOT (User=\"SYSTEM\" AND ParentImage=\"*\\\\services.exe\" AND\n       CommandLine=\"*Microsoft\\\\ConfigMgr*\")\n| where count > 0\n```\n\nDocument tuning decisions:\n```yaml\nrule_name: Suspicious PowerShell Execution\ntuning_date: 2024-03-15\noriginal_fp_rate: 78%\ntuned_fp_rate: 22%\nexclusions_added:\n  - ParentImage containing ccmexec.exe (SCCM client)\n  - User=SYSTEM with ConfigMgr in CommandLine\n  - Scheduled task: Windows Update PowerShell module\nalerts_reduced: ~180\u002Fday eliminated\ndetection_impact: None — exclusions verified against ATT&CK test cases\napproved_by: detection_engineering_lead\n```\n\n### Step 4: Implement Alert Consolidation\n\nGroup related alerts into single incidents:\n\n```spl\n--- Consolidate alerts by source IP within time window\nindex=notable earliest=-1h\n| sort _time\n| dedup src, rule_name span=300\n| stats count AS alert_count, values(rule_name) AS related_rules,\n        earliest(_time) AS first_alert, latest(_time) AS last_alert\n  by src\n| where alert_count > 3\n| eval consolidated_alert = src.\" triggered \".alert_count.\" related alerts: \".mvjoin(related_rules, \", \")\n```\n\n**Splunk ES Notable Event Suppression:**\n```spl\n--- Suppress duplicate alerts for the same source\u002Fdest pair within 1 hour\n| notable\n| dedup src, dest, rule_name span=3600\n```\n\n### Step 5: Implement Tiered Alert Routing\n\nRoute alerts based on confidence and severity:\n\n```\nALERT ROUTING STRATEGY\n━━━━━━━━━━━━━━━━━━━━━\nTier 1 (Automated):\n  - Risk score \u003C 30: Auto-close with enrichment data logged\n  - Known false positive patterns: Auto-suppress (reviewed quarterly)\n  - Informational alerts: Route to dashboard only (no queue)\n\nTier 2 (Analyst Review):\n  - Risk score 30-75: Standard triage queue\n  - Medium confidence alerts: Analyst decision required\n  - Enriched with automated context (VT, AbuseIPDB, asset info)\n\nTier 3 (Priority Investigation):\n  - Risk score > 75: Immediate investigation\n  - Deception alerts: Auto-escalate (zero false positive)\n  - Known malware detection: Auto-contain + analyst review\n```\n\nImplement in Splunk:\n```spl\nindex=notable\n| eval routing = case(\n    urgency=\"critical\" OR source=\"deception\", \"TIER3_IMMEDIATE\",\n    urgency=\"high\" AND risk_score > 75, \"TIER3_IMMEDIATE\",\n    urgency=\"high\" OR urgency=\"medium\", \"TIER2_STANDARD\",\n    urgency=\"low\" AND fp_rate > 80, \"TIER1_AUTO_CLOSE\",\n    1=1, \"TIER2_STANDARD\"\n  )\n| where routing != \"TIER1_AUTO_CLOSE\"  --- Auto-closed alerts removed from queue\n```\n\n### Step 6: Measure Improvement and Maintain\n\nTrack alert fatigue metrics over time:\n\n```spl\n--- Weekly alert quality trend\nindex=notable earliest=-90d\n| bin _time span=1w\n| stats count AS total,\n        sum(eval(if(status_label=\"Resolved - True Positive\", 1, 0))) AS tp,\n        sum(eval(if(status_label=\"Resolved - False Positive\", 1, 0))) AS fp\n  by _time\n| eval tp_rate = round(tp \u002F total * 100, 1)\n| eval fp_rate = round(fp \u002F total * 100, 1)\n| eval alerts_per_analyst = round(total \u002F 42, 0)  --- 6 analysts * 7 days\n| table _time, total, tp, fp, tp_rate, fp_rate, alerts_per_analyst\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|-----------|\n| **Alert Fatigue** | Cognitive overload from excessive alert volumes leading analysts to dismiss or ignore valid alerts |\n| **Risk-Based Alerting (RBA)** | Detection approach aggregating risk contributions from multiple events before generating a single high-context alert |\n| **Signal-to-Noise Ratio** | Ratio of true positive alerts to false positives — higher ratio indicates better alert quality |\n| **False Positive Rate** | Percentage of alerts classified as benign after investigation — target \u003C30% for production rules |\n| **Alert Consolidation** | Grouping related alerts from the same source\u002Fcampaign into a single investigation unit |\n| **Detection Tuning** | Process of refining rule logic to exclude known benign patterns while maintaining true positive detection |\n\n## Tools & Systems\n\n- **Splunk ES Risk-Based Alerting**: Framework converting individual detections into cumulative risk scores per entity\n- **Splunk ES Adaptive Response**: Actions that can auto-close, suppress, or route alerts based on enrichment results\n- **Elastic Detection Rules**: Built-in severity and risk score assignment with exception lists for tuning\n- **Chronicle SOAR**: Google's SOAR platform with automated alert deduplication and grouping capabilities\n- **Tines**: No-code SOAR platform enabling custom alert routing and automated enrichment workflows\n\n## Common Scenarios\n\n- **Post-RBA Implementation**: Convert 15 threshold alerts into risk contributions, reducing daily volume by 85%\n- **Quarterly Tuning Cycle**: Review top 20 noisiest rules, apply exclusions, measure FP rate improvement\n- **New Tool Deployment**: After deploying new EDR, tune initial detection rules to baseline the environment\n- **Analyst Capacity Planning**: Calculate optimal alert-to-analyst ratio (target 40-60 alerts\u002Fanalyst\u002Fshift)\n- **Compliance Balance**: Maintain detection coverage for compliance while reducing operational alert volume\n\n## Output Format\n\n```\nALERT FATIGUE REDUCTION REPORT — Q1 2024\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nBefore (January 2024):\n  Daily Alert Volume:     1,847\n  Alerts\u002FAnalyst\u002FShift:   154\n  False Positive Rate:    82%\n  True Positive Rate:     8%\n  Signal-to-Noise:        0.10\n  Analyst Morale:         Low (2 resignations in Q4)\n\nAfter (March 2024):\n  Daily Alert Volume:     287 (-84%)\n  Alerts\u002FAnalyst\u002FShift:   24\n  False Positive Rate:    23% (-72% improvement)\n  True Positive Rate:     41% (+413% improvement)\n  Signal-to-Noise:        1.78\n\nChanges Implemented:\n  [1] Risk-Based Alerting deployed (15 rules converted)       -1,200 alerts\u002Fday\n  [2] Top 10 noisy rules tuned with exclusion lists           -280 alerts\u002Fday\n  [3] Alert consolidation (5-min dedup window)                -80 alerts\u002Fday\n  [4] Tier 1 auto-close for low-confidence alerts             -N\u002FA (removed from queue)\n\nDetection Coverage Impact: NONE — ATT&CK coverage maintained at 67%\nTrue Positive Detection Rate: IMPROVED — 12 additional true positives caught per week\n```\n",{"name":5,"tags":47,"author":48,"domain":41,"license":15,"version":49,"nist_csf":50,"subdomain":55,"description":56,"mitre_attack":57},[35,29,28,27,26,40,34],"mahipal","1.0",[51,52,53,54],"DE.CM-01","DE.AE-02","RS.MA-01","DE.AE-06","soc-operations","Implements strategies to reduce SOC alert fatigue by tuning detection rules, consolidating duplicate alerts, implementing risk-based alerting, and measuring alert quality metrics to maintain analyst effectiveness and prevent critical alert dismissal. Use when SOC teams face overwhelming alert volumes, high false positive rates, or declining analyst performance.\n",[58,59,60,61,62],"T1078","T1685.002","T1685.005","T1566","T0816","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fimplementing-alert-fatigue-reduction",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-alert-fatigue-reduction",{"tool":79,"command":80},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-alert-fatigue-reduction",{"tool":82,"command":83},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-alert-fatigue-reduction","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-alert-fatigue-reduction\u002FSKILL.md",true,[87,92,98],{"path":88,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-alert-fatigue-reduction\u002FLICENSE",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fapi-reference.md","REFERENCE","参考文档",2002,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-alert-fatigue-reduction\u002Freferences\u002Fapi-reference.md",{"path":99,"resourceType":100,"resourceTypeDesc":101,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Fagent.py","SCRIPT","脚本",7282,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-alert-fatigue-reduction\u002Fscripts\u002Fagent.py",[105,132,156,182,208,234],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":42},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[111],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,115,116,117,41,118,119,120,121,122,123,124,125,126,127,128,129,130,131],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":42},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[138],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[140,128,141,142,117,143,41,120,144,145,146,147,148,149,150,151,152,153,154,155],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":166,"publishedAt":42},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[162,165],{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[150,167,168,169,170,41,171,172,144,173,174,175,176,177,25,32,178,179,180,181],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":42},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[190,191,192,41,193,194,195,196,197,198,199,200,201,202,203,204,147,205,206,207],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"publishedAt":42},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[214],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[216,217,218,41,219,220,221,222,223,224,225,226,227,228,31,229,230,231,232,233],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":42},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[240],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,242,41,40,243,244,35,245,246,247,248,32,249,178,250,251,252,253,254,255],"triaging security incident","file","ioc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]