Cybersecurity-Teams müssen SBOM-Mandate durchsetzen

Druckfreundlich, PDF & E-Mail

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 Unternehmen 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. Aus diesem Grund enthält die von der Biden-Regierung ausgestellte Durchführungsverordnung eine Bestimmung, dass jede Anwendung, die von einer Bundesbehörde verwendet wird, eine SBOM enthalten muss. Die Mehrheit der großen IT-Unternehmen werden diesem Beispiel wahrscheinlich folgen. IT-Teams sollten auch davon ausgehen, dass jede Cybersecurity-Versicherungspolice wahrscheinlich eine ähnliche Anforderung haben wird, um die Haftung zu begrenzen, indem sie den Zeitaufwand für das Patchen einer Anwendung verkürzt.

Die Linux Foundation, die Joint Development Foundation und die Open-Source-SPDX-Gemeinschaft 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. Es gibt auch den leichten SBOM-Standard CycloneDX, der auf einem Open-Source-Projekt basiert, das über die Open Web Application Security Project (OWASP)-Community erstellt wurde. Außerdem gibt es einen Software Identification Standard (SWID) für Tags, der von einigen Organisationen zum Erstellen von SBOMs verwendet wird.

Das „Manifest for Modern Cybersecurity“ postuliert, dass Unternehmen 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.

Nach oben scrollen
Twittern
Teilen
Teilen