Am 19. Juli 2024 kam es weltweit zu einer Betriebsstörung zahlreicher Computer. Schätzungsweise 8,5 Millionen Systeme, die Windows als Betriebssystem und die Software Falcon von CrowdStrike nutzten, waren betroffen. Infolge dieser Ausfälle mussten zahlreiche Institutionen ihren Betrieb einstellen. Die Störung traf Unternehmen unterschiedlichster Größenordnungen – von kleinen und mittleren Unternehmen bis hin zu Betreibern kritischer Infrastrukturen. Der Gesamtschaden wird auf mindestens 10 Milliarden US-Dollar geschätzt.
Der Inhalt im Überblick
Was ist bei dem CrowdStrike-Vorfall passiert?
Betroffen waren Microsoft-Systeme, die an die Falcon-Plattform, einer Cloud-basierten Lösung für den Schutz von Endgeräten von CrowdStrike, angeschlossen sind. Am benannten Tag lieferte CrowdStrike eine Aktualisierung für eine Channel-Datei des Falcon-Sensors, um die Erkennungsrate von Schadsoftware zu verbessern. Dieser läuft im Kernel-Modul der jeweiligen Betriebssysteme, also mit höchsten Rechten und direkten Zugriff auf kritische Systemressourcen.
Durch das Update kam es zu einem Zugriff auf Speicherbereiche, die eigentlich außerhalb des Programms liegen, wodurch es unmittelbar zum Absturz der betroffenen Systeme kam, ähnlich zu dem Vorfall von Heartbleed, von dem wir berichteten. Da das Kernel-Modul vor dem Betriebssystem geladen wird, stürzten die Systeme beim Hochfahren direkt wieder ab, was zu einem Teufelskreis führte und einen Zugriff aus der Ferne unmöglich machte. Damit konnten auch neue Versionen der Channel-Datei nicht automatisch verwendet werden. In vielen Fällen mussten Administratoren direkt an die jeweiligen Systeme, um den Fehler beheben zu können.
Was können wir lernen aus dem CrowdStrike-Vorfall lernen?
Aus der durch das fehlerhafte Update entstandenen Situation können wir viel lernen – und das nicht nur aus der Perspektive von CrowdStrike.
Qualitätssicherung in Softwareentwicklung
Ursache für den Zugriff außerhalb des Speichers war die Übergabe von zu wenig Werten an den Compiler. Es wurden nur 20 Werte übergeben, obwohl 21 erwartet wurden. Etwas, dass einem unachtsamen Entwickler schnell mal passieren kann. Jedoch sollte Software im Rahmen ihrer Entwicklung verschiedene Arten der Qualitätssicherung durchlaufen, die unter anderem diese Art von Fehler vermeiden sollen. Die Möglichkeiten reichen hier weit. Vom Pair-Programming, über das Definieren und Durchlaufen einfacher Testszenarien, bis hin zu statischen Codeanalysen. Eigentlich rechtfertigt nichts, dass ein solcher Fehler Produktivsysteme erreicht.
Testen vor dem Einspielen von Updates
Dieser Punkt trifft nicht ganz auf den Vorfall von CrowdStrike zu, da diese Aktualisierung nicht ganz den klassischen Regeln von System- oder Softwareupdates folgt. Davon aber abgesehen sollten Updates nicht einfach blind auf Produktivsystemen installiert werden, weil diese Updates fehlerhaft sein können, was zu unvorhersehbaren Ereignissen führt. Stattdessen sollten Updates in einer kontrollierten Umgebung getestet werden, deren Versagen die Produktivumgebung nicht beeinträchtigen kann. Nach dem erfolgreichen Testen des Updates kann es dann auf die Produktivumgebung ausgerollt werden.
Vorbereitung auf Vorfälle & Aufbau eines Notfallmanagements
CrowdStrike hat uns nicht nur vor Augen geführt, wie viel Schaden durch weit verbreitete, fehlerhafte Software entstehen kann, sondern auch, wie unzureichend viele Unternehmen auf Notfälle vorbereitet sind. Dementsprechend sollten Unternehmen ein effektives Notfallmanagement aufbauen, um bestmöglich auf vergleichbare Situationen vorbereitet zu sein. Die Maßnahmen hier können entsprechend weit reichen und sollten sich an den jeweiligen Schutzbedarf der Werte und dem Schadenspotential orientieren. Ebenso kann es sinnvoll sein, dedizierte Notfallpläne zu erstellen. Dabei ist es aber auch wichtig, diese Notfallpläne nicht nur in der Theorie zu erstellen, sondern diese auch in der Praxis im Rahmen von Notfallübungen zu erproben.
Im Rahmen der wachsenden Bedrohung durch Ransomware-Angriffe kann es hilfreich sein, ein spezialisiertes Team für Notfälle zu haben, das einen Vorfall idealerweise gar nicht erst zu einem Notfall werden lässt. Je größer ein Unternehmen ist und mit wachsender Systemrelevanz, desto mehr sollte auf eine angemessene Vorbereitung für Notfälle geachtet werden.
Auch gesetzliche Vorgaben wie DORA und NIS-2 verschärfen die Anforderungen an das Notfallmanagement weiter. Da beide Regelwerke zudem Anforderungen an die Lieferketten der betroffenen Unternehmen stellen, wirken sich die verschärften Vorgaben auch auf die Unternehmen innerhalb dieser Lieferketten aus.
