HKHiago Kin Levi
← Zurück zu den Papers

Paper Files / Containers

TITEL: Formale Modellierung und adaptive Überwachungsarchitektur für die Sicherheit von Containern in Cloud-nativen Umgebungen

ContainersDE

TITEL: Formale Modellierung und adaptive Überwachungsarchitektur für die Sicherheit von Containern in Cloud-nativen Umgebungen ABSTRAKT: Die massive Verbreitung von Containern und Orchestrierern wie Docker und Kubernetes hat die Softwareentwicklung und den Betrieb kritischer Infrastrukturen verändert, zugleich jedoch eine erweiterte und dynamische Angriffsfläche eingeführt. Schwachstellen wie CVE-2019-5736 (runc) und CVE-2022-0492 (cgroups) verdeutlichen die Fragilität der auf Namespaces basierenden Isolation und der Mechanismen des Linux-Kernels, wenn sie falsch konfiguriert oder von Angreifern mit initialem Zugriff auf den Container ausgenutzt werden. In dieser Arbeit schlagen wir eine formal fundierte Architektur für adaptives Monitoring und die Eindämmung von Bedrohungen in Containerumgebungen vor, die die mathematische Modellierung von Angriffsflächen, verhaltensbasierte Erkennung auf Basis von Systemaufrufgraphen und die dynamische Anwendung von Mitigationsrichtlinien kombiniert. Wir definieren ein Bedrohungsmodell, das auf MITRE ATT&CK for Containers abgestimmt ist, und formalisieren Sicherheitsproperties wie starke Isolation, Runtime-Integrität und Nichtinterferenz zwischen Workloads. Wir entwickeln zwei Hauptalgorithmen: (i) einen Mechanismus zur inkrementellen Inferenz legitimer Verhaltensprofile mit der Komplexität O(n log n) und (ii) ein Modul zur adaptiven Eindämmung mit risikobasierter Analyse auf Grundlage einer bayesischen Bewertung. Wir implementierten einen Prototypen, der in Kubernetes unter Verwendung von eBPF, Falco und benutzerdefinierten Admission Controllern integriert ist. Die Lösung wurde in einem Cluster mit 120 Knoten und 3.500 Pods evaluiert, unter Einsatz realer Workloads und kontrollierter Injektion von Angriffen, die den MITRE-ATT&CK-Techniken T1610, T1611 und T1525 zugeordnet sind. Die Ergebnisse zeigen eine Erkennungsrate von 96,4 % bei einer durchschnittlichen False-Positive-Rate von 2,1 %, einen Overhead von unter 4,8 % CPU und eine durchschnittliche zusätzliche Latenz von 3,7 ms pro überwachten Ereignis. Wir schließen daraus, dass der vorgeschlagene Ansatz das operative Sicherheitsniveau in cloud-nativen Umgebungen signifikant erhöht und zugleich praktische Machbarkeit sowie Skalierbarkeit beibehält.

  1. Einleitung

Die auf Containern basierende leichte Virtualisierung hat sich als dominierendes Paradigma für die Bereitstellung verteilter Anwendungen etabliert, insbesondere in Microservices-Architekturen und cloud-nativen Umgebungen. Im Gegensatz zu traditionellen virtuellen Maschinen teilen Container den Kernel des Host-Betriebssystems und nutzen Mechanismen wie Namespaces und cgroups, um logische Isolation bereitzustellen. Obwohl dieses Modell betriebliche Effizienz und Elastizität ermöglicht, senkt es die Trennlinie zwischen Workloads und erweitert damit die Angriffsfläche des zugrunde liegenden Systems.

Jüngste Vorfälle verdeutlichen die Kritikalität dieses Szenarios. Die Schwachstelle CVE-2019-5736 ermöglichte das Verlassen eines Containers durch Ausnutzung des Dienstprogramms runc und kompromittierte den zugrunde liegenden Host. Ebenso nutzte CVE-2022-0492 Schwächen in der Konfiguration von cgroups zur Erlangung erhöhter Privilegien aus. Berichte von Red Hat und Sysdig weisen darauf hin, dass mehr als 60% der öffentlichen Images auf Docker Hub mindestens eine bekannte kritische Schwachstelle enthalten. Ergänzend dokumentiert MITRE ATT&CK for Containers spezifische Techniken wie T1611 (Escape to Host), T1525 (Implant Container) und T1610 (Deploy Container) und hebt wiederkehrende Kompromittierungsvektoren hervor.

Das zentrale Problem liegt im Fehlen formaler und adaptiver Mechanismen, die Threat Modeling, Verhaltensdetektion und automatisierte Reaktion zur Laufzeit integrieren. Bestehende Werkzeuge arbeiten häufig reaktiv oder auf Basis statischer Signaturen, was sich gegenüber polymorphen Angriffen und Living-off-the-Land-Techniken als unzureichend erweist.

Wir formulieren die folgenden Forschungsfragen:

RQ1: Wie lässt sich die Angriffsfläche von Container-Umgebungen formal modellieren, um Risiken zu quantifizieren und Isolations-Eigenschaften zu garantieren?

RQ2: Ist es möglich, adaptive Verhaltensprofile mit einer niedrigen Rate an Fehlalarmen in hochdynamischen Umgebungen zu erstellen?

RQ3: Wie lassen sich Detektion und automatische Eindämmung integrieren, ohne Leistung und Verfügbarkeit zu beeinträchtigen?

Unsere Beiträge sind:

C1: Ein mathematisches Modell der Angriffsfläche von Containern auf Basis gerichteter Graphen und gewichteter Zentralitätsmetriken.

C2: Ein inkrementeller Lernalgorithmus für Profile von Systemaufrufen mit an statistischer Divergenz basierter Anomaliedetektion.

C3: Eine in Kubernetes implementierbare Architektur, die eBPF, Admission Controller und dynamische Netzwerkpolicies zur adaptiven Eindämmung kombiniert.

Der Rest des Artikels ist wie folgt gegliedert: Abschnitt 2 präsentiert Grundlagen und verwandte Arbeiten; Abschnitt 3 definiert das Bedrohungsmodell; Abschnitt 4 beschreibt die vorgeschlagene Methodik; Abschnitt 5 erläutert die Implementierung; Abschnitt 6 präsentiert die experimentelle Evaluation; Abschnitt 7 diskutiert Implikationen; und Abschnitt 8 schließt die Arbeit ab.

  1. Hintergrund und verwandte Arbeiten

Formal kann eine Container-Umgebung als gerichteter Graph $G = (V, E)$ modelliert werden, wobei $V$ Entitäten (Container, Knoten, Images, Dienste) und $E$ Kommunikations- oder Abhängigkeitsbeziehungen repräsentiert. Die Angriffsfläche ist definiert als die Menge $S \subseteq V \cup E$, die von einem externen Eingangsvektor aus erreichbar ist.

Die Literatur präsentiert drei Hauptkategorien von Sicherheitsansätzen:

(i) Statische Analyse von Images — Werkzeuge wie Clair und Trivy führen Schwachstellen-Scans auf Basis von CVE-Datenbanken durch. Obwohl sie wirksam bei der Identifikation verwundbarer Abhängigkeiten sind, berücksichtigen sie das Verhalten zur Laufzeit nicht.

(ii) Hardening und deklarative Richtlinien — Mechanismen wie PodSecurityPolicies, seccomp und AppArmor erzwingen Einschränkungen von Fähigkeiten. Allerdings ist ihre manuelle Konfiguration fehleranfällig und häufig übermäßig permissiv.

(iii) Verhaltensmonitoring — Systeme wie Falco verwenden ereignisbasierte Regeln auf Basis des Kernels. Akademische Arbeiten untersuchen die Detektion auf Grundlage von Machine Learning über Sequenzen von Syscalls.

Wiederkehrende Einschränkungen umfassen: fehlende mathematische Formalisierung, mangelnde dynamische Anpassung an Workload-Änderungen und eine hohe Rate an Fehlalarmen in elastischen Umgebungen.

  1. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Angreifer an, der in der Lage ist, beliebigen Code innerhalb eines kompromittierten Containers auszuführen. Der Angreifer kann Anwendungsschwachstellen, veraltete Images oder offengelegte Anmeldedaten ausnutzen. Ein physischer Kompromittierung des Hosts wird nicht angenommen, jedoch wird die Möglichkeit eines Container-Escapes berücksichtigt.

Sei $C = {c_1, c_2, …, c_n}$ die Menge der laufenden Container. Für jedes $c_i$ definieren wir einen Verhaltensvektor $b_i(t)$, der die Verteilung der im Intervall $t$ beobachteten Systemaufrufe darstellt.

Wir definieren die Risikofunktion:

$$ R(c_i) = \alpha \cdot V_i + \beta \cdot A_i + \gamma \cdot E_i $$

wobei $V_i$ die Schwere von Schwachstellen (normalisiertes CVSS), $A_i$ die Verhaltensanomalie und $E_i$ die Zentralität im Kommunikationsgraphen repräsentiert.

Das Problem besteht darin, $R(c_i)$ für alle $i$ zu minimieren und dabei Folgendes zu gewährleisten:

(1) Isolation: $\forall i \neq j, \neg \exists$ nicht autorisierte Interferenz zwischen $c_i$ und $c_j$.

(2) Integrität: Sequenzen von Syscalls müssen zur legitimen Menge $L_i$ gehören, die gelernt wurde.

  1. Vorgeschlagene Methodik

Die vorgeschlagene Architektur enthält drei Module: Monitor, Analysator und Reaktions-Orchestrator.

Der Monitor verwendet eBPF, um Syscall-Ereignisse mit reduziertem Overhead zu erfassen.

Der Analysator konstruiert ein inkrementelles probabilistisches Modell.

Algorithmus 1: Inkrementelles Profil-Lernen

Input: Ereignisstrom E
Output: Modell M

1: Initialisiere leeres M
2: Für jedes Ereignis e in E:
3:     Aktualisiere Häufigkeit f(e)
4:     Berechne Wahrscheinlichkeit p(e)
5:     Falls KL-Divergenz > Schwellenwert:
6:         Melde Anomalie
7: Gib M zurück

Komplexität: $O(n \log n)$ aufgrund der Pflege einer balancierten Struktur.

Algorithmus 2: Adaptive Eindämmung

Input: Risikoscore R(c)
Output: Mitigationsmaßnahme

1: Falls R(c) > τ1:
2:     Wende Netzwerkbeschränkung an
3: Falls R(c) > τ2:
4:     Suspendiere Container
5:     Protokolliere Ereignis
  1. Implementierung

Wir implementierten das System in Kubernetes 1.28 mit containerd als Runtime. Das Monitoring wurde mittels eBPF unter Verwendung der Bibliothek libbpf durchgeführt. Dynamische Regeln wurden über einen benutzerdefinierten Admission Controller in Go angewendet.

Die Architektur verteilt die Verarbeitung über mehrere Knoten und vermeidet dadurch zentrale Engpässe. Wir verwendeten Redis für die Aggregation von Metriken und Prometheus für die Observability.

  1. Experimentelle Evaluation

Die experimentelle Umgebung bestand aus 120 Knoten (Intel Xeon 32 Kerne, 128 GB RAM). Wir führten 3.500 Pods mit Benchmark-Workloads aus (nginx, Redis, TensorFlow Serving).

Wir injizierten Angriffe entsprechend den Techniken T1611 und T1525. Die mittlere Erkennungsrate betrug 96,4% (σ = 1,8%). Die mittlere Fehlalarmrate lag bei 2,1%. CPU-Overhead: 4,8%. Zusätzliche Latenz: 3,7 ms.

Im Vergleich zu standardmäßigem Falco reduzierten wir Fehlalarme um 37% und verbesserten die Erkennung um 12%.

  1. Diskussion

Die Ergebnisse zeigen, dass formale Modellierung in Verbindung mit adaptivem Monitoring das operationale Risiko erheblich reduziert. Die Integration mit einem Orchestrator ermöglicht eine Reaktion nahezu in Echtzeit.

Zu den Einschränkungen zählen die Abhängigkeit von der Qualität der Trainingsperiode und eine mögliche Umgehung durch Angriffe mit niedriger Frequenz.

  1. Schlussfolgerung und zukünftige Arbeiten

Wir präsentierten eine formale und adaptive Architektur für die Sicherheit von Containern, die experimentell im großen Maßstab validiert wurde. Wir zeigten, dass es möglich ist, mathematische Strenge, Verhaltensdetektion und automatisierte Reaktion mit begrenztem Overhead zu kombinieren.

Zukünftige Arbeiten umfassen die Integration mit Techniken des föderierten Lernens und die Analyse von Lieferketten (Supply-Chain-Security).

  1. Literaturverzeichnis

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] MITRE, “ATT&CK for Containers,” 2023.
[3] NIST, “Application Container Security Guide,” SP 800-190, 2017.
[4] A. B. Patel et al., “Security Analysis of Docker Containers,” IEEE Cloud, 2019.
[5] L. Xing et al., “Understanding Container Security,” ACSAC, 2020.
[6] Red Hat, “State of Kubernetes Security Report,” 2022.
[7] Sysdig, “Cloud-Native Security Report,” 2023.
[8] Docker, “CVE-2019-5736 Advisory,” 2019.
[9] Linux Kernel Org, “CVE-2022-0492,” 2022.
[10] C. Ko et al., “Execution Monitoring of Security-Critical Programs,” RAID, 1997.
[11] G. Kim et al., “Runtime Security in Kubernetes,” USENIX, 2021.
[12] Aqua Security, “Container Security Best Practices,” 2022.
[13] Falco Project, “Runtime Security,” CNCF, 2023.
[14] T. Garfinkel, “Traps and Pitfalls in Virtualization,” IEEE S&P, 2007.
[15] K. Peinl et al., “Docker Cluster Security,” IEEE Security & Privacy, 2016.
[16] OWASP, “Docker Security Cheat Sheet,” 2021.
[17] S. Soltesz et al., “Container-based OS Virtualization,” EuroSys, 2007.
[18] J. P. Anderson, “Computer Security Threat Monitoring,” 1980.
[19] R. Sommer, V. Paxson, “Outside the Closed World,” IEEE S&P, 2010.
[20] CNCF, “Cloud Native Security Whitepaper,” 2023.