Log4j: BSI empfiehlt Anomalieerkennung. Und nun?

Seit der initialen Veröffentlichung der log4j-Schwachstelle sind einige Wochen vergangen. Inzwischen empfiehlt das BSI explizit den Einsatz von Lösungen zur Anomalieerkennung auf Netzwerkebene.

Was ist seit der Veröffentlichung passiert?

In unserem zurückliegenden Blogpost vom 14.12. “Log4j Schwachstelle – was tun?” sind wir näher auf:

  • die Hintergründe,
  • Möglichkeiten der Schwachstellenerkennung, sowie
  • verschiedene Methoden für die Detektion einer möglichen Kompromittierung

eingegangen.

Inzwischen haben wir, so wie viele andere IT-Sicherheitsdienstleister auch, unsere Kunden aktiv in dieser sehr herausfordernden Situation unterstützt. Hierbei ging es vor allem darum, zügig Maßnahmen umzusetzen, um kurzfristig das sich aus der Schwachstelle ergebende Gesamtrisiko für die IT- und Informationssicherheit eines jeweiligen Unternehmens zu senken. Klar war, dass die Bedrohung nicht mit einem Federstrich zu beseitigen sein wird. In der Unterstützung unserer Kunden wurde der Fokus auf entscheidende kurzfristige Maßnahmen gelegt:

  • die log4j Schwachstelle innerhalb der IT-Infrastruktur- und Applikationslandschaft identifizieren
  • betroffene Systeme/Applikationen umgehend patchen
  • in Systemen/Applikationen, die nicht kurzfristig gepatcht werden können, log4j durch das Setzen entsprechender Variablen deaktivieren
  • manuell entsprechende Logdaten auf ausgewählten Systemen prüfen
  • mit IOC / YARA Scannern exponierte Systeme scannen
  • Überprüfung und Anpassung von Firewall-Konfigurationen

Nach Durchführung der obigen Maßnahmen lässt sich behaupten, das Bedrohungsniveau deutlich gesenkt zu haben. ABER, eine Kompromittierung kann dadurch nicht ausgeschlossen werden. Auch wenn die Schwachstelle erfolgreich beseitigt wurde und keine Anzeichen einer Kompromittierung bestehen, wäre es ein Irrtum daraus zu schlussfolgern, dass kein Risiko besteht. Eine solche Schlussfolgerung könnte durchaus zu dem in der IT-Sicherheit so gefürchteten “false negative” führen. Mit anderen Worten: Risikoampel auf grün, obwohl sich doch irgendwo ein unentdecktes Risiko verbirgt.

Schwachstelle geschlossen – alles gut?

Um im Vorhinein Mißverständnisse auszuschließen: Das zügige Beheben von bekannten Schwachstellen ist grundsätzlich eine gute Idee, immer! Durch das vorzeitige Beseitigen einer Schwachstelle wird die potentielle Angriffsfläche reduziert und die Wahrscheinlichkeit eines erfolgreichen gezielten oder zufälligen Angriffs maßgeblich gesenkt. Jedoch ist diese Aussage mit einem großen ABER einzuordnen. Tatsache ist, dass oftmals sehr lange Zeiträume zwischen der ursächlichen Kompromittierung eines Systems und dem schlussendlich sichtbaren Angriff vergehen. Mit anderen Worten: Zwischen dem Zeitpunkt zu dem ein System initial mit einer unauffälligen Schadsoftwarekomponente kompromittiert wird und dem Zeitpunkt zu dem dieses System beispielsweise durch Ransomware in Beschlag genommen wird, können häufig viele Monate oder sogar Jahre vergehen.

Hier liefert der IBM Data Breach Report jedes Jahr eindrucksvolle Zahlen: Im aktuellen Bericht (2021) beziffert IBM die Dauer zwischen der initialen Kompromittierung und der Erkennung eines erfolgreichen, zu Datenabfluss führenden Angriffs, auf 212 Tage – im Durchschnitt!

Unterm Strich bedeutet das: Trotz aller Bemühungen, eine Schwachstelle frühzeitig zu schließen, ist es durchaus möglich und grundsätzlich nicht auszuschließen, dass eine Kompromittierung schon vorher stattgefunden hat und Symptome erst viel später sichtbar werden. So auch im Falle der log4j-Schwachstelle. Also was tun?

Das Ziel muss sein, das sich verändernde Verhalten eines Systems bzw. der IT-Infrastruktur insgesamt zu erkennen. In einem Szenario in dem ein System schon kompromittiert worden ist, muss es beispielsweise möglich sein zu erkennen, dass ein Host plötzlich versucht öffentliche IP-Adressen mit fragwürdiger Reputation zu kontaktieren (um Schadsoftwarekomponenten nachzuladen) oder dass Prozesse gestartet werden, die in dieser Form oder in dieser Kombination noch nie gestartet worden sind. Eine entsprechende Anomalieerkennungslösung kann zwar die mittels einer (alten) Schwachstelle erfolgte Kompromittierung eines Systems nicht mehr verhindern, aber sie kann die frühzeitige Erkennung eines lokalen Angriffs ermöglichen, um einen breitflächigen Ausfall der IT-Infrastruktur zu verhindern.

Log4j: Das BSI empfiehlt Anomalieerkennung

Im aktuellen “Arbeitspapier Detektion und Reaktion” des BSI zur kritischen Schwachstelle in log4j, empfiehlt das BSI explizit den Einsatz einer Anomalieerkennung auf Netzwerkebene. Das BSI beschreibt diese Detektionsmaßnahme als “nicht trivial einzurichten”. Gleichzeitig erläutert das BSI aber auch weshalb einfachere Detektionsmethoden unter Umständen unzureichend sind:

  • Einfache Anfragenauswertung mit Regelwerken -> erkennt nur Angriffe auf in den Server-Logs erfasste Teile der Anfrage
  • Detaillierte Anfragenuntersuchung mit Regelwerken -> möglicherweise unentdeckte Anfragen durch Umgehung des Regelwerks
  • Einfache Prozesslistensuche oder Ressourcenverbrauchsanalyse -> nur in trivialen, positiven Fällen der Kompromittierung konklusiv

Wichtig ist in diesem Zusammenhang auch, dass es hier nicht nur um extern erreichbare, exponierte Systeme geht, sondern auch um interne Systeme, die aufgrund der Verwendung eines anderen Angriffsvektors bzw. einer anderen Schwachstelle im Zugriff des Angreifers sind. Hierzu schreibt das BSI:

“Sowohl nach außen (ins Internet) exponierte IT-Systeme als auch interne Systeme, welche keine Verbindungen ins Internet aufweisen, können durch die veröffentlichten Schwachstellen angegriffen werden. Eine Möglichkeit zur Infektion von nicht aus dem Internet erreichbaren Systemen bietet die grundsätzliche Wurmfähigkeit der Schwachstelle. Angreifende mit Zugriffen auf interne Systeme können die Schwachstellen bspw. für die Bewegung im internen Netzwerk nutzen (eng. „Lateral Movement“).”

Die große Stärke einer Anomalieerkennungslösung besteht darin, dass sie die gesamte IT-Infrastruktur in ihrem Verhalten im Blick hat und nicht nur einzelne exponierte Systeme. Wenn also beispielsweise ein System, das nur intern erreichbar ist, bei der initialen Beseitigung einer Schwachstelle nicht gleich berücksichtigt und in dieser Phase kompromittiert wurde, wird es früher oder später aufgrund von Verhaltensauffälligkeiten durch eine entsprechende Anomalieerkennung detektiert werden.

Das BSI empfiehlt Anomalieerkennung – aber muss man diese selbst betreiben?

Ja, das BSI empfiehlt Anomalieerkennung auf Netzwerkebene. Und ja, das BSI weist darauf hin, dass eine solche in ihrer Einrichtung nicht trivial ist. Aber, es ist nicht notwendig diese selbst zu programmieren oder zu konfigurieren. Es ist auch nicht notwendig diese selbst zu betreiben.

Hierfür gibt es Lösungen und Dienstleistungskonzepte ohne Ihre bestehende IT-Mannschaft zu überfrachten. Mit Trovent Managed Detection & Response nehmen wir Ihnen die Sorgen ab. Wir liefern Detektion und Reaktion: Eine Angriffserkennung, die flexibel auf die Gegebenheiten Ihrer bestehenden IT-Infrastruktur angepasst werden kann sowie die auf die Erkennung folgenden Reaktionsprozesse.

Wir kümmern uns um:

  • die fortlaufende Anpassung von Erkennungsregeln und -algorithmen
  • die Bewertung von potentiell sicherheitsrelevanten Meldungen
  • den Ausschluss von “False Positives” (Falschmeldungen)
  • die Detailanalyse von komplexen Vorfällen
  • konkrete Handlungsempfehlungen für die Eindämmung des Schadenrisikos

Nach der Schwachstelle ist vor der Schwachstelle

Was lässt sich aus der log4j-Situation als Zwischenfazit ziehen?

Sicher ist, log4j hat IT-Abteilungen und Softwarehersteller bislang sehr beschäftigt. Und die Aufräumarbeiten sind lange noch nicht vorbei. Gleichzeitig dürfen wir uns nichts vormachen, getreu dem Motto: Nach der Schwachstelle ist vor der Schwachstelle.

Wir werden uns immer wieder mit neuen Schwachstellen beschäftigen müssen. Dabei ist sicher, dass auch sehr kritische Schwachstellen wie log4j mit von der Partie sein werden. Sicherlich können sich viele noch sehr gut an die Citrix-Schwachstelle zum Jahreswechsel 2019/20 erinnern. Und manch einer wird diesen damit in Verbindung stehenden Vorfall sicher nicht so schnell vergessen.

Aber, kein Unternehmen ist diesen Risiken hilflos ausgeliefert! Es gibt Lösungen.

Kostenfreie Beratung

Sie ziehen den Einsatz einer Anomalieerkennungslösung in Betracht? Gerne bieten wir Ihnen einen ersten kostenfreien Beratungstermin an. Einen Termin können Sie kurzerhand über unser Kontaktformular einrichten. Wir stellen Ihnen in der Folge auch gerne die Leistungsfähigkeit unserer EAGLE-Plattform in Ihrer Infrastruktur unter Beweis!