CrowdStrike – Was können wir daraus lernen?

Was war passiert?

Am Freitag, den 19.07.2024 kam es weltweit zu zahlreichen Ausfällen von Windows Systemen. Grund dafür war ein Update der Firma CrowdStrike. Dieses Update spielte auf die beteiligten Windows Rechner eine Datei ein, die einen Device Treiber von CrowdStrike zum Absturz brachte. Das führte dazu, dass die betroffenen Windows Rechner in einer endlosen Schleife von Neustarts landeten (Blue Screen of Death, BSoD). Im Ergebnis waren unter anderem ganze Flughäfen lahmgelegt. Es handelte sich also um ein schwerwiegendes Ereignis, man kann auch sagen eine Katastrophe.

Natürlich gab und gibt es einige Beschuldigungen und auch Häme. Vor allem stand die Frage im Raum, wie ein Device Treiber ins System kommen kann, der ein so schwerwiegendes Problem auslösen kann. Doch aktualisiert wurde nicht der Device Treiber, sondern eine Datendatei. Der Treiber stürzte ab, weil diese Datendatei ein Szenario enthielt, auf das der Treiber nicht korrekt reagierte. Es war also kein kurzfristiges Update eines Treibers. Und ich gehe davon aus, dass sowohl CrowdStrike als auch Microsoft Prozesse etabliert haben, die darauf abzielen, solche Situationen zu vermeiden. Und trotzdem ist es passiert.

Es stellt sich für mich die Frage, was wir daraus lernen können. Es ist mir unmöglich, konkrete Empfehlungen zur CrowdStrike Situation zu geben. Da werden grundsätzlich fähige Entwickler arbeiten und ihren Kram vernünftig testen. Dennoch lautet mein Zwischenfazit: wir müssen als Entwickler massiv den Fokus auf das Thema Testen richten. Wer eine zu geringe Testabdeckung in seinen Projekten hat muss sich darum kümmern!

Das BSI…

Der Spiegel schreibt: Die Präsidentin des Bundesamts für Sicherheit in der Informationstechnik (BSI), Claudia Plattner, hat nun Maßnahmen angekündigt, um derartige Pannen künftig möglichst auszuschließen. »Es gibt ein paar Stellen und Hebel, an denen wir etwas tun können und auch müssen«, sagte sie dem Sender Phoenix.

Laut Plattner gehe es vor allem darum, bei den Herstellern deutlicher auf die Qualität der Produkte zu achten. »Da werden wir deutlich tiefer reinschauen«, sagte sie. In der jüngeren Vergangenheit sei bereits viel geschehen, um die Sicherheit zu erhöhen. »Der heutige Tag hat uns aber gezeigt, dass es in der Lieferkette durchaus noch einige Themen gibt, wo wir alle noch mehr machen müssen.«

Interessante Aussage. Ich frage mich, ob Frau Plattner versteht, wovon sie spricht. Gerade in den großen Unternehmen sind Prozesse etabliert, die zum Ziel haben, Fehler in der Software frühzeitig aufzudecken. Vielleicht denkt sie an noch mehr Vorschriften und Auflagen. Meiner Einschätzung nach hilft vor allem eines: wir Entwickler müssen uns an die Nase fassen und mehr tun für die Korrektheit unserer Software. Das CrowdStrike Problem ist die Spitze des Eisbergs. Es gibt ungezählte Softwareprojekte, die nach wie vor ohne oder mit drastisch zu wenigen Tests arbeiten. Das Problem wird meist heruntergespielt. Seit 2009, seit wir die Clean Code Developer Initiative gestartet haben, werden wir nicht müde darauf hinzuweisen, dass automatisiertes Testen von Software absolute Notwendigkeit ist. Man kann es vergleichen mit dem Anlegen einer Rettungsweste beim Segeln. Man tut es einfach! Auch bei schönem Wetter, auch als erfahrener Segler. Punkt.

Was nun?

Nun möchte ich nicht behaupten, dass bei meinen eigenen Softwareprojekten alles tippi toppi ist. Der Fall CrowdStrike hat mich sehr nachdenklich gemacht und ich habe mir meine Testabdeckung angeschaut. Da geht noch was! Auch beim Einsatz diverser Tools. Wir stehen beim Testen nicht mehr dort, wo wir 2009 waren. Coverage Analyse, Mutation Testing, Property Based Testing, Approval Testing… ungezählte Möglichkeiten.

Auch die Programmiersprachen haben sich weiterentwickelt. In C# müssen sich Entwickler zwingend mit dem Thema nullable auseinandersetzen. Jedes Projekt muss den Eintrag <Nullable>enable</Nullable> enthalten. Der Compiler und die IDE bombardieren uns dann in einem Legacy Projekt typischerweise mit Warnungen. Nun gilt es, diese eine nach der anderen anzugehen und bewusst zu entscheiden, was die jeweils beste Lösung ist, um das Thema null an der Wurzel zu packen. Ziel muss sein, möglichst keine nullable Referenztypen mehr zu verwenden.

Wir können als Entwickler einiges tun. Wichtig ist die Reflexion über unsere Arbeitsweise, um bewusst zu entscheiden, das nächste Feature erst anzugehen, wenn die bisherigen eine zuverlässige Testabdeckung erreicht haben.

Fazit

Die CrowdStrike Katastrophe muss minutiös aufgearbeitet werden. Es wäre für die gesamte IT Branche hilfreich, zu den Abläufen eine exakte Schilderung zu erhalten. So können wir aus den Prozessen und deren Lücken lernen und es zukünftig besser machen. In der Seefahrt wird jedes Unglück durch die Bundesstelle für Seeunfalluntersuchung untersucht und die Berichte sind offen zugänglich (siehe https://www.bsu-bund.de/DE/Publikationen/Unfallberichte/Unfallberichte_node.html). Als Segler schaue ich dort immer mal wieder rein, um daran erinnert zu werden, welche Maßnahmen notwendig sind, um Unfälle zu vermeiden. Im Bereich der Softwareentwicklung brauchen wir unbedingt eine Mentalität von Weiterentwicklung und Lernen. Legt eure Rettungswesten an!