„Nur 62 Minuten“: Vom Sicherheitsanbieter zum Sicherheitsproblem

„Ihr Unternehmen kann innerhalb von nur 62 Minuten ruiniert werden“: Damit wirbt der Sicherheitsanbieter Crowdstrike. Nun hat der US-amerikanische Hersteller durch ein fehlerhaftes Produktupdate selbst einen geschätzten Schaden in Höhe eines mehrstelligen Milliardenbetrags verursacht – mit rasender Geschwindigkeit.

Am 19. Juli um 04:09 Uhr (UTC) verteilte der Security-Spezialist CrowdStrike ein Treiber-Update für seine Falcon-Software für Windows-PCs und -Server. Nur 159 Minuten später, um 06:48 UTC, meldete Google Compute Engine das Problem, das „nur“ bestimmte Windows-Computer und -Server mit der CrowdStrike Falcon-Software betraf.

Fast fünf Prozent des weltweiten Flugverkehrs wurde dadurch kurzerhand lahmgelegt, 5.000 Flüge mussten gecancelt werden. Supermärkte von Deutschland bis Neuseeland mussten schließen, weil die Kassensysteme versagten. Ein Drittel aller japanischen MacDonalds-Filialen schloss kurzfristig die Türen. Unter den betroffenen US-Behörden befinden sich das Department of Homeland Security, die NASA, die Federal Trade Commission, die National Nuclear Security Administration und das Department of Justice. In Großbritannien waren sogar die meisten Arztpraxen betroffen.

Das Problem

Der Vorfall weist auf ein brennendes Problem: Die Zentralisierung von Services und die zunehmende Vernetzung der dahinterstehenden IT-Systeme macht uns verwundbar. Wenn ein Dienstleister in der digitalen Lieferkette betroffen ist, kann die gesamte Kette brechen, was dann zu groß angelegten Ausfällen führt. Betroffen war in der Folge auch die Microsoft Azure-Cloud, in der tausende virtuelle Server erfolglos versuchten neu zu starten. Prominente Betroffene reagieren daraufhin recht eindeutig. So will Elon Musk die CloudStrike-Produkte von all seinen Systemen verbannen.
Erschreckender ist jedoch die Tatsache, dass eine Sicherheitssoftware in Bereichen eingesetzt wird, für sie nicht vorgesehen ist. Zwar wirbt der Hersteller recht drastisch mit der Bedrohung durch Dritte, übernimmt aber für die Probleme, die die eigenen Produkte verursachen können, und deren Folgeschäden keine Verantwortung. CrowdStrike rät in den AGB ausdrücklich davon ab, die Lösungen in kritischen Bereichen einzusetzen. Dort steht wörtlich – und in Großbuchstaben: „DIE CROWDSTRIKE-ANGEBOTE UND CROWDSTRIKE-TOOLS SIND NICHT FEHLERTOLERANT UND NICHT FÜR DEN EINSATZ IN GEFÄHRLICHEN UMGEBUNGEN AUSGELEGT ODER VORGESEHEN.“

Die Haftungsfrage

Nicht für kritische Infrastrukturen geeignet, aber gerne dort eingesetzt: Wie kann das passieren? Fahrlässige Fehler mit großen Schäden, aber keine Haftung des Herstellers: Wie kann das sein? 
Oft wird im Kontext von Open Source unzutreffend argumentiert, dass hier die Haftungsfrage im Falle von Fehlfunktionen und Risiken ungeklärt sei, obwohl die meisten Hersteller, die Open Source mit ihren Produkten in Verkehr bringen, sehr wohl Gewährleistung dafür übernehmen. 

Wir können einiges tun, um es besser zu machen, wenn wir die Probleme angehen, die durch mangelnde Qualität und die Abhängigkeit von einzelnen großen Herstellern entstehen. Natürlich wird eine Open Source Supply Chain kritisch betrachtet, und das ist auch gut so. Aber gegenüber einer proprietären Supply Chain hat sie klare Vorteile. Der Vorfall ist ein schlagendes Beispiel dafür. Dass ein Open Source Unternehmen planmäßig ein Update ausrollt, in dem basale Komponenten einfach nicht funktionieren, lässt sich durch entsprechende Toolchains leicht verhindern, und das geschieht auch so. 

Die Konsequenzen

Was also können wir aus dem Desaster lernen und welche Schritte sind als nächste zu tun? Hier sind einige Vorschläge:

1. Qualität verbessern: Der beste Hebel, um Druck auf die Hersteller zu machen, ist, über eine verschärfte Haftung die Motivation für Qualität zu erhöhen. Hier bietet der Cyber Resilience Act (CRA) erste Ansätze.
2. Safety first: Im vorliegenden Fall bezieht sich diese Regel vor allem auf den technischen Ansatz bei der Produktentwicklung. Tief in die Kundensysteme einzugreifen, ist sicherheitstechnisch umstritten. Viele Kunden lehnen das ab, die Betroffenen offensichtlich (noch) nicht. Sie haben jetzt den Schaden. Dabei gibt es Alternativen, die zudem auf Open Source basieren.
3. Software nur bestimmungsgemäß einsetzen: Wenn ein Hersteller vom Einsatz im kritischen Umfeld abrät, dann ist das keine Floskel in den AGB, sondern ein Ausschlussgrund.
4. Zentralisierung mit Augenmaß: Es gibt Vor- und Nachteile einer Zentralisierung der digitalen Supply Chain, die gegeneinander abgewogen werden müssen. Wenn Abhängigkeit auf mangelnde Vertrauenswürdigkeit trifft, entstehen Risiken und Schäden. Anwendende Behörden und Unternehmen stehen dann hilflos in der Warteschlange, ohne Alternativen, und ohne eigene Souveränität.