Log4j-Schwachstelle Log4Shell
Jackpot für Kriminelle
Fortsetzung des Artikels von Teil 2
Sicherheit der digitalen Supply Chain verbessern
Von Anfang an stand eine Frage im Raum: Welche Rolle spielt der Umstand, dass es sich hier um Open Source handelt, bei dieser Sicherheitslücke? Schließlich beruht ein erheblicher Teil der globalen Digitalinfrastruktur auf der Arbeit Freiwilliger, die – oft in ihrer Freizeit und ohne jegliche Vergütung – quelloffenen Code schreiben und zur Verfügung stellen. Als Sicherheitsvorteil quelloffener Software gilt, dass jedermann und jedefrau jederzeit jede Codezeile einsehen und überprüfen kann.
„Generell kann jede Software anfällig für Angriffe sein, und bei populärer Open-Source-Software gibt es oft ein großes Ökosystem, das nach Sicherheitsbedrohungen sucht und diese behebt“, erläutert Barracuda-Mann Tanner. Er betont: „Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist.“ Closed Source ist also keineswegs die bessere Alternative – auch hier gibt es genügend Beispiele für Sicherheitslücken.
Ein Damoklesschwert kann allerdings laut scheppernd herunterkrachen, wenn es sich um ein verbreitetes, aber aus Entwicklersicht „unsexy“ Stückchen Code handelt, für das sich nur „irgendjemand in Nebraska“ verantwortlich fühlt – das deutsche Pendant der Metapher wäre: „irgendjemand auf einer Almhütte im tiefsten Allgäu“. Denn da hängt der Code mitunter nur an einer Person – bei Log4j übrigens an drei Personen in der Schweiz. Wie also lässt sich das „Nebraska-Almhütten-Problem“ nicht nur im aktuellen Einzelfall, sondern dauerhaft lösen?
Ein erster Schritt könnte es laut Marktkennern sein, die Open-Source-Entwicklergemeinde finanziell besser auszustatten. Das muss nicht heißen, dass alle Freiwilligen künftig Honorar erhalten. Doch dass Organisationen wie die Apache Foundation von den Zuwendungen einer Sponsorenschar abhängig sind, wird der eminenten Rolle nicht gerecht, die Open-Source-Code in der digitalisierten Welt spielt. So schlug Filippo Valsorda, verantwortlich für die Security in Googles Go-Team, auf seinem Blog vor: Open-Source-Entwickler sollten den Unternehmen, die von ihrer Arbeit abhängen, ruhig mal fünf- bis sechsstellige Rechnungen schicken.
Hierzulande fordert die Open Knowledge Foundation vor dem Hintergrund politischer Bestrebungen, stärkere digitale Souveränität zu etablieren: Für die Entwicklung, Verbesserung und Instandhaltung offener digitaler Basistechnologien müsse es einen „Sovereign Tech Fund“ geben, um das Open-Source-Ökosystem nachhaltig zu stärken.
Ein Bremsklotz: Dazu muss man staatliche Finanzbürokratie in Einklang bringen mit einer agilen Softwareentwicklungswelt – nicht unbedingt ein Traumpaar. Immerhin, erste Ansätze dazu gab es bereits: Das Fossa-Projekt (Free and Open Source Software Auditing) der EU zielte darauf ab, die Sicherheit und Integrität kritischer Open-Source-Software zu erhöhen. Die Europäische Kommission hatte es 2014 nach der Entdeckung des Heartbleed-Bugs ins Leben gerufen – das Projekt lief jedoch im Juli 2020 aus.
Als – neben der leidigen Finanzierungsfrage – zweite große Hürde besteht die immense Herausforderung, in der DevOps- und idealerweise DevSecOps-Welt den Überblick über die zahllosen verwendeten Softwarebausteine zu behalten. Nicht umsonst herrschte anfangs die erwähnte Unsicherheit, wen Log4Shell überhaupt betrifft. So stellt Udo Schneider, IoT-Security-Experte beim japanischen Sicherheitsanbieter Trend Micro, die provokante Frage: „Nutzt vielleicht eine bei Ihnen eingesetzte Bibliothek eines Drittanbieters intern Log4J? Oder noch schlimmer – nutzt eine Library, die Sie verwenden, eine Library, die wiederum von einer Library abhängt und so weiter, die Log4J nutzt?“ Schneider rät deshalb zu einer „Software Bill of Materials“ (SBOM, Software-Materialstückliste), also zur Dokumentation der Softwarebausteine und zum Tracking von deren Abhängigkeiten. Der SBOM-Einsatz müsse einhergehen mit einem Schwachstellen-Monitoring und einem Software-Supply-Chain-Management.
Wichtig: Nicht nur in der IT-, sondern auch in der OT-Welt (Operational Technology, industrielle Betriebstechnik) kann ein Eingreifen erforderlich sein: „Die meisten OT-Infrastrukturen basieren auf alter Technologie und eingeschränkten, eingebetteten Systemen. Hier kam Java kaum zum Zug, sodass die Gefahr weniger groß ist“, erklärt Tony de Bos, Vice President Operations bei Kudelski Security. Doch er warnt: „Moderne OT-Anlagen mit Internetzugang sind dagegen ähnlich bedroht wie herkömmliche IT-Systeme – und Hacker werden diese Gelegenheit ausnutzen. Betroffene sollten sich Transparenz über ihre Anlagen verschaffen und insbesondere für Altanlagen ohne Aussicht auf Patches alternative Sicherheitskonzepte suchen.“
Laut Fachleuten haben wir hinsichtlich der Schäden, die Log4Shell anrichten kann, bislang wohl nur die Spitze des Bauklötzchenbergs gesehen – schließlich steckt Log4j nicht nur in Cloud-Services und Enterprise-Applikationen, sondern auch in Switches, WLAN-Routern und industrieller Betriebstechnik. Wünschenswert wäre, dass Log4Shell als Weckruf dient, die Open-Source-Sicherheit ebenso ernst zu nehmen, ebenso finanziell zu unterfüttern und ebenso effizient zu organisieren wie die Sicherheit kommerzieller Software – idealerweise sogar effizienter. Hier heißt es: nicht kleckern, sondern klotzen! Denn sonst werden wir uns künftig immer wieder bei Lücken in scheinbar nebensächlichen Softwarekomponenten aus irgendeiner Entwickler-Almhütte die Augen reiben und angesichts der enormen Auswirkungen einer Lücke Bauklötzchen staunen.
- Jackpot für Kriminelle
- Sisyphusarbeit
- Sicherheit der digitalen Supply Chain verbessern
Lesen Sie mehr zum Thema
