Spätestens seit dem 10. Dezember kennt die ganze Welt ein kleines Stück Programmcode, welches bisher bestenfalls nur Entwicklern und Systemadministratoren ein Begriff war: Log4j. Die unerwartet große Bekanntheit verdankt das Softwareteilchen einer schweren kritischen Sicherheitslücke namens Log4Shell, die viele Versionen der Apache Log4j Anwendung betrifft, und die an diesem Tag öffentlich bekannt wurde. Experten bezeichnen Log4Shell als die größte und kritischste Schwachstelle aller Zeiten.
Log4j steht für Logging for Java. Eingesetzt wird es von vielen Entwicklern, die in der Programmiersprache Java Software entwickeln. Der Baustein Log4j ist dazu da, ein Protokoll aller Prozesse zu erstellen, die bei der Anwendung einer Software ablaufen. Was ist im Dezember passiert? Eine bisher unbekannte Schwachstelle wurde öffentlich. Das Problem dabei: Log4j wird millionenfach in Systemen und Anwendungen eingesetzt. In vielen Fällen betrifft es Komponenten, die zudem direkt aus dem Internet erreichbar sind. Dementsprechend haben verschiedene Actor Groups begonnen, die Welt nach diesen Schwachstellen abzusuchen. Sie liefern sich nun ein Wettrennen mit den Security-Teams, welche die betroffenen Systeme aktualisieren, um diese Schwachstelle so rasch wie möglich zu beheben. Eine stetig aktualisierte Liste mit betroffenen Produkten ist auf der Plattform Github einsehbar.
Rekordjahr 2021
Dieser Vorgang ist in der Fachwelt grundsätzlich unter dem Begriff Zero-Day Schwachstelle bzw. Zero-Day Attacke bekannt. Es handelt sich hier nicht um außergewöhnliche Einzelfälle. Mittlerweile sind Zero-Day Schwachstellen eher zu einer regelmäßigen Erscheinung geworden. Was jedoch auch klar ist: Das Jahr 2021 war in Sachen Zero-Day Vulnerability ein Rekord Jahr.
Das Exposure einer Schwachstelle bestimmt das Risiko maßgeblich.
Dies hat primär zwei Ursachen. Einerseits wurden noch nie so viele Schwachstellen gemeldet. Anderseits wird die Zeitspanne zwischen dem Bekanntwerden einer Schwachstelle bis zu ihrem aktiven Ausnutzen (Exploitation) immer kürzer. Im Fall Log4j waren es gerade mal wenige Stunden. Das stellt die Security- und Sys-Admin Teams vor eine fast unlösbare Aufgabe. Diese Zeit reicht häufig nicht aus, um alle verwundbaren Systeme rechtzeitig zu aktualisieren.
Das sieht im ersten Moment nach einem verlorenen Kampf für die Securityteams aus. Auf jeden Fall erfordert der Umgang mit Schwachstellen ein Umdenken. Der Kampf ist jedoch auf keinen Fall verloren. Dazu müssen wir uns das kleine Einmaleins des Risikomanagements in Erinnerung rufen.
Andere Priorisierung von Zero-Day Schwachstellen
Demnach entsteht ein Risiko, wenn eine gegebene Gefahr (Threat) auf eine entsprechend exponierte (Exposure) Schwachstelle (Vulnerability) trifft. Auf die Threat Actors und auf die Schwachstellen haben wir dabei wenig Einfluss. Allerdings können wir das Exposure der Schwachstellen maßgeblich steuern. Und wenn es uns gelingt, das Exposure einer Schwachstelle im Griff zu haben, dann sinkt auch das gesamte Risiko signifikant. Im Fall von Log4j (und den meisten anderen Zero-Day Schwachstellen) bedeutet das: Wenn es gelingt, die Schwachstelle vom direkten Zugriff von außerhalb meiner Organisation fernzuhalten, dann sinkt das Risiko deutlich und die Verantwortlichen gewinnen Zeit, die Schwachstelle in Ruhe zu beheben. Dieses Problem ist mittlerweile auch den Behörden bewusst geworden. So hat die US Cyber Infrastructure and Security Agency (CISA) Anfang Dezember erstmals eine Direktive erlassen, welche die Schwachstellen nicht mehr nach Kritikalität, sondern nach der aktiven Ausnutzung (Actively exploited) durch Threat Actors priorisiert.
Das Exposure einer Schwachstelle bestimmt das Risiko maßgeblich.
Technisch lässt sich das am besten umsetzen, indem man die Zahl der von außen sichtbaren (exponierten) Systeme grundsätzlich möglichst klein hält und zudem hinter entsprechende Proxy (bspw. Web Application Firewalls und/oder IDS/IDPs) platziert. Diese Systeme erlauben es zudem, auch temporäre Schutz- und/oder Erkennungsmaßnahmen zu implementieren, selbst wenn noch kein offizieller Patch des Herstellers zur Behebung der eigentlichen Schwachstelle verfügbar ist. Zwar können, wie im Fall von Log4j, auch diese Komponenten von Zero-Day Schwachstellen betroffen sein, jedoch lässt sich diese begrenzte Zahl von Systemen wesentlich rascher aktualisieren als dutzende oder sogar hunderte einzelner Systeme und Anwendungen.
Web Application Firewall Lösungen wie Airlock ermöglichen die Funktion des Virtual Patchings. Diese reduzieren das Expsoure einer bestehenden Schwachstelle deutlich.
Die richtigen Schlüsse ziehen
Die finalen Auswirkungen des Log4Shell-Exploits sind noch längst nicht bekannt. Security-Verantwortliche können und sollten diese Erfahrung aber als Gelegenheit nutzen, um ihre Sicherheitsstrategien und -Maßnahmen zu überprüfen und zu optimieren. Denn letztlich ist klar: Jede Organisation kann jederzeit von einer Sicherheitsverletzung betroffen sein. Daher ist es eine unvermeidbare Notwendigkeit, das Unternehmen auf Cyberangriffe und Erpressungssituationen vorzubereiten. Zudem ist es wichtig, zu trainieren, wie mit so einer Situation umgegangen werden kann, wenn sie eintritt – und zwar so, als würde sie tatsächlich eintreten.
ISPIN und Anovis
Sowohl Anovis als auch ISPIN sind Mitglieder der Cybersicherheitsgruppe CymbiQ Group mit Sitz in Zürich. Die CymbiQ Group bündelt verschiedene Cybersicherheitskompetenzen unter einem Dach und bietet integrierte Sicherheitslösungen sowie Cyber-Risk-Resilience-Services aus einer Hand an.