Wenn es um Verstöße gegen die Cybersicherheit geht, richtet sich die Aufmerksamkeit der Öffentlichkeit meist auf die Hacker – nicht auf die Softwareentwickler. Doch die Vergangenheit hat gezeigt, dass die verheerendsten Sicherheitslücken oft genau in dem Code ihren Ursprung haben, dem wir die Sicherheit unserer sensibelsten Systeme anvertrauen. Die unangenehme Wahrheit lautet: Wenn man den Quellcode nicht einsehen kann und die Integrität sowie die Herkunft der Personen, die ihn entwickelt haben, nicht überprüfen kann, kann man nicht sicher sein, dass er frei von Hintertüren ist.
Closed-Source-Software erfordert naturgemäß Vertrauen – nicht nur in den Anbieter, sondern auch in jede einzelne Person, die jemals zu ihrem Quellcode beigetragen hat. In Bereichen wie Verteidigung, Nachrichtendienste, Finanzwesen und anderen regulierten Branchen ist blindes Vertrauen nicht mehr akzeptabel. Wir brauchen strenge Richtlinien: Jeder Anbieter von Closed-Source-Software, der seine Produkte an kritische Infrastrukturen verkauft, sollte erforderlich um zu bestätigen, dass keiner ihrer Entwickler jemals für einen ausländischen Geheimdienst oder Verteidigungsdienst tätig war, insbesondere nicht im Bereich der Cybersicherheit, was es ihnen ermöglichen könnte, versteckte Sicherheitslücken einzubauen.
Das ist keine Paranoia – das ist Mustererkennung. Die Geschichte der besonders schwerwiegenden Cyberspionage ist voll von Beispielen, bei denen raffinierte Akteure Hintertüren auf eine Weise eingebaut haben, die praktisch nicht zu erkennen war, bis der Schaden bereits angerichtet war.
Fallstudie 1: Die NetScreen-/ScreenOS-Hintertür (Juniper Networks)
Ende 2015 gab Juniper Networks bekannt, dass unbefugter Code in sein Firewall-Betriebssystem ScreenOS eingeschleust worden war – jene Software, die für die Sicherheit der Netzwerke der US-Regierung, von Rüstungsunternehmen und Fortune-500-Unternehmen zuständig ist. Dabei handelte es sich nicht um einen einfachen Programmfehler. Es handelte sich um eine präzise eingefügte Modifikation des Zufallszahlengenerators „Dual_EC_DRBG“, die dem Angreifer effektiv die Möglichkeit gab, den VPN-Datenverkehr nach Belieben zu entschlüsseln.
Sicherheitsforscher kamen später zu dem Schluss, dass die plausibelste Erklärung darin bestand, dass die Hintertür absichtlich von einem hochkompetenten Geheimdienst eingebaut worden war. Der Code war Closed-Source, und die Kompromittierung blieb jahrelang unentdeckt.
Das Wichtigste auf einen Blick: Dank des geschlossenen Quellcodes war es einem gut positionierten Insider (oder ehemaligen Insider) möglich, zentrale kryptografische Funktionen so zu verändern, dass dies für die Kunden praktisch nicht zu erkennen war.
Fallstudie 2: Solarigate / Angriff auf SolarWinds Orion
Der SolarWinds-Angriff auf die Lieferkette im Jahr 2020 – auch als „Solarigate“ bezeichnet – war ein Meisterwerk der Tarnung. Die Angreifer kompromittierten das Build-System der Netzwerküberwachungsplattform Orion und schleusten eine Hintertür ein, die digital signiert war und als Teil legitimer Software-Updates verbreitet wurde. Tausende Kunden installierten diese Software, darunter das US-Heimatschutzministerium, mehrere Bundesbehörden und Rüstungsunternehmen.
Hier handelte es sich nicht um eine Aktion von „Script-Kiddies“, sondern um einen mit umfangreichen Ressourcen ausgestatteten, staatlich geförderten Angriff, der darauf abzielte, sich unauffällig in das normale Softwareverhalten einzufügen. Der Orion-Quellcode war nicht öffentlich zugänglich, der Build-Prozess undurchsichtig, und der Einfügepunkt wurde von vertrauenswürdigen Insidern kontrolliert.
Das Wichtigste auf einen Blick: Da keine offene Prüfung stattfindet, hängt die Integrität von Closed-Source-Software vollständig von der Vertrauenswürdigkeit und dem Hintergrund der Personen ab, die an der Entwicklung und der Build-Kette beteiligt sind.
Fallstudie 3: Der Rootkit-Vorfall bei JPMorgan Chase
Im Jahr 2014 erlitt JPMorgan Chase einen der größten Datenlecks in der Geschichte des US-Bankwesens, bei dem die personenbezogenen Daten von über 83 Millionen Kunden gestohlen wurden. Untersuchungen ergaben, dass die Angreifer ein hohes Maß an Persistenz erreicht hatten, indem sie Zugriff auf Rootkit-Ebene nutzten, um die Kontrolle zu behalten und einer Entdeckung zu entgehen. Der Angriff umfasste zwar mehrere Phasen und Akteure, machte jedoch deutlich, dass Angreifer, sobald sie Hooks auf niedriger Ebene implantieren können, Daten manipulieren, Transaktionen abfangen und Standard-Sicherheitskontrollen umgehen können.
Obwohl JPMorgan nicht öffentlich bestätigt hat, ob das Rootkit auf eine Infiltration der Lieferkette oder auf einen Insiderangriff zurückzuführen ist, macht der Vorfall deutlich, dass Closed-Source-Komponenten in der Bankinfrastruktur bevorzugte Ziele für heimliche, dauerhafte Manipulationen sind.
Das Wichtigste auf einen Blick: Im Finanzsektor und in regulierten Branchen kann schon eine einzige versteckte Hintertür in einem Closed-Source-Modul Investitionen in Sicherheitsmaßnahmen in Milliardenhöhe sowie jahrelange Compliance-Arbeit zunichte machen.
Enthüllte Muster:
Mehrjährige Erfassungsverzögerungen kommen häufig vor – selbst in Unternehmen mit hochmodernen SOCs.
Build-Umgebungen einrichten und Server aktualisieren sind ideale Ansatzpunkte für staatliche Akteure.
Geschlossener Quellcode verschleiert böswillige Änderungen weitaus effektiver als Open-Source-Alternativen.
Wichtige nationale Sicherheits- und Finanzsysteme werden systematisch ins Visier genommen.
Die politische Lücke: Die Herkunft der Entwickler ist eine Frage der nationalen Sicherheit
Wir verfügen über strenge Exportkontrollen im Bereich der Kryptografie, Einfuhrbeschränkungen für Telekommunikationsausrüstung aus feindlich gesinnten Staaten sowie Zertifizierungssysteme für Hardware-Lieferketten. Dennoch haben wir keine gleichwertige Schutzmaßnahme um sicherzustellen, dass die Personen, die Closed-Source-Code für kritische Infrastrukturen schreiben und kompilieren, nicht von ausländischen Geheimdiensten, die für offensive Cyberoperationen bekannt sind, ausgebildet wurden oder für diese gearbeitet haben.
Die Einheit 8200 in Israel, die Cyber-Einheiten des GRU und des SVR in Russland, die Einheit 61398 der Volksbefreiungsarmee (PLA) in China sowie weitere offensive Cyber-Einheiten weltweit verfügen über eine gut dokumentierte Geschichte der Entwicklung und des Einsatzes von Hintertüren sowohl in offenen als auch in geschlossenen Systemen. Wenn ein Anbieter einen Entwickler mit einem solchen Hintergrund einstellt – ohne das Risiko offenzulegen oder zu mindern –, haben Kunden keine Möglichkeit zu wissen, dass sie möglicherweise Code vertrauen, der von jemandem geschrieben wurde, der ausdrücklich darin geschult wurde, nicht nachweisbare Schwachstellen einzubauen.
Die kühne Behauptung: Keine Zertifizierung, keine Bereitstellung
Kritische Infrastruktur in den Bereichen Verteidigung, Nachrichtendienste und regulierte Sektoren sollte den Einsatz jeglicher Closed-Source-Software ablehnen, es sei denn, der Anbieter legt eine verbindliche Bescheinigung vor dass:
Kein Code in diesem Produkt wurde von Personen entwickelt, kompiliert oder geprüft, die jemals für einen ausländischen Geheimdienst oder eine Verteidigungsorganisation in den Bereichen Cybersicherheit, Fernmeldeaufklärung oder Netzwerkauswertung tätig waren.
Der Anbieter führt für alle Mitwirkenden an der Closed-Source-Codebasis fortlaufende Hintergrundüberprüfungen durch.
Die Software wird regelmäßig einer Integritätsprüfung auf Binärcode-Ebene durch ein unabhängiges, in den USA ansässiges Sicherheitslabor unterzogen, das über eine staatliche Sicherheitszulassung verfügt.
Hier geht es nicht um Fremdenfeindlichkeit oder Protektionismus – es geht um die betriebliche Realität. Die Vorfälle mit Hintertüren bei Juniper, SolarWinds und unzähligen anderen Unternehmen haben gezeigt, dass die Entwicklungskette eine Angriffsfläche für die nationale Sicherheit darstellt. Wir sichern bereits den physischen Zugang zu kritischen Standorten und Hardware-Lieferketten ab; es ist an der Zeit, dieselbe Strenge auch auf die Personen anzuwenden, die den Code schreiben und kompilieren, der diese Systeme steuert.
Fazit: Vertrauen, aber Herkunft nachweisen lassen
Auf dem modernen Cyber-Schlachtfeld ist die Grenze zwischen Verteidigung und Angriff fließend, und viele der weltweit besten Ingenieure haben bereits beide Rollen ausgefüllt. Bei unregulierten Verbraucher-Apps mag das ein akzeptables Risiko sein. Bei Software jedoch, die Nuklear-Kommandosysteme, Verteidigungssatelliten, Finanzclearingstellen und die Flugsicherung steuert? Da ist das nicht der Fall.
Closed-Source-Software ist eine Black Box – und die Geschichte hat gezeigt, dass sich hinter Black Boxes sehr scharfe Messer verbergen können. Solange wir keine nachprüfbare Gewissheit darüber einfordern, wer den Code entwickelt hat, ist jede Bereitstellung ein Akt des blinden Vertrauens. Bei kritischer Infrastruktur ist blindes Vertrauen keine Sicherheitsstrategie.