«CrowdStrike»: Ausfälle verstehen und vermeiden

Ein BlueScreen, der ausnahmsweise nichts mit CrowdStrike zu tun hat. Symbolbild.

Am Freitag standen in weiten Teilen der Welt Millionen von Windows-Rechnern still: Bancomaten, Lebensmittelgeschäfte, Flughäfen, Spitäler uvam. waren lahmgelegt. Die Schweiz blieb weitgehend nur verschont, weil sie noch schlief. Ich schaue hinter die Kulissen und zeige auf, was wir tun müssen, damit dies nicht nochmals passiert. Leider betrifft uns das alle.

Die Details finden sich in folgenden zwei Artikeln:
Teil 1: CrowdStrike oder: Wie eine Closed-Source-Firma fast die Welt lahmlegte
Teil 2: Wie können wir ein zweites «CrowdStrike» vermeiden?

Was ist passiert?

Selbst wer die letzten paar Tage hinter dem Mond verbracht hat: Um zwei Themen ist man nicht herumgekommen: CrowdStrike und Biden. Auch ich liefere im DNIP-Artikel eine Zusammenfassung, mit der üblichen Kombination von Technik, Hintergrund und Allgemeinverständnis. Also alles, was man braucht, um heute in der Kaffeepause auftrumpfen zu können.

Hier das Wichtigste in Kürze:

  1. Die Schweiz kam gut davon. Aber nicht, weil wir aufgeweckt, sondern weil wir verschlafen sind (wir hatten noch Nacht).
  2. Die SkyGuide-Geschichte ist etwas anders als ich ursprünglich dachte. Mehr dazu (Hintergrund, was bleibt) in der Korrigenda. [geändert 2024-07-24]
    Die einzigen mit öffentlich bekannten grösseren Ausfällen in der Schweiz war SkyGuide, deren Flugverkehrskontrolle durch CrowdStrike lahmgelegt wurde. Interessanterweise verbieten die AGB den Einsatz der Software in diesem Bereich. Auf diese Diskrepanz angesprochen meinte deren Pressestelle nur:
    «Skyguide setzt seit einigen Jahren Crowdstrike ein. Zu Einkaufsprozessen, Vertragsverhandlungen mit Lieferanten und operativem Einsatz äussern wir uns nicht.»
    Ich habe Fragen…
  3. Können wir gut schlafen? Nein, denn auch bei der Energieversorgung sind wir nur mit Glück vor grösseren Problemen verschont geblieben. Denn einige der grössten Stromkonzerne setzen CrowdStrike ein. Und hatten — zum Glück — nur ein paar interne Probleme. Das kann das nächste Mal anders aussehen.

Als Volk sind wir indirekt Chefs vieler dieser Firmen und der Aufsichtsorgane. Wir sollten also an guten Vermeidungsstrategien interessiert sein. Hoffe ich.

Der CrowdStrike-Vorfall war die schlimmste Art von Ausfall: Diejenige, die bedingt, dass alle Administrator:innen herumrennen müssen. Jeder PC will besucht werden, um ihn dort in einem Spezialmodus zu starten und ein paar Passwörter einzugeben, bevor man die auslösende Datei löschen kann.

Extrem aufwändig, vor allem in Firmen mit vielen Rechnern über viele Standorte verteilt. Ausgelöst durch eine Software, die u.a. genau das verhindern sollte.

Das darf nicht nochmals passieren.

Wie können wir es vermeiden?

Im zweiten Teil der Artikelminiserie gibt es zuerst einen Blick hinter die Kulissen. Auch hinter die Kulissen der einfachen Rezepte, die „im Internet“ angeboten wurden. Der zu einfachen Rezepte. Die Kernprobleme lagen weder am Freitag noch an Windows noch an der Programmiersprache.

Sie lagen daran, dass nicht richtig getestet wurde. Und Updates noch diesen „Channel Files“ nicht verzögert werden können („Staged rollout“). Und wahrscheinlich an den Entscheidungen des CrowdStrike-Managements, die dafür sorgten.

CrowdStrike ist extrem zurückhaltend, was Informationen betrifft. Ein Problem, welches schon die Vorgängerfirma des aktuellen CEO betraf.

So wussten wir 24-48 Stunden nach erstem Bekanntwerden der xz-Sicherheitslücke mehr über die Hintergründe als jetzt 96 Stunden nach dem CrowdStrike-Vorfall. Und das, obwohl die xz-Hintermänner alles versucht hatten, ihre Aktivitäten zu verschleiern.

Ein schlechtes Zeichen. Ganz besonders für eine Firma, die von Vertrauen lebt.

Aber was ist denn dieser ominöse «Logic error», der durch dieses CrowdStrike-Channel-File ausgelöst wurde und hinter dem gesamten Absturz von über 8 Millionen Rechnern weltweit steht? Nicht viel:

Programmcode ist die Festschreibung der Logik hinter dem Programm bzw. seinen Algorithmen, also den Rechenanweisungen. Das Programm *ist* die Logik. Entsprechend ist ein Logikfehler einfach ein hundskommuner Programmfehler. Einfach schön verpackt.

Ein weiteres Anzeichen für Intransparenz. Nicht gut.

Was lernen wir daraus?

  1. Homogenität ist gut, Heterogenität rettet aber Leben.
  2. Testen, testen, testen.
  3. Staged Rollout (nicht alles gleichzeitig updaten) für alles Kritische. Immer.
  4. Systeme sollten sich einen letzten guten Zustand merken. Nicht einfach, aber wichtig.
  5. Es wäre in grossen Firmen empfehlenswert, wenn man Systeme aus der Ferne neu aufsetzen könnte.
  6. Aber unbezahlbar sind gute IT-Ingenieur:innen mit Überblick. Sie können solche Risiken rechtzeitig erkennen. Das Management muss aber auch hören wollen.

Das geht uns alle an. Details im 2. Teil.

Das hat uns aber niemand gesagt!

Alle Entscheidungsträger sollten auch den «Move fast and break things»-Artikel lesen. Da werden lehrreiche und spannende Geschichten erzählt, wie ein moderner, zuverlässiger Softwareentwicklungsprozess aussieht (keine Programmierkenntnisse nötig, ehrlich).

Und welche Fehler von früher wir damit vermeiden, die dem „klassischen“ Softwareentwicklungsprozess immer noch anhaften.

Bei konsequenter Umsetzung wäre CrowdStrike wohl nicht so passiert.

[Neu 2024-07-24]:

  1. Es gibt inzwischen eine «Auflösung» von CrowdStrike, kommentiert.
  2. …und eine Liste von Dingen, die man eigentlich nicht zu wissen braucht. Aber Humor ist manchmal das Einzige, was in solchen Situationen hilft.

Die Details finden sich in folgenden zwei Artikeln:
Teil 1: CrowdStrike oder: Wie eine Closed-Source-Firma fast die Welt lahmlegte
Teil 2: Wie können wir ein zweites «CrowdStrike» vermeiden?

Aktuelles zu IT-Sicherheit


Bleibe auf dem Laufenden!

Erhalte eine Mail bei jedem neuen Artikel von mir.

Ca. 1-2 Mails pro Monat, kein Spam.

Folge mir im Fediverse


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.


Webapps