WAF++ WAF++
Back to WAF++ Homepage

WAF-SEC-100 – Incident Response Readiness

Pillar: Security | Severity: Medium | Kategorie: Incident Response | Automatisierbar: Gering

Beschreibung

Jede Organisation, die produktive Cloud-Workloads betreibt, MUSS über dokumentierte Incident-Response-Prozesse verfügen. Ein Incident-Response-Runbook MUSS für mindestens die Szenarien „Kompromittierte IAM-Credentials", „Datenleck / öffentlich zugänglicher S3-Bucket" und „GuardDuty HIGH/CRITICAL Finding" existieren. GuardDuty-Findings MÜSSEN via SNS-Alerting an einen definierten On-Call-Kanal (PagerDuty, Opsgenie, Slack) weitergeleitet werden. Incident-Response-Drills MÜSSEN mindestens einmal jährlich durchgeführt und dokumentiert werden.

Rationale

Incident Response planen zu müssen, während ein Incident aktiv ist, führt zu langsamen Reaktionen, Entscheidungsfehlern und erhöhtem Schaden. Dokumentierte Runbooks ermöglichen es auch unerfahrenen On-Call-Personen, strukturiert zu reagieren. GuardDuty-Alerting ohne definierten Eskalationsweg ist wertlos – Findings müssen einen menschlichen Entscheider erreichen, nicht nur einen Log-Stream. Drills testen die Realitätsnähe der Runbooks und identifizieren Lücken, bevor ein echter Incident eintritt.

Bedrohungskontext

Risiko Beschreibung

Langsame MTTR durch fehlende Runbooks

Ohne vordefinierte Prozesse verbringen On-Call-Teams Zeit mit Planung statt Reaktion – die MTTR steigt dramatisch.

Nicht erreichbare Alerts

GuardDuty-Findings, die nur in der Konsole landen, werden außerhalb der Bürozeiten nicht bemerkt.

Beweisverlust durch falsche Containment-Reihenfolge

Falsches Vorgehen (z. B. sofortiges Löschen kompromittierter Ressourcen) kann forensische Beweise vernichten.

DSGVO-Meldepflicht verfehlt

Ohne klaren Eskalationsprozess wird die 72-Stunden-Meldefrist nach Art. 33 DSGVO nicht eingehalten.

Anforderung

  • Ein Incident-Response-Runbook MUSS im Repository (oder verknüpftem Wiki) versioniert verfügbar sein.

  • GuardDuty-Findings der Severity >= HIGH MÜSSEN via EventBridge + SNS an einen On-Call-Kanal weitergeleitet werden.

  • Das Runbook MUSS mindestens abdecken: Kompromittierte IAM-Credentials, S3-Public-Access-Breach, CRITICAL GuardDuty Finding.

  • Incident-Response-Drills (Tabletop oder Live) MÜSSEN mindestens einmal jährlich durchgeführt und dokumentiert werden.

  • Klare Eskalationswege (wer wird wann informiert) MÜSSEN dokumentiert sein.

  • Post-Incident-Reviews (PIR) MÜSSEN nach jedem HIGH/CRITICAL-Incident mit Blameless-Ansatz durchgeführt werden.

Implementierungsanleitung

  1. EventBridge-Regel für GuardDuty: aws_cloudwatch_event_rule auf Source aws.guardduty mit Detail-Type GuardDuty Finding und Severity-Filter >= 4.0.

  2. SNS-Topic konfigurieren: aws_sns_topic mit E-Mail- oder HTTPS-Subscriptions zu PagerDuty/Opsgenie-Endpoint.

  3. Runbook erstellen: Mindestens 3 Szenarien mit Detect → Contain → Eradicate → Recover → Post-Mortem Struktur.

  4. Eskalationsmatrix dokumentieren: Wer ist First Responder? Wer ist Incident Commander? Wer informiert Datenschutzbeauftragten?

  5. Drills planen: Quartalsweise Tabletop-Übung für On-Call-Team; jährlicher Live-Drill mit simulierten GuardDuty-Findings.

  6. Post-Incident-Review-Template: 5-Why-Analyse + Lessons-Learned + konkrete Action Items mit Owner und Datum.

  7. Run-Log einführen: Jeder Incident bekommt ein Ticket mit Zeitstempel jeder Aktion (für DSGVO-Dokumentation).

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Kein Incident-Response-Prozess

Kein Runbook; GuardDuty-Findings werden nicht weitergeleitet; Incidents ad-hoc behandelt.

2

Rudimentäre Dokumentation

Einfaches Runbook existiert; GuardDuty-Alerts per E-Mail; kein strukturierter Eskalationsweg; keine Drills.

3

Definierter IR-Prozess mit Alerting

Mindestens 3 Runbooks; GuardDuty → EventBridge → PagerDuty/On-Call; jährlicher Drill; Post-Incident-Reviews.

4

Proaktive IR-Vorbereitung

Alle CRITICAL-Szenarien mit Runbooks abgedeckt; SOAR-Automation für erste Containment-Schritte; monatliche Drills.

5

Vollautomatisierter Response mit SOAR

Automatisierte Playbooks für bekannte Incident-Typen; MTTR < 1h; vollständige DSGVO-Incident-Dokumentation automatisiert.

Terraform Checks

waf-sec-100.tf.aws.guardduty-sns-alerting

Prüft: EventBridge-Regel für GuardDuty-Findings muss mit SNS-Target konfiguriert sein.

Compliant Non-Compliant 
resource "aws_cloudwatch_event_rule" "guardduty_alerts" {
  name        = "guardduty-high-severity"
  description = "Alert on HIGH/CRITICAL GuardDuty findings"
  event_pattern = jsonencode({
    source      = ["aws.guardduty"]
    detail-type = ["GuardDuty Finding"]
    detail = {
      severity = [{ numeric = [">=", 4] }]
    }
  })
}

resource "aws_cloudwatch_event_target" "guardduty_sns" {
  rule      = aws_cloudwatch_event_rule.guardduty_alerts.name
  target_id = "guardduty-sns"
  arn       = aws_sns_topic.security_alerts.arn
}
 
# Kein EventBridge-Target für GuardDuty
# Findings landen nur in der Console
# WAF-SEC-100 Violation: kein On-Call-Alerting

Remediation: aws_cloudwatch_event_rule auf GuardDuty-Source mit Severity-Filter und aws_cloudwatch_event_target auf einen SNS-Topic mit On-Call-Subscription erstellen.

Evidenz

Typ Pflicht Beschreibung

Governance

✅ Pflicht

Incident-Response-Runbook (versioniert) mit mindestens 3 Szenarien und Eskalationsmatrix.

IaC

✅ Pflicht

Terraform-Konfiguration von EventBridge-Regel und SNS-Topic für GuardDuty-Alerting.

Process

✅ Pflicht

Nachweis mindestens eines Incident-Response-Drills pro Jahr (Protokoll oder Ticket).

Process

Optional

Post-Incident-Review-Dokumentation für aufgetretene HIGH/CRITICAL-Incidents.

Regulatorisches Mapping

Regulatorisches Mapping

Framework Controls

ISO 27001:2022

A.5.15 – Threat intelligence; A.5.16 – Threat classification; A.5.24 – Information security incident management; A.5.25 – Assessment and decision on information security events; A.5.26 – Response to information security incidents; A.5.27 – Learning from information security incidents; A.5.28 – Collection of evidence; A.8.16 – Technology use identification and monitoring; A.8.21 – Telecommunications and network security

ISO 27017

CLD.5.1 – Information security in cloud services; CLD.5.2 – Access control in cloud services

ISO 27018

A.2 – Purpose legitimacy and PII protection; A.10 – Confidentiality and security of PII

GDPR

Art. 5(1)(c) – Data minimisation; Art. 5(1)(f) – Integrity and confidentiality; Art. 9 – Special categories of personal data; Art. 25 – Data protection by design and by default; Art. 32 – Security of processing

BSI C5:2020

IDM-01 – Identity and access management policy; IDM-02 – Role management; IDM-03 – User lifecycle management; COM-01 – Network and service security; COM-02 – Cloud monitoring

EUCS (ENISA)

IAM-01 – Identity and access management; IAM-02 – Access rights management; IAM-03 – Privileged access management

NIST SP 800-53

AC-1 – Policy and procedures; AC-2 – Account management; AC-3 – Access enforcement; AC-6 – Least privilege; IA-2 – Identification and authentication; SI-4 – Information system monitoring

FedRAMP

AC-1, AC-2, AC-3, AC-6, IA-2 (Moderate/High baseline)

HIPAA

§ 164.308(a)(4) – Access management; § 164.312(a) – Access control; § 164.312(d) – Information system activity review

PCI DSS v4.0

Req 7 – Restrict access to cardholder data; Req 8 – Identify and authenticate access; Req 8.3 – Non-service accounts

SOC 2 Type II

CC6.1 – Logical access security software; CC6.2 – Logical access security management; CC6.6 – Secure configuration

CSRD

ESRS E1 – Climate change; ESRS G1 – Governance

NIST CSF 2.0

GV.AC – Identity management and access control; DE.CM – Configuration management

CIS Controls v8

CIS 4 – Secure Configuration; CIS 4.4 – Access control; CIS 4.5 – Least privilege

TISAX

Information security – Access rights management

ANSSI SecNumCloud

Domain – Identity and access management; Domain – Security monitoring

BIO

BIO – Identificatie en authenticatie; BIO – Toegangsbeheer

ENS High

org.3 – Políticas de acceso; op.exp.5 – Monitorización de la configuración

UK NCSC CAF

B1 – Access control; B2 – Secure configuration

CMMC 2.0

AC.L2-3.1.1 – Access control policy; AC.L2-3.5.1 – Access enforcement

IRAP

ISM – Identity and access management; ISM – Access control

CCCS PBMM

AC-6 – Least privilege; AC-7 – Unsuccessful logon attempts

MAS TRM

Ch.4 – Identity and access management; Ch.8 – Security monitoring

ISMAP

Access control and identity management

FISC

Operational measures – Access control

Verwandte Controls