Unstrittig ist, dass Crowdstrike ein Fehler in einem Pattern Update unterlaufen ist, der nicht durch die internen Prüfungen entdeckt worden ist, bevor dieses Pattern Update veröffentlicht wurde. Dies hat zu einem Speicherfehler im Kernel von Windows Systemen und zu deren Ausfall geführt. Die Systeme konnten nicht mehr erfolgreich gestartet werden, da diese immer wieder in diesen Fehler hineingelaufen sind. Die Lösung des Problems war sehr simpel, die Datei des Pattern Updates, die diesen Fehler verursacht hat, musste einfach gelöscht werden und das System hat wieder normal gestartet. Da die Kunden von Crowdstrike im Enterprise Segment beheimatet sind, hat es entsprechende Auswirkungen gehabt und auch viele Kunden der jeweiligen Unternehmen betroffen. Mit jeweils unternehmensbezogenen massiven IT-Ausfällen in einen Freitag hinein zu starten, ist nicht das Szenario, welches man sich so kurz vor dem Wochenende wünscht. Aber Dinge sind nunmal, wie Dinge einmal so sind.
Zum Glück gibt es ja einen auf den ersten Blick Schuldigen und dann liegt es auch Nahe schnell nach Schadensersatz zu rufen, da man ja seit mehr als einer Woche immer noch mit Problemen zu kämpfen hat. In diesem Fall war Crowdstrike der Auslöser, aber darf man sich wirklich die Schuldfrage in dieser Situation so einfach machen? Hier habe ich ganz gehörig meine Zweifel und das aus verschiedenen Gründen. Software ist nie zu 100% fehlerfrei und wird sie auch nie werden. Das gleiche gilt für Hardware, auch hier kann es entsprechende Fehler geben. Ein hypothetischer Fehler in intel oder AMD Server CPU’s (ist ja auch Hardware und Software), der zu einem bestimmten Zeitpunkt auftritt, würde ganze Datacanter ausfallen lassen. Ein anderes Szenario wäre eine Zero Day Lücke, welche von einer Cyberattacke ausgenutzt wird. Das hätte auf jeden Fall eine ganz andere Dimension als das Crowdstrike Problem des besagten Freitag. Manche erinnern sich an das Jahr 2000 Problem, was nicht eingetreten ist, da die IT’s über Monate damit beschäftigt waren, BIOS, Firmware, Betriebssystem und andere Software zu aktualisieren. Genau aus diesem Grund, weil man vorher seine Hausaufgaben gemacht hat, ist das Problem nicht aufgetreten, bzw. haben die Einzelfälle keine nennenswerten Schäden verursacht. Hätte man nichts gemacht, war die Schuldfrage ganz klar, es war jeder Schuld, der die Betriebsverantwortung innehatte. Genau dieses Szenario lässt sich auch auf den Crowdstrike-Vorfall anwenden. Wir alle wissen um die Tatsache, dass Software nicht frei von Fehlern ist, dies gilt uneingeschränkt für alle Arten von Software. Das klärt auch sofort die Frage, ob der Wechsel zu einem anderen Hersteller nicht “die Lösung” ist, da dieser ja ebenfalls die 100% Fehlerfreiheit nicht garantieren kann. Da es keiner garantieren kann, ist die Entscheidungsgrundlage nach wie vor dieselbe, warum man sich für Crowdstrike als Schutzsoftware entschieden hat. Das bringt einen jetzt wieder zu den eigenen Hausaufgaben. Diese Ausfälle können passieren, wie jetzt der jüngste aufgezeigt hat und solche Vorfälle werden auch in Zukunft passieren. Die Frage, ob es passiert, stellt sich nicht, sondern nur wann es wieder passiert – und damit ist man auch wieder bei der Betriebsverantwortung, die bei einem selbst liegt.
Alle die, die kalt erwischt worden sind oder sehr lange oder noch immer mit massiven Problemen wegen des Crowdstrike-Vorfalls kämpfen, haben schlicht ihre Hausaufgaben nicht gemacht, so einfach lässt es sich herunterbrechen – Stichwort BCM, Notfall- und Krisenhandbücher, Wiederanlaufpläne, Ressourcenplanung usw. einfach einen Plan entwickelt zu haben, wie man auf solche Szenarien reagiert!
Wenn der Vorfall eines gezeigt hat und da sprechen wir aus Erfahrung und dem jüngst Erlebten, dass alle, die sich im Vorfeld über solche Szenarien Gedanken gemacht und sich passend aufgestellt haben, sind im Verhälnis sehr schnell wieder in den Normalbetrieb übergegangen. Alle mit einem BCM, ob nun Teil eines ISMS oder etwas anderem, waren vorbereitet und konnten schnell und effektiv handeln, zumal die Lösung an sich trivial war – eine Datei musste gelöscht oder umbenannt werden. Nicht wenige, die vorbereitet waren(!), hatten ihre Kernsysteme schon gegen Freitagmittag wieder vollständig in Betrieb und spätestens ab 16:00 Uhr waren sie wieder so gut wie im Normalbetrieb.
Selbst entsprechend vorbereitet zu sein ist die Lehre und “die Lösung” aus dem Vorfall und nicht überrascht tun, dass IT Systeme oder Technik ausfallen können. Alle, die jetzt nach Schadensersatz rufen, weil die Wiederherstellung sehr lange gedauert oder immer noch andauert, sollten auch mal über ihre eigenen Versäumnisse in Ruhe nachdenken, weil sie nicht darauf vorbereitet waren, dass Technik und insbesondere Software durch Fehler, wie sie jeder Zeit passieren können, ausfallen kann. Wer jetzt nicht handelt, weil es sehr bequem ist, einen vermeintlich Schuldigen zu haben, wird unweigerlich wieder genau in dieses Szenario hineinlaufen, was vor allem auch noch deutlich schlimmer kommen kann.