Ansätze und Abhängigkeiten: Wettrüsten für eine sichere Software-Supply-Chain
Die Sicherheit der Software-Lieferkette ist für Unternehmen von entscheidender Bedeutung, um die Integrität, Vertraulichkeit und Verfügbarkeit ihrer Anwendungen und Dienste zu gewährleisten. Doch wie lässt sich die Supply Chain schützen? Unser Autor gibt einen Überblick über die Situation und zeigt Abhängigkeiten und Ansätze auf.
Die IT ist im Laufe der Jahre ein zunehmend unsicheres oder jedenfalls bedrohtes Feld geworden, auf dem sich staatliche Akteure (gerade der russische Angriffskrieg hat das wieder deutlich gemacht), kriminelle Banden und verspielte Amateure tummeln.
Es findet ein regelrechtes Wettrüsten statt: Unternehmen und die öffentliche Hand werden immer routinierter im Umgang mit Risiken, von der Architektur über präventive Maßnahmen bis hin zur aktiven Verteidigung. Gleichzeitig werden Systeme verteilter zwischen diversen Clouds bis hin zu Edge-Anwendungen, sie werden komplexer und vor allem auch dynamischer. Und die Angriffe werden immer ausgeklügelter. Sowohl Angreifer als auch Verteidiger verwenden zunehmend intelligente und automatisierte Ansätze.
Das neue Normal
Attacken sind mittlerweile kein gelegentliches Ereignis mehr, sondern die Regel. Sie finden am laufenden Band statt: Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat im Rahmen seiner Untersuchung zur Lage der IT-Sicherheit in Deutschland 2023 täglich rund 21.000 neu infizierte Systeme erkannt; die Dunkelziffer liegt wohl weit höher. Die „2023 Supply Chain Risk Management Survey“ von Gartner stellt fest, dass „Angriffe auf die Software-Lieferkette auf dem Vormarsch sind”; 63 Prozent der Befragten gaben an, im vergangenen Jahr betroffen gewesen zu sein.
Die Frage ist nicht, ob eine Organisation einen Angriff auf ihre Software-Lieferketten erlebt, sondern wann, wie und wie oft. Die Europäische Union hat diese Gefahr erkannt und mit der „Network and Information Security“-Richtlinie (NIS-2) und dem EU Cyber Resilience Act Grundlagen für mehr IT-Sicherheit und den Schutz kritischer Infrastruktur geschaffen.
Einer Studie des Digitalverbandes Bitkom nach ließen sich 46 Prozent der Angriffe auf betroffene Unternehmen übrigens nach Russland zurückverfolgen, 42 Prozent nach China. Zum Vergleich: Im Jahr 2021 lag die Zahl der Angriffe aus Russland noch bei der Hälfte, jene aus China bei 30 Prozent.
Angriffe auf die IT-Infrastruktur haben durch staatliche Akteure eine neue Dimension erhalten, und nicht nur die Deutsche Bundeswehr hat mit ihrem Zentrum für Cybersicherheit aufgerüstet, auch das Bundeskriminalamt schafft mit dem Nationalen Cyber-Abwehrzentrum (Cyber-AZ) eine Koordinierungsstelle, die im Krisenfall dazu beitragen soll, die Handlungsfähigkeit der Bundesregierung zu erhalten.
Der Seiteneingang
Während Angreifer auf immer ausgefeiltere Techniken und Werkzeuge zurückgreifen können und sich auch im Darknet vernetzen und Informationen austauschen, sind Anbieter und Anwender nicht untätig geblieben: Firewalls und Netzwerksegmentierung, Zwei-Faktor-Authentifizierung, Intrusion Detection und vieles mehr sind mittlerweile Standard.
Anstelle einfach immer wieder gegen diese Bollwerke anzulaufen, wählen Angreifer weichere, vielversprechendere Angriffsvektoren: Menschen, über Social Engineering. Und einen definitionsgemäß mehr oder minder offenen Eintrittspunkt: Software-Supply-Chains. Über Supply-Chains gelingt ein Eindringen, ohne zunächst Aufmerksamkeit zu erwecken und üblicherweise gar auf Einladung hin. Sprich: Entwickler oder IT-Fachkräfte holen aktiv neue Komponenten oder Updates bestehender Programme und Bibliotheken in ihre Umgebungen, in das Herz der IT.
Denn die Lieferketten haben sich im Lauf der Jahre massiv gewandelt. Wurde Software ursprünglich auf Datenträgern ausgeliefert, typischerweise read-only wie CDs und DVDs, verhältnismäßig selten neu installiert und noch seltener aktualisiert, erfolgt der Bezug heute elektronisch, und dank agiler Prozesse und einer stets wachsenden Zahl an bekannten Sicherheitslücken werden Updates monatlich, wöchentlich, ja oft auch täglich eingespielt – und das nicht bloß auf Mobiltelefonen, sondern eben zunehmend in Produktionsumgebungen.
In unserer täglichen Welt außerhalb der IT finden Lieferketten zu guten Teilen auf Straßen statt. Was wir mit Software-Lieferketten erleben, gleicht zunehmend Autobahnen, wo in hoher Frequenz und mehrspurig Pakete in Zentren verbracht werden, begleitet von einer Vielzahl zusätzlicher Einfallstraßen: Moderne Programmiersprachen – Go, Javascript, Python, Ruby, um nur einige zu nennen – bringen eigene Portale mit Unmengen an Modulen und anderen nützlichen Ergänzungen, aus denen Entwickler gern schöpfen.
Zusätzlich nutzen viele GitHub, den Platzhirschen mit nach eigenen Angaben über 100 Millionen Entwicklern und mehr als 420 Millionen Repositories, darunter mindestens 28 Millionen öffentliche Repositories, als virtuelle Fundgrube. Dazu kommen viele klassische Anwendungen von unabhängigen Softwareherstellern (ISVs) und selbstständige Open-Source-Projekte. Insgesamt eine immense Vielfalt und Menge, die gern und oft konsumiert wird.
So praktisch und sinnvoll die Nutzung all dieser Quellen ist, sie birgt Risiken, sich ein Problem ins Haus zu holen: Auch die besten Entwickler machen Fehler, und böswillige Hacker können diese entdecken und ausnutzen. Ein Entwickler mag unerfreuliche Absichten haben und kompromittierenden Code einfügen. Ein anderer hat das Pech, dass sein Account geknackt wird und jemand unter seinem Namen schadhaften Code einfügt. Dazu kann bei mangelhafter Sicherheit auf dem Weg vom Entwickler zum Portal oder vom Portal zum Anwender etwas verändert werden, etwa durch eine sogenannte „Man-in-the-Middle“-Attacke. Und zuletzt begegnen wir immer wieder auch übel wollenden ehemaligen Mitarbeitern oder Dienstleistern mit Insiderwissen.
Was nun?
Ein wesentlicher Schritt ist es, den Menschen in den Mittelpunkt zu stellen, aufzuklären, gemeinsam Richtlinien zu erarbeiten, Praktiken zu etablieren und Policies zu setzen, aus welchen Quellen Code bezogen werden darf, unter welchen Voraussetzungen und mit welchen Vorgehensweisen.
Dem klassischen „Trust but verify“ folgend mag das in kritischen Umgebungen bis hin zur Inspektion von Quellcode durch Spezialisten führen oder zumindest einem schnellen Durchsehen und Testen in einer isolierten Umgebung. Natürlich will man auch auf bekannte Muster beziehungsweise bekannte Common Vulnerabilities and Exposures (CVEs) scannen, von denen es allein im Jahr 2023 29.065 Stück gab.
Sicherheit und insbesondere die Suche nach bekannten Schwachstellen ist ein kontinuierlicher Prozess und keine einmalige Aktion. Etwas, das gestern sicher schien, alle Tests mit Bravour bestanden hat und im Herz des Netzwerks implementiert wurde, mag angesichts neuer Erkenntnisse heute tiefrot aufscheinen – bei im Schnitt rund 80 neuen CVEs pro Tag, Tendenz steigend, durchaus keine Seltenheit. Es gilt also nicht nur gelegentlich oder gar bloß einmalig bei der Inbetriebnahme zu überprüfen, sondern laufend: auf Entwicklungssystemen, in Registries (Bibliotheken), in Produktionsumgebungen und auch der Infrastruktur selbst.
Erstrebenswert ist es, auch bei eigenen Entwicklern und gerade auch in Open Source Communities mehr Bewusstsein für Sicherheit zu schaffen und Coaching, Code-Reviews und entsprechende Werkzeuge zur Verfügung zu stellen.
Ein weiterer Ansatz sind, zumindest im kommerziellen Bereich, Zertifizierungen, die bestätigen, dass Hersteller bei der Entwicklung, Wartung und Verteilung ihrer Software oder auch sogenannter Distributionen – die im Fall von Linux-Distributionen durchaus schon einmal zweitausend Komponenten und mehr bündeln – bestimmten Prinzipien folgen und ein hohes Maß an Sorgfalt an den Tag legen. Dazu zählen die langfristige Aufbewahrung aller Artefakte, die beim Bauen dieser Software anfallen, detaillierte Code Reviews, Vieraugenprinzip, das Signieren der Software sowie aller Updates, kryptografisch gesicherte Lieferwege. Googles SLSA (Supply-Chain Levels for Software Artifacts, ausgesprochen „Salsa“) und eine Common-Criteria-Zertifizierung durch das BSI sind gute Beispiele.
Nobody is perfect
Letztlich müssen wir jedoch einer Wahrheit ins Auge schauen: Absolute Sicherheit existiert nicht. Wir können uns so gut wie möglich schützen und lernen, auf Unerwartetes und Unerwünschtes zu reagieren. Eine hundertprozentig sichere Supply-Chain ist illusorisch, außer vielleicht in extremen und sehr eingeschränkten Fällen.
Wie gehen wir also mit diesem Fall der Fälle um, wenn doch einmal etwas durchrutscht? Wie können wir es hoffentlich, wenn auch spät, erkennen? Wie können wir allzu großen Schaden verhindern? Und nur selektiv Maßnahmen ergreifen, ohne den gesamten Betrieb einzustellen? Hier sind zum Beispiel Zero-Trust-Ansätze sehr vielversprechend und Notfallpläne (inklusive Kommunikation), die auch geübt werden.
Dr. Gerald Pfeifer lebt und arbeitet in Wien, Nürnberg und wo immer seine Rolle als CTO bei SUSE sowie Chair des openSUSE Board und seine Leidenschaft für Yoga und Tauchen ihn hinführen. Er hat in technischen Wissenschaften promoviert und beschäftigt sich mit Infrastruktursoftware, Applikationsplattformen und Open Source, bevor dieser Begriff überhaupt geprägt wurde.