Kurzfassung: Eine Tabletop-Übung ist das Durchspielen eines Sicherheitsvorfalls am Tisch, ohne echte Technik: Ein Moderator schildert ein Szenario, das sich Schritt für Schritt entwickelt, und die Teilnehmer entscheiden, was sie täten. Der Wert liegt darin, den Incident-Response-Plan zu testen, bevor der Ernstfall es tut, und die Lücken zu finden: unklare Zuständigkeiten, fehlende Kontakte, Entscheidungen, die niemand treffen darf. Eine gute Übung braucht ein realistisches Szenario, die richtigen Teilnehmer über die IT hinaus, einen Moderator mit Einspielungen und vor allem eine ehrliche Auswertung, aus der konkrete Verbesserungen werden. Sie ist die günstigste Art, die Reaktionsfähigkeit zu prüfen.
Eine Tabletop-Übung zu planen ist der praktische Weg, den Incident-Response-Plan zu testen, bevor ein echter Vorfall ihn testet. Ein Plan, der nie geübt wurde, ist eine Vermutung: Er sieht auf dem Papier vollständig aus, aber ob die Zuständigkeiten klar sind, die Kontakte stimmen und die Entscheidungen im Druck getroffen werden, zeigt sich erst, wenn man den Vorfall durchspielt. Die Tabletop-Übung ist dafür das günstigste Werkzeug, weil sie keine Technik, kein Labor und keine Ausfallzeit braucht, nur einen Raum, die richtigen Leute und ein paar Stunden. Dieser Beitrag zeigt, wie man eine solche Übung aufsetzt: das Szenario, die Teilnehmer, den Ablauf mit Einspielungen und die Auswertung, aus der die eigentliche Wirkung entsteht.
Was eine Tabletop-Übung ist und was nicht
Eine Tabletop-Übung ist eine Trockenübung am Tisch, im Unterschied zu einer technischen Übung wie der Purple-Team-Übung, bei der echte Angriffe ausgeführt werden. Hier passiert nichts an echten Systemen; stattdessen schildert ein Moderator ein Szenario, und die Teilnehmer beschreiben und diskutieren, was sie tun würden. Das klingt weniger spektakulär als ein echter Angriff im Labor, testet aber etwas, das die technische Übung nicht erreicht: die Entscheidungen, die Kommunikation und die Organisation eines Vorfalls. Die meisten Vorfälle scheitern nicht an fehlender Technik, sondern daran, dass unklar ist, wer entscheidet, wer wen informiert und wer was tun darf. Genau das übt der Tabletop. Er ergänzt die technische Übung, statt sie zu ersetzen: Die eine prüft, ob das SOC den Angriff sieht, die andere, ob die Organisation ihn bewältigt.
Das Szenario
Ein gutes Szenario ist realistisch, relevant und entwickelt sich. Realistisch heißt: ein Vorfall, der diese Organisation wirklich treffen könnte, kein exotischer Sonderfall. Für die meisten ist das ein Ransomware-Vorfall oder ein kompromittiertes Konto mit Business Email Compromise, weil das die häufigsten schweren Fälle sind. Relevant heißt: Es berührt die Systeme und Prozesse, die dieser Organisation wichtig sind. Und es entwickelt sich: Das Szenario beginnt klein (eine gemeldete verdächtige Mail, ein langsamer Server) und eskaliert in Stufen, damit die Teilnehmer immer wieder neu entscheiden müssen. Der Moderator bereitet diese Stufen als Einspielungen vor, kleine Neuigkeiten, die die Lage verändern: „Jetzt meldet die Buchhaltung, dass Dateien verschlüsselt sind.“ „Die Presse ruft an.“ „Der Angreifer meldet sich mit einer Lösegeldforderung.“ Jede Einspielung zwingt zu einer Entscheidung und deckt auf, ob der Plan sie trägt.
Die Teilnehmer
Der häufigste Fehler ist, eine Tabletop-Übung nur mit der IT zu besetzen. Ein echter Vorfall betrifft die ganze Organisation, und genau die Schnittstellen zwischen den Bereichen sind die Stellen, an denen es hakt. Wer dabei sein sollte:
- Die IT und das Blue Team als die, die technisch reagieren.
- Die Geschäftsführung oder eine Person mit Entscheidungsbefugnis, weil viele Entscheidungen im Vorfall (Systeme abschalten, Lösegeld, Öffentlichkeit) über die IT hinausgehen.
- Die Kommunikation oder Pressestelle, weil die externe und interne Kommunikation im Ernstfall oft über den Schaden entscheidet.
- Der Datenschutz und die Rechtsseite, wegen der Meldepflichten, die im Vorfall unter Zeitdruck greifen.
- Vertreter der betroffenen Fachbereiche, etwa die Produktion oder die Buchhaltung, weil sie wissen, was ein Ausfall für das Geschäft bedeutet.
Nicht alle müssen bei jeder Übung dabei sein, aber eine Übung, die nur aus IT besteht, findet die organisatorischen Lücken nicht, um die es eigentlich geht.
Der Ablauf
- Vorbereitung. Der Moderator schreibt das Szenario und die Einspielungen aus, legt die Lernziele fest (was soll die Übung prüfen?) und lädt die richtigen Teilnehmer ein. Ein bis zwei Stunden Übungszeit sind ein guter Rahmen.
- Regeln klären. Zu Beginn wird der Rahmen gesetzt: Es gibt keine falschen Antworten, es geht nicht um Schuld, sondern darum, den Plan zu prüfen. Das ist wichtig, damit die Teilnehmer offen sagen, was sie wirklich täten, und nicht, was gut klingt. Dieselbe schuldfreie Haltung wie beim Post-Incident-Review.
- Das Szenario spielen. Der Moderator schildert die Ausgangslage, die Teilnehmer entscheiden, dann kommt die nächste Einspielung. Der Moderator hält das Tempo, notiert die Entscheidungen und die Stellen, an denen es hakt, und widersteht der Versuchung, selbst Lösungen zu liefern. Die entscheidende Frage immer wieder: „Wer macht das jetzt, und wie?“
- Die Lücken festhalten. Während des Spiels notiert der Moderator jede Lücke: eine Kontaktnummer, die niemand hat, eine Entscheidung, die niemand treffen darf, ein Schritt im Plan, der in der Praxis nicht funktioniert. Das sind die Ergebnisse der Übung.
- Auswerten. Direkt im Anschluss die Übung gemeinsam besprechen: Was lief gut, wo hakte es, welche Lücken wurden sichtbar? Diese Auswertung ist der wichtigste Teil.
Die Auswertung: wo die Wirkung entsteht
Eine Tabletop-Übung ohne konsequente Auswertung ist ein netter Nachmittag ohne Ertrag. Der Wert entsteht erst, wenn aus den gefundenen Lücken konkrete Maßnahmen mit Verantwortlichen und Fristen werden. Jede Lücke bekommt einen Eintrag: Was fehlt, wer kümmert sich darum, bis wann? Der Incident-Response-Plan wird entsprechend aktualisiert, die fehlenden Kontakte ergänzt, die unklaren Zuständigkeiten geklärt. Und die Übung selbst wird wiederholt, denn eine einmalige Tabletop-Übung ist ein Anfang, kein Abschluss: Erst die regelmäßige Wiederholung, mit wechselnden Szenarien, hält den Plan lebendig und die Organisation geübt. Das ist dieselbe Schleife wie im Post-Incident-Review: aus der Erfahrung wird eine dokumentierte Verbesserung, oder die Erfahrung war umsonst.
Typische Lücken, die eine Übung aufdeckt
- Fehlende Kontakte. Die Nummer des IR-Dienstleisters, der Versicherung oder der Aufsichtsbehörde, die im Ernstfall niemand zur Hand hat. Der häufigste und am leichtesten behebbare Fund.
- Unklare Entscheidungsbefugnis. Wer darf entscheiden, die Produktion anzuhalten oder ein Kernsystem abzuschalten? Wenn das im Vorfall erst geklärt werden muss, ist wertvolle Zeit verloren.
- Kommunikation nach außen. Wer spricht mit der Presse, wer informiert Kunden, und was wird gesagt? Ohne Vorbereitung entsteht hier der größte Reputationsschaden.
- Der Plan funktioniert nur auf dem Papier. Ein Schritt wie „Backup einspielen“, der voraussetzt, dass das Backup getestet und erreichbar ist, was im Ernstfall vielleicht nicht stimmt.
- Meldefristen unterschätzt. Dass die Meldepflicht schon nach Stunden greift, überrascht viele. Die Übung macht den Zeitdruck spürbar.
Fazit
Eine Tabletop-Übung ist die günstigste und oft wirksamste Art, die Reaktionsfähigkeit einer Organisation zu prüfen, weil sie genau das testet, woran die meisten Vorfälle scheitern: Entscheidungen, Kommunikation und Zuständigkeiten. Ein realistisches, sich entwickelndes Szenario, die richtigen Teilnehmer über die IT hinaus, ein Moderator mit Einspielungen und eine konsequente Auswertung, aus der Maßnahmen mit Fristen werden, machen aus ein paar Stunden am Tisch einen erprobten Plan. Für ein Blue Team ist die Tabletop-Übung die Gelegenheit, die Lücken im Ernstfall-Ablauf zu finden, solange sie noch nichts kosten, und den Incident-Response-Plan von einem Dokument in eine geübte Fähigkeit zu verwandeln.