LF-KI-Sicherheit

Dieses Leitfaden beschreibt technische Maßnahmen zur Absicherung von KI-Systemen im ISMS-Kontext. Es adressiert Lücken in der Umsetzung von EU AI Act (Art. 15, 13), BSI Grundschutz und ISO 27001 A.8.25ff. Die Maßnahmen gewährleisten Robustheit gegen Angriffe, Modellschutz und prüfbare Nachverfolgbarkeit. Sie sind für Hochrisiko-KI-Systeme zwingend erforderlich, um Haftungsrisiken zu minimieren und Audits zu bestehen.

Einleitung

Künstliche Intelligenz (KI) birgt erhebliche Sicherheitsrisiken, die durch den EU AI Act und nationale Standards wie BSI Grundschutz adressiert werden müssen. Dieser Leitfaden beschreibt die technischen Maßnahmen zu KI-Härtung, Modellsicherheit und Nachvollziehbarkeit, die für den sicheren Einsatz von KI-Systemen im Unternehmen zwingend erforderlich sind.

Zielgruppe: IT-Sicherheitsverantwortliche, Data Scientists und ISMS-Beauftragte.

Sinn und Zweck: Bereitstellung implementierbarer und prüfbarer Maßnahmen zur Erfüllung von EU AI Act Art. 12-15, Konformität mit ISO 27001 und Vermeidung von Haftungsrisiken. Die Maßnahmen ermöglichen Audits, schützen vor Angriffen und gewährleisten die Nachverfolgbarkeit kritischer Entscheidungen.

Die nachfolgenden Kapitel leiten direkt aus den gesetzlichen Pflichten ab und enthalten konkrete Umsetzungsschritte mit Prüfkriterien.

Rechtliche Grundlagen und Pflichten

Die Maßnahmen basieren auf zwingenden Anforderungen des EU AI Act und nationaler Standards:

• EU AI Act Art. 15 (Hochrisiko-KI): Robustheit gegen Angriffe, Cybersicherheit, Härte-Maßnahmen.
• EU AI Act Art. 13: Transparenzpflichten inklusive technischer Dokumentation und Nachvollziehbarkeit.
• EU AI Act Art. 12: Qualitätsmanagement mit Risikobewertung und Auditfähigkeit (10-Jahre-Dokumentation).

Ziel: Haftungsminimierung, Audits bestand, Konformität mit NIS2 und DSGVO.

KI-Härtung (Robustheit gegen Angriffe)

KI-Härtung schützt KI-Systeme vor manipulierenden Angriffen durch Erhöhung der Robustheit. Sie verhindert, dass Angreifer Modelle durch gezielte Eingaben (Prompt Injection, Adversarial Examples) umgehen oder gefährliche Ausgaben provozieren.

Input-Sanitization

Input-Sanitization filtert bösartige Eingaben vor der Modellverarbeitung. Sie blockiert Jailbreak-Versuche, SQL-Injection und Prompt Injections, die Modelle zu unzulässigen Antworten zwingen. Erforderlich durch EU AI Act Art. 15 (Robustheit).

Best-Practice-Umsetzung:

• Bibliothek llm-guard oder neural-classifier für Input-Vorfilterung.
• Regex-Regeln für bekannte Angriffsmuster (ignore previous instructions, sudo, Base64-Payloads).
• Whitelisting erlaubter Zeichenmengen (alphanumerisch + begrenzte Sonderzeichen).
• Implementierung als Middleware (FastAPI/Flask): request.input = sanitize(request.input).

Rate Limiting

Begrenzt API-Aufrufe pro Benutzer/IP, um Denial-of-Service (DoS) und Brute-Force-Angriffe zu verhindern. Schützt Rechenressourcen und ermöglicht Anomalie-Erkennung.

Best-Practice-Umsetzung:

• Redis-basiertes Sliding-Window-Limiting: 100 Requests/Stunde pro User-ID/IP.
• Framework-Integration: FastAPI-Limiter (slowapi), Django-RateLimit.
• Headers setzen: X-RateLimit-Remaining, Retry-After.
• Monitoring: Prometheus-Metriken für Rate-Limit-Hits.

Output-Moderation

Prüft Modell-Ausgaben auf Toxizität, Hate Speech oder sensible Datenlecks vor Auslieferung. Verhindert rechtliche Haftung durch schädliche Inhalte.

Best-Practice-Umsetzung:

• OpenAI Moderation API oder HuggingFace unitary/toxic-bert.
• Kategorien: Hate, Violence, Self-Harm, PII (Personendaten).
• Block-Regel: Score > 0.7 → Antwort verweigern mit "Inhalt nicht zulässig".
• Fallback: Statische Regex für Kreditkarten/SVNr.

Adversarial Training

Trainiert Modelle mit feindlichen Beispielen, sodass sie Angriffe erkennen und abwehren. Erhöht Robustheit gegen OWASP LLM Top 10-Attacken.

Best-Practice-Umsetzung:

• Dataset: OWASP LLM Top 10 + Anthropic Red-Team-Dataset.
• Fine-Tuning: LoRA-Adapter auf bestehendem Modell (1-2% zusätzlicher VRAM).
• Metriken: Attack Success Rate (ASR) <5% nach Training.
• Tools: trl (Transformers Reinforcement Learning), adversarial-robustness-toolbox.

Container-Härtung

Sichert den KI-Deploy-Container gegen Privilege Escalation und Side-Channel-Angriffe. Entspricht CIS Docker Benchmarks.

Best-Practice-Umsetzung:

• Non-root User (USER 1000:1000 im Dockerfile).
• AppArmor/SELinux-Profil für KI-Prozess.
• Read-only Root-Filesystem (--read-only bei docker run).
• Seccomp-Filter: Nur read/write/socket erlauben.
• Image-Scan: Trivy vor Deploy.

Prüfkriterien und Prüfungsmodalitäten für KI-Härtung

Übergeordnetes Kriterium: Sicherheits-Test durch externe Experten mit weniger als 5% Angriffserfolg über alle Maßnahmen.

Input-Sanitization – Prüfkriterium und Umsetzung

Kriterium: 95% der bekannten gefährlichen Eingaben werden erkannt und blockiert.

Prüfungsmodalitäten:

1. Test-Suite: 500+ Angriffsvektoren (DAN-Jailbreaks, Base64-Payloads, Unicode-Exploits)
2. Tool: llm-attacks oder garak (automatisierte Tests)
3. Erfolg: Blockquote ≥95%, False-Positive-Rate <1%
4. Dokumentation: Test-Report mit Pass/Fail pro Vektor

Umsetzung: Wöchentlicher Test mit bekannten Angriffsmustern → Bericht per E-Mail.

Rate Limiting – Prüfkriterium und Umsetzung

Kriterium: Kein Benutzer kann mehr als 100 Anfragen pro Stunde stellen.

Prüfungsmodalitäten:

1. Load-Test: Apache Bench (ab -n 200 -c 10)
2. Überprüfung: Redis-Keys `ratelimit:ip:X` TTL ≤3600s
3. Response: HTTP 429 mit Retry-After Header bei Überschreitung
4. Metriken: Prometheus `ratelimit_hits_total > 0`

Umsetzung: Monatliche Lasttests mit Tools wie Apache Bench.

Output-Moderation – Prüfkriterium und Umsetzung

Kriterium: 98% der gefährlichen Antworten werden erkannt.

Prüfungsmodalitäten:

1. Dataset: HuggingFace "unitary/toxic-bert" Testset (10.000 Samples)
2. Threshold: F1-Score ≥0.95 bei Hate/Violence/Self-Harm
3. Audit: 100% manuelle Stichprobe kritischer Outputs
4. Log: Moderation-Ergebnisse 90 Tage auffindbar

Umsetzung: Vierteljährliche Tests mit öffentlichen Test-Datensätzen.

Adversarial Training – Prüfkriterium und Umsetzung

Kriterium: Angriffe gelingen in weniger als 5% der Fälle nach Training.

Prüfungsmodalitäten:

1. Benchmark: OWASP LLM Top 10 + Anthropic Red-Team (1.000 Angriffe)
2. Metrik: ASR = erfolgreiche Angriffe / Gesamtangriffe
3. Baseline-Vergleich: Vorher/Nachher ASR-Differenz ≥80%
4. Periodisch: Quartalsweise Re-Test nach Modell-Updates

Umsetzung: Automatisierte Tests nach jedem Modell-Update.

Container-Härtung – Prüfkriterium und Umsetzung

Kriterium: Container erfüllt 30+ Sicherheitsregeln (Docker-Standard).

Prüfungsmodalitäten:

1. Scan: Trivy `trivy image ki-app:latest` → 0 Criticals
2. Runtime: `docker-bench-security` → ≥95% Compliance
3. Prozess: `ps aux | grep ki-app` → non-root User
4. Netzwerk: `docker inspect` → No privileged ports (<1024)

Umsetzung: Wöchentliche automatische Scans aller Container.

Übergeordnete Sicherheitsprüfung

Empfehlenswert ist ein regelmäßiger Prüf- und Auditzyklus z.B.: interne monatliche oder quartalsmäßige Prüfung und jährliche externe Prüfung

Alle Testergebnisse 10 Jahre aufbewahren (gesetzliche Pflicht EU AI Act).

Modellsicherheit (Integritätsschutz)

Modellsicherheit schützt das trainierte KI-Modell vor Diebstahl, Manipulation und unbefugter Nutzung während des gesamten Lebenszyklus.

Model Cards

Model Cards sind standardisierte Dokumente, die Architektur, Trainingsdaten, Leistung und Risiken des Modells beschreiben. Sie ermöglichen Transparenz und sind für Audits erforderlich (EU AI Act Art. 13).

Best-Practice-Umsetzung:

• Vorlage nach HuggingFace-Standard verwenden
• Inhalte: Modelltyp, Parameteranzahl, Trainingsdatenmenge, Bias-Metriken
• Automatische Generierung mit Tools wie model-card-toolkit
• Im Versionskontrollsystem (Git) als Markdown-Datei speichern

Integritätsprüfung

Überprüft vor jeder Nutzung, ob das Modell manipuliert wurde. Verhindert Einsatz beschädigter oder vergifteter Modelle.

Best-Practice-Umsetzung:

• SHA-256-Hash des Originalmodells berechnen und signieren
• Vor Inference: Hash vergleichen → bei Abweichung Notfall-Stopp
• Digitale Signatur mit GPG oder Hardware Security Module (HSM)
• Automatisierte Prüfung als Docker-Entry-Point-Script

Output-Watermarking

Fügt unsichtbare Markierungen in KI-Ausgaben ein, um deren Herkunft nachzuweisen. Schützt vor Missbrauch und Plagiat.

Best-Practice-Umsetzung:

• Token-basierte Watermarks (OpenAI-Methode): Spezielle Token-Wahrscheinlichkeiten
• Text-Watermarking: Synonyme-Ersetzung nach festem Muster
• Bild-Watermarking: LSB-Steganographie (Least Significant Bit)
• Detektions-Tool parallel bereitstellen

Differential Privacy

Verhindert, dass einzelne Trainingsdaten aus Modell-Ausgaben rekonstruiert werden können. Schützt personenbezogene Daten (DSGVO).

Best-Practice-Umsetzung:

• Training mit DP-SGD (Differential Privacy Stochastic Gradient Descent)
• Privacy Budget ε=1.0 (Branchenstandard)
• Bibliothek: Opacus (PyTorch) oder TensorFlow Privacy
• Privacy-Audit: Membership Inference Attack Tests

SBOM (Software Bill of Materials)

Vollständige Liste aller Komponenten des KI-Systems für Supply-Chain-Sicherheit. Ermöglicht Schwachstellen-Management.

Best-Practice-Umsetzung:

• CycloneDX-Format für Python/ML-Umgebungen
• Automatische Generierung: cyclonedx-py oder GitHub Dependency Graph
• Dependency-Scan: Snyk/Trivy vor Deploy
• Versionspflicht: Jede Komponente mit exakter Versionsnummer

Prüfkriterien und Prüfungsmodalitäten für Modellsicherheit

Übergeordnetes Kriterium: 100% der Modelle sind vollständig dokumentiert und integritätsgesichert.

Model Cards – Prüfkriterium und Umsetzung

Kriterium: Jede Modellversion hat vollständige Model Card (10+ Kategorien).

Prüfungsmodalitäten:

1. Vollständigkeits-Check: Checkliste mit Pflichtfeldern
2. Aktualität: Model Card ≤ 3 Monate alt
3. Qualität: Techniker können Modell aus Card reproduzieren
4. Audit: Jährliche Stichprobe 20% aller Model Cards

Umsetzung: Git-Hook blockiert Commits ohne Model Card.

Integritätsprüfung – Prüfkriterium und Umsetzung

Kriterium: 100% Integritätsprüfung vor jeder Modellnutzung.

Prüfungsmodalitäten:

1. Log-Analyse: Alle Inference-Starts mit Hash-Check
2. Fehlerrate: 0 Integritätsfehler pro Monat
3. Recovery-Test: Manipuliertes Modell wird erkannt
4. Signatur-Validierung: GPG-Key korrekt

Umsetzung: Monatliche Log-Auswertung und Alarm bei Fehlern.

Output-Watermarking – Prüfkriterium und Umsetzung

Kriterium: 95% Detektionsrate bei Watermark-Prüfung.

Prüfungsmodalitäten:

1. Test-Suite: 1.000 Ausgaben mit/ohne Watermark
2. False-Positive-Rate: <1%
3. Robustheit: Watermark übersteht Copy-Paste/OCR
4. Dokumentation: Detektions-Tool verfügbar

Umsetzung: Wöchentliche Batch-Tests mit Testausgaben.

Differential Privacy – Prüfkriterium und Umsetzung

Kriterium: Privacy Budget ε ≤ 1.0 nach Training.

Prüfungsmodalitäten:

1. Privacy-Audit: Membership Inference Attack <5% Erfolg
2. ε-Berechnung: Auditor bestätigt korrekte Berechnung
3. Dokumentation: Training-Logs mit Privacy-Metriken
4. Zertifikat: Privacy-Bericht verfügbar

Umsetzung: Audit nach jedem Training.

SBOM – Prüfkriterium und Umsetzung

Kriterium: Vollständiger, aktueller SBOM für jedes KI-System.

Prüfungsmodalitäten:

1. Vollständigkeit: 100% aller Dependencies erfasst
2. Aktualität: SBOM ≤ 30 Tage alt
3. Schwachstellen: Keine Critical Vulnerabilities
4. Validierung: CycloneDX-Schema-Check

Umsetzung: CI/CD-Pipeline generiert SBOM automatisch.

Nachvollziehbarkeit (Traceability)

Nachvollziehbarkeit ermöglicht die Rekonstruktion jeder KI-Entscheidung für Audits und Vorfälle (EU AI Act Art. 12-13, 10-Jahre-Pflicht).

Vollständiges Inference-Logging

Protokolliert alle KI-Anfragen und Antworten vollständig. Ermöglicht Nachverfolgung von Fehlentscheidungen oder Missbrauch.

Best-Practice-Umsetzung:

• Log-Einträge: User-ID, Timestamp, Input, Output, Modell-Version, Rechenzeit
• JSON-Format mit strukturierten Feldern
• Speicherung in Elasticsearch oder PostgreSQL (append-only)
• Retention: 10 Jahre (gesetzlich vorgeschrieben)

End-to-End-Audit-Trails

Verknüpft alle Schritte einer KI-Entscheidung von der Eingabe bis zur finalen Ausgabe. Notwendig für Haftungsfragen.

Best-Practice-Umsetzung:

• MLflow oder Weights&Biases für Experiment-Tracking
• Jeder Inference-Request erhält eindeutige Request-ID
• Chain-of-Thought-Logging (Zwischenschritte des Modells)
• API: /audit/{request_id} für Nachverfolgung

Explainability für kritische Entscheidungen

Zeigt auf, warum das Modell eine bestimmte Entscheidung getroffen hat. Erforderlich bei Hochrisiko-Anwendungen.

Best-Practice-Umsetzung:

• SHAP/LIME für Feature Importance (wichtigste Einflussfaktoren)
• Bei Bild-KI: Grad-CAM Heatmaps
• Erklärung als Text + Grafik im Log speichern
• Nur für kritische Entscheidungen (Schwellenwert-basiert)

Versionskontrolle Modelle/Daten

Jede Entscheidung ist exakt einer Modell-/Daten-Version zuzuordnen. Verhindert "Wer hat welches Modell verwendet?"-Probleme.

Best-Practice-Umsetzung:

• DVC (Data Version Control) für Datasets und Modelle
• Git-Tags für Modell-Releases (v1.2.3)
• Jeder Log-Eintrag enthält model_hash und data_version
• Container-Images mit Digest (SHA-256)

SIEM-Integration und Anomalie-Erkennung

Erkennt ungewöhnliches KI-Verhalten automatisch und leitet Alarme ein. Erfüllt ISO 27001 Überwachungspflichten.

Best-Practice-Umsetzung:

• Logs in Splunk/ELK-Stack einspielen
• Anomalie-Detektoren: Zu viele Token, ungewöhnliche Anfragen, Spitzenzeiten
• Alerting: Slack/PagerDuty bei >10x normalem Verbrauch
• Dashboard mit KI-spezifischen Metriken

Prüfkriterien und Prüfungsmodalitäten für Nachvollziehbarkeit

Übergeordnetes Kriterium: Jede KI-Entscheidung vollständig nachvollziehbar innerhalb 24 Stunden.

Inference-Logging – Prüfkriterium und Umsetzung

Kriterium: 100% aller KI-Anfragen protokolliert (keine Lücken).

Prüfungsmodalitäten:

1. Log-Vollständigkeit: Request-Count vs. Log-Count = 100%
2. Format-Check: JSON-Schema-Validierung
3. Retention-Test: Daten aus 2025 abrufbar
4. Performance: Logging <50ms Overhead pro Request

Umsetzung: Täglicher Log-Completeness-Check per Cron-Job.

Audit-Trails – Prüfkriterium und Umsetzung

Kriterium: Request-ID Nachverfolgung von Input zu Output in <5 Sekunden.

Prüfungsmodalitäten:

1. End-to-End-Test: 100 zufällige Request-IDs prüfen
2. Chain-of-Thought: Zwischenschritte vollständig
3. Suchzeit: Elasticsearch Query <2s für 1 Jahr Daten
4. API-Test: /audit/{id} liefert vollständige Spur

Umsetzung: Monatliche Stichproben mit Zufalls-Request-IDs.

Explainability – Prüfkriterium und Umsetzung

Kriterium: 95% der kritischen Entscheidungen mit Erklärung versehen.

Prüfungsmodalitäten:

1. Abdeckung: Kritische Entscheidungen = Erklärungen
2. Qualität: Erklärung verständlich für Nicht-Experten
3. Performance: SHAP-Berechnung <2s pro Anfrage
4. Speicherung: Erklärungen 10 Jahre haltbar

Umsetzung: Wöchentliche Prüfung kritischer Logs.

Versionskontrolle – Prüfkriterium und Umsetzung

Kriterium: 100% der Logs enthalten korrekte Modell-/Daten-Version.

Prüfungsmodalitäten:

1. Hash-Validierung: model_hash existiert in Registry
2. Reproduzierbarkeit: Gleiches Modell = gleiche Ausgabe
3. Versions-Historie: 12 Monate rückverfolgbar
4. Daten-Integrität: DVC-Status clean

Umsetzung: Tägliche Validierung neuer Logs.

SIEM-Integration – Prüfkriterium und Umsetzung

Kriterium: Anomalien innerhalb 15 Minuten erkannt und eskaliert.

Prüfungsmodalitäten:

1. Alert-Test: Simulierte Anomalie → Alarm in <15min
2. False-Positive-Rate: <5 pro Woche
3. Dashboard: Alle KI-Metriken real-time sichtbar
4. Incident-Response: 95% Alarme innerhalb SLA bearbeitet

Umsetzung: Wöchentliche Anomalie-Simulationstests.

Verantwortlichkeiten

Die Maßnahmen erfordern eine klare Rollenverteilung über IT-Sicherheit, Entwicklung und Nutzung hinaus.

Auch Mitarbeitende tragen Mitverantwortung durch korrekte Bedienung und Meldung von Anomalien.

Rolle	Aufgaben	KPIs
CISO	ISMS-Integration, Audit-Planung	100% Konformität
Data Scientists	Model Cards, Training-Sicherheit	100% Modelle dokumentiert
IT-Admin	Logging, Container-Härtung	99,9% Logging-Verfügbarkeit
Datenschutzbeauftragte	DSGVO-Privacy (ε=1.0)	Privacy-Audits bestanden
Mitarbeitende	Nur erlaubte Nutzung, richtige Bedienung, Anomalien melden	95% korrekte Nutzung, 100% Incident-Meldung

Nächste Schritte: Integration in ISMS-Prozesse, erste Red-Team-Tests.

Umsetzung

Die Umsetzung erfolgt in vier Phasen mit klarer Priorisierung. Jede Phase baut auf der vorherigen auf und kann parallel mit begrenzten Ressourcen begonnen werden.

Phase 1: Sofortmaßnahmen (Grundschutz)

Diese Maßnahmen schützen innerhalb von Tagen vor den häufigsten Angriffen:

1. Input/Output-Filter aktivieren (llm-guard, Moderation API)
2. Logging-Infrastruktur aufsetzen (ELK/PostgreSQL, JSON-Format)
3. Rate Limiting implementieren (Redis, 100 Requests/Stunde)
4. Wartungsmodus für Tests definieren

Phase 2: Dokumentationspflicht

Erstellt die Audit-Grundlage für EU AI Act Konformität:

1. Model Cards für alle produktiven Modelle erstellen
2. SBOMs für KI-Systeme generieren (cyclonedx-py)
3. Versionskontrolle einrichten (DVC/Git für Modelle/Daten)
4. Integritätsprüfungen automatisieren (SHA-256 vor Inference)

Phase 3: Erweiterte Härte-Maßnahmen

Erhöht die Robustheit gegen komplexe Angriffe:

1. Adversarial Training für kritische Modelle (LoRA, OWASP Dataset)
2. Container-Härtung (non-root, AppArmor, Trivy Scans)
3. Differential Privacy bei neuen Trainings (Differential Privacy mit Branchenstandard ε=1.0)
4. Watermarking für Text/Bild-Outputs implementieren

Phase 4: Laufende Prüfung und Optimierung

Stellt dauerhafte Konformität sicher:

1. Automatisierte Tests einrichten (garak, docker-bench-security)
2. SIEM-Integration mit Anomalie-Erkennung (ELK + Alerts)
3. Erste interne Prüfung aller Maßnahmen durchführen
4. Externe Red-Team-Prüfung beauftragen (jährlich)

Monitoring:

• Wöchentliche Automatiktests mit Berichten
• Monatliche Stichproben der Logs
• Jährliche externe Validierung
• Alle Testergebnisse 10 Jahre archivieren (EU AI Act)

Fazit

Die beschriebenen Maßnahmen zu KI-Härtung, Modellsicherheit und Nachvollziehbarkeit bilden die technische Grundlage für konforme KI-Nutzung in Behörden oder Unternehmen. Sie erfüllen die zwingenden Anforderungen des EU AI Act (Art. 12-15) und des BSI Grundschutz, minimieren Haftungsrisiken und gewährleisten Auditfähigkeit.

Sofortige Umsetzung priorisieren:

1. Logging-Infrastruktur – schnellste Wirkung, geringer Aufwand
2. Input/Output-Filter – sofortiger Angriffsschutz
3. Model Cards für bestehende Modelle – Audit-Vorbereitung

Langfristig: Jährliche Red-Team-Tests und kontinuierliche Weiterentwicklung der Maßnahmen entsprechend neuer Bedrohungen (OWASP LLM Top 10 Updates).

Die Integration in bestehende ISMS-Prozesse schafft Wettbewerbsvorteile durch vertrauenswürdige KI und erfüllt regulatorische Pflichten gleichzeitig. Beginne mit dem Umsetzungsplan – die rechtlichen Fristen laufen.

Weiterführende Quellen

• BSI/ACS Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs)
• NIST AI Risk Management Framework (RMF 1.0)
• OWASP Top 10 für LLM-Applikationen (v 2025 de)