TITEL: Eine formal fundierte Architektur zur Erkennung und Eindämmung von Kompromittierungen in Container-Umgebungen auf Basis von mehrschichtiger Telemetrie

1. Einleitung

Die leichtgewichtige Virtualisierung auf Basis von Containern hat die Ingenieurwissenschaft verteilter Systeme tiefgreifend verändert und sich zum dominierenden Paradigma in cloud-nativen Architekturen entwickelt. Laut dem Bericht der CNCF (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 Gegensatz zu virtuellen Maschinen teilen Container denselben Kernel des Hosts und verwenden Mechanismen wie Namespaces und cgroups für logische Isolation. Diese architektonische Entscheidung impliziert, dass Fehler im Kernel oder im Runtime mehrere Container gleichzeitig kompromittieren können. Das CVE-2019-5736, das runc ausnutzte, um das Host-Binary zu überschreiben, illustriert die Kritikalität dieser Vulnerabilitätsklasse. In jüngerer Zeit ermöglichte CVE-2022-0492 eine Privilegieneskalation über fehlerhaft konfigurierte cgroups v1.

Berichte von Aqua Security und Red Hat zeigen, dass mehr als 80 % der in öffentlichen Repositorien analysierten Container-Images mindestens eine bekannte Schwachstelle (CVE) enthalten. Darüber hinaus identifiziert die MITRE-ATT&CK-Matrix für Container 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-Prüfung und von Admission-Policies bleibt die Erkennung bösartiger Verhaltensweisen zur Laufzeit eine offene Herausforderung. Viele Lösungen beruhen auf statischen Signaturen oder vordefinierten Policies 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 Eindämmungsmechanismen auf die Verfügbarkeit und die Systemleistung?

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 Multi-Variablen-Erkennungsmechanismus mit adaptivem Schwellenwert und zeitlicher Korrelation.

C3: Eine in die Kontrollebene von Kubernetes integrierte Architektur zur automatischen Eindämmung mit formalen Garantien zur Erhaltung von Isolationsinvarianten.

Der Rest des Artikels 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 Evaluation; Abschnitt 7 diskutiert Implikationen und Limitationen; und Abschnitt 8 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

2.1 Formale Definitionen

Ein Container kann formal als ein Tupel $C = (I, R, N, G)$ definiert werden, wobei $I$ das unveränderliche Image, $R$ das Runtime, $N$ die Menge der Namespaces und $G$ die Menge der cgroups-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 einen beschrifteten gerichteten 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 vorhandenen Ansätze lassen sich in vier Kategorien einteilen:

1. Statische Image-Prüfung (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. In jüngerer Zeit untersuchen Forschungsarbeiten eBPF für Beobachtbarkeit mit geringem Overhead.

2.3 Einschränkungen

Die meisten Lösungen:

(i) verfügen über keine formale Fundierung;
(ii) integrieren keine mehrschichtige Beobachtbarkeit;
(iii) weisen in dynamischen Workloads hohe False-Positive-Raten auf;
(iv) bieten keine automatisierte Eindämmung mit Korrektheitsgarantien.

Diese Lücken motivieren unseren Vorschlag.

3. Bedrohungsmodell und Problemformalierung

Wir nehmen einen Angreifer an mit der Fähigkeit:

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

Wir nehmen keine vorherige Kompromittierung der Kontrollebene von Kubernetes 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 Rechenaufwands $O \leq \epsilon$.

4. Vorgeschlagene Methodik

4.1 Überblick

Unsere Architektur umfasst drei Schichten:

1. Telemetrie-Erfassung (eBPF, auditd)
2. Analyse-Engine (probabilistisches Modell + Graph)
3. Eindämmungsmechanismus (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)$, markieren wir eine Anomalie.

Algorithm 1: Multi-Variablen-Erkennung

Input: Ereignisstrom E
Output: Alarm A

1: μ, Σ initialisieren
2: for each time window 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$ (vorberechnet).

4.3 Eindämmungsalgorithmus

Algorithm 2: Adaptive Eindämmung

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

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

Wir stellen sicher, dass die resultierende Policy die erforderliche minimale Konnektivität gemäß $R_{min}$ erhält.

5. Implementierung

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

Der experimentelle Cluster bestand aus 48 physischen Knoten, jeder 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 den 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 adaptive Stichproben.

6. Experimentelle Evaluation

6.1 Konfiguration

Wir führten 17 Angriffsszenarien aus, darunter:

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

Baselines:

• Falco (Standardregeln)
• Sysdig Secure
• Nur auf einem statischen Schwellenwert basierender Detektor

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
• False Positives: 2,3 % (±0,4)
• Mittlerer CPU-Overhead: 4,9 %
• Mittlere Erkennungsverzögerung: 1,8 s

Im Vergleich:

Falco:

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

Sysdig:

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

Die mittlere Eindämmungszeit 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 mehrschichtige Korrelation kontextuelle Ambiguität reduziert und die Präzision verbessert. Die Integration mit der Kontrollebene ermöglicht eine nahezu unmittelbare Reaktion.

Zu den Limitationen gehören die Abhängigkeit von repräsentativen Trainingsdaten und eine mögliche Umgehung durch Angriffe niedriger und langsamer Intensität.

Die externe Validität kann in heterogenen Umgebungen mit angepassten Kernels beeinträchtigt sein.

8. Fazit und zukünftige Arbeiten

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

Wir demonstrierten signifikante quantitative Verbesserungen bei Präzision und Reaktionszeit bei kontrolliertem Overhead.

Als zukünftige Arbeiten beabsichtigen wir, Folgendes zu untersuchen:

(i) auf dynamischen zeitlichen Graphen basierende Modelle;
(ii) Integration mit SBOM und Lieferkettenanalyse;
(iii) formale Verifikation von Policies 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.