Warum Log4j-Sicherheitslücken die Bedeutung von DevSecOps unterstreichen

Im Dezember 2021 erhielten IT-Sicherheitsteams und Entwicklungsorganisationen auf der ganzen Welt einen unhöflichen Weckruf. Forscher hatten eine schwerwiegende Sicherheitslücke im Apache Log4j Utility entdeckt, einer beliebten Logging-Komponente, die in unzählige Java-Anwendungen und -Dienste eingebettet ist. Die Nachricht von dieser Sicherheitslücke veranlasste IT-Sicherheitsteams und Entwicklungsorganisationen dazu, alle Instanzen der anfälligen Versionen von Log4j in ihren eigenen Netzwerken zu finden.

Die Log4j-Sicherheitslücke hat die DevSecOps-Teams auch gezwungen, eine Frage zu beantworten, die sich jetzt weniger theoretisch anfühlt. Wenn Log4j oder eine andere Sicherheitslücke eine intern entwickelte Anwendung gefährden würde, wären die Sicherheitsteams dann in der Lage, den Angriff zu isolieren und seinen Schaden zu mindern? Bereiten aktuelle DevOps-Praktiken ein Unternehmen darauf vor, mithilfe seines eigenen Codes schnell und effektiv auf die Suche nach Bedrohungen zu gehen?

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

Die Log4j-Sicherheitslücke und warum sie wichtig ist

Die Sicherheitslücke, die all diese Aufmerksamkeit auf sich zieht, beinhaltet Verwendung des Java Naming and Directory Interface durch Log4j (JNDI), eine beliebte Benennungs- und Such-API für Java-Anwendungen. Frühe Versionen von Log4j aktivierten standardmäßig die Substitutionsfunktion von JNDI für die Nachrichtensuche. Mithilfe dieser Funktion können Angreifer sorgfältig konstruierte 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 könnte 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 ist 4 Prozent der Java-Pakete im Maven Central Repository, das weithin als das wichtigste Java-Paket-Repository anerkannt ist. Log4j wird in allen Arten von Software verwendet, von Webanwendungen über Back-End-Dienste bis hin zu benutzerdefinierten Apps für IoT-Geräte.

Sobald diese Sicherheitslücke bekannt wurde, begannen IT-Sicherheitsteams, ihre Netzwerke zu durchsuchen und nach Dateinamen und anderen Hinweisen auf die Präsenz von Log4j in einem beliebigen Verzeichnis in ihrer Umgebung zu suchen. DevOps-Teams waren ebenfalls damit beschäftigt, ihre eigenen Archive nach einer möglichen Verwendung von Log4j in ihren eigenen Anwendungen zu durchsuchen.

Es steht viel auf dem Spiel. Cyberkriminelle haben diese Sicherheitslücke 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 Sicherheitslücke abzielen. Zum Beispiel neue Night Sky-Ransomware-Ziele Log4j-Sicherheitslücken in der VMware Horizon-Software.

Das Gesamtbild: Schwachstellen im Quellcode und die damit verbundenen Risiken

Die Log4j-Sicherheitslücke verdeutlicht zwei größere Probleme für interne Entwicklungsorganisationen. Erstens haben die meisten Unternehmen, unabhängig davon, wie gut ihre DevOps-Tools und -Prozesse organisiert sind, Schwierigkeiten, alle in ihren Anwendungen verwendeten Komponenten zu ermitteln, 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 Hilfsprogramm in eine Anwendung aufzunehmen, ohne eine Log4j-JAR-Datei in einem Repository zu belassen. Es ist eine schwierige und zeitaufwändige Arbeit, alle Versionen aller Softwarekomponenten — ob Open Source oder nicht — in Anwendungen zu finden.

Zweitens: Wenn festgestellt wird, dass eine Anwendung aufgrund einer Sicherheitslücke angegriffen wird, müssen die Sicherheitsteams eine Möglichkeit haben, 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 wichtig, um sensible Daten zu schützen und die Betriebskontinuität sicherzustellen, obwohl diese Ziele offensichtlich von entscheidender Bedeutung sind.

Aber es gibt auch einen Compliance-Aspekt. Am 4. Januar 2022 wurde Die US-amerikanische Federal Trade Commission (FTC) kündigte an, Strafen und Bußgelder durchzusetzen gegen Unternehmen, die aufgrund der Log4j-Sicherheitslücken den Zugriff auf vertrauliche Verbraucherdaten zugelassen haben.

Unter Berufung auf Strafe in Höhe von 700 Millionen US-Dollar gegen Equifax Wegen des Durchsickerns von Verbraucherdaten aufgrund einer ungepatchten Sicherheitslücke im Apache Struts-Framework kündigte die FTC an, dass sie „beabsichtigt, ihre vollen rechtlichen Befugnisse zu nutzen, um Unternehmen zu verfolgen, die es versäumen, angemessene Maßnahmen zu ergreifen, um Verbraucherdaten in Zukunft vor einer Offenlegung durch Log4j oder ähnliche bekannte Sicherheitslücken zu schützen“.

Es stellt sich heraus, dass Log4j die Spitze eines riesigen Eisbergs potenzieller Bedrohungen ist. Um Sicherheitslücken zu finden und zu beheben, die sich nicht nur auf Log4j beziehen, sondern auch auf jede Softwarekomponente In ihren eigenen Anwendungen oder Anwendungen von Drittanbietern, die sie ausführen, benötigen Unternehmen einen umfassenden Einblick in ihre Softwareumgebungen. Wenn diese Sicherheitslücken nicht gefunden werden, bevor sie zu einer Datenschutzverletzung führen, kann dies zu hohen behördlichen Bußgeldern und dauerhaften Schäden für die Marke eines Unternehmens führen.

Zum Glück kann DevSecOps helfen.

Die Rolle von DevSecOps bei der Minderung von Bedrohungen durch Softwareschwachstellen

Die Idee hinter DevSecOps ist einfach: Sicherheit sollte kein nachträglicher Gedanke sein, wenn es um die Entwicklung und Bereitstellung von Software geht. Stattdessen sollte Sicherheit in jeden Schritt von DevOps einbezogen werden, vom Design über die Entwicklung über das Testen bis hin zur Veröffentlichung und zum Betriebsmanagement. DevSecOps ist die Praxis, Sicherheit in die Softwareanwendungen zu integrieren, die über DevOps-Prozesse entwickelt und verwaltet werden.

Wie kann DevSecOps helfen, Probleme wie die Log4j-Sicherheitslücke zu beheben?

Erstens würden die Best Practices von DevSecOps die Entwicklungsteams dazu auffordern, aktualisierte Versionen von Komponenten wie Log4j zu verwenden, wenn sie Anwendungen erstellen und verwalten.

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

Ebenso wichtig ist, dass die Best Practices von DevSecOps die Einbettung von Sicherheitskontrollen in Anwendungen vorsehen, sodass Teams darauf vorbereitet sein können, alle einzudämmen, wenn sich unweigerlich eine andere Open-Source-Bibliothek oder -Komponente als anfällig herausstellt Zero-Day-Angriffe gegen diese Sicherheitslücke schnell und effektiv. Wenn bereits Abwehrmaßnahmen getroffen wurden, kann das Unternehmen handeln, um einen Angriff abzuwehren, auch wenn ein Patch für die Sicherheitslücke Tage oder Wochen entfernt ist.

Eine der besten Sicherheitskontrollen, die es einzubetten gilt, ist eine Zero-Trust-Segmentierungslösung, die die in den Systemen integrierten Firewalls verwendet, um Sicherheitsrichtlinien durchzusetzen und den Netzwerkverkehr nur auf autorisierte Benutzer und Prozesse zu beschränken. Durch die Zero-Trust-Segmentierung werden die Netzwerkpfade, die Angreifern zur Verfügung stehen, drastisch reduziert und sie auf den wenigen Systemen isoliert, die sie möglicherweise 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 im Netzwerk stattfindet, 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 fest wie ein glückloser Einbrecher, der es geschafft hat, durch ein Dachfenster einzudringen, nur um sich in einer Bärenfalle wiederzufinden. Sie sind reingekommen, aber sie gehen nirgendwohin. Und es wurde ein Alarm ausgelöst.

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

Illumio Zero Trust-Segmentierung ist eine wertvolle Sicherheitslösung für jede DevSecOps-Organisation, da sie es Entwicklungsteams leicht macht, strenge Sicherheitskontrollen in Anwendungen einzubetten, ohne sich mit den Feinheiten der 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 dann mithilfe der von Illumio problemlos durchsetzen Virtueller Erzwingungsknoten (VEN) zusammen mit den hostbasierten Firewalls, die bereits in die Systeme integriert sind, auf denen die Anwendungen des Unternehmens ausgeführt werden. Der Illumio VEN ist ein leichter, ausfallsicherer Client, der einfach in Software-Builds integriert werden kann. Es sind keine umfassenden Designänderungen erforderlich.

Die Illumino-Lösung verwendet Firewalls, erspart Entwicklern jedoch die Mühe, komplexe Firewall-Regeln programmieren zu müssen. Stattdessen können Entwickler und Sicherheitsteam die Richtlinien definieren, die durchgesetzt werden sollen, sodass nur der erforderliche Datenverkehr ihre Anwendungen durchläuft, und diese Richtlinien dann zur Durchsetzung an VENs weitergeben, die in Anwendungen integriert sind.

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

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

Dann fügt das DevSecOps-Team einfach ein Illumio VEN zu einem Software-Build hinzu. Sobald das VEN in der Anwendungsumgebung ausgeführt wird, erzwingt es Zero-Trust-Richtlinien, warnt bei Erkennung verdächtiger seitlicher Bewegungen und schränkt den Datenverkehr als Reaktion auf aktive Angriffe ein, sodass infizierte Endgeräte vom Rest des Netzwerks isoliert werden.

Illumio bietet auch eine C-VEN-Client und Kubelink-Service zur Verwendung in containerisierten Umgebungen, die in Microservices-Architekturen beliebt sind. C-VEN ist ein leichter Illumio-Agent, der als Pod auf jedem Knoten in einem Kubernetes-Cluster läuft und den Knoten und alle darauf laufenden Pods schützt. C-VEN wird als DaemonSet bereitgestellt und skaliert je nach Entwicklung des Clusters nach oben und unten. Kubelink ist ein Illumio-Service, der den Kubernetes-API-Server überwacht, um mehr über die Ressourcen innerhalb des Clusters zu erfahren und dem PCE den Kubernetes-Kontext zur Verfügung zu stellen. Er wird als Paket geliefert und benötigt nur ein Replikat pro Cluster, was dazu beiträgt, die Illumio Container-Lösungen hochgradig skalierbar zu machen.

DevSecOps-Teams haben zwei Möglichkeiten, mit dem Illumio PCE zu interagieren: über die PCE-Benutzeroberfläche oder die gut dokumentierten REST-APIs. DevSecOps-Teams können die APIs verwenden, um Illumio in CI/CD-Pipelines zu integrieren, sodass 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 eingesetzt werden, einschließlich Endpunkten in:

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

Log4j wird nicht die letzte Softwarekomponente sein, die eine gefährliche Sicherheitslücke enthält. Durch die Einführung von DevSecOps-Praktiken und den Einsatz von Illumio zur Durchsetzung der Zero-Trust-Segmentierung in Anwendungen auf der ganzen Welt 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:

• Schauen Sie sich die Lösungsübersicht an, Illumio für DevSecOps.
• Kontaktiere uns für eine Demo.