Tabletop Exercise (Krisenübung)

Tabletop Exercise (TTX) ist die kostengünstigste Form der Krisenprävention: Man sitzt zusammen, der Moderator schildert ein Angriffsszenario, und alle Beteiligten diskutieren was sie jetzt tun würden - anhand ihrer tatsächlichen Rollen und Prozesse. Was dabei herauskommt, überrascht regelmäßig: Fast jedes Unternehmen entdeckt kritische Lücken.

Warum Tabletop Exercises unverzichtbar sind

Das Problem mit Incident-Response-Plänen:

• Werden einmal erstellt - und dann nie wieder geöffnet
• Stehen im Wiki, aber niemand kennt sie
• Beschreiben Prozesse, die in der Realität nicht funktionieren
• Annahmen (“der IT-Chef ist erreichbar”) stimmen nicht

Was eine TTX zeigt:

“Wer entscheidet ob wir den Betrieb abschalten?” - Antwort: Schweigen → niemand weiß es genau

“Wie informieren wir Kunden bei einem Datenleck?” - Antwort: “Das macht… Marketing? Die Geschäftsführung? Legal?”

“Haben wir Offline-Backups die wir im Ransomware-Fall nutzen können?” - Antwort: “Ich glaube schon… aber ich müsste IT fragen”

Ergebnis: Lücken sichtbar BEVOR sie im Ernstfall kosten.

Arten von Tabletop Exercises

1. Einfache TTX (Discussion-Based)

• Moderator präsentiert Szenario
• Team diskutiert Reaktion
• Keine Zeitvorgaben, kein Stress
• Gut für: Erstes Kennenlernen des Plans, Awareness
• Dauer: 2-3 Stunden

2. Fortgeschrittene TTX (Injected Events)

• Moderator fügt während der Übung neue Informationen ein
• “Breaking News: Ihre Daten tauchen im Darknet auf”
• “Ihr CEO hat gerade ein Interview gegeben”
• Testet Adaptionsfähigkeit
• Dauer: 4-6 Stunden

3. Vollständige Krisenübung (Functional Exercise)

• Alle Rollen aktiv (IT, GF, Legal, Marketing, HR)
• Rollenspiel: Presse-Simulator, Kunden-Anrufe (simuliert)
• Zeitdruck und realistische Stresssimulation
• Dauer: 1 ganzer Tag

4. Full-Scale Exercise

• Echte Systeme teilweise einbezogen (Fail-over testen)
• Nur für sehr reife BCM-Programme
• Dauer: 1-3 Tage

Empfehlung für Mittelstand: Typ 1 oder 2, jährlich oder halbjährlich.

Ablauf einer Ransomware-Tabletop-Exercise

Vorbereitung (1 Woche vorher)

• Ziel definieren: Was wollen wir testen?
• Teilnehmer einladen: IT, GF, HR, Legal, Marketing, ggf. externe Partner
• Szenario auswählen: Ransomware-Angriff (häufigster Use Case)
• Materialien verteilen: IR-Plan, Kontaktlisten, BCP-Dokumente
• Moderator briefen: Inject-Karten vorbereiten

Übungstag - Szenario “Montag, 07:30 Uhr”

[Moderator]: “Es ist Montag Morgen. Der IT-Helpdesk erhält die ersten Anrufe: Windows-Rechner zeigen eine rote Nachricht - alle Dateien wurden verschlüsselt. Eine Lösegeldforderung: 500.000 EUR in Bitcoin.”

Inject-Karten (zeitgesteuert):

Zeit	Inject
08:00	”Der lokale Systemadministrator ist im Urlaub. Nicht erreichbar.”
09:00	”Ein Journalist von der WAZ ruft an - hat er die Geschichte schon?“
10:30	”Das BSI meldet sich: War das ein staatlicher Angreifer?“
11:00	”Ihre Krankenhaus-Partnereinrichtung ist ebenfalls betroffen”
12:00	”NIS2-Pflicht: Meldung ans BSI bis heute 17:00 Uhr”
14:00	”Ein Mitarbeiter hat in Panik seinen Laptop neu aufgesetzt”

Diskussionsfragen zu jedem Inject:

• “Was tun Sie jetzt?”
• “Wer entscheidet?”
• “Was kommunizieren Sie?”
• “Haben Sie die Notfallnummer Ihres IT-Dienstleisters griffbereit?”
• “Welche Systeme priorisieren Sie bei der Wiederherstellung?”

Debriefing (letzte 60 Minuten)

• “Was lief gut?”
• “Wo haben wir gemerkt, dass wir vorbereitet wären?”
• “Was müssen wir verbessern?”
• Aktionsplan: wer macht was bis wann?

Die häufigsten Erkenntnisse aus TTX

Kommunikation (fast immer ein Problem)

• Keine aktuellen Notfallkontakte (persönlich, nicht @firma.de!)
• Keine klare Eskalationskette
• GF und IT sprechen unterschiedliche Sprachen
• Kein definierter externer Kommunikationskanal (wenn Mail/Slack verschlüsselt)
• Pressekontakt ist niemandes Aufgabe

Technisch

• Backup-Status unklar (“Ich glaube, wir haben Backups”)
• Keine Offline-Kopien (alle Backups ebenfalls verschlüsselt)
• Keine Asset-Liste → unklar welche Systeme kritisch sind
• Forensik-Kapazitäten nicht definiert

Organisatorisch

• Entscheidungsträger nicht erreichbar / im Urlaub
• IR-Plan nicht geübt → niemand kennt ihn wirklich
• KEIN IR-Retainer mit externem Dienstleister vereinbart
• Cyber-Versicherung vorhanden aber Prozess unklar

Regulatorisch

• BSI-Meldepflicht (NIS2: 24h!) unbekannt
• DSGVO-Meldepflicht (72h an Aufsichtsbehörde) unbekannt
• Zuständige Aufsichtsbehörde nicht bekannt

Tabletop Exercise planen - Checkliste

Vorbereitung

• Ziel und Scope definieren (Was testen wir? Was NICHT?)
• Teilnehmer: alle relevanten Rollen (nicht nur IT!)
• Szenario wählen: Ransomware / Datenleck / DDoS / Insider-Threat
• Inject-Karten schreiben (5-8 reiche für 4h-Übung)
• Moderator: intern oder extern (externes Moderator = objektiver)
• Materialen: IR-Plan, Notfallliste, Versicherungspolice
• Zeitrahmen festlegen (4-6h für mittlere TTX)

Durchführung

• Regeln erklären: “Diese Übung ist kein Vorwurf. Ziel ist Verbesserung.”
• Zeitdruck simulieren (ohne zu überfordern)
• Alle Entscheidungen und Diskussionen dokumentieren
• Niemanden “gewinnen lassen” - Stresssituationen einbauen

Nachbereitung

• Hot Wash: sofortiges Feedback direkt nach der Übung
• After Action Report schreiben
• Aktionsplan: konkretes “Wer macht Was bis Wann”
• IR-Plan aktualisieren
• Nächste TTX planen (jährlich mindestens, besser halbjährlich)

TTX und NIS2 / ISO 27001

NIS2 (Art. 21 Abs. 2b - Incident Handling)

• Incident-Response-Plan ist PFLICHT
• Tabletop Exercises sind nachweisbares Mittel zur Überprüfung
• BSI kann Nachweis über geplante Übungen fordern

ISO 27001:2022

• Control A.5.24: Planning and preparation for information security incident management
• Control A.5.25: Assessment and decision on information security events
• Control A.5.26: Response to information security incidents

Zertifizierungsprüfer erwarten:

• Dokumentierten IR-Plan
• Nachweis dass Plan geübt wurde
• After-Action-Reports aus vorherigen Übungen
• Kontinuierliche Verbesserung (Aktionspläne umgesetzt)

Empfehlung:

• Tabletop Exercises in ISMS-Kalender aufnehmen
• Jährlich mindestens eine TTX, Protokoll im ISMS ablegen
• Erkenntnisse in Risikobeurteilung einfließen lassen