Wie sich Angriffe durch den „Lieferanteneingang“ vermeiden lassen: SBOMs für Cloud-Services

Die Achillesferse der Lieferketten ist das Zusammenspiel von grenzenlosem Vertrauen und der undurchsichtigen Natur des Systems, vor allem wenn es um Cloud-Dienste geht. Als Lösungsansatz wird unter anderem darüber diskutiert, Software-Bill-of-Materials (SBOMs) einzuführen – maschinenlesbare Verzeichnisse, die alle Komponenten einer Lieferkette genau auflisten.

Im Juli 2021 sorgte der Kaseya-Hack für weltweite Schlagzeilen. Kaseya, ein Software-Dienstleister, der sich auf Tools zur Fernüberwachung und -verwaltung spezialisiert hat, wurde Opfer einer raffinierten Attacke. Angreifer nutzten eine Zero-Day-Schwachstelle in Kaseyas eigenen Systemen aus und verschafften sich so Zugriff auf Appliances, die von Kaseya-Kunden genutzt werden. Die Attacke führte zur Ausführung von bösartigem Code und setzte Ransomware bei den Kunden ein, die von den Appliances verwaltet werden. Von der Attacke betroffen waren nach Schätzungen etwa 50 Managed Service Provider (MSP) und etwa 1.500 Endkunden mit Tausenden von Systemen.

Weitaus größer war die Zahl der Betroffenen beim sogenannten SolarWinds Supply-Chain-Hack vom Dezember 2020. Dabei wurde die Management- und Überwachungssoftware von SolarWinds kompromittiert und als Teil eines Updates über deren eigenen Server verbreitet. Zehntausende Organisationen, darunter prominente MSP und Regierungsbehörden wie das U.S. Treasury und das U.S. Commerce Department, waren von diesem weitreichenden Angriff betroffen. Die Angreifer hatten über ein Jahr lang unerkannt in den Systemen verweilt, bevor die Attacke aufgedeckt wurde.

Diese und weitere Vorfälle werfen ein Schlaglicht auf ein bisher oft unterschätztes Problem: Angriffe über die IT-Supply-Chain. Der Begriff „Supply Chain“ (Lieferkette) beschreibt das Netzwerk aus zugelieferten Teilprodukten und Leistungen, die zusammen die IT-Infrastruktur einer Organisation bilden. Dies gilt allgemein für alle Produkte und Dienstleistungen, ganz besonders aber im Kontext von Software und Cloud-Diensten. In der Cloud-Supply-Chain setzt sich die Lieferkette oft wenig transparent aus einer Vielzahl von Lieferanten und Produkten zusammen.

Wenn Vertrauen unangebracht ist

Die Bandbreite der Produkte, die zur Cloud Supply Chain beitragen, reicht von der zugrunde liegenden Hardware über Betriebssysteme bis zu den Softwarekomponenten des eigentlichen Dienstes. Darüber hinaus sind Software und Komponenten enthalten, die entweder direkt (wie Bibliotheken) oder indirekt (wie Datenbanken oder andere Cloud-Dienste) integriert werden.

Diese wiederum sind Teil der Lieferkette, ebenso wie die Produkte, die zu ihrer Entwicklung beigetragen haben. Es kommt nicht selten vor, dass dieselben Komponenten in verschiedenen Versionen parallel verwendet werden. Das zentrale Problem im Bereich der IT-Sicherheit ist folgendes: Den verwendeten Komponenten wird ein erhebliches Maß an Vertrauen entgegengebracht. Bezogene Software und Dienste werden mit privilegierten Rechten betrieben. Das bedeutet, dass ein Angreifer, der über die Supply-Chain eindringt, diese Privilegien nutzen kann, um umfassenden Zugriff auf Systeme und Daten zu erlangen. Gleichzeitig ist die Supply-Chain oft undurchsichtig. Benutzer haben in der Regel keine Kenntnis über die einzelnen Komponenten, die in den von ihnen genutzten Diensten eingesetzt werden, und sind daher auf den Anbieter angewiesen, wenn es um die Sicherheit geht.

Dieses Problem tritt besonders stark auf, wenn es um Cloud-Dienste geht, die als Software-as-a-Service bereitgestellt werden. Hier ist die Lieferkette besonders komplex, und die Benutzer haben nur sehr begrenzte Einblicke und Einflussmöglichkeiten. Aber auch herkömmliche Software, die lokal betrieben wird, greift immer häufiger auf Cloud-Ressourcen zurück, beispielsweise über Cloud-APIs. Das Problem der privilegierten Vertrauensstellung in Verbindung mit mangelnder Transparenz erstreckt sich daher auch in die Tiefe der Supply-Chain.

Zwei weitere Beispiele sollen das Problem verdeutlichen: Im Dezember 2021 wurde eine gravierende Sicherheitslücke in der Java-Bibliothek Apache Log4J bekannt. Dieses Framework wird zur Protokollierung von Ereignissen und zur Verwaltung von Log-Daten in Anwendungen verwendet. Die Sicherheitslücke ermöglichte es Angreifern, auf einfache Weise beliebigen Code in den Server einzuschleusen und auszuführen, was zur Übernahme des Systems führte. Besondere Aufmerksamkeit erlangte diese Lücke, da Log4J in zahlreichen Softwareprojekten und Systemen weit verbreitet ist, darunter Webanwendungen, Server, Netzwerkkomponenten und andere Softwarelösungen.

Nach der Entdeckung der Lücke stellten sich viele IT-Verantwortliche die Frage, ob ihre Systeme betroffen waren. Die Antwort auf diese scheinbar einfache Frage erwies sich oft als problematisch, da die Transparenz über die in der IT verwendeten Komponenten fehlte. Dies erschwerte die Umsetzung von Schutzmaßnahmen gegen eine solche Sicherheitslücke praktisch.

Ein weiteres Beispiel aus der Vergangenheit ist der sogenannte „Heartbleed-Bug“, der im April 2014 in der weit verbreiteten OpenSSL-Softwarebibliothek entdeckt wurde. Diese Bibliothek wird zur Implementierung von SSL/TLS-Verschlüsselung in vielen Internetdiensten verwendet. Der Fehler ermöglichte es Angreifern, vertrauliche Informationen aus dem Speicher eines entfernten Servers auszulesen, ohne sich gegenüber dem Server zu authentifizieren.

Konkret konnte ein Angreifer manipulierte „Heartbeat“-Nachrichten senden, die dazu führten, dass der Server einen kleinen Teil seines Speichers zurücksendete, bis zu 64 Kilobyte. Dieser Speicherinhalt konnte sensible Daten wie Passwörter, private Schlüssel und andere vertrauliche Informationen enthalten, die normalerweise im Arbeitsspeicher des Servers gespeichert waren. Bei der Untersuchung der Schwachstelle stellte sich heraus, dass der fehlerhafte Teil der Software nur von zwei Open-Source-Entwicklern erstellt worden war und offenbar keine gründliche Codeprüfung stattgefunden hatte. Dennoch wurde diese Software weitreichend in vielen Anwendungen und Systemen, einschließlich solcher renommierter
Hersteller, eingesetzt.

Was Anwender zu Ihrem Schutz tun können

Es ist unzureichend, sich allein auf den Softwareanbieter oder den Betreiber eines Dienstes zu verlassen. Zwar sollten Anbieter und Betreiber die Sicherheit ihrer Software und Dienste
gewährleisten, aber im Falle einer Sicherheitslücke sind am Ende die Systeme und Daten der Anwender betroffen. Die Anwender tragen somit die Folgen eines Angriffs, selbst wenn
möglicherweise Haftungs- und Schadenersatzansprüche gegenüber dem Anbieter geltend gemacht werden können. Wie die zuvor genannten Beispiele verdeutlichen, sind selbst renommierte Anbieter nicht vor Sicherheitslücken gefeit. Daher sind Schutzmaßnahmen gegen Supply-Chain-Angriffe auch aufseiten der Anwender erforderlich.

Die erste Schutzmaßnahme besteht in der sorgfältigen Auswahl des Anbieters. Obwohl kein Anbieter eine hundertprozentige Sicherheit garantieren kann, reduziert eine sorgfältige Auswahl das Risiko. Hierbei sollte auch die Überprüfung der vom Anbieter ergriffenen Sicherheitsmaßnahmen, einschließlich Maßnahmen zur Prüfung der eingesetzten Komponenten
(wie Vulnerability Scanning und Patch-Management), einbezogen werden. Zertifikate über vom Anbieter durchgeführte Sicherheitsprüfungen können hilfreich sein, sollten jedoch daraufhin überprüft werden, ob sie Risiken aus der Supply-Chain angemessen berücksichtigen. Anwender sollten außerdem vertragliche Prüfrechte („Audit-Recht“) verlangen, die es ihnen ermöglichen, entsprechende Überprüfungen auch nach Vertragsabschluss durchzuführen.

Um effektive Schutzmaßnahmen planen und umsetzen zu können, ist ein umfassender Überblick über die zu schützenden IT-Assets erforderlich, einschließlich Systeme, Dienste und darin gespeicherte Daten. Hierbei kann ein IT-Asset-Management-System (ITAM-System) helfen. In jüngster Zeit wird auch der Einsatz von sogenannten „Software Bill of Materials“ (SBOM) diskutiert. SBOMs zeigen, welche Komponenten in einer Software enthalten sind, einschließlich solcher von Drittanbietern. Die minimale Anforderung für SBOMs ist die Angabe spezifischer Bezeichnungen und Versionen der eingebetteten Komponenten.

Um vollständige Transparenz und eine umfassende Risikobewertung zu ermöglichen, sollten Softwareanbieter und Cloud-Dienstbetreiber SBOMs für alle gelieferten Anwendungen und Dienste bereitstellen, einschließlich der wesentlichen Komponenten, die in ihrer Software enthalten sind oder genutzt werden. Diese SBOMs sollten bei jeder neuen Version und jedem Update aktualisiert werden, insbesondere in dynamischen Cloud-Diensten (Continuous Integration/Continuous Delivery, CI/CD). Die Erstellung und Bereitstellung von SBOMs sollte in den CI/CD-Prozess integriert werden. Die Inhalte der SBOMs sollten in den Schwachstellenmanagement-Prozess einfließen und als Grundlage für regelmäßige Scans gegen bekannte Sicherheitslücken dienen.

Die zunehmende Anzahl von Angriffen auf die IT-Supply-Chain hat auch das Interesse der Gesetzgeber geweckt. In den USA wurde beispielsweise im Mai 2021 eine Executive Order erlassen, die später vom US Department of Commerce und dem US National Institute of Standards and Technology (NIST) näher konkretisiert wurde.

Diese Verordnung schreibt vor, dass Lieferanten, die Software an die US-Regierung liefern, während der Entwicklung SBOMs verwenden und zusammen mit der Software bereitstellen müssen. In der EU ist der „Cyber Resilience Act“ in Vorbereitung, eine Verordnung, die Hersteller, Importeure und Händler von Produkten mit digitalen Elementen zur Umsetzung verschiedener Maßnahmen zur Verbesserung der IT-Sicherheit verpflichten wird, darunter die Bereitstellung einer Liste von Softwarekomponenten.

Obwohl diese Vorschriften und Empfehlungen zunächst auf Softwareanbieter abzielen, ist zu erwarten, dass insbesondere größere Benutzer SBOMs für interne Risikobewertungen ihrer IT-Systeme verwenden werden. Im Bereich kritischer Infrastrukturen wird die NIS-2-Richtlinie entsprechende Vorgaben machen. Daher ist anzunehmen, dass die Bereitstellung und Nutzung von SBOMs sich weit verbreiten und im Markt als Standard etablieren wird.

Für den Einsatz von SBOMs stehen verschiedene Formate und Standards zur Verfügung, wobei die Formate SPDX und CycloneDX im Kontext der IT-Sicherheit besonders zu empfehlen sind. Diese Standards werden auch in der im August 2023 veröffentlichten Technischen Richtlinie TR-03183 „Cyber-Resilienz-Anforderungen“ des Bundesamts
für Sicherheit in der Informationstechnik (BSI) genannt, die Softwareherstellern als Leitlinie zur Erhöhung der Sicherheit in der Software-Lieferkette dienen soll.

Fazit

Die Risiken aus der IT-Supply-Chain sind in den letzten Jahren deutlich sichtbar geworden. Cloud-Services sind aus Anwendersicht besonders betroffen, weil hier der größte Teil der Leistung eingekauft und der Anwender daher vom Lieferanten beziehungsweise vom Betreiber der Leistung abhängig ist. Anbieter und Anwender sind aufgerufen, alles zu tun, um die Sicherheit in der IT-Supply-Chain zu verbessern.

Besonders Software Bill of Materials (SBOM) können einen großen Beitrag zur Verbesserung der Sicherheit in der Supply-Chain leisten. Anwender sollten daher die Bereitstellung von SBOMs durch Provider in ihren Anforderungskatalog aufnehmen. Provider sollten ihrerseits ihren Anwendern diese Informationen zur Verfügung stellen.

Weitere Informationen zur Verbesserung der Sicherheit bei der Nutzung von Cloud-Services liefern die TeletTrusT Leitfäden Cloud Security und Cloud Supply Chain Security, erhältlich als Download unter https://www.teletrust.de/publikationen/broschueren/cloud-security/