Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
34 LANline 2 2022 www lanline de Schwerpunkt Security gen für die Applikationen haben können die von der Schwachstelle betroffen sind“ so Hänsler Deshalb gebe es in Fachkreisen „unterschiedliche Sichtweisen zu den Mitigationsstrategien“ Viele Anbieter nutzen die Gelegenheit auf den Wert ihrer eigenen Security-Lösungen für diese Mitigationsstrategien hinzuweisen In der Tat kann praktisch die gesamte Bandbreite der Security-Lösungen von der Code-Qualitätskontrolle im DevOps-Einsatz bis hin zu EDR NDR und XDR Endpoint Network Extended Detection und Response zum Aufspüren von Angriffsversuchen hier ihre Schlagkraft unter Beweis stellen Talos empfiehlt den Unternehmen darüber hinaus die Aktualisierung von Incident-Response-Plänen und Playbooks oder eine Tabletop-Übung um ihre Reaktionsfähigkeit bei derlei Vorfällen zu testen 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ünfbis 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 DevOpsund 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 „Moderne OT-Anlagen mit Internetzugang sind ähnlich bedroht wie herkömmliche IT-Systeme“ warnt Tony de Bos von Kudelski Security Bild Kudelski Security Security-Experte Udo Schneider von Trend Micro rät zur Erstellung einer „Software Bill of Materials“ SBOM Bild Trend Micro