Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Erinnern Sie sich noch an den Dezember 2021? An die allgemeine Panik, als Log4Shell bekannt wurde und plötzlich jedes Entwicklerteam auf der Welt verzweifelt versuchte herauszufinden, ob es Log4j einsetzte, wo es sich in seiner Infrastruktur versteckte und wie schnell es das Problem beheben konnte?
Die meisten Teams glauben, dass diese Geschichte Anfang 2022 zu Ende ging. Sie haben ihre Anwendungen gepatcht, ihre Abhängigkeiten überprüft, vielleicht ein paar Bibliotheken aktualisiert und sind dann zur Tagesordnung übergegangen. Log4j wurde zu einem dieser Vorfälle, von denen man sagt: „Weißt du noch, damals?“ – damals zwar stressig, aber inzwischen gelöst.
Nur dass das Problem noch nicht gelöst ist. Nicht einmal annähernd.
Die Wahrheit ist, dass das Risiko durch die Log4j-Sicherheitslücke nach der ersten Welle von Log4Shell-Korrekturmaßnahmen nicht verschwunden ist. Es ist lediglich weniger auffällig und schwerer zu erkennen geworden. Heute, im Jahr 2026, verstecken sich immer noch anfällige Log4j-Instanzen in Produktionsumgebungen, eingebettet an Stellen, an denen Teams schon vor Jahren aufgehört haben zu suchen. Und das liegt nicht daran, dass die Entwicklerteams nachlässig sind – es liegt daran, dass die Art und Weise, wie Software-Abhängigkeiten funktionieren, dazu führt, dass „wir haben es einmal gepatcht“ oft ein trügerisches Gefühl der Erledigung vermittelt.
Lassen Sie uns darüber sprechen, wo das eigentliche Log4j-Risiko derzeit liegt, warum es immer wieder auftaucht und wie wirksame Gegenmaßnahmen konkret aussehen, wenn man es mit modernen Software-Stacks zu tun hat, die aus unzähligen Schichten verborgener Abhängigkeiten bestehen.
Die Log4j-Sicherheitslücke über Log4Shell hinaus
Log4Shell (CVE-2021-44228) sorgte für Schlagzeilen, und das zu Recht. Eine Sicherheitslücke, die die Ausführung von Remote-Code ermöglicht, in einer Logging-Bibliothek, die von der Hälfte des Java-Ökosystems genutzt wird, ist so schlimm, wie es nur sein kann. Sich jedoch nur auf Log4Shell zu konzentrieren, ist so, als würde man sich um den Hai sorgen, den man sehen kann, während man diejenigen ignoriert, die unter der Oberfläche kreisen.
Seit Log4Shell wurden mehrere weitere Log4j-Sicherheitslücken entdeckt. CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 und weitere folgten in relativ schneller Folge. Jede einzelne erforderte Aufmerksamkeit, jede einzelne erforderte Patches, und jede einzelne bewies, dass Log4j als Komponente tiefgreifendere Sicherheitsprobleme aufwies als nur diese eine spektakuläre RCE-Sicherheitslücke.
Besonders heimtückisch ist, dass diese nachfolgenden Sicherheitslücken oft andere Versionsbereiche betreffen als Log4Shell. Ein Team, das von Log4j 2.14.1 auf 2.15.0 aktualisiert hat, um Log4Shell zu beheben, war möglicherweise anfällig für CVE-2021-45046. Ein Upgrade auf 2.16.0 behob dieses Problem, doch bei älteren Versionen bestand weiterhin die Gefahr durch CVE-2021-44832. Dieses „Whack-a-Mole“-Spiel mit den Sicherheitslücken führte dazu, dass die Nachverfolgung „sicherer“ Versionen kompliziert wurde, und viele Unternehmen verloren den Überblick darüber, welche Systeme vollständig behoben und welche nur teilweise gepatcht worden waren.
Dann ist da noch das offensichtliche Problem: Log4j 1.x. Während sich die öffentliche Panik größtenteils auf die Schwachstellen von Log4j 2.x konzentrierte, weist Log4j 1.x eigene Sicherheitsprobleme auf und hat bereits 2015 das Ende seines Lebenszyklus erreicht. Dennoch ist es immer noch im Umlauf und läuft in Produktionssystemen, die nie auf Log4j 2.x migriert wurden. Diese Systeme sind mit Schwachstellen konfrontiert, für die es niemals offizielle Patches geben wird, da die Codebasis aufgegeben wurde.
Auch die Schwachstellenlandschaft ist nicht statisch. Sicherheitsforscher entdecken weiterhin Probleme in Logging-Bibliotheken. Die Aufmerksamkeit, die Log4Shell auf Log4j und ähnliche Komponenten gelenkt hat, bedeutet, dass nun mehr Augen nach Problemen Ausschau halten. Es wäre naiv anzunehmen, dass wir die letzte Log4j-Schwachstelle gefunden haben.
Wo sich Log4j in modernen Stacks versteckt
Der Grund dafür, dass das Log4j-Risiko weiterhin besteht, liegt nicht darin, dass Teams es absichtlich ignorieren. Vielmehr ist es tatsächlich schwierig, jede einzelne Log4j-Instanz in einem modernen Anwendungsstack aufzuspüren.
Transitive Abhängigkeiten sind die häufigste Versteckstelle. Ihre Anwendung hängt vielleicht nicht direkt von Log4j ab, aber eine Ihrer Abhängigkeiten tut dies. Oder eine der Abhängigkeiten Ihrer Abhängigkeiten tut dies. Oder Sie befinden sich mehrere Ebenen tief in einem Abhängigkeitsbaum und irgendwo dort, drei Ebenen tiefer verborgen, befindet sich Log4j 2.14.0.
Tools zur Abhängigkeitsanalyse sind zwar hilfreich, aber nicht perfekt. Sie können Ihnen zwar bekannte Abhängigkeiten in den deklarierten Abhängigkeitsdateien Ihres Projekts aufzeigen, erfassen jedoch nicht immer alles. Manchmal verbergen Bibliotheken Abhängigkeiten – sie bündeln diese intern auf eine Weise, die bei einer standardmäßigen Abhängigkeitsanalyse nicht sichtbar wird. Manchmal befindet sich die Abhängigkeit in einem Binärartefakt, das Ihr Scanner nicht gründlich genug überprüft.
Containerisierte Anwendungen bringen ihre eigenen Herausforderungen mit sich. Möglicherweise verwenden Sie Container-Images, die vor Monaten oder Jahren erstellt wurden, also bevor Log4Shell bekannt war. Das Basis-Image könnte anfällige Log4j-Versionen enthalten. Die Anwendungsschichten könnten weitere hinzufügen. Sofern Sie die Images nicht regelmäßig neu erstellen und scannen, bleiben diese Schwachstellen bestehen, selbst wenn Ihr aktueller Quellcode sauber ist.
Anwendungen von Drittanbietern und kommerzielle Software enthalten oft ihre eigenen Abhängigkeiten, darunter auch Log4j. Das Unternehmensüberwachungstool, das Sie 2020 bereitgestellt haben? Möglicherweise läuft dort intern Log4j 2.12.1, und Sie haben keinen Einblick darin, da es sich um eine Blackbox des Anbieters handelt. Der Anbieter hat vielleicht eine gepatchte Version veröffentlicht, aber wenn Sie die Sicherheitshinweise des Anbieters nicht genau verfolgen oder wenn Upgrades umfangreiche Tests und Ausfallzeiten erfordern, bleibt diese anfällige Instanz bestehen.
Lesen Sie auch unseren technischen Leitfaden zur Implementierung einer Korrektur für die Log4j-Sicherheitslücke, um versteckte Abhängigkeiten in komplexen Systemstacks aufzudecken.
Build-Tools und Entwicklungsumgebungen enthalten manchmal anfällige Log4j-Versionen, die zwar nicht direkt Teil Ihrer Produktionsanwendung sind, aber dennoch ein Risiko darstellen. Jenkins-Plugins, Maven-Repositorys, IDE-Erweiterungen – all diese können Log4j enthalten, und sie werden nicht immer in produktionsorientierten Schwachstellenscans berücksichtigt.
Altsysteme und unveränderte Codebasen stellen vielleicht die größte Herausforderung dar. Diese kritische Java-Anwendung, die seit fünf Jahren unverändert läuft, weil sie stabil ist und „niemand sie anfassen will“? Sie enthält wahrscheinlich das anfällige Log4j. Ein Upgrade bedeutet jedoch, dass Tests mit aktuellen JDK-Versionen durchgeführt, seit Jahren unveränderte Integrationen validiert und möglicherweise festgestellt werden muss, dass kritische Abhängigkeiten nicht mehr gepflegt werden.
Eingebettete Komponenten und Geräte runden die Liste ab. Netzwerkgeräte, Sicherheitsanwendungen, IoT-Systeme und andere eingebettete Java-Anwendungen nutzen Log4j häufig intern. Diese sind in der Regel am schwierigsten zu patchen, da Updates vom Hersteller kommen müssen, Upgrade-Zyklen langsam sind und manchmal der Hersteller selbst nicht mehr existiert oder den Support für das Produkt eingestellt hat.
All diesen Szenarien ist eines gemeinsam: Sie bleiben unsichtbar. Diese Log4j-Instanzen tauchen nicht im Abhängigkeitsbaum Ihrer Hauptanwendung auf. Sie werden von Ihren üblichen Patch-Prozessen nicht erfasst. Sie existieren in den Lücken zwischen dem, was Sie zu betreiben glauben, und dem, was tatsächlich bereitgestellt ist.
Warum „Wir haben das schon einmal behoben“ nicht ausreicht
Selbst Teams, die Ende 2021 und Anfang 2022 gründliche Abhilfemaßnahmen durchgeführt haben, stellen oft fest, dass sich anfällige Log4j-Instanzen wieder in ihre Umgebungen einschleichen. Das liegt nicht daran, dass die Patches rückgängig gemacht wurden – sondern daran, dass Software-Ökosysteme dynamisch sind.
- Neue Bereitstellungen bringen alte Sicherheitslücken mit sich. Ein Entwickler richtet einen neuen Microservice auf Basis einer Projektvorlage aus dem Jahr 2020 ein. Die Vorlage enthält ältere Abhängigkeiten. Sofern Ihr Abhängigkeitsmanagement nicht außerordentlich diszipliniert ist, könnte dieser neue Dienst mit dem anfälligen Log4j ausgeliefert werden, obwohl Ihr Unternehmen Log4j bereits vor zwei Jahren „behoben“ hat.
- Aktualisierungen von Abhängigkeiten können Korrekturen rückgängig machen. Sie aktualisieren eine nicht betroffene Bibliothek, und diese zieht eine ältere Version einer ihrer Abhängigkeiten mit sich, was transitiv eine anfällige Log4j-Version wieder einführt. Ihre Regeln zur Abhängigkeitsauflösung sind möglicherweise nicht streng genug, um dies zu verhindern, oder der Algorithmus zur Lösung von Versionskonflikten wählt aus Kompatibilitätsgründen die anfällige Version aus.
- Übernahmen und Integrationen bringen externen Code mit sich. Ihr Unternehmen übernimmt ein anderes Unternehmen oder integriert das System eines Partners. Plötzlich sind Sie für dessen Codebasis verantwortlich, die möglicherweise nicht dieselbe Aufmerksamkeit bei der Log4j-Behebung erhalten hat wie Ihre eigene.
- Schatten-IT und inoffizielle Bereitstellungen umgehen Ihre Standardprozesse. Ein Team stellt in Eile etwas bereit und überspringt dabei die üblichen Sicherheitsscans und Genehmigungsverfahren. Oder jemand betreibt einen „vorübergehenden“ Dienst, der dauerhaft wird. Diese nicht genehmigten Bereitstellungen enthalten oft Schwachstellen, von denen Sie dachten, sie seien beseitigt worden.
- Wiederherstellung von Backups und Notfallwiederherstellung können anfällige Versionen wiederherstellen. Sie stellen ein System aus einem Backup wieder her, das vor Bekanntwerden von Log4Shell erstellt wurde. Oder Sie bauen einen Dienst aus archivierten Bereitstellungsartefakten neu auf. Sofern Sie in diesen Wiederherstellungsszenarien nicht gezielt nach Log4j suchen, bringen Sie möglicherweise anfälligen Code wieder in die Produktion.
Das grundlegende Problem ist, dass Softwaresicherheit kein Zustand ist, den man einmal erreicht, sondern ein Prozess, den man aufrechterhalten muss. „Gepatcht“ ist kein dauerhafter Zustand. Es erfordert ständige Wachsamkeit, regelmäßige erneute Überprüfungen und ein ständiges Bewusstsein dafür, was tatsächlich läuft und was Ihrer Meinung nach laufen sollte.
Risikobewertung in der Praxis
Nicht jede Log4j-Instanz birgt das gleiche Risiko. Wenn Sie Ihr tatsächliches Risiko kennen, können Sie Abhilfemaßnahmen sinnvoll priorisieren, anstatt alles als gleich dringliche Krise zu behandeln.
- Die Gefährdung ist entscheidend. Eine anfällige Log4j-Instanz in einer internetbasierten Webanwendung, die nicht vertrauenswürdige Benutzereingaben verarbeitet, stellt ein hohes Risiko dar. Eine anfällige Log4j-Instanz in einem internen Batch-Verarbeitungsjob, der ausschließlich strukturierte Daten aus vertrauenswürdigen Quellen verarbeitet, birgt ein geringeres Risiko. Die Schwachstelle ist dieselbe, doch die praktische Ausnutzbarkeit ist unterschiedlich.
- Die Sensibilität der Daten erhöht das Risiko. Systeme, die Zahlungsinformationen, persönliche Gesundheitsdaten oder andere regulierte Daten verarbeiten, sind durch Log4j-Sicherheitslücken einem höheren Risiko ausgesetzt. Eine Sicherheitsverletzung bedeutet nicht nur eine technische Kompromittierung – sie bedeutet auch Verstöße gegen Compliance-Vorschriften, rechtliche Haftung und behördliche Sanktionen.
- Die Netzwerkpositionierung beeinflusst die Ausnutzbarkeit. Log4j-Schwachstellen in Systemen, die nur über interne Netzwerke erreichbar sind, lassen sich weniger unmittelbar ausnutzen als solche, die dem öffentlichen Internet ausgesetzt sind. Das macht sie zwar nicht sicher, verändert aber das Bedrohungsmodell und die Dringlichkeit der Behebung.
- Die Verfügbarkeit von Exploits beeinflusst den Zeitplan. Sobald funktionierende Exploits für eine bestimmte Log4j-Sicherheitslücke öffentlich verfügbar sind und von Angreifern aktiv genutzt werden, schrumpft das Zeitfenster für eine sichere Behebung drastisch. Ältere Sicherheitslücken mit ausgereiften Exploit-Ökosystemen sind gefährlicher als neu entdeckte Probleme, die sich noch in der Forschungsphase befinden.
- Ausgleichsmaßnahmen verringern das praktische Risiko. Wenn anfällige Log4j-Instanzen hinter Webanwendungs-Firewalls sitzen, die so konfiguriert sind, dass sie JNDI-Lookup-Muster blockieren, oder wenn Tools zum Schutz von Anwendungen zur Laufzeit auf Exploit-Versuche überwachen, ist das praktische Risiko geringer als bei vollständig ungeschützten Bereitstellungen. Diese Maßnahmen sind kein Ersatz für Patches, beeinflussen jedoch die Risikobewertung.
Das Ziel der Risikobewertung besteht nicht darin, Untätigkeit zu rechtfertigen. Vielmehr soll sie Ihnen dabei helfen, begrenzte Ressourcen für Abhilfemaßnahmen dort einzusetzen, wo sie den größten Einfluss auf Ihre tatsächliche Sicherheitslage haben.
Praktische Strategien zur Risikominderung
Sie haben also Log4j-Sicherheitslücken in Ihrer Umgebung entdeckt. Einige lassen sich leicht beheben, andere sind komplizierter. Hier erfahren Sie, wie eine wirklich wirksame Abhilfe aussieht.
Zunächst eine umfassende Bestandsaufnahme
Was man nicht findet, kann man auch nicht beheben. Investieren Sie in eine gründliche Analyse, bevor Sie mit der Fehlerbehebung beginnen.
Nutzen Sie verschiedene Scan-Ansätze: Analyse der Abhängigkeiten im Quellcode, Container-Image-Scan, Binäranalyse der bereitgestellten Artefakte und Erkennung zur Laufzeit. Jeder Ansatz deckt unterschiedliche Aspekte auf. Der Quellcode-Scan ermittelt deklarierte Abhängigkeiten. Der Container-Scan deckt Schwachstellen im Basis-Image auf. Die Binäranalyse ermittelt verdeckte Abhängigkeiten. Die Erkennung zur Laufzeit ermittelt, was tatsächlich in der Produktion geladen ist.
Beschränken Sie die Überprüfung nicht auf die Produktionsumgebung. Überprüfen Sie auch Entwicklungsumgebungen, Build-Systeme, Staging-Umgebungen und alle anderen Orte, an denen Code ausgeführt wird. Ein anfälliges Log4j auf dem Laptop eines Entwicklers stellt zwar möglicherweise kein unmittelbares Risiko für die Produktion dar, bedeutet jedoch technische Schulden und ein potenzielles zukünftiges Sicherheitsrisiko.
Dokumentieren Sie Ihre Ergebnisse detailliert: welche Systeme, welche Log4j-Versionen, welche Codepfade die Protokollierungsfunktion tatsächlich nutzen und wie das Sicherheitsrisiko aussieht. Diese Bestandsaufnahme dient Ihnen als Fahrplan für die Behebung der Schwachstellen.
Priorisierung auf der Grundlage des tatsächlichen Risikos
Beheben Sie zuerst die Fälle mit dem höchsten Risiko. Dazu gehören Systeme mit Internetanbindung, Systeme, die sensible Daten verarbeiten, sowie alle Systeme, bei denen aktive Angriffsmuster bekannt sind.
Bei Systemen mit mittlerem Risiko sollten Sie Ausgleichsmaßnahmen ergreifen, während Sie geeignete Abhilfemaßnahmen planen. Richten Sie WAF-Regeln ein, aktivieren Sie die Laufzeitüberwachung, beschränken Sie den Netzwerkzugriff und implementieren Sie zusätzliche Authentifizierungsebenen. Diese Maßnahmen verschaffen Ihnen Zeit, um Upgrades ordnungsgemäß durchzuführen, anstatt sie überstürzt durchzuführen.
Bei Systemen mit geringerem Risiko können Sie sich einen etwas großzügigeren Zeitplan leisten, aber lassen Sie „geringeres Risiko“ nicht zu „wird nie behoben“ werden. Legen Sie konkrete Fristen fest und halten Sie sich daran.
Wo möglich, aktualisieren
Die richtige Lösung für die Log4j-Sicherheitslücken ist ein Upgrade auf gepatchte Versionen. Für Log4j 2.x bedeutet dies, auf mindestens Version 2.17.1 umzusteigen, die alle wesentlichen Sicherheitslücken behebt, die bis Anfang 2022 entdeckt wurden.
Testen Sie Upgrades gründlich. Änderungen an der Log4j-Version können zu Abweichungen im Verhalten führen, insbesondere in Bezug auf Konfiguration und Leistung. Führen Sie vor der Bereitstellung Tests in Staging-Umgebungen durch, die die Produktionsumgebung widerspiegeln.
Falls direkte Log4j-Upgrades aufgrund von Einschränkungen bei übergeordneten Abhängigkeiten nicht möglich sind, versuchen Sie, die Abhängigkeiten zu aktualisieren, die Log4j einbinden. Manchmal müssen Sie mehrere Ebenen Ihres Abhängigkeitsbaums aktualisieren, um das Problem zu beheben.
Migration weg von Log4j 1.x
Wenn Sie noch Log4j 1.x verwenden, nutzen Sie eine nicht mehr unterstützte und nicht mehr gepflegte Codebasis. Der richtige Schritt ist die Umstellung auf ein modernes Logging-Framework – Log4j 2.x, Logback oder eine andere gepflegte Alternative.
Das ist oft ein umfangreiches Unterfangen. Die Konfigurationsformate unterscheiden sich. Die APIs haben sich geändert. Abhängigkeiten müssen möglicherweise aktualisiert werden. Aber es handelt sich um eine notwendige Arbeit, die schon vor Jahren hätte erledigt werden sollen und nicht auf unbestimmte Zeit aufgeschoben werden kann.
Planen Sie die Migration in mehreren Phasen. Beginnen Sie mit weniger kritischen Systemen, um die Abläufe kennenzulernen und Probleme zu erkennen. Erstellen Sie interne Dokumentationen und Migrationsleitfäden. Arbeiten Sie sich dann systematisch durch Ihre Produktionssysteme.
Behandlung von Komponenten von Anbietern und Drittanbietern
Überprüfen Sie bei kommerzieller Software und von Anbietern bereitgestellten Komponenten die Sicherheitshinweise und Aktualisierungspläne. Viele Anbieter haben Log4j-Patches veröffentlicht, übertragen diese jedoch nicht automatisch auf die Installationen ihrer Kunden.
Falls Anbieter ihre Software noch nicht gepatcht haben, eskalieren Sie das Problem. Erstellen Sie Support-Tickets, beziehen Sie Ihre Kundenbetreuer mit ein und machen Sie deutlich, dass dies ein Hindernis für die weitere Nutzung darstellt. Anbieter reagieren auf Druck von Kunden, insbesondere wenn dieser von mehreren Kunden gleichzeitig ausgeht.
Bei kritischer Anbietersoftware, die nicht aktualisiert werden kann, sollten Sie eine Netzwerkisolierung und zusätzliche Sicherheitsmaßnahmen implementieren. Nur weil Sie die Software nicht patchen können, heißt das nicht, dass Sie ihr Risiko nicht begrenzen können.
Wenn die Sanierung an ihre Grenzen stößt
Trotz aller Bemühungen lassen sich manche Log4j-Instanzen nicht beheben. Sie haben es mit nicht mehr unterstützten Altsystemen zu tun, die sich nicht ohne Weiteres aktualisieren lassen, mit Anbietersoftware, für die keine Patches mehr bereitgestellt werden, oder mit maßgeschneiderten Anwendungen, deren Umstellung auf neuere Log4j-Versionen einen erheblichen Aufwand erfordern würde.
Für diese Szenarien bieten Optionen für erweiterten Sicherheits-Support eine Alternative. Dienste wie der von TuxCare „Endless Lifecycle Support for Log4j“ können Sicherheitspatches für ältere, nicht mehr unterstützte Softwareversionen bereitstellen – einschließlich älterer Log4j-Instanzen, für die keine offiziellen Updates mehr angeboten werden.
Dies ist weder eine langfristige Lösung noch eine Ausrede, um notwendige Upgrades zu vermeiden. Es handelt sich jedoch um einen pragmatischen Ausweg für Situationen, in denen eine sofortige Behebung technisch nicht machbar ist. Wenn Sie in einer festgefahrenen Legacy-Anwendung, deren Migration achtzehn Monate dauern würde, weiterhin Log4j 1.x einsetzen müssen, kann der erweiterte Support dafür sorgen, dass diese Instanz gegen bekannte Sicherheitslücken gepatcht bleibt, während Sie den Migrationsplan umsetzen.
Betrachten Sie es als eine Möglichkeit, sich Zeit zu verschaffen, ohne das volle Risiko einzugehen, Software zu betreiben, für die es keinerlei Patches gibt. Sie müssen diese Systeme zwar irgendwann modernisieren, sind aber nicht zu überstürzten Migrationen gezwungen, die neue Probleme oder Betriebsstörungen verursachen könnten.
Entscheidend ist, die Strategie klar zu formulieren. Eine verlängerte Unterstützung ist kein Ersatz für eine ordnungsgemäße Behebung – sie ist vielmehr eine Überbrückung, die es Ihnen ermöglicht, das Problem innerhalb eines vernünftigen Zeitrahmens zu beheben, anstatt unter dem Druck einer Krisensituation handeln zu müssen.
Aufbau nachhaltiger Sicherheitspraktiken
Die eigentliche Lehre aus Log4j betrifft nicht diese spezielle Bibliothek. Es geht vielmehr um die Natur von Software-Abhängigkeiten und die ständige Wachsamkeit, die für das Sicherheitsmanagement in modernen Anwendungen erforderlich ist.
- Disziplin beim Abhängigkeitsmanagement muss eine zentrale Praxis in der Entwicklung sein, nicht etwas, worüber man erst nachdenkt, wenn eine Krise eintritt. Das bedeutet regelmäßige Abhängigkeitsprüfungen, automatisiertes Scannen in CI/CD-Pipelines, Richtlinien zu akzeptablen Abhängigkeitsversionen sowie Prozesse zur kontinuierlichen Bewertung und Aktualisierung von Abhängigkeiten.
- Sicherheitsscans dürfen keine einmalige Angelegenheit sein. Sicherheitslücken werden ständig entdeckt. Ihre Scans müssen kontinuierlich laufen – in der Entwicklung, in CI/CD, in der Produktion und in allen dazwischenliegenden Umgebungen. Was gestern noch sicher war, kann heute schon eine Schwachstelle sein.
- Risikomanagement bei Lieferanten erfordert eine aktive Überwachung. Verfolgen Sie die von Ihnen eingesetzte Software von Drittanbietern, beobachten Sie Sicherheitshinweise der Anbieter, bewerten Sie die Sicherheitspraktiken der Anbieter vor der Beschaffung und legen Sie in den Lieferantenverträgen klare SLAs für Sicherheitsupdates fest.
- Prozesse zur Reaktion auf Vorfälle sollten Schwachstellen in Abhängigkeiten als Szenario berücksichtigen. Wenn die nächste Schwachstelle vom Typ Log4Shell auftritt – und es wird eine geben –, wie schnell können Sie betroffene Systeme identifizieren? Wie priorisieren Sie die Behebung? Wer trifft Entscheidungen über akzeptable Risiken und Zeitpläne?
- Architekturentscheidungen können die Auswirkungen von Sicherheitslücken begrenzen. Microservices mit isolierten Abhängigkeiten lassen sich leichter aktualisieren als monolithische Anwendungen mit umfangreichen Abhängigkeitsbäumen. Containerisierte Anwendungen mit regelmäßig neu erstellten Images übernehmen Sicherheitsupdates nahtloser als lang laufende VMs. Eine unveränderliche Infrastruktur verkürzt die Zeitfenster für Sicherheitslücken.
Ihr Aktionsplan
Wenn Sie dies lesen und sich fragen, ob in Ihrer Umgebung noch versteckte Log4j-Sicherheitslücken lauern, sollten Sie Folgendes tun:
Führen Sie umfassende Scans in allen Umgebungen durch, wobei Sie verschiedene Scan-Ansätze nutzen. Überprüfen Sie nicht nur Ihre Hauptanwendungen, sondern auch Build-Systeme, Anbietersoftware, containerisierte Workloads und Altsysteme.
Erfassen Sie Ihre Funde so detailliert, dass Sie Risiken einschätzen und Abhilfemaßnahmen planen können. Nicht nur „Log4j 2.14.1 gefunden“, sondern „gefunden in einem kundenorientierten API-Dienst, der die Zahlungsabwicklung übernimmt und mit dem Internet verbunden ist“.
Setzen Sie Prioritäten konsequent auf der Grundlage des tatsächlichen Risikos. Beheben Sie gefährliche Probleme sofort. Planen Sie gezielte Abhilfemaßnahmen für Fälle mit mittlerem Risiko. Ignorieren Sie Fälle mit geringem Risiko nicht, aber lassen Sie nicht zu, dass sie Arbeiten mit hoher Priorität behindern.
Führen Sie Ausgleichsmaßnahmen für alles ein, was Sie nicht sofort beheben können. WAF-Regeln, Netzwerksegmentierung, Laufzeitüberwachung – nutzen Sie jedes verfügbare Werkzeug, um die praktische Ausnutzbarkeit zu verringern.
In Fällen, in denen man wirklich nicht weiterkommt, sollte man eine verlängerte Unterstützung als Übergangslösung in Betracht ziehen. Man sollte jedoch ehrlich darlegen, was diese Lösung beinhaltet und was nicht, und klare Zeitpläne für die spätere endgültige Behebung des Problems festlegen.
Die unbequeme Wahrheit
Das Risiko durch die Log4j-Sicherheitslücke ist kein Problem, das man einmal löst und dann vergisst. Es handelt sich um ein fortwährendes Sicherheitsrisiko, das ständige Aufmerksamkeit, regelmäßige Überprüfungen und kontinuierliche Maßnahmen zur Behebung erfordert.
Die Schwachstellen verschwinden nicht einfach. Abhängigkeiten werden weiterhin anfällige Versionen an unerwarteten Stellen verbergen. Altsysteme werden sich weiterhin gegen einfache Upgrades wehren. Es könnten noch neue Log4j-Sicherheitslücken entdeckt werden. Die Arbeit ist nie wirklich abgeschlossen.
Das ist jedoch kein Grund zur Verzweiflung oder Lähmung. Es ist vielmehr ein Grund, nachhaltige Vorgehensweisen zu etablieren, die das Management solcher Risiken zur Routine statt zur Ausnahme machen. Teams, die die Sicherheit von Abhängigkeiten als kontinuierliche Aufgabe und nicht als periodisch auftretende Krise betrachten, bewältigen solche Situationen wesentlich effektiver.
Es geht nicht darum, Perfektion zu erreichen. Es geht darum, den Überblick zu behalten, Risiken intelligent zu managen und kontinuierlich Fortschritte zu erzielen. So sieht nachhaltige Sicherheit in der Praxis aus.
Die Log4Shell-Panik ist längst vorbei. Doch die Geschichte um die Log4j-Sicherheitslücke geht weiter. Bleiben Sie weiterhin wachsam.
Wenn Sie langfristige Sicherheitsupdates wünschen, die Ihnen auch weit über das Ende des Supportzeitraums hinaus Schutz bieten, informieren Sie sich hier Endless Lifecycle Support für Log4j.
