Ich habe letztens hier schon über das Thema Lagebilder geschrieben, und den Aspekt Lagebildumfragen beleuchtet. In der IT-Security Koordinierungsstruktur des Bundes, dem IKDOK, wird einmal im Monat ein Lagebild erstellt, das irgendwo zwischen strategischer und operativer Ebene angesiedelt ist. Dieses wird dann an diverse Zielgruppen verteilt.

Einmal im Monat werden wir gebeten, einen Beitrag für dieses Lagebild zu liefern. Das ist immer eine spannende Frage, weil der Monatstakt es oft sinnlos macht, auf ganz akute Probleme einzugehen. Der Prozess vom Schreiben und Einwerfen unseres Beitrags, Aggregation dieses mit den anderen, Lagebildsitzung, Endredaktion, Freigabe und Verteilung dauert in Summe etwa eine Woche. Viele der wirklich spannenden Sachen sind bis dahin gegessen, und es macht keinen Sinn mehr, sie im Lagebild noch drinnen zu haben. Dafür gibt es unsere Warnungen.

Daher versuche ich immer, eine Abstraktionsebene höher zu gehen, einen konkreten Vorfall in den richtigen Kontext zu setzen, dahinter liegende Muster aufzuzeigen und Lösungsstrategien anzubieten, die nicht nur auf den Anlassfall passen.

Das ist nicht immer einfach.

Ich will diesen Prozess anhand eines aktuellen Beispiels erläutern:

Ausgangslage

Der Vorfall am 19. Juli mit den EDR von CrowdStrike war eine große Sache: es gab echte Auswirkungen auf die Bevölkerung und ein entsprechendes Medienecho. Auch wir waren involviert, es gab von uns ein Aktuelles und einen Blogpost.

Der Inhalt des ersteren ist für das Lagebild unbrauchbar, denn die Hinweise zur Behebung braucht ein Monat nach dem Vorfall keiner mehr. Der Blogpost schon eher, das war meine Vorbereitung für ein Interview, wo es auch schon um Lektionen aus dem Vorfall gehen könnte.

Überlegungen

Die erste Entscheidung war, welche der vier Lektionen aus dem Blogpost ich im Lagebild betonen will: idealerweise die, zu welchen ich Trends und Hintergründe angeben kann. Meine Wahl war „Abhängigkeiten“, zuvor muss ich aber noch den Anlass kurz umreißen und auch erklären, warum das ganze passiert ist.

Das Thema „Updates (incl. AV-Definitionen) auf kritischen Systemen“ ist überhaupt nicht neu, vor allem im Bereich der Gesundheitstechnik ist das ein Dauerbrenner, da an vielen Stellen nur zertifizierte Systeme eingesetzt werden dürfen. Da schon ein Windows Patchday, oder auch nur ein Pattern-Update der AV-Software die Zertifizierung aufheben kann, steht man dort immer schon in der Zwickmühle zwischen Security-Updates und Safety-Zertifizierung.

Abstrakt betrachtet sind die Systeme, die diese Definitionsupdates liefern, Teil der kritischen Informationsinfrastruktur. Fallen diese aus, oder (meistens schlimmer) liefern sie fehlerhafte Daten, dann kann das sehr direkte Auswirkungen auf die Verfügbarkeit haben. Das kann man aus dem Kontext NIS2 betrachten, und diese Systeme in die Risikobewertung miteinschließen. Wobei hier die Unterscheidung zwischen Lieferantenmanagement (verkauft mir der Hersteller eine vernünftige Lösung) und einem Outsourcing (etwa: liefert mir mein AV-Vendor jeden Tag gute Signatur-Updates) nicht trivial ist. Weil das viele noch nicht am Radar haben, ist hier auch ein Verweis auf den Cyber Resilience Act angebracht, der hier die Produkthaftung neu definiert.

Durch die Abhängigkeit von Cloud-Komponenten können auch signifikante Klumpenrisiken entstehen, die Steuerung von Solaranlagen ist dafür ein gefährliches Beispiel.

Wir hatte vor einiger Zeit einen Vorfall in einer kritischen Infrastruktur, bei dem ein Tausch einer Beschleunigungskarte in einer Firewall durch den Lizenzserver des Herstellers mit einem „Du darfst das nicht nutzen“ quittiert wurde, worauf es zu massiven Ausfällen kam. In dem Fall war das schlicht ein Prozessfehler, ich will aber nicht drüber nachdenken, was ein böswilliger Akteur mit Zugriff auf Lizenzserver eines großen Anbieters an globalen Disruptionen anrichten könnte.

Neben dem Aspekt „liefert die Cloud die richtigen Daten“ wird auch immer mehr „laufen meine Systeme überhaupt noch an, wenn ich keine Netzverbindung habe“ relevant. Die Klassiker dafür sind das DNS und externe Abhängigkeiten von internen Webanwendungen. Es kann sein, dass in manchen Bereichen zirkuläre Abhängigkeiten entstanden sind, die einen Neustart nach komplettem Shutdown sehr schwierig machen. 

Da ich nur wenig Platz im Lagebild habe, wurde aus all diesen Überlegungen der folgende Text:

Lagebildbeitrag

Externe Abhängigkeiten

Am 19. Juli wurde durch ein Signaturupdate ein Bug im CrowdStrike Falcon EDR getriggert, was global zu weitreichenden IT-Störungen führte. Dazu ist festzuhalten:

• Damit AV/EDR Produkte ihre volle Funktionalität entfalten können, müssen sie unter Windows im Kernelmodus laufen. Dadurch führte der Bug zu einem Komplettausfall der betroffenen Systeme.
• Noch mehr als bei normalen Software-Updates muss bei den laufenden Aktualisierungen von Sicherheitskomponenten eine Balance zwischen schneller Wirksamkeit und sorgfältigem Testen gefunden werden. Bei kritischen Systemen müssen nicht nur neue Softwareversionen, sondern auch Konfigurationsupdates (incl. AV-Definitionen) auf Staging-Systemen getestet werden.
• Dieser Vorfall hat gezeigt, dass die Grenze zwischen einem Produkt und einer Dienstleistung verschwimmen kann. Der kommenden EU Cyber Resilience Act geht darauf ein, in dem er „remote data processing solutions“ („Datenfernverarbeitungslösungen“) als integralen Teil eines „Produkt mit digitalen Elementen“ definiert.
• Betroffene Produkte reichen von harmlos (Staubsaugeroboter für Zuhause) über heikel (fernsteuerbare Türschlösser) bis hin zu kritisch (Steuerung von Solaranlagen).
• Auch die zunehmende Online-Lizenzierung von Software bis hin zu Netzwerkkomponenten stellt eine Gefahr für die Verfügbarkeit dar. Ein Vorfall, oder auch nur ein Fehler, in einem Lizenzserver kann signifikante Folgen haben.
• Was bei Kraftwerken die „Schwarzstartfähigkeit“ ist, also die Möglichkeit ohne externe Stromquelle hochzufahren, könnte in Zukunft auch in der IT relevant werden: die Fähigkeit, auch ohne Netzzugang und Cloud-Komponenten den Betrieb aufnehmen zu können.