Warum Log4j-Schwachstellen die Bedeutung von DevSecOps unterstreichen

Im Dezember 2021 erhielten IT-Sicherheitsteams und Entwicklungsorganisationen auf der ganzen Welt einen bösen Weckruf. Forscher hatten eine schwerwiegende Sicherheitslücke im Apache Log4j-Dienstprogramm entdeckt, einer beliebten Protokollierungskomponente, die in unzählige Java-Anwendungen und -Dienste eingebettet ist. Die Nachricht von dieser Schwachstelle veranlasste IT-Sicherheitsteams und Entwicklungsorganisationen, sich darum zu bemühen, alle Instanzen der anfälligen Versionen von Log4j in ihren eigenen Netzwerken zu finden.

Die Log4j-Schwachstelle hat die DevSecOps-Teams auch gezwungen, eine Frage zu beantworten, die sich jetzt weniger theoretisch anfühlt. Wenn Log4j oder eine andere Schwachstelle eine intern entwickelte Anwendung kompromittieren würde, wären die Sicherheitsteams dann in der Lage, den Angriff zu isolieren und seinen Schaden zu mindern? Bereiten die aktuellen DevOps-Praktiken ein Unternehmen darauf vor, schnell und effektiv mit seinem eigenen Code auf Bedrohungsjagd zu gehen?

Werfen wir einen kurzen Blick auf die Log4j-Schwachstelle, was sie für DevSecOps-Teams bedeutet und wie die Zero-Trust-Segmentierung von Illumio DevSecOps-Teams dabei helfen kann, Bedrohungen zu mindern, wenn anfällige Software angegriffen wird, bevor sie behoben werden kann.

Die Log4j-Schwachstelle und warum sie wichtig ist

Die Schwachstelle, die all diese Aufmerksamkeit auf sich zieht, betrifft die Verwendung des Java Naming and Directory Interface (JNDI) durch Log4j, eine beliebte Benennungs- und Nachschlage-API für Java-Anwendungen. Frühe Versionen von Log4j aktivierten standardmäßig die Funktion zum Ersetzen von Nachrichtensuchen in JNDI. Mit dieser Funktion können Angreifer sorgfältig erstellte Nachrichten an eine Anwendung senden und die Anwendung dazu zwingen, Code auszuführen, der von LDAP-Servern oder anderen Endpunkten unter der Kontrolle des Angreifers geladen wurde. Dieser Code kann Malware installieren, Daten exfiltrieren oder andere bösartige Aktionen im Netzwerk der Anwendung ausführen.

Log4j ist weit verbreitet. Google schätzt, dass es in 4 Prozent der Java-Pakete im Maven Central Repository enthalten ist, das weithin als das wichtigste Java-Paket-Repository anerkannt ist. Log4j wird in allen Arten von Software verwendet, die von Webanwendungen über Backend-Dienste bis hin zu benutzerdefinierten Apps für IoT-Geräte reichen.

Sobald diese Schwachstelle bekannt wurde, begannen IT-Sicherheitsteams, ihre Netzwerke zu durchsuchen und nach Dateinamen und anderen Hinweisen auf das Vorhandensein von Log4j in einem beliebigen Verzeichnis in ihrer Umgebung zu suchen. Auch DevOps-Teams waren damit beschäftigt, ihre eigenen Archive nach einer Verwendung von Log4j in ihren eigenen Anwendungen zu durchsuchen.

Es steht viel auf dem Spiel. Cyberkriminelle haben diese Schwachstelle bereits genutzt, um Ransomware-Angriffe zu starten, Coin-Mining-Software in Unternehmensnetzwerken zu installieren und das belgische Verteidigungsministerium zu infiltrieren. Angreifer entwickeln neue Formen von Malware, die auf die Schwachstelle abzielen. Die neue Ransomware Night Sky zielt beispielsweise auf Log4j-Schwachstellen in der VMware Horizon-Software ab.

Das große Ganze: Schwachstellen im Quellcode und die Risiken, die sie darstellen

Die Log4j-Schwachstelle wirft ein Schlaglicht auf zwei größere Probleme für interne Entwicklungsorganisationen. Unabhängig davon, wie gut ihre DevOps-Tools und -Prozesse organisiert sind, haben die meisten Unternehmen Schwierigkeiten, alle in ihren Anwendungen verwendeten Komponenten zu bestimmen, insbesondere wenn diese Komponenten als Bibliotheken eingebettet sind oder über Abhängigkeiten mit anderen Diensten darauf zugegriffen wird.

Im Fall von Log4j ist es beispielsweise möglich, das Dienstprogramm in eine Anwendung einzubinden, ohne dass eine Log4j-JAR-Datei in einem Repository verbleibt. Alle Versionen aller Softwarekomponenten – Open Source oder nicht – in Anwendungen zu finden, ist eine schwierige und zeitaufwändige Arbeit.

Zweitens: Wenn festgestellt wird, dass eine Anwendung aufgrund einer Schwachstelle angegriffen wird, benötigen Sicherheitsteams eine Möglichkeit, den Angriff sofort zu isolieren, bevor sich der Angriff auf andere Systeme im Netzwerk ausbreiten kann.

Das Abfangen und Stoppen von Log4j-Angriffen ist nicht nur für den Schutz sensibler Daten und die Gewährleistung der Betriebskontinuität wichtig, obwohl diese Ziele natürlich von entscheidender Bedeutung sind.

Aber es gibt auch einen Compliance-Aspekt. Am 4. Januar 2022 kündigte die US-amerikanische Federal Trade Commission (FTC) an, Strafen und Bußgelder gegen Unternehmen durchzusetzen, die aufgrund der Log4j-Schwachstellen die Verletzung vertraulicher Verbraucherdaten zugelassen haben.

Unter Berufung auf die Strafe in Höhe von 700 Millionen US-Dollar gegen Equifax wegen der Weitergabe von Verbraucherdaten aufgrund einer nicht gepatchten Schwachstelle im Apache Struts-Framework kündigte die FTC an, dass sie "beabsichtigt, ihre volle rechtliche Befugnis zu nutzen, um Unternehmen zu verfolgen, die es versäumen, angemessene Schritte zu unternehmen, um Verbraucherdaten vor der Offenlegung infolge von Log4j oder ähnlichen bekannten Schwachstellen in der Zukunft zu schützen".

Es stellt sich heraus, dass Log4j nur die Spitze eines massiven Eisbergs potenzieller Bedrohungen ist. Um Schwachstellen nicht nur im Zusammenhang mit Log4j, sondern auch in Bezug auf alle Softwarekomponenten in ihren eigenen Anwendungen oder Anwendungen von Drittanbietern, die sie ausführen, zu finden und zu beheben, benötigen Unternehmen einen umfassenden Einblick in ihre Softwareumgebungen. Wenn diese Schwachstellen nicht gefunden werden, bevor sie zu einer Datenschutzverletzung führen, kann dies zu hohen Geldstrafen und dauerhaften Schäden für die Marke eines Unternehmens führen.

Glücklicherweise kann DevSecOps helfen.

Die Rolle von DevSecOps bei der Minderung von Bedrohungen durch Software-Schwachstellen

Die Idee hinter DevSecOps ist einfach: Sicherheit sollte bei der Entwicklung und Bereitstellung von Software nicht im Hintergrund stehen. Stattdessen sollte die Sicherheit in jeden Schritt von DevOps einbezogen werden, vom Design über die Entwicklung und das Testen bis hin zum Release- und Betriebsmanagement. DevSecOps ist die Praxis, Sicherheit in die Softwareanwendungen zu integrieren, die durch DevOps-Prozesse entwickelt und verwaltet werden.

Wie kann DevSecOps helfen, Probleme wie die Log4j-Schwachstelle zu beheben?

Erstens würden die Best Practices von DevSecOps verlangen, dass Entwicklungsteams beim Erstellen und Verwalten von Anwendungen aktualisierte Versionen von Komponenten wie Log4j verwenden.

Zweitens würde DevSecOps auch Entwicklungs- und Testorganisationen dazu auffordern, die Versionen aller Komponenten, einschließlich Open-Source-Komponenten, zu verfolgen, die in Anwendungen verwendet werden. Auf diese Weise kann die DevSecOps-Organisation, wenn die IT-Sicherheits-Community eine Schwachstelle in einer bestimmten Komponente ankündigt, schnell feststellen, welche ihrer eigenen Anwendungen gegebenenfalls betroffen sind.

Ebenso wichtig ist, dass die Best Practices von DevSecOps die Einbettung von Sicherheitskontrollen in Anwendungen erfordern, damit die Teams darauf vorbereitet sind, Zero-Day-Angriffe gegen diese Schwachstelle schnell und effektiv einzudämmen, wenn sich unweigerlich herausstellt, dass eine andere Open-Source-Bibliothek oder -Komponente anfällig ist. Wenn bereits Abwehrmaßnahmen ergriffen wurden, kann das Unternehmen handeln, um sich gegen einen Angriff zu verteidigen, selbst wenn ein Patch für die Schwachstelle noch Tage oder Wochen entfernt ist.

Eine der besten Sicherheitskontrollen für die Einbettung ist eine Zero-Trust-Segmentierungslösung, die die integrierten Firewalls auf den Systemen verwendet, um Sicherheitsrichtlinien durchzusetzen und den Netzwerkverkehr nur auf autorisierte Benutzer und Prozesse zu beschränken. Durch die drastische Reduzierung der Netzwerkpfade, die Angreifern zur Verfügung stehen, schließt Zero Trust Segmentation Angreifer ein und isoliert sie auf den wenigen Systemen, die sie zunächst kompromittieren könnten. Mit der Zero-Trust-Segmentierung wären Angreifer nicht in der Lage, Code von einer bösartigen Website herunterzuladen und auszuführen.

Wenn ein Angriff isoliert über das Netzwerk erfolgt, können Cyberkriminelle Ransomware nicht auf andere Systeme übertragen. Sie können das Netzwerk nicht heimlich erkunden und nach wertvollen Daten suchen, die sie exfiltrieren können. Sie stecken an Ort und Stelle fest wie ein unglückseliger Einbrecher, der es geschafft hat, durch ein Dachfenster hineinzufallen, nur um sich in einer Bärenfalle wiederzufinden. Sie sind reingekommen, aber sie gehen nirgendwo hin. Und es wurde Alarm geschlagen.

Illumio bietet die Transparenz und Automatisierung, die DevSecOps-Teams benötigen

Illumio Zero Trust Segmentation ist eine wertvolle Sicherheitslösung für jedes DevSecOps-Unternehmen, da es Entwicklungsteams leicht macht, strenge Sicherheitskontrollen in Anwendungen einzubetten, ohne sich mit den Feinheiten von Netzwerk- oder Sicherheitspraktiken vertraut machen zu müssen.

Illumio schützt Anwendungen, indem es Entwicklern und Sicherheitsteams die Definition von Zero-Trust-Segmentierungsrichtlinien erleichtert. Einmal erstellt, können Unternehmen diese Richtlinien einfach durchsetzen, indem sie den Virtual Enforcement Node (VEN) von Illumio zusammen mit den hostbasierten Firewalls verwenden, die bereits in die Systeme integriert sind, auf denen die Anwendungen des Unternehmens ausgeführt werden. Der Illumio VEN ist ein leichtgewichtiger, ausfallsicherer Client, der einfach in Software-Builds integriert werden kann. Es sind keine umfangreichen Designänderungen erforderlich.

Die Illumio-Lösung verwendet Firewalls, erspart Entwicklern aber die Mühe, komplexe Firewall-Regeln programmieren zu müssen. Stattdessen können Entwickler und Sicherheitsteams die Richtlinien definieren, die durchgesetzt werden sollen, sodass nur der erforderliche Datenverkehr ihre Anwendungen passieren kann, und diese Richtlinien dann zur Durchsetzung an VENs weitergeben, die in Anwendungen eingebettet sind.

DevSecOps-Organisationen können Richtlinien für verschiedene Anwendungen und Umgebungen feinabstimmen. Insbesondere können sie Richtlinien definieren, die auf Folgendem basieren:

• Rollen innerhalb der Anwendung
• Die Anwendung selbst
• Die Umgebung, in der die Anwendung ausgeführt wird, z. B. Entwicklung, Test oder Produktion
• Der Standort der Umgebung: z. B. eine Produktionsumgebung in einem Rechenzentrum an der US-Westküste

Dann fügt das DevSecOps-Team einfach einen Illumio VEN zu einem Software-Build hinzu. Sobald die VEN in der Anwendungsumgebung ausgeführt wird, setzt sie Zero-Trust-Richtlinien durch, gibt Warnungen aus, wenn verdächtige laterale Bewegungen erkannt werden, und schränkt den Datenverkehr als Reaktion auf aktive Angriffe ein, wodurch infizierte Endpunkte vom Rest des Netzwerks isoliert werden.

Illumio bietet auch einen C-VEN-Client und einen Kubelink-Service für den Einsatz in containerisierten Umgebungen, die in Microservices-Architekturen beliebt sind. C-VEN ist ein schlanker Illumio-Agent, der als Pod auf jedem Knoten in einem Kubernetes-Cluster ausgeführt wird und den Knoten und alle darauf laufenden Pods schützt. C-VEN wird als DaemonSet bereitgestellt und kann mit der Weiterentwicklung des Clusters nach oben und unten skaliert werden. Kubelink ist ein Illumio-Dienst, der den Kubernetes-API-Server überwacht, um mehr über Ressourcen innerhalb des Clusters zu erfahren und dem PCE Kubernetes-Kontext bereitzustellen. Es wird als Paket geliefert und benötigt nur ein Replikat pro Cluster, was dazu beiträgt, die Illumio-Containerlösungen hochgradig skalierbar zu machen.

DevSecOps-Teams haben zwei Möglichkeiten, mit dem Illumio PCE zu interagieren: über die PCE-Benutzeroberfläche oder seine gut dokumentierten REST-APIs. DevSecOps-Teams können die APIs nutzen, um Illumio in CI/CD-Pipelines zu integrieren, so dass die Zero-Trust-Segmentierung zu einem Standardbestandteil der DevSecOps-Workflows wird. APIs ermöglichen es Sicherheitsteams auch, Illumio in andere Sicherheitstools und Workflows zu integrieren.

Die Illumio-Produktsuite bietet Zero-Trust-Segmentierung überall dort, wo Anwendungen und Dienste bereitgestellt werden, einschließlich Endpunkten in:

• Rechenzentren: Illumio Core
• Öffentliche, private oder hybride Clouds: Illumio CloudSecure
• Endgeräte: Illumio Edge

Log4j wird nicht die letzte Softwarekomponente sein, die eine gefährliche Schwachstelle enthält. Durch die Einführung von DevSecOps-Praktiken und den Einsatz von Illumio zur Durchsetzung der Zero-Trust-Segmentierung in Anwendungen überall können Unternehmen darauf vorbereitet sein, ihre Daten, Anwendungen und Mitarbeiter zu schützen, während die zeitaufwändige Arbeit des Netzwerkscans und der Bedrohungssuche weitergeht.

Um mehr zu erfahren:

• Sehen Sie sich die Lösungsübersicht Illumio für DevSecOps an.
• Kontaktieren Sie uns für eine Demo.