Sicherheit von Open Source

Vorschläge für die Absicherung von Projekten durch einen Fond

Dr. Thomas Fricke

Im Auftrag des Prototype Fund

Version: 0.9, 8. September 2021

Lizenz: Creative Commons Lizenz CC BY-SA 3.0 DE

Über den Autor

Dr. Thomas Fricke

Vortrag

Das Thema habe ich auf der RC3 erzählen dürfen:

10 Mio€ für Open Source - jedes Jahr

Zusammenfassung für die Entscheidung

Open Source ist ein wichtiger Wirtschaftsfaktor und trägt zu Milliarden Wertschöpfung pro Jahr bei. Es gibt zahlreiche Projekte, die in sicherheitsrelevanten Bereichen eingesetzt werden. Diese Initiativen benötigen Unterstützung im Bereich der Automatisierung von Prozessen und modernen, sicheren Verfahren.

Die Communities sind sehr sicherheitsbewusst und liefern auf einem stabilen Niveau sichere Open Source Pakete. Allerdings sind aufwändigere Methode der Absicherung von Softwareprozessen nicht Standard, weil in den Projekten nicht genug personelle Ressourcen zur Verfügung stehen. Manchmal arbeiten die Communities am Rande ihrer Leistungsfähigkeit. Um abgesicherte Prozesse zu implementieren wird eine Unterstützung durch einen Fond im Bereich 15-30 Millionen € / Jahr vorgeschlagen. Ziel muss eine weitestgehend automatische Analyse und Installation der Software sein. Dem gegenüber stehen Risiken für potentielle Schäden im hohen Milliardenbereich.

Die vorgeschlagenen Projekte sind wichtig für industrielle Anwendung aus dem Bereich Clouds, Gaia-X, Maschinelles Lernen und die Weiterentwicklung des Einsatzes. Hinzu kommen Reallabore für zukünftige Sicherheitstechnologien im Energie- und Industriebereich, um moderne Sicherheitsparadigmen zum Standard zu erheben.

Zum Umgang mit Sicherheitslücken wird eine verantwortungsvolle Offenlegung vorgeschlagen. Der Fond sollte von technisch erfahrenen, in der Community anerkannten Personen geführt werden, um Akzeptanz zu erreichen.

Das Dokument geht auf nach Ansicht des Autors wichtige Beispiele ein. Es stellt keine repräsentative Analyse dar und beruht auf der persönlichen Erfahrung der letzten Jahrzehnte. Es gibt viel mehr Projekte, die eine Erwähnung verdienen.

Wirtschaftliche Bedeutung von Open Source

Die wirtschaftliche Bedeutung von Open Source beträgt 65-95 Milliarden Euro im Jahr 2018, wie die Ergebnisse der Open Source Impact Study¹ zeigen. Der Einsatz zieht sich durch alle Bereiche des wirtschaftlichen Lebens, von privaten Mobiltelefonen², Routern³, Fernsehern⁴, Fahrzeugen⁵, Telekommunikationsinfrastruktur⁶, bis zu Industrieanlagen mit tausenden von Seiten⁷ für die Software Inventarliste in der BOM⁸. Die Bedeutung geht soweit, dass für die automatisierte Erfassung aller Komponenten u.a. von Bosch und Siemens spezialisierte Open Source Produkte mitentwickelt werden, die die automatische Erstellung von BOMs aus dem Source Code erlauben⁹. Darüber hinaus gibt es bei Bosch, BMW, Daimler und Siemens eigene Gruppen, die an der Normierung von Open Source Compliance im Rahmen des Open Chain Projekts an der ISO 5230¹⁰ mitwirken. Der Anteil von Software an der Wertschöpfung im Auto wird bereits in wenigen Jahren auf 60% geschätzt¹¹.

Für den Einsatz in Behörden und die Weiterentwicklung von Open Source durch die öffentliche Hand sind die grundsätzlichen Fragen bereits geklärt.¹² Viele der diskutierten Aspekte treffen auch auf die Wirtschaft zu.

Sicherheit von Open Source vs Closed Source Produkten

Mit der Annahme, dass nur genug Augen auf den Code schauen müssen, um alle Bugs an die Oberfläche zu bringen, auch Linus's law¹³ genannt, wird in der Sicherheitsdebatte für FOSS argumentiert. Er sagt aber weder, wie viele Augen, noch wie oft sie auf den Code schauen sollen.

Im Gegensatz dazu bedeutet closed source auch nicht, dass der binäre Code nicht gelesen werden kann. Es gibt entsprechende Tools¹⁴ und entsprechend im Reverse Engineering¹⁵ erfahrene Software Ingenieure, die mit ihrer Hilfe in der Lage sind, auch Binär Code zu lesen, selbst Chips¹⁶ lassen sich mit entsprechendem Aufwand analysieren. Ist in diesen Systemen z.B. ein globaler Schlüssel¹⁷ enthalten, verbreitet sich dieses Wissen im Internet sehr schnell und ganze Gruppen von Systemen sind auf einen Schlag diskreditiert und werden nach sehr kurzer Zeit massiv angegriffen¹⁸. Die Sicherheitslücken werden spätestens beim Patch bekannt und die Angriffe beginnen innerhalb eines Tages¹⁹.

All das zeigt, dass Security by Obscurity²⁰, Sicherheit durch Unklarheit, keine Strategie ist, um Systeme abzusichern und lediglich den Aufwand erhöht, um ein geschlossenes System zu diskreditieren. Dies ist im Grundsatz seit dem 19 Jahrhundert bekannt²¹. Auch der völlig unzureichende Updateprozess in Komponenten der Medizin-Telematik²² zeigt, dass sich unter solchen Umständen die Anzahl und Kritikalität an bekannten Sicherheitslücken für ein Gerät im Laufe der Zeit schwerwiegende Auswirkungen haben kann.

Hersteller Support für langlebige Wirtschaftsgüter

Bei Komponenten mit schon abgelaufenen oder ablaufenden Herstellersupport informiert der Hersteller nicht mehr über neue Schwachstellen, selbst wenn diese bekannt werden (sogenannte “End-of-Life”-Komponenten). Deswegen ist es essentiell für Betreiber, für alle eingesetzten Komponenten zu überwachen, ob für diese noch Hersteller Support angeboten wird.

Der Sicherheitsstatus der Komponente ist ohne Support unbekannt und eine “Worst-Case-Annahme” ist geboten. Der Betreiber hat nun die Verantwortung, Maßnahmen zu treffen, so dass Sicherheitslücken in den Komponenten nicht ausgenutzt werden können. Beispielsweise kann dies durch Zugangsbeschränkungen mit Netzwerksegmentierung oder zusätzlicher Autorisierungs- und Authentifizierungsfunktionen in Jump-Hosts ermöglicht werden. Weitere Maßnahmen werden u.a. im BSI-Grundschutz-Kompendium beschrieben²³.

Das Problem der End-of-Life-Komponenten kann im Bereich Open Source umgangen werden. So werden, um klassische Betriebssysteme wie VAX/VMS oder Solaris weiter zu betreiben, OpenVMS²⁴ und OpenSolaris²⁵ von einer Community schon jahrelang mit Upgrades und neuen Features versorgt.

Cloud Anbieter zeigen hier einen Trend auf, da diese bei sicherheitsrelevanten Komponenten wie Betriebssystemen, Libraries, Cloud²⁶, Netzwerkkomponenten²⁷ und auch Standard Hardware²⁸ schon seit längerem vorrangig auf Open Source setzen. Dadurch erreicht man Unabhängigkeit von der zu Grunde liegenden Hardware und des Herstellers.

Das Beispiel Python

Am Beispiel von Python kann sehr gut diskutiert werden, welche Sicherheitsanforderungen an eine Community Software gestellt wird und wie sich Sicherheitslücken auswirken. Python ist eine Programmiersprache, die von Microcontrollern²⁹ bis High Performance Computing³⁰ alle Felder abdeckt. Im August 2021 ist Python im TIOBE Index³¹ auf Platz 2 vorgerückt, direkt hinter C und noch vor Java und C++. Nach Einschätzung der IEEE ist Python seit fünf Jahren auf Platz 1 Programmiersprachen im Engineering Bereich³². Das ist insofern bemerkenswert, weil Python aus einer Open Source Community und nicht aus einem Firmenprojekt hervorging, sondern wie C++ aus einer universitären Studie³³. Python hat bis heute eine nicht herstellergebundene Community, im Gegensatz zu Java(Oracle, Red Hat, IBM), C++, DotNet (Microsoft), Go (Google), Rust (Mozilla) oder NodeJS (NPM). Für Java liegt bereits eine umfassende Analyse vor³⁴.

Python in Kritischer Infrastruktur

Python ist die Grundlage für die meisten Machine Learning Frameworks³⁵ und wird intensiv in kritischen Infrastrukturen eingesetzt, z.B. um den Energieverbrauch und den -preis an der Leipziger Energiebörse vorherzusagen, aber auch um Stromnetze im Verbund der deutschen Übertragungsnetzbetreiber und der Europäischen Transmission System Operators³⁶ zu planen³⁷.

Aufgrund der Ergebnisse dieser Vorhersagen werden bisher manuell, später auch automatisch Transaktionen an der Energiebörse Leipzig oder Schaltungen im Hochspannungsnetz oberhalb von 110kV ausgeführt. Die Auswirkungen dieser Berechnungen haben also indirekt und in Zukunft auch direkt Wirkungen nicht nur auf Stromhandel sondern auch auf Operational Technology³⁸, also Industrielle Kontrollsysteme und sind damit als Kritische Infrastrukturen³⁹ im Sinne von BSI und BBK⁴⁰. Dem Autor sind keine Systeme bekannt, deren Ausfall weiter reichende Konsequenzen hat. Ein Ausfall hätte unmittelbare Auswirkungen auf Wirtschaft und Sicherheit in Deutschland und Europa.

Python Releases

Der Community Support für Releases ist drei Jahre, mit der Ausnahme des letzten Releases von Python 2, Version 2.7 mit 10 Jahren⁴¹ um den Umstieg auf Python 3 erleichter. Der Umstieg wurde immer wieder verlängert, weil die Anwender Community die Migration nicht abschließen konnte.

Python Security

Das Python Ökosystem betrifft nicht nur die Programmiersprache selbst, sondern auch das zentrale Library Repository, den Python Package Index PyPi⁴² mit hunderttausenden von Paketen und Millionen von Releases. In diese Menge von Paketen verbirgt sich auch Schadsoftware. Die Angreifer versuchen Tippfehler in der Paketbezeichnung auszunutzen, um eine Installation zu initiieren. Diese Typosquatting⁴³ genannte Methode wird inzwischen abgewehrt⁴⁴. Dadurch können alle möglichen Angriffe z.B. Datendiebstahl ⁴⁵ oder weitere Kompromittierung auch kritischer Systeme eingeleitet werden.

Existierende Sicherheits Projekte

Das Problem ist nicht unerkannt. Schon im Rahmen des Horizon 2020 Projektes⁴⁶ gab es Bestrebungen, die Lizenz und Security Compliance als Fasten 2020 Initiative⁴⁷ zu untersuchen. Die Initiative hat bisher keinen tiefgreifenden Erfolg gehabt, vor allem weil die Breite der Fragestellunge, Fluktuationen im Projekt und mangelnde Verankerung in der Community nicht zur Nachhaltigkeit geführt haben. Auch ist Typosquatting nach Einschätzung des Autors nicht mit den vorhandenen Compliance Pattern zu erkennen. Das Google Insights⁴⁸ Projekt hat Python adressiert, aber noch nicht umgesetzt. In diesem Fall ist es nur möglich, relevante Pakete zu identifizieren, mit allen ihren Abhängigkeiten automatisch zu scannen und als geprüft zu qualifizieren. In den Anwendungen brauchen auf diese Art und Weise gesicherte Pakete nicht mehr gesondert auditiert werden.

Das Python Security Project⁴⁹ ist eingeschlafen, weil es nach dem Ende von Python 2.7 nicht fortgeführt wurde.

Ein Audit Prozess, der einzelne Projekte qualifiziert und signiert⁵⁰ und ein PyPi Mirror⁵¹, mit auditierten Paketen sind naheliegend, um nur relativ sichere Pakete zu verbreiten. Die Python Community selber hat einen Vorschlag für einen curated index⁵² gemacht, der logisch der Idee eines Mirrors sehr ähnlich ist. Ein kuratierter Index ist wie ein virtueller Mirror zu betrachten.

Der Engpass ist ist eindeutig die geringe Personaldecke, nur eine Person arbeitet in Teilzeit bezahlt für PyPi⁵³. Eine Umsetzung dieser Ideen erfordert ohne weiteres mehrere Vollzeit Stellen für die Entwicklung und die Administration.

Einbettung in andere Projekte

Es gibt eine Reihe von ähnlichen Projekten, in die diese Aktivitäten integriert werden können. Dazu gehört das Projekt The Update Framework⁵⁴ der Linux Foundation⁵⁵, das die Sicherheit von Updatesystemen zum Ziel hat. Eine Python Version, updaterpy existiert bereits⁵⁶. Weitere Projekte, wie die Absicherung von Deployment Pipelines durch SigStore⁵⁷, die Integration in die Open Security Foundation⁵⁸ und deren Projekt

ScoreCards⁵⁹ sind dringend zu empfehlen. Bei entsprechender Ausstattung könnten auch neuere Projekte wie Google Insights unterstützt werden.

Die Zusammenführung unter einer Organisation, die Open Source Security zusammen mit der Community unterstützt, ist dringend geboten. Der Widerspruch zwischen wirtschaftlichem Wert und von der Community benötigten Ressourcen ist grotesk. Auf der Seite der Wertschöpfung haben wir Milliarden Nutzen, mit entsprechendem Risiko bei einem Ausfall, für einen Schaden in der Europäischen Kritischen Infrastruktur ohne weiteres auch ein Billionen Risiko (10¹²€) , auf der anderen Seite eine Community, die das Projekt selbst organisiert und mit der Python Foundation eine Organisation hervorgebracht hat, die nicht nur die Entwicklung der Programmiersprache zu einer der wichtigsten Sprachen für alle Arten von Anwendungen vorantreibt, sondern auch Konferenzen unterstützt mit einem Budget im niedrigen Millionenbereich⁶⁰, verglichen mit den Einnahmen die Firefox für den Verkauf der Suche an Google erzielt⁶¹.

Auf der anderen Seite wird die Sicherheit praktisch nebenbei und oder in der Freizeit mit erledigt. Eine Förderung in wie durch die Core Infrastructure Initiative⁶² ist dringend geboten. Vor der Heartbleed⁶³ Sicherheitslücke hatte OpenSSL⁶⁴, die Library, die für die Verschlüsselung der meisten Internetverbindungen durch TLS⁶⁵ verantwortlich ist, eine Förderung von jährlich lächerlichen 2000$, danach sprang u.a. durch Spenden der Industrie der Betrag auf einige 100.000$ pro Jahr. Als Geldgeber für zwei Vollzeitstellen fungiert die Core Infrastructure Initiative (CII)⁶⁶, eine Unterorganisation der Linux Foundation.

Container und Kubernetes

Das Container Ökosystem hat seit der Verbreitung von Docker 2013⁶⁷ als Vereinfachung von Linux Containers⁶⁸ ein ganze Ökosystem hervorgebracht. Die Orchestrierung, d.h. das Management des Zusammenspiels von vielen Containern, die verteilte Microservices⁶⁹ zu Cloud Native Anwendungen⁷⁰ verbinden, wird heute fast ausschließlich mit Kubernetes⁷¹ implementiert.

Aufbauend auf einem eigen Container System “Borg” entschied sich Google 2014⁷², Kubernetes als Open Source bereit zu stellen. Alle Anbieter von Clouds und alle namhaften Softwareunternehmen bieten Produkte im Kubernetes Ökosystem an, die von der Cloud Native Computing Foundation CNCF⁷³ zertifiziert sind⁷⁴. Die Landschaft⁷⁵ umfasst fast tausend Projekte. Hinter den Startups in diesem Bereich Venture Capital Investitionen im Bereich von knapp 20 Milliarden. Kubernetes erschließt sich vom Einsatz einer leichtgewichtigen Variante K3S in IoT⁷⁶ bis zum Einsatz in im Militär⁷⁷ und in der Cloud⁷⁸.

Es gibt inzwischen Clustermanagement Systeme, also Systeme die selbst wieder Cluster managen, die Millionen von Clustern⁷⁹ verwalten können. Zahlreiche deutsche Cloud Anbieter haben die Bereitstellung von Kubernetes in ihren Rechenzentren als Geschäftsmodell aufgegriffen und bieten eine von ihnen verwaltete⁸⁰ Version an.

Ebenfalls ist das 5G-Mobilfunknetz vom Kern bis zu den Mobilfunkmasten mit Kubernetes und Containern abgesichert⁸¹.

Gaia-X

Die Hauptidee von Gaia-X⁸² ist Bereitstellung von Föderierten Diensten⁸³ in einem Ökosystem. Der Sovereign Cloud Stack⁸⁴, eine Beschreibung der notwendigen Komponenten und Schnittstellen durch eine Integration von Kubernetes in Openstack⁸⁵ ist eine beispielhafte Referenzarchitektur. Sie umfasst bestehende und zukünftige Komponenten von standardisierten, souveränen Cloud- und Container-Infrastrukturen, die sich ergänzen. Das Ziel ist, eine vollständig offene, föderierte und kompatible Plattform zu definieren, zu implementieren und zu betreiben.

Bemerkenswert daran ist, dass die Kubernetes Komponenten darin verpflichtend, die Implementierungen auf Open Stack aber optional sind⁸⁶. Alle Komponenten stehen unter Open Source Lizenzen, Open Stack ist weitgehend in Python⁸⁷ implementiert und würde auch unmittelbar von einer Absicherung des Python Ökosystems profitieren.

Sicherheit im Container Ökosystem

Aufgrund des schnellen Wachstums ist die Komplexität so stark angewachsen, dass die Mehrheit der Anwender bereits Sicherheitsprobleme⁸⁸ bemerkt. Die technischen Probleme reichen von Containern mit Malware, Fehlentscheidungen in der Architektur von Kubernetes und Fehlkonfigurationen in der Anwendung. Besonders besorgniserregend ist, das viele Lücken oft auch nach Jahren noch nicht geschlossen sind. DockerHub⁸⁹ ist die umfangreichste und wichtigste Registry⁹⁰ für Container. Hier werden Container Images bereitgestellt, die⁹¹ Die Unsicherheiten, die für Images im Jahr 2015 beanstandet wurden⁹² sind 2020 immer noch vorhanden⁹³:

Fast 51 % der Images wiesen kritische Sicherheitslücken auf, die ausgenutzt werden konnten, und 68 % der Images waren in unterschiedlichem Maße anfällig. 0,16 % bzw. 6432 der analysierten Images enthielten Schadsoftware.

Die Cloud Anbieter und Hersteller wälzen die Verantwortung auf die Betreiber und Entwickler ab, die mit der Aufgabe der Absicherung zuerst einmal vollkommen überfordert sind.

Es fehlen durchgängig nachhaltige, wirksame und anwendbare Prozesse, die Erkennung und dauerhafte Behebung sicherheitsrelevanter Schwierigkeiten behandelt. Alleine Red Hat hat mit einem Container Catalog⁹⁴ ein kommerzielles Angebot, das wichtige Basis Container aktuell hält und deren Sicherheit mit einem an einem an amerikanische Schulnoten angelegten Health Index bewertet⁹⁵. Die produktive Nutzung setzt eine Red Hat Subscription voraus.

Planungen für ähnliche Angebote für andere Distributionen sind nicht bekannt. Wichtig wären die Abdeckung aller Debian⁹⁶ basierten Distributionen und von Alpine⁹⁷. Debian basierte Systeme, dazu zählt auch Ubuntu, kommen mit fast 50% am häufigsten vor⁹⁸. Alpine Container sind sehr weit verbreitet, weil sie auf Größe optimiert und wesentlich, zum Teil einen Faktor 3, kleiner sind als andere Container Distributionen⁹⁹ und damit im Cloud Umfeld Ressourcen sparen und sich wesentlich schneller deployen lassen. Typische automatisierte Prozesse in Deployment Pipelines umfassen tausende von Images und bei gleichen Ressourcen sind auf Alpine aufbauende Container Prozesse dementsprechend schneller. Alpine setzt auf eine strenge Sicherheitspolitik, die selbst etablierte tools und libraries ersetzt, um die Angriffsfläche so klein wie möglich zu halten¹⁰⁰. Aus diesem Grund ist Alpine auch ein sehr guter Kandidat für Reproduzierbare Builds¹⁰¹.

Sicherheit von Kubernetes

Durch die Komplexität von Kubernetes ist es so gut wie unmöglich, einen Kubernetes Cluster mit vernünftigem Aufwand sicher aufzusetzen und zu betreiben¹⁰². Bei Untersuchungen mit dem auf dem CIS Standard¹⁰³ aufsitzenden Kubebench¹⁰⁴ von Aqua Security finden sich fast immer Sicherheitslücken, die einem Angreifer erlauben, einen Cluster zu übernehmen¹⁰⁵. Mit entsprechendem Kubernetes Wissen gelingt sogar der Aufbau einer parasitären, vom Angreifer kontrollierten Steuerungsebene, die bei normalem Betrieb nicht entdeckt wird¹⁰⁶. Die Sicherheitstiefe, definiert als die Anzahl der Fehler, die zusammentreffen müssen, um eine vollständige Kompromittierung zu erlauben, ist vier.

1. Fehler in der Applikation¹⁰⁷,

2. Zugriff auf das SecurityToken¹⁰⁸

3. Lokale Installationsmöglichkeit,
   es reicht in ein temporäres Verzeichnis schreiben zu können¹⁰⁹

4. Unverstandene rollenbasierte Zugriffskontrolle¹¹⁰

Punkt 1 ist ein häufiger Fehler in Applikationen¹¹¹, Punkt 2 ist die Default ! Einstellung, Punkt 3 ist auch fast immer erfüllt, selbst in “sicheren” Containern. Punkt 4 braucht eine gängige, im Internet häufig als Teil einer Installationsanleitung beschriebene Fehlkonfiguration. Diese Faktoren treffen in der Praxis sehr häufig zusammen.

Dabei bietet Kubernetes zahlreiche Möglichkeiten, Container abgesichert und gehärtet zu betreiben¹¹². Sichere Grundkonfiguration auf der Container Ebene durch Zugangskontrollen¹¹³, NetworkPolicies¹¹⁴, oder Zero Trust in Form von Service Meshs¹¹⁵ sind bereits in Form von Open Source Projekten anwendungsreif implementiert. Leider ist auch hier die Default Einstellung unsicher¹¹⁶, obwohl eine sichere Einstellung einfach möglich ist¹¹⁷. Um die damit weiter gestiegene Komplexität zu beherrschen, sind automatisierte Sicherheitsüberprüfungen z.B. als Erweiterung oder Ergänzung von Kubebench (s.o.) dringend notwendig. Custom Resources¹¹⁸ sind Teil der Erweiterungsmöglichkeiten für Kubernetes, aber leider auch anfällig für Fehlkonfigurationen¹¹⁹.

Seitenkanal Angriffe

Ein weiteres Problem für die geteilte Nutzung von Hardware Ressourcen sind Seitenkanal Angriffe auf den CPU Cache¹²⁰. Dieser Angriff ist generell für Clouds bedrohlich und lässt sich auch in klassisch virtualisierten Systeme ausnutzen . Die großen Cloud Anbieter verwenden interne, nicht veröffentlichte Anpassungen, um diese Angriffe zu verhindern¹²¹, eine Erkennung ist eigentlich nicht schwierig¹²². Bisherige Abwehrmaßnahmen sind das Abschalten von Hyperthreading, was einen Performance Verlust nach sich zieht, oder Patches, die nur die bekannten Lücken schliessen. Es werden aber immer wieder neue Varianten entdeckt, die sich mit bekannten Methoden nicht patchen lassen¹²³.

Der richtige Ort, um Prozesse zu überwachen, ist eine eigene Control Group für Cache Misses¹²⁴ und die Integration in Kubernetes¹²⁵. Dafür müsste ein entsprechendes Cgroup Modul geschrieben und in den Linux Kernel eingebracht werden¹²⁶.

Schlüsselbibliotheken

Kryptographische Schlüssel Bibliotheken sind wichtig für die Absicherung der Internet Transportschicht¹²⁷ vor allem OpenSSL¹²⁸, aber auch die anderen Implementierungen wie GNU TLS, LibreSSL oder WolfSSL sind verbreitet¹²⁹.

Implementierungsfehler

Trotz der Aufnahme in das Programm der Open Source Security Foundation (s.o) ist OpenSSL häufig Opfer von Verwundbarkeiten¹³⁰, aktuell wieder eine Lücke die aus dem Unverständnis von Speicherverwaltung entstanden ist¹³¹. Es ist völlig inakzeptabel, dass derartige Sicherheitslücke immer noch in weit verbreiteten und seit Jahren eingesetzten Bibliotheken vorhanden sind.

Updates von Crypto Bibliotheken

Die Lebensdauer von kryptographischen Verfahren ist im Bereich einiger Jahre. Für kein Verfahren kann das BSI im Augenblick eine Verwendung für mehr als fünf Jahre¹³² empfehlen. Das bedeutet, dass ein Algorithmus, der diskreditiert ist, ausgetauscht werden muss. Dafür existieren bis heute keine allgemeingültigen Prozesse. Während die Transport Schicht nur kurzfristig abgesichert werden muss, beruhen Signaturverfahren ebenfalls auf kryptografischen Verfahren mit einem Lebenszyklen von mehreren Jahren. Das ist insbesondere für IoT in Industrieanlagen, aber auch schon ein Gebäuden ein Problem.

Der Grund ist zum einen die lange Lebensdauer von Industrieanlagen, die vertraglich bis zu 30 Jahre eingesetzt werden können, teilweise aber aber auch 50 Jahre in Betrieb sind. Wird die Software in Zukunft in “smarte” Bauwerke integriert, kann sich die Thematik der Absicherung auch auf die Gebäude und ihre Lebensdauer ausdehnen¹³³.

Hashlisten

Der gesamte Bereich von verketteten Hashlisten und Blockchain¹³⁴ hängt von der Stärke der verwendeten Hash Algorithmen ab. In allen diesen Fällen muss die Integrität der Signatur auch gesichert werden, wenn ein Krypto Algorithmus gebrochen ist. Dies ist mehrfach für Hash Algorithmen geschehen, zuletzt sind Kollisionen in SHA1 einfach geworden¹³⁵, so dass nun mindestens SHA2 eingesetzt werden muss. Nach dem Finden einer theoretischen Schwäche hat es ungefähr ein Jahrzehnt gebraucht, um SHA1 endgültig unbrauchbar werden zu lassen.

Asymmetrische Verschlüsselung

Ähnlich verhält es sich mit asymmetrischen, Public-Private Key, Verschlüsselungs- und Signaturverfahren¹³⁶. Die Grundannahme, dass es mathematisch schwer ist, das Produkt zweier Primzahlen zu faktorisieren, lässt sich gegenwärtig weder beweisen noch widerlegen¹³⁷. Die asymmetrische Verschlüsselung dient dem Austausch eines symmetrischen Schlüssels zur Beschleunigung für

Für den theoretischen Einsatz von Quantencomputern gibt es mit dem Shore-Algorithmus bereits¹³⁸ ein Verfahren, das beliebig langer asymmetrischer Schlüssel¹³⁹ brechen kann. Weil asymmetrische Schlüssel die Grundlage der sicheren Kommunikation darstellen, wäre in diesem Falle wäre die gesamte Verschlüsselung des Internets gebrochen. Nur die Schwierigkeiten einen funktionierenden Quantencomputer zu bauen, der den Shore-Algorithmus implementiert, bewahren uns vor der Quantum Cryptocalypse¹⁴⁰. Wann und ob überhaupt Quantencomputer jemals einsetzbar sein werden, ist schwer vorhersehbar. Die Digitalstrategie der EU erwartet einen ersten Europäischen Quantencomputer 2023¹⁴¹. Es ist zu erwarten, dass die massenhafte Verbreitung von Quantencomputern auch alle Kryptoverfahren schwer erschüttern wird¹⁴².

Weil Quanten-Computer keine universellen Computer sind, gibt es seit einigen Jahren, Bestrebungen die Entwicklung von Post Quanten Kryptographie¹⁴³ voranzutreiben. Inzwischen gibt es viele Kandidaten, die kryptographisch untersucht sind und ausgerollt werden können. In den meisten Fällen sind sie nicht langsamer als die bekannten Algorithmen, brauchen aber teilweise viel mehr Speicher, so dass sie erst in den nächsten Generationen von Chipkarten zum Einsatz kommen können¹⁴⁴.

Wichtig erscheint daher die Absicherung von Crypto Verfahren, sowohl in Hinsicht auf existierende Sicherheitslücken wie auf drohende fundamentale Einschnitte durch Quantencomputer oder fehlende mathematische Beweise für die Sicherheit der Verfahren.

Gemeinsamkeiten

Gemeinsam sind allen diesen Probleme, dass sie sich mit Updates gut lösen lassen. Im Angesicht der Dringlichkeit der Probleme, ist es essentiell, Sicherheitslücken in zu erkennen, zu beheben und zu patchen, also eine abgesicherte Version so schnell wie möglich zu installieren.

Das gelingt nur, wenn dieser Prozess weitestgehend automatisiert werden kann. Statische Analyse Methoden sind standard¹⁴⁵. Google sucht schon länger nach Sicherheitslücken in C, C++ und Java Virtual Machine basierten Sprachen¹⁴⁶ durch Fuzzing¹⁴⁷, ein Verfahren das Source Code durch Zufalls Eingaben überprüft¹⁴⁸ und auch schon in Deutschland von Bosch, der Telekom, Continental und der Deutschen Börse eingesetzt wird¹⁴⁹. Die wolfSSL Library wurde damit auf die gängigen Fehler überprüft¹⁵⁰. Das Verfahren nutzt viel nicht verwendete Rechenleistung. Ein akademische Projekt wie Angr¹⁵¹, das den Kontrollfluss effektiver analysiert, hat zwar einige spektakuläre Erfolge erzielt, wird aber kaum angewandt.

Sichere Deployment Pipelines

Als Continuous Integration / Continuous Deployment wird der Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung bezeichnet¹⁵². Er besteht aus mehreren Schritten, vom Einchecken des Source Codes bis zum Ausrollen in Produktion.

Diese Arte des Ausrollens von neuer Software unter den Stichworten Continuous Integration¹⁵³ und Continuous Delivery¹⁵⁴ oder Continuous Deployment¹⁵⁵ in vielen modernen Systemumgebungen inzwischen Standard ist.

Eine einfache Deployment Pipeline mit elementarer Sicherheitsüberprüfung zeigt das folgende Bild vom commit des Source Codes bis zum Ausrollen in Produktion, also der Installation auf der Zielplattform.

Aufwändigere Pipelines sind durch die Integration von mehr Tests ohne weiteres möglich. Bei kleinen Änderungen kann die Pipeline ohne weiteres vollständig in 20 Minuten durchlaufen werden, von Commit des Sourcecodes bis deployment in Produktion¹⁵⁶. Die sicherheitsrelevanten Schritte sind rot unterlegt und können asynchron, z.B. über Nacht ablaufen. Eine aufwändigeres Beispiel mit Trennung der Umgebungen findet sich bei Gitlab¹⁵⁷.

Wichtig ist, dass die Deployment Pipeline die softwaretechnische Implementierung eines DevSecOps¹⁵⁸ Prozesses ist, und nicht einfach ein Tool was zum Einsatz kommt¹⁵⁹. Eine vollständige Beschreibung dieses Prozesses ist von der Cloud Native Computing Foundation zusammen mit dem US Department of Defense¹⁶⁰ erstellt worden.

Das ist eine erhebliche Umstellung, die nicht nur die Technik sondern alle Abläufe inklusive der Organisationsstruktur selbst betrifft, auch als Shift-Left¹⁶¹ bezeichnet. Der Autor schätzt, dass eine Einführung dieser Abläufe in einer etablierten Organisation mindestens fünf Jahre in Anspruch nehmen wird. Das US National Institute of Standards stellte dies schon im Hinblick auf Container im Jahr 2017 fest: Schneiden Sie die organisatorische Betriebskultur und die technischen Prozesse so zu, dass sie den neuen Weg von der Entwicklung, dem Betrieb und dem Support von Anwendungen in Containern ermöglichen¹⁶². Aus der technischen Anforderung ergeben sich unmittelbar Auswirkungen auf die Betriebsorganisation. Da Organisationen generell gegen Änderungen erstmal passiven Widerstand leisten, muss dieser Veränderungsprozess aktive gemanagt werden.

Aufwände für den Betrieb von Build Pipelines

Im Vergleich zum klassischen Arbeit in der Softwareentwicklung stellt die Verwendung von Build Pipelines einen Übergang der Code Entwicklung zum Software Engineering dar. Der spielerischen Motivation vieler Open Source Entwickler stehen zum Teil die strikten Anforderungen des Software Engineering entgegen. Die Integration in eine automatische Umgebung mit statischer Codeanalyse und Fuzzing bedeutet eine Umstellung der Arbeitsweise, und nicht zu unterschätzenden Aufwand für die Bewertung der Analyseergebnisse¹⁶³. Die Transformation ist für etablierte Projekte nicht trivial und ohne Unterstützung nur sehr schwer zu leisten¹⁶⁴.

Das Beispiel des etablierten Projektes GnuPG soll das erläutern. Das Geschäftsmodell hat mit G10 Code¹⁶⁵ eine Firma hervorgebracht, die sich um Weiterentwicklung und Support kümmert. Durch Support und Dienstleistungsverträge wird GPG für Dokumente, die als Verschlusssache¹⁶⁶ eingestuft sind für die Kunden aus Sicherheitsbehörden verwendbar. Die vorhandene Developer können diese Modell auch gut unterstützen. Es fehlen aber Ressourcen für die Pflege der Dokumentation, die automatische Code Analyse, Fuzzing der Codebasis, Aufbau von Deployment Prozessen und eine Weiterentwicklung. Externe Audits finden regelmäßig statt, aber das Einarbeiten der Ergebnisse bedeutet jeweils einen hohen zusätzlichen Aufwand

Der Verein zu GnuPG¹⁶⁷ ist finanziell gut ausgestattet, aber es fehlen Ressourcen für Community Management und die Außendarstellung. Zudem stellt auch hier die Überalterung der Community ein Problem dar¹⁶⁸.

Eine erste Abschätzung zeigt, dass hier fünf bis zehn Vollzeitstellen sinnvoll eingesetzt wären.

Supply Chain Attacks

Alle hier behandelten Pakete sind Teil der Supply Chain, die selbst wieder ein vorrangiges Ziel von Angriffen ist¹⁶⁹. Ein unerkannter Angriff wie auf Solarwinds hat einen dauerhaften Schaden in der gesamten Software Ökonomie hinterlassen¹⁷⁰. Abhilfen durch Signieren der einzelnen Schritte in der Pipeline wie durch Sigstore¹⁷¹ oder der Pipeline selbst inklusive Auditing wird in naher Zukunft Standard werden¹⁷². Gerade sicherheitskritischer Code muss in vertrauenswürdigen Umgebungen aus dem Source Code gebaut werden, idealerweise als Reproducible Build, s.o. Diesen Software Engineering Aufwand können Projekte nicht dauerhaft im Nebenjob leisten.

Zusammenfassung und Massnahmen

Die Einrichtung eines Open Source Security Fonds scheint dringend geboten. Auf der einen Seite stehen Milliardeninvestionen, die von Open Source abhängen, auf der anderen Seite gibt es keine kohärenten und nachhaltigen Maßnahmen zur Absicherung. Für die üblichen Forschungsprojekte der EU wie Fasten 2020 gibt es über drei Jahre eine Förderung im Bereich weniger Millionen. Nach Ende des Projekts entsteht zwar ein Projektbericht, aber es bleibt keine Organisation, die die Ergebnisse weiterentwickelt und den Transfer in die Community betreibt. Die wichtigste guten Ansätze für sichere DevSecOps Prozesse haben eine starke Bindung zum US Militär und sollten durch eine starke, zivile Europäische Initiative ergänzt werden.

Der Fond sollte einzelne Projekte, Communities und Ökosysteme identifizieren und mit den Maintainer Schwachstellen analysieren und Ressourcen zur Behebung bereitstellen. Dazu müssen die wichtigsten Komponente gefunden werden und mit der Community Prozesse definiert werden, die automatisch unterstützt werden können. Diese Prozesse sollten ebenfalls gemeinsam implementiert und abgesichert werden.

Für eine Community wie die Python Foundation würde das aufgrund der Anzahl der Paket mehrere Vollzeitstellen, begleitet von externer Expertise wie mindestens jährlichen Audits und der Bereitstellung kuratierter Subrepositories von PyPi bedeuten. Hinzu kommt eine entsprechend hoch abgesicherte Deployment Pipeline. Mit Projekt und Community Management müsste jährlich ein höherer einstelliger Millionenbetrag verwendet werden. Wichtig ist eine nachhaltige Investition, Projekte mit einem endlichen zeitlichen Horizont sind immer verpufft. Kooperationen mit Partner sollten gesucht und koordiniert werden.

Weitere unterstützenswerte Projekte

Entsprechende Projekte für andere Programmiersprachen wie Ruby oder das Ökosystem von Owncloud oder Nextcloud¹⁷³, Videokonferenz Tools wie Jitsi oder Big Blue Button¹⁷⁴ würden sicher zu ähnlichen Ergebnissen führen, je nach Umfang der Komponenten. Ein weiteres Beispiel ist Rechenzentrumsinfrastruktur, Software Defined Networks lässt sich auf gängiger High End Hardware auch mit Open Source sicher betreiben¹⁷⁵. Einzelne Cloud Anbieter zwingen Hardware Lieferanten auf Linux basierte Betriebssysteme¹⁷⁶ oder pflegen ihre eigenen, von Open Source Software abgeleiteten Infrastrukturkomponenten. Eine Unterstützung von Offener Hardware und Offener Infrastruktur ist im Hinblick auf den Einsatz in der Gaia-X Initiative auch geboten¹⁷⁷. Weitere ambitionierte Projekte wie das Linux Phone¹⁷⁸ oder ein modifiziertes Android¹⁷⁹ zielen auf die Privacy der Anwendenden, es muss aber betont werden, dass der Einsatz auch unmittelbar der Sicherheit der Wirtschaft zugute kommt.

Bemerkenswert ist die hohe Kompetenz, die deutsche und europäische Anbieter bereits aufgebaut haben, wie BISDN¹⁸⁰ im High End Carrier und Netzwerk Markt, Nitrokey¹⁸¹ im Bereich Verschlüsselung oder K-9 Mail mit Email Verschlüsselung¹⁸². K9 Mail hat einen Funding Aufruf zu Maintenance gestartet. K-9 Mail ist im wesentlichen das Projekt eines einzelnen Entwicklers¹⁸³, der um eine vergleichsweise bescheidene Finanzierung bittet, die die Community schon zum größten Teil aufgebracht hat. Von diesem Projekt mit 600.000 Downloads hängen tatsächlich kleinere Unternehmen ab, in denen jeweils hundert Mitarbeiter K-9 Mail verwenden¹⁸⁴. Auf Finanzierung angesprochen kann er sich nicht vorstellen, eine Firma mit eigenen Mitarbeitern zu gründen. Er wünscht sich für kleine Open Source eine einfache Möglichkeit des Funding, wie sie in den USA von der Plattform Open Collective¹⁸⁵ angeboten wird.

Bewertung

Die Gespräche, die für diese Analyse durchgeführt werden, zeigen einen hohen Grad an Unterstützungsbedarf. Die Communities signalisieren sehr oft, wie im GnuPG Beispiel, dass sie gut versorgt sind¹⁸⁶, bei näherer Nachfrage zeigt sich aber, dass diese Aussage nur auf einem niedrigen Niveau richtig ist. Die Ausstattung der Projekte, wie GnuPG, Python oder Alpine Linux ist nur bei einem minimalen Anspruch ausreichend. Fragt man nach professioneller Softwareentwicklung, die die Automatisierung einschließt, wie Deployment Pipelines, automatische Sicherheitsanalysen, Fuzzing oder Audits ergeben sich Defizite in vielen Bereichen. Die Community gleicht das durch ein überwältigende persönliches Engagement aus, aber um den Preis des Burnouts, der auch in den Open Source Communities angekommen ist. Mit der entsprechenden Sensibilisierung lassen sich die Symptome sogar oft beobachten¹⁸⁷.

Alle Community Projekte signalisieren, dass sie weitere Ressourcen sehr begrüßen würden. Ausgewählte kleine Projekte von einzelnen Entwicklerinnen sollten einfach und ohne viel Bürokratie finanziert werden, dabei es möglich sein auch freiberuflich Entwicklerinnen zu unterstützen.

Strategische Projekte

Dringend notwendig wäre auch die Unterstützung strategischer Projekte im Cloud Bereich. Dazu zählt auch Edge Computing¹⁸⁸, das im Bereich massiv verteilter Systeme, wie im smarten Energiemanagement¹⁸⁹ und der Echtzeit Industriesteuerung¹⁹⁰ in Zukunft eine Notwendigkeit ist. Edge Computing, z.B. durch K3S¹⁹¹ ist ein leichtgewichtiges Kubernetes, kommt aus dem Cloud Computing. Im gesamten Bereich der Cloud Orchestrierung, ist selbst das BSI schwach aufgestellt¹⁹². Moderne Sicherheitsarchitekturen wie Zero Trust¹⁹³, der flächendeckende Einführung von Multi Faktor Authentifizierung¹⁹⁴, OpenID¹⁹⁵ und günstigen Signaturdiensten¹⁹⁶ für Dokumente oder Zertifikate ACME¹⁹⁷ sind in diesem Bereich notwendig. Initiativen wie der Souvereign Cloud Stack¹⁹⁸ sind scheinbar über Gaia-X und Förderprojekte gut ausgestattet, können diesen Bereich auch nicht vollständig abdecken. Auch eine Integration von Chaos Security Engineering¹⁹⁹ in diese Architektur ist zu empfehlen²⁰⁰.

Organisation eines Open Source Security Fonds

Es muss die Aufgabe des Fonds sein, für die unterstützten Projekte eine nachhaltige und ausreichende Ausstattung zu gewährleisten. Dazu gehört neben der Entwicklung eine vernünftige Automatisierung, Audits und professionelle Kommunikation und Community Management.

Es wird empfohlen, Kriterien zu erarbeiten um 10-20 Communities auszuwählen, den Reifegrad und den Bedarf festzustellen und dort je 5-10 Vollzeitstellen zu schaffen. Mehr sind mit einem Fond am Anfang nicht zu bewegen.

Zusätzlich ist es sinnvoll, eine gleiche Anzahl kleinerer Projekte mit 2-4 Vollzeitstellen zu unterstützen. Kleine und sehr kleine Projekte, auch Einzelpersonen, sollten mit einer Konstruktion wie Open Collective die Möglichkeit bekommen sich zu transparent zu finanzieren und zu verwalten.

Die Führungspositionen des Fonds müssen durch anerkannte Mitglieder der Community besetzt werden. Gerade erst ist der Chief Software Officer der US Air Force zurückgetreten, weil die IT-Erfahrung der im beigeordneten Führungsebene nicht ausreicht²⁰¹. Es ist sinnvoll, dass die Industrie, die an den Projekten mitarbeitet, Vertreter mit dem entsprechenden Wissen ebenfalls entsenden kann. In keinem Fall dürfen die Projekte als verlängerte Werkbänke angesehen oder sogar Weisungen erteilt werden.

Reallabore

Alle diese Technologien sind real einsatzbereit und haben den höchsten Technology Readiness Level²⁰² nämlich 9. Es geht also nicht um Forschungsprojekte, sondern um flächendeckende Umsetzung, z.B. in Gaia-X. Ein föderiertes Entwicklungsmodell “Einer für alle” zusammen mit den Mitgliedern der Gaia-X Foundation sollte die Technologie, die ein einzelner mittelständischer Provider nicht anbieten kann, für die Provider Community flächendeckend für alle zur Verfügung stellen können. Wichtig hier ist auch eine Flankierung durch das BSI, die die Anforderungen konkretisiert und formalisiert.

Umgang mit Sicherheitslücken

Alle Sicherheitslücken müssen in einem Responsible Disclosure²⁰³ Prozess veröffentlicht werden. In keinem Fall dürfen Sicherheitsbehörden Lücken ausnutzen, die noch nicht veröffentlicht sind. Ein Handel mit Sicherheitslücken muss strikt unterbunden, am besten verboten werden. Alle diesbezüglichen Entscheidungen müssen durch die Communities selbst getroffen, ein politischer Einfluss muss streng ausgeschlossen, weil sonst ein wichtiger Teil der Sicherheits Community nicht mehr mit dem Programm kooperieren kann.

Auch das BSI ist nicht neutral genug²⁰⁴. Das Vertrauen der Community in die Politik ist durch irrationale und technisch schlecht begründet Entscheidungen schwer beschädigt²⁰⁵. Eine offene oder verdeckte Einflussnahme würde zum Rückzug wichtiger Akteure aus der Zusammenarbeit mit den Fond bedeuten.

Internet Bug Bounties²⁰⁶ sind kein geeignetes Mittel, um nachhaltig Sicherheit zu erzeugen. Sie schaffen einen Markt, der mit dem Malware Markt konkurriert²⁰⁷.

Über den Autor

Dr. Thomas Fricke

1989 Installation von Unix Cluster, erste Linux Versionen

1994 Promotion in Aachen

1996-2005 Softwareentwickler in Anstellung

seit 2005 freiberuflicher Berater als Software und System Engineer

2006 verschiedene Projekte im Bereich Clouds, Automatisierung

seit 2015 Kubernetes

2013 Mitbegründer der Endocode AG (jetzt Hoverture Deutschland AG), einem Open Source und Cloud Dienstleister

2013-2021 Vorstand, CTO und Aufsichtsrat bei Endocode

Kubernetes Projekte CoreOs, Google, SAP, Red Hat

2019-2020: Mitglied des Technisches Advisory Board von Octarine (jetzt VMWare)

seit 2017 unabhängiger Cloud Security Architekt für Kubernetes und OpenShift

2021 Mitgründer der Resility GmBH (Security Chaos Engineering)

Sektoren Energie und Gesundheit

Projekte im Sicherheitsbereich für die Bundesdruckerei und Mail Anbieter

Ehrenamtliche Mitarbeit im IT-Planungsrat

osssecurity@thomasfricke.de

https://www.linkedin.com/in/thomas-fricke-9840a21/

---

• Next Post →