Exfiltration alert routing configured

Severity: Recommended (Critical for big projects)

When exfiltration is detected, alerts must reach the right people immediately with actionable context - not just logged somewhere nobody checks.

Check automatically:

1. Check for alert destinations:

# Slack webhook configuration
grep -rE "slack.*webhook|SLACK_WEBHOOK|hooks\.slack\.com" --include="*.ts" --include="*.js" --include="*.yml" --include="*.env*" 2>/dev/null

# PagerDuty configuration
grep -rE "pagerduty|PAGERDUTY" --include="*.ts" --include="*.js" --include="*.yml" --include="*.env*" 2>/dev/null

# Email alerting
grep -rE "alert.*email|sendgrid|ses.*alert|smtp.*alert" --include="*.ts" --include="*.js" --include="*.yml" 2>/dev/null

# Generic webhook/notification config
grep -rE "webhook.*alert|notification.*url|alert.*endpoint" --include="*.ts" --include="*.js" --include="*.yml" 2>/dev/null

2. Check cloud provider alerting:

# AWS SNS topics for security alerts
aws sns list-topics 2>/dev/null | jq '.Topics[].TopicArn' | grep -iE "security|alert|incident"

# AWS CloudWatch alarm actions
aws cloudwatch describe-alarms --query "MetricAlarms[].AlarmActions" 2>/dev/null

# GCP alerting policies
gcloud alpha monitoring policies list --format="table(displayName,notificationChannels)" 2>/dev/null

3. Check Cloudflare notifications:

# Cloudflare notification destinations
curl -sX GET "https://api.cloudflare.com/client/v4/accounts/{account_id}/alerting/v3/destinations/webhooks" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" 2>/dev/null | jq '.result'

curl -sX GET "https://api.cloudflare.com/client/v4/accounts/{account_id}/alerting/v3/destinations/pagerduty" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" 2>/dev/null | jq '.result'

4. Check for security-specific alert routing:

# Look for security alert categorization
grep -rE "security.*alert|exfiltration|intrusion|breach|incident" --include="*.ts" --include="*.js" src/ 2>/dev/null

# Check for alert severity/priority routing
grep -rE "alert.*severity|priority.*high|critical.*notify|escalat" --include="*.ts" --include="*.js" --include="*.yml" src/ 2>/dev/null

5. Check for on-call/escalation configuration:

# PagerDuty/Opsgenie escalation
grep -rE "escalation|on-call|oncall|rotation" --include="*.yml" --include="*.json" --include="*.ts" 2>/dev/null

# Incident response documentation
find . -type f \( -name "*incident*" -o -name "*runbook*" -o -name "*playbook*" \) 2>/dev/null

Ask user:

• "Who gets notified when a security alert fires?"
• "Are security alerts routed differently from ops alerts?"
• "What's the escalation path if the primary contact doesn't respond?"
• "How quickly should someone acknowledge a security alert?"

Alert quality requirements:

• Include context: what happened, why it's suspicious
• Include affected resources: IP, user, endpoint, query
• Include recommended action: what to investigate first
• Not just "high bandwidth detected" but "IP x.x.x.x downloaded 500MB in 10 minutes from /api/users"

Cross-reference with:

• IDS-002 (network alerts feed into this)
• IDS-003 (database alerts feed into this)
• INC-001 (on-call rotation from section 35)
• MON-004 (general alerting from section 12)

Pass criteria:

• Alert destinations configured for security events
• Recipients defined (not just "whoever's on call" - security-aware people)
• Alerts are immediate (not batched/daily digest)
• Alerts include actionable context (what, where, why suspicious, what to do)
• Escalation path exists if primary contact unavailable

Fail criteria:

• Alerts go to a log file nobody reads
• No defined recipients for security alerts
• Alerts batched (daily/weekly) instead of immediate
• Alerts are raw data without context
• No escalation if primary contact unavailable

Evidence to capture:

• Alert destinations (Slack channel, PagerDuty, email list)
• Security alert recipients (names/roles)
• Escalation path documentation
• Example alert format (does it include context?)
• SLA for alert acknowledgment (if defined)

---