Eine SBOM oder Software-Materialliste ist eine Liste der Komponenten und Abhängigkeiten, aus denen ein bestimmtes Softwareprodukt besteht. Sie enthält alle Bibliotheken, Module, Frameworks und andere externe Ressourcen, die für den Aufbau der Software und die Beziehungen zwischen ihnen erforderlich sind. Im Wesentlichen stellt eine SBOM die digitale Lieferkette für ein Softwaresystem dar. Und es ist jetzt von allen Anbietern erforderlich, die Software an die Bundesregierung verkaufen. Jeder andere, der Software erstellt oder betreibt, kann auch davon profitieren.
SBOMs sind seit mehr als einem Jahrzehnt Teil der Open-Source-Community, haben aber seit der Welle von Software-Lieferkettenangriffen auf US-Unternehmen und Regierungsbehörden in den Jahren 2020 und 2021 mehr Aufmerksamkeit in Cybersicherheitskreisen erregt.
Insbesondere der SolarWinds-Hack, bei dem Bundesbehörden, einschließlich des Department of Homeland Security und des Treasury Department, unwissentlich eine trojanisierte Komponente eingesetzt hatten, die es den Angreifern ermöglichte, Zugang zu den Computersystemen der Opfer zu erhalten, hat eine Exekutivanordnung ausgelöst, die Mai 2021 verlangt, dass jeder Anbieter, der Software an die Bundesregierung verkauft, seine Komponenten in einer SBOM detailliert.
Aufgrund der Komplexität der Software-Lieferkette kann eine einzelne Softwarekomponente einen überdimensionierten Einfluss auf ihre Sicherheit haben. Benutzer haben jedoch nur minimale Transparenz in die Komponenten, die in ihren geschäftskritischen Anwendungen verschachtelt sind. Eine Liste der Produkt-„Inhaltsstoffe“ kann ihnen eine bessere Vorstellung ihrer Sicherheitsrisiken geben und einen Fahrplan zur Verfolgung von Schwachstellen bereitstellen, bevor sie eine Krise verursachen.
Was ist der Ursprung der SBOM?
Der neue Schwerpunkt auf SBOMs entstand aus der Executive Order (EO) 14028 von Präsident Biden zur Verbesserung der Cybersicherheit der Nation, die das National Institute of Standards and Technology (NIST) und andere Bundesbehörden mit der Verbesserung der Cybersicherheit durch eine Vielzahl von Initiativen in Bezug auf die Sicherheit und Integrität der Software-Lieferkette beauftragt, um die Netzwerke der Bundesregierung besser zu schützen.
Der EO war größtenteils eine Reaktion auf die Zunahme von Cyberangriffen auf US-Unternehmen und die US-Regierung in den Jahren 2020 und ’21. Die Angriffe in diesem Zeitraum waren häufiger und schwerwiegender, wobei zwei der schädlichsten – SolarWinds und der Ransomware-Angriff der Colonial Pipeline – den EO anregten.
Beim SolarWinds-Angriff ermöglichte eine einzige trojanisierte Komponente in der Orion-Software des in Texas ansässigen Unternehmens, die zur Überwachung und Verwaltung von IT-Netzwerken und Infrastrukturen verwendet wird, Hackern den Zugriff auf die Systeme von Tausenden von Organisationen, einschließlich Fortune- 500 -Unternehmen, mehreren Bundesbehörden und sogar der US-Cybersicherheitsfirma, die schließlich den Verstoß entdeckte. Bis zu 18 000 Opfer aus dem privaten und öffentlichen Sektor haben die infizierte Software heruntergeladen, obwohl weniger in der Folge kompromittiert wurden.
Der Ransomware-Angriff Colonial Pipeline zielte auf eine einzige Organisation ab, hatte jedoch weitreichende Auswirkungen auf die Infrastruktur des Landes. Als das Unternehmen, das etwa 45 Prozent des Treibstoffs der Ostküste liefert, den Angriff entdeckte, war es gezwungen, kritische Computersysteme offline zu nehmen, um die Bedrohung einzudämmen und seinen Betrieb effektiv zu stoppen. Die daraus resultierenden Kraftstoffengpässe führten zu einer Hektik des Panikkaufs und einem Anstieg der Gaspreise.
[Lesen Sie auch: Was die Biden-Führungsanordnung für Tech Executives bedeutet]
Der EO spiegelt die aus diesen und anderen Sicherheitsvorfällen gewonnenen Erkenntnisse wider und versucht, die Zusammenarbeit im öffentlichen und privaten Sektor zu fördern, um immer raffiniertere Cyberangriffe abzumildern. Konkret beschreibt sie mehrere Ziele:
- Verbessern Sie den Informationsaustausch – Der EO weist darauf hin, dass alle vertraglichen Hindernisse für den Informationsaustausch zwischen der Regierung und dem privaten Sektor beseitigt werden und verlangt, dass IT-Dienstleister Informationen über Bedrohungen, Schwachstellen und Vorfälle weitergeben, die sich potenziell auf die Bundesregierung auswirken könnten.
- Modernisieren Sie die Cybersicherheit der Regierung – Der EO belastet die Bundesregierung mit der Einführung stärkerer Cybersicherheitsstandards und Best Practices. Dazu gehören die Einführung sicherer Cloud-Dienste, die Verwendung eines Zero-Trust -Sicherheitsmodells und die Implementierung von Multifaktor-Authentifizierungs- (MFA) und Verschlüsselungsroutinen.
- Stärkung der Sicherheit der Software-Lieferkette – Die Regierung muss grundlegende Sicherheitsstandards für die Softwareentwicklung für die Software festlegen, die sie von Auftragnehmern bezieht. Das Handelsministerium und die National Telecommunications and Information Administration (NTIA) müssen Elemente für eine Software-Materialliste veröffentlichen, die die einzelnen Komponenten auflistet und detailliert aufführt, aus denen ein Softwareprodukt besteht.
- Einrichtung eines Sicherheitsüberprüfungsgremiums für Cybersicherheit – Die Regierung wird ein Gremium einrichten, das von Experten der Regierung und des privaten Sektors gemeinsam geleitet wird und nach einem erheblichen Cybersicherheitsvorfall zusammentritt, um zu analysieren, was passiert ist, und Empfehlungen für Sicherheitsverbesserungen abzugeben.
[Lesen Sie auch: Der Kampfplan der US-Regierung zur Stärkung der Lieferketten]
- Erstellen Sie ein Incident Response Playbook – IT-Führungskräfte der Regierung müssen ein Standard-Playbook für die Reaktion auf Sicherheitsvorfälle entwickeln, um sicherzustellen, dass alle Bundesbehörden effektiv auf Cyberangriffe reagieren und ihre Schäden beheben können.
- Verbesserung der Vorfallserkennung – Der EO verlangt, dass ein regierungsweites Endpunkterkennungs- und Reaktionssystem (EDR) implementiert wird und dass der Informationsaustausch innerhalb der Bundesregierung verbessert wird, um Cybersicherheitsvorfälle besser zu erkennen.
- Verbesserung der Untersuchung und Behebung – Die Regierung erstellt Anforderungen an das Cybersicherheitsereignisprotokoll für alle Bundesbehörden, um die Untersuchung und Behebung von Cybersicherheitsvorfällen in Bundesnetzen zu verbessern.
Der EO legte unmittelbare Ziele für mehrere Regierungsbehörden fest, die sich erfüllen sollten, hat aber eine kaskadierende Wirkung in der gesamten bundesstaatlichen Vertragslieferkette. Konkret betrifft der EO drei Gruppen:
- Bundesexekutivagenturen – Regierungsbehörden auf oberster Ebene werden mit der Modernisierung ihrer Technologieumgebung und Sicherheitspraktiken beauftragt.
- Bundesauftragnehmer – Auftragnehmer, die Geschäfte mit der US-Regierung tätigen, einschließlich kommerzieller Standardsoftwareanbieter (COTS), können neue Cybersicherheitsstandards erwarten, die in Vertragsbedingungen integriert sind. Sie sind auch verpflichtet, weitere Informationen über Cybervorfälle weiterzugeben.
- Privatunternehmen – Privatunternehmen unterliegen neuen Cybersicherheitsgesetzen und einer verstärkten Durchsetzung bestehender Gesetze und Richtlinien mit einem stärkeren Fokus auf Software-Lieferkettensicherheit und der Meldung von Cybervorfällen. Darüber hinaus liegt ein größerer Schwerpunkt auf Transparenz durch vorgeschlagene Verbrauchersicherheitskennzeichnungen auf Software- und Internet of Things (IoT)-Geräten, was zu neuen Sicherheitsanforderungen und Bewertungsstandards für diese Anbieter führt.
Warum sind SBOMs heute wichtig?
SBOMs sind wichtig, da sie Organisationen dabei helfen können, Schwachstellen zu identifizieren und zu beheben, die in ihrer Software und ihren Abhängigkeiten vorhanden sein können. Moderne Anwendungen werden unter Verwendung einer Lieferkette von Softwarekomponenten entwickelt, die genauso kompliziert sind wie die von Herstellern physischer Waren. Eine typische App wird aus Dutzenden von Komponenten unter Verwendung einer Mischung aus proprietärem Code und wiederverwendbaren Komponenten von Drittanbietern erstellt. Während ein Entwickler jeden Code, den er geschrieben hat, auf Fehler und Fehler überprüfen kann, hat er weniger Einblick in den Code von Drittanbietern. Angreifer verstehen und nutzen dies, indem sie Komponenten von Drittanbietern anvisieren, die wissen, dass sie wahrscheinlich der Erkennung entgehen werden.
„Wenn eine Schwachstelle entdeckt oder offengelegt wird, können SBOMs dabei helfen, festzustellen, wo diese Softwareversion im Unternehmen verwendet wird.“
Neben dem jetzt berüchtigten SolarWinds-Vorfall hat eine Reihe von Lieferkettenangriffen in den letzten Jahren die verheerenden Auswirkungen hervorgehoben, die dieses Szenario haben kann. Angreifer nutzten eine kritische Schwachstelle in der Open-Source-Software Apache Log4j aus, einer nahezu allgegenwärtigen Protokollierungsbibliothek, die Aktivitäten in Millionen von Java-basierten Anwendungen aufzeichnet. Hacker nutzten auch vier separate Zero-Day-Schwachstellen in Microsoft Exchange Server, um Zugriff auf die Netzwerke von 30 000 US-Organisationen zu erhalten.
Eine SBOM kann einem Unternehmen helfen, sich besser vor diesen Arten von Lieferkettenangriffen zu schützen und sein Risikomanagement zu priorisieren. Zum Beispiel kann es SBOMs verwenden, um zuerst die Verwendung von Bibliotheken mit bekannten Schwachstellen zu eliminieren und dann sicherzustellen, dass es die neueste Version jeder Open-Source-Bibliothek verwendet. Wenn eine Schwachstelle entdeckt oder offengelegt wird, können SBOMs helfen, zu bestimmen, wo diese Softwareversion in der Organisation verwendet wird. Im Allgemeinen ermöglichen SBOMs Organisationen, fundiertere Entscheidungen über die Software zu treffen, die sie verwenden, und ermutigen Softwareanbieter, sicherere Produkte zu produzieren.
Was sind die Komponenten einer SBOM?
Im Jahr Juli 2021veröffentlichte die NTIA „Die Mindestelemente für eine Software-Stückliste“, die die Anforderungen der Bundesregierung an eine SBOM darlegt. Es unterteilt die Basiskomponenten einer SBOM in drei Kategorien: Datenfelder, Automatisierungsunterstützung sowie Praktiken und Prozesse. Sehen Sie sich die einzelnen genauer an.
Datenfelder
Datenfelder sollten jede Komponente effektiv identifizieren, damit sie über die Software-Lieferkette überwacht und gegen Schwachstellen- und Lizenzdatenbanken referenziert werden können. NTIA gibt sieben Datenfelder an:
- Name des Lieferanten: Der Name der Organisation, die die Komponente erstellt und identifiziert.
- Komponentenname: Der Name, der einer Softwareeinheit vom ursprünglichen Lieferanten zugewiesen wurde.
- Version der Komponente: Die Build- und Versionsdetails der Komponente, die in einem Softwareprodukt verwendet wird.
- Andere eindeutige Kennungen: Suchschlüssel und andere Informationen, wie z. B. eine Kennung aus dem CPE-Wörterbuch von NIST, die zur Identifizierung einer Komponente verwendet werden können.
- Abhängigkeitsbeziehung: Eine Beschreibung der Abhängigkeiten zwischen der Komponente und anderer Software. Zum Beispiel ist Komponente A in Software B enthalten.
- Autor der SBOM-Daten: Der Name der Organisation, die die SBOM-Daten der Komponente erstellt hat.
- Zeitstempel: Das Datum und die Uhrzeit, zu der die SBOM-Daten kompiliert wurden.
Automatisierungssupport
Da es Sicherheitsexperten nicht möglich ist, in jeder SBOM manuell nach kompromittierten Komponenten zu suchen, erfordert NTIA, dass jede SBOM Automatisierung über eines von drei maschinenlesbaren Formaten unterstützt:
- Zyklon DX
- Softwarepaket-Datenaustausch (SPDX)
- Software-Identifikations-Tags (SWID)
[Lesen Sie auch: Hier ist Ihr Sicherheitsautomatisierungs-Playbook für 2023]
Praktiken und Prozesse
Praktiken und Prozesse gewährleisten die Genauigkeit eines SBOM-Dokuments während des gesamten Lebenszyklus eines Softwareprodukts. NTIA beschreibt mehrere Mindestelemente, die behandelt werden müssen, darunter:
- Häufigkeit: Wenn eine Softwarekomponente mit einem neuen Build oder Release aktualisiert wird, muss eine neue SBOM generiert werden, um die neue Version der Software widerzuspiegeln. Dazu gehören Software-Builds zur Integration einer aktualisierten Komponente oder Abhängigkeit. Ebenso sollte der Lieferant, wenn er einen Fehler korrigieren oder Informationen in den vorhandenen SBOM-Daten aktualisieren möchte, eine neue, überarbeitete SBOM ausgeben.
- Tiefe: Eine SBOM sollte alle Komponenten der obersten Ebene enthalten und ihre Abhängigkeiten auflisten.
- Bekannte Unbekannte: Manchmal erkennen Entwickler, dass sie nicht alle Abhängigkeitsbeziehungen über eine Komponente kennen. In diesen Fällen sollte die SBOM klarstellen, dass die Daten unvollständig sind, und erklären, wo Beziehungen bestehen können.
- Verteilung und Bereitstellung: SBOMs sollten denjenigen zur Verfügung stehen, die sie zeitnah benötigen und über angemessene Zugriffsberechtigungen und Rollen verfügen.
- Zugriffskontrolle: Organisationen, die SBOM-Daten privat halten möchten, müssen die Bedingungen angeben, einschließlich Zulagen und Anpassungen für Benutzer, um SBOM-Daten in ihre Sicherheitstools zu integrieren.
- Fehlerbeseitigung: Da die Verwaltung von SBOM-Daten eine sich weiterentwickelnde Praxis ist, sollten die Benutzer gegenüber zufälligen Fehlern tolerant sein. Lieferanten sollten aktualisierte Daten anbieten, da Probleme in früheren SBOMs identifiziert werden, und Benutzer sollten diese Updates und Korrekturen ohne Nachteile begrüßen, um eine kontinuierliche Verbesserung zu fördern.
Die SBOM-Anforderungen werden wahrscheinlich weiter wachsen und sich weiterentwickeln. Weitere Datenfelder und das Hinzufügen von Sicherheitsbewertungen, Schwachstellenlisten und anderen Informationen können aktualisierte Richtlinien enthalten. Organisationen sind zwar nur verpflichtet, die Mindestanforderungen einer SBOM zu erfüllen, aber zusätzliche relevante Informationen über ein Softwareprodukt zeigen ein starkes Engagement für Transparenz und Sicherheit.
Was ist der Lebenszyklus der SBOM-Entwicklung?
Idealerweise sollten SBOMs automatisch generiert werden, wenn Software bereitgestellt wird, und ein möglichst vollständiges Inventar enthalten. Der Lebenszyklus von SBOM erleichtert dies, indem er einen Prozess zur Identifizierung von Anwendungen bereitstellt, SBOMs erstellt und sie Endbenutzern zur Verfügung stellt.
„SBOMs sollten automatisch generiert werden, wenn Software bereitgestellt wird, und so vollständig wie möglich ein Inventar enthalten.“
Sie besteht aus den folgenden fünf Phasen:
- Asset-Discovery: Die erste Phase besteht darin, die Anwendung zu finden, für die Sie eine SBOM bereitstellen müssen. Es wird bevorzugt, ein Asset-Discovery-Tool zu verwenden, um eine vollständige Visibilität in all Ihre Apps zu gewährleisten.
- Anwendungsdatenanalyse – Die für die SBOM erforderlichen Anwendungsdaten werden erfasst.
- SBOM-Erstellung – Die SBOM-Datei wird erstellt, einschließlich aller relevanten Anwendungsdaten. Dies sollte jedes Mal erfolgen, wenn eine neue Version der App veröffentlicht wird, um sicherzustellen, dass die SBOM immer mit dem aktuellen Status der Software übereinstimmt.
- SBOM-Speicher – SBOMs müssen zentral und sicher mithilfe von Verschlüsselung gespeichert werden.
- SBOM-Suchbarkeit – Die letzte Phase besteht darin, die Suchfunktionalität für die SBOM sicherzustellen, sodass der Endbenutzer potenzielle Schwachstellen suchen kann.
Welche SBOM-Standards gibt es?
Ein SBOM-Standard ist ein Schema zur Detaillierung der Zusammensetzung der Software in einer maschinenlesbaren Datei, die von anderen Tools wie Schwachstellenscannern und Softwarelizenz-Trackern verwendet werden kann. Derzeit gibt es drei Hauptstandards für die Erstellung von SBOMs und deren Weitergabe an Endbenutzer:
- SPDX – Der SPDX-Standard (Software Package Data Exchange), der von der Linux Foundation entwickelt wurde, ist ein weit verbreitetes Format zur Kommunikation von SBOM-Daten wie Komponenten, Lizenzen, Urheberrechten und Sicherheitsinformationen einer App in mehreren Dateiformaten.
- CycloneDX—CycloneDX ist ein weiterer offener Standard, der von der OWASP-Community entwickelt wurde. Es basiert auf dem SPDX-Standard, wurde aber optimiert, um die Implementierung und Verwendung zu vereinfachen
- SWID – SWID, die Abkürzung für Software Identification Tags, ist eine Art von Metadaten, die automatisch von vielen Anwendungen generiert werden können, um die Komponenten der Software zu beschreiben und zu kontextualisieren.
NTIA wählte diese drei SBOM-Standards als akzeptabel aus, da sie nicht nur menschenlesbar sind, sondern auch maschinenlesbar sind und Automatisierung unterstützen können, um es Endbenutzern zu erleichtern, SBOMs in ihrer gesamten Organisation zu verwenden und zu skalieren.
[Lesen Sie auch: Die Zukunft des Risikomanagements dreht sich um Automatisierung]
Was sind die Herausforderungen beim Erstellen und Verwenden einer SBOM?
Wie bei jedem neuen System birgt das Erstellen und Verwenden einer SBOM einige Herausforderungen.
Ein Haupthindernis ist die fehlende Standardisierung. SBOMs sind wahrscheinlich am effektivsten, wenn die gesamte Lieferkette dieselben Standards, Prozesse und Werkzeuge einhält. In diesen frühen Tagen gibt es jedoch wenig Konsens über diese, und ein Mangel an Einheitlichkeit zwischen Softwarelieferanten und Endbenutzern ist unvermeidlich. Dies kann zu mehr Zeit für die Dissektion und Anpassung von SBOMs an die Bestellung führen.
„SBOMs sind wahrscheinlich am effektivsten, wenn die gesamte Lieferkette dieselben Standards, Prozesse und Werkzeuge einhält. In diesen frühen Tagen gibt es jedoch wenig Konsens über diese.“
Eine weitere Herausforderung ist die Notwendigkeit, SBOMs kontinuierlich anzupassen. Jedes Mal, wenn es eine neue Version einer App gibt, muss sie eine neue SBOM enthalten, die den aktuellen Status der App widerspiegelt. Das macht es entscheidend, SBOM-Managementtools zu übernehmen, die die SBOM-Generierung in den Softwareentwicklungslebenszyklus integrieren können.
Die Skalierung von SBOMs, wenn Sie mehr Lieferkettenpartner übernehmen, kann auch ein Problem sein, wenn Sie herkömmliche Methoden verwenden, um sie zu generieren, wie Tabellenkalkulationen und E-Mail. Darüber hinaus sind diese manuellen Verfahren zeitaufwändig, fehleranfällig und können es schwierig machen, hierarchische Beziehungen zwischen Komponenten zu verfolgen.
Welche Best Practices gibt es für die Erstellung einer effektiven SBOM?
Die folgenden Best Practices können Ihnen helfen, effektive SBOMs zu erstellen:
- Verwenden Sie ein einheitliches Format – Es ist wichtig, bei der Strukturierung von SBOM-Daten ein Standardformat zu befolgen. SPDX, CycloneDX und SWID sind die beliebtesten Formate, aber letztendlich ist Ihre Formatwahl weniger wichtig als die konsequente Verwendung.
- Automatisieren Sie die Erstellung von SBOMs – Die automatische Erstellung von SBOMs als Teil Ihrer Softwarebereitstellungspipeline hat mehrere Vorteile. In erster Linie spart es Entwicklern Zeit, da sie nicht jede SBOM manuell erstellen müssen. Es macht es auch wahrscheinlicher, dass SBOMs regelmäßig Teil Ihres Softwarebereitstellungszyklus werden. Schließlich ermöglicht es Ihnen, die Anforderungen des Biden EO für die Bereitstellung von IT-Dienstleistungen an die Bundesregierung zu erfüllen.
- Aktualisieren Sie SBOMs mit jeder Version – Eine SBOM muss für jede Softwareversion spezifisch sein, auch wenn eine Anwendung aktualisiert wird. Automatisierung ist hier der Schlüssel; wenn Entwickler ihre SBOM mit jedem App-Update manuell aktualisieren müssen, ist die Wahrscheinlichkeit weitaus geringer.
- Vollständige Metadaten einschließen – Obwohl es keine universellen SBOM-Standards gibt, sollten Sie es zu einer Praxis machen, so viele Metadaten wie möglich in jede SBOM einzuschließen. Dadurch wird reduziert, wie viele Informationen Ihre Endbenutzer manuell nachschlagen und Ihr Engagement für Sicherheit und Transparenz demonstrieren müssen. Sie erleichtert auch die Aktualisierung.
