IT-Sicherheit : Symptom oder Ursache? Was uns der Crowdstrike-Fall lehrt

Er ist ein moderner Klassiker der IT: Der Windows-Bluescreen versetzt uns bereits seit Windows 3.11 in Angst und Schrecken – auch wenn er am Anfang vielleicht noch gar nicht blau war. Wie schaffen wir es, ihm zu entgehen? Wie erreichen wir also Sicherheit, wie stärken wir die Resilienz? In meinen Ausführungen über die nicht mehr ganz so neuen Zero-Trust-Prinzipien zog ich eine Analogie zu Bunkerräumen, in denen nicht vertrauenswürdige Software „explodieren“ kann, ohne dass Schäden am Gebäude und den durch die Betonwände geschützten, lebenswichtigen Strukturen entstehen. So weit, so gut.

Allerdings stellt dieses Konzept für Betriebssystem-Kernel ein grundsätzliches Problem dar, denn sie bringen alle lebenswichtigen Funktionen eines Computers in nur einem Raum unter. Dieser Raum enthält in der Regel eine Menge Code – und ist meist so konstruiert, dass während der Laufzeit sogar noch weiterer Code nachgeladen werden kann. Wie sicher kann ein solcher Raum wirklich sein?

Das „Legacy“-Problem: Warum etwas ändern, das (meist) funktioniert?

Ich muss zugeben: Windows wird immer besser darin, sichere Zonen auf Kernel-Ebene bereitzustellen. Konzepte wie Trusted Computing und „Virtualization Based Security“ (VBS) sind der richtige Weg. Dennoch: Das schwierige Erbe eines monolithischen Systemdesigns bleibt. Und wir haben für den Moment schlichtweg keine andere Wahl. Zu meinem Artikel über Zero Trust ließe sich sinngemäß ergänzen: Auch wenn unsere Feuermelder uns für einige Tage aus unseren Holzgebäuden ausgesperrt haben, müssen wir jetzt wieder in sie einziehen, da wir keine anderen Gebäude haben.

Ein anderes Argument im Kontext des Crowdstrike-Vorfalls hieß „Monokultur“ – nennen wir es aber lieber „Legacy“ oder auch: „Never change a running system“. In Zahlen ausgedrückt haben wir nämlich im Vergleich zu Windows ungefähr dieselbe Anzahl von iOS-Geräten – rund 1,3 Milliarden – und mehr als doppelt so viele Android-Geräte im Einsatz. Natürlich sorgen wir uns auch um deren Monokulturen. Allerdings sind die geschlossenen Systeme grundsätzlich weniger anfällig für Probleme wie den jüngsten Vorfall. Das macht sie aus architektonischer Perspektive nicht sicherer, doch haben sie zumindest ein sehr strenges Modell für die kontrollierte Ausführung von Drittanbietercode. Niemand kann einfach so einen Kernel-Treiber in iOS laden. Das geht nur nach einem Jailbreak – und davon ist genau aus diesem Grund abzuraten.

Alles eine Frage des Vertrauens

Im Gegensatz dazu ist ein offenes Ökosystem aus Hardware, Betriebssystem und Treibern verschiedener Anbieter strukturell viel anfälliger und macht es schwieriger, ein starkes Sicherheitsmodell auf Hardware- und Betriebssystemebene zu etablieren.

Zudem verlangt Windows nicht nur von uns, Microsoft zu vertrauen. Vielmehr dehnt das Konzept der „Kernel-Treiber“ im offenen PC-Ökosystem dieses Vertrauensmodell auf jeden Drittanbieter aus, dem Microsoft vertraut, indem es seine Treiber signiert. Wenn dann der Signierschlüssel verloren geht, gibt es ein echtes Problem.

Es existiert hier keine strenge Kontrolle darüber, welcher Code mit Kernel-Rechten ausgeführt wird – so ist es nur eine Frage der Zeit, bis etwas passiert. Und: Wir reden dabei nur von zufälligen Fehlern, die das Fundament des Gebäudes wegpusten können. Was ist mit böswilligen Angreifern, die diesen Weg nutzen, um ihren Angriffscode mit den höchsten Privilegien auszuführen?

Glücklicherweise haben wir wunderbare Cybersecurity-Tools, die kontinuierlich nach Angriffsmustern suchen. Die Herausforderung ist, dass die Informationen über Angriffsmuster unbedingt auf dem neuesten Stand gehalten werden müssen – daraus konnten Firmen wie Crowdstrike ein riesiges Geschäft machen. Ihr Versprechen: Sich ausbreitende Angriffe können in einem recht frühen Stadium erkannt und begrenzt werden. Dies ist übrigens das Versprechen vieler Cybersecurity-Unternehmen, nicht nur das von Crowdstrike.

Die Voraussetzung dafür ist jedoch ein in Echtzeit aktualisiertes Überwachungs- und Erkennungsnetz von KI-basierten Software-Agents – und das auf hoffentlich jedem IT-System der Welt. Naturgemäß benötigen sie alle Kernel-Privilegien, um alles zu sehen, was sie sehen müssen: anomales Verhalten von Anwendungen, verdächtige Aktivitäten auf Speicherstrukturen und so weiter. Unter Sicherheitsaspekten klingen aber Echtzeit-Update und Kernel-Privilegien nach einem „Setup to fail“, oder nicht?

Es muss nicht alles beim Alten bleiben

Wie wir gesehen haben, führt das Legacy-Problem dazu, dass es keinen schnellen Ausweg aus dieser Misere gibt. Dennoch können wir versuchen, uns daraus zu befreien. Wir halten fest: Eine gute Sicherheitsschicht kann nicht für alles offen sein und muss eher statisch aufgebaut sein. In einer Welt der monolithischen Betriebssysteme führt dies zu einem ziemlich großen Hardware-/Software-Stack, der sehr streng kontrolliert werden muss. Aber es ist durchaus möglich, damit mehr zu erreichen als mit Standard-Windows plus Cybersecurity-Tools.

Wird alles besser, wenn wir konsequent auf Open Source setzen? Einige Evangelisten machen das Closed-Source-Universum von Microsoft für das jüngste Desaster verantwortlich. Nun, auch ich bin Open-Source-Enthusiast, und es gibt immer gute Argumente dafür – dazu gleich mehr. Doch bei den Ausfällen, um die es hier geht, haben wir es mehr mit einer Frage der Systemarchitektur und des Ökosystemdesigns zu tun. Die Probleme des Ökosystems haben wir bereits diskutiert. Schauen wir uns nun die Sicherheitsarchitektur an.

Rettet Linux die Welt?

Ganz so einfach ist es dann eben doch nicht: Konzeptionell ist der Linux-Kernel unter Sicherheitsaspekten ehrlich gesagt nicht viel besser. Es handelt sich dabei ebenfalls um einen riesigen monolithischen Kernel, in den einige Millionen Codezeilen einkompiliert sind. Nicht einmal signierte Treiber sind Standard. Schlimmer noch, ein Konzept namens eBPF erlauben es, beliebigen Code von Drittanbietern im Kernelmodus auszuführen – um der Effizienz willen. Wie ich aber lese, sind eBPF-Programme „daraufhin verifiziert, dass sie den Kernel nicht zum Absturz bringen“ – hoffentlich klappt das besser als letztens bei Crowdstrike.

Die Realität ist komplizierter

Gerade sind wir schon einer weiteren „Nicht-Lehre“ aus Jahrzehnten der Sicherheitstechnologie begegnet: Effizienz gewinnt. Wer „Security by Design“ will, muss von Grund auf neu konzipieren: Hardware, Betriebssystem, die gesamte Systemarchitektur. Dem entgegen stehen das Legacy-Problem und das Diktat der Effizienz. Es ist schlicht einfacher und aus geschäftlicher Sicht vielversprechender, Linux und Windows zu verwenden. Außerhalb des akademischen und stark regulierten Umfelds (zum Beispiel in der Luftfahrt) baut fast niemand seine eigenen Betriebssysteme oder verwendet besser konzipierte Architekturen wie zum Beispiel Mikrokerne.

Linux und Open Source ermöglichen es uns überhaupt erst, ein besser kontrollierbares, sichereres System mit zusätzlichen Sicherheitsschichten zu bauen. Wir können Systeme schaffen, die die Verwendung von potenziell gefährlichen Konzepten wie eBPF nicht zulassen, mit einem sehr begrenzten, streng kontrollierten Satz von Treibern, mit einer Gesamtarchitektur, die auf dem „Least Privilege“-Prinzip aufbaut, ohne die Möglichkeit, einen Agent im Kernel-Modus laufen zu lassen. Kurzum wäre das ein weniger verwundbares Fundament und ein Bunkerraum obendrauf. In diesem Bunker kann dann das gesamte Windows laufen.

Trotzdem: Der Linux-Kernel ist immer noch zu groß für wirklich kritische Anwendungen. Ein einziger Raum im Fundament eines solchen kritischen Gebäudes – selbst wenn er gehärtet ist – ist einfach zu riesig. Es gibt resilientere Strukturen: Mikrokerne oder Separationskerne sind bekannte Konzepte aus den siebziger Jahren des letzten Jahrhunderts. Sie erfordern mehr Aufwand, sind weniger effizient und haben einige Einschränkungen. Aber in solch einer Architektur kann das System nicht durch einen einfachen Null Pointer weggepustet werden. Das ist echte „Security by Design”.

Nun bleibt immer noch das Legacy-Problem: So sehr wir es uns auch wünschen mögen, können wir die Altlasten da draußen nicht leugnen. Wir können sie nur einhegen und hart an der Migration zu neuen, resilienteren Architekturen arbeiten. Diese „Einhegung“ kann zum Beispiel durch die Virtualisierung von Windows erreicht werden, das dann seinen eigenen Bunkerraum in einer virtuellen Maschine (VM) erhält.

Der Grundstein für Resilienz ist gelegt

Wird uns Windows noch lange begleiten? Ich wette, dass Microsoft bereits aktiv an der Abschaffung von Windows arbeitet – mit dem Ziel, alles in die Cloud zu verlagern, zu SaaS, zu webbasierten Anwendungen, die auf Microservice-Architekturen aufbauen.

Werden wir dann automatisch mehr Resilienz haben? Nun, ich bin sehr skeptisch, wenn wir uns allein die Azure-Ausfälle und die Schlüsselverluste der letzten Zeit anschauen. Auch Cloud-Infrastrukturen müssen aus ihren Monokulturen befreit werden. An dieser Stelle können wir aber festhalten, dass wir technisch gesehen alle Bausteine für mehr Resilienz haben: Mikrokerne, Thin(ner) Clients, hochredundante Netzwerke, virtualisierte Legacy-Systeme, Cloud-Technologie, eine potenziell größere Angebotsvielfalt auf dem Markt auf der Basis von Open Source und offenen Standards. Das klingt zunächst wie ein Traumland. Aber Albträume wie der jüngste werden uns weiterhin verfolgen, wenn wir nicht aktiv daran arbeiten, dieses Traumland Realität werden zu lassen.

Kai Martius ist Chief Technology Officer der Secunet Security Networks AG.