Vom Papierplan zum Praxistest: Was der CrowdStrike-Ausfall für BCM verändert hat

Der 19. Juli 2024 hat einen Satz endgültig widerlegt, den viele Unternehmen unausgesprochen glaubten: „Unser BCM wurde noch nie gebraucht, also funktioniert es." An diesem Freitagmorgen zeigte sich, dass business continuity crowdstrike nicht nur ein Schlagwort ist, sondern eine operative Anforderung mit messbarem Scheitern.

Ein Jahr später ist der Ausfall nicht mehr Krisenthema sondern Referenzfall. Wer seine Business Continuity Management-Strukturen seither nicht überprüft hat, testet sie beim nächsten Vorfall live.

Der 19. Juli 2024: Was geschah und warum es jeden traf

Um 04:09 UTC begann CrowdStrike, ein fehlerhaftes Update seiner Falcon-Sensor-Software an Windows-Systeme auszuspielen. Das Update enthielt eine fehlerhafte Konfigurationsdatei (Channel File 291), die einen Speicherfehler im Windows-Kerneltreiber auslöste. Das Ergebnis war ein Bluescreen mit Boot-Loop und ohne automatische Wiederherstellung.

8,5 Millionen Windows-Systeme fielen innerhalb von Stunden aus. Nach Schätzungen des Versicherungskonzerns Parametrix dürften sich die versicherten Schäden bei Fortune-500-Unternehmen auf rund 5,4 Milliarden US-Dollar belaufen haben (Stand: Juli 2024, Parametrix-Analyse). Airlines strichen tausende Flüge, darunter dokumentiert Delta Air Lines mit über 7.000 gestrichenen Flügen in den Folgetagen. Krankenhäuser mussten nicht-dringliche Operationen verschieben. Behörden stellten auf Papierprozesse um.

Der entscheidende Befund ist freilich nicht die Schadenssumme. CrowdStrike war kein Angriff. Keine Ransomware, kein Nation-State-Akteur. Ein reguläres Software-Update hatte die Wirkung einer globalen Cyberattacke. Business-Continuity-Pläne, die ausschließlich auf Angreiferszenarien zugeschnitten waren, griffen nicht.

Lehre 1: Monokultur ist ein BCM-Risiko

Wer auf allen Endpoints denselben Sicherheitsagenten betreibt, schafft eine systemische Abhängigkeit. Ein einziges fehlerhaftes Update trifft dann nicht einen Rechner, sondern die gesamte Flotte gleichzeitig.

ISO 27031, die Norm für IKT-Kontinuität als Teil des BCMS, adressiert genau dieses Prinzip unter dem Begriff der „Redundanzarchitektur". Abschnitt 8.4 der Norm verlangt, dass Organisationen kritische IKT-Dienste so gestalten, dass ein einzelner Ausfall nicht zu einem vollständigen Betriebsstillstand führt. Ein Sicherheitsprodukt, das selbst zum Single Point of Failure wird, erfüllt diese Anforderung nicht.

Für den Mittelstand folgt daraus eine unangenehme Hausaufgabe. Welche Softwarekomponenten laufen flächendeckend und ohne Fallback auf allen Systemen? Die Antwort ist selten „keine".

Lehre 2: Update-Staging ist BCM-Pflicht, nicht DevOps-Kür

CrowdStrike hatte kein Staging-Verfahren für Content-Updates implementiert, das vergleichbar mit klassischen Software-Releases behandelt wurde. Das Update rollte ungefiltert auf alle Systeme.

ISO 22301:2019 (Abschnitt 8.4, Business Continuity Procedures) fordert, dass Organisationen Änderungsprozesse kontrollieren, die kritische Dienste beeinflussen könnten. Ein automatisches, ungestagtes Update auf Sicherheitssoftware mit Kerneltreiber-Zugriff ist ein solcher Prozess.

Kanarische Releases, also das initiale Ausspielen auf einer kleinen, kontrollierten Systemgruppe, bevor der Rollout flächendeckend erfolgt, sind in der Softwareentwicklung längst Standard. Im Security-Tooling gelten sie freilich noch immer als exotisch. Nach CrowdStrike hat sich das geändert. Mehrere große EDR-Anbieter haben stagingbasierte Update-Kanäle für Enterprise-Kunden eingeführt oder ausgebaut.

Lehre 3: IKT-Drittparteien brauchen Kontinuitätsbewertung

CrowdStrike war für viele Unternehmen kein kritischer Lieferant im formalen Sinne. Das Produkt schützte die Infrastruktur, war aber selbst keine Infrastruktur. Diese Einordnung war falsch.

DORA, die EU-Verordnung zur digitalen Resilienz für Finanzunternehmen (Verordnung (EU) 2022/2554), schreibt in Art. 28 ff. eine strukturierte Drittparteienrisikoanalyse vor. Kritische IKT-Drittdienstleister müssen identifiziert, bewertet und vertraglich auf Kontinuitätsanforderungen verpflichtet werden. Art. 30 Abs. 2 lit. f DORA verlangt explizit Regelungen zur Verfügbarkeit, Kontinuität und Wiederherstellung.

Der CrowdStrike-Fall zeigt, dass „kritisch" nicht bedeutet, dass ohne den Dienst gar nichts geht. Kritisch heißt, dass ein Ausfall flächendeckende Betriebsunterbrechungen auslösen kann. Auch Organisationen außerhalb des Finanzbereichs sollten diese Bewertungslogik übernehmen. Welche Drittanbieter können durch einen Fehler in ihrem Produkt gleichzeitig alle unsere Systeme lahmlegen?

Lehre 4: Offline-Wiederanlaufpläne müssen physisch existieren

Ein bemerkenswertes Detail aus dem CrowdStrike-Ausfall ist dokumentiert. Zahlreiche Unternehmen konnten ihre Notfallpläne nicht aufrufen, weil diese auf SharePoint, in OneDrive oder auf betroffenen Systemen lagen. Der Wiederanlaufplan war selbst ausgefallen.

ISO 22301:2019 Abschnitt 8.4.5 verlangt dokumentierte Wiederanlaufverfahren, die in einer Notlage tatsächlich verfügbar sind. „Verfügbar" ist dabei technisch zu verstehen. Ein Dokument auf einem ausgefallenen Server ist nicht verfügbar.

Die Konsequenz ist schlicht und wird dennoch erstaunlich selten umgesetzt. Kritische Wiederanlaufpläne müssen in ausgedruckter Form oder auf offline gespeicherten Medien vorliegen. Standortverantwortliche müssen wissen, wo diese liegen. Das gilt insbesondere für die ersten 30 bis 90 Minuten einer Großstörung, in denen Entscheidungen unter Unsicherheit getroffen werden müssen.

Lehre 5: Kommunikationspläne ohne Microsoft 365

Am Morgen des 19. Juli 2024 waren Teams, Outlook und SharePoint für viele Unternehmen nicht erreichbar. Nicht weil Microsoft direkt betroffen war, sondern weil die Endgeräte ausgefallen waren, über die der Zugriff erfolgte.

Eine Business-Continuity-Kommunikation, die ausschließlich auf das reguläre Kollaborations-Stack aufbaut, versagt genau dann, wenn sie gebraucht wird. ISO 22301:2019 Abschnitt 8.4.3 fordert explizit Kommunikationsverfahren für Notfallsituationen, die von den betroffenen Systemen unabhängig sind.

In der Praxis bedeutet das dreierlei. Mobilnummern der Krisenkommunikations-Kerngruppe müssen außerhalb digitaler Systeme verfügbar sein. Ein alternativer Kommunikationskanal (Signal-Gruppe, SMS-Kette, Festnetz-Kaskade) muss definiert und bekannt sein. Externe Stakeholder müssen wissen, wie sie das Unternehmen in einem solchen Szenario erreichen.

ISO 22301 und DORA: Wie Normen auf CrowdStrike reagiert haben

ISO 22301 und ISO 27031 haben keine Notfall-Revisionen erfahren. Das war auch nicht nötig, denn die Anforderungen standen bereits im Text. Was CrowdStrike geändert hat, ist die Auslegungspraxis.

Die ISO 22301-Zertifizierungspraxis hat die Anforderungen an Business Impact Analyses (BIA) in Bezug auf IKT-Lieferanten verschärft. Auditoren fragen heute gezielt nach, ob Sicherheitstools in der IKT-Kontinuitätsplanung berücksichtigt sind und ob es Szenarien für lieferanteninduzierte Ausfälle gibt.

DORA ist am 17. Januar 2025 in Kraft getreten. Art. 24 verpflichtet betroffene Finanzunternehmen zu regelmäßigen Resilienztests, die über klassische Backuptests hinausgehen und explizit IKT-Drittparteienszenarien einschließen sollen. Der CrowdStrike-Fall dient in vielen DORA-Implementierungsprojekten inzwischen als Referenzszenario für genau diesen Testtyp.

Für Unternehmen außerhalb des DORA-Geltungsbereichs gilt: Die regulatorische Logik ist übertragbar. ISO 27031 Abschnitt 8.6 verlangt regelmäßige Tests und Übungen des IKT-Kontinuitätsplans. Ein Planspiel auf Basis eines realen Vorfalls wie CrowdStrike ist konzeptionell wertvoller als ein generisches Ausfallszenario.

Was ein Mittelständler heute priorisieren sollte

Business continuity crowdstrike ist kein Thema nur für Konzerne. 8,5 Millionen betroffene Systeme bedeuten, dass Unternehmen jeder Größe betroffen waren. Darunter waren zahlreiche mittelständische IT-Abteilungen, die an diesem Freitag manuell Systeme reparieren mussten, ohne Plan, ohne Priorisierung, ohne Kommunikationsprotokoll.

Drei Maßnahmen sind kurzfristig umsetzbar und haben hohen Hebel:

1. IKT-Drittparteienregister aktualisieren. Welche Software-Agenten, Security-Tools und Cloud-Dienste laufen flächendeckend auf allen oder kritischen Systemen? Diese Komponenten gehören in die Business Impact Analysis, nicht nur die Anwendungen, die direkte Geschäftsprozesse abbilden.

2. Update-Richtlinie für kritische Systemsoftware definieren. Automatische Updates auf Sicherheitsprodukte mit Kerneltreiber-Zugriff sollten auf einen Staging-Kanal umgestellt werden. Viele EDR-Anbieter bieten dies heute an. Wer das nicht umsetzt, delegiert das Risiko an den Anbieter.

3. Erste-30-Minuten-Protokoll für Großstörungen entwickeln. Dieses Protokoll muss offline verfügbar sein, muss Kommunikationswege ohne reguläre IT benennen und muss bekannt sein. Nicht im Wiki, sondern im Schrank.

Wer zusätzlich eine ISO 22301-konforme BCM-Struktur aufbauen oder überprüfen möchte, findet unter SECURAM BCM-Leistungen Informationen zur Begleitung von der initialen Business Impact Analysis bis zur Zertifizierungsreife. Ergänzend erläutert unser Beitrag zum Risikomanagement im Mittelstand, wie sich solche Drittparteienrisiken in einer übergreifenden Risikolandkarte verankern lassen. Für NIS-2-betroffene Unternehmen zeigt die NIS-2-Betroffenheitsprüfung, welche zusätzlichen Pflichten aus dem neuen Regelwerk erwachsen.

FAQ: CrowdStrike, BCM und was das für Ihr Unternehmen bedeutet

Wie hätte unser BCM uns beim CrowdStrike-Ausfall geschützt?

Ein funktionierendes BCM hätte drei Dinge geleistet. Erstens eine vorab definierte Priorisierung, welche Systeme zuerst wiederhergestellt werden. Zweitens einen Kommunikationsplan, der ohne die ausgefallene IT funktioniert. Drittens dokumentierte manuelle Ersatzprozesse für kritische Geschäftsabläufe. Unternehmen mit ISO 22301-zertifizierten BCMS-Strukturen berichteten in der Nachbetrachtung deutlich kürzere Wiederanlaufzeiten, nicht weil ihre IT schneller lief, sondern weil die Entscheidungswege klar waren.

Was ist eine Business Impact Analysis und warum ist sie beim Thema CrowdStrike relevant?

Die Business Impact Analysis (BIA) nach ISO 22301 Abschnitt 8.2 identifiziert, welche Prozesse wie schnell wiederhergestellt werden müssen (Recovery Time Objective, RTO) und welcher Datenverlust tolerierbar ist (Recovery Point Objective, RPO). Beim CrowdStrike-Ausfall war das entscheidend. Wer keine BIA hatte, musste unter Zeitdruck entscheiden, was zuerst repariert wird. Mit BIA ist diese Entscheidung vorweggenommen.

Welche Update-Strategie ist BCM-konform?

Eine BCM-konforme Update-Strategie für kritische Systemsoftware sieht mindestens vor: automatische Updates nur auf einem definierten Staging-Ring (etwa 5 Prozent der Systeme), einen Beobachtungszeitraum von 24 bis 48 Stunden vor breiterem Rollout sowie ein Rollback-Verfahren, das auch dann funktioniert, wenn das Update selbst den Rollback blockiert (wie bei CrowdStrike). ISO 27031 Abschnitt 8.4 adressiert Change-Management im IKT-Kontinuitätskontext.

Wie oft sollten BCM-Tests stattfinden?

ISO 22301:2019 Abschnitt 8.5 verlangt regelmäßige Tests und Übungen des BCM, ohne eine feste Frequenz vorzuschreiben. Branchenpraxis ist mindestens ein Volltest pro Jahr, ergänzt durch Tabletop-Übungen (Planspiele) auf Basis realer Szenarien. Für Unternehmen, die unter DORA fallen, schreibt Art. 24 regelmäßige digitale Resilienztests vor, deren Frequenz und Tiefe von der Größe und Systemrelevanz des Unternehmens abhängt. Ein Planspiel auf Basis des CrowdStrike-Szenarios ist für die meisten Mittelstandsunternehmen ein sinnvoller Einstieg.

Ist CrowdStrike ein DORA-relevanter Drittparteienrisiko-Fall?

Ja, für Unternehmen, die unter DORA fallen (Finanzunternehmen im Sinne von Art. 2 DORA). CrowdStrike wäre nach Art. 28 DORA als kritischer IKT-Drittdienstleister zu bewerten, sofern ein Ausfall wesentliche Betriebsunterbrechungen verursachen kann. Die EBA hat in ihren Q&A-Dokumenten klargestellt, dass Sicherheitssoftware mit flächendeckendem Einsatz in diese Kategorie fallen kann. Für Unternehmen außerhalb des DORA-Geltungsbereichs ist die Einordnung freiwillig, aber sinnvoll. Jeder IKT-Drittanbieter, der einen CrowdStrike-ähnlichen Ausfall auslösen könnte, sollte in der BIA entsprechend berücksichtigt sein.