Wenn es um Cybersicherheitsverletzungen geht, richtet sich die öffentliche Aufmerksamkeit meist auf die Hacker – nicht auf die Softwareentwickler. Doch die Geschichte hat gezeigt, dass die verheerendsten Sicherheitsverletzungen oft ihren Ursprung in genau dem Code haben, dem wir die Sicherheit unserer sensibelsten Systeme anvertrauen. Die unangenehme Wahrheit lautet: Wenn Sie den Quellcode nicht einsehen und die Integrität und Herkunft der Entwickler nicht überprüfen können, können Sie nicht sicher sein, dass er frei von Hintertüren ist.
Closed-Source-Software erfordert naturgemäß Vertrauen – nicht nur in den Anbieter, sondern in jeden Einzelnen, der jemals zu ihrem Code beigetragen hat. In Sektoren wie Verteidigung, Geheimdiensten, Finanzen und anderen regulierten Branchen ist blindes Vertrauen nicht mehr akzeptabel. Wir brauchen eine strenge Politik: Jeder Anbieter von Closed-Source-Software, der in kritische Infrastrukturen verkauft, sollte falls angefordert um zu bestätigen, dass keiner ihrer Entwickler jemals für einen ausländischen Geheim- oder Verteidigungsdienst gearbeitet hat, insbesondere nicht im Bereich der Cybersicherheit, was es ihnen ermöglichen könnte, versteckte Schwachstellen zu implantieren.
Das ist keine Paranoia, sondern Mustererkennung. Die Geschichte der Cyber-Spionage mit schwerwiegenden Folgen ist voll von Beispielen, bei denen raffinierte Akteure Hintertüren auf eine Art und Weise einführten, die praktisch nicht erkennbar war, bis der Schaden bereits angerichtet war.
-------
Fallstudie 1: Die NetScreen/ScreenOS-Hintertür (Juniper Networks)
Ende 2015 gab Juniper Networks bekannt, dass unautorisierter Code in sein Firewall-Betriebssystem ScreenOS eingeschleust worden war – die Software, die für die Sicherung der Netzwerke der US-Regierung, von Rüstungsunternehmen und Fortune-500-Unternehmen zuständig ist. Dabei handelte es sich nicht um einen schlampigen Fehler. Es handelte sich um eine gezielt eingeschleuste Modifikation des Zufallszahlengenerators Dual_EC_DRBG, die es Angreifern ermöglichte, VPN-Verkehr nach Belieben zu entschlüsseln.
Sicherheitsforscher kamen später zu dem Schluss, dass die plausibelste Erklärung darin bestehe, dass die Hintertür absichtlich von einem hochqualifizierten Geheimdienst hinzugefügt wurde. Der Code war Closed Source, und die Kompromittierung blieb jahrelang unentdeckt.
Key zum Mitnehmen: Durch den Closed-Source-Code konnte ein Insider (oder Ex-Insider) in einer guten Position zentrale kryptografische Funktionen ändern, die für Kunden praktisch unmöglich zu erkennen waren.
-------
Fallstudie 2: Solarigate / SolarWinds Orion-Kompromittierung
Der Angriff auf die Lieferkette von SolarWinds im Jahr 2020 – genannt „Solarigate“ – war ein Meisterstück der Tarnung. Angreifer kompromittierten das Build-System der Netzwerküberwachungsplattform Orion und schleusten eine digital signierte Hintertür ein, die als Teil legitimer Software-Updates verteilt wurde. Tausende Kunden installierten die Hintertür, darunter das US-Heimatschutzministerium, mehrere Bundesbehörden und Rüstungsunternehmen.
Dies war keine Script-Kiddie-Operation; es handelte sich um einen staatlich geförderten Angriff mit hohen Ressourcen, der so konzipiert war, dass er sich in das normale Verhalten der Software einfügte. Die Orion-Codebasis war geschlossen, der Build-Prozess undurchsichtig und der Einfügepunkt wurde von vertrauenswürdigen Insidern kontrolliert.
Key zum Mitnehmen: In Ermangelung offener Audits hängt die Integrität von Closed-Source-Software vollständig von der Vertrauenswürdigkeit und dem Hintergrund der Personen in der Entwicklungs- und Build-Kette ab.
-------
Fallstudie 3: Rootkit-Vorfall bei JPMorgan Chase
Im Jahr 2014 erlitt JPMorgan Chase einen der größten Datendiebstähle in der US-Bankengeschichte. Dabei wurden die persönlichen Daten von über 83 Millionen Kunden gestohlen. Untersuchungen ergaben, dass die Angreifer sich tiefgreifend in das System eingeschlichen hatten und Rootkit-Zugriffe nutzten, um die Kontrolle zu behalten und unentdeckt zu bleiben. Obwohl der Angriff mehrere Phasen und Akteure umfasste, zeigte er, dass Angreifer, sobald sie einfache Angriffspunkte einschleusen, Daten manipulieren, Transaktionen abfangen und Standardsicherheitskontrollen umgehen können.
Obwohl JPMorgan nicht öffentlich bestätigt hat, ob das Rootkit aus einer Infiltration der Lieferkette oder einem Insider-Angriff stammt, unterstreicht der Vorfall, dass Closed-Source-Komponenten in der Bankinfrastruktur ein Hauptziel für heimliche, anhaltende Modifikationen sind.
Key zum Mitnehmen: Im Finanzwesen und in regulierten Branchen kann eine einzige versteckte Hintertür in einem Closed-Source-Modul Milliarden von Dollar zunichtemachen, die in Sicherheitsvorkehrungen und jahrelange Compliance-Arbeit investiert wurden.
-------
Beweisblock: Historische Closed-Source-Backdoor-Vorfälle in kritischen Systemen
Aufgedeckte Muster:
Mehrjährige Verzögerungen bei der Erkennung sind weit verbreitet – selbst in Organisationen mit fortschrittlichen SOCs.
Erstellen Sie Umgebungen und aktualisieren Sie Server sind wichtige Angriffspunkte für nationalstaatliche Akteure.
Closed-Source-Code maskiert bösartige Änderungen weitaus effektiver als Open-Source-Äquivalente.
Hochwertige nationale Sicherheits- und Finanzsysteme werden konsequent gezielt.
-------
Die politische Lücke: Die Herkunft der Entwickler ist ein Problem der nationalen Sicherheit
Wir haben strenge Exportkontrollen für Kryptographie, Importbeschränkungen für Telekommunikationsausrüstung aus gegnerischen Ländern und Zertifizierungssysteme für Hardware-Lieferketten. Dennoch haben wir keine gleichwertige Absicherung um sicherzustellen, dass die Menschen, die den Closed-Source-Code für kritische Infrastrukturen schreiben und kompilieren, nicht von ausländischen Geheimdiensten ausgebildet wurden oder für diese gearbeitet haben, die für offensive Cyberoperationen bekannt sind.
Die Einheit 8200 in Israel, die Cyber-Einheiten GRU und SVR in Russland, die PLA-Einheit 61398 in China und andere offensive Cyber-Abteilungen weltweit haben eine gut dokumentierte Geschichte der Entwicklung und Bereitstellung von Hintertüren in offenen und geschlossenen Systemen. Stellt ein Anbieter einen Entwickler mit einem solchen Hintergrund ein – ohne das Risiko offenzulegen oder zu mindern – können Kunden nicht wissen, ob sie möglicherweise Code vertrauen, der von jemandem geschrieben wurde, der explizit darauf trainiert wurde, nicht erkennbare Schwachstellen einzubauen.
-------
Die kühne Behauptung: Keine Zertifizierung, kein Einsatz
Kritische Infrastrukturen in den Bereichen Verteidigung, Geheimdienst und regulierte Sektoren sollten Weigern Sie sich, Closed-Source-Software bereitzustellen, es sei denn, der Anbieter stellt eine verbindliche Zertifizierung bereit dass:
Kein Code im Produkt wurde von jemandem entwickelt, kompiliert oder überprüft, der jemals für eine ausländische Geheimdienst- oder Verteidigungsorganisation in den Bereichen Cybersicherheit, Signalaufklärung oder Netzwerkausnutzung gearbeitet hat.
Der Anbieter führt eine kontinuierliche Hintergrundprüfung aller Mitwirkenden an der Closed-Source-Codebasis durch.
Die Software wird regelmäßig von einem unabhängigen, in den USA ansässigen Sicherheitslabor mit behördlicher Zulassung auf Binärebene einer Integritätsprüfung unterzogen.
Es geht nicht um Fremdenfeindlichkeit oder Protektionismus – es geht um die betriebliche Realität. Die Backdoor-Vorfälle bei Juniper, SolarWinds und unzähligen anderen Unternehmen haben gezeigt, dass die Entwicklungskette eine Angriffsfläche für die nationale Sicherheit darstellt. Wir sperren bereits den physischen Zugang zu kritischen Standorten und Hardware-Lieferketten; es ist an der Zeit, die gleiche Strenge auch auf die Menschen anzuwenden, die den Code für diese Systeme schreiben und kompilieren.
-------
Fazit: Vertrauen, aber Herkunft verlangen
Auf dem modernen Cyber-Schlachtfeld ist die Grenze zwischen Verteidigung und Angriff schmal, und viele der weltbesten Ingenieure haben beide Rollen innegehabt. Für unregulierte Verbraucher-Apps ist das vielleicht ein akzeptables Risiko. Für die Software, die nukleare Kommandosysteme, Verteidigungssatelliten, Finanzclearinghäuser und die Flugsicherung steuert? Nicht.
Closed-Source-Software ist eine Blackbox – und die Geschichte hat gezeigt, dass sich in Blackboxen sehr scharfe Messer verbergen können. Solange wir keine überprüfbare Gewissheit darüber verlangen, wer den Code erstellt hat, ist jede Bereitstellung ein Akt blinden Vertrauens. Für kritische Infrastrukturen ist blindes Vertrauen keine Sicherheitsstrategie.
