Synopsys SIG

Der laxe Umgang mit der Security

24. August 2022, 10:39 Uhr | Lucas von Stockhausen
Der laxe Umgang mit der Security
© vectorfusionart – adobe.stock.com

Mitte Dezember 2021 wurde in der Java-Bibliothek Log4j die Schwachstelle „Log4Shell“ entdeckt. Ein Vorfall der am Image von Open Source nagt. Wie ist Schadensbegrenzung bei der Verwendung von Open Source möglich?

Die Java-Bibliothek Log4j ist sehr weit verbreitet. Systemadministratoren und Programmierer auf der ganzen Welt binden die Bibliothek aufgrund ihrer Funktionalität in Rechenzentren, Unternehmensserver, Netzwerktechnologien und Systemkomponenten ein. Die Sicherheitslücke Log4Shell war zu Beginn besonders leicht auszunutzen. Einmal im System konnten Angreifer beliebigen Programmcode ausführen, Schadsoftware nachladen oder Daten stehlen. Im Endeffekt führte dies zur potenziellen Verwundbarkeit von global mehreren Milliarden Computern.

Die Log4Shell-Schwachstelle führt erwartungsgemäß zu einem vorhersehbaren Ergebnis: Führungskräfte und Regierungen sind zunehmend besorgt, wenn der Begriff Open Source fällt. Den meisten von ihnen ist nicht unbedingt bewusst, dass ein Großteil der Software, die sie erfolgreich verwenden, nicht von kommerziellen Anbietern, sondern von Freiwilligen entwickelt wird. Inzwischen kommt selbst bei einigen der kritischsten Systemen Open-Source-Software zum Einsatz. Was es allerdings häufig in Unternehmen nicht gibt, ist eine Liste sämtlicher Open-Source-Software, respektive aller verwendeten Komponenten. Schwerwiegende Vorfälle aus der Vergangenheit wie HeartBleed, Dirty Cow und die Erfahrungen mit Apache Struts und dem daraus resultierenden Datenschutzvorfall bei Equifax haben zu Überprüfungen seitens staatlicher Stellen geführt. Nicht selten sollen dann die „schlechten“ Open-Source-Komponenten, in diesem Fall log4j, durch eine vermeintlich sicherere Alternative ersetzt werden.

Forum Safety&Security 2022

Vom 21. bis 22. September 2022 dreht sich in der Hochschule Landshut alles um das Thema Sicherheit in IT und OT. Das Programm steht jetzt online. 

Schon die Keynote nimmt die Teilnehmer mit in die ‚digitale Unterwelt‘ und widmet sich der ‚Anatomie eines Angriffs‘: Der Referent Tim Berghoff, Security Evangelist bei G Data CyberDefense, nimmt die Teilnehmer auf eine imaginäre Reise von der Sicherheitslücke bis zur Erpressernachricht mit. Denn: Niemand kann vor Angriffen sicher sein.

Nach diesem Auftakt geht es zweigleisig weiter: Während sich der eine Track den Methoden und Tools in Sachen Safety und Security widmet, taucht der andere Track tief in die Sicherheitsaspekte und -problemstellungen von Anwendungen ein.

>>> Hier finden Sie das Programm!

>>> Hier geht es direkt zur Anmeldung!

Bei all diesen Szenarien wird ein Aspekt von Open-Source-Software in unserer modernen Gesellschaft aber gerne und häufig übersehen: Open Source genießt sehr hohes Vertrauen.

So hoch, dass sie in manchen Unternehmen frei heruntergeladen und verwendet werden darf, wie sie ist, und zwar ohne nennenswerte Sicherheitsüberprüfungen. Oder anders herum formuliert: Eine aus dem Internet heruntergeladene Software wird selten so überprüft wie die selbst entwickelte Software. Sie zweifeln daran? Fragen Sie sich, wer in einem Unternehmen Docker oder libxml oder auch eine Open-Source-Datenbank (auf die etliche Anwendungen angewiesen sind) auf Sicherheitsprobleme hin überprüft hat. Und selbst wenn: Höchstwahrscheinlich gab es nur einen einzigen Prüfdurchgang, und der wird kaum bei jedem Update wiederholt werden. Dies ist durchaus ein starker Vertrauensbeweis für Open Source.

Die Software Supply Chain

Die Gründe, sich für Open-Source-Technologien zu entscheiden sind vielfältig, können aber in drei Hauptbereiche unterschieden werden:

  • Erstens verzichtet Open-Source-Software oftmals auf eine Lizenzgebühr. Das ist schon allein deshalb attraktiv, weil man sich nicht mit Budgetfreigaben oder Nachprüfungen bei der Vergabe herumschlagen muss.
  • Zweitens ist es sehr wahrscheinlich, dass die betreffende Open-Source-Technologie von einem Experten für genau dieses Gebiet entwickelt worden ist. Würde man so einen Experten intern beschäftigen wollen, würde das komplex oder teuer.
  • Und drittens bieten Open-Source-Technologien nicht selten eine populäre Lösung für ein allfälliges Problem. Beispielsweise gibt es viele Optionen für die Container-Orchestrierung, aber Kubernetes hat die Nase vorn – das heißt, die Implementierung genießt sowohl bei Fachleuten als auch bei Wettbewerbern ein hohes Vertrauen.

Was in der Diskussion um die Akzeptanz verloren geht, ist, dass Open-Source-Software, genau wie kommerzielle Software, oft aus mehreren Komponenten besteht. Es gibt weder eine einzige ausführbare Linux-Datei noch eine einzige ausführbare Kubernetes-Datei. Jede einzelne erfordert eine beträchtliche Anzahl von Abhängigkeiten. Das Gleiche gilt für mobile Anwendungen, IoT-Firmware und sogar simple Logikfunktionen bei geschäftlichen Anwendungen, wie sie über AWS Lambda bereitgestellt werden. Sie alle weisen Abhängigkeiten auf, die notwendig sind, damit die Anwendung richtig funktioniert.

Wenn Leute dann von einer „Software Supply Chain“ sprechen, ist es diese Liste von Abhängigkeiten, auf die sie sich beziehen, und es ist auch genau diese Liste von Abhängigkeiten, in der das größte Risiko bei Open Source liegt.

Die Frage der Resilienz

Wenn ein Open-Source-Projekt ausreichend weit verbreitet ist, um zu einem De-Facto-Standard zu werden, wie etwa Kubernetes, dann arbeiten viele freiwillige Entwickler am Code. Manch ein Unternehmen stellt sogar Entwickler ab, welche sich ausdrücklich nur um Kubernetes kümmern. Das bedeutet Resilienz. Wenn ein Entwickler pausiert oder sich ganz aus dem Projekt zurückzieht, geht es trotzdem weiter. Populäre Projekte verkraften es deshalb sogar relativ gut, wenn sich zentrale Entwickler verabschieden.

Bei kleineren Projekten ist die Sachlage eine völlig andere. Es gibt Millionen von GitHub-Projekten, bei denen sich die Zahl der Entwickler im einstelligen Bereich bewegt. Und GitHub ist nicht das einzige Repository für Open-Source-Aktivitäten. Wenn sich dann nur ein einziger Entwickler zurückzieht, ist das nicht selten jemand, der genau versteht, warum bestimmte Bereiche des Codes so geschrieben wurden, wie sie jetzt sind. Solche Projekte finden sich am häufigsten auf der Liste der Abhängigkeiten für eine Anwendung. Oft decken sie elementare Aktivitäten ab wie etwa das Schreiben von Logdaten – wie im Fall von log4j.

Da die Zahl der Entwickler bei Open-Source-Projekten so stark variiert, überrascht es auch nicht, dass sie sehr unterschiedlich auf einen Sicherheitsvorfall reagieren. Einige, wie Kubernetes oder das Xen-Projekt, haben entsprechend ihrem Standing sehr gut definierte Sicherheitsprozesse. Andere behandeln ein Sicherheitsproblem exakt wie jeden anderen Bug, der zwar behoben werden muss – aber eher zu einem unbestimmten Zeitpunkt in der Zukunft. Ein gut definierter Sicherheitsprozess verknüpft wahrscheinlich einen Patch mit einer Offenlegung im CVE-Format. Projekte, die Sicherheitsprobleme wie Bugs behandeln, beheben häufig einfach nur den Fehler, legen ihn aber nicht offen. Das macht es für ein Unternehmen nicht unbedingt leichter, das Risiko in der Supply Chain realistisch zu bewerten und angemessene Richtlinien zu entwickeln, die eben dieses Risiko senken sollen.

Ein Muss: Umfassende Inventarisierung

Wenn man das mit Open-Source-Software verbundene unternehmerische Risiko senken will, das in Wirklichkeit ein Softwarerisiko ist, sollte man eine Prämisse akzeptieren: Firmen profitieren von Open-Source-Software. Ein Großteil des geschäftlichen Risikos rührt daher, dass Open-Source-Software anders verwaltet wird als kommerzielle Software. Die Beschaffungs- und Patch-Prozesse bei beiden sind unterschiedlich. Realistisch betrachtet lassen sich OSS und kommerzielle Software nicht auf ein und dieselbe Art managen.

Der laxe Umgang mit der Security
Der Autor: Lucas v. Stockhausen ist Senior Director Solutions and Sales Engineering bei Synopsys SIG.
© Synopsys

Wer das Risiko senken will, sollte mit einer umfassenden Inventarisierung des Bestandes sämtlicher im Unternehmen verwendeten Software beginnen (Asset Management) und zwar unabhängig davon, woher die Software stammt und welcher Beschaffungsprozess zugrunde liegt. Anhand dieses Inventars kann man feststellen, welche Open-Source-Komponenten von den einzelnen Assets verwendet werden. Das passiert mithilfe der so genannten Software Composition Analysis (SCA). Eine Software kann sowohl in eine Binärdatei kompiliert oder quellbasiert sein. Das ausgewählte SCA-Tool sollte also sowohl binäre als auch quellbasierte Assets mit den gleichen Mitteln verarbeiten können. Ein Asset-Inventar umfasst vermutlich tausende von Einträgen. Es macht also Sinn, wenn ein SCA-Tool aktiv auf Änderungen des Sicherheitsrisikos innerhalb der Assets hinweist, und zwar, ohne dass ein erneuter Scan nötig ist.

An diesem Punkt lässt sich festlegen, wie mit einem veränderten Risiko aufgrund einer neu offengelegten Schwachstelle umgegangen werden soll. Schließlich ist es nicht ganz einfach, etwas zu patchen, von dem bislang niemand wusste, dass es überhaupt vorhanden ist. Genauso wie man nie gewiss sein kann, wann wieder eine neue Software mit einer anfälligen Komponente erstellt worden ist.


Das könnte Sie auch interessieren

Verwandte Artikel

Synopsys

Safety & Security