Runtime-Security-Tools systematisch bewerten

Das richtige Runtime-Security-Tool zu wählen, entscheidet darüber, wie gut sich moderne cloud-native Umgebungen schützen lassen. Wir haben dafür ein gründliches Bewertungsverfahren durchlaufen, mit echten Angriffssimulationen auf unseren Kubernetes-Clustern und Linux-Servern. Der Grund: Herkömmliche Cloud-Audit-Logs liefern zu wenig Detail und lassen dadurch Lücken bei Bedrohungserkennung, Incident Response und Forensik. Unsere Bewertung hat jede kritische Phase im Einzelnen untersucht, vom ersten Zugriff über die laterale Bewegung bis zur Datenexfiltration.

Den Anbieter nennen wir in diesem Beitrag nicht. Wir teilen aber unser Vorgehen im Detail und die wichtigsten Erkenntnisse daraus, als Vorlage, die sich für eigene Werkzeugbewertungen anpassen lässt.

Warum sind Runtime-Security-Tools nötig?

Ohne Runtime-Security-Tools wird es ausgesprochen schwierig, "verdächtige Aktivitäten" zu erkennen und nachzuvollziehen, "was tatsächlich geschehen ist".

Grenzen von Cloud-Audit-Logs

• Fehlende Laufzeitdetails Cloud-Audit-Logs erfassen vor allem Operationen und Datenzugriffe innerhalb der Cloud. Was zur Laufzeit auf Systemen wie Kubernetes-Servern geschieht, halten sie nicht fest: feingranulare Befehlsausführungen, Prozessverhalten und kurzlebige Netzwerkaktivitäten bleiben außen vor.
• Lücken bei Untersuchung und Forensik In Kubernetes-Umgebungen können ohne durchgehende Protokollierung in Echtzeit entscheidende Aufzeichnungen verloren gehen, sobald ein Container endet.

Es gibt bekannte quelloffene Runtime-Security-Tools. Wir haben uns dennoch für die Bewertung eines kommerziellen Produkts entschieden, um zusätzliche Fähigkeiten und Enterprise-Support anhand von Angriffssimulationen zu prüfen.

Aufgabe und Zweck von Runtime-Security-Tools

Runtime-Security-Tools schließen diese Lücken, indem sie Systeme fortlaufend in Echtzeit überwachen. Sie leisten dabei Folgendes:

• Bedrohungserkennung Sie beobachten Befehlsausführungen, Systemaufrufe und Netzwerkereignisse in Echtzeit und erkennen ungewöhnliches Verhalten unmittelbar, sodass das Sicherheitsteam zügig reagieren kann. Manche Public-Cloud-Anbieter bieten inzwischen eine eingeschränkte Laufzeitüberwachung an, doch diesen nativen Lösungen fehlt in der Regel die Tiefe und Breite spezialisierter Sicherheitswerkzeuge.
• Incident Response Durch lückenlose chronologische Aufzeichnungen der Systemaktivitäten liefern diese Werkzeuge dem Sicherheitsteam die Belege, um den zeitlichen Ablauf eines Angriffs zu rekonstruieren, das volle Ausmaß der Kompromittierung zu bestimmen und nach einem Vorfall gründliche forensische Untersuchungen durchzuführen.
• Skalierbarkeit der Untersuchung Anders als bei forensischer Analyse Endpunkt für Endpunkt lassen sich Daten zentral über die gesamte Umgebung hinweg sammeln, speichern und auswerten. Vorfälle lassen sich dadurch untersuchen, ohne verstreute Datenquellen von Hand zusammenzuführen.

Hinweis: Runtime-Security-Tools bringen mitunter auch Schwachstellenverwaltung für Container und Server mit. Diese Funktionen sind hier nicht Gegenstand der Betrachtung.

Bedrohungserkennung nützt nur, wenn Alerts die richtigen Personen erreichen und dort auch bearbeitet werden. Wie das Sicherheitsteam von GitLab dafür einen Self-Service-Workflow für die Alert-Bearbeitung aufgebaut hat, steht in einem eigenen Beitrag (englisch).

Worauf es bei der Bewertung ankam

Unser Hauptziel war herauszufinden, wie wirksam ein Runtime-Security-Tool in echten Sicherheitsuntersuchungen ist. Bewertungen richten sich oft auf die Menge der Erkennungen oder die Abdeckung insgesamt. Im Betrieb aber kann eine Flut von False Positives ein Incident-Response-Team lahmlegen. Dasselbe gilt für Dutzende Alerts, die alle zur selben Angriffskette gehören. Unsere Untersuchung zielte deshalb darauf, ob sich mit dem Werkzeug tatsächliche Angriffe verstehen und bearbeiten lassen.

• Erkennungsfähigkeit
  • Eingebaute Regeln Wir haben geprüft, ob die mitgelieferten Regelsätze verschiedene Angriffstechniken zuverlässig erkennen und dabei genug Detail für eine belastbare Einordnung liefern.
  • Eigene Erkennungsregeln Wir haben bewertet, wie leicht sich zusätzliche Regeln einbinden lassen, und dabei die Qualität der Telemetriedaten betrachtet, mit denen sich eigene Überwachungslösungen bauen lassen, zugeschnitten auf unsere Kenntnis der eigenen Umgebung.
  • Alert-Qualität Ebenso haben wir die Rate der False Positives überprüft und bestätigt, dass das Werkzeug sich auf echte, handlungsbedürftige Bedrohungen konzentriert und Rauschen vermeidet, das zu Alert-Müdigkeit führt.
• Incident Response
  • Aussagekraft der Logs Wir haben bewertet, ob die Logs genug Detail festhalten, um einen Vorfall vollständig zu rekonstruieren: ausgeführte Befehle, Netzwerkverbindungen, DNS-Abfragen und Prozessinformationen. Den gesamten Angriffsverlauf zusammensetzen und die volle Wirkung bestimmen zu können, ist in der Incident Response entscheidend.
  • Durchsuchbarkeit der Logs Wir haben geprüft, wie gut sich Ereignisse über mehrere Systeme hinweg suchen, filtern und zueinander in Beziehung setzen lassen. Große Datenmengen zügig abfragen zu können, ist bei Sicherheitsvorfällen unverzichtbar.

Der Ablauf der Bewertung

Wir haben die Bewertung in vier Phasen gegliedert:

1. Angriffsszenarien entwickeln Wir haben Szenarien entworfen, die realen Angriffsabläufen nachempfunden sind. Gemeinsam mit unserem Red Team entstanden daraus:
   • Angriffe über GitLab-spezifische Schwachstellen (etwa CVE-2021-22205)
   • Angriffe über kompromittierte Entwicklungsrechner
   • detaillierte Schritt-für-Schritt-Abläufe
2. Infrastruktur aufsetzen Wir haben zwei parallele Umgebungen bereitgestellt:
   • eine Kubernetes-Umgebung
   • eine Umgebung mit virtuellen Maschinen
   
   Für die Prüfung bekannter Schwachstellen kam eine ältere GitLab-Version zum Einsatz, und beide Umgebungen durchliefen vergleichbare Abläufe.
3. Angriffe ausführen Wir haben den Angriffsablauf jedes Szenarios durchgeführt und den zeitlichen Verlauf genau festgehalten, vom ersten Zugriff über die laterale Bewegung bis zur Datenexfiltration.
4. Ergebnisse auswerten Wir haben Erkennungsfähigkeit, Aussagekraft der Logs und Verbesserungsbedarf umfassend bewertet und Stärken wie Schwächen der Werkzeuge klar benannt.

Die Angriffsszenarien

Szenario 1: Ausnutzen einer bekannten GitLab-Schwachstelle

• Angriffsablauf
  1. Erster Zugriff Wir haben CVE-2021-22205 ausgenutzt, eine bekannte GitLab-Schwachstelle, die Remote Code Execution erlaubt. Damit hatten wir unberechtigten Zugriff auf das Zielsystem.
  2. Befehlsausführung Nach dem Zugriff haben wir eine Reverse Shell gestartet, um die kompromittierte Maschine aus der Ferne zu steuern.
  3. C2-Agent einrichten Wir haben einen Command-and-Control-Agenten (C2) installiert, um Persistenztechniken zu bewerten und weitere Befehle aus der Ferne auszuführen.
  4. Laterale Bewegung Anschließend haben wir uns innerhalb der Umgebung weiterbewegt und auf Secrets der Kubernetes-API sowie auf PostgreSQL-Datenbanken zugegriffen.
  5. Datenexfiltration Sensible Daten haben wir über einen eigenen C2-Kanal abgezogen.

Die folgende Tabelle fasst die Techniken je Phase zusammen:

Szenario 2: Kompromittierter Entwicklungsrechner

• Angriffsablauf
  1. Erste Kompromittierung Wir haben nachgestellt, wie ein Angreifer einen Entwicklungsrechner übernimmt und legitime Zugangsdaten missbraucht, um unberechtigt an interne Ressourcen zu gelangen.
  2. Rechteausweitung Mit den erbeuteten Zugangsdaten haben wir unsere Rechte in der Kubernetes-Umgebung ausgeweitet.
  3. Container manipulieren Wir haben einen privilegierten Container ausgerollt, um an sensible Informationen zu kommen.
  4. Exfiltration und Persistenz Wir haben sensible Daten abgezogen und uns dauerhaften Zugriff erhalten.
     Die folgende Tabelle fasst die Techniken je Phase zusammen:

Die Ausführung der Angriffe

Während der Szenarien haben wir nach folgendem Vorgehen detaillierte Aufzeichnungen gewonnen:

• Erkennungen überprüfen: Wir haben festgestellt, ob jeder Angriffsbefehl erkannt und ob die entscheidenden Punkte jedes Szenarios ordentlich gemeldet wurden.
• Zeitverlauf festhalten: Jedes Ereignis wurde der Reihe nach protokolliert, um zu bewerten, wie gut Befehlsausführungen und Netzwerkkommunikation erfasst werden.
• Bewerten und auswerten: Jedes Ereignis wurde nach Erkennungsgüte bewertet, um die Leistung des Werkzeugs zahlenmäßig einzuordnen.

Was wir gelernt haben

Kommerzielle Produkte selbst prüfen

• Erkennungslücken finden und angehen (Zusammenarbeit mit dem Anbieter) Unsere Bewertung hat gezeigt, dass mehrere kritische Szenarien und Ereignisse nicht erkannt oder nicht protokolliert wurden. Daraufhin haben wir mit dem Anbieter gesprochen und mehrere Verbesserungswünsche eingereicht. Der Anbieter hat das Produkt anschließend erweitert und die Erkennung verbessert, und viele der von uns gefundenen Punkte sind inzwischen behoben.
• Grenzen verstehen Viele moderne Runtime-Security-Tools setzen auf eBPF, um Linux-Systemaufrufe zur Erkennung zu beobachten. Weil Befehle innerhalb eines C2-Frameworks jedoch keine neuen Prozesse erzeugen, war es schwierig, diese Angriffsereignisse nachzuverfolgen.
• Reichweite der Werkzeuge einordnen Unsere Ergebnisse zeigen, dass es in der Incident Response nicht genügt, sich allein auf Runtime-Security-Tools zu stützen. Erst zusammen mit anderen Logs, etwa Kubernetes-Audit-Logs und Cloud-Logs, entsteht ein vollständiges Bild.

Warum durchgehende Laufzeitprotokollierung in Kubernetes zählt

In Kubernetes-Umgebungen droht der Verlust forensischer Daten, sobald Container enden. Durchgehende Protokollierung ist deshalb unverzichtbar. Unsere Bewertung hat bestätigt, dass eine skalierbare, dauerhafte Protokollinfrastruktur entscheidend ist. Ohne geeignete Runtime-Security-Tools kann nach einem Angriff eine erhebliche Menge wichtiger Informationen verloren sein.

Fazit

Wir installieren Sicherheitswerkzeuge nicht blind, sondern prüfen ihren Nutzen, damit unsere Kundschaft GitLab.com sicher nutzen kann. Gründliche Produktbewertungen wie die beschriebene bringen nicht nur Anwendungsfälle und Verbesserungsbedarf zutage, die Anbietern entgehen können. Sie liefern zugleich Erkenntnisse, von denen der Anbieter ebenso profitiert wie die eigenen Teams, wenn es darum geht, den Einsatz des Werkzeugs sinnvoll aufzusetzen.