Best Practices für eine sichere Software-Supply-Chain

Die Schwachstelle in Log4j und die Folgen

Werfen Sie nur einen Blick auf die Log4j-Schwachstelle. Sie wurde Ende des Jahres 2021 bekannt (siehe auch Warnstufe Rot: Log4Shell gefährdet Server, Dienste und Apps). Seitdem beschäftigt sie zahllose Unternehmen. Haben Sie bereits herausgefunden, wie sich Log4j in Ihrer IT-Umgebung auswirkt? Es gibt mehrere Analysen, die Sie in diesem Zusammenhang durchführen sollten: Prüfen Sie zunächst die von Ihnen eingesetzte Software, also alle internen und auch die für Ihre Kunden bereitgestellten Lösungen, die aus Ihrem Hause stammen.

Verwenden sie die Log4j-Bibliothek in irgendeiner Form? Abhängig von dieser Frage gibt es weitere Punkte, die abgeklärt werden sollten: An welchen Stellen werden die Anwendungen genutzt? Wie sieht es mit der Middleware, also zum Beispiel Ihren Datenbanken aus? Welche Libraries nutzen ebenfalls Log4j? Darüber hinaus sollten Sie auch herausfinden, ob sich eventuell eine oder mehrere der von ihnen eingesetzten Anwendungen mit anderer Software verbindet, die dann wiederum selbst Log4j nutzt.

Eine Schwachstelle oder ein Risiko, das sich irgendwo entlang dieser Abhängigkeitsketten befindet, kann zu völlig unerwarteten Auswirkungen an ganz anderer Stelle führen. Solche Effekte sind nur sehr schwer vorauszusagen, da moderne Supply Chains äußerst komplex aufgebaut sind.

Es ist daher von größter Bedeutung, dass Ihr Sicherheitsteam die Softwarelieferketten genau versteht, die Ihr Unternehmen nutzt. Es gibt bereits einige offizielle Bestrebungen, diese Bemühungen zu standardisieren. So haben etwa die USA im Mai 2021 die Executive Order 14028 erlassen. Sie soll die Cyber-Defense des Landes stärken. Auch das National Institute of Standards and Technology (NIST) hat sich zum Beispiel mit einer Aktualisierung der Special Publication 800-161 beschäftigt. Sie hat das Ziel, das Risikomanagement in der Software-Supply-Chain zu erleichtern. Auch die Internationale Organisation für Normung (ISO) hat vor kurzem den Standard Software Package Data Exchange (SPDX) als ISO/IEC 5962:2021 für Softwarestücklisten angenommen.

Die meisten dieser Standards befinden sich derzeit aber noch in der Entwicklung. Bis diese abgeschlossen ist, müssen sich die meisten Unternehmen daher selbst behelfen. Zum Glück gibt es bereits eine Reihe von informellen Best Practices, die in der aktuellen Situation sehr hilfreich sind.

Die im Folgenden beschriebenen vier bewährten Verhaltensweisen sind natürlich nicht die einzigen, die zur Absicherung von Softwarelieferketten genutzt werden können. Es gibt zu viele Möglichkeiten, wie Unternehmen Software einsetzen, um sie alle abzudecken. Ihre ganz speziellen Anforderungen haben daher einen großen Einfluss auf die zu treffenden Maßnahmen. Die beschriebenen vier Best Practices haben sich aber bereits in der Praxis bewährt, da sie

• von den meisten Unternehmen angewendet werden können,
• mit einem relativ geringen Aufwand und Kosten umgesetzt werden können und
• außerdem über den Wert hinaus, den sie für Software-Lieferketten bieten, allgemein anerkannt gute Methoden sind.

1. Verstehen des Herstellungsprozesses bei Software

Zunächst ist es wichtig, die Prozesse zu verstehen, wie in Ihrem Unternehmen Software entsteht und wie sie in der Praxis eingesetzt wird.

Dafür eignen sich die folgenden Techniken:

• Modellierung des Bedrohungsmodells einer Anwendung,
• Entwurf von Prozessen für einen sicheren Software-Entwicklungs-Lebenszyklus,
• Bereitstellen von Methoden zum sicheren Entwickeln von Code,
• Penetrationstests für Anwendungen,
• statische und dynamische Tests der Anwendungssicherheit sowie
• spezielle Security-Trainings für die Programmierer.

Wenn Sie eigene Software in Ihrem Haus entwickeln, sollte dies so sicher wie nur irgendwie möglich erfolgen. Wenn Sie aber vor allem von anderen entwickelte Anwendungen nutzen, dann sind die im Weiteren vorgestellten Methoden ebenfalls dabei behilflich, sicherzustellen, dass sie so sicher wie nur möglich sind.

2. Erweitern Sie die Security-Awareness mit Softwarestücklisten

Wie gut die genutzten Entwicklungsprozesse verstanden werden können, hängt von den verschiedenen Komponenten in Ihrer Software ab.

Hier spielen Softwarestücklisten beziehungsweise auf Englisch Software Bill of Materials (SBOMs) eine große Rolle (siehe auch SBOM: Mit Softwarestücklisten Risiken reduzieren). Eine solche Liste ist im Prinzip eine Art Abhängigkeitskarte, die alle erforderlichen Bibliotheken, geteilten Objekte, Dynamic Link Libraries (DLLs), Middleware, Ressourcen und anderen Artefakte enthält. Jede Abhängigkeit hat jedoch meist wieder weitere Abhängigkeiten, die selbst wieder abhängig von anderen Bestandteilen sind – und so weiter und so fort.

Ein SBOM muss daher Daten über den gesamten Abhängigkeitsbaum enthalten oder zumindest über den Teil, der zum Zeitpunkt seiner Erstellung bekannt ist. Wenn Sie Software nur erwerben und nutzen, erhalten Sie durch eine solche Liste Informationen über die in den Lösungen eingebundenen und genutzten Komponenten. Nach und nach wird es zum Standard werden, dass die Kunden von ihren Softwarelieferanten solche Listen einfordern – und auch erhalten. Sie sollten Ihre Anbieter daher auch danach fragen. Selbst wenn ein Hersteller keine solche Liste präsentieren kann oder will, erhöht jede einzelne Anfrage den Druck auf ihn, zumindest in Zukunft für eine bessere Transparenz zu sorgen.

3. Wo, von wem und wie Software eingesetzt wird

Über jedes einzelne Teil einer Software informiert zu sein und genau zu wissen, welche Prozesse dabei genutzt werden, ist ein hervorragender erster Schritt zu ihrer Absicherung. Es ist aber ebenfalls wichtig, sich damit auseinander zu setzen, wo und wie sie eingesetzt wird, sobald sie in Ihrem Unternehmen angekommen ist. Nehmen wir wieder Log4j als Beispiel. Es ist für einen Anbieter eine Sache, Ihnen mitzuteilen, dass seine Software davon betroffen ist. Es ist aber ein ganz anderer Punkt, selbst genau zu wissen, wo und wie diese Software in Ihrem Unternehmen überhaupt genutzt wird. Nur dann können Sie geeignete Gegenmaßnahmen ergreifen.

Es gibt verschiedene mögliche Wege und Mittel, um herauszufinden, wie einzelne Softwarebestandteile genutzt werden und wofür. Eine dafür geeignete Methode ist, die Prüfung in die Analyse der Auswirkungen auf die Geschäftstätigkeit (Business Impact Analysis, BIA) aufzunehmen. Oft gehören solche Prüfungen bereits zur Planung der Business Continuity im Unternehmen.

Bei der Durchführung einer BIA werden die verschiedenen Abteilungen gefragt, welche Anwendungen und Systeme sie einsetzen. Damit wird erreicht, dass sie bei einer Katastrophe oder wenn es zu einem Ausfall kommt, weiterarbeiten können. Die durch eine BIA erfassten Daten können aber auch für andere Zwecke genutzt werden. So lässt sich mit ihnen leicht herausfinden, wo überall im Unternehmen eine bestimmte Software genutzt wird, bei wem und aus welchem Grund.

4. Daten verwertbar machen und für Verbesserungen nutzen

Nach dem Sammeln der Daten, wie in den drei vorherigen Schritten beschrieben, ist es an der Zeit, sie einem sinnvollen Einsatz zuzuführen. Machen Sie die Daten verwertbar, indem Sie sie in ein Framework und in Ihre Prozesse integrieren. Für manche Unternehmen hängt dies eng mit den Maßnahmen zum Risikomanagement zusammen. In einem solchen Fall sollten Sie die über die Softwarelieferketten gesammelten Daten – abhängig von den Auswirkungen auf Ihre Risikotoleranz – auch in Ihr Risikomanagement integrieren.

Nutzen Sie die Risikoprofile, um potenzielle Auswirkungen besser einschätzen und um sie mit den bereits vorhandenen Mechanismen zum Überwachen und Berichten über erkannte Risiken verbinden zu können. Wohl am wichtigsten ist aber, dass auf Basis der gesammelten Daten auch Maßnahmen zum Reagieren auf erkannte Risiken festgelegt werden sollten. Daher ist nicht nur von Bedeutung, welche Software eingesetzt wird, sondern auch woher sie stammt, was sie enthält und wer sie alles nutzt.