Ein Rückblick auf Log4j Teil 4: 5 Lektionen von Log4j
In Teil 4 der Log4j-Rückblickreihemöchte ich die wichtigsten Erkenntnisse hervorheben. Bei der Arbeit zur Behebung dieser Schwachstelle werden noch viele weitere Lektionen aufgedeckt werden. Es gibt jedoch bereits fünf grundlegende Erkenntnisse.
1. Die neue Norm
Sowohl die Komplexität der Software als auch die Geschwindigkeit, mit der Endnutzer neue Funktionen verlangen, wachsen immer schneller und ohne Grenzen. Um die Anforderungen der Endnutzer im erforderlichen Zeitrahmen zu erfüllen, müssen sich Entwickler auf eine schnell wachsende Anzahl verfügbarer Bibliotheken, Sprachökosysteme und Drittanbieter-Infrastrukturen und -Services verlassen. Dies hat zur Folge, dass ein immer größerer Teil der Funktionalität einer Software aus Komponenten besteht, die die Entwickler selbst vielleicht nie angefasst oder verstanden haben.
In jedem Software-Abhängigkeitsdiagramm werden Schwachstellen von Blattknoten (gemeinsamer Code und gemeinsame Services) nach oben an den Stammknoten oder das zu programmierende Produkt vererbt. Da immer mehr dieser Blattknoten einem Projekt hinzugefügt werden (wie oben beschrieben), erhöht sich auch das Risiko einer Schwachstelle.
All dies führt zu einer unvermeidlichen Schlussfolgerung: Diese Art von Schwachstellen wird nicht nur bestehen bleiben, sondern auch immer häufiger auftreten und sich immer stärker auswirken.
Das ist die neue Norm.
2. Risiko ist rekursiv
Wir denken oft fälschlicherweise, dass sich das Risiko auf die Systeme, die Software und die Funktionen bezieht, die wir direkt kontrollieren können. Fortschrittlichere Unternehmen bewerten das Risiko eine Stufe tiefer, indem sie beispielsweise ihre Entwickler bitten, die Vertrauenswürdigkeit einer bestimmten Bibliothek zu prüfen.
Da jedoch immer mehr Systeme und Software auf immer mehr Schichten von Drittanbietercode aufgebaut sind, müssen Unternehmen zunehmend nicht nur das Risiko einer bestimmten Bibliothek oder eines Partners bewerten, sondern auch die Praktiken dieser Entwicklergemeinschaft oder dieses Anbieters. Nur so können sie sicherstellen, dass auch ihre Abhängigkeiten geprüft werden.
Jeder Knoten in der Abhängigkeitsstruktur und in der Lieferkette sollte von Ihnen, Ihren Partnern und/oder der jeweiligen Entwicklungsgemeinschaft bewertet werden, um festzustellen, ob das tolerierbare Risikoniveau erreicht ist.
3. Geschwindigkeit dank Transparenz
Selbst wenn die oben genannten Risikobewertungen durchgeführt wurden, werden Schwachstellen auftreten. Wir müssen diese Tatsache akzeptieren. Die Frage ist, wie wir die Situation effektiver angehen können, wenn sie eintritt – und nicht, wie wir sie gänzlich verhindern können.
Zu diesem Zweck ist Transparenz ist von größter Bedeutung. Viele Unternehmen tun sich mit dem Patching schwer, weil sie nicht wissen, welche Rechner überhaupt betroffen sind. Unternehmen müssen über Systeme verfügen, die einen Einblick in die Abläufe im Rechenzentrum und in der Cloud ermöglichen.
Je umfassender und genauer die Transparenz ist, desto schneller kann ein Unternehmen reagieren und die notwendigen Maßnahmen ergreifen.
4. Das Offensichtliche herausfiltern
Viele Schwachstellen können nur durch eine Kette von Exploits angegriffen werden. Das Durchtrennen eines Teils der Kette reicht oft aus, um eine vollständige Ausbeutung zu verhindern. Folglich sind Systeme, die sowohl frühere als auch offensichtliche Angriffe herausfiltern, von entscheidender Bedeutung.
Unternehmen sollten die folgenden Systeme priorisieren:
- Endpoint Protection Platforms (EPP)
Schützen Sie Endgeräte vor bekannter schädlicher Software.
Web Application Firewalls (WAF)
Schützen Sie Webanwendungen vor bekannten schädlichen Payloads und Bedrohungsakteuren – nutzen Sie den erstklassigen Kona-Schutz von Akamai
DNS-Firewall
Schützen Sie Endpoints vor dem Besuch schädlicher Domains und filtern Sie schädliche DNS-Payloads heraus – erwägen Sie die Akamai-Lösung Enterprise Threat Protection
Secure Web Gateway (SWG)
Schützen Sie Ihre Endpoints vor dem Herunterladen von Malware und dem Besuch schädlicher Websites im Internet – nutzen Sie die Akamai-Lösung Enterprise Threat Protection
Multi-Faktor-Authentifizierung (MFA)
Verringern Sie das Risiko, dass gestohlene Anmeldedaten den Zugang zu Ihrem Unternehmen ermöglichen, wodurch eine Exploit-Kette entstehen kann – erwägen Sie Akamai MFA
Identitätsbasierte Segmentierung
Beschränken Sie Software und Systeme darauf, nur mit den Maschinen zu kommunizieren, die für die Erfüllung ihrer Aufgaben erforderlich sind – erwägen Sie Akamai Guardicore Segmentation
Zero Trust Network Access (ZTNA)
Begrenzen Sie die Auswirkungen infizierter Endnutzer, die ins Netzwerk gelangen – erwägen Sie Akamai Enterprise Application Access
5. Das Prinzip der geringstmöglichen Berechtigungen ist Trumpf
Schließlich sollten Unternehmen das Prinzip der geringstmöglichen Berechtigungen voll und ganz anwenden. Sperren Sie Server, Maschinen und Software so, dass sie nur auf die Systeme zugreifen können, die für die Ausführung ihrer Aufgaben erforderlich sind.
Viele der Systeme, die im Rahmen des Log4j-Exploits ausgehende LDAP-Aufrufe tätigen, mussten beispielsweise noch nie LDAP verwenden. Bei solchen Systemen sollte der Zugang zu LDAP durch eine Firewall geschützt sein. Weiteres Beispiel: Wenn ein Service nur eingehende Anfragen beantwortet, blockieren Sie ausgehende Verbindungen.
Durch die Anwendung des Prinzips der geringstmöglichen Berechtigungen auf alle Systeme und sämtliche Software, die Sie kontrollieren, können Sie die Angriffsfläche bei Schwachstellen erheblich reduzieren und in vielen Fällen die Angriffskette stoppen, bevor Sie betroffen sind.
Weitere Informationen
Danke, dass Sie mit mir bis zum Ende dieser Reihe durchgehalten haben. Auch wenn diese Blogreihe hier endet, geht unsere Forschung und der Schutz unserer Kunden vor Sicherheitslücken weiter. Zögern Sie nicht, sich mit Ihrem Akamai-Kontakt in Verbindung zu setzen, wenn Sie mehr über folgende Themen erfahren möchten: Unsere Empfehlungen zur Risikominderung Log4j und andere Bedrohungen.
