Nur wer seine Supply Chain kennt, kann sie auch schützen CVE-Flut täuscht über reale Gefahren in der Software-Lieferkette hinweg

Anbieter zum Thema

Stackable GmbH

sysob IT-Distribution GmbH & Co. KG

Fsas Technologies GmbH

FTAPI Software GmbH

Manipulierte Pakete in Software-Lieferketten können Millionen Systeme kompromittieren, bevor jemand es bemerkt. Über 50 Prozent der Firmen sehen laut WEF die Supply Chain als größte Herausforderung. Big-Data- und Open-Source-Experte Lars Francke erklärt, warum lange CVE-Listen täu­schen: Entscheidend ist der Kontext, nicht die Anzahl der Schwachstellen.

Ransomware war gestern. Statt sich durch Firewalls zu hacken oder Passwörter abzugreifen, schleusen heute viele Cyberkriminelle ihre Schadcodes direkt in die Werkzeuge ein, auf die Entwickler jeden Tag vertrauen. Die Angriffe auf npm, Asus oder PyPI-Tokens zeigen, wie verwundbar moderne Software-Lieferketten sind: Ein einziges manipuliertes Paket kann Millionen Systeme kompromittieren, bevor jemand überhaupt merkt, dass etwas nicht stimmt. Welche Rolle spielen dabei Open und Closed-Lösungen? Und was sollten Unternehmen für ein effektives Schwachstellenmanagement beachten? Das haben wir uns auch bei Stackable gefragt.

Update: Neue Variante des Shai-Hulud Worm

Supply-Chain-Angriff trifft über 1.000 npm-Pakete

Ob Closed Source oder Open Source beim Thema Sicherheit die bessere Wahl ist, darüber werden sich IT-Experten wohl nie einig werden. Fest steht aber, dass Cyberkriminelle beide Systemarten gleichermaßen ins Visier nehmen. Ein relativ neues Phänomen bei quelloffener Software ist, dass die Täter es auf die Supply Chain abgesehen haben. Also auf fertige Programmier-Bausteine, die Entwickler innerhalb der eigenen Software als Zuliefermodule für bestimmte kleine und große Funktionen einbinden. Bei einer Befragung für den letztjährigen Global Cybersecurity Outlook des World Economic Forum (WEF) gaben über 50 Prozent der Organisationen an, dass dies für sie die größte Herausforderung darstellt.

Einen großen Zwischenfall gab es etwa 2019 – das Sicherheitsunternehmen Kaspersky taufte ihn auf den Namen „ShadowHammer“. Dabei wurde das Dienstprogramm Asus Live Update mit einem Backdoor-Trojaner infiziert, der über einen C2-Server weitere Payloads herunterladen konnte. Ein weiteres bekanntes Beispiel ist der Angriff auf GitHub Actions um PyPI-Tokens zu exfiltrieren. Und erst vor wenigen Monaten erwischte es den Paketmanager npm gleich doppelt: Bei einer ersten Attacke erbeuteten die Täter die Zugangsdaten eines Entwicklers und veröffentlichten manipulierte Pakete. Kurz darauf wurde ein Paket mit einem Wurm infiziert, das jede Woche millionenfach heruntergeladen wird.

Beispiele gibt es jedenfalls genug, das zeigt schon diese Momentaufnahme. Was Unternehmen daraus mitnehmen sollten: Die digitale Supply Chain muss genauso gesichert werden wie die physische. In einem Umfeld, bei dem Personen mit böswilligen Absichten für Chaos sorgen können, egal ob Open Source, Closed Source oder im Mix, ist das natürlich leichter gesagt als getan. Was gibt es also für Optionen? Mehr Kapazitäten in die eigene Security zu stecken reicht meist nicht aus und ist nach unserer Erfahrung häufig auch nur schwer in der Praxis umzusetzen. Viele Unternehmen müssen daher darauf vertrauen, dass ihre Softwarelieferanten die eigene Supply Chain absichern. Und da Kontrolle bekanntlich besser als Vertrauen ist, sollten die Lieferanten ein möglichst transparentes Konzept bieten – so unsere Erfahrung.

Strategien für eine sichere Software-Lieferkette

So funktionieren Supply-Chain-Attacks

Herausfinden, wann der Wolf wirklich kommt

Als Hersteller einer Data Platform mit unterschiedlichen Open Source-Komponenten auch wir auf eine sichere Lieferkette angewiesen sind Und deshalb haben wir eine spezielle Strategie für unsere Kunden und Partner entwickelt.

Dafür war es zuerst nötig, sich von einem hartnäckig haltenden Vorurteil zu verabschieden. In Sicherheitsreports ist häufig von hunderten offener „Common Vulnerabilities and Exposures“, sogenannten CVEs, zu lesen. Auf den ersten Blick wirken diese Berichte sehr beunruhigend, dabei sind sie meist eher irreführend. Eine lange Liste mit CVEs steht nämlich nicht unbedingt für Unsicherheit – während wenige Einträge nicht automatisch Sicherheit bedeuten. Viel wichtiger ist es, wie relevant die Schwachstelle im jeweiligen Kontext ist.

Ein anschauliches Beispiel aus unserer täglichen Arbeit: Bei dem für Fernzugriffe genutzten Programm OpenSSH gibt es einige bekannte Schwachstellen in der CVE-Datenbank. Und oft schlagen Sicherheitsscanner Alarm, wenn sie in der verwendeten Version eine bekannte CVE entdecken. Ein Risiko gibt es deshalb aber nicht unbedingt. Wir nutzen das Programm beispielsweise nur als Client bzw. um Verbindungen nach außen aufzubauen. Und deshalb sind CVEs bei den serverseitigen Funktionen von OpenSSH für uns nicht von Bedeutung – an anderen Stellen aber natürlich schon.

Wichtig ist es deshalb, bei jedem Sicherheitshinweis Aufwand und Nutzen abzuwägen und sich auf die realen Gefahren zu fokussieren. Es gilt sozusagen herauszufinden, wann der Wolf wirklich kommt. Und dazu gibt es unterschiedliche Möglichkeiten: Wir vergleichen beispielsweise Listen von Vulnerabilities, bei denen eine Ausnutzung nachgewiesen ist, mit CVE-Einträgen. Und wir behalten Exploit-Quellen wie das Proof-of-Concept-Repos auf GitHub oder Metasploit im Auge. Zudem setzen wir auch auf Exploit Prediction Scoring Systeme, kurz EPPS, um die Wahrscheinlichkeit eines Vulnerability-Exploits realistisch einzuschätzen. Letztendlich geht es darum zu evaluieren, ob ein Einfallstor wirklich ausgenutzt wird – nicht, ob es vorhanden ist.

Und lohnt sich dieser Aufwand? Absolut! Wir wollen vor allem ein stabiles Produkt abliefern und es nicht durch vorschnelle Patches unnötig aus dem Gleichgewicht bringen. Das Ziel ist nicht eine möglichst hohe Update-Frequenz, sondern zuverlässige Sicherheit. Und um dieses Ziel zu erreichen, ist der klare Fokus auf Open Source das beste Mittel.

Alles zum Cyber Resilience Act – Teil 2

Betroffene Produkte und Anforderungen durch den CRA

Mit Transparenz zu erhöhter Security

Aktuelle Umfragen zeigen: Open Source fristet kein Nischendasein, sondern ist bei vielen Unternehmen zu einem festen Bestandteil geworden. Im aktuellen Open Source Monitor der Bitkom gaben mehr als 70 Prozent der Befragten an, Open Source in verschiedenen Bereichen einzusetzen. Auf die Frage, welche Themen für sie am wichtigsten sind, antworteten die meisten Teilnehmer: Funktionalität und Sicherheit.

Wie eine Software, bei der jeder User den Quellcode ansehen und ändern kann, für mehr Sicherheit sorgt, ist für Laien vermutlich nicht gleich ersichtlich. Schließlich bekommen so auch Kriminelle Einblick in potentielle Schwachstellen und können sie ausnutzen. Dabei ist es aber gerade diese Transparenz, die für ein sehr hohes Maß an Sicherheit sorgt. Durch die Zusammenarbeit der globalen Community ist der Code unter permanenter Beobachtung. So werden Schwachstellen rasch identifiziert und beseitigt. Und das oft viel schneller als bei proprietären Lösungen, bei denen niemand von außerhalb Zugriff auf den Code hat und Sicherheitsrisiken meist nicht mal öffentlich werden. Kurz gesagt: Bei proprietären Anbietern muss man Vertrauen haben, während man bei Open Source die Kontrolle hat - und das ist bekanntlich besser.

Open Source war deshalb auch für uns das optimale Werkzeug, mit dem wir Sicherheit und Funktionalität kombinieren können. Alles, was wir entwickeln, ändern, anpassen, können alle User jederzeit nachverfolgen. Wir haben die komplette Kontrolle über den Quellcode und das Endprodukt – und dadurch können wir immer nachvollziehen, wie Schwachstellen entstehen. Darüber hinaus erstellen wir für jedes Container-Image unserer Datenplattform eine öffentliche SBOM, also ein Software-Bill-of-Materials, mit der die Bestandteile des Produkts transparent werden und wir alle genutzten Komponenten nach potentiellen Risiken durchleuchten können.

Nur wer seine Supply Chain kennt, kann sie auch schützen. Und dabei kommt es auf Sorgfalt an: Nicht jede Schwachstelle ist eine Gefahr, aber trotzdem verdient jede Aufmerksamkeit. Es gilt, das Schwachstellenmanagement als fortlaufenden Prozess zu betrachten. Wer darüber hinaus auf quelloffene Lösungen setzt, verbessert seine Sicherheitslage entscheidend.

Über den Autor: Lars Francke gehört zu den gefragtesten Big Data- und Open Source-Experten im deutschsprachigen Raum. Über 10 Jahre hat er seine Expertise als Berater und Committer in verschiedenen Unternehmen und Organisationen eingebracht. 2020 hat er zusammen mit Sönke Liebau das Unternehmen Stackable gegründet.

Sicherheit ist mehr als nur ein Wert

CVE-Bewertungen unter die Lupe genommen

(ID:50774931)