Nie wieder Log4Shell: freie Werkzeuge bannen Open-Source-Sicherheitslücken

Inhaltsverzeichnis

Eine auf den ersten Blick unbedeutende Sicherheitslücke in Log4J deckte eine gravierende Schwachstelle bei den meisten Firmen auf: Eigentlich handelt es sich nur um eine Bibliothek, die das Logging in Java-Programmen vereinfacht – doch bei den meisten Unternehmen herrschte gar kein Überblick über die eingesetzten Open-Source-Pakete, auf denen die eigene Software basiert. In Folge mussten Administratoren in kleineren IT-Abteilungen im Alleingang jede Anwendung durchforsten und in Konzernen panisch Excel-Tabellen zusammenstellen, in denen Verantwortliche einer Applikation eintragen sollten, ob in ihr das betroffene Paket zum Einsatz kommt – Rückmeldung am besten bis gestern! Dabei gibt es schon lange ein Konzept, das all dem Chaos Abhilfe geschaffen hätte: Software Bill of Materials, kurz SBOM.

Materiallisten für Software

Jede moderne Applikation basiert auf Paketen, die nicht aus eigener Hand stammen, sondern über Paketmanager wie Maven für Java, NPM für JavaScript oder Packagist für PHP frei verfügbar angeboten werden. Hierbei handelt es sich nicht nur große Frameworks, sondern auch Pakete, die den Umgang mit Zeit- und Datumsformaten vereinfachen oder eben erweiterte Funktionen für das Logging bieten. Gerade diese finden sich in nahezu jeder Anwendung wieder. Dementsprechend groß sind die Auswirkungen, wenn Angreifer eine Schwachstelle in ihnen finden. Deshalb ist es als Unternehmen wichtig, sich einen Überblick über das zu verschaffen, was da so im Hintergrund werkelt. In der Industrie sind Materiallisten schon lange verbreitet: Für jedes Endprodukt ist bekannt, welchen Stahl man von welchem Hersteller und aus welcher Charge verbaut, um bei Materialmängeln genau zu wissen, welche Produkte man zurückrufen muss. Genau dieses Konzept lässt sich auf die Softwareentwicklung übertragen, denn die SBOM enthält alle Pakete und Services, von denen ein Programm abhängig ist und fasst sie mitsamt ihrer Version in einem Dokument zusammen. Wenn eine bestimmte Version eines Pakets von einer Sicherheitslücke betroffen ist, reicht ein Blick in die SBOMs der eigenen Anwendungen, um Auswirkungen auf die eigene IT festzustellen.

CycloneDX

Für dieses Konzept gibt es mehrere Implementierungen. Am verbreitetsten ist CycloneDX, das direkt die OWASP Foundation entwickelt und unter einer Open-Source-Lizenz steht. Die Ausgabe erfolgt in JSON oder XML und umfasst neben den Metadaten des beschriebenen Programms alle abhängigen Pakete sowie externen Dienste, die es einbindet. Wenn es also Aktienkurse über eine externe Schnittstelle bezieht, findet sich letztere dort wieder. Das Format kann Applikationen, Container, Betriebssysteme und Firmware, aber auch Bibliotheken und Frameworks beschreiben. Analog zu Lieferketten in der Industrie kann man in einer SBOM außerdem einen Abhängigkeitsbaum – auch Dependency Tree genannt – aufnehmen. Sollten beim Erstellen bereits Sicherheitslücken bekannt sein, kann CycloneDX sie ebenfalls im Dokument berücksichtigen. Den vollständigen Aufbau der Spezifikation zeigt die Abbildung. Darüber hinaus lassen sich noch andere Bill of Materials (BOMs) für die IT erzeugen, so gibt es eine Software-as-a-Service-BOM (SaasBOM), eine Operations-BOM (OBOM) und eine Manufacturing-BOM (MBOM).

SBOMs im Unternehmen etablieren

Um sich das Log4J-Chaos zu ersparen, muss für möglichst viele Anwendungen eine SBOM existieren. Ausschließlich so kann die Betroffenheitsanalyse komplett auf diesen SBOMs basieren. Im ersten Schritt der Einführung muss man also eine möglichst hohe Abdeckung erreichen: Für im eigenen Unternehmen entwickelte Programme bieten sich Werkzeuge an, die in ihren Continuous Integration Pipelines automatisch eine SBOM generieren. Das CycloneDX Tool Center kann mit allen gängigen Programmiersprachen umgehen und macht diesen Schritt zum Kinderspiel. Um zusätzlich zugekaufte Applikationen abzudecken, sollte man den jeweiligen Entwickler bitten, mit jeder neuen Version eine SBOM mitzuliefern. In den USA sind Anbieter hierzu gar mit einer Executive Order des Weißen Hauses im Mai 2021 verpflichtet worden – entsprechend gut vorbereitet sind große Softwarehäuser also. Falls im eigenen Unternehmen formalisierte Change- und Release-Prozesse existieren, bietet es sich an, die SBOM für jede neue Version verpflichtend als Dokument anzufordern und so die Anwendungslandschaft größtmöglich abzudecken.

SBOMs dezentral analysieren

Sobald die – idealerweise gesamte – Anwendungslandschaft mit SBOMs beschrieben ist, können Unternehmen Prozesse und Werkzeuge etablieren, die die SBOMs mit Schwachstellen-Datenbanken abgleichen und im Falle eines Treffers Alarm schlagen. Schließlich ist allein mit einer SBOM noch nicht viel getan, um Schwachstellen zu identifizieren – sie listet lediglich auf, auf welchen Komponenten eine Software basiert. Für den Abgleich gibt es im Wesentlichen zwei unterschiedliche Ansätze: Erstens lassen sich SBOMs dezentral direkt nach ihrem Erstellen zum Beispiel in der CI/CD-Pipeline auf Schwachstellen prüfen. Dafür bietet sich etwa Dependency Check an, ein weiteres Open-Source-Werkzeug, das die OWASP Foundation entwickelt. Das Kommandozeilenprogramm überprüft, ob für die aufgelisteten Pakete ein Eintrag in der Datenbank für Common Vulnerabilities and Exposures (CVEs), die weltweit größte Datenbank für Schwachstellen, existiert. In größeren Unternehmen gerät bei diesem dezentralen Ansatz jedoch schnell die Übersicht verloren: Selbst bei nur 100 Applikationen und Abhängigkeiten zu jeweils über eintausend Paketen, kommt schnell ein Blumenstrauß von Schwachstellen zusammen, den die Administratoren irgendwie verwalten müssen. Deswegen benötigen IT-Sicherheits-Teams in Konzernen eine zentrale Sicht auf die Dinge.

Continuous Security Monitoring

Für genau diesen zweiten Bedarf gibt es das freie Dependency Track der OWASP Foundation. Statt sie direkt in der Pipeline zu analysieren, hinterlegt das Tool jede Applikation – ob selbst entwickelt oder eingekauft – auf der Plattform mit seiner SBOM und überprüft sie in regelmäßigen Intervallen auf Schwachstellen. Dashboards zeigen den Status quo der Anwendungslandschaft, über nennenswerte Änderungen informieren verschiedene Kanäle wie E-Mail, Microsoft Teams oder Slack.

Dependency Track verfügt über eine API und lässt sich über sie automatisiert mit den neuesten SBOMs der eigenen Software versorgen. Ist die SBOM in der CI/CD-Pipeline erstellt und direkt über die API auf Dependency Track geladen, spricht man von Continuos Security Monitoring – also der vollautomatischen Analyse aller Komponenten. Dies sollte das Ziel sein, denn nur dann entsteht für die Entwickler keinerlei Aufwand: Sind alle SBOMs hinterlegt, lassen sich bei einzelnen Programmen alle Schwachstellen und deren Schweregrad überblicken oder für eine einzelne Schwachstelle alle betroffenen Anwendungen auflisten.

Fazit

Seit Jahren steigt die Anzahl von Open-Source-Paketen und ihrer Downloads auf dem Paketmanager NPM für JavaScript. Gleichzeitig kennt auch die Anzahl von CVE-Einträgen nur eine Richtung: nach oben. Die Frage ist also nicht, ob eine Sicherheitslücke mit Auswirkungen wie bei Log4J noch einmal auftaucht, sondern wann sie es tut. Mit jeder abgelösten Altanwendung steigt die Wahrscheinlichkeit, betroffen zu sein. Unternehmen müssen jetzt Prozesse etablieren, die automatisiert SBOMs analysieren, Alarme verschicken und die betroffenen Anwendungen mit einem Klick auflisten. Nur so gibt es statt überarbeiteter Administratoren samt Excel-Chaos die Klarheit und Zeit, um sich auf das zu konzentrieren, was beim Schwachstellenfund im Mittelpunkt stehen sollte: die Mitigation der Sicherheitslücke.

Quellen und Links:

• Vergleich von SBOM-Implementierungen
• CycloneDX: Spezifikationen
• CycloneDX: Tool Center
• Dependency-Check
• Dependency Track

(fo)