Incident-Response-Playbooks
Incident Response Plan und Playbooks für kleine Betriebe: wie Sie Abläufe für typische Sicherheitsvorfälle vorbereiten, gliedern und aktuell halten.
Ein Incident Response Plan legt fest, wie Ihr Betrieb auf Sicherheitsvorfälle reagiert: wer entscheidet, wer informiert wird, welche Schritte folgen. Playbooks ergänzen ihn um kurze Ablaufpläne für typische Fälle, etwa «Postfach gehackt» oder «Laptop verloren».
Warum Playbooks helfen
Im Ernstfall stehen Menschen unter Druck. Ein Playbook nimmt Entscheidungen vorweg, die man in Ruhe besser treffen kann: Darf ein Mitarbeiter den Rechner vom Netz nehmen? Wer sperrt ein Konto? Wann wird die Versicherung angerufen? Wer das vorher geklärt hat, verliert keine Zeit.
Klein anfangen
Sie brauchen keine Bibliothek mit fünfzig Szenarien. Für einen kleinen Betrieb reichen meist vier bis sechs Playbooks für die Fälle, die am wahrscheinlichsten sind:
- Klick auf einen Phishing-Link oder Eingabe des Passworts auf einer falschen Seite
- gehacktes E-Mail-Postfach
- Ransomware, also verschlüsselte Daten
- verlorenes oder gestohlenes Gerät
- gefälschte Zahlungsanweisung, etwa angeblich vom Chef
Eine Seite pro Fall
Ein gutes Playbook passt auf ein bis zwei Seiten, ist in klarer Sprache geschrieben und liegt auch ausgedruckt vor.
Der nächste Schritt
Schreiben Sie mit Ihrem IT-Dienstleister zuerst das Playbook für ein gehacktes E-Mail-Postfach. Das ist einer der häufigsten Fälle und lässt sich in einer Stunde erstellen. Danach üben Sie es einmal am Tisch.
Plan und Playbook: die Abgrenzung
Der Incident Response Plan ist das Rahmendokument. Er beschreibt, was als Sicherheitsvorfall gilt, wie Vorfälle gemeldet und eingestuft werden, wer zuständig ist, wann eskaliert wird und wie der Übergang ins Notfallmanagement erfolgt. Playbooks sind szenariobezogene Ablaufpläne, die auf diesem Rahmen aufbauen. Der Notfallplan des Betriebs deckt zusätzlich Ereignisse ab, die keine Sicherheitsvorfälle sind, etwa Brand oder Stromausfall.
Grundlage im IT-Grundschutz
Der Baustein DER.2.1 Behandlung von Sicherheitsvorfällen (Edition 2023) enthält die Anforderungen, aus denen sich ein Incident Response Plan zusammensetzt:
- Basis-Anforderungen: Definition eines Sicherheitsvorfalls (A1), Richtlinie zur Behandlung von Sicherheitsvorfällen (A2), Verantwortlichkeiten und Ansprechpersonen (A3), Benachrichtigung betroffener Stellen (A4), Behebung (A5) und Wiederherstellung der Betriebsumgebung (A6).
- Standard-Anforderungen unter anderem: eine definierte Vorgehensweise (A7), Organisationsstrukturen (A8), Meldewege (A9), Eindämmen der Auswirkungen (A10), Einstufung (A11), Eskalationsstrategie (A14), Dokumentation (A16) und Nachbereitung (A17).
Ein Satz Playbooks ist eine praktische Form, die Vorgehensweise, die Eindämmung und die Eskalation für typische Fälle umzusetzen.
Aufbau eines Incident Response Plan
Geltungsbereich und Definition
Was ist ein Sicherheitsvorfall, was eine normale Störung? Beispiele helfen Mitarbeitenden bei der Einordnung.
Meldeweg
Ein einziger, allen bekannter Meldeweg: eine Telefonnummer, eine Person, eine Vertretung. Mitarbeitende sollen ohne Angst vor Vorwürfen melden können, auch einen Fehlklick.
Einstufung und Eskalation
Eine einfache Einstufung genügt, zum Beispiel drei Stufen: geringe Auswirkung (IT kümmert sich), erhebliche Auswirkung (Geschäftsführung und Datenschutz informieren), Notfall (Notfallstab, Notfallplan aktivieren). Für jede Stufe ist festgelegt, wer informiert wird und wer entscheidet.
Rollen
Koordination, Technik, Kommunikation, Datenschutz und Entscheidung. In kleinen Betrieben übernimmt eine Person mehrere Rollen, wichtig sind benannte Vertretungen.
Externe Kontakte
IT-Dienstleister, Cyber-Versicherung mit Hotline, Datenschutzbeauftragte, Rechtsberatung, Polizei (Zentrale Ansprechstellen Cybercrime), gegebenenfalls Forensik-Dienstleister.
Aufbau eines Playbooks
Bewährt hat sich eine feste Gliederung:
- Auslöser: Woran erkennt man den Fall?
- Sofortmaßnahmen: die ersten drei bis fünf Schritte, die jede Person ausführen darf.
- Einstufung: Wann wird aus dem Fall ein Notfall?
- Technische Schritte: eindämmen, Spuren sichern, bereinigen, wiederherstellen.
- Entscheidungen: wer was entscheidet, zum Beispiel Abschalten des Internetzugangs oder Information der Kunden.
- Meldungen: Datenschutz-Aufsicht, BSI, Versicherung, Auftraggeber, jeweils mit Frist.
- Kommunikation: wer intern und extern informiert, mit Textbausteinen.
- Abschluss: Kriterien für das Ende, Dokumentation, Nachbereitung.
Beispiel: Playbook «E-Mail-Postfach kompromittiert»
Auslöser: Kunden melden seltsame Mails von Ihrer Adresse, unbekannte Weiterleitungsregeln, Anmeldungen aus fremden Ländern.
Sofort: Passwort des Kontos ändern, alle aktiven Sitzungen beenden, Zwei-Faktor-Authentifizierung prüfen oder aktivieren, IT-Verantwortliche informieren.
Technik: Weiterleitungs- und Posteingangsregeln prüfen und entfernen, Anmeldeprotokolle sichern, prüfen, ob von dem Konto aus Mails versandt wurden, verbundene Anwendungen und App-Kennwörter kontrollieren, betroffenes Gerät auf Schadsoftware untersuchen.
Bewertung: Welche Daten lagen im Postfach? Wurden personenbezogene Daten eingesehen? Dann Meldepflicht nach Art. 33 DSGVO prüfen.
Kommunikation: Empfänger der gefälschten Mails warnen, besonders bei Zahlungsaufforderungen.
Abschluss: Ursache dokumentieren, etwa Phishing, und Schulung oder technische Maßnahmen ableiten.
Beispiel: Playbook «Gefälschte Zahlungsanweisung»
Auslöser: Eine E-Mail, angeblich von der Geschäftsführung oder einem Lieferanten, fordert eine dringende Überweisung oder meldet eine geänderte Bankverbindung.
Sofort: Nicht zahlen. Über einen bekannten, unabhängigen Weg rückfragen, etwa per Telefon an die bekannte Nummer, nicht an die in der E-Mail. Ist bereits gezahlt, sofort die eigene Bank anrufen und einen Rückruf der Zahlung versuchen.
Technik: E-Mail mit Kopfzeilen sichern, prüfen, ob ein eigenes Postfach kompromittiert ist, Absenderadresse und ähnliche Domains notieren.
Meldungen: Strafanzeige erstatten, Versicherung informieren, betroffenen Geschäftspartner warnen.
Abschluss: Freigaberegeln für Zahlungen und Kontoänderungen festlegen, etwa Vier-Augen-Prinzip und Rückruf bei jeder Änderung der Bankverbindung.
Beispiel: Playbook «Gerät verloren oder gestohlen»
Sofort: Verlust melden, Konten des Geräts sperren oder Passwörter ändern, Gerät über die Geräteverwaltung sperren oder löschen lassen, sofern eingerichtet.
Bewertung: War das Gerät verschlüsselt? Welche Daten lagen darauf oder waren über angemeldete Konten erreichbar? Bei unverschlüsselten personenbezogenen Daten Meldepflicht prüfen.
Abschluss: Diebstahl bei der Polizei anzeigen, Ersatzgerät sauber einrichten, Inventar aktualisieren.
Playbooks aktuell halten
- Nach jedem echten Vorfall und jeder Übung prüfen, ob das Playbook gestimmt hat.
- Kontakte und Zuständigkeiten bei personellen Änderungen sofort anpassen.
- Mindestens einmal im Jahr in einer Planbesprechung durchgehen.
- Eine ausgedruckte Fassung bereithalten, denn bei vielen Vorfällen sind genau die Systeme betroffen, auf denen die Playbooks gespeichert sind.
Mit dem IT-Dienstleister abstimmen
In kleinen Betrieben führt oft ein externer Dienstleister die technischen Schritte aus. Klären Sie deshalb gemeinsam, welche Playbook-Schritte er übernimmt, wie er außerhalb der Geschäftszeiten erreichbar ist, welche Reaktionszeit vereinbart ist und wer im Betrieb Entscheidungen trifft, die er nicht treffen darf, etwa das Abschalten zentraler Systeme oder die Information von Kunden. Halten Sie das schriftlich fest, idealerweise im Dienstleistungsvertrag.
Häufige Fragen
Was ist der Unterschied zwischen Incident Response Plan und Notfallplan?
Der Incident Response Plan regelt den Umgang mit Sicherheitsvorfällen, von der Meldung bis zur Nachbereitung. Der Notfallplan deckt alle Ereignisse ab, die wichtige Abläufe unterbrechen, auch Brand oder Stromausfall. Wird ein Sicherheitsvorfall zum Notfall, greift der Notfallplan.
Was gehört in ein Incident-Response-Playbook?
Auslöser, Sofortmaßnahmen, Einstufung, technische Schritte, Entscheidungen mit Zuständigkeiten, Meldepflichten, Kommunikation und Abschlusskriterien. Es sollte auf ein bis zwei Seiten passen.
Wie viele Playbooks braucht ein kleiner Betrieb?
Meist reichen vier bis sechs für die häufigsten Fälle, etwa Phishing, kompromittiertes Postfach, Ransomware, Geräteverlust und Zahlungsbetrug. Wichtiger als die Anzahl ist, dass sie geübt werden.