GenAI Red Teaming erfordert einen strukturierten methodischen Ansatz, der traditionelle Sicherheitsstandards mit spezifischen Praktiken für generative KI-Systeme integriert. Die Aktivität bewertet das gesamte KI-Ökosystem unter Berücksichtigung menschlicher Angreifer, Modellverhalten und der Qualität der erzeugten Ausgaben, wobei ein besonderer Schwerpunkt auf den Risiken durch schädliche Inhalte, Desinformation und ethische Verstöße liegt.

Für einen Überblick über die Aktivitäten des GenAI Red Teaming und deren Rolle in der KI-Sicherheit, konsultieren Sie den vollständigen Leitfaden zum GenAI Red Teaming.

Referenz-Framework: NIST AI RMF

Das methodische Framework basiert auf drei grundlegenden Dokumenten des National Institute of Standards and Technology:

• NIST AI 100-1: Artificial Intelligence Risk Management Framework, das den allgemeinen Ansatz für das Management von KI-Risiken definiert.
• NIST AI 600-1: AI RMF Generative Artificial Intelligence Profile, spezifisch für generative Systeme.
• NIST SP 800-218A: Secure Software Development Practices for Generative AI, fokussiert auf die sichere Entwicklung.

GenAI Red Teaming wird der Funktion Map 5.1 des NIST AI RMF zugeordnet, die eine systematische Bewertung der Fähigkeiten und Grenzen des KI-Systems in Bezug auf den geplanten Einsatzkontext erfordert.

Strukturierung des Red-Teaming-Projekts

Abschnitt 2 des NIST AI 600-1 bietet präzise Anleitungen zur Definition des Projektumfangs unter Berücksichtigung von drei grundlegenden Dimensionen:

Lebenszyklusphase

Tests können in verschiedenen Phasen durchgeführt werden:

• Design und anfängliche Systementwicklung
• Pre-Deployment und Validierung
• Betrieb und kontinuierliche Überwachung
• Decommissioning und Außerbetriebnahme

Jede Phase erfordert differenzierte Testansätze, basierend auf der Reife des Systems und den spezifischen Risiken des jeweiligen Zeitpunkts.

Risikobereich

Die Bewertung kann sich auf drei Ebenen konzentrieren:

• Modell: Intrinsische Schwachstellen des Basismodells, Bias, Generalisierungsfähigkeiten
• Infrastruktur: Sicherheit der Bereitstellungsumgebung, Datenmanagement, Zugriffskontrollen
• Ökosystem: Interaktionen mit anderen Systemen, Auswirkungen auf Stakeholder, systemische Risiken

Risikoquelle

Die Analyse identifiziert die Ursprünge der zu testenden Risiken, die Folgendes umfassen können:

• Gezielte Manipulation durch externe Angreifer
• Unvorhergesehenes emergentes Verhalten des Modells
• Problematische Interaktionen mit legitimen Benutzern
• Schwachstellen in der Lieferkette (Supply Chain) des Modells

Scoping-Prozess und Priorisierung

Die Definition des Umfangs erfordert die Einbeziehung verschiedener Unternehmens-Stakeholder:

Abstimmung mit dem Risikomanagement

Der Austausch mit den Risikomanagement-Teams ermöglicht es:

• Spezifische Risikotoleranzschwellen für den Geschäftskontext zu definieren
• Kritische Risiken zu identifizieren, die eine priorisierte Prüfung erfordern
• Messbare Erfolgsmetriken für Red-Teaming-Aktivitäten festzulegen

Zusammenarbeit mit Systemverantwortlichen

Die Systemverantwortlichen (System Owner) liefern wesentliche Informationen zu:

• Geplanten Anwendungsfällen und realen Betriebsszenarien
• Technischen Einschränkungen und bekannten Limitierungen des Systems
• Geschäftsprioritäten, die die Testentscheidungen leiten

Wenn beispielsweise das Hauptrisiko der Diebstahl proprietärer Custom-Modelle ist, konzentriert sich das Testing auf Techniken der Model-Extraktion und den Schutz geistigen Eigentums.

Auswahl und Einbindung von Experten

Die Zusammensetzung des Red-Teaming-Teams variiert je nach zu bewertenden Risiken:

Expertentypen

• Repräsentative Benutzer: zum Testen der Benutzerfreundlichkeit und Identifizierung problematischer Verhaltensweisen bei normaler Nutzung
• Fachexperten: zur Bewertung der Genauigkeit und Relevanz der Ausgaben in spezialisierten Kontexten
• Cybersicherheitsexperten: zur Identifizierung technischer Schwachstellen und Angriffsvektoren
• Demografische Vertreter: zur Erkennung von Bias und Fairness-Problemen gegenüber spezifischen Gruppen

Erforderliche Werkzeuge und Ressourcen

Das Projekt erfordert die Anschaffung geeigneter Tools:

• Testdatensätze, die spezifisch auf die identifizierten Risiken zugeschnitten sind
• Adversarielle Modelle zur Simulation von Angriffen
• Test-Harness zur Automatisierung wiederholbarer Testszenarien
• Werkzeuge zur Erfassung, Analyse und Berichterstattung der Ergebnisse

Betriebsstandards und Governance

Die Methodik erfordert die Definition formeller Verfahren, um verantwortungsbewusstes und effektives Testen zu gewährleisten:

Autorisierung und Berechtigungen

Vor Beginn der Aktivitäten müssen folgende Punkte eingeholt werden:

• Formelle Autorisierung durch die Systemverantwortlichen
• Genehmigung durch Rechts- und Compliance-Teams
• Einverständniserklärung, wenn das Testing personenbezogene Daten betrifft

Datenprotokollierung und Rückverfolgbarkeit

Alle Testaktivitäten müssen dokumentiert werden durch:

• Detaillierte Protokolle der Systeminteraktionen
• Aufzeichnung der verwendeten Testtechniken
• Nachverfolgung der Ergebnisse und identifizierten Schwachstellen

Berichterstattung und Kommunikation

Die Ergebnisse werden gemäß definierten Protokollen kommuniziert, die Folgendes spezifizieren:

• Format und Inhalt der Schwachstellenberichte
• Kommunikationskanäle für verschiedene Risikoschweregrade
• Zeitpläne für verantwortungsvolle Offenlegung (Responsible Disclosure)

Datenmanagement und -entsorgung

Die während des Testings gesammelten Daten erfordern spezifische Verfahren für:

• Sichere Aufbewahrung während des Projekts
• Zugriffskontrolle auf sensible Daten
• Sichere Löschung nach Abschluss der Aktivitäten

Spezifische Bewertungsziele

Das methodische Framework leitet die systematische Identifizierung verschiedener Risikokategorien:

Unsichere und schädliche Inhalte

Das Testing prüft, ob das System dazu verleitet werden kann, Folgendes zu generieren:

• Gewalttätige, beleidigende oder illegale Inhalte
• Anleitungen für gefährliche Aktivitäten
• Material, das gegen Unternehmensrichtlinien oder Vorschriften verstößt

Desinformation und Genauigkeit

Die Bewertung konzentriert sich auf die Fähigkeit des Systems:

• Faktisch korrekte Informationen zu produzieren
• Manipulationen zu widerstehen, die auf die Erzeugung von Desinformation abzielen
• Anfragen für falsche oder irreführende Inhalte zu identifizieren und abzulehnen

Bias und Diskriminierung

Das Testing identifiziert Vorurteile in den Antworten in Bezug auf:

• Demografische Merkmale (Geschlecht, Ethnie, Alter)
• Geografische oder kulturelle Kontexte
• Soziale Gruppen oder Berufskategorien

Offenlegung sensibler Daten

Die Überprüfung kontrolliert, ob das System:

• Vertrauliche Informationen aus den Trainingsdaten preisgeben kann
• Personenbezogene oder proprietäre Daten offenlegen kann
• Anforderungen an Datenschutz und Datensicherheit verletzen kann

Verhalten außerhalb des Anwendungsbereichs

Das Testing bewertet, ob das System Antworten produziert, die:

• Nicht mit dem geplanten Anwendungsfall übereinstimmen
• Die erklärten Fähigkeiten überschreiten
• Definierte operative Grenzen verletzen

Integration mit Reaktionsfähigkeiten

Das methodische Framework beschränkt sich nicht auf die Identifizierung von Schwachstellen, sondern umfasst auch die Überprüfung der Reaktionsfähigkeiten des Systems:

• Wirksamkeit der implementierten Sicherheitsmaßnahmen
• Fähigkeit zur Erkennung von Manipulationsversuchen
• Incident-Response-Verfahren für KI-spezifische Probleme
• Fallback-Mechanismen und Fehlerbehandlung

Nützliche weiterführende Informationen

Um die operativen und strategischen Aspekte des GenAI Red Teaming zu vertiefen, konsultieren Sie diese Ressourcen:

• GenAI Red Teaming: Allgemeiner Rahmen für Red-Teaming-Aktivitäten für generative KI-Systeme
• GenAI Red Teaming Techniken: Operative Test- und Angriffstechniken
• Risiken und Bedrohungen im GenAI Red Teaming: Risikokategorien und spezifische Bedrohungen
• Red-Teaming-Strategie für LLMs: Strategische Planung der Aktivitäten
• Metriken für GenAI Red Teaming: Messung der Wirksamkeit der Aktivitäten
• Tools und Datensätze für Red Teaming: Operative Ressourcen für das Testing

• Welche NIST-Dokumente sind die Referenz für GenAI Red Teaming?
• Die drei grundlegenden Dokumente sind NIST AI 100-1 (AI Risk Management Framework), NIST AI 600-1 (Generative AI Profile) und NIST SP 800-218A (Secure Software Development Practices for Generative AI). Diese Standards bieten das vollständige methodische Framework zur Strukturierung von Red-Teaming-Projekten für generative KI-Systeme.
• Wie definiert man den Umfang eines GenAI Red-Teaming-Projekts?
• Der Umfang wird unter Berücksichtigung von drei Dimensionen definiert: die Lebenszyklusphase des Systems (Design, Deployment, Betrieb), der Risikobereich (Modell, Infrastruktur, Ökosystem) und die Quelle der zu analysierenden Risiken. Diese Strukturierung erfordert die Einbeziehung von Risikomanagement-Teams und Systemverantwortlichen, um die Testprioritäten mit den Geschäftszielen in Einklang zu bringen.
• Welche Experten sollten in Red-Teaming-Aktivitäten einbezogen werden?
• Die Zusammensetzung des Teams variiert je nach identifizierten Risiken und kann repräsentative Benutzer, Fachexperten, Cybersicherheitsprofis und Vertreter der Zielgruppen umfassen. Die Auswahl der Experten sollte sich an den spezifischen zu bewertenden Risiken und dem operativen Kontext des Systems orientieren.
• Welche Betriebsstandards müssen während des Testings eingehalten werden?
• Das Framework erfordert formelle Verfahren für die Testautorisierung, Datenprotokollierung und Rückverfolgbarkeit, strukturierte Berichterstattung, Konfliktmanagement, verantwortungsvolle Kommunikation und die sichere Entsorgung der gesammelten Daten. Diese Standards stellen sicher, dass Red-Teaming-Aktivitäten ethisch, legal und nachvollziehbar durchgeführt werden.
• Wie lässt sich GenAI Red Teaming in die Incident-Response-Fähigkeiten integrieren?
• Das methodische Framework beinhaltet die Überprüfung der implementierten Sicherheitsmaßnahmen, der Manipulationserkennungsfähigkeiten, der KI-spezifischen Incident-Response-Verfahren und der Fallback-Mechanismen. Das Ziel ist es, nicht nur Schwachstellen zu bewerten, sondern auch die Wirksamkeit der Systemreaktion auf Angriffsversuche.