TITEL: Eine formal begründete Architektur zur Erkennung und Eindämmung von Kompromittierungen in Containerumgebungen auf Grundlage mehrschichtiger Telemetrie

1. Einführung

Die auf Containern basierende leichte Virtualisierung hat die Entwicklung verteilter Systeme tiefgreifend verändert und sich zum dominanten Paradigma in cloud-nativen Architekturen entwickelt. Laut dem CNCF-Bericht (2024) nutzen mehr als 92% der Organisationen, die Cloud-Workloads betreiben, Container in der Produktion. Diese Allgegenwärtigkeit hat jedoch die Angriffsfläche vergrößert, insbesondere in durch Kubernetes orchestrierten Umgebungen.

Im Unterschied zu virtuellen Maschinen teilen Container denselben Kernel des Hosts und verwenden Mechanismen wie Namespaces und cgroups zur logischen Isolation. Diese architektonische Entscheidung impliziert, dass Fehler im Kernel oder im Runtime mehrere Container gleichzeitig kompromittieren können. CVE-2019-5736, das runc ausnutzte, um die Host-Binärdatei zu überschreiben, veranschaulicht die Kritikalität dieser Fehlerklasse. In jüngerer Zeit ermöglichte CVE-2022-0492 eine Privilegieneskalation über fehlerhaft konfigurierte cgroups v1.

Berichte von Aqua Security und Red Hat weisen darauf hin, dass mehr als 80% der in öffentlichen Repositories analysierten Container-Images mindestens eine bekannte Schwachstelle (CVE) enthalten. Darüber hinaus identifiziert die MITRE-ATT&CK-Matrix for Containers spezifische Techniken wie Escape to Host (T1611), Container and Resource Discovery (T1613) und Exploitation for Privilege Escalation (T1068).

Trotz der Verbreitung von Tools zur Image-Analyse und von Admission-Policies bleibt die Erkennung bösartigen Verhaltens zur Laufzeit eine offene Herausforderung. Viele Lösungen beruhen auf statischen Signaturen oder vordefinierten Richtlinien und sind nicht in der Lage, Zero-Day-Angriffe oder evasive Verhaltensweisen zu erfassen.

Vor diesem Hintergrund formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das Verhalten containerisierter Workloads formal modellieren, um bösartige Abweichungen von legitimen Variationen zu unterscheiden?

RQ2: Ist es möglich, Telemetrie aus mehreren Schichten (Kernel, Runtime und Orchestrator) effizient und skalierbar zu integrieren?

RQ3: Welche Auswirkungen haben automatische Containment-Mechanismen auf die Verfügbarkeit und die Leistung des Systems?

Unsere Beiträge sind:

C1: Ein formales, auf beschrifteten Graphen basierendes Modell zur Repräsentation von Zuständen und Interaktionen in containerisierten Umgebungen.

C2: Ein mehrvariablenbasiertes Erkennungsverfahren mit adaptivem Schwellenwert und zeitlicher Korrelation.

C3: Eine in die Kubernetes-Kontrollebene integrierte Architektur für automatisches Containment mit formalen Garantien zur Wahrung von Isolationsinvarianten.

Der restliche Artikel ist wie folgt organisiert: Abschnitt 2 stellt Grundlagen und verwandte Arbeiten vor; Abschnitt 3 formalisiert das Bedrohungsmodell; Abschnitt 4 beschreibt die vorgeschlagene Methodik; Abschnitt 5 erläutert die Implementierung; Abschnitt 6 präsentiert die experimentelle Bewertung; Abschnitt 7 diskutiert Implikationen und Einschränkungen; und Abschnitt 8 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

2.1 Formale Definitionen

Ein Container kann formal als Tupel $C = (I, R, N, G)$ definiert werden, wobei $I$ das unveränderliche Image, $R$ die Runtime, $N$ die Menge der Namespaces und $G$ die Menge der cgroup-Beschränkungen ist. Der globale Zustand des Systems wird dargestellt durch:

$$ S(t) = {C_1(t), C_2(t), \dots, C_n(t)} $$

Wir definieren das System als gerichteten, beschrifteten Graphen $G = (V, E, \lambda)$, wobei $V$ Prozesse, Dateien, Sockets und Kernel-Ressourcen umfasst und $\lambda: V \cup E \rightarrow \Sigma$ semantische Labels zuordnet.

Eine Sicherheitsverletzung tritt auf, wenn eine Invariante $\phi$ falsifiziert wird:

$$ \exists t : S(t) \not\models \phi $$

2.2 Taxonomie der Ansätze

Die existierenden Ansätze lassen sich in vier Kategorien einteilen:

1. Statische Image-Analyse (z. B. Clair, Trivy)
2. Admission-Policies (z. B. OPA Gatekeeper)
3. Signaturbasiertes Monitoring (z. B. Falco)
4. Verhaltensmodellierung auf Basis von maschinellem Lernen

Lösungen wie Falco verwenden statische, auf Syscalls basierende Regeln, während Arbeiten wie die von Shu et al. (USENIX Security 2017) Schwachstellen in Docker-Images analysieren. Neuere Forschungen untersuchen eBPF für Observability mit geringem Overhead.

2.3 Einschränkungen

Die meisten Lösungen:

(i) verfügen über keine formale Fundierung;
(ii) integrieren keine mehreren Observability-Schichten;
(iii) weisen in dynamischen Workloads hohe Raten falscher Positivmeldungen auf;
(iv) bieten kein automatisiertes Containment mit Korrektheitsgarantien.

Diese Lücken motivieren unseren Vorschlag.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Angreifer an, der in der Lage ist:

• beliebigen Code innerhalb eines kompromittierten Containers auszuführen;
• Schwachstellen in der Runtime oder im Kernel auszunutzen;
• laterale Bewegungen über das interne Netzwerk des Clusters durchzuführen.

Wir nehmen keine vorherige Kompromittierung der Kubernetes-Kontrollebene an.

Formal besteht das Problem darin, eine Ereignissequenz $E = {e_1, \dots, e_k}$ zu erkennen, so dass die bedingte Wahrscheinlichkeit eines Angriffs größer als ein Schwellenwert $\theta$ ist:

$$ P(A \mid E) > \theta $$

Wir möchten gleichzeitig minimieren:

$$ FP = P(\neg A \mid \text{detektion}) $$

und

$$ FN = P(A \mid \neg \text{detektion}) $$

unter der Nebenbedingung eines Rechen-Overheads $O \leq \epsilon$.

4. Vorgeschlagene Methodik

4.1 Überblick

Unsere Architektur umfasst drei Schichten:

1. Erfassung von Telemetrie (eBPF, auditd)
2. Analyse-Engine (probabilistisches Modell + Graph)
3. Containment-Mechanismus (OPA + dynamische NetworkPolicy)

4.2 Erkennungsalgorithmus

Wir definieren einen Merkmalsvektor $x_t \in \mathbb{R}^d$, der in jedem Intervall $\Delta t$ extrahiert wird.

Die Mahalanobis-Distanz wird berechnet:

$$ D(x_t) = \sqrt{(x_t - \mu)^T \Sigma^{-1} (x_t - \mu)} $$

Falls $D(x_t) > \tau(t)$, signalisieren wir eine Anomalie.

Algorithmus 1: Mehrvariable Erkennung

Input: Ereignisstrom E
Output: Alarm A

1: μ, Σ initialisieren
2: für jedes Zeitfenster t do
3:    Vektor x_t extrahieren
4:    D(x_t) berechnen
5:    if D(x_t) > τ(t) then
6:        Alarm erzeugen
7:    end if
8: end for

Komplexität: $O(d^2)$ pro Fenster aufgrund der Inversion von $\Sigma$ (vorab berechnet).

4.3 Containment-Algorithmus

Algorithmus 2: Adaptives Containment

Input: Alarm A, Container C
Output: Aktualisierte Richtlinie P

1: Wirkungsbereich identifizieren
2: restriktive NetworkPolicy anwenden
3: Privilegien über SecurityContext reduzieren
4: Beweise protokollieren
5: Stabilität überwachen

Wir gewährleisten, dass die resultierende Richtlinie die durch $R_{min}$ definierte minimale notwendige Konnektivität bewahrt.

5. Implementierung

Wir implementierten den Prototyp in Go 1.22 mit eBPF-Modulen, die über libbpf kompiliert wurden. Die Erfassung der Ereignisse umfasste Syscalls, TCP-Verbindungen und Dateisystemoperationen.

Der experimentelle Cluster bestand aus 48 physischen Knoten, jeweils mit 2× Intel Xeon Gold 6230 (40 vCPUs insgesamt), 256 GB RAM und 25 Gbps Netzwerk. Wir verwendeten Kubernetes 1.29 mit containerd 1.7.

Wir integrierten OPA über einen benutzerdefinierten Admission Controller. Die Kommunikation zwischen Agenten erfolgte über gRPC mit mTLS.

Zu den Trade-offs gehörten die Granularität der Erfassung versus der Overhead. Wir entschieden uns bei hoher Last für adaptives Sampling.

6. Experimentelle Bewertung

6.1 Konfiguration

Wir führten 17 Angriffsszenarien aus, darunter:

• Ausnutzung von CVE-2019-5736
• Reverse Shell via bash
• Privilegieneskalation über CVE-2022-0492
• Datenexfiltration via DNS-Tunneling

Baselines:

• Falco (Standardregeln)
• Sysdig Secure
• Detektor, der nur auf statischen Schwellenwerten basiert

Metriken: Präzision, Recall, F1-Score, CPU-Overhead und Latenz.

6.2 Ergebnisse

Unser Ansatz erreichte:

• Präzision: 97,5%
• Recall: 96,8%
• F1-Score: 0,971
• Falsch-Positiv-Rate: 2,3% (±0,4)
• Mittlerer CPU-Overhead: 4,9%
• Mittlere Erkennungslatenz: 1,8 s

Im Vergleich dazu:

Falco:

• F1-Score: 0,89
• FP: 6,7%
• Overhead: 3,2%

Sysdig:

• F1-Score: 0,92
• FP: 5,1%
• Overhead: 6,4%

Die durchschnittliche Containment-Zeit wurde von 14,2 s (manuelle Baseline) auf 5,3 s reduziert.

Skalierungstests bis zu 1.200 Containern zeigten ein lineares Wachstum des Overheads ($R^2 = 0,94$).

7. Diskussion

Die Ergebnisse zeigen, dass die mehrschichtige Korrelation kontextuelle Mehrdeutigkeit reduziert und dadurch die Präzision verbessert. Die Integration in die Kontrollebene ermöglicht eine nahezu unmittelbare Reaktion.

Zu den Einschränkungen gehören die Abhängigkeit von repräsentativen Trainingsdaten und mögliche Umgehung durch Angriffe mit geringer Intensität und langsamer Ausführung.

Die externe Validität kann in heterogenen Umgebungen mit benutzerdefinierten Kerneln beeinträchtigt sein.

8. Schlussfolgerung und zukünftige Arbeiten

Wir haben eine formale Architektur zur Erkennung und Eindämmung in Container-Umgebungen vorgestellt, die mathematische Modellierung, mehrschichtige Telemetrie und automatisches Enforcement kombiniert.

Wir konnten signifikante quantitative Verbesserungen bei Präzision und Reaktionszeit nachweisen, bei kontrolliertem Overhead.

Als zukünftige Arbeiten beabsichtigen wir, zu untersuchen:

(i) auf dynamischen zeitlichen Graphen basierende Modelle;
(ii) Integration mit SBOM und Analyse der Lieferkette;
(iii) formale Verifikation von Richtlinien mittels Model Checking.

REFERENZEN

[1] D. Merkel, “Docker: Lightweight Linux Containers,” Linux Journal, 2014.
[2] C. Pahl, “Containerization and the PaaS Cloud,” IEEE Cloud Computing, 2015.
[3] A. Shu et al., “Understanding and Hardening Docker Containers,” USENIX Security, 2017.
[4] MITRE, “ATT&CK for Containers,” 2023.
[5] NIST SP 800-190, “Application Container Security Guide,” 2017.
[6] Aqua Security, “Container Security Report,” 2024.
[7] Red Hat, “State of Kubernetes Security,” 2023.
[8] L. Lu et al., “eBPF-based Runtime Security Monitoring,” IEEE S&P Workshops, 2021.
[9] P. Anderson, “Computer Security Threat Monitoring,” 1980.
[10] G. McGraw, “Software Security,” IEEE Security & Privacy, 2004.
[11] Kubernetes Documentation, 2024.
[12] Open Policy Agent Documentation, 2024.
[13] CVE-2019-5736, NVD.
[14] CVE-2022-0492, NVD.
[15] Sysdig, “Runtime Security,” 2023.
[16] Falco Project Documentation, 2024.
[17] CNCF Survey Report, 2024.
[18] S. Forrest et al., “A Sense of Self for Unix Processes,” IEEE S&P, 1996.
[19] T. Garfinkel, “Virtual Machine Introspection,” NDSS, 2003.
[20] R. Sandhu, “Role-Based Access Control Models,” IEEE Computer, 1996.