3.4.3.5. Configuring Alerting Based on Unexpected or Anomalous Security Events

3.4.3.5. Configuring Alerting Based on Unexpected or Anomalous Security Events

Real-time security alerting bridges the gap between detection and response.

GuardDuty severity-based alerting:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 7]}]
  }
}

• Severity 7-8.9 (High): Immediate investigation required
• Severity 4-6.9 (Medium): Investigate during business hours
• Severity 0.1-3.9 (Low): Review periodically

Security Hub alerting:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL"]},
      "Workflow": {"Status": ["NEW"]}
    }
  }
}

Alerting architecture:

• Critical findings (severity ≥ 7): EventBridge → SNS → PagerDuty (immediate page)
• High findings (severity 4-6): EventBridge → SNS → Slack ops channel
• Compliance violations: Config rule → EventBridge → Jira ticket creation
• All findings: EventBridge → Kinesis Firehose → S3 (security data lake for analysis)

Suppression rules in GuardDuty and Security Hub filter out known-good findings (e.g., a security scanner's port probes) to reduce alert fatigue.

Exam Trap: Security Hub findings have a Workflow.Status field: NEW, NOTIFIED, SUPPRESSED, RESOLVED. Your EventBridge rules should filter on NEW to avoid re-alerting on findings that are already being investigated. Without this filter, every update to an existing finding triggers a new alert.