Anzeige

Notfallplan: Krisenkommunikation trotz IT-Ausfall

Bild: KI-generiert mit Google Gemini / stk

Der Krisenplan liegt im Intranet, die Kontaktliste in Outlook, der Stabsraum entsteht per Videokonferenz. Fällt die IT durch Ransomware, einen Rechenzentrumsbrand oder ein missratenes Update komplett aus, verliert der Krisenstab sein gesamtes Werkzeug. Was dann noch funktioniert, führte der CrowdStrike-Vorfall vor.

Im Juli 2024 rollt CrowdStrike ein Konfigurationsupdate für den Falcon-Sensor aus, das Windows-Systeme rund um den Globus erreicht. Durch einen Speicherzugriffsfehler stürzen die Rechner Minuten später reihenweise ab – Microsoft schätzt die Zahl auf rund 8,5 Millionen Geräte.

CrowdStrike stoppt die Auslieferung nach gut einer Stunde, doch die Systeme stecken bereits im Bluescreen fest. Für abgestürzte Geräte ist eine normale Fernwartung nicht mehr möglich. Der US-Rechnungshof GAO wertet den Vorfall in seiner Untersuchung als einen der potenziell größten IT-Ausfälle der Geschichte.

Abhängigkeitsfalle: Der Ausfall trifft auch den Krisenstab

Welche Werkzeuge besaß der Krisenstab noch? Daran hängt die Lehre für die Krisenkommunikation, nicht an der technischen Ursache. Alarmierung, Dokumentenzugriff, Videokonferenz, Mitarbeitererreichbarkeit und Entscheidungsprotokoll laufen vielerorts über dieselbe Infrastruktur – und fallen deshalb womöglich gemeinsam aus.

Krisenplan und Kontaktliste ausdrucken und allen Beteiligten eine Kopie geben – darauf läuft die Empfehlung der US-Behörde CISA hinaus. Interne E-Mail-, Chat- und Dokumenten-Dienste bleiben während eines Vorfalls möglicherweise unzugänglich, heißt es zur Begründung. Auch das britische NCSC empfiehlt alternative Kommunikationswege.

Papier und Funk sind aber nur ein Teil des Gedankens. Gemeint ist Unabhängigkeit vom betroffenen Fehlerbereich. Hängt ein externes SaaS-Werkzeug am selben zentralen Log-in, an denselben Endgeräten oder im selben Netz, taugt es als Fallback wenig. Solche Abhängigkeiten bleiben in Notfallkonzepten leicht unbemerkt.

Praxisbeispiele: Dieselbe Störung trifft Organisationen unterschiedlich

Delta Air Lines strich rund 7.000 Flüge in fünf Tagen. Den direkten Umsatzeffekt schätzt die US-amerikanische Fluggesellschaft auf etwa 380 Millionen US-Dollar, wie eine SEC-Veröffentlichung zeigt. Am Update allein hing es nicht, wie hart die Organisation getroffen wurde. Auch die Systemarchitektur spielte hinein, ebenso wie das Wiederanlaufverfahren. Und schlicht die Frage, welche Ressourcen für den Wiederanlauf zur Verfügung standen.

Wer in Phoenix oder Portland den Notruf wählte, kam durch. Stumm blieben allerdings die Computersysteme dahinter, sodass die Bearbeitung von Hand weiterlief. Dieses Muster nennt sich partielle Redundanz: Ein Teil der Kette hält die Störung aus, ein anderer nicht. Dokumentiert hat den Fall der Congressional Research Service.

Satellitenkommunikationseinheit, Funkgeräte, Notstromversorgung und Laptop mit Notfalldatenbank auf Workstation in einem atmosphärisch beleuchteten Technikraum.
Redundante Kommunikationswege im Krisenfall: Satelliteneinheit, Funkgeräte und autarke Stromversorgung sichern die Handlungsfähigkeit des Krisenstabs bei IT-Totalausfällen. (Bild: Google Gemini/stk)

Einzelfehlerpunkte: Fünf blinde Flecken untergraben die Vorsorge

Besonders folgenreich ist eine Lücke beim Wiederherstellungsschlüssel. Bei der Windows-PE-Wiederherstellung BitLocker-verschlüsselter Geräte kann die Eingabe des Schlüssels erforderlich sein, wie die Wiederherstellungsanleitung von Microsoft zeigt. Liegt er nur in einer betroffenen Management-Umgebung, versperrt die Schutzmaßnahme den eigenen Zugang.

Nicht anders steht es um den Krisenplan im Intranet: Ein Dokument an nur einem Ort teilt das Schicksal seines Systems. Die BSI-Vorlage für das Notfallhandbuch nennt beispielhaft mehrere Ablageorte: Intranet, Stabsraum, Battlebox und Büro des BCM-Beauftragten.

Drei weitere Schwachstellen stecken in den Fallbacks: Das externe Werkzeug hängt am ausgefallenen Identity-Provider. Software-Telefone, Konferenzsysteme und Alarmierungsplattformen können dieselbe Konnektivität oder dasselbe Gerätemanagement nutzen. Und ohne unabhängige Zugangsdaten und mehrere geschulte Redakteure kann auch die externe Statusseite mit der Hauptumgebung ausfallen.

Packliste: Was in den Notfallkoffer gehört

Ein vorbereiteter Notfallkoffer (englisch „Battlebox“) enthält alles, was ein Incident-Response-Team im Ernstfall braucht – ob in Form von Papierunterlagen oder offline nutzbaren Datenträgern:

Personen und Rollen
Rollenkarten mit Aufgaben und Entscheidungsrechten · Kontakte der Stabsmitglieder samt alternativer Rufnummern und Vertretungen · Erreichbarkeiten von Rechtsabteilung, Datenschutz, Betriebsrat und Pressestelle

Externe Stellen
Kontaktdaten von Lieferanten und Dienstleistern außerhalb ihrer Kundenportale · Aufsichtsbehörden, Meldestellen, Versicherer und Forensikdienstleister · Meldefristen und Meldeformulare · Ansprechpartner wichtiger Großkunden

Arbeitsmittel und Technik
Vordrucke für Zeitlinie, Entscheidungsprotokoll, Aufgabenliste und Schichtübergabe · Lagekarten und Netzpläne · Textbausteine · unabhängig verwahrte Zugänge der Statusseite · Wiederherstellungsmedien und Hinweise zum Schlüsselzugriff · Zugänge zum Ausweichraum · geladene Ersatzmobiltelefone mit Zweitanbieter-SIM

Formales
Versionsnummer, Erstellungs- und Prüfdatum sowie Siegel. An jedem relevanten Standort sollte ein Exemplar bereitliegen. Inhalt und Kontaktdaten sind mindestens jährlich sowie nach Änderungen, Vorfällen, Tests und Übungen zu überprüfen.

Rechtspflichten: Das BSIG schreibt Notfallkommunikation vor

Nach § 30 BSIG müssen besonders wichtige und wichtige Einrichtungen Sicherheitsvorfälle bewältigen, den Betrieb aufrechterhalten und Krisen managen. Dazu zählen gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls Notfallkommunikationssysteme. Die Umsetzung und Überwachung weist § 38 BSIG der Geschäftsleitung zu.

Die BCM-Checkliste und der BSI-Standard 200-4 nennen dafür unter anderem eine besondere Aufbauorganisation, Alarmierung, Wiederanlaufplanung und Ausweich-Telekommunikationsdienste.

Vorbereitung: Acht Bausteine sichern die Handlungsfähigkeit

Ein belastbarer C-Level-Notfallplan entsteht vor dem Ereignis. Acht Bausteine gehören hinein:

  1. Szenario festlegen: Die Geschäftsführung definiert konkrete Worst Cases, etwa den Ausfall von E-Mail, Intranet, Identitätsdiensten, Telefonie und Endgeräten.
  2. Rollen zuweisen: Für Ausrufung, Produktionsstopp, Behörden- und Pressearbeit braucht es Verantwortliche und Vertretungen.
  3. Battlebox bestücken: An relevanten Standorten liegen versionierte Notfallkoffer mit den benötigten Unterlagen und Arbeitsmitteln bereit.
  4. Kanäle trennen: Zweiter Mobilfunkanbieter, Telefonbäume und Treffpunkte schaffen Alternativen; für kritische Standorte kommen Funk oder Satellitentelefonie infrage.
  5. Statusseite auslagern: Sie läuft außerhalb der eigenen Infrastruktur, mit separater Authentisierung und vorbereiteten Texten.
  6. Mindestprozesse definieren: Jeder zeitkritische Prozess benötigt einen Plan B mit Papier, Telefon oder lokalen Listen.
  7. Lieferanten einbinden: Notfallkontakte, Reaktionszeiten und Wiederanlaufverfahren zeitkritischer Dienstleister gehören möglichst in Vertrag oder Service-Level-Agreement.
  8. Jährlich üben: E-Mail, Kollaborationsplattform, VPN und zentrale Endgeräte gelten dabei als ausgefallen.

Tabletop-Exercise-Pakete stellt die CISA bereit, eine Vorlage für das Notfallhandbuch das BSI. Der Haken an der Sache: Ein ungeübter Plan bleibt bedrucktes Papier.

Alarmierung: Der Stab prüft zuerst die Kanäle

In den ersten Minuten zählt ein klarer Ablauf mehr als vollständige Informationen. Die dafür benannte Person ruft die Krise über einen Weg aus, der auch ohne das Firmennetz funktioniert. Danach übernehmen Stabsleitung und Stellvertretung. Sie beziehen den vorgesehenen Stabsraum oder, falls dieser nicht verfügbar ist, den Ausweichraum. Anschließend prüft der Stab, welche Kommunikationswege tatsächlich noch funktionieren.

Belegschaft informieren, vorbereitete Ersatzverfahren starten – darum geht es in der ersten Stunde. Nach außen nennt der Stab vier Dinge: was betroffen ist, was weiterhin funktioniert, was Kunden tun sollen und wann das nächste Update folgt. Parallel laufen die gesetzlichen Meldefristen. Bei erheblichen Sicherheitsvorfällen mit Meldepflicht sind Meldungen binnen 24 und 72 Stunden fällig, nachzulesen in § 32 BSIG. Meldepflichtige Datenschutzverletzungen sind unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu melden – so steht es in Art. 33 DSGVO.

Gerade für diese Meldungen braucht der Stab belastbare Angaben. Unter Zeitdruck verschwimmt jedoch schnell die Grenze zwischen Hörensagen und Befund. Deshalb muss nachvollziehbar bleiben, wer welche Information wann eingebracht hat.

Stabilisierung: Feste Taktung schlägt spontane Meldungen

In den nächsten Stunden folgen die Meldungen einem festen Zeitplan: intern etwa alle 30 bis 60 Minuten, extern ungefähr alle zwei Stunden. Die genauen Abstände hängen von der Lage und der Zielgruppe ab. Auch wenn es nichts Neues gibt, sollte ein kurzes Update erfolgen – etwa: „Stand seit 12:00 Uhr unverändert.“ Bleibt eine angekündigte Meldung aus, entstehen schnell Gerüchte.

An jede Aussage nach außen gehören zwei Marker: Von wann stammt der Stand – und wie belastbar ist er? Ändert sich die Lage später, korrigiert der Krisenstab eine Momentaufnahme und kein Versprechen. Dokumentiert wird notfalls mit Stift auf Papier, denn der BSI-Standard 200-4 sieht auch Protokolle in Papierform vor.

Nachbereitung: Fünf Kennzahlen belegen die Krisenreife

Wenige Tage nach dem Ereignis beginnt die Nachbereitung, wobei die vollständige Bewertung Wochen dauern kann. NIST SP 800-61 Rev. 3 ordnet Incident Response dem Cyberrisikomanagement zu. Fünf Kennzahlen helfen bei der Auswertung:

  • Zeit bis zur Einberufung des Stabs
  • Erreichbarkeitsquote der Schlüsselpersonen
  • Zeit bis zur ersten internen und externen Meldung
  • Dauer der manuellen Prozesse
  • Zahl unklarer Verantwortungsübergaben

Unklare Übergaben weisen auf unsaubere Rollenzuweisungen hin. Den BCM-Rahmen setzt ISO 22301, für den Aushang bietet das BSI eine IT-Notfallkarte.

Technikfortschritt: Automatische Reparatur verkürzt die Ausfallzeit

Microsofts Quick Machine Recovery soll unterstützte Windows-11-Rechner automatisch reparieren, wenn sie nicht mehr starten. Das Gerät wechselt dafür in die Wiederherstellungsumgebung, verbindet sich mit dem Internet und lädt eine verfügbare Korrektur über Windows Update. Auf unternehmensverwalteten Geräten muss die IT diese Cloud-Funktion allerdings erst aktivieren. Doch ohne Netzzugang oder passende Korrektur funktioniert sie nicht.

Nachgebessert hat auch CrowdStrike. Zusätzliche Tests, schrittweise Roll-outs, mehr Kontrolle für Kunden: Davon berichtete der Anbieter in einer Kongressanhörung. Das Risiko eines ähnlich schwerwiegenden Ausfalls sinkt damit zwar, grundsätzlich ausschließen lassen sich fehlerhafte Updates aber nicht.

Fazit: Kosten pro Vorgang schlagen jeden Benchmark

Wirksam ist ein Notfallplan nur dann, wenn er außerhalb des betroffenen Fehlerbereichs verfügbar bleibt. Ob er auf Papier liegt oder im System, ist dabei zweitrangig. Alles andere könnte ebenfalls ausfallen. Nach 78 Minuten zog CrowdStrike das fehlerhafte Update aus der Auslieferung zurück – die bereits abgestürzten Geräte reparierte das nicht automatisch. Sie mussten zunächst manuell wiederhergestellt werden, später auch mit speziellen Wiederherstellungsmedien.

Vier Fragen bleiben für die Geschäftsleitung: Wer entscheidet im Ernstfall? Wie erreicht der Stab diese Person ohne Firmen-IT? Welche Leistung erbringt das Unternehmen ohne IT weiter? Wie dokumentiert der Stab seine Entscheidungen? Erst eine Übung, die alle vier Antworten praktisch prüft, macht aus dem Dokument einen belastbaren Notfallplan.

Autor: Stefan Kuhn