Kommentar zur Cybersicherheit für Wertschöpfungsketten „SBOMs jetzt in die Entwicklungspraxis integrieren“

Anbieter zum Thema

FTAPI Software GmbH

TXOne Networks

mongoDB

Setzt eine Cyber-Attacke an der „richtigen“ Stelle an, kann sie eine ganze Kettenreaktion entlang der Software Supply Chain auslösen. Das Implementieren einer SBOM, sprich Software Bill of Materials oder Software-Stückliste, sollte bei Unternehmen ganz oben auf der Prioritätenliste stehen.

Welches Potenzial Cyberattacken für Kettenreaktionen entlang ganzer Lieferketten haben wurde durch Ereignisse wie den SolarWinds-Hack deutlich. Auch in Deutschland waren Einrichtungen der öffentlichen Verwaltung vom Angriff auf den US-Hersteller betroffen, darunter Ministerien, Behörden und das THW.

Die US-Regierung reagierte mit einer strengeren Gesetzgebung, um die Sicherheit der Software-Supply-Chain im öffentlichen Sektor zu verbessern. Damit einher gehen Auflagen für Zulieferer, deren Lösungen dort eingesetzt werden. So wird ihnen auferlegt, eine so genannte Software Bill of Materials (SBOM) zur Verfügung zu stellen und damit offenzulegen, welche Komponenten in ihren Anwendungen stecken. IT-Sicherheitsexperten sollten darauf vorbereitet sein.

Warum SBOM?

Eine SBOM ist ein Inventar, eine Stückliste von Bestandteilen und Bibliotheken, die eine Software verwendet. Unternehmen müssen also sicherstellen, dass ihnen diese Informationen lückenlos vorliegen. Das klingt zunächst nach einer Selbstverständlichkeit, die es aber nicht ist, Beispiel Log4j.

Das Framework zum Loggen von Anwendungsmeldungen in Java ist ein Standard, der in vielen Open-Source- und kommerziellen Software-Lösungen steckt. Eine kritische Schwachstelle in Log4j führte Ende 2021 zu einem erheblichen Bedrohungspotenzial. Die Situation wurde dadurch verschärft, das viele Unternehmen nicht einmal wussten, ob und wo sie Log4j einsetzten.

Solche Bedrohungsszenarien sollen dank SBOMs der Vergangenheit angehören. Mit der Norm ISO 5962 wurde ein SBOM-Format international standardisiert. SBOMs werden in den kommenden Jahren zu einem unverzichtbaren Tool für die Sicherheit und Compliance von Wertschöpfungsketten werden.

Status quo: Die Definitionsphase läuft noch

Die Phase der Definition von Spezifikationen und Standards läuft noch. SBOMs benötigen eine sichere Backend-Schicht für die Speicherung und Integration. Entwickler wiederum benötigen ein Frontend, das Sicherheit in ihren Arbeitsablauf integriert, ohne die Produktivität zu beeinträchtigen. Noch gibt es keine marktreifen Implementierungen, doch das dürfte sich noch im laufenden Jahr 2022 ändern.

In einigen Branchen fordern Kunden schon heute SBOMs von ihren SaaS-Lieferanten. In Deutschland führt das novellierte IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) zu neuen Auflagen für Betreiber Kritischer Infrastrukturen (KRITIS), Bundesbehörden und Unternehmen im besonderen öffentlichen Interesse sowie deren Zulieferer. Diese Einrichtungen werden die ersten großen Nutzer von SBOMs sein und diese verstärkt nachfragen.

Kontrolle über Komponenten

Die Log4j-Schwachstelle belegte eindrucksvoll, welches Risiko von fehlenden Kontrollmechanismen hinsichtlich der „Zutaten“ von IT-Produkten ausgeht. Und dieses Ereignis war nur eines von zahlreichen sicherheitsrelevanten Vorkommnissen: Ripple20 – eine Serie von teils kritischen Sicherheitslücken in einer TCP/IP-Implementierung – gefährdete im Internet der Dinge vernetzte Geräte in Haushalt, Industrie und sogar Krankenhäusern und anderen Einrichtungen des Gesundheitswesens.

Diese Fälle machten deutlich, dass Hersteller teils nicht oder nur mit hohem Aufwand ermitteln können, welche Bibliotheken und andere „Third Party“-Komponenten in ihren Produkten stecken. SBOMs stellen dagegen eine kontinuierliche Überwachung aller eingesetzten Software-Komponenten sicher.

Mehr Kooperation und bessere Vernetzung

SBOMs besitzen das Potenzial, die Abstimmung zwischen Sicherheitsfachleuten zu erleichtern und zu beschleunigen, indem sie einen besseren und vollständigeren Informationsaustausch über Sicherheitslücken gewährleisten. Log4j, Ripple 20 und SolarWinds warfen ein deutliches Schlaglicht auf die Gefahren, die von unsicheren Software-Komponenten ausgeht.

Seitens öffentlicher Einrichtungen und Unternehmen, die IT-Lösungen für den öffentlichen Sektor liefern, ist das Interesse an sicheren Lieferketten hoch, um Ausfallrisiken mit potenziell schwerwiegenden Folgen (etwa im Bereich der kritischen Infrastrukturen) zu minimieren. SBOMs erleichtern den Austausch über relevante Informationen zu identifizierten Schwachstellen.

Automatisierung ist ein unerlässlicher Bestandteil für die Erstellung von SBOMs

Das BSI gibt in seinem Report zur Lage der IT-Sicherheit in Deutschland 2021 an, dass der Prozess der Überprüfung, ob eine bekannte Schwachstelle ein Produkt betrifft, in Kombination mit dem Common Security Advisory Framework (CSAF) innerhalb der Wertschöpfungsnetzwerke automatisiert werden kann.

SBOMs sind vor allem dann effizient, wenn sie in Verbindung mit Automatisierungslösungen bei der Erfassung und Erstellung eingesetzt werden. Dabei helfen so genannte SCA-Tools (Software Composition Analysis): Sie analysieren und verwalten Open-Source-Elemente von Anwendungen. Entwickler setzen sie ein, um die Lizenzierung zu überprüfen und Schwachstellen zu bewerten, die mit einzelnen Open-Source-Komponenten verbunden sind.

Kein einheitliches SBOM-Rahmenwerk

Ein klar definierter, einheitlicher und gestraffter SBOM-Prozess trägt zu einer reibungslosen Implementierung und zur Akzeptanz bei. Allerdings haben in den USA das staatliche National Institute of Standards and Technology (NIST) und die private OWASP (Open Web Application Security Project) Foundation bereits unterschiedliche Rahmenwerke definiert. Weitere dürften hinzukommen.

Unternehmen müssen deshalb agil genug sein, um unterschiedliche Rahmenwerke nutzen zu können. Sicherheitsverantwortliche erhalten dadurch eine Wahlmöglichkeit und können die beste Lösung für die Bedürfnisse ihres Unternehmens nutzen.

Fazit

SBOMs werden zu einem unverzichtbaren Baustein für die Softwaresicherheit und das kollaborative Risikomanagement in der Software-Wertschöpfungskette werden. Ihre Implementierung betrifft längst nicht nur Hersteller mit Geschäftsbeziehungen zum öffentlichen Sektor in den USA.

Angesichts der weiter gestiegenen Bedrohungslage ist die Sicherheit der Softwarelieferkette inzwischen für nahezu alle Unternehmen ein Thema; und der Kreis der rechtlich zur Bereitstellung der in SBOMs standardisierten Informationen verpflichteten Betriebe wurde mit dem IT-SiG 2.0 deutlich erweitert. Unternehmen sollten SBOMs – die es bereits seit 2018 gibt – spätestens jetzt in ihre Entwicklungspraxis integrieren.

* Lena Smart ist seit März 2019 bei MongoDB und verfügt über mehr als 20 Jahre Erfahrung im Bereich Cybersicherheit. Lena ist Gründungsmitglied von Cybersecurity at MIT Sloan (früher: Interdisciplinary Consortium for Improving Critical Infrastructure Cybersecurity), einem Konsortium, das es führenden Vertretern der Wissenschaft und des privaten Sektors ermöglicht, gemeinsam an den größten Sicherheitsproblemen zu arbeiten. Lena ist Mitglied von IT-ISAC, hält häufig Vorträge bei Branchenveranstaltungen und wurde bereits in Fortune, Dark Reading und CSO Online vorgestellt.

(ID:48564314)