Incident Response Playbook: Wie man im Ernstfall richtig reagiert

Wenn es brennt, ist nicht der Moment um einen Löschplan zu schreiben. Ein Incident-Response-Playbook muss existieren, geübt sein und griffbereit sein - bevor der erste Alarm ausgelöst wird. Dieser Guide zeigt wie man ein praxistaugliches Playbook aufbaut, das im Ernstfall tatsächlich hilft.

Was ist ein Incident-Response-Playbook?

Ein IR-Playbook ist mehr als ein IR-Plan. Während der IR-Plan die übergreifende Strategie beschreibt (Wer macht was? Welche Rollen gibt es?), beschreiben Playbooks die konkreten Schritt-für-Schritt-Maßnahmen für spezifische Incident-Typen.

Der IR-Plan definiert das Incident-Response-Team und seine Rollen (IR-Lead, Forensik, Kommunikation, Legal), die Eskalationswege intern und extern, Notfallkontakte und wer wann informiert wird, sowie die rechtlichen Pflichten - NIS2-Meldung und DSGVO-Meldung.

Auf dieser Grundlage bauen die spezifischen Playbooks auf: ein Ransomware-Playbook für verschlüsselte Systeme, ein Datenpanne-Playbook für Datenlecks, ein BEC-Playbook für manipulierte Überweisungen, ein DDoS-Playbook für Überlastungsangriffe und ein Insider-Threat-Playbook für internen Datenmissbrauch.

Grundstruktur: NIST 800-61 IR Lifecycle

NIST SP 800-61 definiert vier Phasen, die jeden Incident umrahmen:

Phase 1: Preparation (dauerhaft)

Die Vorbereitung ist kein einmaliges Projekt, sondern ein permanenter Zustand. Dazu gehören: IR-Plan dokumentieren und im Unternehmen bekannt machen, Playbooks für jeden relevanten Incident-Typ schreiben, Tabletop Exercises durchführen (simulierte Szenarien), das IR-Toolkit zusammenstellen und offline verfügbar halten, externe IR-Unterstützung in einem IR-Retainer vereinbaren, Backup-Tests durchführen, Logging und SIEM sicherstellen und einen Notfallkommunikationskanal einrichten (Signal oder ähnliches, außerhalb des Firmennetzes).

Phase 2: Detection & Analysis

Ein eingehender Alert muss zunächst triagiert werden - echt oder False Positive? Dann: Schweregrad bestimmen (Kritisch/Hoch/Mittel/Niedrig), den IR-Lead benachrichtigen, sofort mit der Incident-Dokumentation beginnen (dieser Schritt wird häufig zu spät gestartet), eine erste Analyse durchführen (was ist betroffen, welcher Angriffstyp?) und eine Timeline aufbauen - wann hat der Angriff begonnen?

Phase 3: Containment, Eradication & Recovery

Containment (sofort): Betroffene Systeme vom Netz isolieren, Angreifer-Zugang sperren (Accounts, VPN, API-Keys) und forensische Kopien sichern - unbedingt vor jeder weiteren Änderung.

Eradication (nach Containment): Malware entfernen, betroffene Systeme bereinigen, Schwachstelle und Einfallstor schließen.

Recovery (sorgfältig): Systeme aus verifizierten Backups wiederherstellen, Monitoring intensivieren (ist der Angreifer noch aktiv?) und schrittweise in die Produktion zurückkehren.

Phase 4: Post-Incident Activity

Ein Lessons-Learned-Meeting sollte zeitnah, maximal zwei Wochen nach dem Incident, stattfinden. Daraus folgen ein Incident-Report, Playbook-Aktualisierungen und - falls NIS2 oder DSGVO-Meldepflicht bestand - der Behörden-Abschlussbericht.

Playbook 1: Ransomware-Angriff

Wichtig: Dieses Playbook ersetzt keinen IR-Experten. Bei schwerem Ransomware-Angriff sofort einen externen IR-Dienstleister anrufen.

Erkennungsmerkmale

Dateien haben unbekannte Erweiterungen (.locked, .encrypted), der Desktop-Hintergrund zeigt eine Lösegeldforderung, Dateiserver sind nicht mehr erreichbar, der Antivirus schlägt Alarm oder das SIEM meldet auffällig viele Dateizugriffe in kurzer Zeit.

Sofortmaßnahmen (Minute 0-30)

Schritt 1: Nicht sofort zahlen - erst untersuchen und den Schaden vollständig verstehen.

Schritt 2: Systemverantwortlichen und IR-Lead informieren.

Schritt 3: Betroffene Systeme sofort vom Netz trennen - Netzwerkkabel ziehen (bei kabelgebundenen Geräten), WLAN deaktivieren. Kein Shutdown - forensische Beweise liegen im Arbeitsspeicher. Ausnahme: bei aktiver Daten-Exfiltration kann sofortige Isolation nötig sein.

Schritt 4: Forensische Sicherung, bevor alles andere geschieht - RAM-Dump (mit Volatility oder Belkasoft RAM Capturer, wenn technisch möglich), kurzer Netzwerk-Traffic-Mitschnitt, Systemlogs sichern bevor sie überschrieben werden.

Schritt 5: Ausbreitung verhindern - alle Domain-Admin-Passwörter von einem sauberen System aus ändern, alle Service-Account-Passwörter zurücksetzen, VPN-Zugänge deaktivieren, Cloud-Sync pausieren (OneDrive, Dropbox).

Analyse (Stunden 1-24)

Schritt 6: Ausmaß bestimmen - welche Systeme sind betroffen, welche Daten wurden verschlüsselt, gibt es Hinweise auf Daten-Exfiltration? Die Ransomware-Familie kann über nomoreransom.org/identify.html identifiziert werden.

Schritt 7: Timeline rekonstruieren - wann begann die Verschlüsselung (Event Log 4663, Dateizugriffe), wie kam der Angreifer rein (E-Mail, RDP, VPN), wie weit hat er sich bewegt (Event Log 4624, 4625, 4648)?

Schritt 8: Backup-Status prüfen - sind die Backups intakt und nicht ebenfalls verschlüsselt? Sind Air-gapped oder Offline-Backups vorhanden? Wie alt ist das letzte gute Backup (RPO)?

Kommunikation

• Intern: Geschäftsführung, IT-Team, Rechtsabteilung
• BSI (wenn KRITIS/NIS2): Meldung innerhalb 24h über meldung.bsi.bund.de
• Datenschutzbehörde (wenn personenbezogene Daten betroffen): Frist 72h nach DSGVO
• Cyber-Versicherung: sofort melden - Fristen beachten
• Presse: kein Kommentar bis zur rechtlichen und forensischen Klärung

Recovery

Schritt 9: Saubere Umgebung aufbauen - wenn Active Directory kompromittiert ist, muss ein neues AD aufgesetzt werden. Kein Restore auf dem bestehenden kompromittierten System.

Schritt 10: Aus Backups wiederherstellen - den verifizierten Backup-Zeitpunkt vor Ransomware-Aktivität nutzen, Restore in isolierter Umgebung testen und die Systemintegrität per Hash-Vergleich prüfen.

Schritt 11: Schrittweise Rückkehr - kritische Systeme (Produktion, ERP) zuerst, mit erhöhtem Monitoring (ist der Angreifer noch aktiv?). Empfohlene Beobachtungszeit: 2-4 Wochen.

Playbook 2: Datenpanne (DSGVO)

Erkennungsmerkmale

Ein Datenbank-Export wurde auf einem externen Server entdeckt, ein Mitarbeiter meldet eine versehentlich gesendete E-Mail mit internen Daten, das Darknet-Monitoring schlägt an, eine Phishing-Seite nutzt interne Kundendaten (Spear-Phishing-Indikator), oder eine fehlerhafte Zugriffsrechte-Konfiguration wird entdeckt.

Sofortmaßnahmen

Schritt 1: Sachverhalt sofort dokumentieren - wann wurde was entdeckt, wer hat es entdeckt, was genau ist betroffen (Datenkategorie, Anzahl betroffener Personen)?

Schritt 2: Informationsfluss stoppen - fehlgeleitete E-Mails mit einem Rückruf-Request adressieren (ohne Garantie, aber immer versuchen), falsch gesetzte Rechte sofort zurücksetzen, kompromittierte Systeme vom Netz trennen.

Schritt 3: Den Datenschutzbeauftragten (DSB) informieren. Der DSB übernimmt die rechtliche Bewertung: liegt eine meldepflichtige Verletzung vor?

Schritt 4: Meldepflicht bewerten.

Meldung an die Aufsichtsbehörde (Art. 33 DSGVO) ist erforderlich, wenn die Verletzung nicht als unwahrscheinlich ohne Risiko für Personen eingestuft werden kann. Im Zweifel: melden. Die Frist beträgt 72 Stunden.

Information der Betroffenen (Art. 34 DSGVO) ist erforderlich, wenn ein hohes Risiko für persönliche Rechte und Freiheiten besteht - beispielsweise bei finanziellen Daten mit Identitätsdiebstahl-Risiko.

Meldung an die Aufsichtsbehörde (72-Stunden-Frist)

Die Meldung nach Art. 33 Abs. 3 muss folgende Inhalte haben:

• Art der Verletzung (wie viele Personen, welche Datenkategorien)
• Name und Kontaktdaten des DSB
• Beschreibung der wahrscheinlichen Folgen
• Ergriffene oder geplante Abhilfemaßnahmen

Die zuständige Behörde richtet sich nach dem Unternehmenssitz: LDI NRW für Nordrhein-Westfalen (ldi.nrw.de), BayLDA für Bayern (lda.bayern.de), BlnBDI für Berlin (datenschutz-berlin.de). Die Meldung kann als Frühwarnung abgegeben und später ergänzt werden.

Kommunikation mit Betroffenen (wenn Art. 34 greift)

Die Kommunikation muss in klarer, verständlicher Sprache erfolgen - kein Juristendeutsch. Sie soll erklären: was ist passiert, welche Daten sind betroffen, was tut das Unternehmen dagegen, was können Betroffene selbst tun, und wer ist Ansprechpartner für Fragen.

Muster-Benachrichtigungstext:

Sehr geehrte/r [Name],

wir müssen Sie darüber informieren, dass am [Datum] eine Verletzung des Schutzes Ihrer personenbezogenen Daten stattgefunden hat. Betroffen sind: [Datenkategorien]. Wir haben folgende Maßnahmen ergriffen: [Maßnahmen]. Bei Fragen wenden Sie sich bitte an: [DSB-Kontakt].

Playbook 3: Business Email Compromise (BEC)

Erkennungsmerkmale

Das Finance-Team erhält eine E-Mail scheinbar vom CEO mit einer dringenden Überweisungsanfrage, ein Lieferant hat angeblich eine neue Bankverbindung mitgeteilt, ein Mitarbeiter hat eine Zahlung veranlasst und meldet nachträglich Zweifel, oder ein DMARC-Report zeigt Spoofing der eigenen Domain.

Sofortmaßnahmen bei laufendem Angriff

Schritt 1: Überweisung stoppen - jede Minute zählt. Die Bank sofort über die Notfallnummer anrufen und einen Überweisungsrückruf ("RECALL" via SWIFT) beantragen. Das Zeitfenster für einen erfolgreichen Recall beträgt oft nur wenige Stunden - bei SEPA-Überweisungen innerhalb Europas sind die Chancen besser als bei SWIFT.

Schritt 2: HR, Finance und IT informieren. Die E-Mail-Kette vollständig sichern - Screenshot und vollständige E-Mail-Header, nicht nur den sichtbaren Inhalt.

Schritt 3: E-Mail-Header analysieren - war der Absender wirklich @firma.de oder ein Lookalike wie @firm4.de? Von welchem Server kam die Mail? Hat die DMARC-Prüfung geschlagen?

Schritt 4: Strafanzeige. Anzeige bei der Polizei über die Internetwache erstatten, bei größeren Beträgen direkt das BKA Cyber-Dezernat kontaktieren.

Investigation

Schritt 5: War echter E-Mail-Account-Zugang im Spiel? Login-History der E-Mail-Konten prüfen, in Azure AD die Sign-in Logs auf unbekannte IP-Adressen untersuchen. Wenn ein Konto kompromittiert ist: sofort Passwort ändern und MFA aktivieren.

Schritt 6: Malware auf dem Rechner des Betroffenen ausschließen - vollständiger EDR-Scan. Bei positivem Befund: Rechner isolieren und forensisch untersuchen.

Prävention nach dem Incident

• DMARC-Policy auf p=reject setzen - verhindert Domain-Spoofing dauerhaft
• Vier-Augen-Prinzip für alle Überweisungen über 5.000 EUR
• Callback-Verifikation: neue Bankverbindungen immer telefonisch bestätigen - unter der bekannten, nicht der in der E-Mail genannten Nummer
• CEO-Fraud-Training für das Finance-Team
• Externe E-Mail-Markierung "[EXTERN]" aktivieren
• Reply-to-Checks: wenn Reply-to von der Absender-Domain abweicht → Warnung

Kommunikationsvorlagen

Template 1: Interne Erstmeldung an Führungskräfte

Betreff: [VERTRAULICH] Sicherheitsvorfall - Erste Einschätzung

Datum/Zeit: [Uhrzeit]
Gemeldet von: [Name, Funktion]
Incident-Typ: [Ransomware / Datenpanne / BEC / ...]

Zusammenfassung:
Um [Uhrzeit] wurde [Beschreibung des Vorfalls] festgestellt.
Betroffen sind: [Systeme/Daten/Personen]
Aktuelle Einschätzung: [Kritisch / Hoch / Mittel]

Sofortmaßnahmen bereits eingeleitet:
- [Maßnahme 1]
- [Maßnahme 2]

Nächste Schritte:
- Situationsupdate um [Uhrzeit]
- Entscheidungsbedarf: [Was brauche ich von GF?]

Kontakt IR-Lead: [Name, Handy]

Template 2: Update-Nachricht (alle 2 Stunden in der Krisenphase)

Betreff: [UPDATE] Sicherheitsvorfall - Status [Uhrzeit]

Ausmaß: [bekannte betroffene Systeme]
Enthaltung/Isolierung: [Ja/Nein/Teilweise]
Systeme wiederhergestellt: [0%/25%/50%/...]

Erkenntnisse seit letztem Update:
- [Neues 1]
- [Neues 2]

Nächster Update: [Uhrzeit]
Entscheidungsbedarf: [Ggf.]

Checkliste: IR-Playbook-Aufbau

Grundlage

• IR-Plan vorhanden (übergreifend)
• Rollen definiert: IR-Lead, Forensik, Kommunikation, Legal
• Kontaktliste: intern und extern - offline verfügbar
• Externer IR-Dienstleister: Kontakt und Konditionen vereinbart (IR-Retainer)

Playbooks erstellen für

• Ransomware / Malware-Infektion
• Datenpanne (DSGVO-Meldepflicht)
• Business Email Compromise
• DDoS-Angriff
• Insider-Bedrohung / Datenmissbrauch durch Mitarbeiter
• Account-Kompromittierung (Social Media, E-Mail, Admin)

Jedes Playbook enthält

• Erkennungsmerkmale
• Sofortmaßnahmen (erste 30 Minuten)
• Analyseschritte
• Kommunikationsvorgaben (intern/extern/Behörden)
• Wiederherstellungsschritte
• Checkliste zum Abhaken

Übungen

• Tabletop Exercise: Playbook anhand eines simulierten Szenarios durchgehen
• Frequenz: mindestens jährlich pro Playbook
• Erkenntnisse: Playbooks nach jeder Übung aktualisieren

NIS2 / ISO 27001

• Playbooks als ISMS-Dokumente versioniert
• Review-Zyklus: jährlich oder nach jedem echten Incident
• BSI- und Aufsichtsbehörden-Meldeprozesse in Playbooks verankert

---

Keinen Incident-Response-Plan? AWARE7 unterstützt bei der Erstellung von IR-Plänen und Playbooks - von der Prozessdefinition bis zur Tabletop-Übung mit Ihrem Team.

IR-Plan anfragen | ISO 27001 Beratung