Das Crowdstrike-Debakel und seine Lehren

Was am 19. Juli 2024 in Australien begann, zog mit dem Aufgang der morgendlichen Sonne über die Erde und riss Millionen Windows-Computer mit sich: die größte IT-Panne aller Zeiten. Was waren die Ursachen für diesen globalen Ausfall und welche Lehren müssen wir ziehen?

Ein Überblick

Es ist ein tägliches Ritual in den Büros dieser Welt: Ankommen, Kaffeemaschine an, Hinsetzen und dann: Computer hochfahren. Doch am Freitag, den 19. Juli, wurde diese Routine jäh unterbrochen von etwas, das in der Fachwelt als "BSOD" bezeichnet wird, einem "Blue Screen of Death" (etwa: einem blauen Bildschirm des Todes). Nichts ging mehr auf Windows-Computern weltweit, in Krankenhäusern, Flughäfen, Behörden, Schulen, der Industrie. Die Computer ließen sich nicht mehr hochfahren.

Was war passiert? Die Hinweise verdichteten sich schnell. Offenbar hingen die Symptome zusammen mit dem neuesten Update einer Sicherheitssoftware, der sog. "Falcon"-Plattform der in Texas in den USA ansässigen Firma Crowdstrike. Diese Software wird von Unternehmen eingesetzt, um Schadprogramme und davon verursachte verdächtige Aktivitäten zu erkennen und zu eliminieren - also eine Art hochentwickelte Antiviren-Software.

Diese Software ist auch für Mac und Linux-PCs verfügbar, aber in diesem Fall waren nur Windows-Systeme betroffen. Und zwar weltweit. Und es war schnell klar: Der Schaden geht in die Milliarden und die Aufarbeitung des Debakels wird Unternehmen und die Öffentlichkeit noch jahrelang beschäftigen. Technisch war zwar bereits relativ schnell ein Workaround gefunden, mit dem man das unmittelbare Problem der blau anlaufenden PCs beheben kann. Dafür musste man den betroffenen PC im abgesicherten Modus starten und dann eine bestimmte Datei im fehlerhaften Falcon-Update löschen. Aber das war in der Praxis tückisch.

Denn so begann für viele IT-Administratoren das, was sie als "Turnschuh-Administration" bezeichnen. Sie mussten aus Kapazitätsgründen eine Triage machen - wen retten wir zuerst? Wer braucht es am dringendsten? Und welchen Kunden stellen wir hinten an? Anschließend mussten sie dann zu jedem betroffenen Computer physisch hinfahren und das Procedere durchführen. Eine Mammutaufgabe bei komplexen Organisationen wie einem Krankenhaus oder einem Flughafen, mit hunderten oder tausenden Rechenplätzen, Terminals und Automaten. Stunden strichen ins Land, Flüge wurden annulliert, überlebenswichtige OPs verschoben, Fließbänder angehalten, Kunden vertröstet. Erst am Samstag konnte in den meisten betroffenen Betrieben Vollzug gemeldet werden - zumindest für die wichtigsten Rechner. Aber auch eine Woche nach dem Vorfall waren jedoch noch hunderttausende, weniger kritische PCs von dem Problem betroffen.

Was genau verursachte den Fehler?

Dass ein simples Update einer Sicherheitssoftware eine so verheerende Kettenreaktion auslösen konnte, liegt in diesem Fall an Besonderheiten im Windows-Betriebssystem. Jeder Heimanwender weiß, dass Anti-Viren-Programme und ähnliche Software nur funktioniert, wenn sie möglichst umfassende Berechtigungen im Betriebssystem hat. Um Schädlinge tief im System aufspüren und neutralisieren zu können, müssen Norton, Avira und Co. eben genauso tief ins System eingreifen können. Das gilt in besonderer Weise für High-End-Sicherheitslösungen wie die Falcon Suite.

Diese sogenannte "Endpoint Detection and Response" (EDR) von Crowdstrike benötigt im Betrieb sogenannte "Kernel-Mode-Rechte". Ein Kernel (englisch für "Kern") ist wie der CEO eines Computers. Er sorgt dafür, dass Programme und Hardware gut und effizient zusammenarbeiten. Dabei gibt es in einem Computer mehrere Sicherheitszonen, wie z.B. auch bei großen öffentlichen Events. Nicht jeder hat das Recht, in jede Zone zu gelangen. Software auf Kernel-Ebene (also im "Kernel-Modus") hat dabei alle erdenklichen Rechte in einem PC.

Windows hat Drittanbietern diese Rechte 2009 nach einer Klage der EU-Kommission wegen Wettbewerbsverzerrung eingerichtet. Und so kommt es, dass unter Windows manche sicherheitskritische Software mit Kernel-Rechten ausgestattet ist. Und ist in dieser Software dann "der Wurm drin", sei es wegen eines Angriffs oder eines dummen Fehlers im Code, kann passieren, was jetzt auch passierte: Der Computer erkennt einen Fehler auf der Ebene seiner Kernfunktionen und ist blockiert.

Monokulturen?

Fehler passieren jedem einmal. In gewisser Weise sind die kleinen Fehler es vielleicht sogar, die diese Welt menschlich und liebenswert machen. Ich persönlich finde, dass das dezente Knistern einer Schallplatte das Hörerlebnis reicher macht als der kristallklare Sound von Spotify. Und, dass ihre - physikalisch bedingte - leichte Körnigkeit Analogfotos lebendiger macht als die Hochglanzbilder des neuesten iPhones.

Aber kritisch wird es spätestens dann, wenn ein simpler Fehler ein größeres weltweites Chaos anrichtet als jeder bekannte Hackerangriff. Dann darf man sich die Frage stellen: ist die globale IT-Ordnung schuld? Immerhin hat Windows im Bereich der Desktop- und Laptop-Computer einen weltweiten Marktanteil von etwa 70 - 80%. Und die Firma Crowdstrike, mit Ihrer Falcon Suite als Flaggschiff, ist vor allem in den größten Unternehmen der Welt weit verbreitet. Haben Monokulturen Schuld an dem Debakel?

Nun, ich bin da nicht so sicher. Microsoft hat als Betriebssystem bei Desktops und Laptops deutlich die Nase vorn - bei Mobilgeräten und im IoT spielen sie keine Rolle (iOS ist von Apple und Android ist ein Linux-System), und die Serverlandschaft, die im Hintergrund das 21. Jahrhundert am Laufen hält, ist von Linux-Systemen dominiert. Ein wirkliches Monopol lässt sich also nicht direkt feststellen.

Und der Fehler lag hier tatsächlich bei Crowdstrike, nicht bei Windows. Allerdings ist auch Crowdstrike bei aller Marktmacht mitnichten ein Monopolist. Von Konkurrenten wie SentinelOne, Cisco, Broadcom, Mandiant, WithSecure und auch Windows selbst werden Alternativen zu Falcon angeboten und diese auch genutzt. Es ist also davon auszugehen, dass ein ähnlicher Fehler sowohl andere Betriebssysteme, als auch andere Software hätte betreffen können.

Das alles soll den Einfluss von Playern wie Microsoft und Crowdstrike, deren Name hier in tragischer Weise passt, nicht kleinreden. Wenn ausgerechnet die Software, die für die Sicherheit eines Systems sorgen soll, einen Fehler hat, dann ist schnell Land unter.

Was können Unternehmen tun, um sich zu wappnen?

Wie können sich Unternehmen also vor Debakeln wie diesem schützen? Wie sollten sie ihre IT ausrichten, damit sie möglichst resilient durch eine solche Krise gehen? Wie können wir die IT unserer Unternehmen so antifragil gestalten, dass wir vielleicht sogar von solchen Ereignissen profitieren können (denken wir nur an Fluggesellschaften: manche flogen, manche nicht...).

Hier gibt es tatsächlich keine einfache Lösung. Man könnte das Betriebssystem wechseln, und tatsächlich haben die verschiedenen Systeme individuelle Vor- und Nachteile. Unsere Kunden wissen z.B., dass wir große Linux-Fans sind. Aber Crowdstrike selber hat in der Vergangenheit auch schon Updates bereitgestellt, die dann Linux-Systeme blockierten. Die Resonanz war erwartbar geringer, das Problem für die betroffenen Unternehmen aber ähnlich.

Parallelstrukturen aufzubauen ist gerade im Bereich der Sicherheitssoftware selten sinnvoll. So, wie auch Heimanwender nicht Kasperski und Norton gleichzeitig installieren können, geht dies auch in professionelleren Settings nur sehr bedingt, weil diese Programme sich sonst in die Quere kommen und gegenseitig behindern. Und mehrere Computer mit unterschiedlichen Betriebssystemen für die selben Aufgaben vorzuhalten ist nicht nur teuer, sondern organisatorisch aufwändig und auch nur dann sicherer, wenn es die Admins schaffen, auch all diese Systeme stets kompatibel und aktuell zu halten - eine Mammutaufgabe.

Einige grundlegende Maßnahmen könnten Unternehmen je nach Größe und Anwendungsfall zwar ergreifen. Dazu gehören u.a.:

• Analoge und/oder digitale Redundanzen aufstellen, um das Kerngeschäft so im Notbetrieb weiter betreiben zu können.
• Robuste Notfall-Verfahren entwickeln und kommunizieren.
• Zentralisierte Lösungen wie die großen Cloud-Anbieter meiden, wo sinnvoll und möglich. Lösungen mit geringerer Marktdurchdringung nutzen.
• Wo möglich, Updates nur rekursiv, d.h. gestaffelt, einspielen und die Auswirkungen testen.

Aber vor allem der letzte Punkt leitet gut über auf die Hauptproblematik in diesem Fall.

Was müssen Software-Entwickler tun, um solche Fehler zu vermeiden?

Der Fehler lag hier weniger im System. Er war auch für die Anwender schwer zu vermeiden. Aber Crowdstrike als Hauptverursacher und Microsoft als betroffene Plattform hätten mehr tun können und müssen:

• Updates sollten, auch wenn sie noch so klein sind, rekursiv ausgespielt werden. Es muss nicht sein, dass erst die ganze Welt brennt, bevor der Fehler bemerkt wird. Es ist aus gutem Grund gängige Praxis, erst einen Teil der Nutzer zu aktualisieren und dann zu sehen, ob alles passt. Das wurde hier offenbar versäumt.
• Bereits vor dem Ausspielen eines Updates sollte dieses auf allen betreffenden Systemen automatisiert und auch manuell getestet werden, um eventuelle Fehler im Code noch rechtzeitig zu beheben (z.B. durch Fault Injection, Stabilitätstests, Stresstests, Fuzzing oder Schnittstellenprüfungen). Auch das scheint Crowdstrike vorliegend nur ungenügend getan zu haben - zu klein schien die Änderung.
• Es sollten auch mögliche Rollback-Verfahren etabliert und getestet werden, mit denen ein fehlerhaftes Update wieder zurückgefahren werden kann. Ein Rollback funktionierte im vorliegenden Fall deshalb nicht, weil der Computer ja nach dem Update gar nicht mehr hochfahren konnte. Aber sowas ist vermeidbar.

Crowdstrike selber gelobt Besserung. Aber der Schaden ist - vor allem ihren Kunden - bereits entstanden.

Die wirkliche Lösung: Skin in the Game

Aktuell haben Unternehmen wie Crowdstrike, außer der Gefahr für ihre eigene Reputation, wenig Anreize, ein so rigides Test-Regime zu etablieren. Ausgenommen bei Open-Source-Anwendungen schaut den Entwicklern selten ein außenstehender Dritter über die Finger und kann auf mögliche Gefahren hinweisen (das ist, nebenbei bemerkt, ein wichtiger Grund für die Sicherheit von Open-Source wie Gnu/Linux).

Hier sollten Strukturen geschaffen werden, wo Unternehmen wirklich wieder "Skin in the Game" haben. Wo sie (und ihre Entscheider) wieder direkt und persönlich für Schäden haften müssen, die durch die von ihnen verkaufte Software entstehen. Das würde Fehler zwar nicht verhindern - aber es hätte das Potenzial, zu verhindern, dass diese sich so weltweit und verheerend ausbreiten, wie das in diesem Monat der Fall war.