Der Incident-Response-Lebenszyklus auf AWS

Ein Sicherheitsvorfall ist jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit Ihrer AWS-Ressourcen oder -Daten beeinträchtigen kann. Dabei kann es sich um einen offengelegten Zugriffsschlüssel, eine mit Schadsoftware infizierte Instanz oder einen öffentlich zugänglichen S3-Bucket handeln.

Incident Response (IR) ist der strukturierte Prozess zur Vorbereitung auf solche Ereignisse, zu ihrer Erkennung und zu ihrer Bewältigung. AWS bietet Ihnen dabei eine Geschwindigkeit und Automatisierung, von der On-Premises-Teams nur träumen können.

AWS unterteilt die Incident Response in drei übergeordnete Phasen, die jeweils auf der vorherigen aufbauen:

• Vorbereitung — Richten Sie Personen, Prozesse und Tools ein, bevor etwas geschieht.
• Betrieb — Erkennen, analysieren, begrenzen, beseitigen und beheben Sie einen aktiven Vorfall.
• Nach dem Vorfall — Lernen Sie aus dem Geschehenen und verbessern Sie Ihre Abläufe.

Diese Phasen entsprechen weitgehend dem klassischen NIST-Lebenszyklus, den Sie für die Prüfung kennen müssen.

Die Vorbereitung ist die wichtigste Phase, da sie die einzige ist, die Sie steuern können, bevor der Druck steigt. Dazu gehören das Erstellen von Runbooks, das frühzeitige Zuweisen der richtigen IAM-Rollen an die Einsatzkräfte, das Aktivieren der Protokollierung überall sowie Übungen in Form von Game Days.

Ein vorbereitetes Team kann einen Vorfall innerhalb weniger Minuten eindämmen. Ein Team, das improvisiert, verliert wertvolle Zeit damit zu klären, wer überhaupt handeln darf.

Erkennung wandelt Rohsignale in einen bestätigten Vorfall um. Dienste wie Amazon GuardDuty, AWS Security Hub und CloudTrail machen verdächtige Aktivitäten sichtbar.

Die Analyse beantwortet anschließend die entscheidenden Fragen: Welche Ressource ist betroffen, wie ist der Angreifer eingedrungen und wie groß ist der Schadensumfang? Amazon Detective unterstützt Sie dabei, von einem einzelnen Finding zur vollständigen Geschichte zu wechseln.

Die Eindämmung stoppt die weitere Ausbreitung, ohne Beweise zu zerstören. Sie können beispielsweise eine EC2-Instanz (Elastic Compute Cloud) mit einer restriktiven Sicherheitsgruppe isolieren, die Sitzung einer kompromittierten Rolle widerrufen oder einen Zugriffsschlüssel deaktivieren.

Ziel ist es, den Schaden zu begrenzen und gleichzeitig den für die forensische Analyse erforderlichen Zustand zu bewahren. Zu aggressives Vorgehen kann genau die Hinweise löschen, auf die eine Untersuchung angewiesen ist.

Die Beseitigung entfernt den Angreifer und die Ursache – etwa durch das Schließen der Sicherheitslücke, das Löschen von Backdoors oder das Austauschen aller offengelegten Secrets.

Die Wiederherstellung stellt den normalen Betrieb wieder her: durch das Neuerstellen sauberer Instanzen aus vertrauenswürdigen Images, das Wiederherstellen von Daten aus Backups und die Bestätigung, dass die Bedrohung tatsächlich beseitigt ist, bevor Systeme wieder mit der Produktion verbunden werden.

Wenn sich die Lage beruhigt hat, führen Sie eine blameless Retrospektive durch. Dokumentieren Sie den zeitlichen Ablauf, was funktioniert hat, was fehlgeschlagen ist und welche konkreten Verbesserungen sich daraus ergeben.

Aktualisieren Sie Runbooks, ergänzen Sie Erkennungsmechanismen, die den Vorfall früher entdeckt hätten, und automatisieren Sie manuelle Schritte. Jeder Incident bietet die Möglichkeit, die nächste Reaktion schneller und ruhiger zu machen.

Die Cloud verändert die Incident Response grundlegend. Über APIs können Sie innerhalb von Sekunden mit einem einzigen Aufruf einen Datenträger als Snapshot sichern, eine Security Group ändern oder eine Rolle unter Quarantäne stellen. Infrastructure as Code ermöglicht es, bei Bedarf saubere Umgebungen neu aufzubauen.

Dadurch können Sie Neubereitstellung statt Reparatur bevorzugen – das Ersetzen einer kompromittierten Instanz durch eine frische Instanz ist oft schneller und sicherer als ihre Bereinigung.

Klare Zuständigkeiten verhindern Chaos. Legen Sie fest, wer einen Incident ausruft, wer mit Stakeholdern kommuniziert und wer direkt am System arbeitet.

Erstellen Sie die IAM-Rollen, die von den Einsatzkräften übernommen werden, im Voraus, damit der Zugriff bereitsteht und protokolliert wird. Das Modell der geteilten Verantwortung gilt weiterhin: AWS sichert die Cloud, aber die Reaktion auf Ereignisse in Ihren Accounts ist Ihre Aufgabe.

Ihr erster echter Incident sollte nicht gleichzeitig Ihr allererster Incident sein. Game Days sind simulierte Ereignisse, bei denen das Team das Runbook vollständig durchspielt.

Dabei werden Lücken sichtbar – etwa fehlende Berechtigungen, veraltete Kontaktlisten oder nicht getestete Automatisierungen –, während die Konsequenzen noch gering sind. Regelmäßiges Üben macht aus einem schriftlichen Plan eine eingeübte Routine.

Ordnen Sie Services den einzelnen Phasen zu, damit Sie wissen, wonach Sie greifen müssen:

• Erkennen: GuardDuty, Security Hub, CloudWatch-Alarme.
• Analysieren: Detective, CloudTrail, Athena.
• Eindämmen: Security Groups, IAM, AWS Systems Manager.
• Wiederherstellen: Backups, AMIs (Amazon Machine Images), CloudFormation.

Testen Sie Ihr Verständnis des Lebenszyklus.

Die Incident Response auf AWS umfasst die Phasen Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung, Wiederherstellung und Nachbereitung. Die Vorbereitung ist die Phase, die Sie vollständig kontrollieren können, und Game Days halten sie auf einem hohen Stand. Die Cloud ermöglicht es, über APIs innerhalb von Sekunden einzudämmen und neu aufzubauen, wobei die Neubereitstellung gegenüber der Reparatur bevorzugt wird. Gehen Sie bei der Eindämmung sorgfältig vor, damit Beweise erhalten bleiben, beseitigen Sie anschließend die Ursache und stellen Sie den Betrieb aus vertrauenswürdigen Quellen wieder her.