Wissen, was drin steckt

von Martin Kuppinger

Angriffe über Schwachstellen in weit verbreiteter Software und viel genutzten Standardbibliotheken wie Log4j haben in den vergangenen Jahren für große Sicherheitsherausforderungen gesorgt. Das Konzept der Software Bill of Materials – SBOM – ist in den USA bereits vorgeschrieben und wird dank neuer EU-Gesetzgebung auch seinen Weg nach Deutschland finden. SBOMs sollen Informationen liefern, damit Unternehmen wissen, was in welcher Software an Komponenten steckt, sodass IT-Verantwortliche besser auf Angriffe und Schwachstellen reagieren können.

In den vergangenen Jahren gab es sowohl gezielte Angriffe auf die Software-Supply-Chain unter anderem bei Solarwinds und Kaseya als auch auf identifizierte Schwachstellen in weit verbreiteten Open-Source-Bibliotheken. Letztere waren beispielsweise 2014 Heartbleed, eine Schwachstelle in OpenSSL, oder Log4j im Jahr 2021. In beiden Fällen waren unzählige Systeme betroffen.

Bereits im Mai 2021 haben die USA in einer "Presidential Executive Order on Improving the Nation’s Cybersecurity" die Verpflichtung zur Bereitstellung einer "Software Bill of Materials" (SBOM) eingeführt. Die EU befindet sich im Abstimmungsprozess über den Entwurf des CRA (Cyber Resilience Act), der ebenfalls eine SBOM vorsieht. In Deutschland hat das BSI im August 2023 die technische Richtlinie TR-03183 Teil 2 veröffentlicht, in der es um "Cyber-Resilienz-Anforderungen" und im zweiten Teil konkret um SBOM geht. Der erste Teil mit den allgemeinen Anforderungen soll bis Ende 2023 veröffentlicht werden.

Hier besteht also konkreter Handlungsbedarf für alle Unternehmen, die Software als eigenständiges Produkt oder als Teil von Produkten wie Elektrogeräten oder Maschinen produzieren und weitergeben. Gleichzeitig bietet das Konzept der SBOM jedem Unternehmen die Chance, die Angriffsfläche besser zu verstehen und zu verwalten sowie schneller auf Bedrohungen zu reagieren.

Eine Stückliste für Software

Der Begriff "Bill of Materials" steht für Stückliste. Bei der Produktion physischer Güter gibt es die Stücklisten, aus denen sich ein Produkt zusammensetzt. Ebenso wird der weit überwiegende Teil moderner Software nicht mehr von Grund auf codiert und dann kompiliert, sondern nutzt in hohem Maße Standardbibliotheken wie eben die bereits Angesprochenen respektive Frameworks wie OpenSSL oder Log4j, die Funktionen wie SSL-/TLS-Verschlüsselung oder Logging bereitstellen. Ein sehr großer Teil solcher Bibliotheken entsteht quelloffen und ist damit frei verfügbar. Neben den grundlegenden Bibliotheken kommen in Software – ob in technischen Gütern, als eigenständige Anwendungen oder in Form von Clouddiensten – aber auch andere Dienste zum Einsatz. Gerade bei Cloudanwendungen sind dies typischerweise Clouddienste auf PaaS (Platform-as-a-Service) – von Datenbanken bis hin zu KI-Diensten.

Die Realität heute ist von komplexer, vielfach verschachtelter Software aus einer Vielzahl unterschiedlicher Quellen geprägt. Das schafft die Herausforderung, dass (bisher) schwierig nachvollziehbar ist, was genau in einer Software steckt und ob das eigene Unternehmen von einer neuen Schwachstelle betroffen ist. Im traditionellen Konzept führen Stücklisten die in einem Produkt enthaltenen Teile auf. Damit lassen sich im Fall von Fehlern in einer spezifischen Komponente eines Produkts die enthaltenen Teile einfacher lokalisieren und Fehler damit beheben.

Gleiches soll eine SBOM leisten, indem sie die Informationen über die "Software, die in Software steckt", in definierter und vollständiger Form bereitstellt. Damit sind Unternehmen in der Lage, zum Beispiel bei einer Schwachstelle in einer Open-Source-Bibliothek schnell zu identifizieren, welche genutzte Software und Dienste davon betroffen sein können. Damit sind gezielte Gegenmaßnahmen sehr viel schneller möglich.

Szenarien von Supply-Chain-Angriffen

Die verschiedenen Bedrohungen, die in den vergangenen Jahren über Software-Supply-Chains sehr viele Unternehmen betroffen haben, lassen sich in vier Gruppen unterteilen (wobei die vierte nur im weiteren Sinn hier einzuordnen ist):

- Schwachstellen in Standardbibliotheken

- Schwachstellen in Softwarekomponenten von Drittherstellern

- Infektion von COTS (Commercial of the Shelf Software, kommerzielle Softwareprodukte) für Angriffe auf deren Nutzer

- Angriffe auf Clouddienste und deren Mandanten

Exemplarisch für die erste Gruppe stehen die Schwachstellen in OpenSSL und Log4j. Wenn in Standardbibliotheken und -frameworks Schwachstellen entstehen, sind davon typischerweise sehr viele Softwareprodukte und deren Nutzer betroffen. Es kann sich dabei um Millionen von betroffenen Systemen handeln. Ein wesentlicher Unterschied ergibt sich daraus, dass Patches kommerzieller Anbieter wie Microsoft den betroffenen Systemen automatisch bereitgestellt werden, was dann eine automatisierte Installation erlaubt. Dieser Vorgang erfolgt dabei manchmal später als vom IT-Verantwortlichen erwünscht und auch nicht jeder nutzt die automatische Installation. Zwei wichtige Aspekte sind aber, dass damit bekannt ist, welche Systeme betroffen sind, und eine automatische Patch-Bereitstellung und -Installation möglich ist.

Auch für Open-Source-Komponenten werden natürlich schnell nach der Erkennung von Schwachstellen Patches entwickelt und bereitgestellt. Die Herausforderung ist aber, dass IT-Verantwortliche eben nicht die beschriebenen Automatismen für die betroffenen Systeme haben und vielfach nicht bekannt ist, welche Komponenten überhaupt verwendet werden.

Hinzu kommt als zweiter Fall, dass in der überwiegenden Zahl heutiger kommerzieller Softwareprodukte und Clouddienste neben Open-Source-Komponenten häufig auch Softwarekomponenten von Drittanbietern enthalten sind. Das gilt zum Beispiel auch für Microsoft, das freie Software an vielen Stellen in Produkten und Clouddiensten einsetzt. Ein anderes Beispiel sind Dashboards: Wer weiß schon, auf welcher technischen Basis diese in einer Software oder einem Cloudservice basieren? Ziemlich sicher ist, dass der Anbieter die dem Dashboard zugrundeliegende Funktionalität für die Darstellung von Diagrammen nicht selbst entwickelt hat, sondern eine andere Lösung nutzt. Und diese greift unter Umständen wieder auf andere Komponenten einschließlich Open-Source-Bibliotheken und -Frameworks zurück. Schwachstellen in Softwarekomponenten und Diensten von Drittherstellern stellen ebenfalls ein Software-Supply-Chain-Risiko dar. Das Konzept von SBOM soll auch hier Einsicht verschaffen.

Etwas anders gelagert ist der dritte Fall, also Szenarien wie die genannten Vorfälle bei Solarwinds und Kaseya. Dabei setzten die Angreifer auf weitverbreitete Software, um eine Tür zu deren Kunden zu öffnen. Der wesentliche Unterschied ist hier, dass über die Bereitstellung der Software, also entlang der Software-Supply-Chain, ein Angriff initiiert wurde, aber die in diesem Fall infizierte Software nicht mehr Bestandteil weiterer Anwendungen, sondern das Endprodukt beim Kunden war. Natürlich sind hierbei auch Angriffe über bewusst implementierte Schwachstellen in Standardbibliotheken und -frameworks nicht auszuschließen.

Der Vorteil im Vergleich zu Schwachstellen in Softwarebibliotheken und Drittprodukten ist, dass ein Unternehmen in der Regel genau weiß, dass es solche Software einsetzt. Andererseits kann, gerade wenn der Angriff über Managementsoftware für IT-Infrastrukturen erfolgt, schon längst Schaden entstanden sein und der Bösewicht Zugriff auf weitere Systeme haben, bevor eine solche Schwachstelle entdeckt wird und die Patches verteilt sind.

Im vierten Fall, beispielsweise dem Microsoft Exchange Server Data Breach im Jahr 2021, geht es darum, dass Angreifer erfolgreich einen Clouddienst oder andere kritische Systeme angreifen und darüber die Möglichkeit erhalten, die Mandanten oder Kunden solcher Dienste anzugreifen. Auch wenn die Problematik ähnlich gelagert ist, handelt es sich nicht im engeren Sinne um eine Software-Supply-Chain-Attacke, weil nicht die Lieferkette von grundlegenden Komponenten über beispielsweise PaaS-Dienste bis hin zum fertigen Cloudservice der Angriffsweg ist, sondern die bereitgestellte Cloudanwendung und dessen Nutzer.

SBOM als Weg zur Cyberresilienz

Deutlich zeigen aber alle Szenarien, wie komplex die Herausforderung ist, die sich durch die heutige Art der Softwareproduktion ergibt. Ebenso, wie Autos durch das Zusammensetzen eigener Teile und Komponenten von Zulieferern mit oft kritischer Bedeutung wie Bremsen entstehen, ist Software, ob in klassischer Form oder als Clouddienst, heute typischerweise ein Zusammenspiel von eigenem Code und von Komponenten aus dem Open-Source-Bereich und von Drittanbietern.

Während bei einem Auto manche Teile dabei "nur" zu Funktionsfehlern führen können, ist bei Software jede einzelne der Komponenten kritisch, weil diese eben nicht nur Funktionalität bereitstellt, sondern auch als Angriffsfläche dienen kann. Manche Komponenten – beispielsweise OpenSSL und die sichere Kommunikation – sind dabei heikler als andere, aber letztlich stellt jede ein Risiko dar.

Regulierung wird SBOMs zur Pflicht machen

Verschiedene Ereignisse haben dazu geführt, dass dieses Cyberrisiko inzwischen erkannt wurde. Die amerikanische NTIA (National Telecommunications and Information Administration) hatte bereits 2018 begonnen, die Arbeit an SBOM-Konzepten mit verschiedenen Beteiligten als gemeinsames Projekt zu koordinieren. An dieser Arbeit ist inzwischen auch die CISA (Cybersecurity & Infrastructure Security Agency) der USA beschäftigt, ebenso wie die amerikanische Standardisierungsorganisation NIST (National Institute of Standards and Technology).

Mit der amfangs erwähnten Executive Order des US-Präsidenten wurde in Abschnitt 4 das Thema "Enhancing Software Supply Chain Security" zur Verpflichtung gemacht, mit vergleichsweise kurzen Übergangsfristen. SBOMs sind ein Teil dieser Vorgaben, die aber auch generisch die Anforderung nach einer Verbesserung von sicheren Softwareentwicklungsprozessen (SDLC, Secure Development Lifecycle) umfassen.

Am 15. September 2022 hat die EU den Entwurf ihres Cyber Resilience Act (CRA) veröffentlicht und in die Konsultation gegeben. Dort ist die SBOM als Teil der Anforderungen an die Behandlung von Schwachstellen ebenfalls explizit vorgegeben. Das BSI hat dann Anfang August 2023 – letztlich auch im Vorgriff auf die finale Publikation und Inkraftsetzung der CRA – den Teil 2 der technischen Richtlinie TR-03183 veröffentlicht, die sich konkret mit der technischen Umsetzung von SBOMs beschäftigt. Diese Richtlinie ist damit ein unverzichtbares Dokument für alle Unternehmen, die Software produzieren, da sie die Vorgaben liefert und gleichzeitig auf die zu verwendenden Standards verweist.

Alle zentralen Regulierungen und Standards liefert Ihnen unser Link-Code-Kasten am Ende des Artikels. Deren unterschiedlichen Ansätze definieren auch, wann und in welcher Form Informationen in welchem Detaillierungsgrad bereitzustellen sind. Dabei geht es um die Balance zwischen dem Schutz vor Cyberbedrohungen und dem Schutz von geistigem Eigentum. Auf einer Verpackung von Lebensmitteln sind zwar die Inhaltsstoffe grundsätzlich aufgeführt, aber beispielsweise dann nur "künstliche Aromen" genannt, nicht aber die einzelnen Aromen und deren Mengenanteile, um nicht die Rezeptur an den Wettbewerb zu verraten. In gleicher Weise geht es auch bei SBOMs darum, die Balance zu finden. Ein wichtiges Element ist daher auch die Schwachstellenkommunikation durch Hersteller. CVEs (Common Vulnerabilities and Exposures) bilden die Basis für die Berichterstattung über Schwachstellen in definierter Form und mit einer einheitlich bewerteten Kritikalität nach dem CVSS (Common Vulnerability Scaling System).

Interoperabilität und Automatisierung

SBOMs sind bei der Vielzahl und Komplexität heute genutzter Software, die ja auch im IoT (Internet of Things) und Maschinen steckt, eine Herausforderung sowohl für die Ersteller von Software als auch für die Nutzer. Letzteren fällt die Aufgabe zu, die Informationen über neue Schwachstellen dahingehend zu analysieren, ob sie betroffen sind, um dann bedarfsweise Gegenmaßnahmen zu starten. Das erfordert Automatisierungsfunktionen, um diese Aufgabe schnell und zielgerichtet anzugehen und sowohl die Informationen zur "Nicht-Betroffenheit" als auch die gefährdeten Systeme und Dinge schnell zu identifizieren.

Inzwischen entwickeln und etablieren sich hier Standards in verschiedenen Bereichen, zunächst für das Format von SBOMs. Die Richtlinie TR-03813 des BSI schreibt vor, dass die SBOM als "CycloneDX" in der Version 1.4 oder höher oder als "SPDX" (Software Package Data eXchange) in der Version 2.3 oder höher vorliegen muss. Dabei handelt es sich um international etablierte Formate, was die Austauschbarkeit von Informationen der SBOM ermöglicht.

Ein zweiter Bereich betrifft den Austausch von Informationen über Schwachstellen. Hier steht das Konzept VEX (Vulnerability Exploitability eXchange) im Mittelpunkt, das von der U.S. NTIA entwickelt wurde. VEX ist als ein Profil im CASF (Common Security Advisory Framework) der OASIS Open implementiert und wird von CycloneDX als Teil von deren umfassenden SBOM-Framework unterstützt.

Zu erwähnen sind zudem noch die beiden ISO-Standards ISO/IEC 5230:2020 sowie ISO/EIC 5962:2021, die sich mit OpenChain respektive dem Datenaustauschformat SPDX beschäftigen und diese standardisieren. Bei OpenChain geht es spezifisch um SBOM im Open-Source-Umfeld.

Besseres Securitymanagement

Ein höheres Maß an Klarheit über die in Anwendungen enthaltenen Komponenten durch SBOM verbessert auch die Möglichkeiten für das Attack Surface Management (ASM). Dabei geht es darum, systematisch zu ermitteln, welche Angriffsflächen einer Organisation für Cyberangriffe ausgenutzt werden können. Zu ASM gehören viele unterschiedliche Elemente der Bedrohungsanalyse und des konkreten Testens auf Schwachstellen und deren Behebung.

Schwachstellen, die durch direkt in eigenentwickelten Applikationen oder indirekt durch Open-Source-Komponenten oder Software und Clouddienste von Drittanbietern entstehen, sind ein zentrales Element eines umfassenden ASM. Dazu gehört die Risikobewertung ebenso wie die kontinuierliche Überwachung von neuen Informationen wie CVEs, um auf neue potentielle Bedrohungen reagieren zu können.

ASM kann aber auch in hohem Maße von SBOMs profitieren, da mehr und schneller Klarheit darüber entsteht, ob eine konkrete Bedrohung besteht oder nicht. Letztlich bedeutet dies auch eine Verringerung von Risiken, weil es Unternehmen die Möglichkeit gibt, gezielt zu handeln. Bisher besteht dagegen häufig eine Unsicherheitssituation, weil die Information darüber fehlt, ob eine App oder ein Clouddienst von einer neu entdeckten, kritischen Schwachstelle betroffen ist oder nicht. Unsicherheit verhindert aber gezieltes Handeln oder erfordert erheblichen Aufwand, um zunächst zu klären, wie der Status ist. SBOMs werden diese Situation grundlegend verbessern.

Damit optimiert sich auch das Incident Response Management. Als beispielsweise Log4j auftauchte, haben auch sehr große Unternehmen mit einem starken Cybersecurity-Team zunächst viel Zeit damit verbringen müssen zu identifizieren, welche der eingesetzten Anwendungen betroffen sein könnten. Das bedeutet in der Konsequenz, dass das Zeitfenster für Angreifer länger offensteht, weil IT-Verantwortliche nicht unmittelbar handeln können und betroffene Systeme patchen, isolieren oder abschalten. Mit SBOMs im Zusammenspiel mit einem verbesserten und automatisierten Austausch über Schwachstellen (VEX) und der Automatisierung für das IT-Infrastruktur- und Software-Assetmanagement sowie für das Patchmanagement lassen sich hier massive Verbesserungen erzielen.

Informationen über Schwachstellen, deren Schweregrad und die Betroffenheit von Software und Diensten lasen sich automatisch verarbeiten, sodass Informationen über die betroffenen Systeme bereitstehen. Diese Informationen dienen wiederum dem Ergreifen automatischer Gegenmaßnahmen. Im Idealfall ist ein solcher Prozess weitestgehend automatisierbar, auch weil es bereits Standards gibt, um die entsprechenden Informationen auszutauschen.

Fazit

SBOMs sind ein wichtiges Konzept, dessen Umsetzung wird einerseits durch die regulatorischen Vorgaben zwingend. Sie bieten aber auch ein großes Potenzial, um die Prozesse für die sichere Softwareentwicklung zu verbessern und die Cyberresilienz zu erhöhen. Dies gerade auch durch die Automatisierung im Zusammenspiel mit den hier vorgestellten Werkzeugen wie IT-Assetmanagement, Patchmanagement und anderen. Schon durch die regulatorischen Anforderungen müssen Unternehmen handeln. Das gilt nicht nur für Softwareunternehmen, sondern in allen Bereichen, in denen Software Teil von Produkten ist – beispielsweise als Firmware. Unternehmen müssen sich jetzt mit SBOM und den Auswirkungen beschäftigen und sollten das Potential nutzen, um die Integration zwischen Softwareentwicklung und Cybersicherheit zu verbessern und Prozesse zu optimieren.

Software Bill of Materials soll Security verbessern