ISMS-Ratgeber WiKi - Letzte Änderungen [de]

Grundschutz++ Einführung und Aufbau

2026-04-05T09:00:54Z

Glossar

Grundschutz++

2026-04-04T03:07:50Z

Weiterführende Informationen

← Nächstältere Version		Version vom 4. April 2026, 05:07 Uhr
Zeile 36:		Zeile 36:
	* [[Grundschutz++ Einführung und Aufbau\|'''Grundschutz++ Einführung und Vorgehen''']]		* [[Grundschutz++ Einführung und Aufbau\|'''Grundschutz++ Einführung und Vorgehen''']]
	* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']		* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']
	* '''[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik]'''		* '''[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]'''
	* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]		* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
	* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]		* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]

Grundschutz++ Einführung und Aufbau

2026-04-04T03:06:46Z

Weiterführende Ressourcen

← Nächstältere Version		Version vom 4. April 2026, 05:06 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 347:		Zeile 347:
	== Weiterführende Ressourcen ==		== Weiterführende Ressourcen ==
	*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]		*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
			*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
	*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]		*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
	*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]		*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]

Grundschutz++

2026-04-04T03:05:40Z

← Nächstältere Version		Version vom 4. April 2026, 05:05 Uhr
Zeile 36:		Zeile 36:
	* [[Grundschutz++ Einführung und Aufbau\|'''Grundschutz++ Einführung und Vorgehen''']]		* [[Grundschutz++ Einführung und Aufbau\|'''Grundschutz++ Einführung und Vorgehen''']]
	* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']		* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']
			* '''[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik]'''
	* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]		* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
	* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]		* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]

KI Startseite

2026-04-03T11:43:22Z

Wiki-interne Verweise

← Nächstältere Version		Version vom 3. April 2026, 13:43 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1:		Zeile 1:
			[[Datei:Brain-8764400.png\|alternativtext=KI\|rechts\|160x160px]]
	{{#seo:		{{#seo:
	\|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz		\|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
Zeile 278:		Zeile 279:
	* [[KI-Nutzung]]		* [[KI-Nutzung]]
	* [[KI-Register]]		* [[KI-Register]]
			* [[LF-KI-Sicherheit]]
	* [[LF-KI-Chatbots]]		* [[LF-KI-Chatbots]]
	* [[RiLi-KI-Einsatz]]		* [[RiLi-KI-Einsatz]]

KI-Nutzung

2026-04-03T11:37:47Z

Weitere Infomationen

← Nächstältere Version		Version vom 3. April 2026, 13:37 Uhr
Zeile 260:		Zeile 260:
	== Weitere Infomationen ==		== Weitere Infomationen ==

			* [[KI Startseite\|Einführung zu sinnvollen Regelungen für den KI-Einsatz]]
	* [[Datenbias\|Was ist Daten-Bias?]]		* [[Datenbias\|Was ist Daten-Bias?]]
	* [[KI Datenschutz\|Datenschutz in KI-Anwendungen]]		* [[KI Datenschutz\|Datenschutz in KI-Anwendungen]]
	* [[RiLi-KI-Einsatz\|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]		* [[RiLi-KI-Einsatz\|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
			* [[LF-KI-Sicherheit\|Leitfaden zur KI-Sicherheit]]
	* [[KI-Register\|Mustervorlage für ein KI-Register]]		* [[KI-Register\|Mustervorlage für ein KI-Register]]
	* [[LF-KI-Chatbots\|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]		* [[LF-KI-Chatbots\|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]

LF-KI-Sicherheit

2026-04-02T12:34:37Z

Änderungen zeigen

OSCAL

2026-04-02T06:21:28Z

OSCAL-Layers im Überblick

← Nächstältere Version		Version vom 2. April 2026, 08:21 Uhr
Zeile 22:		Zeile 22:
	# '''Verbessertes Risikomanagement''': Durch die Bereitstellung eines genauen, aktuellen Bildes der Sicherheitslage verbessert OSCAL die Entscheidungsfindung, insbesondere bei der Reaktion auf Vorfälle.		# '''Verbessertes Risikomanagement''': Durch die Bereitstellung eines genauen, aktuellen Bildes der Sicherheitslage verbessert OSCAL die Entscheidungsfindung, insbesondere bei der Reaktion auf Vorfälle.
	# '''Skalierbare Compliance-Verwaltung''': OSCAL bietet einen modularen und erweiterbaren Ansatz für Compliance, der mit dem Unternehmenswachstum skalieren kann.		# '''Skalierbare Compliance-Verwaltung''': OSCAL bietet einen modularen und erweiterbaren Ansatz für Compliance, der mit dem Unternehmenswachstum skalieren kann.
			# '''Interoperabilität''': OSCAL ermöglicht den Austausch von Sicherheitsinformationen zwischen Tools, Auditoren und Organisationen ohne Medienbrüche.

	=== Konzept und Layout von OSCAL ===		=== Konzept und Layout von OSCAL ===
Zeile 29:		Zeile 30:
	Die Kernstruktur gliedert sich in fünf Haupt-Layers, die aufeinander aufbauen:		Die Kernstruktur gliedert sich in fünf Haupt-Layers, die aufeinander aufbauen:
	[[Datei:Oscal-layers-models-traceability.jpg\|alternativtext=OSCAL Layer\|zentriert\|rahmenlos\|640x640px\|Quelle: NIST]]		[[Datei:Oscal-layers-models-traceability.jpg\|alternativtext=OSCAL Layer\|zentriert\|rahmenlos\|640x640px\|Quelle: NIST]]
	# '''Control Layer''' Dieser Layer enthält Catalogs mit standardisierten Sicherheitskontrollen, z. B. aus NIST SP 800-53 oder anderen Quellen. Controls werden hier definiert, gruppiert (in Classes und Groups), parametrisiert und mit Props versehen. Er bildet die ~~unveränderliche~~ Basis; Parameter erlauben Flexibilität, z. B. für Passwortlängen oder Retention-Zeiten.		# '''Control Layer''' Dieser Layer enthält Catalogs mit standardisierten Sicherheitskontrollen, z. B. aus NIST SP 800-53 oder anderen Quellen. Controls werden hier definiert, gruppiert (in Classes und Groups), parametrisiert und mit Props versehen. Er bildet die stabile, versionierte Basis; Parameter erlauben Flexibilität, z. B. für Passwortlängen oder Retention-Zeiten.
	# '''Profile Layer''' Profiles wählen, modifizieren und erweitern Controls aus Catalogs. Typische Anpassungen: Ausschlüsse (modify remove), Hinzufügungen (modify add) oder Parameter-Setzungen. Ein Profile kann „aufgelöst“ (resolve) werden, um ein maßgeschneidertes Control-Set zu erzeugen, z. B. „FedRAMP Moderate Baseline“ oder ISO 27001-mappings.		# '''Profile Layer''' Profiles wählen, modifizieren und erweitern Controls aus Catalogs. Typische Anpassungen: Ausschlüsse (modify remove), Hinzufügungen (modify add) oder Parameter-Setzungen. Ein Profile kann „aufgelöst“ (resolve) werden, um ein maßgeschneidertes Control-Set zu erzeugen, z. B. „FedRAMP Moderate Baseline“ oder ISO 27001-mappings.
	# '''Implementation Layer''' Beschreibt die konkrete Umsetzung im System:		# '''Implementation Layer''' Beschreibt die konkrete Umsetzung im System:

RiLi-KI-Einsatz

2026-04-01T13:17:10Z

Änderungen zeigen

LF-KI-Sicherheit

2026-04-01T13:16:20Z

Die Seite wurde neu angelegt: „{{#seo: |title=Leitfaden KI-Sicherheit: Härtung, Modellsicherheit und Nachvollziehbarkeit |keywords=KI-Härtung, Modellsicherheit, Nachvollziehbarkeit, AI-Hardening, KI-Risiken, KI-Logging, KI-Audit, EU AI Act, ISMS, ISO 27001 |description=Fachlicher Leitfaden zur KI-Sicherheit mit Maßnahmen für Härtung, Modellsicherheit und Nachvollziehbarkeit. Mit Anforderungen, Prüfkriterien und Best Practices für Unternehmen. }}{{SHORTDESC:Härtung, Modellsiche…“

Neue Seite

{{#seo:
|title=Leitfaden KI-Sicherheit: Härtung, Modellsicherheit und Nachvollziehbarkeit
|keywords=KI-Härtung, Modellsicherheit, Nachvollziehbarkeit, AI-Hardening, KI-Risiken, KI-Logging, KI-Audit, EU AI Act, ISMS, ISO 27001
|description=Fachlicher Leitfaden zur KI-Sicherheit mit Maßnahmen für Härtung, Modellsicherheit und Nachvollziehbarkeit. Mit Anforderungen, Prüfkriterien und Best Practices für Unternehmen.
}}{{SHORTDESC:Härtung, Modellsicherheit und Nachvollziehbarkeit}}''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 <code>llm-guard</code> oder <code>neural-classifier</code> für Input-Vorfilterung.
* Regex-Regeln für bekannte Angriffsmuster (<code>ignore previous instructions</code>, <code>sudo</code>, Base64-Payloads).
* Whitelisting erlaubter Zeichenmengen (alphanumerisch + begrenzte Sonderzeichen).
* Implementierung als Middleware (FastAPI/Flask): <code>request.input = sanitize(request.input)</code>.

=== 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 (<code>slowapi</code>), Django-RateLimit.
* Headers setzen: <code>X-RateLimit-Remaining</code>, <code>Retry-After</code>.
* 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 <code>unitary/toxic-bert</code>.
* 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: <code>trl</code> (Transformers Reinforcement Learning), <code>adversarial-robustness-toolbox</code>.

=== 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 (<code>USER 1000:1000</code> im Dockerfile).
* AppArmor/SELinux-Profil für KI-Prozess.
* Read-only Root-Filesystem (<code>--read-only</code> bei <code>docker run</code>).
* Seccomp-Filter: Nur <code>read/write/socket</code> 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 <code>model-card-toolkit</code>
* 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: <code>cyclonedx-py</code> 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: <code>/audit/{request_id}</code> 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 <code>model_hash</code> und <code>data_version</code>
* 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.
{| class="wikitable"
! 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:

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

=== Phase 2: Dokumentationspflicht ===
Erstellt die Audit-Grundlage für EU AI Act Konformität:

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

=== Phase 3: Erweiterte Härte-Maßnahmen ===
Erhöht die Robustheit gegen komplexe Angriffe:

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

=== Phase 4: Laufende Prüfung und Optimierung ===
Stellt dauerhafte Konformität sicher:

# '''Automatisierte Tests''' einrichten (garak, docker-bench-security)
# '''SIEM-Integration''' mit Anomalie-Erkennung (ELK + Alerts)
# '''Erste interne Prüfung''' aller Maßnahmen durchführen
# '''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:'''

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

'''Langfristig:''' Jährliche Red-Team-Tests und kontinuierliche Weiterentwicklung der Maßnahmen entsprechend neuer Bedrohungen ([https://genai.owasp.org/llm-top-10/ 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 ==

* [https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Kreise/Expertenkreis_KI_LLMs.pdf BSI/ACS Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs)]
* [https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf NIST AI Risk Management Framework (RMF 1.0)]
* [https://genai.owasp.org/download/46119/?tmstv=1741814262|OWASP OWASP Top 10 für LLM-Applikationen (v 2025 de)]

[[Kategorie:Artikel]]
[[Kategorie:KI]]
[[Kategorie:Leitfaden]]

Willkommen im ISMS-Ratgeber WiKi

2026-04-01T13:15:04Z

← Nächstältere Version		Version vom 1. April 2026, 15:15 Uhr
Zeile 216:		Zeile 216:
	*[[LF-Sicher_arbeiten\|Leitfaden sicheres Arbeiten]]		*[[LF-Sicher_arbeiten\|Leitfaden sicheres Arbeiten]]
	*[[LF-Sicher_unterwegs\|Leitfaden sicher unterwegs]]		*[[LF-Sicher_unterwegs\|Leitfaden sicher unterwegs]]
			*[[LF-KI-Sicherheit\|Leitfaden KI-Sicherheit]]
	*[[LF-KI-Chatbots\|Leitfaden zur Nutzung von KI-Systemen]]		*[[LF-KI-Chatbots\|Leitfaden zur Nutzung von KI-Systemen]]
	*[[LF-Modellierung\|Leitfaden Gruppierung und Modellierung]]		*[[LF-Modellierung\|Leitfaden Gruppierung und Modellierung]]

← Nächstältere Version		Version vom 3. April 2026, 13:37 Uhr
Zeile 260:		Zeile 260:
	== Weitere Infomationen ==		== Weitere Infomationen ==

			* [[KI Startseite\|Einführung zu sinnvollen Regelungen für den KI-Einsatz]]
	* [[Datenbias\|Was ist Daten-Bias?]]		* [[Datenbias\|Was ist Daten-Bias?]]
	* [[KI Datenschutz\|Datenschutz in KI-Anwendungen]]		* [[KI Datenschutz\|Datenschutz in KI-Anwendungen]]
	* [[RiLi-KI-Einsatz\|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]		* [[RiLi-KI-Einsatz\|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
			* [[LF-KI-Sicherheit\|Leitfaden zur KI-Sicherheit]]
	* [[KI-Register\|Mustervorlage für ein KI-Register]]		* [[KI-Register\|Mustervorlage für ein KI-Register]]
	* [[LF-KI-Chatbots\|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]		* [[LF-KI-Chatbots\|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]

← Nächstältere Version		Version vom 1. April 2026, 15:15 Uhr
Zeile 216:		Zeile 216:
	*[[LF-Sicher_arbeiten\|Leitfaden sicheres Arbeiten]]		*[[LF-Sicher_arbeiten\|Leitfaden sicheres Arbeiten]]
	*[[LF-Sicher_unterwegs\|Leitfaden sicher unterwegs]]		*[[LF-Sicher_unterwegs\|Leitfaden sicher unterwegs]]
			*[[LF-KI-Sicherheit\|Leitfaden KI-Sicherheit]]
	*[[LF-KI-Chatbots\|Leitfaden zur Nutzung von KI-Systemen]]		*[[LF-KI-Chatbots\|Leitfaden zur Nutzung von KI-Systemen]]
	*[[LF-Modellierung\|Leitfaden Gruppierung und Modellierung]]		*[[LF-Modellierung\|Leitfaden Gruppierung und Modellierung]]