Gerald Boyne ist IT-Security-Architekt und -Berater mit langjähriger Erfahrung in der Modernisierung komplexer IT-Landschaften. Er begleitet mittlere und große Unternehmen bei Fragen rund um Cloud-Migration, Sicherheitsarchitektur und Lieferantenmanagement – stets mit Blick auf das Zusammenspiel von Technologie, Regulierung und geopolitischem Risiko. Zuvor war er mehrere Jahre bei AWS tätig und kennt daher die Perspektive eines führenden Hyperscalers aus erster Hand.
Seit der Wiederwahl Donald Trumps wird auf Social Media häufig ein Szenario durchgespielt, in welchem die USA gezielt Software in Europa abschalten. Können die USA etwa das F35-Kampfflugzeug abschalten, auch wenn er eigentlich den Niederlanden gehört? Gerald und ich haben uns der Frage gewidmet, wie gängig solche Abschaltvorrichtungen sind und wie gut sie in klassischer Software erkannt werden können.
Gregor: Was ist ein Kill Switch?
Gerald: Ein Kill Switch ist eine eingebaute Möglichkeit, Software gezielt außer Betrieb zu setzen – entweder automatisiert, etwa über ein Datum im Code, oder manuell, zum Beispiel durch ein Signal vom Hersteller. Die Idee dahinter – ein Notausschalter, der in der Hand des Herstellers liegt: Bestimmte Bedingungen führen dazu, dass eine Software nicht mehr funktioniert, selbst wenn sie lokal korrekt installiert ist. Stell dir vor, ein DNS-Server startet ab einem bestimmten Tag einfach nicht mehr – das wäre ein klarer Fall.
„Ein Kill Switch ist der Notausschalter in der Hand des Herstellers – und damit immer auch ein Machtinstrument.“
Gregor: Welche Arten von Kill Switches gibt es?
Gerald: Im Wesentlichen begegnen uns drei Varianten. Die häufigste ist die Lizenzprüfung über einen Server: Die Software schaut regelmäßig nach, ob sie noch verwendet werden darf. Ist das nicht der Fall – etwa weil der Vertrag ausgelaufen ist oder keine Verbindung mehr besteht – schaltet sie sich ab.
Daneben gibt es sogenannte Feature Toggles. Dabei wird Software ausgeliefert, deren Funktionen zunächst deaktiviert sind und erst bei Bedarf oder nach externem Befehl freigeschaltet werden. Das ist zwar vor allem fürs Produktmanagement gedacht, kann aber genauso gut zum Sperren von Funktionen genutzt werden.
Und schließlich gibt es – deutlich seltener, aber besonders heikel – die Fälle, in denen Geräte oder Software gezielt aus der Ferne abgeschaltet werden. Ein bekanntes Beispiel: Traktoren eines US-Herstellers, die nach Beginn des Ukrainekriegs deaktiviert wurden, sie wurden in der Ukraine gestohlen und als Kriegsbeute nach Russland verbracht. Das zeigt, wie technisch und politisch ein Kill Switch ineinandergreifen können.
Gregor: Wie geläufig sind denn diese Switches?
Gerald: Lizenzbasierte Abschaltungen sind quasi Alltag – die finden sich in unzähligen Produkten, ohne dass man sie groß hinterfragt. Feature Toggles sind vor allem im SaaS-Cloud-Umfeld sehr verbreitet, weil sie Flexibilität im Rollout ermöglichen – technisch aber ebenfalls ein Mittel zur Kontrolle.
Wirklich gefährlich wird es bei den versteckten Mechanismen: zeitgesteuert, abhängig von Signalen oder durch gezielte Remote-Aktionen. Die sind schwer zu entdecken, aber sie existieren – wie der XZ-Backdoor-Fall gezeigt hat. Und genau diese Kombination aus Unsichtbarkeit und Kontrolle macht sie so riskant. Denn letztlich geht es dabei nicht nur um Technik, sondern um Macht über Systeme.
„Das Beispiel der deaktivierten Traktoren im Ukrainekrieg zeigt, wie eng Technik und Geopolitik bei Kill Switches verknüpft sind.“
Gregor: Kann man solche Abschaltmöglichkeiten in Open Source Software erkennen?
Gerald: In der Theorie ist Open Source ja für jeden überprüfbar – der Quellcode liegt offen, also könnte man Schwachstellen wie Kill Switches entdecken. Aber die Praxis sieht anders aus: Kaum jemand schaut wirklich tief in den Code. Gerade bei stark verbreiteten, aber wenig beachteten Komponenten fehlt oft jede systematische und dokumentierte Qualitätssicherung.
Ein gutes Beispiel dafür ist Log4j. Die Schwachstelle darin war jahrelang öffentlich, aber niemand hat sie bemerkt – obwohl das Logging-Framework in unzähligen Systemen weltweit eingesetzt wurde. Dass der Fehler schließlich auffiel, war Zufall und reines Glück.
Der Fall zeigt: Open Source ist nicht automatisch sicher, nur weil sie quell-offen ist. Sicherheit entsteht erst, wenn sich auch tatsächlich jemand darum kümmert – gezielt, regelmäßig und mit den richtigen Mitteln.
Gregor: Wie sieht die Best Practice bei der Qualitätssicherung von Open Source aus?
Gregor: Best Practices sieht man vor allem bei großen Playern wie Microsoft: Die ziehen Open-Source-Komponenten nicht direkt aus dem Netz, sondern prüfen, härten und integrieren sie erst nach klaren internen Standards. So minimiert man Risiken wie versteckte Kill Switches.
Viele kleinere Organisationen haben dafür weder Prozesse noch Ressourcen. Und genau hier leistet die Sovereign Tech Agency wertvolle Arbeit: Sie unterstützt dabei, Open Source sicher und souverän einzusetzen. Das ist ein wichtiger Beitrag zur digitalen Souveränität und zur Absicherung unserer Infrastruktur.
„Closed Source lässt Kill Switches im Dunkeln – erkennbar ist nur das Verhalten der Software, nicht ihr Inneres.“
Gregor: Wie sieht es mit Closed-Source-Software aus … kann man Kill-Switches in irgendeiner Variante erkennen?
Gerald: Nein, nicht direkt. Closed Source heißt: Kein Zugriff auf den Quellcode – also kannst du nicht überprüfen, ob irgendwo ein Kill Switch eingebaut ist. Was du aber tun kannst, ist dir das Verhalten der Software anschauen: Kommuniziert sie nach außen? Holt sie sich regelmäßig Updates? Gibt es Remote-Zugänge? Das sind alles potenzielle Pfade, über die ein Kill Switch ausgelöst werden könnte – etwa durch ein manipuliertes Update oder einen Steuerbefehl von außen.
Große Organisationen gehen deshalb dazu über, Updates zuerst über eine Quarantänestation laufen zu lassen. Da wird geprüft, was sich verändert, bevor es ins Produktivsystem geht. Das ist aufwendig, aber notwendig, wenn man Kontrolle behalten will. Im Mittelstand ist das allerdings kaum verbreitet – da laufen viele Prozesse auf Vertrauen.
Gregor: Wenn ich die Kill-Switches in Closed Source kaum erkennen kann … was kann ich denn überhaupt tun?
Gerald: Du musst in Szenarien denken – und daraus deine Architektur ableiten. Wenn du nicht verhindern kannst, dass ein einzelnes System ausfällt, dann sorge dafür, dass es nicht alleine ausreicht, um den Betrieb zu stören. Mein Vater hat früher an der Sicherheit von Kernkraftwerken gearbeitet. Dort galt: Wenn du zwei Sensoren brauchst, nimm nicht zwei vom gleichen Hersteller. Nimm unterschiedliche Technologien, unterschiedliche Lieferanten. Dann hast du echte Redundanz – aber nicht den gleichen Fehler zweimal.
„Architektur muss Szenarien mitdenken: Redundanz heißt unterschiedliche Technologien, nicht zweimal derselbe Anbieter.“
Das gleiche Prinzip gilt für IT: Wenn du alles auf eine Plattform, einen Anbieter oder eine Updatequelle setzt, dann hast du einen Single Point of Failure. Besser ist es, Systeme so aufzubauen, dass sie in unterschiedlichen Szenarien unterschiedlich reagieren – also zum Beispiel Multi-Cloud, unterschiedliche Hersteller, getrennte Updatepfade. So wird’s unwahrscheinlicher, dass dich ein Kill Switch – ob absichtlich oder nicht – komplett lahmlegt. Absolute Sicherheit gibt es nicht, aber strukturierte Heterogenität erhöht deine Handlungsfähigkeit enorm.
Gregor: Die Kill-Switch-Frage kommt ja häufig auf im Kontext der Debatte zur digitalen Souveränität. Wie bewertest du die Situation aus Deiner Sicht?
Gerald: Die Kill-Switch-Frage ist ein gutes Beispiel dafür, warum digitale Souveränität so wichtig ist. Es geht darum, in kritischen Szenarien handlungsfähig zu bleiben – egal ob durch politische Entscheidungen, technische Fehler oder gezielte Angriffe.
Das Problem ist nicht nur Abhängigkeit von US-Anbietern, sondern auch, dass wir oft zu wenig in IT-Sicherheit und robuste Strukturen investieren. Souveränität heißt nicht, alles selbst zu bauen, sondern Systeme so aufzustellen, dass kein einzelner Ausfall alles lahmlegt.
Heterogenität, gute Steuerung und unabhängige Prüfstrukturen sind dafür entscheidend.
Gregor: Gerald, vielen Dank für Deine Zeit!
