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?
Update vom 17. Dezember: Apache hat den Schweregrad von CVE-2021-45046, einer zweiten Log4j-Schwachstelle, von niedrig auf kritisch (9.0 CVSSv3) heraufgesetzt, da unter bestimmten Konfigurationen Remote Code Execution (RCE) möglich ist. Weitere Informationen finden Sie in diesem Beitrag in der Tenable Community.
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:
- Werden diese Software-Programme in unseren Umgebungen ausgeführt?
- Was ist mit unserer Infrastruktur?
- Wie sieht es in unseren eigentlichen Build-Pipelines aus?
- Was ist mit den Providern unserer Infrastruktur? (Dieser Punkt ist besonders wichtig, wenn Sie die Dienste von Cloud-Providern nutzen)
- 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/
Verwandte Artikel
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
FlowFixation: AWS Apache Airflow Service Takeover Vulnerability and Why Neglecting Guardrails Puts Major CSPs at Risk
March 21, 2024Tenable Research discovered a one-click account takeover vulnerability in the AWS Managed Workflows Apache Airflow service that could have allowed full takeover of a victim’s web management panel of the Airflow instance. The discovery of this now-resolved vulnerability reveals a broader problem of misconfigured shared-parent domains that puts customers of major CSPs at risk.
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Enhancing Transportation Cybersecurity and Fleet Management for the DoD
March 25, 2024Few things can halt operations across the Department of Defense like a critical failure of logistics and transportation. From automated asset inventory to malicious-activity detections through baselining, learn how Tenable OT Security can protect these critical functions within the DoD and work towards the federal government’s zero trust mandate in OT environments.
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
- Cloud
- Container security
- Continuous Monitoring
- Incident Response
- Log Analysis
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning