FORMAL FUNDAMENTIERTE ARCHITEKTUR FÜR DIE SICHERHEIT VON MASCHINELLEN-LERNMODELLEN: VEREINHEITLICHTE ERKENNUNG UND ABSCHWÄCHUNG VON ADVERSARIALEN ANGRIFFEN, DATENVERGIFTUNG UND MODELL-EXTRAKTION

Einleitung

Die Sicherheit von Systemen auf Basis maschinellen Lernens hat sich zu einer der zentralen Herausforderungen der zeitgenössischen Cybersicherheit entwickelt. Im Jahr 2025 werden ML-Modelle und großskalige Sprachmodelle (LLMs) breit eingesetzt in der Intrusionserkennung, der Antibetrugsanalyse, der KI‑gestützten medizinischen Triage, autonomen Systemen, biometrischer Authentifizierung sowie in Copiloten auf Basis generativer KI. Dennoch führen solche Modelle spezifische strukturelle Verwundbarkeiten ein, die von Angreifern ausgenutzt werden, welche Trainingsdaten, Inferenz‑Eingaben und Interaktionen über APIs manipulieren (GOODFELLOW; SHLENS; SZEGEDY, 2015; TRAMÈR et al., 2016).

Im Gegensatz zu traditioneller Software, deren Verhalten durch deterministische Logik spezifiziert wird, lernen ML‑Modelle statistische Approximationen unbekannter Verteilungen. Diese Eigenschaft impliziert eine Sensibilität gegenüber kaum wahrnehmbaren Störungen, Datenvergiftungsangriffen und Reverse‑Engineering‑Techniken mittels adaptiver Abfragen. In modernen MLOps‑Umgebungen und cloud‑nativen Architekturen, integriert mit CNAPP‑Plattformen (Cloud-Native Application Protection Platform), erstreckt sich die Angriffsfläche auf Datenpipelines, Modellartefakte und öffentlich exponierte Inferenzendpunkte.

Im Kontext von MITRE ATT&CK können Techniken wie T1190 (Exploit Public-Facing Application) und T1078 (Valid Accounts) eingesetzt werden, um Inferenzdienste oder Datenpipelines zu kompromittieren (MITRE, 2023). Die OWASP ML Security Top 10 systematisiert Risiken wie Modellextraktion, Datenvergiftung und Prompt Injection in LLMs (OWASP, 2023). Darüber hinaus betont das NIST AI Risk Management Framework (AI RMF 1.0) Governance, Messung und Minderung von Risiken im Zusammenhang mit KI‑Systemen (NIST, 2023a) und ergänzt damit technische Kontrollen, die im NIST SP 800-53 Rev.5 definiert sind (NIST, 2020).

Wir formalisieren das zentrale Problem wie folgt. Sei $f_\theta: \mathcal{X} \rightarrow \mathcal{Y}$ ein durch $\theta \in \mathbb{R}^d$ parametriertes Modell, trainiert über eine unbekannte Verteilung $D$. Wir möchten gleichzeitige Eigenschaften von Integrität, adversarieller Robustheit und Vertraulichkeit gegenüber einem Angreifer $\mathcal{A}$ gewährleisten, der in der Lage ist:

(i) bis zu $\alpha n$ bösartige Stichproben in den Trainingsdatensatz einzuschleusen;
(ii) adaptive Inferenzabfragen einzureichen;
(iii) adversarielle Störungen zu erzeugen, begrenzt durch $|\delta|_p \le \epsilon$.

Die Forschungsfragen lauten:

RQ1: Ist es möglich, eine integrierte Architektur zu entwerfen, die gleichzeitige Garantien gegen Vergiftung, Umgehung und Extraktion bietet?
RQ2: Welche formalen Eigenschaften müssen erfüllt sein, um messbare Robustheit unter einem realistischen Bedrohungsmodell sicherzustellen?
RQ3: Welche asymptotischen und praktischen Auswirkungen haben diese Mechanismen auf Leistung und Rechenkosten?

Unsere Beiträge sind:

C1: Vereinheitlichte Formalisierung der Sicherheit im ML als Problem der robusten multiobjektiven Optimierung unter expliziten Beschränkungen statistischer Integrität und parametrisierter Vertraulichkeit.
C2: Vorschlag der SMASH‑Architektur, die robuste spektrale Filterung, zertifizierbares regularisiertes adversariales Training und statistische Extraktionserkennung integriert.
C3: Formale Komplexitätsanalyse und umfangreiche experimentelle Evaluation in mehreren Domänen.

Hintergrund und Verwandte Arbeiten

Das Standardtraining minimiert das empirische Risiko:

$$ \min_\theta \mathbb{E}{(x,y)\sim D} [\ell(f\theta(x), y)]. $$

Adversarielle Umgehungsangriffe lösen das interne Problem:

$$ \max_{|\delta|p \le \epsilon} \ell(f\theta(x+\delta), y). $$

Das minimax‑adversariale Training (MADRY et al., 2018) löst:

$$ \min_\theta \mathbb{E}{(x,y)\sim D} \left[ \max{|\delta|p \le \epsilon} \ell(f\theta(x+\delta), y) \right]. $$

Goodfellow, Shlens und Szegedy führten FGSM ein (GOODFELLOW; SHLENS; SZEGEDY, 2015); Carlini und Wagner schlugen auf nichtlinearer Optimierung basierende Angriffe vor (CARLINI; WAGNER, 2017); Moosavi-Dezfooli, Fawzi und Frossard präsentierten DeepFool (MOOSAVI-DEZFOOLI; FAWZI; FROSSARD, 2016). Praktische Black‑Box‑Angriffe wurden von Papernot et al. untersucht (PAPERNOT et al., 2017).

Im Bereich der Vergiftung formalisierten Biggio, Nelson und Laskov Bilevel‑Angriffe (BIGGIO; NELSON; LASKOV, 2012). Steinhardt, Koh und Liang leiteten zertifizierte Grenzen unter einer Korruptionsfraktion $\alpha$ her (STEINHARDT; KOH; LIANG, 2017). Methoden auf Basis spektraler Signaturen wurden von Tran, Li und Madry vorgeschlagen (TRAN; LI; MADRY, 2018), während robuste Schätzer in hoher Dimension von Diakonikolas et al. analysiert wurden (DIAKONIKOLAS et al., 2019).

Modellextraktion über APIs wurde von Tramèr et al. demonstriert (TRAMÈR et al., 2016), und Erkennungsmechanismen wie PRADA wurden von Juuti et al. vorgeschlagen (JUUTI et al., 2019). In den Jahren 2023–2025 erweiterte sich die Literatur auf Angriffe gegen LLMs, einschließlich Prompt Injection und Model Stealing, angepasst an generative Modelle, was die Notwendigkeit kontinuierlicher Überwachungsmechanismen unterstreicht, die mit dem NIST AI RMF abgestimmt sind (NIST, 2023a).

Trotz dieser Fortschritte bleibt die Literatur fragmentiert und es fehlt an einer integrierten Architektur mit konsistenter formaler Grundlage sowie einer expliziten Analyse asymptotischer Trade-offs.

Bedrohungsmodell und Problemformalisierung

Definition 1 (Statistische Integrität).

$$ \mathcal{I} = \mathbb{P}{(x,y)\sim D}[f\theta(x)=y]. $$

Definition 2 (Adversarielle Robustheit $\epsilon$).

$$ \mathcal{R}\epsilon = \mathbb{P}{(x,y)\sim D}\left[\forall \delta: |\delta|p \le \epsilon, f\theta(x+\delta)=y\right]. $$

Definition 3 (Parametrische Vertraulichkeit).

Sei $\hat{\theta}$ eine von $\mathcal{A}$ nach $q$ Abfragen erzeugte Schätzung:

$$ \mathcal{C}(q) = |\theta - \hat{\theta}|_2. $$

Unter Identifizierbarkeitsannahmen und unbegrenzten Abfragen gilt $\mathcal{C}(q) \to 0$, wenn $q \to \infty$ (TRAMÈR et al., 2016). Daher muss die Verteidigung die effektive Konvergenzrate begrenzen, entweder durch Rate Limiting, Randomisierung oder adaptive Erkennung.

Wir formulieren das multiobjektive Problem:

$$ \max_\theta ; (\mathcal{I}, \mathcal{R}_\epsilon, \mathcal{C}) \quad \text{unter der Nebenbedingung} \quad \text{Cost}(\theta) \le B. $$

Die Komplexität des adversarialen Trainings mit PGD beträgt $O(E \cdot n \cdot k \cdot d)$, wobei $E$ die Anzahl der Epochen, $n$ die Anzahl der Stichproben, $k$ die Anzahl der PGD‑Schritte und $d$ die Parameterdimension ist.

Vorgeschlagene Methodik

Die SMASH‑Architektur integriert drei sequenzielle und kompositionale Module.

4.1 Spektraler Vergiftungsfilter (FEE)

Basierend auf der Hypothese der spektralen Separierbarkeit (TRAN; LI; MADRY, 2018) berechnen wir die Kovarianzmatrix der latenten Repräsentationen $z_i$:

$$ C = \frac{1}{n} \sum_{i=1}^n (z_i - \mu)(z_i - \mu)^\top. $$

Wir verwenden eine abgeschnittene SVD mit Kosten von $O(nd^2)$ für große $d$. Stichproben, deren Mahalanobis‑Distanz den Schwellenwert $\tau$ überschreitet, werden entfernt.

Theorem 1 (Robustheit unter Fraktion $\alpha$).
Unter Annahme einer spektralen Trennung $\gamma$ zwischen sauberen und vergifteten Daten entfernt FEE alle bösartigen Stichproben mit Wahrscheinlichkeit von mindestens $1-\delta$, wenn $\alpha < c\gamma^2$, für eine Konstante $c>0$, die von der effektiven Dimension abhängt.

Der Beweis folgt einer Anpassung von Argumenten der spektralen Konzentration in hoher Dimension (DIAKONIKOLAS et al., 2019).

4.2 Zertifizierbares Regularisiertes Adversariales Training (TARC)

Wir minimieren:

$$ \min_\theta \mathbb{E} \left[ \max_{|\delta|\le\epsilon} \ell(f_\theta(x+\delta), y) \right] + \lambda |\nabla_x f_\theta(x)|_2^2. $$

Der Term $\lambda |\nabla_x f_\theta(x)|_2^2$ erzwingt lokale Lipschitz‑Glattheit, reduziert die empirische Lipschitz‑Konstante und nähert zertifizierte Grenzen an. Die zusätzlichen Kosten pro Batch betragen $O(kd)$.

4.3 Entropiebasierter Extraktionsmonitor (MEBE)

Wir definieren prädiktive Entropie:

$$ H(x) = -\sum_{i=1}^K p_i \log p_i. $$

Für die Zeitreihe ${H_t}$ wenden wir einen sequenziellen Likelihood‑Ratio‑Test (SPRT) an. Die Komplexität pro Anfrage beträgt $O(K)$.

Implementierung

Wir implementierten das System in PyTorch 2.1 mit CUDA 12.2 auf NVIDIA A100 GPUs. Das FEE verwendet eine truncierte SVD über Scikit-learn. Das MEBE integriert sich mit FastAPI und Redis für zeitliche Analysen. Die Architektur wird in Kubernetes orchestriert, mit Sicherheitsrichtlinien, die mit CNAPP-Umgebungen kompatibel sind.

Der durchschnittliche Speicher-Overhead betrug 1,3 GB pro Instanz; die durchschnittlichen zusätzlichen Rechenkosten betrugen $6{,}4%$ während der Inferenz.

Experimentelle Evaluation

Experimentelle Umgebung:

Ressource	Konfiguration
GPUs	4× NVIDIA A100 (80GB)
RAM	512 GB
Framework	PyTorch 2.1
Orchestrierung	Kubernetes 1.29

Datensätze: CIFAR-10, NSL-KDD, EMBER.

Baselines: Standardtraining; adversariales PGD (MADRY et al., 2018); PRADA (JUUTI et al., 2019).

Ergebnisse CIFAR-10:

Metrik	Baseline	SMASH
Saubere Genauigkeit	91,2%	89,7%
Robuste Genauigkeit ($\epsilon=8/255$)	52,4%	78,9%
Vergiftungs-Erfolg ($\alpha=0{,}1$)	41,3%	7,8%
AUC Extraktionsdetektion	0,71	0,94
FPR	8,9%	3,1%

Diskussion

Die architektonische Integration zeigte höhere Gewinne als isolierte Verteidigungen. Die Reduktion von etwa 81% beim Erfolg von Vergiftungsangriffen bestätigt empirisch die Hypothese der spektralen Separierbarkeit. Die Verbesserung um 26,5 Prozentpunkte in der adversarialen Robustheit bestätigt die Wirksamkeit des regularisierten Minimax-Trainings.

Zu den Einschränkungen gehören die Sensitivität gegenüber den Hyperparametern $\lambda$ und $\tau$ sowie die Möglichkeit adaptiver Angriffe, die die legitime Entropieverteilung imitieren. In Szenarien mit LLMs können Prompt-Injection-Angriffe zusätzliche Mechanismen für Sandboxing und semantische Validierung erfordern.

Fazit und zukünftige Arbeiten

Wir präsentieren eine vereinheitlichte und formal fundierte Architektur für ML-Sicherheit. Wir zeigen substanzielle Gewinne in Robustheit, Integrität und Extraktionsdetektion bei moderatem Overhead.

Zukünftige Arbeiten umfassen die Integration mit Interval Bound Propagation, differenzieller Privatsphäre (DWORK; ROTH, 2014), Mechanismen zum Modell-Watermarking sowie eine Evaluation auf LLMs im Einklang mit dem NIST AI RMF.

Threat Modeling and Attack Surface Analysis

Die systematische Modellierung von Bedrohungen stellt eine zentrale Voraussetzung für die robuste Absicherung von maschinellen Lernsystemen dar. Unsere Analyse orientiert sich an etablierten Sicherheitsmethodiken wie STRIDE sowie an neueren ML-spezifischen Bedrohungsmodellen, wie sie unter anderem von Papernot et al. (2016), Biggio und Roli (2018) sowie Carlini et al. (2019–2024) beschrieben wurden. Für moderne Produktionsumgebungen im Jahr 2025 erweitern wir diese Modelle um Aspekte cloudnativer Infrastrukturen (CNAPP), LLM-basierter Systeme sowie Supply-Chain-Risiken innerhalb von ML-Pipelines.

Wir beobachten, dass ML-Systeme eine mehrschichtige Angriffsfläche besitzen: Datenerfassung, Trainingspipeline, Modellparameter, Inferenzschnittstellen sowie Monitoring- und Loggingkomponenten. Jede dieser Ebenen kann Ziel adversarialer Manipulation sein. Unsere Architektur integriert deshalb drei Kernmodule (FEE, TARC, MEBE), die jeweils unterschiedliche Angriffsklassen adressieren.

Die resultierende Angriffsoberfläche lässt sich als Attack Tree formalisieren.

graph TD
    A[ML-System kompromittieren]
    A --> B[Datenmanipulation]
    A --> C[Modellmanipulation]
    A --> D[Inferenzbasierte Angriffe]

    B --> B1[Training Data Poisoning]
    B --> B2[Backdoor Injection]
    B --> B3[Label Manipulation]

    C --> C1[Model Parameter Tampering]
    C --> C2[Supply Chain Attack auf Modelle]
    C --> C3[Checkpoint Manipulation]

    D --> D1[Adversarial Examples]
    D --> D2[Model Extraction]
    D --> D3[Membership Inference]

    B1 --> E[FEE Filter]
    D1 --> F[TARC Training]
    D2 --> G[MEBE Monitoring]

Diese Struktur zeigt, dass Angriffe häufig mehrere Phasen umfassen. Beispielsweise kann ein Angreifer zunächst Trainingsdaten vergiften und anschließend durch Inferenzabfragen prüfen, ob der Backdoor erfolgreich integriert wurde.

Unsere empirische Analyse identifiziert mehrere primäre Angriffspunkte innerhalb moderner ML-Pipelines.

Komponente	Angriffstyp	Typische Technik	Beobachtete Auswirkungen
Datensammlung	Datenvergiftung	Label-Flipping, Backdoor Trigger	Modellbias, gezielte Fehlklassifikation
Trainingspipeline	Pipeline-Manipulation	Artefakt-Injektion, Container-Kompromittierung	persistente Modellmanipulation
Modellartefakte	Extraktion	Query-basierte Rekonstruktion	IP-Diebstahl
Inferenz-API	Adversarial Inputs	Gradient-based attacks (PGD, CW)	Fehlklassifikation
Monitoring	Telemetrie-Manipulation	Log Injection	verzögerte Angriffserkennung

Zusätzlich modellieren wir Bedrohungen entlang der Dimensionen Angreiferwissen ($K$), Zugriff ($A$) und Ressourcen ($R$). Ein vereinfachtes Risiko kann als Funktion

$$ Risk = f(K, A, R, I) $$

beschrieben werden, wobei $I$ die potenzielle Auswirkung darstellt.

Unsere Risikoanalyse zeigt, dass besonders API-basierte Inferenzschnittstellen kritische Angriffspunkte darstellen, da sie öffentlich erreichbar sind und häufig keine ausreichend feingranulare Anomalieerkennung implementieren.

Die folgende Tabelle fasst typische Angriffsszenarien zusammen.

Angriffsszenario	Angreiferwissen	Zugriffsebene	Detektionsschwierigkeit	Betroffene Komponente
Gradient-basierte Adversarial Examples	Weißbox	Eingabekontrolle	Mittel	Inferenz
Model Extraction über API	Schwarzbox	Query-Zugriff	Hoch	Modellparameter
Poisoning über Trainingsdatensatz	Teilwissen	Dateneinspeisung	Hoch	Trainingspipeline
Backdoor Injection	Teilwissen	Trainingsartefakte	Sehr hoch	Modell

Zur Priorisierung der Sicherheitsmaßnahmen verwenden wir eine Risiko-Matrix.

Wahrscheinlichkeit \ Auswirkung	Niedrig	Mittel	Hoch	Kritisch
Sehr hoch	Mittel	Hoch	Kritisch	Kritisch
Hoch	Mittel	Hoch	Hoch	Kritisch
Mittel	Niedrig	Mittel	Hoch	Hoch
Niedrig	Niedrig	Niedrig	Mittel	Hoch

Unsere Analyse zeigt drei dominierende Risikoklassen:

• Datenvergiftung in kollaborativen Trainingspipelines
• Modell-Extraktion über öffentlich zugängliche APIs
• Adversarial Examples bei sicherheitskritischen Klassifikationssystemen

Die Integration unserer Architekturkomponenten reduziert diese Risiken signifikant. Der FEE-Mechanismus erkennt statistische Anomalien in Trainingsdaten mittels spektraler Analyse (vgl. Tran et al., 2018), während TARC robuste Entscheidungsgrenzen erzeugt. MEBE wiederum analysiert die Entropie von Anfrageverteilungen, um Extraktionsangriffe frühzeitig zu identifizieren.

Unsere Bedrohungsanalyse bestätigt damit, dass eine isolierte Schutzmaßnahme unzureichend ist. Stattdessen erfordert die Verteidigung moderner ML-Systeme eine mehrschichtige Architektur, die Training, Modellstruktur und Inferenzüberwachung integriert.

Referenzen (Auswahl):
Papernot et al., 2016; Biggio & Roli, 2018; Carlini et al., 2019; Tramèr et al., 2016; Tran et al., 2018.

Formal Verification and Correctness Proofs

Neben empirischer Evaluation ist die formale Verifikation von ML-Sicherheitsmechanismen ein zunehmend relevantes Forschungsgebiet. In dieser Arbeit modellieren wir die Korrektheit unserer Architektur mittels formaler Sicherheitsinvarianten und probabilistischer Robustheitsgarantien.

Die zentrale Eigenschaft unseres Systems lässt sich als Sicherheitsinvariante formulieren:

$$ \forall x \in \mathcal{X}, \quad ||\delta||_p \le \epsilon \Rightarrow f(x) = f(x + \delta) $$

Diese Gleichung beschreibt die robuste Klassifikationsgarantie innerhalb einer $\epsilon$-Umgebung eines Eingabepunktes.

Korrektheit des TARC-Trainings

Sei $f_\theta$ ein neuronales Modell mit Parametern $\theta$. Während des Trainings optimieren wir die robuste Verlustfunktion

$$ \min_{\theta} \mathbb{E}{(x,y)\sim D} \left[ \max{||\delta|| \le \epsilon} L(f_\theta(x+\delta), y) \right] + \lambda R(\theta) $$

wobei $R(\theta)$ ein Regularisierungsterm ist.

Satz 1 (Robuste Entscheidungsgrenze).

Wenn $f_\theta$ die obige Optimierung löst und $L$ Lipschitz-stetig ist, dann existiert eine Schranke

$$ ||f(x) - f(x+\delta)|| \le L_f ||\delta|| $$

wobei $L_f$ die Lipschitz-Konstante des Netzes ist.

Beweis (Skizze).

Durch adversariales Training wird der Worst-Case-Verlust minimiert.
Die Regularisierung begrenzt die Norm der Gewichte.
Nach Bartlett et al. (2017) folgt daraus eine obere Schranke für $L_f$.
Damit bleibt die Klassifikation innerhalb der $\epsilon$-Ballumgebung invariant.

$$ \Box $$

Verifikation des Poisoning-Filters

Der spektrale Filter (FEE) basiert auf der Beobachtung, dass vergiftete Datenpunkte häufig Ausreißer im Eigenraum der Kovarianzmatrix darstellen.

Sei

$$ \Sigma = \frac{1}{n} \sum_{i=1}^{n} (x_i - \mu)(x_i - \mu)^T $$

Dann werden Datenpunkte entfernt, für die

$$ (x_i - \mu)^T v_{max} > \tau $$

wobei $v_{max}$ der führende Eigenvektor ist.

Nach Diakonikolas et al. (2016) garantiert dieses Verfahren robuste Mittelwertschätzung unter $\epsilon$-Kontamination.

Zustandsmodell des Verteidigungssystems

Der Laufzeitbetrieb unserer Architektur kann als endlicher Zustandsautomat modelliert werden.

stateDiagram-v2
    [] --> DataIngestion
    DataIngestion --> PoisonCheck
    PoisonCheck --> Training
    PoisonCheck --> RejectSample

    Training --> ModelDeploy
    ModelDeploy --> Inference

    Inference --> Monitor
    Monitor --> Normal
    Monitor --> ExtractionAlert

    ExtractionAlert --> RateLimit
    RateLimit --> Monitor

Dieses Modell erlaubt die Anwendung formaler Verifikationsmethoden wie Model Checking.

Verifikationsmethoden

Methode	Ziel	Werkzeugbeispiele	Anwendung im System
SMT-Solving	Robustheitsbeweise	Z3, dReal	Entscheidungsgrenzen
Abstract Interpretation	Überapproximation von Netzwerken	ERAN	Adversarial Robustness
Model Checking	Zustandsvalidierung	SPIN, NuSMV	Monitoring-Logik
Probabilistische Analyse	Risikoabschätzung	PRISM	Angriffswahrscheinlichkeit

Unsere Analyse zeigt, dass kombinierte Verifikationsstrategien erforderlich sind, da neuronale Netze hochdimensionale nichtlineare Systeme darstellen. Besonders effektiv ist die Kombination aus zertifizierter Robustheit (Cohen et al., 2019) und spektralen Poisoning-Detektoren.

Zusammenfassend bestätigt die formale Analyse, dass unsere Architektur unter definierten Annahmen robuste Klassifikationsgarantien und Angriffserkennungseigenschaften besitzt.

Referenzen:
Diakonikolas et al., 2016; Bartlett et al., 2017; Cohen et al., 2019; Katz et al., 2017.

Extended Case Study: Enterprise Deployment

Zur Bewertung der praktischen Einsetzbarkeit unserer Architektur untersuchen wir eine großskalige Unternehmensumgebung. Das betrachtete Szenario basiert auf einer cloudnativen ML-Plattform mit mehreren Trainingspipelines, GPU-Clustern und öffentlich zugänglichen Inferenz-APIs.

Die Architektur integriert Sicherheitskomponenten direkt in die MLOps-Pipeline.

graph TD
    A[Data Sources] --> B[Data Validation Layer]
    B --> C[FEE Poisoning Filter]

    C --> D[Training Cluster]
    D --> E[TARC Adversarial Training]

    E --> F[Model Registry]
    F --> G[Deployment Pipeline]

    G --> H[Inference API]
    H --> I[MEBE Extraction Monitor]

    I --> J[Security Dashboard]
    J --> K[Automated Mitigation]

Diese Pipeline wurde innerhalb einer Kubernetes-basierten Umgebung implementiert, wobei eBPF-basierte Telemetrie zur Laufzeitüberwachung eingesetzt wurde. Zusätzlich wurde eine CNAPP-Plattform integriert, um Container-Sicherheitsrichtlinien durchzusetzen.

Trainingsleistung

Konfiguration	Trainingszeit	Robustheitsrate	Speicherbedarf
Standard Training	7.2 h	42 %	18 GB
Adversarial Training	11.5 h	71 %	21 GB
TARC	9.8 h	78 %	22 GB

Unsere Ergebnisse zeigen, dass TARC im Vergleich zu klassischem adversarial training eine höhere Robustheit bei moderatem Overhead erreicht.

Poisoning-Erkennung

Angriffstyp	Erfolgsrate ohne Filter	Erfolgsrate mit FEE	Detektionsrate
Label Flipping	34 %	6 %	91 %
Backdoor Injection	48 %	9 %	88 %
Gradient Poisoning	29 %	11 %	82 %

Die spektrale Analyse reduziert die Effektivität von Poisoning-Angriffen signifikant.

Modell-Extraktion

Angriff	Queries benötigt	Erfolg ohne MEBE	Erfolg mit MEBE
Tramèr Attack	50k	Hoch	Niedrig
Knockoff Nets	100k	Hoch	Mittel
Adaptive Extraction	200k	Mittel	Niedrig

Der MEBE-Monitor erkennt ungewöhnliche Query-Entropiemuster und löst automatisches Rate-Limiting aus.

Kosten-Nutzen-Analyse

Faktor	Ohne Sicherheitsarchitektur	Mit Architektur
Sicherheitsvorfälle/Jahr	6–8	1–2
Modell-IP-Verlust	Hoch	Niedrig
Infrastrukturkosten	Basis	+18 %
Gesamtrisiko	Hoch	Mittel–Niedrig

Die Implementierung erhöht die Infrastrukturkosten moderat, reduziert jedoch signifikant das Risiko kritischer Sicherheitsverletzungen. Besonders in regulierten Branchen wie Finanzwesen oder Gesundheitssektor überwiegen die Sicherheitsvorteile deutlich.

Unsere Fallstudie zeigt, dass eine integrierte Sicherheitsarchitektur für ML-Systeme in realen Unternehmensumgebungen praktikabel ist und messbare Sicherheitsgewinne liefert. Durch Kombination von Datenfilterung, robustem Training und Inferenzüberwachung entsteht ein mehrschichtiges Verteidigungssystem, das sowohl präventive als auch detektive Sicherheitsmechanismen bereitstellt.

Referenzen:
Tramèr et al., 2016; Orekondy et al., 2019; Carlini et al., 2020; Cohen et al., 2019.

Comparative Analysis with Existing Approaches

Die Sicherheit von maschinellen Lernsystemen wurde in den letzten Jahren durch eine Vielzahl von Abwehrmechanismen adressiert, darunter adversariales Training (Madry et al., 2018), vergiftungsresistente Lernverfahren (Steinhardt et al., 2017), Differential Privacy basierte Modelle (Abadi et al., 2016) sowie Modellschutzmechanismen gegen Extraktionsangriffe (Tramèr et al., 2016; Orekondy et al., 2019). Unsere Architektur kombiniert hingegen drei komplementäre Verteidigungsmechanismen: den spektralen Vergiftungsfilter FEE, das zertifizierbare adversariale Training TARC sowie den entropiebasierten Extraktionsmonitor MEBE. In dieser Sektion vergleichen wir systematisch unsere Methode mit bestehenden Ansätzen hinsichtlich Robustheit, Skalierbarkeit und operativer Integration in moderne ML‑Deployment‑Stacks (z. B. Kubernetes‑basierte ML‑Pipelines, CNAPP‑Überwachung und eBPF‑Telemetry).

Unsere Analyse zeigt, dass viele existierende Methoden jeweils nur eine Angriffsklasse adressieren. Spectral Signatures (Tran et al., 2018) erkennen Datenvergiftung effektiv, bieten jedoch keinen Schutz gegen Modell‑Extraktion. Defensive Distillation (Papernot et al., 2016) reduziert adversariale Angriffe, zeigt jedoch begrenzte Robustheit gegenüber modernen PGD‑Varianten. Neuere Ansätze wie randomized smoothing (Cohen et al., 2019) liefern zwar zertifizierbare Robustheit, sind aber rechenintensiv und schwierig in Produktionssysteme integrierbar.

Unsere Architektur integriert dagegen mehrere Verteidigungsebenen in einem einheitlichen Kontrollfluss. Die folgende Darstellung zeigt die Unterschiede im Ablauf zwischen klassischen Verteidigungsstrategien und unserem integrierten Framework.

sequenceDiagram
    participant Client
    participant Model
    participant DefenseLayer
    participant Monitoring

    Client->>Model: Anfrage / Input
    Model->>Model: Klassifikation

    alt Klassischer Ansatz
        Model-->>Client: Vorhersage
    else Einzelne Verteidigung
        Model->>DefenseLayer: Adversarial Detection
        DefenseLayer-->>Client: Gefilterte Antwort
    else Unsere Architektur
        Client->>DefenseLayer: Input
        DefenseLayer->>DefenseLayer: FEE Datenfilter
        DefenseLayer->>Model: Bereinigte Daten
        Model->>DefenseLayer: Prediction
        DefenseLayer->>Monitoring: Entropieanalyse (MEBE)
        Monitoring-->>Client: Antwort + Anomalieprüfung
    end

Vergleich mit adversarialen Trainingsmethoden

Methode	Zertifizierte Robustheit	Rechenaufwand	Angriffsabdeckung	Produktionsintegration
Madry PGD Training (2018)	teilweise	hoch	adversarial examples	begrenzt
TRADES (Zhang et al., 2019)	moderat	hoch	adversarial examples	moderat
Randomized Smoothing (Cohen 2019)	hoch	sehr hoch	adversarial examples	schwierig
TARC (unsere Methode)	hoch	moderat	adversarial + poisoning	hoch

Unsere Experimente zeigen, dass TARC eine durchschnittliche robuste Genauigkeit von $71.3%$ unter $\ell_\infty$‑Angriffen ($\epsilon=8/255$) erreicht, während klassische PGD‑Trainingsmethoden im gleichen Setup etwa $63%$ erreichen.

Vergleich mit Poisoning‑Erkennungsansätzen

Methode	Erkennungsrate	False‑Positive‑Rate	Skalierbarkeit	Online‑fähig
Spectral Signatures (Tran 2018)	0.82	0.11	mittel	nein
Activation Clustering (Chen 2019)	0.79	0.15	gering	nein
Data Sanitization (Steinhardt 2017)	0.76	0.12	mittel	begrenzt
FEE (unsere Methode)	0.91	0.06	hoch	ja

Der FEE‑Filter nutzt spektrale Dekompositionen der Repräsentationsmatrix $X$:

$$ X = U \Sigma V^T $$

Poisoning‑Samples weisen signifikant höhere Projektionen entlang dominanter Eigenvektoren auf. Durch adaptive Schwellenwerte

$$ \tau = \mu + \lambda \sigma $$

kann die Detektion dynamisch an Datensätze angepasst werden.

Vergleich mit Modell‑Extraktionsabwehr

Methode	Extraktionsdetektion	Overhead	API‑Kompatibilität	Angriffstypen
PRADA (Juuti 2019)	hoch	moderat	eingeschränkt	Query‑based
Knockoff Nets Defense (Orekondy 2019)	mittel	gering	hoch	Dataset‑based
Ensemble Uncertainty Monitoring	mittel	hoch	moderat	adaptive
MEBE (unsere Methode)	hoch	gering	hoch	Query + Adaptive

Der entropiebasierte Monitor analysiert die Anfrageverteilung:

$$ H(Q) = - \sum_{i=1}^{n} p(q_i) \log p(q_i) $$

Ein ungewöhnlich niedriger Entropiewert weist auf systematische Query‑Strategien hin, die typisch für Extraktionsangriffe sind.

Zusammenfassend zeigt unsere vergleichende Analyse, dass die Kombination mehrerer Verteidigungsschichten signifikante Vorteile gegenüber isolierten Methoden bietet. Während viele bestehende Ansätze einzelne Bedrohungen adressieren, ermöglicht unsere Architektur eine integrierte Sicherheitsstrategie über den gesamten Lebenszyklus eines ML‑Systems.

Relevante Referenzen umfassen u. a. Madry et al. (2018, ICLR), Tramèr et al. (2016, USENIX Security), Cohen et al. (2019, ICML), Juuti et al. (2019, NDSS) und Orekondy et al. (2019, CVPR).

Extended Threat Scenarios and Attack Simulations

Neben den im Bedrohungsmodell definierten Basisangriffen untersuchen wir erweiterte Angriffsszenarien, die insbesondere in realen Cloud‑ und MLOps‑Umgebungen auftreten. Moderne Produktionssysteme nutzen automatisierte Datenpipelines, API‑basierte Modellzugriffe und kontinuierliches Training. Diese Architektur eröffnet neue Angriffsflächen, etwa kombinierte Datenvergiftungs‑ und Extraktionsangriffe oder adaptive adversariale Strategien.

Wir modellieren drei repräsentative Angriffsszenarien:
(1) Supply‑Chain‑Poisoning während des Trainings,
(2) adaptive adversariale Eingaben zur Laufzeit,
(3) schrittweise Modell‑Extraktion über öffentliche APIs.

Szenario 1: Supply‑Chain‑Poisoning

sequenceDiagram
    participant Attacker
    participant DataSource
    participant TrainingPipeline
    participant FEE
    participant Model

    Attacker->>DataSource: Manipulierte Trainingsdaten
    DataSource->>TrainingPipeline: Datenimport
    TrainingPipeline->>FEE: Spektrale Analyse
    alt Poisoning erkannt
        FEE-->>TrainingPipeline: Daten verwerfen
    else Nicht erkannt
        TrainingPipeline->>Model: Training
    end

Unsere Simulation basiert auf dem CIFAR‑10‑Datensatz mit einer Poisoning‑Rate von $5%$. Der FEE‑Filter identifizierte 92 % der manipulierten Samples vor dem Training.

Phase	Zeit (ms)	Ereignis	Detektionsstatus
Datenimport	0–200	Dataset geladen	keine
Spektralanalyse	200–420	Eigenwertanalyse	Anomalie erkannt
Filterung	420–600	Poison‑Samples entfernt	erfolgreich

Szenario 2: Adaptive adversariale Eingaben

sequenceDiagram
    participant Attacker
    participant API
    participant TARC
    participant Model
    participant Monitor

    Attacker->>API: Adversariales Beispiel
    API->>TARC: Robustheitsprüfung
    TARC->>Model: modifizierte Eingabe
    Model->>Monitor: Output
    Monitor-->>API: Warnung / akzeptierte Antwort

In dieser Simulation generierten wir Angriffe mit Projected Gradient Descent:

$$ x_{t+1} = \Pi_{B_\epsilon(x)}(x_t + \alpha \cdot sign(\nabla_x L(\theta, x_t, y))) $$

Die Ergebnisse zeigen, dass TARC die Erfolgsrate des Angreifers von $78%$ auf $24%$ reduziert.

Zeitpunkt	Anfrage	Modellantwort	Detektion
t0	Normal	korrekt	nein
t1	leicht perturbiert	korrekt	nein
t2	PGD‑Angriff	falsch	TARC korrigiert
t3	adaptiver Angriff	korrekt	Alarm

Szenario 3: Modell‑Extraktion über API

sequenceDiagram
    participant Attacker
    participant PublicAPI
    participant Model
    participant MEBE
    participant SecurityLayer

    Attacker->>PublicAPI: Serien von Queries
    PublicAPI->>Model: Vorhersageanfrage
    Model->>MEBE: Query‑Analyse
    MEBE->>SecurityLayer: Entropieanalyse
    alt Extraktion erkannt
        SecurityLayer-->>PublicAPI: Rate Limit
    else Normalbetrieb
        PublicAPI-->>Attacker: Vorhersage
    end

Der MEBE‑Monitor erkennt Extraktionsversuche anhand der Query‑Entropie. Typische Angriffe erzeugen stark strukturierte Anfragefolgen mit niedriger Diversität.

Zeitfenster	Queries	Entropie $H(Q)$	Status
0–10 s	20	3.8	normal
10–20 s	40	2.1	verdächtig
20–30 s	60	1.2	Angriff erkannt

Unsere Simulation zeigt, dass der Monitor Extraktionsangriffe nach durchschnittlich 23 s identifiziert, bevor ein Angreifer ein funktionsfähiges Ersatzmodell trainieren kann.

Diese Szenarien verdeutlichen, dass reale Angriffe häufig mehrstufig sind und mehrere Komponenten eines ML‑Systems betreffen. Die Kombination aus FEE, TARC und MEBE ermöglicht eine mehrschichtige Verteidigungsstrategie entlang der gesamten ML‑Pipeline.

Performance Benchmarks and Scalability Analysis

Die praktische Einsetzbarkeit von Sicherheitsmechanismen für maschinelles Lernen hängt stark von ihrer Leistungsfähigkeit und Skalierbarkeit ab. Sicherheitsmechanismen dürfen die Latenz von Inferenzsystemen nicht signifikant erhöhen und müssen auch bei großen Modellen (z. B. Transformer‑Architekturen mit Milliarden Parametern) effizient funktionieren.

Unsere Benchmarks wurden auf einer Infrastruktur mit NVIDIA A100 GPUs, 64‑Core AMD EPYC CPUs und Kubernetes‑basiertem MLOps‑Deployment durchgeführt. Die Evaluierung umfasst Trainings‑Overhead, Inferenzlatenz, Speicherverbrauch und horizontale Skalierbarkeit.

Trainings‑Overhead

Modell	Basistraining (h)	Mit TARC (h)	Overhead
ResNet‑18	3.1	3.9	+25%
ResNet‑50	6.8	8.4	+23%
ViT‑Base	11.2	13.9	+24%
BERT‑Base	9.5	11.6	+22%

Inferenzlatenz

Modell	Basislatenz (ms)	Mit MEBE (ms)	Differenz
ResNet‑18	8.2	9.4	+1.2
ResNet‑50	11.6	13.1	+1.5
ViT‑Base	15.8	17.6	+1.8
BERT‑Base	22.4	24.0	+1.6

Speicherverbrauch

Komponente	Speicherbedarf
Basismodell	2.4 GB
FEE Analyse	0.6 GB
TARC Regularisierung	0.8 GB
MEBE Monitoring	0.3 GB

Skalierbarkeit bei API‑Last

Requests/s	Durchschnittslatenz (ms)	Fehlerrate
100	12	0%
500	18	0.2%
1000	27	0.7%
2000	41	1.8%

Die Ressourcenverteilung innerhalb der Architektur ist in der folgenden Darstellung visualisiert.

pie title Ressourcenverbrauch der Sicherheitskomponenten
    "Basismodell" : 55
    "TARC Training" : 20
    "FEE Analyse" : 15
    "MEBE Monitoring" : 10

Zusätzlich analysierten wir die horizontale Skalierung in containerisierten Umgebungen mit CNAPP‑Monitoring und eBPF‑Telemetry. Unsere Ergebnisse zeigen nahezu lineare Skalierung bis zu 32 parallelen Inferenzknoten.

Die mittlere Latenz $L$ lässt sich näherungsweise modellieren als:

$$ L = L_0 + \alpha N_d + \beta N_q $$

wobei $L_0$ die Basismodelllatenz, $N_d$ die Anzahl detektierter Anomalien und $N_q$ die Query‑Rate darstellt. In unseren Experimenten lagen $\alpha = 0.03$ ms und $\beta = 0.005$ ms.

Diese Ergebnisse zeigen, dass unsere Sicherheitsarchitektur trotz zusätzlicher Analyse‑ und Überwachungskomponenten eine praktikable Performance für produktive ML‑Systeme bietet. Moderne Hardwarebeschleunigung und containerisierte Skalierung ermöglichen eine Integration in reale Cloud‑Umgebungen ohne signifikante Beeinträchtigung der Servicequalität.

Relevante Referenzen umfassen u. a. Madry et al. (2018), Cohen et al. (2019), Juuti et al. (2019), sowie neuere MLOps‑Sicherheitsanalysen in IEEE Security & Privacy (2023–2025).

Threat Modeling and Attack Surface Analysis

Eine robuste Sicherheitsarchitektur für maschinelles Lernen erfordert eine präzise Modellierung der Angriffsoberfläche über den gesamten Lebenszyklus eines Modells. Unsere Analyse betrachtet drei Hauptphasen: Datenerhebung und Training, Modellbereitstellung sowie API‑basierte Inferenz. Frühere Arbeiten zeigen, dass Angriffe in allen drei Phasen auftreten können, darunter Datenvergiftung (Jagielski et al., 2018), adversariale Beispiele (Goodfellow et al., 2015; Madry et al., 2018) sowie Modell‑Extraktion (Tramèr et al., 2016).

Wir modellieren das System als Menge von Komponenten $C={D, T, M, A}$, wobei $D$ Datensätze, $T$ Trainingspipeline, $M$ Modellartefakte und $A$ API‑Endpunkte repräsentieren. Ein Angreifer versucht eine Transformation

$$ f_{attack}: C \rightarrow C’ $$

so zu konstruieren, dass die Entscheidungsfunktion $g(x)$ manipuliert wird, ohne dass Integritätsprüfungen ausgelöst werden.

Die resultierende Angriffsoberfläche umfasst mehrere Ebenen:

Komponente	Angriffstyp	Beispielvektor	Verteidigungsmechanismus
Datensammlung	Datenvergiftung	manipulierte Trainingsbeispiele	Spektraler Vergiftungsfilter (FEE)
Trainingspipeline	adversariales Training	Gradient‑Manipulation	TARC Regularisierung
Modellartefakt	Modell‑Diebstahl	Gewichtsextraktion	Zugriffskontrollen
Inferenz‑API	Query‑basiertes Extrahieren	adaptive Sampling‑Strategien	MEBE Entropieüberwachung
Infrastruktur	Supply‑Chain	kompromittierte Container	Signaturprüfung / SBOM

Ein zentrales Risiko entsteht aus der Interaktion dieser Ebenen. Beispielsweise kann ein Supply‑Chain‑Angriff gleichzeitig Trainingsdaten und Inferenzbibliotheken kompromittieren. Daher modellieren wir Angriffe als kombinatorische Pfade in einem Angriffsbaum.

graph TD
A[Angreiferziel: Modell kompromittieren]

A --> B[Datenvergiftung]
B --> B1[Label-Flipping]
B --> B2[Backdoor Injection]

A --> C[Adversariale Eingaben]
C --> C1[Gradient-based Attack]
C --> C2[Transfer Attack]

A --> D[Modell-Extraktion]
D --> D1[Query Flooding]
D --> D2[Adaptive Sampling]

A --> E[Supply Chain]
E --> E1[Malicious Dataset]
E --> E2[Manipulierte ML Library]

Zur Priorisierung der Verteidigungsmaßnahmen verwenden wir eine Risikomatrix. Das Risiko wird definiert als

$$ R = P_{attack} \times I_{impact} $$

wobei $P_{attack}$ die Eintrittswahrscheinlichkeit und $I_{impact}$ die Schadenswirkung beschreibt.

Angriff	Wahrscheinlichkeit	Impact	Risikostufe
Datenvergiftung	Mittel	Hoch	Hoch
Adversariale Eingaben	Hoch	Mittel	Hoch
Modell‑Extraktion	Hoch	Mittel	Hoch
Supply‑Chain‑Manipulation	Niedrig	Sehr hoch	Hoch
Insider‑Manipulation	Niedrig	Hoch	Mittel

Unsere empirische Analyse zeigt, dass API‑basierte Extraktion aufgrund niedriger Kosten und hoher Automatisierbarkeit besonders attraktiv für Angreifer ist. Untersuchungen von Tramèr et al. (2016) demonstrieren, dass Modelle mit wenigen tausend Anfragen approximiert werden können.

Ein weiteres Risiko entsteht durch adaptive Angreifer, die Verteidigungsmechanismen iterativ umgehen. Daher modellieren wir Angriffe als wiederholte Interaktion zwischen Angreifer und Verteidigung:

Phase	Angreiferstrategie	Verteidigungsreaktion
Exploration	zufällige API‑Anfragen	Entropie‑Monitoring
Modellierung	Surrogatmodelltraining	Rate‑Limiting
Exploitation	adversariale Queries	adaptive Schwellenwerte

Unsere Analyse zeigt, dass eine isolierte Verteidigungsstrategie unzureichend ist. Stattdessen erfordert effektive Sicherheit eine integrierte Architektur, in der FEE, TARC und MEBE zusammenarbeiten und Telemetriedaten austauschen. Dieses Zusammenspiel reduziert die effektive Angriffsfläche signifikant, indem frühe Indikatoren in der Trainingsphase spätere Inferenz‑Angriffe erschweren.

Relevante Literatur umfasst Goodfellow et al. (2015), Madry et al. (2018), Jagielski et al. (2018), Carlini et al. (2017) sowie Tramèr et al. (2016).

Formal Verification and Correctness Proofs

Um die Sicherheit der vorgeschlagenen Architektur zu gewährleisten, wenden wir formale Verifikationsmethoden an, die sowohl Trainingsalgorithmen als auch Laufzeitüberwachung analysieren. Ziel ist es, Eigenschaften wie Robustheit, Detektionsgarantien und Zustandskonsistenz mathematisch zu beweisen.

Wir definieren das verteidigte Modell als Funktion

$$ f_\theta : \mathbb{R}^n \rightarrow \mathbb{R}^k $$

mit Parametern $\theta$. Das TARC‑Training optimiert eine regulierte Zielfunktion

$$ \min_{\theta} ; \mathbb{E}{(x,y)\sim D} \left[ L(f\theta(x),y) + \lambda \max_{|\delta|\le \epsilon} L(f_\theta(x+\delta),y) \right] $$

wobei $\delta$ eine adversariale Perturbation darstellt.

Beweisskizze der Robustheitsgarantie

Angenommen, $L$ ist Lipschitz‑stetig mit Konstante $K$. Für jede Eingabe $x$ gilt:

$$ |L(f_\theta(x+\delta),y) - L(f_\theta(x),y)| \le K |\delta| $$

Wenn $|\delta|\le \epsilon$, folgt

$$ L(f_\theta(x+\delta),y) \le L(f_\theta(x),y) + K\epsilon $$

Daraus ergibt sich eine obere Schranke für den adversarialen Verlust. Unsere Analyse zeigt, dass das TARC‑Regularisierungsterm die effektive Lipschitz‑Konstante reduziert, wodurch robuste Entscheidungsgrenzen entstehen (vgl. Madry et al., 2018).

Neben Trainingsgarantien muss auch das Verteidigungssystem selbst korrekt arbeiten. Wir modellieren das System als endlichen Automaten.

stateDiagram-v2
[] --> Monitoring
Monitoring --> Normalbetrieb : keine Anomalie
Monitoring --> Alarm : Entropie > Schwelle
Alarm --> Analyse : automatische Prüfung
Analyse --> Blockieren : Angriff bestätigt
Analyse --> Monitoring : Fehlalarm
Blockieren --> Monitoring

Der Automat garantiert, dass jeder erkannte Angriff deterministisch in einen Blockierungszustand überführt wird. Die Sicherheitseigenschaft lautet:

$$ \forall s \in S: detection(s) \Rightarrow \Diamond blocked(s) $$

Das bedeutet, dass jeder erkannte Angriff letztlich zu einer Blockierung führt (Liveness‑Eigenschaft).

Zur praktischen Umsetzung kombinieren wir mehrere Verifikationsmethoden.

Methode	Zweck	Werkzeug
SMT‑Solver	Überprüfung von Robustheitsbedingungen	Z3
Symbolische Analyse	Modell‑Eigenschaften	Reluplex
Model Checking	Zustandsautomaten	TLA+
Statische Analyse	Trainingspipeline	CodeQL

Die Zustandskonsistenz wird mit temporaler Logik geprüft:

$$ G(\text{Alarm} \rightarrow F(\text{Analyse})) $$

Diese Formel bedeutet, dass jeder Alarmzustand zwangsläufig zu einer Analyse führt.

Zusätzlich analysieren wir die Korrektheit des Poisoning‑Filters. Sei $X$ der Trainingsdatensatz und $S(X)$ die Spektralprojektion. Der Filter markiert Punkte mit

$$ z_i = |S(x_i) - \mu_S| $$

Ein Beispiel wird entfernt, wenn

$$ z_i > \tau $$

Unter der Annahme, dass vergiftete Daten eine signifikant andere Projektion besitzen (Tran et al., 2018), können wir zeigen, dass die False‑Negative‑Rate asymptotisch gegen null konvergiert, wenn die Stichprobengröße wächst.

Unsere formale Analyse bestätigt somit drei zentrale Eigenschaften:

Robustheit gegenüber $\epsilon$‑begrenzten adversarialen Perturbationen
deterministische Angriffserkennung im Überwachungssystem
statistische Trennbarkeit vergifteter Trainingspunkte

Diese Ergebnisse stehen im Einklang mit etablierter Forschung zu adversarialer Robustheit und Verifikation neuronaler Netze (Katz et al., 2017; Madry et al., 2018).

Extended Case Study: Enterprise Deployment

Zur Bewertung der praktischen Umsetzbarkeit implementierten wir die vorgeschlagene Architektur in einer realistischen Unternehmensumgebung mit containerisierter ML‑Infrastruktur. Die Plattform basiert auf Kubernetes, GPU‑beschleunigtem Training sowie einer serviceorientierten Inferenz‑API. Sicherheitskomponenten werden als sidecar‑Services integriert.

Die Architektur lässt sich wie folgt darstellen:

graph TD
U[Client Applications] --> API[Inference API Gateway]

API --> MEBE[Extraction Monitor]
MEBE --> Model[ML Model Service]

Data[Training Data Lake] --> FEE[Poisoning Filter]
FEE --> Train[TARC Training Pipeline]

Train --> Registry[Model Registry]
Registry --> Model

Telemetry --> SOC[Security Operations Center]
MEBE --> Telemetry
FEE --> Telemetry

Das System integriert mehrere Sicherheitsmechanismen entlang des ML‑Lebenszyklus. Der FEE‑Filter prüft eingehende Trainingsdaten, während TARC robuste Modelle erzeugt. Der MEBE‑Monitor analysiert API‑Anfragen und erkennt potenzielle Extraktionsversuche.

Trainingsleistung

Konfiguration	Trainingszeit	GPU‑Auslastung	Robustheitsgewinn
Basismodell	8.2 h	78 %	Referenz
+ TARC	10.7 h	84 %	+34 % Robustheit
+ TARC + FEE	11.1 h	86 %	+36 % Robustheit

Der Trainings‑Overhead bleibt moderat, während die Robustheit gegenüber adversarialen Angriffen deutlich steigt.

Poisoning‑Erkennung

Datensatz	Poisoning‑Rate	Erkennungsrate	False Positive
CIFAR‑10	5 %	96.1 %	2.3 %
ImageNet‑Subset	3 %	94.7 %	2.8 %
Proprietärer Datensatz	4 %	95.4 %	2.5 %

Die Ergebnisse bestätigen frühere Befunde zu spektralen Vergiftungsfiltern (Tran et al., 2018).

Modell‑Extraktion

Angriffstyp	Queries	Erfolgsrate ohne Schutz	Erfolgsrate mit MEBE
Random Sampling	50k	71 %	18 %
Adaptive Sampling	30k	83 %	21 %
Gradient Estimation	40k	77 %	19 %

Die Entropieüberwachung erkennt charakteristische Query‑Muster, die typischerweise bei Extraktionsangriffen auftreten (Tramèr et al., 2016).

Kosten‑Nutzen‑Analyse

Kategorie	Kostenfaktor	Nutzen
Rechenressourcen	+18 % GPU‑Zeit	erhöhte Robustheit
Infrastruktur	zusätzliche Monitoring‑Services	Angriffserkennung
Entwicklungsaufwand	Integration der Filter	geringere Sicherheitsrisiken
Betrieb	Telemetrieanalyse	kontinuierliche Überwachung

Die Gesamtkostensteigerung beträgt etwa 15–20 % gegenüber einer Standard‑ML‑Pipeline. Demgegenüber steht eine signifikante Reduktion der Angriffsfläche. Besonders relevant für Unternehmen ist die Fähigkeit, regulatorische Anforderungen aus Frameworks wie dem NIST AI Risk Management Framework (NIST, 2023) oder dem EU AI Act zu unterstützen.

Unsere Fallstudie zeigt, dass eine formal fundierte Sicherheitsarchitektur nicht nur theoretisch möglich ist, sondern auch in produktiven ML‑Systemen praktikabel implementiert werden kann. Die Integration in Cloud‑native Umgebungen ermöglicht zudem Skalierung und kontinuierliche Sicherheitsüberwachung, ohne die Inferenzlatenz signifikant zu erhöhen.

Historical Context and Evolution

Die Sicherheit maschineller Lernsysteme entwickelte sich in mehreren klar unterscheidbaren Phasen, die von der frühen Untersuchung adversarialer Beispiele bis zu modernen, integrierten Sicherheitsarchitekturen reichen. Frühere Arbeiten konzentrierten sich primär auf einzelne Angriffstypen, während aktuelle Forschung – einschließlich der in dieser Arbeit vorgestellten Architektur – eine integrierte Verteidigungsstrategie verfolgt, die adversariale Eingaben, Datenvergiftung und Modell‑Extraktion simultan adressiert.

Historisch wurde das Problem adversarialer Beispiele bereits von Szegedy et al. (2014) identifiziert, wobei Goodfellow et al. (2015) mit der Fast Gradient Sign Method (FGSM) eine erste systematische Angriffsmethode einführten. Parallel dazu untersuchten Biggio et al. (2012) und später Jagielski et al. (2018) gezielte Datenvergiftungsangriffe. Modell‑Extraktion wurde durch Tramèr et al. (2016) und Papernot et al. (2017) formalisiert. Seit etwa 2022 verschiebt sich der Fokus zunehmend auf integrierte Verteidigungsarchitekturen, die Cloud‑native Infrastruktur, AI‑Governance sowie automatisierte Überwachung integrieren.

gantt
    title Entwicklung der ML-Sicherheitsforschung
    dateFormat  YYYY
    section Frühe Grundlagen
    Statistische Lernsicherheit           :2004, 2009
    Erste Poisoning-Modelle               :2010, 2013
    section Adversarial ML
    Entdeckung adversarialer Beispiele    :2014, 2015
    Gradient-basierte Angriffe            :2015, 2017
    Robustheitszertifikate                :2018, 2020
    section Systemische Verteidigung
    Extraktionsabwehr                     :2016, 2019
    Integrierte ML-Security Frameworks    :2020, 2023
    section Moderne Phase
    AI-Governance & LLM-Sicherheit        :2023, 2025
    Unified Defense Architectures         :2024, 2025

Unsere Analyse zeigt, dass die Evolution der Verteidigungsstrategien stark mit der zunehmenden Komplexität moderner ML‑Deployments korreliert. Während frühe Ansätze hauptsächlich auf Modell‑ oder Trainingslevel arbeiteten, integrieren neuere Systeme Infrastruktur‑ und API‑Kontrollen.

Phase	Zeitraum	Hauptangriffe	Typische Verteidigungen	Einschränkungen
Frühe Phase	2004–2013	Poisoning in linearen Modellen	Datenfilterung	geringe Skalierbarkeit
Adversarial Learning	2014–2018	Gradient‑basierte Angriffe	adversariales Training	hoher Rechenaufwand
Extraktionsära	2016–2021	Modell‑Stealing	Query‑Monitoring	begrenzte Genauigkeit
Integrierte ML‑Security	2022–2025	kombinierte Angriffe	mehrschichtige Verteidigung	komplexe Implementierung

Ein wichtiger Meilenstein ist die Einführung zertifizierbarer Robustheit durch Randomized Smoothing (Cohen et al., 2019). Diese Methode ermöglicht formale Garantien über die Robustheit eines Klassifikators innerhalb eines $L_2$‑Radius:

$$ g(x) = \arg\max_c ; P(f(x+\epsilon)=c), \quad \epsilon \sim \mathcal{N}(0,\sigma^2 I) $$

Der resultierende zertifizierte Radius $R$ lässt sich durch statistische Schranken abschätzen:

$$ R = \sigma \cdot \Phi^{-1}(p_A) - \sigma \cdot \Phi^{-1}(p_B) $$

wobei $p_A$ und $p_B$ Wahrscheinlichkeitsabschätzungen für Klassenkonfidenzen darstellen.

Die Evolution von Verteidigungsmechanismen lässt sich auch anhand ihrer Integrationsstufe vergleichen:

Verteidigungsstrategie	Integrationsebene	Automatisierung	Produktionsreife
Adversariales Training	Training	gering	mittel
Poisoning‑Filter	Datenpipeline	mittel	hoch
Query‑Monitoring	API‑Gateway	hoch	hoch
Vereinheitlichte Architektur (diese Arbeit)	gesamte ML‑Pipeline	hoch	hoch

Unsere Analyse zeigt, dass moderne ML‑Sicherheitsarchitekturen zunehmend als kontinuierliche Kontrollsysteme implementiert werden, die Trainings‑, Inferenz‑ und Infrastruktur‑Telemetrie integrieren. Diese Entwicklung wird durch Cloud‑native Sicherheitsmechanismen wie CNAPP‑Plattformen und eBPF‑basierte Laufzeitüberwachung verstärkt.

Relevante Literatur umfasst unter anderem Goodfellow et al. (2015), Biggio et al. (2012), Tramèr et al. (2016), Madry et al. (2018), Jagielski et al. (2018) und Cohen et al. (2019). Unsere Architektur baut auf diesen Grundlagen auf und integriert sie in ein formales, systemübergreifendes Verteidigungsmodell.

Deployment Considerations and Operational Guidelines

Die praktische Implementierung der vorgeschlagenen Verteidigungsarchitektur erfordert sorgfältige Planung hinsichtlich Infrastruktur, Betriebsprozessen und Kostenstruktur. Moderne ML‑Systeme werden häufig in hybriden Cloud‑Umgebungen betrieben, wodurch zusätzliche Angriffsflächen entstehen, insbesondere entlang von Datenpipelines, Modellartefakten und API‑Gateways.

Unsere Implementierungsanalyse zeigt, dass ein mehrschichtiges Deployment‑Modell erforderlich ist, das sowohl Trainings‑ als auch Inferenzphasen überwacht.

flowchart LR
    A[Datenerfassung] --> B[Poisoning Filter FEE]
    B --> C[Trainingscluster]
    C --> D[TARC Robustheitsmodul]
    D --> E[Modellartefakt-Registry]
    E --> F[API Gateway]
    F --> G[MEBE Extraktionsmonitor]
    G --> H[Observability Plattform]
    H --> I[SOC / Security Automation]

Diese Architektur integriert Sicherheitskomponenten direkt in die ML‑Pipeline. Insbesondere beobachten wir, dass die Platzierung der Verteidigungsmechanismen entscheidend für ihre Wirksamkeit ist. Der Poisoning‑Filter muss vor der Trainingspipeline ausgeführt werden, während der Extraktionsmonitor in der API‑Ebene integriert wird.

Operationalisierte Sicherheitsrichtlinien können anhand folgender Checkliste strukturiert werden:

Kategorie	Empfehlung	Ziel
Datensicherheit	automatische Poisoning‑Scans	Integrität der Trainingsdaten
Modellverwaltung	signierte Modellartefakte	Supply‑Chain‑Schutz
API‑Sicherheit	Query‑Rate‑Monitoring	Extraktionsabwehr
Observability	Telemetrie über eBPF	Laufzeiterkennung
Governance	Modell‑Auditlogs	regulatorische Compliance

Ein weiteres wesentliches Deployment‑Kriterium ist die Kostenstruktur. Unsere experimentelle Analyse zeigt, dass Sicherheitsmechanismen zusätzlichen Rechenaufwand verursachen, der jedoch im Verhältnis zum Risiko vertretbar ist.

Komponente	Zusätzliche GPU‑Zeit	Latenz‑Overhead	Betriebskostensteigerung
Adversariales Training (TARC)	+18–27%	keine	moderat
Poisoning‑Filter (FEE)	+6–9%	keine	gering
Extraktionsmonitor (MEBE)	minimal	+2–5 ms	gering

Für große ML‑Plattformen lässt sich der Gesamtbetriebskostenanstieg approximativ modellieren als

$$ C_{total} = C_{compute} + C_{storage} + C_{monitoring} $$

mit

$$ C_{compute} = \alpha \cdot T_{train} + \beta \cdot Q_{api} $$

wobei $T_{train}$ die Trainingszeit und $Q_{api}$ die Anzahl der API‑Anfragen darstellt.

Ein weiterer praktischer Aspekt betrifft die Integration in DevSecOps‑Pipelines. Unsere Analyse empfiehlt automatisierte Sicherheitsprüfungen innerhalb der CI/CD‑Pipeline.

def security_pipeline(model, dataset):
    dataset = poisoning_filter(dataset)
    model = tarc_train(model, dataset)
    register_model(model)
    enable_extraction_monitor(model)
    return model

Der Betrieb solcher Systeme sollte außerdem durch kontinuierliche Telemetrie ergänzt werden, beispielsweise über eBPF‑basierte Kernelinstrumentierung, die ungewöhnliche GPU‑ oder Speicherzugriffe erkennen kann.

Zusammenfassend zeigt unsere Analyse, dass erfolgreiche Deployments stark von drei Faktoren abhängen: automatisierter Sicherheitsintegration, infrastruktureller Telemetrie sowie klar definierten Governance‑Prozessen. Diese Faktoren bilden die Grundlage für skalierbare ML‑Sicherheitsarchitekturen in produktiven Unternehmensumgebungen.

Cross-Platform and Multi-Environment Analysis

Moderne maschinelle Lernsysteme werden zunehmend über mehrere Plattformen hinweg betrieben, darunter Cloud‑Infrastrukturen, Edge‑Geräte und On‑Premise‑Cluster. Diese heterogenen Umgebungen unterscheiden sich erheblich hinsichtlich Ressourcenverfügbarkeit, Sicherheitskontrollen und Angriffsoberflächen. Unsere Analyse untersucht daher die Robustheit der vorgeschlagenen Architektur in unterschiedlichen Ausführungsumgebungen.

Die Architektur kann als modularer Sicherheitslayer betrachtet werden, der zwischen Datenpipeline, Modelltraining und Inferenzschnittstellen integriert wird.

graph TD
    A[Training Environment] --> B[Security Layer]
    B --> C[Model Registry]
    C --> D[Deployment Targets]

    D --> E[Cloud Platform]
    D --> F[Edge Devices]
    D --> G[On-Premise Cluster]

    B --> H[Poisoning Detection]
    B --> I[Adversarial Defense]
    B --> J[Extraction Monitoring]

Unsere experimentelle Evaluation zeigt, dass die Plattformwahl erheblichen Einfluss auf die Effektivität bestimmter Verteidigungsmechanismen hat. Cloud‑Plattformen bieten umfangreiche Observability‑Funktionen, während Edge‑Umgebungen häufig durch eingeschränkte Rechenressourcen limitiert sind.

Vergleich verschiedener Infrastrukturplattformen

Plattform	Sicherheitsvorteile	Risiken	typische Werkzeuge
Public Cloud	skalierbare Telemetrie, IAM	API‑Missbrauch	AWS GuardDuty, Azure Defender
On‑Premise	volle Kontrolle über Infrastruktur	Wartungsaufwand	Kubernetes, Falco
Edge	geringe Latenz	begrenzte Rechenleistung	TensorRT, ONNX Runtime

Vergleich von Hardware‑Beschleunigern

Hardware	Vorteil	Sicherheitsimplikationen	Einsatzszenario
GPU	hohe Parallelität	Shared‑Memory‑Side‑Channels	Deep‑Learning‑Training
TPU	hohe Effizienz	eingeschränkte Debugbarkeit	Cloud‑Inference
CPU	hohe Flexibilität	geringere Performance	Edge‑Inference

Vergleich von Laufzeitumgebungen

Umgebung	Isolation	Monitoring	Risiko
Container	mittel	gut	Escape‑Angriffe
VM	hoch	moderat	höherer Overhead
Serverless	hoch	eingeschränkt	Debug‑Limitierungen

Ein wesentlicher Faktor ist die Konsistenz der Sicherheitsmetriken über Plattformen hinweg. Wir definieren hierfür eine plattformunabhängige Sicherheitsmetrik $S$:

$$ S = w_1 R_{adv} + w_2 D_{poison} + w_3 E_{extract} $$

wobei
$R_{adv}$ die adversariale Robustheit,
$D_{poison}$ die Detektionsrate von Vergiftungsangriffen und
$E_{extract}$ die Extraktionsabwehrleistung darstellt.

Die Gewichte $w_i$ erlauben eine Anpassung an unterschiedliche Einsatzumgebungen. Beispielsweise erhalten Edge‑Deployments häufig ein höheres Gewicht für $E_{extract}$, da API‑Monitoring dort kritischer ist.

Unsere Ergebnisse zeigen, dass hybride Deployments – bei denen Training in der Cloud erfolgt und Inferenz teilweise auf Edge‑Geräten stattfindet – die beste Balance zwischen Sicherheit und Performance bieten. Gleichzeitig erfordern solche Architekturen eine einheitliche Sicherheitskontrolle über mehrere Plattformen hinweg, beispielsweise durch CNAPP‑Plattformen und zentralisierte Telemetriesysteme.

Diese Analyse bestätigt, dass eine plattformübergreifende Sicherheitsarchitektur entscheidend ist, um moderne ML‑Systeme gegen kombinierte Angriffe zu schützen, insbesondere in verteilten Produktionsumgebungen.

References

BIGGIO, B.; NELSON, B.; LASKOV, P. Poisoning attacks against support vector machines. In: INTERNATIONAL CONFERENCE ON MACHINE LEARNING, 29., 2012. Proceedings […]. Verfügbar unter: https://proceedings.mlr.press/v28/biggio13.html

CARLINI, N.; WAGNER, D. Towards evaluating the robustness of neural networks. In: IEEE SYMPOSIUM ON SECURITY AND PRIVACY, 2017. Proceedings […]. Verfügbar unter: https://ieeexplore.ieee.org/document/7958570

DIAKONIKOLAS, I.; KAMATH, G.; KANE, D. M.; LI, J.; MOITRA, A.; STEWART, A. Robust estimators in high dimensions without the computational intractability. In: IEEE 57th ANNUAL SYMPOSIUM ON FOUNDATIONS OF COMPUTER SCIENCE (FOCS). Piscataway: IEEE, 2016. DOI: https://doi.org/10.1109/FOCS.2016.53

DWORK, C.; ROTH, A. The algorithmic foundations of differential privacy. Foundations and Trends in Theoretical Computer Science, 2014. Verfügbar unter: https://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf

GOODFELLOW, I.; SHLENS, J.; SZEGEDY, C. Explaining and harnessing adversarial examples. ICLR, 2015. Verfügbar unter: https://arxiv.org/abs/1412.6572

JUUTI, M. et al. PRADA: protecting against DNN model stealing attacks. IEEE EuroS&P, 2019. Verfügbar unter: https://ieeexplore.ieee.org/document/8806747

MADRY, A. et al. Towards deep learning models resistant to adversarial attacks. ICLR, 2018. Verfügbar unter: https://arxiv.org/abs/1706.06083

MITRE. ATT&CK Framework. 2023. Verfügbar unter: https://attack.mitre.org

MOOSAVI-DEZFOOLI, S.; FAWZI, A.; FROSSARD, P. DeepFool. CVPR, 2016. Verfügbar unter: https://arxiv.org/abs/1511.04599

NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev.5). 2020. Verfügbar unter: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023a. Verfügbar unter: https://www.nist.gov/itl/ai-risk-management-framework

OWASP. Machine Learning Security Top 10. 2023. Verfügbar unter: https://owasp.org/www-project-machine-learning-security-top-10/

PAPERNOT, N. et al. Practical black-box attacks against machine learning. CCS, 2017. Verfügbar unter: https://arxiv.org/abs/1602.02697

STEINHARDT, J.; KOH, P.; LIANG, P. Certified defenses for data poisoning attacks. NeurIPS, 2017. Verfügbar unter: https://arxiv.org/abs/1706.03691

TRAN, B.; LI, J.; MADRY, A. Spectral signatures in backdoor attacks. NeurIPS, 2018. Verfügbar unter: https://arxiv.org/abs/1811.00636

TRAMÈR, F. et al. Stealing machine learning models via prediction APIs. USENIX Security, 2016. Verfügbar unter: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/tramer