Ein Incident-Response-Plan ist das Dokument, das im Vorfall die Fragen beantwortet, für die dann keine Zeit mehr ist: Wer entscheidet, wer wird wann informiert, welche Nummer hat der IR-Dienstleister, darf der Fileserver nachts vom Netz? Die meisten Organisationen haben so einen Plan entweder nicht, oder sie haben einen, der 60 Seiten lang ist, auf dem SharePoint liegt und den außer dem Autor niemand gelesen hat. Dieser Beitrag beschreibt, was in einen brauchbaren Plan gehört, wie eine Zwei-Seiten-Version für kleine Organisationen aussieht, wie du den Plan testest und woran Pläne in der Praxis scheitern. Die Struktur lässt sich direkt als Vorlage übernehmen.
Was ein Incident-Response-Plan ist und was nicht
Der Plan ist das steuernde Dokument für den Umgang mit Sicherheitsvorfällen: Rollen, Befugnisse, Meldewege, Phasen, Kommunikation. Er ist nicht das Playbook, das für einen bestimmten Vorfalltyp wie Ransomware oder Phishing die technischen Schritte beschreibt; Playbooks hängen am Plan an. Er ist auch nicht der Notfall- oder Business-Continuity-Plan, der regelt, wie das Geschäft ohne IT weiterläuft; beide greifen ineinander, aber der IR-Plan endet, wo die Wiederherstellung beginnt. Die Hierarchie, die sich bewährt hat: eine Richtlinie, die festlegt, dass es Incident Response gibt und wer verantwortlich ist; der Plan, der beschreibt, wie sie abläuft; Playbooks pro Vorfalltyp; und darunter technische Anleitungen für einzelne Handgriffe. Der Incident-Response-Prozess mit seinen Phasen ist das Gerüst, der Plan füllt es mit den Namen, Nummern und Regeln deiner Organisation.
Die Bausteine: Vorlage in zwölf Abschnitten
- Zweck und Geltungsbereich. Wofür der Plan gilt, für welche Systeme, Standorte und Tochtergesellschaften, und wer ihn freigegeben hat. Eine halbe Seite.
- Definitionen und Klassifikation. Was ein Ereignis ist, was ein Vorfall, und die Schweregrade mit Beispielen und Reaktionszeiten. Diese Tabelle wird im Vorfall am häufigsten aufgeschlagen.
- Rollen und Kontaktliste. Incident Lead mit Stellvertretung, technische Analyse, IT-Betrieb, Kommunikation, Recht, Datenschutz, Geschäftsführung. Extern: IR-Dienstleister, Forensik, Cyberversicherung, Anwalt, Behörden. Mit Mobilnummern und Erreichbarkeit außerhalb der Bürozeiten.
- Interne Meldewege. Wie ein Mitarbeiter einen Verdacht meldet (Telefonnummer, Adresse, Ticket), wer die Meldung entgegennimmt, wie sie zum SOC oder zum Incident Lead eskaliert wird, mit Zeitvorgaben pro Schweregrad.
- Phasen und Verantwortliche. Vorbereitung, Erkennung, Eindämmung, Beseitigung, Wiederherstellung, Nachbereitung, und für jede Phase, wer führt und was das Ergebnis ist.
- Kommunikationsplan. Welcher Kanal im Vorfall verwendet wird, wenn E-Mail und Chat kompromittiert sein könnten, wer intern und extern spricht, welche Sprachregelung für Kunden und Presse gilt und wer sie freigibt.
- Meldepflichten. Welchen Regelwerken die Organisation unterliegt, wer meldet, an wen, in welcher Frist, mit Zugangsdaten und Vorlagen. Die Details stehen im Beitrag zu den Meldepflichten bei Cyberangriffen.
- Beweissicherung und Dokumentation. Was gesichert wird, bevor etwas verändert wird, wie das Vorfallprotokoll geführt wird (wer, wann, was, Entscheidung, Begründung) und wie Beweismittel übergeben werden.
- Entscheidungsbefugnisse. Wer darf ein Produktivsystem abschalten, wer die Internetverbindung kappen, wer Kunden informieren, wer über Lösegeld entscheiden. Ohne diesen Abschnitt verliert das Team die ersten Stunden mit Telefonaten.
- Playbooks. Als Anhang, je eins für die Vorfalltypen, die wahrscheinlich sind: Ransomware, Phishing mit kompromittiertem Konto, Datenabfluss, Schadsoftware auf einem Client, DDoS, verlorenes Gerät.
- Nachbereitung. Wann die Lessons-Learned-Sitzung stattfindet, wer teilnimmt, wie Maßnahmen nachverfolgt werden.
- Pflege und Übung. Wer den Plan besitzt, wie oft er geprüft wird, wann geübt wird, wo er abgelegt ist.
Die Klassifikation: ein Beispiel
Die Schweregrade entscheiden, ob ein Vorfall im Tagesgeschäft bleibt oder den vollen Plan auslöst. Vier Stufen reichen; mehr werden im Ernstfall nicht unterschieden.
| Stufe | Beispiele | Reaktion | Wer wird informiert |
|---|---|---|---|
| 4, gering | Blockierte Phishing-Mail, einzelner Fehlalarm, Schadsoftware vom Virenscanner entfernt | SOC im Tagesgeschäft, Ticket | Niemand außerhalb des SOC |
| 3, mittel | Kompromittiertes Benutzerkonto ohne Hinweis auf Ausbreitung, Schadsoftware ausgeführt auf einem Client | Analyse und Eindämmung innerhalb von 4 Stunden | Leitung IT-Sicherheit |
| 2, hoch | Kompromittiertes privilegiertes Konto, Angreifer auf mehreren Systemen, Datenabfluss vermutet | Incident Lead übernimmt, Plan aktiv, Reaktion innerhalb 1 Stunde, rund um die Uhr | Geschäftsführung, Datenschutz, Recht |
| 1, kritisch | Ransomware-Verschlüsselung, Domain-Admin kompromittiert, Produktion oder Kundendienste stehen | Krisenstab, externe Unterstützung, Meldefristen laufen | Geschäftsführung sofort, Versicherung, Behörden nach Pflicht |
Die Zwei-Seiten-Version
Eine Organisation mit 50 Mitarbeitern und einem externen IT-Dienstleister braucht keine zwölf Abschnitte. Sie braucht zwei Seiten, die jeder Verantwortliche ausgedruckt zu Hause hat: Seite eins ist die Kontaktliste mit sechs Namen, den Nummern des IT-Dienstleisters, des Versicherers und des Anwalts, und dem Satz, wer im Vorfall entscheidet. Seite zwei ist die Reihenfolge der ersten Stunden: Verdacht bestätigen, betroffene Systeme vom Netz statt aus, Backups schützen, nichts neu aufsetzen, Kommunikation per Telefon, Protokoll führen, Meldefristen prüfen, Dienstleister rufen. Dazu die Info, wo die Backups liegen und wer den Zugang hat. Das ist kein vollständiger Plan, aber er verhindert die drei häufigsten Fehler der ersten Stunde, und das ist mehr, als die meisten 60-Seiten-Dokumente im Ernstfall leisten.
Die Kontaktliste ist der wichtigste Teil
Wenn vom ganzen Plan nur eine Seite überlebt, muss es die Kontaktliste sein. Sie enthält für jede Rolle eine Person und eine Vertretung, private Mobilnummern, weil die Firmentelefonie im Vorfall ausfallen kann, und die externen Nummern samt Vertragsnummern: Wer beim Versicherer anruft, braucht die Policennummer, wer beim IR-Dienstleister anruft, den Rahmenvertrag. Die Liste wird quartalsweise geprüft, weil Menschen die Firma verlassen und Nummern wechseln, und sie liegt an mindestens einem Ort, der den Vorfall übersteht: ausgedruckt, auf einem Gerät außerhalb der Domäne, in einem Passwortmanager mit Offline-Zugriff. Ein Plan im SharePoint, der gerade verschlüsselt wurde, ist kein Plan.
Den Plan testen: die Tabletop-Übung
Ein Plan, der nie durchgespielt wurde, hat Lücken, die niemand kennt. Die Tabletop-Übung ist das Werkzeug dafür: alle Rollen an einem Tisch, ein Moderator, ein Szenario, zwei bis drei Stunden. Der Moderator erzählt den Vorfall in Etappen und wirft Wendungen ein: Um 9 Uhr meldet ein Mitarbeiter eine verschlüsselte Datei. Was tut ihr? Um 9:40 stellt sich heraus, dass der Fileserver betroffen ist und die Backups seit Dienstag fehlschlagen. Um 11 Uhr ruft ein Journalist an. Jede Etappe endet mit der Frage, wer jetzt was entscheidet und woher er die Information nimmt. Ein Beobachter protokolliert, wo der Plan die Antwort geliefert hat und wo diskutiert wurde. Die Liste der Diskussionen ist die Liste der Änderungen am Plan.
Einmal im Jahr mit der ganzen Runde inklusive Geschäftsführung ist das Minimum; alle sechs Monate mit dem technischen Kern ist besser. Technische Übungen, bei denen das SOC eine simulierte Technik tatsächlich erkennen und eindämmen muss, ergänzen die Tabletop-Übung, ersetzen sie aber nicht: Die meisten Pläne scheitern nicht an der Technik, sondern an der Frage, wer anruft.
Woran Pläne scheitern
- Zu lang. Was im Vorfall nicht in fünf Minuten gefunden wird, existiert nicht. Der Plan ist kurz, die Playbooks tragen die Details.
- Unbekannt. Der Plan wurde für ein Audit geschrieben und danach abgelegt. Jede Person mit einer Rolle hat ihn gelesen und einmal geübt, sonst gilt sie als nicht besetzt.
- Keine Vertretung. Der Incident Lead ist im Urlaub, und der Plan kennt niemanden sonst. Jede Rolle hat zwei Namen.
- Keine Befugnisse. Der Plan beschreibt, was zu tun ist, aber nicht, wer es darf. Im Vorfall entscheidet dann niemand, bis die Geschäftsführung erreichbar ist.
- Nur digital. Auf dem System, das gerade nicht mehr erreichbar ist.
- Nach dem Vorfall unverändert. Jeder echte Vorfall und jede Übung ist die beste Quelle für die nächste Version. Wer den Plan danach nicht anfasst, hat aus dem Vorfall nichts gelernt.
Zwei Referenzen, an denen sich der Aufbau messen lässt: NIST SP 800-61 Revision 3 beschreibt, wie Incident Response in Governance und Risikomanagement verankert wird, also den Rahmen, in dem der Plan steht. Die Checklisten des BSI für Unternehmen sind das, was die Zwei-Seiten-Version leisten soll, und ein guter Abgleich für die eigene Kurzfassung.
Fazit
Ein Incident-Response-Plan wird nicht daran gemessen, wie vollständig er ist, sondern daran, ob er um zwei Uhr nachts die richtige Nummer und die richtige Entscheidung liefert. Kurz, mit Namen und Befugnissen, an einem Ort, der den Vorfall übersteht, und mindestens einmal im Jahr am Tisch durchgespielt. Alles andere ist Anhang. Wer diese Version hat, gibt seinem Blue Team im Ernstfall das, was es am dringendsten braucht: Zeit für die Technik statt für die Organisation.