Incident Response · Referenz-Checkliste
Eine phasenbasierte Orientierung für den Krisenstab und die Incident Response: Welche Entscheidungen sind in welcher Phase zu treffen, welche Maßnahmen sind umzusetzen und wer ist dafür verantwortlich? Dieses Gerüst gilt für jeden schweren Sicherheitsvorfall. Stellen, die nur bei Ransomware/Erpressung greifen, sind entsprechend markiert.
Geltungsprüfung zuerst: § 32 BSIG betrifft insbesondere „besonders wichtige und wichtige Einrichtungen” bei erheblichen Sicherheitsvorfällen (§ 2 Nr. 11 BSIG). Es ist zu prüfen, ob § 32 einschlägig ist und ob sektorspezifische, behördliche oder vertragliche Anforderungen hinzutreten. Die Fristen des BSIG laufen ab dem Zeitpunkt, zu dem Kenntnis von einem erheblichen Sicherheitsvorfall erlangt wird. Die DSGVO und Verträge haben eigene Auslöser.
Keine gemeinsame Universaluhr: Nach dem BSIG muss unverzüglich nach Kenntnis eines erheblichen Sicherheitsvorfalls gehandelt werden, nach der DSGVO unverzüglich nach Bekanntwerden einer Verletzung personenbezogener Daten. In Versicherungs- und Kundenangelegenheiten richtet sich die unverzügliche Handlung nach dem jeweiligen Vertrag. „Unverzüglich” bedeutet nicht erst am Ende des Höchstzeitraums. Bei offenen Fakten sollte man sich frühzeitig mit gekennzeichneten Unsicherheiten melden und die Informationen stufenweise ergänzen. Gemäß § 32 Abs. 1 BSIG gelten die Pflichten frühestens ab Einrichtung des gesetzlichen Meldewegs.
Operative Phasenstruktur angelehnt an das klassische Modell aus NIST SP 800-61 Rev. 2 und ISO/IEC 27035. NIST Rev. 3 (2025) ordnet Incident Response in CSF 2.0 ein; Phasen überlappen, Eindämmung und Beweissicherung können parallel erfolgen.
Entscheidungsprinzip: Bei aktiver Verschlüsselung oder Exfiltration wirksame Eindämmung unverzüglich priorisieren, forensische Sicherung soweit möglich parallel. Nicht auf einen vollständigen Forensikbericht warten. Jede Entscheidung mit Zeitstempel, Begründung, zuständiger Person und nächstem Review außerhalb dieser lokalen Checkliste protokollieren.
Diese Fragen ziehen sich durch alle Phasen und werden typischerweise auf Krisenstabs-Ebene entschieden.
Illustratives Organisationsmodell, kein gesetzliches Zuständigkeitsverzeichnis. Pro Aufgabe genau eine interne A-Rolle; vor Nutzung Namen, Delegationen, Behördenwege und datenschutzrechtliche Rollen verbindlich festlegen.
| Aufgabe | CISO | Vorstand/GF | CIO | PR | Legal | DSB | SOC | IT-Betrieb | Ext. Forensik | Fachbereiche |
|---|---|---|---|---|---|---|---|---|---|---|
| IR-Playbook erstellen / üben | A | C | C | C | C | C | R | R | C | C |
| Erst-Triage / Scoping | C | I | C | I | I | C | A | R | R | I |
| Gezielte technische Isolierung* | A | I | C | I | C | I | R | R | C | I |
| Betriebsweite Netztrennung* | R | A | R | I | C | I | R | R | C | C |
| Datenschutzrisiko / Meldung† | R | A | C | C | R | C | R | C | C | C |
| Sonstige gesetzliche Meldungen† | R | A | C | C | R | C | C | R | C | C |
| Eradication / AD-Recovery | C | I | A | I | C | I | R | R | R | C |
| Technische Recovery | C | I | A | I | I | I | R | R | C | R |
| Externe Krisenkommunikation | C | A | C | R | C | C | I | I | I | C |
| Lösegeldentscheidung | C | A | C | I | R | C | C | I | C | I |
| Post-Incident Review | A | C | C | C | C | C | R | R | R | R |
R = Responsible (Durchführung) · A = Accountable (Entscheidung/Gesamtverantwortung) · C = Consulted · I = Informed
* Beispielhafte Befugnisse: gezielte Isolation an CISO/SOC delegiert; betriebsweite Trennung Geschäftsleitung. Bei akutem Schaden ist die vorab freigegebene Notfallkompetenz maßgeblich.
† DSGVO: Rechtlich verantwortlich ist der Verantwortliche, nicht der unabhängige DSB; die interne A-Zuordnung zur Leitung ist lediglich ein Organisationsbeispiel. Bei Auftragsverarbeitung Zuständigkeiten nach Art. 28/33 DSGVO prüfen. § 38 BSIG betrifft ausdrücklich Umsetzung/Überwachung der Risikomanagementmaßnahmen nach § 30 und Schulung der Geschäftsleitung; Meldepflichten für Einrichtungen regelt § 32 BSIG. Behörden sind externe Meldungsadressaten, nicht Teil des internen RACI.
Die Fallstricke, an denen Krisen in der Praxis am häufigsten scheitern.
Kommunikation über kompromittierte Systeme
Mail/Teams/VoIP werden weitergenutzt, obwohl der Angreifer mitliest. → Bei Verdacht unverzüglich auf vorbereitete vertrauenswürdige OOB-Kanäle wechseln.
Hektisches Herunterfahren
Ausschalten vernichtet flüchtige Spuren im RAM und erschwert die Bestimmung des Eintrittsvektors. → Wirksam isolieren, parallel Beweise sichern; wenn Isolation unmöglich, Abschaltung gegen Schaden abwägen.
Wiederherstellung vor Ursachenbehebung
Restore in eine noch kompromittierte Umgebung führt zur erneuten Verschlüsselung. → Kontrollierte Recovery-Zonen; Identitäten und Managementebenen vor Anbindung verifizieren.
Zu späte Isolierung
Während man beobachtet, breitet sich die Ransomware weiter aus. → In der Frühphase zählt jede Minute Eindämmungszeit.
Meldefristen verpasst
Legal wartet auf den finalen Forensikbericht. → Anwendbarkeit und getrennte Fristbeginne prüfen; frühzeitig mit gekennzeichneten Unsicherheiten melden.
Unkoordinierte PR
Man spricht von „technischer Störung“, während Daten bereits im Darknet stehen. → Aussagen zwischen PR, Legal und CISO abstimmen; Transparenz wahren.
Lückenhafte Dokumentation
Fehlender Audit-Trail erschwert Versicherungs- und Strafverfahren. → Zeitstempel und Entscheidungen durchgängig protokollieren.
Nachbereitung übersprungen
Ohne Lessons Learned bleibt die Infrastruktur verwundbar. → Review fest einplanen, Maßnahmen mit Fristen nachhalten.