Cybersecurity-Teams müssen SBOM-Mandate durchsetzen

Cybersecurity-Manager sind gut beraten, wenn sie ab sofort von jeder bereitgestellten Anwendung eine Software-Stückliste (Software Bill of Materials, SBOM) verlangen.

Im Zuge der Log4j-Cybersecurity-Krise, die nach der Aufdeckung einer Reihe von Zero-Day-Schwachstellen in Java-Anwendungen entstand, wurde unter anderem deutlich, dass viele Organisationen nicht genau wussten, wie viele Instanzen des betreffenden Codes eingesetzt werden. Das Open Source Log4J-Tool für die Protokollverwaltung war kopiert und in Tausende von Java-Anwendungen eingefügt worden. Viele IT-Organisationen suchten wochenlang nach Code, der möglicherweise mit einem Patch-Update in wenigen Minuten behoben werden kann. Es wäre viel einfacher, wenn IT-Teams Zugang zu SBOMs hätten, die ihnen zuverlässig darüber Auskunft geben, welche Komponenten in einer bestimmten Anwendung enthalten sind.

Natürlich gibt es Tools, mit denen IT-Teams Binärdateien analysieren können, um automatisch eine SBOM zu erstellen. Allerdings bietet eine bereits während der Bereitstellung der Anwendung erstellte SBOM einen einfacheren Mechanismus zum Auffinden von Komponenten, wenn die Zeit drängt. Cyberkriminelle sind inzwischen viel geschickter darin, Schwachstellen innerhalb von Stunden nach der Offenlegung auszunutzen. Deshalb enthält die von der Biden-Administration erlassene Durchführungsverordnung eine Bestimmung, wonach jede Anwendung, die von einer Bundesbehörde verwendet wird, eine SBOM haben muss. Die meisten IT-Organisationen in Unternehmen werden wahrscheinlich diesem Beispiel folgen. IT-Teams sollten auch davon ausgehen, dass jede Cybersecurity-Versicherungspolice wahrscheinlich eine ähnliche Anforderung haben wird, um die Haftung zu begrenzen, indem der Zeitaufwand für das Patchen einer Anwendung verkürzt wird.

Die Linux Foundation, die Joint Development Foundation und die Open-Source-SPDX-Community stehen hinter der Software Package Data Exchange (SPDX)-Spezifikation für die Erstellung von Software-Stücklisten (SBOMs), die jetzt als internationaler Standard nach ISO/IEC 5962:2021 anerkannt ist. Außerdem gibt es CycloneDX, einen leichtgewichtigen SBOM-Standard, der auf einem Open-Source-Projekt basiert, das von der Open Web Application Security Project (OWASP)-Community ins Leben gerufen wurde, und einen Software Identification (SWID)-Standard für Tags, den einige Organisationen zur Erstellung von SBOMs verwenden.

Ein Manifest for Modern Cybersecurity postuliert, dass Organisationen alles verfolgen sollten, da man nicht schützen kann, was man nicht sehen kann. Eine Software-Stückliste ist der erste entscheidende Schritt zur Sicherung einer jeden Anwendungsumgebung. Die Herausforderung besteht darin, Entwicklern, die einfach nur Code schreiben möchten, zu erklären, warum sie eine genaue SBOM für ihre Anwendung erstellen müssen. Natürlich ist es am einfachsten, Entwicklern mitzuteilen, dass ihre Anwendungen ohne SBOM nicht in einer Produktionsumgebung ausgeführt werden dürfen. Cybersecurity-Teams werden staunen, wie schnell der Prozess der Erstellung einer SBOM im Rahmen eines DevOps-Workflows automatisiert wird.

Der optimale Vorfall im Bereich der Cybersecurity ist natürlich der, der nie stattgefunden hat. Eine einfache Software-Stückliste wird verhindern, dass viele Softwarekomponenten mit bekannten Schwachstellen überhaupt eingesetzt werden. Unvermeidlich wird es Zero-Day-Schwachstellen geben, die nach Bereitstellung einer Anwendung in einer Produktionsumgebung entdeckt werden. Eine SBOM macht jedoch den Unterschied aus, ob sich diese Schwachstellen nur als eines von vielen lästigen Ereignissen erweisen oder als Katastrophe aufgrund eines IT-Betriebsausfalls.