Implementando a Redução da Fadiga de Alertas

Quando Usar

Use esta habilidade quando:

• Analistas de SOC enfrentam mais alertas do que podem investigar razoavelmente (>100 alertas/analista/turno)
• Taxas de falsos positivos excedem 70% em regras de detecção chave
• Verdadeiros positivos estão sendo perdidos ou descartados devido ao volume de alertas
• A gerência relata declínio no moral dos analistas ou aumento na rotatividade relacionado à carga de trabalho

Não use para justificar o desativamento de regras de detecção sem análise — reduzir alertas não deve criar pontos cegos na detecção.

Pré-requisitos

• SIEM com 90+ dias de dados de disposição de alertas (verdadeiro positivo, falso positivo, benigno)
• Métricas de alertas: volume, taxa de disposição, MTTD, MTTR por regra
• Recursos de engenharia de detecção para ajuste e teste de regras
• Splunk ES com capacidade de alerta baseado em risco (RBA) ou equivalente
• Métricas de capacidade de analista de linha de base (alertas por analista por turno)

Fluxo de Trabalho

Etapa 1: Medir a Qualidade Atual dos Alertas

Quantifique o problema antes de fazer alterações:

--- Alert volume and disposition analysis (last 90 days)
index=notable earliest=-90d
| stats count AS total_alerts,
        sum(eval(if(status_label="Resolved - True Positive", 1, 0))) AS true_positives,
        sum(eval(if(status_label="Resolved - False Positive", 1, 0))) AS false_positives,
        sum(eval(if(status_label="Resolved - Benign", 1, 0))) AS benign,
        sum(eval(if(status_label="New" OR status_label="In Progress", 1, 0))) AS unresolved
  by rule_name
| eval fp_rate = round(false_positives / total_alerts * 100, 1)
| eval tp_rate = round(true_positives / total_alerts * 100, 1)
| eval signal_to_noise = round(true_positives / (false_positives + 0.01), 2)
| sort - total_alerts
| table rule_name, total_alerts, true_positives, false_positives, benign, fp_rate, tp_rate, signal_to_noise

--- Top 10 noisiest rules (candidates for tuning)
| search fp_rate > 70 OR total_alerts > 1000
| sort - false_positives
| head 10

Volume diário de alertas por analista:

index=notable earliest=-30d
| bin _time span=1d
| stats count AS daily_alerts by _time
| stats avg(daily_alerts) AS avg_daily, max(daily_alerts) AS peak_daily,
        stdev(daily_alerts) AS stdev_daily
| eval alerts_per_analyst = round(avg_daily / 6, 0)  --- 6 analysts per shift
| eval capacity_status = case(
    alerts_per_analyst > 100, "CRITICAL — Exceeds analyst capacity",
    alerts_per_analyst > 50, "WARNING — Approaching capacity limits",
    1=1, "HEALTHY — Within manageable range"
  )

Etapa 2: Implementar Alerta Baseado em Risco (RBA)

Converta alertas baseados em limiar para pontuação de risco no Splunk ES:

--- Instead of generating an alert for every failed login, contribute risk
--- Risk Rule: Failed Authentication (contributes to risk score, no alert)
index=wineventlog EventCode=4625
| stats count by src_ip, TargetUserName, ComputerName
| where count > 5
| eval risk_score = case(
    count > 50, 40,
    count > 20, 25,
    count > 10, 15,
    count > 5, 5
  )
| eval risk_object = src_ip
| eval risk_object_type = "system"
| eval risk_message = count." failed logins from ".src_ip." targeting ".TargetUserName
| collect index=risk

--- Risk Rule: Successful Login After Failures (additive risk)
index=wineventlog EventCode=4624 Logon_Type=3
| lookup risk_scores src_ip AS src_ip OUTPUT total_risk
| where total_risk > 0
| eval risk_score = 30
| eval risk_message = "Successful login after ".total_risk." risk points from ".src_ip
| collect index=risk

--- Risk Threshold Alert: Only alert when cumulative risk exceeds threshold
index=risk earliest=-24h
| stats sum(risk_score) AS total_risk, values(risk_message) AS risk_events,
        dc(source) AS contributing_rules by risk_object
| where total_risk >= 75
| eval urgency = case(
    total_risk >= 150, "critical",
    total_risk >= 100, "high",
    total_risk >= 75, "medium"
  )
--- This single alert replaces 10+ individual threshold alerts

Comparação Antes do RBA vs. Depois do RBA:

BEFORE RBA:
  Rule: "Failed Login > 5"         → 847 alerts/day  (FP rate: 92%)
  Rule: "Suspicious Process"       → 234 alerts/day  (FP rate: 78%)
  Rule: "Network Anomaly"          → 156 alerts/day  (FP rate: 85%)
  Total: 1,237 alerts/day

AFTER RBA:
  Risk aggregation alerts           → 23 alerts/day   (FP rate: 18%)
  Each alert contains full context from multiple risk contributions
  Reduction: 98% fewer alerts with HIGHER true positive rate

Etapa 3: Ajustar Regras de Alto Volume de Falsos Positivos

…