Software-Lieferkette
Die fünf häufigsten Schwachstellen in der Software-Lieferkette vermeiden
Palo Alto Networks über Hintergründe und Schutzmaßnahmen
Alle Angriffe auf die Software-Lieferkette haben ein gemeinsames Hauptmerkmal: Sie ermöglichen es einem Angreifer, in den IT-Bereich eines Unternehmens einzudringen, indem er Software-Schwachstellen ausnutzt, die von anderen Stellen als dem Unternehmen selbst geschaffen wurden.
Die Arten von Schwachstellen, die Angreifer bei Angriffen auf die Lieferkette ausnutzen, sind vielfältig, ebenso wie die Methoden, die Angreifer anwenden. Um sich als Unternehmen vor Bedrohungen in der Lieferkette zu schützen, gilt es, die gängigsten Angriffswege in der Software-Lieferkette zu kennen und eine mehrgleisige Verteidigung gegen sie aufzubauen. Vor diesem Hintergrund erklärt Palo Alto Networks die häufigsten Angriffswege in der Lieferkette, vergleicht den Schweregrad der einzelnen Angriffsarten und beschreibt bewährte Verfahren zur Minderung von Schwachstellen in der Software-Lieferkette.
Was ist eine Software-Lieferkette?
Wer die Meldungen über die Zunahme von Angriffen auf Lieferketten verfolgt hat, weiß wahrscheinlich, dass eine Software-Lieferkette die Sammlung von Softwarekomponenten von Drittanbietern und die zugrundeliegenden Pipelines ist, die erforderlich sind, um Produkte auf den Markt zu bringen. Obwohl die Software-Lieferkette eines jeden Unternehmens einzigartig ist, umfassen ihre Komponenten in der Regel Folgendes:
- Open-Source-Bibliotheken oder -Pakete und Infrastruktur-als-Code-Module (IaC), die Entwickler in ihre eigenen Anwendungen einbauen.
- Versionskontrollsysteme (VCS), bei denen es sich um Anwendungen von Drittanbietern handelt, in denen firmeneigener Code gespeichert, versionskontrolliert und verwaltet wird.
- CI/CD-Pipelines, die in der Regel auf kommerziellen oder Open-Source-Grundlagen von Drittanbietern aufbauen, um Software zu integrieren, bereitzustellen und zu liefern.
- Infrastrukturdienste, z. B. die IaaS-Plattform eines Cloud-Anbieters, auf die sich das Unternehmen beim Hosten seiner Anwendungen verlässt.
- SaaS-Anwendungen, die auf der Infrastruktur eines Drittanbieters gehostet werden, aber Zugriff auf die Daten und Ressourcen des Unternehmens haben.
Es gibt kaum noch ein Unternehmen, das nicht auf die oben beschriebenen Softwareressourcen von Drittanbietern zurückgreift. Mit anderen Worten: Jedes Unternehmen hat eine Software-Lieferkette. Mehr noch: Jedes Unternehmen ist anfällig für Angriffe auf die Software-Lieferkette.
Wie es zu Angriffen auf die Lieferkette kommt
Bei einem Angriff auf die Software-Lieferkette liegt die Ursache des Problems in einer Schwachstelle in einer Pipeline, einem Dienst, einer Anwendung oder einer Softwarekomponente. Angriffe auf die Lieferkette sind insofern einzigartig, als sie in der Regel mit Schwachstellen im Code von Drittanbietern beginnen und nicht mit einer vom Unternehmen selbst erstellten Anwendung oder Ressource. Doch unabhängig vom Ursprung der Schwachstelle kann ein Unternehmen Maßnahmen ergreifen, um Angriffe auf die Lieferkette zu verhindern. Das Unternehmen kann anfällige Ressourcen erkennen und isolieren, bevor sie ausgenutzt werden.
Ein Beispiel wäre, dass eine der eigenentwickelten Anwendungen eine anfällige Open-Source-Bibliothek enthält. Das Unternehmen wäre nun dem Risiko eines Angriffs auf die Lieferkette ausgesetzt. Die Ursache für die Bedrohung ist die Schwachstelle in der Open-Source-Bibliothek, die Entwickler versehentlich in die Anwendung eingebaut haben. Unternehmen können jedoch einen Angriff auf die Lieferkette verhindern, indem sie die Schwachstelle identifizieren und entschärfen. Wenn Unternehmen auf eine neuere Version der anfälligen Open-Source-Bibliothek aktualisieren, bevor ein Angriff erfolgt, beseitigen sie die Schwachstelle und das damit verbundene Risiko. Wenn eine Schwachstelle ausgenutzt wird, bevor sie erkannt wird, können Unternehmen die Infrastruktur abschotten, den Zugang mit den geringsten Rechten aufrechterhalten und Kontrollen durchführen, um den Radius des Angriffs auf die Lieferkette zu minimieren.
Indem sie Maßnahmen zur Erkennung und Eindämmung von Bedrohungen ergreifen, können Unternehmen verhindern, dass sich Risiken in der Lieferkette auf den Geschäftsbetrieb auswirken. Dazu gilt es jedoch, die Probleme, die zu Angriffen auf die Lieferkette führen, genau zu verstehen. Jede Phase des Anwendungslebenszyklus kann neue Schwachstellen mit sich bringen, die Unternehmen entsprechend absichern müssen, damit Angreifer keinen Zugang zu ihrem System erhalten können.
Fünf allgemeine Sicherheitsprobleme in der Lieferkette
Da die Bedrohungen in der Lieferkette sehr unterschiedlich sind, müssen Unternehmen eine breite Angriffsfläche abdecken. Sie müssen die potenziellen Schwachstellen, die zu einem Angriff auf die Lieferkette führen können, berücksichtigen und sicherstellen, dass sie dafür gerüstet sind, die Schwachstellen zu verhindern.
1. Unsichere Anwendungskomponenten
In Fällen wie der Log4j-Schwachstelle sind anfällige Open-Source-Softwarekomponenten in Anwendungen integriert. Open-Source-Komponenten bieten zwar Plug-and-Play-Funktionen, die eine schnellere Markteinführung ermöglichen, können aber auch ein Risiko darstellen. Die Antwort auf diese Herausforderung ist der riesige (und wachsende) AppSec-Bereich. Entwickler sollten AppSec-Tools wie die Software Composition Analysis (SCA) verwenden, um anfällige Komponenten von Drittanbietern in ihrem Quellcode zu erkennen. Wenn Unternehmen ein SCA-Tool in ihr VCS einbetten, können sie betroffene Komponenten vor der Bereitstellung der Anwendung problemlos entfernen oder patchen.
2. Unsichere Container-Images
Ein weiteres Mittel, mit dem Schwachstellen in der Lieferkette in der Umgebung verbreitet werden, sind unsichere Container-Images. Die meisten Anwendungscontainer werden mithilfe von Basis-Images erstellt. Bei den Basis-Images handelt es sich in der Regel um Betriebssysteme wie Alpine oder Ubuntu Linux, die potenziell eine Vielzahl von Schwachstellen enthalten können. Wenn Entwickler einen Container mit einem anfälligen Basis-Image erstellen und den Container in der Produktion einsetzen, können die Schwachstellen im Basis-Image in die Produktionsumgebung gelangen.
Das Scannen von Container-Images ist die beste Möglichkeit, diese Bedrohung einzudämmen. Image-Scanner erkennen automatisch Schwachstellen im Basis-Image oder in anderen Schichten eines Containers und alarmieren dann die Entwickler, damit diese Maßnahmen ergreifen können, bevor unsicherer Code von Drittanbietern zu einem Angriffsvektor wird.
3. Unsichere IaC-Templates
IaC (Infrastructure as Code) ist eine gute Möglichkeit, die Bereitstellung von Infrastrukturressourcen in großem Umfang zu automatisieren. IaC kann aber auch eine vermeidbare Fehlkonfiguration in einem Template verbreiten und so mehrere mögliche Einstiegspunkte oder Gelegenheiten für Angriffe auf die Lieferkette eröffnen. Wenn Entwickler beispielsweise ein IaC-Template erstellen, das alle Server mit einem Betriebssystem ausstattet, das eine unsichere Bibliothek enthält, besteht das Risiko auf jedem Server, der mit diesem Template konfiguriert wurde. So war es auch bei der Version von OpenSSL, die den Heartbleed-Bug auslöste. Da IaC-Konfigurationen automatisch angewendet werden, ist die Wahrscheinlichkeit, dass ein Entwickler die Sicherheitslücke während des Bereitstellungsprozesses bemerkt, gering.
Vorhandene Cloud-Kontrollen können die Auswirkungen unsicherer Anwendungskomponenten oder Container auf die Sicherheit der Lieferkette abschwächen oder verstärken. Eine anfällige Bibliothek, die auf einer virtuellen Maschine mit Port 22 gehostet wird, kann beispielsweise ausgenutzt werden und eine Reverse Shell öffnen. Wenn ein anfälliger Container in einem Pod mit privilegiertem Zugriff besteht, haben Unternehmen ein viel größeres Sicherheitsproblem, als wenn dieser Container keine Host-Funktionen hätte. Die beste Möglichkeit, Fehlkonfigurationen vorzubeugen, besteht daher darin, die IaC-Templates frühzeitig und während des gesamten Entwicklungszyklus automatisch zu überprüfen. Durch die automatische Validierung von IaC-Konfigurationen über IDE-Plugins, CLI-Tools, VCS-Integrationen oder als CI/CD-Build-Schritte können Unternehmen Fehlkonfigurationen erkennen, bevor sie zu Risiken in der Lieferkette werden.
4. Unzureichende Zugriffskontrollen
In einigen Fällen werden Schwachstellen in der Lieferkette, die sonst vielleicht nur geringfügig sind, aufgrund unsicherer Zugangskontrollen zu großen Vorfällen. Ein Beispiel ist der Cr8escape-Bug, der es jedem, der die Erlaubnis hat, einen Kubernetes-Pod bereitzustellen, ermöglicht, den Pod zu verlassen und Code als Root-Benutzer auf dem Host-Node des Pods auszuführen. Die Schwachstelle resultiert aus einem Fehler in der Container-Laufzeitumgebung CRI-O. Jedes Unternehmen, das eine unsichere Version von CRI-O als Teil seiner Lieferkette verwendet, ist von dem Fehler betroffen.
In diesem Fall würden strenge Zugangskontrollen zwar nicht die Ursache des Risikos beheben (dazu müsste CRI-O auf eine sichere Version aktualisiert werden), aber sie würden die Chancen, dass Angreifer den Fehler ausnutzen können, erheblich verringern. Nur die Benutzer, die unbedingt die Berechtigung zum Erstellen von Pods benötigen, sollten daher diese Berechtigung erhalten. So lässt sich das Risiko minimieren, dass ein böswilliger Akteur den CRI-O-Bug ausnutzt, um einen Angriff zur Privilegienerweiterung zu starten.
5. Schwachstellen von CI/CD und Versionskontrolle
Versionskontrollsysteme (VCS) und CI/CD-Pipelines sind der Lebensnerv von Software-Lieferketten, da sie die Grundlage bilden, auf der Code – einschließlich Bibliotheken von Drittanbietern oder IaC-Module – gespeichert, kompiliert und bereitgestellt wird. Neben Schwachstellen und Fehlkonfigurationen können auch Schwachstellen in den zugrundeliegenden Lieferketten-Pipelines als Einfallstore für Angreifer dienen. Zur Bekämpfung von VCS-Schwachstellen sind die Durchsetzung von 2FA- und SSO- sowie Zweigstellenschutzregeln ein Muss. CI/CD-Pipelines stellen eine größere Herausforderung dar, da sie eine gewisse Öffnung nach außen erfordern. Die Verwendung unsanierter Metadaten und übermäßig privilegierter Mitwirkender kann zu bösartigen Injektionen und Datenlecks führen.
Das Scannen der VCS-Organisations- und Repository-Einstellungen sowie der CI/CD-Konfigurationsdateien ist eine gute Möglichkeit, das Risiko zu verringern, dass Angreifer Sicherheitslücken in Workflow-Konfigurationen ausnutzen.
Schutz für die Software-Lieferkette
Das Thema Sicherheit in der Software-Lieferkette ist noch jung und ist nach Erfahrungen von Palo Alto Networks bei vielen Unternehmen noch nicht vollkommen auf dem Radar. Es ist aber bereits klar, dass die Risiken in der Lieferkette am besten durch einen Sicherheitsansatz gemindert werden können, der automatisierte Sicherheitsprozesse in die bestehenden Systeme einbettet, um die Sicherheit so nahtlos wie möglich zu gestalten. Der Schutz der Software-Lieferkette erfordert Transparenz und Abdeckung aller Risiken durch IaC-Scanner, SCA-Software, Container-Image-Scanner, CI/CD- und VCS-Sicherheit. Der Einsatz vieler verschiedener Tools zur Erreichung dieser Ziele kann jedoch kompliziert werden. Ein integrierter und zusammenhängender Ansatz ist hilfreich, um eine reibungslose Codesicherheit einzuführen, die es Unternehmen ermöglicht, Bedrohungen in allen Teilen ihrer Lieferkette zu erkennen und abzuschwächen.
