Ein Jahr nach dem Crowdstrike-GAU: Wurden die richtigen Konsequenzen gezogen?

Am Samstag jährt sich das Crowdstrike-Debakel. Ein guter Anlass, zurückzublicken. Was war passiert? Am 19. Juli 2024 rollte Crowdstrike ein fehlerhaftes Update auf alle Endpoint-Security-Agenten mit Crowdstrikes EDR-System Falcon aus, das Millionen von Windows-Rechnern zum Absturz brachte. Erschwerend kam hinzu, dass die Systeme dabei so nachhaltig beschädigt wurden, dass ein manueller Eingriff vor Ort erforderlich war, um sie wieder benutzbar zu machen.

Das hieß, dass manche Admins tatsächlich zu tausenden Windows-Rechnern gehen mussten, was sich teils über Tage hinzog. Die damit verursachten Schäden belaufen sich auch nach konservativen Schätzungen auf viele Milliarden US-Dollar.

Ursachenforschung

Die zentrale Ursache war Crowdstrikes miserable Qualitätssicherung beim Verteilen von derart kritischen Updates an Millionen von Systemen. Crowdstrike hat dieses Update vorab praktisch nicht getestet und es auf einen Schlag an alle Systeme verteilt. Üblich ist es, das gestaffelt in mehreren Phasen zu machen. Und schließlich haben sie auf die quasi sofort auftretenden Abstürze erst viel zu spät und unzureichend reagiert.

Hinzu kam die System-Architektur bei Windows, die es erlaubte, dass ein solches Channel-Update eine Speicherverletzung im Kernel verursachte. Denn beträchtliche Teile der Sicherheits-Software liefen direkt als Teil des Betriebssystemkerns, was bei Fehlern nicht nur ein Programm, sondern das komplette System zum Absturz bringt. Das hätte man technisch besser lösen können – übrigens auch unter Windows.

Apropos: Mit Windows traf das Problem ein Betriebssystem, das selbst nicht resilient genug konzipiert war. Der Linux-Kernel etwa bietet mit eBPF (extended Berkeley Packet Filter) eine Schnittstelle an, über die Sicherheits-Software auf Kernel-Ressourcen zugreifen kann, ohne selbst im Kernel-Modus zu agieren. Ziel ist es, möglicherweise weniger zuverlässigen Code aus dem Kern des Systems herauszuhalten. Unter Windows hingegen fehlten sowohl Unterstützung als auch Regeln für den Zugriff auf den Kern. Deshalb operieren alle Hersteller – einschließlich Crowdstrike – mit eigenen Treibern selbst im Windows-Kern herum. Und beim Laden dieses Crowdstrike-Treibers stürzte Windows ab.

Das geschah dann auch noch so früh im Startprozess, dass Anwender keine Chance hatten, einzugreifen; ihr System war in einer endlosen Reboot-Schleife gefangen. Auf die naheliegende Idee, den Boot-Prozess zu protokollieren und beim dritten Absturz an derselben Stelle einen Systemstart ohne den problematischen Treiber anzubieten, war man in Redmond offenbar nicht gekommen. Diese einfache Maßnahme hätte die Auswirkungen des Problems deutlich reduziert.

Nachgebessert

Mittlerweile haben die verantwortlichen Akteure nicht nur Besserung gelobt, sondern auch bereits konkrete Maßnahmen umgesetzt, mit denen man solch einen Super-GAU zukünftig vermeiden möchte. Allen voran Crowdstrike, die ihre Systeme und deren Betrieb nun „Resilient by Design“ auslegen wollen. Darunter firmiert zunächst die Beseitigung der bereits angesprochenen Versäumnisse beim Testen und Ausrollen der Updates.

Ziel sei es, Fehler zu finden und zu beseitigen, bevor sie die Systeme der Kunden treffen. Und die Kunden können mittlerweile sogar selbst bestimmen, ob sie Signatur- und Sensorupdates sofort oder mit zeitlicher Verzögerung erhalten wollen. Doch das birgt natürlich auch Risiken: Ganz aktuelle Angriffsmuster erkennt der Sensor dann erst mit Verspätung. Die kritisierte Kernel-Nutzung will Crowdstrike minimieren. Und schließlich soll ein „Chief Resilience Officer“ als Stabsstelle direkt unter dem Geschäftsführer die Widerstandsfähigkeit gegen neuerliche Ausfälle erhöhen.

Auch bei Microsoft steht die Zuverlässigkeit wieder höher im Kurs. Im Rahmen der Windows Resiliency Initiative hat man unter anderem den Boot-Prozess um die Quick Machine Recovery erweitert. Damit soll es zukünftig möglich sein, Windows-Systeme mit Boot-Problemen aus der Ferne wieder flottzubekommen. Ferner verbannt Microsoft Sicherheits-Software weitgehend aus dem Kernel und die Microsoft Virus Initiative (MVI) verpflichtet Sicherheitsanbieter zu umfassenderen Tests und gestaffelten Rollouts ihrer Updates.

Doch die Maßnahmen rufen auch Kritik hervor. Denn anders als bei Linux oder im eingezäunten Garten der Apple-Security ist Microsoft selbst Anbieter von kommerziellen Security-Produkten. Und es mehren sich in der Sicherheitsbranche bereits die Stimmen, dass Microsoft seine Position ausnutze, um sich weitere Vorteile für die eigene Sicherheitssoftware zu verschaffen. Es wäre nicht das erste Mal, dass man in Redmond Windows gezielt nutzt, um die Konkurrenz zu behindern und weitere Monopole aufzubauen. Da werden wir in Zukunft ganz genau aufpassen müssen, was technisch tatsächlich sinnvoll und nötig ist und wo die Wettbewerbsverzerrung beginnt.

Apropos Monopole und Monokulturen

Häufig ist auch zu hören, das Crowdstrike-Fiasko sei das Resultat einer Monokultur. Dem würde ich widersprechen. Crowdstrike ist zwar einer der großen Anbieter im Security-Markt aber bei weitem kein Monopolist; da gibt es SentinelOne, Trend Micro, Palo Alto und nicht zuletzt Microsoft selbst mit seinem Defender for Endpoint als valide Alternativen. Windows ist zwar eine Monokultur und damit auch ein Single Point of Failure. Aber wenn Windows statt auf 70 nur auf 30 Prozent der Systeme liefe und sich den Markt mit mehreren ähnlich starken Wettbewerbern teilte, hätte der Crowdstrike-Fail immer noch Milliardenschäden angerichtet. Microsofts Quasi-Monopol hat das Problem also höchstens vergrößert, aber keineswegs verursacht.

Zu kurz kommt in der Diskussion meiner Ansicht nach hingegen die Frage, wie es kommen konnte, dass ein großer, renommierter Hersteller wie Crowdstrike bei der Qualitätssicherung derart schlampt. Das liegt primär an den fehlenden Konsequenzen. Der Börsenkurs von Crowdstrike ist zwar kurzfristig abgestürzt, aber längst wieder auf neuen Höhenflügen. Den Schaden durch die Ausfälle tragen nicht die Verursacher – also Crowdstrike oder Microsoft, sondern deren Unternehmenskunden und wiederum deren Kunden, die etwa in Scharen an Flughäfen strandeten. Die laufenden Schadensersatzklagen wie die von Delta Airlines werden wohl bestenfalls ein paar leicht verschmerzbare Milliönchen ergeben.

An der systematischen Auslagerung des durch Schlamperei entstehenden Risikos auf die Gesellschaft hat sich auch ein Jahr nach Crowdstrike nichts nennenswert geändert. Sicherheit und Zuverlässigkeit erzeugen beim Hersteller primär Kosten, die er ohne direkte Umsatzverluste einsparen kann. Treibt man es zu weit und es knallt, dann tut man etwas Buße – und macht nach ein paar Jahren genauso weiter. Solange wir die Hersteller und Anbieter im Bereich IT nicht für grob fahrlässige Versäumnisse im Bereich Sicherheit und Zuverlässigkeit haften lassen, wird es auch weiter solche Vorfälle geben.

(ju)