Tenable-CEO Amit Yoran zur Apache-Log4j-Schwachstelle
Fukushima-Moment der Cybersicherheit
Am Freitag, den 10.12.21, kam eine kritische Sicherheitslücke namens Log4Shell in der verbreiteten Open-Source-Protokollierungsbibliothek Apache Log4j ans Licht. Durch diese Schwachstelle, vom BSI als eine höchster Kritikalität eingestuft, kann ein nicht authentifizierter, entfernter Angreifer eine manipulierte Anfrage an einen Server senden und Schadcode ausführen (Remote Code Execution, RCE). Angreifer nutzen die Schwachstelle bereits aus. Sie betrifft eine Fülle von Diensten und Anwendungen, darunter Minecraft, Steam und Apples iCloud. Im nachfolgenden Gastkommentar erläutert Amit Yoran, CEO des Security-Anbieters Tenable, warum er dies als „Fukushima-Moment“ der Cybersicherheit einstuft.
Unternehmen auf der ganzen Welt werden noch jahrelang mit den Folgen dieser als Log4Shell bekannten Sicherheitslücke zu kämpfen haben. Die Entdeckung einer kritischen Schwachstelle in der Apache Log4j-Software ist nichts weniger als ein Fukushima-Moment für die Cybersicherheitsbranche.
Und so wie Fukushima erhebliche Probleme mit langjährigen Prozessen im Kraftwerk ans Licht gebracht hat, so wirft auch die Log4j-Schwachstelle, bekannt als Log4Shell, ein Schlaglicht auf zwei wichtige Praktiken: die Art und Weise, wie Unternehmen ihre riesigen Mengen an Protokolldaten erfassen und schützen, und die Verwendung von Open-Source-Codebibliotheken als Bausteine für wichtige Unternehmensanwendungen.
Das Paradoxon von Log4j
Tenable entdeckt jede Minute neue Anwendungen, die Log4j auf die eine oder andere Weise nutzen. Das betrifft nicht nur den Code, den Unternehmen erstellen, sondern auch die Systeme von Drittanbietern, die sie im Einsatz haben. Alles, vom neuen Drucker, den sie für ihr Büro gekauft haben, bis hin zum Ticketing-System, das sie gerade eingerichtet haben, ist potenziell von dieser Schwachstelle betroffen. Einige der betroffenen Systeme befinden sich vielleicht vor Ort, andere werden in der Cloud gehostet, aber egal, wo sie sich befinden, die Schwachstelle wird wahrscheinlich Auswirkungen haben.
Um ein Gefühl für das Ausmaß der Schwachstelle zu geben: Tenable beobachtet bereits, dass Kunden 1.000 Systeme pro Sekunde überprüfen und ein betroffenes System pro Sekunde identifizieren.
Die Ironie dieser Schwachstelle besteht darin, dass sie es Angreifern ermöglichen könnte, genau die Logging-Praktiken auszunutzen, die das Aushängeschild für solide Sicherheitspraktiken sind: Je sicherer ein Unternehmen ist, desto mehr protokolliert es jede Aktion – was bedeutet, dass es auf einem größeren Pool von Logging-Daten sitzt, die sich potenziell ausnutzen lassen.
Die ausgereiftesten Sicherheitsorganisationen erfassen in der Regel die größte Menge an Protokolldaten, um effektiv auf Vorfälle reagieren und Sicherheitsmaßnahmen ergreifen zu können. Das Kernproblem von Log4j ist, dass man es ausnutzen kann, wenn man es dazu bringt, beliebige Spuren zu protokollieren. Tenable hat es mit sehr unsicheren Daten zu tun, und die Bibliothek behandelt sie aus irgendeinem Grund so, als wären sie bereinigt worden.
Anwendungen auf wackligem Fundament
Die Apache Log4j-Lücke wirft ein grelles Licht auf die riskante Praxis, sich bei der Entwicklung von Unternehmensanwendungen auf Open-Source-Codebibliotheken zu verlassen. Die Apache Foundation, von der auch die Struts-Schwachstelle im Jahr 2017 stammt, ist eine von der Community geführte Organisation, die angibt, Softwareprodukte im Wert von 22 Milliarden Dollar kostenlos für die Allgemeinheit zur Verfügung zu stellen. Unternehmen auf der ganzen Welt profitieren jeden Tag von der Arbeit der Stiftung. Dennoch haben wir es als Branche nicht zu unserer Priorität gemacht, die Organisation mit Mitteln zu unterstützen, die einen sicherheitsorientierten Ansatz fördern können.
Da die Anforderungen an die digitale Transformation und die Agilität der Softwareentwicklung jedes Jahr exponentiell steigen, verlassen sich Unternehmen auf der ganzen Welt auf Open-Source-Bibliotheken als Kernbaustein ihrer Fähigkeit, Anwendungen schnell auf den Markt zu bringen. Die Folge ist eine Abhängigkeit von einem „Wilden Westen“ von Code-Bibliotheken.
Dies wird Unternehmen weiterhin verwundbar machen, solange sie nicht die nötige Zeit und die Ressourcen investieren, um für mehr Sicherheit zu sorgen. Es ist längst an der Zeit, ein Sicherheitsklassifizierungssystem für Open-Source-Codebibliotheken zu schaffen. Ein solches System würde jedem Code eine Sicherheitseinstufung zuweisen und den Benutzern einen Überblick darüber verschaffen, wie gut die Bibliotheken unter Sicherheitsaspekten gepflegt werden.
Wenn Unternehmen Open-Source-Software weiterhin zu einer kritischen Komponente ihrer benutzerdefinierten Entwicklungsmodelle machen wollen, ist es an der Zeit, eine Reihe von Standards und Praktiken einzuführen, die eine saubere Bewertung der Kritikalität jeder Open-Source-Komponente in ihrer Infrastruktur ermöglichen. Ebenso gilt es sicherzustellen, dass bei jedem Schritt im Entwicklungslebenszyklus ein Sicherheitsdesign vorhanden ist.
Lesen Sie mehr zum Thema
