Apache Log4j-Sicherheitslücke rückt Drittanbieter-Software ins Rampenlicht

Während Unternehmen auf der ganzen Welt darum ringen, die kritische Log4j-Schwachstelle, genannt Log4Shell, zu beheben, lautet die wichtigste Frage, die sich jeder Sicherheitsverantwortliche stellt: Wie finde ich heraus, ob diese Schwachstelle bei mir vorhanden ist?

Die schiere Allgegenwärtigkeit von Apache Log4j, einem Open-Source-Logging-Framework, macht die Beantwortung dieser Frage besonders schwierig.

Viele Unternehmen verwenden Log4j nicht nur in ihrem eigenen Quellcode, sondern es kommt auch in vielen der Produkte zum Einsatz, die diese Unternehmen von Dritten erwerben. Unternehmen, die den „Shift Left“-Ansatz für ihren Lebenszyklus der sicheren Softwareentwicklung (SSDL) übernommen haben, können ihren eigenen Quellcode analysieren, um die Schwachstelle in ihren eigenen Systemen zu finden und zu beheben.

Es ist ein SSDL-Ansatz erforderlich, der statische Tests der Anwendungssicherheit (SAST), dynamische Tests der Anwendungssicherheit (DAST), Überprüfung der Abhängigkeiten von Drittanbietern, Container-Sicherheitsscans, Schwachstellen-Management sowie Infrastructure as Code (IaC) umfasst. Aber selbst wenn all diese Verfahren vorhanden sind, wird es Unternehmen dennoch schwer fallen, alle Sicherheitsprobleme frühzeitig genug im Lebenszyklus aufzudecken. Schwachstellen-Management und Web Application Scanning sind ebenfalls von entscheidender Bedeutung, insbesondere im Hinblick auf Ihre Drittanbieter-Software. Die Feststellung, ob eine Schwachstelle vorhanden ist oder nicht, reicht allein nicht aus – Sie müssen auch den Grad des Risikos kennen, das diese Schwachstelle im Kontext der verschiedenen Anwendungen, Assets und Geschäftsprozesse in Ihrem Unternehmen darstellt.

Obwohl die jüngste Verfügung der Biden-Administration Unternehmen dazu anhält, eine Software-Bill-of-Materials (SBOM) zu erstellen, liefern die meisten Anbieter keine SBOMs für ihre Software. Und selbst wenn sie es täten, sind die meisten Unternehmen noch lange nicht so weit, dass sie über die Prozesse und Fähigkeiten verfügen, um diese effektiv nutzen zu können. Wenn also ein Vorfall wie log4j eintritt, bleibt den Cybersecurity-Verantwortlichen nur eine Möglichkeit: Ihre Drittanbieter anzurufen und sie zu fragen. Das ist mühsam, umständlich und zeitaufwändig und führt dazu, dass Unternehmen in Bedrängnis kommen, wenn Angreifer sich auf diese Schwachstelle stürzen.

Nur die FAQs: CVE-2021-45046, CVE-2021-4104:Häufig gestellte Fragen zu Log4Shell und damit verbundenen Schwachstellen.

Selbst in den ausgereiftesten Organisationen, in denen SSDL-Verfahren und SBOMs in den Prozessen verankert sind, bleiben Lücken, die es für Sicherheitsteams schwierig machen, diese entscheidenden fünf Fragen zu beantworten:

1. Werden diese Software-Programme in unseren Umgebungen ausgeführt?
2. Was ist mit unserer Infrastruktur?
3. Wie sieht es in unseren eigentlichen Build-Pipelines aus?
4. Was ist mit den Providern unserer Infrastruktur? (Dieser Punkt ist besonders wichtig, wenn Sie die Dienste von Cloud-Providern nutzen)
5. Da die Analyse der Softwarezusammensetzung (Software Composition Analysis, SCA) nicht sämtliche Instanzen von Log4J aufdecken wird, haben wir andere Kontrollen wie Infrastructure as Code (IaC), Schwachstellen-Management und Web Application Scanning für alle Komponenten unseres Codes durchgeführt?

Unterm Strich bedeutet dies: Es gibt keine einfache Lösung für Log4j. Eine naheliegende Option – die Implementierung einer Web Application Firewall– hat sich bereits als relativ leicht umgehbar erwiesen. Ein verantwortungsbewusstes Unternehmen muss sich die Arbeit machen, seine Kernsoftware zu aktualisieren und zu verstehen, wie sich diese Sicherheitslücke auf das gesamte Risikoprofil auswirkt. Sobald die anfängliche Krise überwunden ist, wird die Versuchung groß sein, die Sache für erledigt zu erklären und sich anderen Dingen zuzuwenden. Unserer Meinung nach wäre das ein katastrophaler Fehler. Es ist längst an der Zeit, dass Unternehmen sich die Mühe machen, ihre Infrastruktur auf Vordermann zu bringen und ihre Systeme mit einem Ansatz zu warten, bei dem Sicherheit im Vordergrund steht.

Wir bei Tenable haben uns SSDL verschrieben und ergreifen die folgenden Maßnahmen als Reaktion auf Log4j:

• Wir haben blockierende Gates, und in diesem Fall blockieren wir die Verwendung aller anfälligen Instanzen von Software, einschließlich Log4j. 
• Wir führen aktiv und kontinuierlich Schwachstellenmanagement-Scans und Web-App-Scanning für unsere gesamte Infrastruktur sowie für vor der Veröffentlichung stehenden Produktcode durch, bevor dieser an Kunden ausgeliefert wird.
• Darüber hinaus haben wir alle Indicators of Compromise (IoC) und Indicators of Attack (IoA) untersucht und Kontrollen auf Netzwerk- und Host-Ebene implementiert.

Wir werden weiterhin Threat Intelligence überwachen, um die Bedrohungslandschaft zu verfolgen und bei Bedarf entsprechende Anpassungen vorzunehmen. Letztendlich geht es bei jeder Reaktion auf einen Vorfall darum, zu wissen, was in Ihrer Umgebung vorhanden ist, Ihre Angriffsoberfläche zu kennen – einschließlich aller Drittparteien - und das Risiko möglichst schnell zu reduzieren. Es ist Eile geboten. Angreifer stehen stets in den Startlöchern, um sich auf die neuesten Schwachstellen zu stürzen und sie für ihre eigenen Zwecke auszunutzen. Unternehmen müssen alles daran setzen, ihre Vorgehensweisen jetzt auf den Prüfstand zu stellen, denn die Auswirkungen dieses Vorfalls werden Unternehmenssoftware noch über Jahre hinweg belasten.

Mehr erfahren

• Besuchen Sie das Tenable-Lösungscenter für Log4j: https://www.tenable.com/log4j
• Lesen Sie die SRT-Warnung: CVE-2021-44228: Proof-of-Concept für kritische Remote Code Execution-Schwachstelle in Apache Log4j verfügbar (Log4Shell)
• FAQs lesen: CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: Häufig gestellte Fragen zu Log4Shell und damit zusammenhängenden Schwachstelen
• Lesen Sie die Perspektive unseres CTO: Apache Log4j-Schwachstelle: Ein Fukushima-Moment für die Cybersecurity-Branche
• Besuchen Sie unsere User-Community, um mehr darüber zu erfahren, wie Tenable helfen kann: https://community.tenable.com/s/