Tabletop-Übung für IT-Ausfälle: ein Ablaufplan für die IT-Notfallübung in zwei Stunden

Tabletop-Übung für den IT-Ausfall: was zwei Stunden am Tisch zeigen

Eine Tabletop-Übung für einen IT-Ausfall bringt die Personen, die Ihr Disaster-Recovery-Plan nennt, für etwa zwei Stunden an einen Tisch und führt sie durch ein Szenario, ohne ein System zu berühren. NIST SP 800-84, der „Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities“, beschreibt die Form: Ein Moderator trägt das Szenario vor und stellt Fragen, ein Datenerfasser hält die Diskussion fest, und ein After Action Report benennt, was sich am Plan ändern muss. Dieser Artikel ist ein Ablaufplan für eine solche IT-Notfallübung, den Sie so verwenden können: Rollen, Vorbereitung, ein Szenario in sechs getakteten Stufen mit den Fragen dazu und der Weg der Befunde ins Runbook.

NIST fasst sich kurz. Tabletop-Übungen sind danach Diskussionen, zu denen sich das Personal in einem Schulungsraum trifft, und eine solche Übung „is discussion-based only and does not involve deploying equipment or other resources“. Der Leitfaden stammt vom September 2006 und wird bei NIST weiterhin mit dem Status „Final“ geführt. Als Dauer nennt er „typically two to eight hours“, für die Leitungsebene zwei bis vier Stunden. Zwei Stunden sind also die Kurzform.

Eine Tabletop-Übung übt einen Plan, sie testet kein System. NIST hält die beiden Wörter auseinander: Der Begriff „test“ ist dem Testen von Systemen oder Systemkomponenten vorbehalten. Nach zwei Stunden wissen Sie, ob die Beteiligten erreichbar sind, wer entscheidet, welche Schritte nur in einem Kopf existieren und welche Annahmen über Backups niemand geprüft hat. Ob ein Replikat startet, ist eine andere Frage; die Tests dafür beschreibt unser Leitfaden zu Disaster-Recovery-Tests.

Rollen im Raum: Moderator, Datenerfasser, Teilnehmer

NIST nennt für die Tabletop-Übung zwei Rollen im Übungsstab: einen Moderator („exercise facilitator“), der die Diskussion unter den Teilnehmern leitet, und einen Datenerfasser („data collector“), der festhält, was während der Übung geschieht. Eine Kopfzahl gibt NIST für keine der beiden an. Das Planungsteam, das die Übung vorbereitet, kann aus einer einzigen Person bestehen, und eines seiner Mitglieder kümmert sich um die Logistik.

NIST SP 800-84 (September 2006), Abschnitte 2 und 4; mit „von uns“ markierte Zeilen sind unser Vorschlag für diesen Ablaufplan. Die deutschen Bezeichnungen folgen dem allgemeinen Sprachgebrauch und sind keiner Norm entnommen.

NIST rät, Leitungsebene und operative Ebene anfangs in getrennten Tabletop-Übungen zu üben. Der Ablaufplan unten ist für die operative Ebene geschrieben, mit einem Entscheider im Raum. Entscheidungen, die der Geschäftsleitung zustehen, werden als offene Punkte festgehalten und in eine eigene, kürzere Sitzung mitgenommen. Der Moderator sollte nicht der Verfasser des Plans sein, und der Datenerfasser sollte nicht zugleich Teilnehmer sein: Wer Fragen beantwortet, schreibt nicht mehr mit.

Vorbereitung: Umfang, Ziele und vier Dokumente

NIST gliedert die Arbeit in Design, Entwicklung, Durchführung und Auswertung. In der Designphase legt das Team Themen und Umfang fest, bestimmt die Ziele, die Teilnehmer und den Übungsstab und regelt die Logistik. Für Übungen, die nicht groß und komplex sind, empfiehlt NIST, mindestens einen Monat vorher zu beginnen.

Aus der Entwicklungsphase gehen nach der Aufzählung von NIST vier Dokumente hervor:

• ein Briefing für die Teilnehmer mit Agenda und Angaben zur Logistik;
• ein Moderatorenleitfaden mit Zweck, Umfang, Zielen, dem Szenario, einer Fragenliste und einer Kopie des geübten Plans;
• ein Teilnehmerleitfaden mit demselben Inhalt ohne die Fragenliste;
• der After Action Report, der nachher anhand vorab festgelegter Bewertungskriterien geschrieben wird.

Der letzte Punkt wird gern ausgelassen. NIST will die Kriterien vor der Übung entwickelt sehen, damit der Datenerfasser weiß, welche Informationen er festhalten soll. Für diesen Ablaufplan schlagen wir drei vor: Jede Entscheidung hat einen benannten Verantwortlichen; jeder Kontakt wird über einen Kanal erreicht, der ohne das ausgefallene System funktioniert; jeder Schritt verweist auf einen Abschnitt im Runbook oder wird als fehlend festgehalten.

Ziele sollten wenige und überprüfbar sein. Unsere für das Szenario unten: Der Plan lässt sich aktivieren, und die Beteiligten sind erreichbar; das Team ist sich einig, wohin und in welcher Reihenfolge wiederhergestellt wird; das Alter des jüngsten brauchbaren Wiederherstellungspunkts ist bekannt und wird mit dem Recovery Point Objective im Plan verglichen; eine benannte Person informiert die Fachbereiche. Hat der Plan noch keine Wiederherstellungs­ziele je System, legen Sie diese zuerst fest; wie, zeigt unser Leitfaden zu RPO und RTO.

Zu unserer Leistung Cloud Disaster Recovery gehört ein kostenloses Screening, ein Überblick über Ihren aktuellen Backup- und DR-Stand; senden Sie uns die Systeme, die Ihr Plan abdeckt, und das Datum der letzten Übung, unser Team hilft Ihnen weiter.

Szenario für die DR-Tabletop-Übung: Storage-Ausfall im Monatsabschluss in sechs Einspielungen

Der Tabletop-Abschnitt von NIST beschreibt keine getakteten Einspielungen. Er kennt eine Szenarioschilderung und eine Fragenliste und sagt, der Moderator könne von Zeit zu Zeit Fragen aus dem Moderatorenleitfaden einstreuen („may inject periodic questions“). Die Einspielung als Substantiv („inject“), eine vorbereitete Nachricht, die den Teilnehmern im Lauf einer Übung übergeben wird, und die Master Scenario Events List gehören bei NIST zu den funktionalen Übungen. Wir entlehnen die Idee für die Tabelle, weil eine Uhr eine Sitzung von zwei Stunden in Gang hält. Die Tabelle ist unser Format, und das Szenario ist ein Beispiel zum Anpassen.

unser Ablaufplan und Beispielszenario; Übungsform, Rollen und Nachbesprechung nach NIST SP 800-84 (September 2006), Abschnitt 4; der Begriff Inject nach Abschnitt 5.

Der Moderator gibt jede Einspielung zu ihrer Minute frei, auch wenn die Diskussion der vorigen nicht beendet ist; was offen bleibt, ist ein Befund. Es folgen die Fragen je Stufe. Die mit „NIST“ gekennzeichneten sind Beispielfragen aus Anhang A von NIST SP 800-84 in unserer Übersetzung, die übrigen stammen von uns.

Minute 10, der Ausfall. Wer ist befugt, den Plan zu aktivieren (NIST)? Wie und von wem würden Sie über die Aktivierung benachrichtigt (NIST)? Wo liegt die Kontaktliste, wenn E-Mail und Wiki auf dem ausgefallenen Array liefen? Wer eröffnet den Fall beim Storage-Hersteller, und unter welchem Vertrag?

Minute 25, keine Reparaturzeit. Ab wann sagt der Plan, dass nicht länger gewartet wird, und wer entscheidet, wenn die benannte Person im Urlaub ist? Welche Systeme kommen zuerst zurück, und nennen alle dieselbe Reihenfolge? Hier zählt, was der Vertrag mit dem Hersteller zusagt; was „Next Business Day“ in den Bedingungen von Serverherstellern bedeutet, steht in unserem Artikel zum Vor-Ort-Service für GPU-Server.

Minute 40, das alte Backup. Welches Recovery Point Objective nennt der Plan für das ERP, und wer hat es letzte Woche mit den Job-Ergebnissen verglichen? Lassen sich die Buchungen seit Donnerstag erneut erfassen, aus welcher Quelle, und wem gehört diese Arbeit? Gibt es weitere Kopien, etwa ein Replikat oder Log-Sicherungen der Datenbank? Warum ein abgeschlossener Job wenig über die Wiederanlaufzeit sagt, erklärt unser Artikel Backup ist kein Disaster Recovery.

Minute 55, Anmeldung und Ziel. Sind die Verfahren zur IT-Wiederherstellung vollständig dokumentiert, und stimmen sie (NIST)? Welche Konten für Backup-Server, Hypervisor und Storage funktionieren ohne den Verzeichnisdienst der Produktion, und wer kommt jetzt an sie heran? Wo liegt das Wiederherstellungsziel, und wurde diese Datenmenge dort je wiederhergestellt? Welche Dienste müssen laufen, bevor die Datenbank startet?

Minute 70, die Fachbereiche fragen. Lassen sich die Wiederherstellungs­verfahren in dem Zeitrahmen abschließen, den der Plan vorgibt (NIST)? Wer nennt den Fachbereichen eine Uhrzeit, und auf welcher Grundlage? Was sagt der Service Desk, und wer hat den Text freigegeben? Verlangt ein Vertrag oder eine Vorschrift eine Meldung, und wer prüft das?

Minute 85, zurück zum Normalbetrieb. Wer gibt frei, dass das wiederhergestellte ERP stimmt, und mit welcher Testbuchung? Wie kehrt das System auf das primäre Array zurück, und ist dieser Schritt aufgeschrieben? Wird das wiederhergestellte System selbst ab der ersten Stunde gesichert? Den Ablauf beschreibt unser Leitfaden zu Failover und Failback.

Ransomware-Szenario für die Tabletop-Übung: was sich im Ablaufplan ändert

Derselbe Takt funktioniert für einen Sicherheitsvorfall, wenn drei Einspielungen ersetzt werden. In Minute 10 sind VMs verschlüsselt, und die Frage lautet, wer Systeme isolieren darf. In Minute 40 muss das Team sagen, welcher Wiederherstellungspunkt vor dem Eindringen liegt und wer das entscheidet. In Minute 70 kommen Meldepflichten hinzu, die unser Artikel zu den NIS2-Meldefristen behandelt. Eine Tabelle mit Einspielungen für diesen Fall steht in unserem Artikel zum Incident-Response-Plan, die Reihenfolge der Arbeiten in den Schritten der Ransomware-Wiederherstellung.

Fertiges Material gibt es. Die CISA veröffentlicht Tabletop Exercise Packages, nach eigener Angabe „over 100“, jedes anpassbar und mit Vorlagen für Übungsziele, Szenarien und Diskussionsfragen, Unterlagen zu den Rollen von Planern, Moderatoren und Teilnehmern sowie einer Vorlage für den After Action Report; unter den Cybersicherheits-Szenarien ist Ransomware. ISO 22398:2013, „Societal security: Guidelines for exercises“, von der ISO 2022 bestätigt, gibt allgemeine Hinweise zum Planen, Durchführen und Verbessern von Übungen. Für deutschsprachige Unterlagen führt das BSI unter den Hilfsmitteln zu seinem BSI-Standard 200-4 Business Continuity Management eine Dokumentvorlage „Übungskonzept“; ihren Inhalt haben wir nicht gelesen.

Nachbesprechung und After Action Report: von den Befunden ins Runbook

NIST setzt die Nachbesprechung unmittelbar nach der Diskussion an: Moderator und Datenerfasser sollen sie direkt im Anschluss führen, „often referred to as a hotwash“. Die Beispielfragen dazu lauten sinngemäß: Was sind die Stärken des Notfallplans, welche Bereiche brauchen eine genauere Prüfung, und wie lassen sich künftige Übungen und Tests verbessern? Die Anmerkungen aus der Nachbesprechung und die Notizen des Datenerfassers gehen in den After Action Report ein, dessen Muster in Anhang A eine Einleitung, die Ziele, die Agenda und die Befunde der Diskussion enthält, allgemeine und spezifische.

Ein Befund ist erledigt, wenn er einen Verantwortlichen, ein Datum und einen Ort in einem Dokument hat. Bei einer Wiederherstellungsübung ist dieser Ort meist ein Abschnitt eines Runbooks. Die Abschnittsnamen unten folgen der Vorlage in unserem Leitfaden zum Disaster-Recovery-Runbook.

unsere Beispiele aus dem Szenario oben; Abschnittsnamen aus unserer Runbook-Vorlage.

Zeigt die Übung, dass Systemstufen und Wiederherstellungs­ziele nie vereinbart wurden, beginnen Sie dort. In unserer Leistung Cloud Disaster Recovery definieren wir gemeinsam mit Ihnen die kritischen Systeme, Ziel-RPO und -RTO je Systemstufe und die Katastrophenszenarien, gegen die Sie sich absichern; beschreiben Sie uns die Systeme, die in Ihrer Übung aufkamen, wir antworten innerhalb eines Werktages.

Wie oft eine Tabletop-Übung, und was DORA und NIS2 zum Testen sagen

Ein Intervall nennt NIST nicht: Tabletop-Übungen sollen regelmäßig stattfinden, nach organisatorischen Änderungen, nach Aktualisierungen eines IT-Plans, nach neuen Vorgaben oder bei Bedarf. NIST SP 800-34 Rev. 1 hält für Systeme mit geringer Auswirkung eine Tabletop-Übung für ausreichend und verlangt für Systeme mit mittlerer Auswirkung eine funktionale Übung. Unser Leitfaden zu Disaster-Recovery-Tests schlägt eine Tabletop-Übung zweimal im Jahr und nach Planänderungen vor.

Für Finanzunternehmen verlangt DORA, die IKT-Geschäfts­fortführungs­pläne und die IKT-Reaktions- und Wiederherstellungs­pläne mindestens jährlich zu testen; die Bestimmungen zitiert unser Artikel zu DORA, Resilienztests und Backup. NIS2 zählt die Aufrechterhaltung des Betriebs und das Krisenmanagement zu den Mindestmaßnahmen, und die zugehörige Durchführungs­verordnung spricht für die von ihr erfassten Einrichtungsarten von Plänen, die getestet, überprüft und aktualisiert werden; siehe unseren Artikel zu NIS2, Backup und Business Continuity. In den Passagen, die wir dort zitieren, nennt keiner der beiden Texte Tabletop-Übungen. Dies ist eine allgemeine Information: Welche Pflichten für Ihr Unternehmen gelten, beurteilt Ihre Rechtsabteilung, und die nationale Umsetzung kann abweichen.

Nach der Tabletop-Übung: Ein Failover-Test zeigt, ob Systeme wieder anlaufen

Eines lässt der Ablaufplan absichtlich unbewiesen. Niemand hat etwas wiederhergestellt, die genannten Zeiten sind also Schätzungen. Der nächste Schritt ist ein Test, bei dem Systeme starten: die Wiederherstellung einer Systemstufe oder ein Failover in einem isolierten Netz. Ein unabhängiges IT-Infrastruktur-Audit betrachtet Backups und Restore-Tests als einen seiner Bereiche, und für VMware-Umgebungen listet unser Artikel zum VMware-Backup nach Broadcom, was nach einem Upgrade zu prüfen ist.

Wir betreiben Ausweichstandorte in Tier-III-Rechenzentren der EU, mit planmäßigen Failover-Tests in isolierter Umgebung und einem Bericht nach jedem Test: was hochkam, wie schnell, was zu beheben ist. Nennen Sie uns die Systeme, die Sie zuerst testen würden, und wie Sie sie heute wiederherstellen.

FAQ