Incident-Response-Tabletop in zwei Stunden: diese Woche starten

Für eine Tabletop-Übung brauchen Sie einen Raum, ein Szenario, zwei Stunden und jemanden, der festhält, was schiefläuft. Sie benötigen keinen Dienstleister, kein Budget und keinen fertigen Incident-Response-Plan. Es geht darum, herauszufinden, solange nichts brennt, wer tatsächlich entscheidet, einen Server vom Netz zu nehmen, und wo die Telefonnummern liegen.

Wählen Sie ein Szenario und die richtigen Teilnehmenden

Wählen Sie genau ein Szenario. Ransomware auf einem Dateiserver und die Übernahme eines Finanz-Postfachs (Account Takeover) sind für ein kleines Team die beiden nützlichsten, weil beide Entscheidungen zu Isolation, Kommunikation und Wiederherstellung erzwingen. Versuchen Sie nicht, beide in einer Sitzung abzudecken.

Sie müssen das Szenario nicht von Grund auf selbst schreiben. Die Exercise in a Box des NCSC ist kostenlos, enthält Tabletop-Übungen zu Themen wie Ransomware und Phishing und liefert Material, um Übungen aufzusetzen, zu planen, durchzuführen und Maßnahmen nach der Übung abzuleiten. Die Tabletop Exercise Packages der CISA bieten Vorlagen für Ziele, Diskussionsfragen, einen Feedbackbogen und einen After Action Report, unter anderem mit Ransomware- und Kommunalverwaltungs-Szenarien. Nutzen Sie diese als Gerüst und passen Sie die Details an Ihre eigenen Systeme an.

Laden Sie die Personen ein, die im Ernstfall tatsächlich in der Krisenrunde säßen:

• die Person, die Verzeichnisdienst und Backups administriert
• die Person, die Ausfallzeiten freigeben darf (eine Führungskraft, nicht nur die IT)
• jemand, der die externe Kommunikation übernimmt, auch wenn es die Office-Managerin ist
• eine Moderation, die nicht mitspielt und keine Fragen beantwortet

Die Moderation ist wichtig. Wenn dieselbe Person das Szenario leitet und ihr eigenes Setup verteidigt, wird die Übung zur Demo.

Die Agenda für zwei Stunden

Legen Sie zu Beginn eine Regel fest: Antworten müssen dem entsprechen, was Sie mit den heutigen Zugängen und Werkzeugen wirklich tun würden, nicht dem, was die Richtlinie vorsieht. Sagt jemand "wir würden die Logs prüfen", fragt die Moderation nach: Welche Logs, wo, und wer hat montags um 07:40 Uhr Zugriff?

Injects für die Ransomware-Variante

Spielen Sie das Szenario schrittweise ein, nicht auf einmal. Eine praxistaugliche Abfolge:

1. Ein Nutzer meldet, dass Dokumente auf einem Netzlaufwerk eine andere Dateiendung haben und in jedem Ordner eine Textdatei mit einer Lösegeldforderung liegt.
2. Zwei weitere Nutzer melden dasselbe. Der Dateiserver ist langsam.
3. Die Backup-Konsole zeigt, dass der letzte Job abgeschlossen wurde, aber der Backup-Server ist in die Domäne eingebunden.
4. Die Erpressernachricht droht, die Daten in 72 Stunden zu veröffentlichen.
5. E-Mail ist ausgefallen, weil der Mail-Connector auf einem betroffenen Host läuft.

Zu jedem Schritt gehört eine Frage. Wer kann den Host isolieren, und braucht diese Person dafür eine Freigabe? Sind die Backups mit denselben Admin-Zugangsdaten erreichbar, die der Angreifer möglicherweise besitzt? Wo liegt die Kontaktliste, wenn Verzeichnisdienst und E-Mail nicht verfügbar sind? Wer entscheidet, ob Polizei oder Aufsichtsbehörde eingebunden werden, und wer informiert Ihre Versicherung?

Injects für die Account-Takeover-Variante

Beginnen Sie damit, dass ein Mitarbeiter aus der Finanzabteilung wiederholt MFA-Abfragen meldet, die er nicht ausgelöst hat. Fügen Sie dann eine Anmeldung aus einem ungewohnten Land hinzu, danach die Entdeckung einer Postfachregel, die E-Mails an eine externe Adresse weiterleitet, und schließlich eine Rechnung mit geänderten Bankdaten, die an einen Kunden verschickt wurde. Fragen Sie, wie Sie Sitzungen und Tokens widerrufen, und zwar nicht nur das Passwort zurücksetzen. Fragen Sie, wie weit Ihre Anmeldeprotokolle zurückreichen und wer das Postfach auf Regeln und delegierte Zugriffe prüft. Wenn Sie schnell prüfen möchten, ob Zugangsdaten Ihrer Mitarbeitenden bereits in öffentlich bekannten Datenlecks auftauchen, ist unser Prüfdienst für kompromittierte Passwörter ein sinnvoller Schritt vor der Übung.

Lücken festhalten, solange sie frisch sind

Die protokollführende Person führt ein schlichtes Protokoll. Räumen Sie es während der Sitzung nicht auf. Ein Eintrag sieht so aus:

Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high

Jede Lücke braucht eine verantwortliche Person und ein Datum, sonst bleibt sie ein Wunsch. Priorisieren Sie danach, was Sie am Arbeiten gehindert hätte, nicht danach, wie peinlich es war. Typische Befunde sind banal: Niemand kannte die Zugangsdaten beim Registrar, die Bereitschaftsnummer war veraltet, die Person mit der Befugnis, die Produktion herunterzufahren, war im Urlaub und hatte keine Vertretung.

Bitten Sie die Teilnehmenden, vor dem Gehen schriftliches Feedback zu geben. Das CISA-Paket enthält eine Vorlage für einen Feedbackbogen und einen After Action Report, sodass Sie beides nicht selbst entwerfen müssen.

Vom Protokoll zum Runbook

Wandeln Sie das Protokoll innerhalb einer Woche in ein kurzes Runbook um. Ein bis zwei Seiten pro Szenario genügen. Ein Runbook, das im Vorfall niemand liest, ist schlechter als keines.

Es sollte enthalten:

• Die erste Stunde: nummerierte Maßnahmen, jeweils mit einer benannten Rolle statt eines Personennamens.
• Entscheidungsbefugnisse: wer Systeme isolieren darf, wer die Beauftragung externer Hilfe freigeben darf, wer mit Kunden spricht.
• Kontakte: ausgedruckt oder offline gespeichert, für Mitarbeitende, Lieferanten, Ihren ISP, die Versicherung und externe Einsatzkräfte.
• Umgang mit Beweismitteln: was nicht gelöscht oder neu gestartet werden darf, bevor Images und Logs gesichert wurden.
• Reihenfolge der Wiederherstellung: welche Systeme zuerst zurückkehren und woran sich zeigt, dass sie sauber sind.

Für eine umfassendere Struktur wird häufig der Computer Security Incident Handling Guide des NIST herangezogen, SP 800-61 Rev. 2. Das NIST hat ihn jedoch am 3. April 2025 zurückgezogen und durch Rev. 3 ersetzt, nutzen Sie daher die aktuelle Revision als Referenz. Wenn Sie eine externe Sicht auf das Runbook wünschen oder Unterstützung bei der Durchführung der Sitzung brauchen, informieren Sie sich über unsere Leistungen in den Bereichen Incident Response und Beratung.

Planen Sie anschließend die Wiederholung. Führen Sie das andere Szenario in drei bis sechs Monaten durch und testen Sie die Korrekturen aus dem ersten Lückenprotokoll erneut.

So fangen Sie an

1. Reservieren Sie diese Woche zwei Stunden und blocken Sie die Kalender der vier oder fünf Personen, die im Ernstfall in der Runde säßen.
2. Laden Sie ein Ransomware- oder Phishing-Szenario aus Exercise in a Box oder einem CISA-Paket herunter und passen Sie es an Ihre realen Systeme an.
3. Benennen Sie eine Moderation, die nicht mitspielt, und eine protokollführende Person, die das Lückenprotokoll pflegt.
4. Führen Sie die Sitzung mit den echten Werkzeugen im Zugriff durch: Backup-Konsole, Verzeichnisdienst, Anmeldeprotokolle, Kontaktliste.
5. Weisen Sie jeder Lücke eine verantwortliche Person und ein Datum zu, bevor sich der Raum leert.
6. Schreiben Sie das einseitige Runbook innerhalb von sieben Tagen und legen Sie eine Kopie dort ab, wo sie auch dann erreichbar ist, wenn Ihr Netzwerk ausfällt.