Bernhard Hecker, Sprecher der WG Public Affairs der OSB Alliance

In der aktuellen Berichterstattung und der Diskussion über die Log4J-Katastrophe wird gelegentlich der Eindruck erweckt, dass sich das Problem mit Hilfe von finanzieller Unterstützung für die Open-Source-Entwickler solcher kritischen Komponenten hätte verhindern lassen können.

Das ist nur teilweise korrekt.

Es entstehen im Moment sehr interessante und wichtige Initiativen, wie z.B. der SouvereignTechFund, mit dessen Hilfe Open-Source-Projekte finanziert werden sollen, die kritische Komponenten unseres digitalen Alltags entwickeln und pflegen – und das aus Idealismus heraus. Das bedeutet nicht, dass alle kritischen Komponenten aus Idealismus heraus entwickelt werden, aber es gibt einige, und diese sollten auch finanziell abgesichert werden, um eine Pflege zu gewährleisten.

Dieser Ansatz ist völlig richtig und sehr hilfreich. Nur löst er leider das Log4J Problem nicht.

Im Falle Log4J wurde von den Entwicklern unmittelbar nach Bekanntwerden des massiven Problems ein Update bereitgestellt, das die Sicherheits-Lücke schließt. Hier hat also der Community-Gedanke der Open-Source-Welt gegriffen, ohne dass finanzielle Mittel fließen müssen. Hier hat die Initiative der Entwickler und die Möglichkeit für Jedermann, sich an der Pflege des Codes zu beteiligen, das bewirkt, was wir als Open-Source-Vertreter immer sagen: Die Möglichkeit für alle, sich an der Verbesserung zu beteiligen, führt dazu, dass das ganz automatisch und auch schnell passiert (wenn es jemanden gibt, für die oder den es wichtig ist).

Das eigentliche Problem mit Log4J liegt an einer anderen Stelle: Jetzt, da das Sicherheitsupdate verfügbar ist, ist noch lange nicht alles sicher. Alle die damit Dienste im Internet bereit stellen oder Log4j in eigene Produkte integriert haben, müssen jetzt das Update auch einspielen, und vor allem auch einspielen können. In vielen alltäglichen Bereichen werden Systeme aus unterschiedlichen Gründen nicht aktualisiert. Sei es, weil den Anwendern keine Möglichkeit gegeben wird, oder ihnen schlicht unbekannt ist, wie Updates eingespielt werden müssen. Es ist in einigen Unternehmen allerdings auch immer ein langwieriger und komplizierter Prozess.

Aber jetzt, nachdem Log4J in einer sichereren Version verfügbar ist, müssen alle Softwarehersteller, die die Komponente in ihren Systemen einsetzen, die Komponente austauschen und ihren Kunden neue Versionen ihrer Produkte bereitstellen.

Im Internet werden bereits Listen zusammengestellt, die die Sicherheitshinweise vieler Hersteller sammeln: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Hier können Kunden sich im Einzelnen informieren, wobei die Liste nur einen Bruchteil der Anwendungen beinhaltet und die meisten Anwender nach wie vor ahnungslos sind. Viele Anwender können auch nicht genau sagen, was sie alles laufen haben, u.a. deswegen testen sie grundsätzlich auf Schwachstellen, denn dann fällt auch jeder „vergessene“ Service auf.

Ein gangbarer Weg, der die Update- und Patchsituation erheblich verbessert, ist die Implementierung sicherer Software Supply Chains. Wenn sichergestellt ist, dass Software durchgängig und auch in kleinen Komponenten schnell und einfach aktualisiert werden kann und wenn dabei auch sichergestellt ist, dass die Lieferkette abgesichert und nachvollziehbar ist, können Patches vertrauenswürdig und schnell auf vielen Geräten bereitgestellt werden. Wenn das Vertrauen in Patches automatisierbar ist, können Wege verkürzt und die Verbreitung von Patches beschleunigt werden.

Die Open Source Communities weltweit haben seit Jahren solche Update- und Patch-Mechanismen aufgesetzt und bereitgestellt. Nicht umsonst sind heute für sehr viele Betriebssysteme und große Open-Source-Projekte Sicherheitsupdates für Log4J verfügbar. Diese werden auch ausgerollt. Allerdings betrifft das in den meisten Fällen große Systeme industrieller Anwender und nicht die Sicherheitskameras in privaten Gärten, die zum Teil noch angreifbar sind.

Bei der Entwicklung von Software werden immer wieder Fehler gemacht, die zu Sicherheitslücken führen. Es gab in der Vergangenheit bei Solarwinds und mit Heartbleed weitere prominente Beispiele. Diese Beispiele und auch die aktuelle Log4J Situation zeigt, dass Softwareentwickler meist sehr gut darin sind, solche Fehler, sobald erkannt, schnell zu beheben.

Das alles sollte uns nicht in trügerischer Sicherheit wiegen. Das Internet ist kein per se sicherer Ort, aber wer sich grundsätzlich gut um Sicherheit kümmert, etwa durch den Einsatz funktionierender Firewalls, muss sich deutlich weniger Sorgen machen.

Als Open-Source-Softwareindustrie fordern wir Hersteller von IT-Produkten und Anbieter von IT-Diensten dazu auf, Verantwortung für ihre Produkte zu übernehmen und Vorkehrungen zu treffen, damit kritische Fehlerkorrekturen schnell und unkompliziert auf alle Geräte und Dienste verteilt werden können.

Wir unterstützen dabei gerne mit unserem Wissen, mit unserer Erfahrung beim Aufbau solcher Prozesse sowie mit fertigen Produkten und Lösungen für die damit verbundenen Probleme.