LLM Security by design: Einbeziehung der Sicherheit in jeder Phase der Entwicklung

Da große Sprachmodelle (LLMs) zunehmend in Unternehmen und Anwendungen eingesetzt werden, war der Bedarf an robusten Sicherheitsmaßnahmen noch nie so groß. Wenn ein LLM nicht ordnungsgemäß gesichert ist, kann es erhebliche Risiken in Form von Datenlecks, Modellmanipulationen und sogar Problemen mit der Einhaltung gesetzlicher Vorschriften mit sich bringen. An diesem Punkt wird die Beauftragung eines externen Sicherheitsunternehmens entscheidend.

In diesem Blog erörtern wir die wichtigsten Überlegungen für Unternehmen, die ein Sicherheitsteam mit der Bewertung und Sicherung ihrer LLM-Systeme beauftragen möchten, sowie die spezifischen Aufgaben, die in den verschiedenen Phasen des Lebenszyklus der LLM-Entwicklung durchzuführen sind.

Stufe 0: Hosting-Modell (physisch vs. Cloud)

Die Wahl des Hosting-Modells, physisch oder cloudbasiert, kann erhebliche Auswirkungen auf die Sicherheit eines großen Sprachmodells (LLM) haben. Jeder Ansatz hat seine eigenen Sicherheitsüberlegungen, die sorgfältig bewertet werden müssen.

Fragen der physischen Sicherheit:

• Physische Sicherheit und Sicherheit des Rechenzentrums - Die Unterbringung eines LLM-Modells in einer physischen Infrastruktur birgt Risiken wie den unbefugten Zugang zu Einrichtungen, Diebstahl oder die Störung kritischer Systeme. Diese Bedrohungen können nicht nur durch technische Schwachstellen entstehen, sondern auch durch menschliche Faktoren, wie Social Engineering oder Verfolgung. Um diese Risiken zu mindern, sollte ein physischer Penetrationstest durchgeführt werden. Dazu gehört die Simulation realer Eindringversuche, wie z.B. sich als eine andere Person auszugeben oder das Personal zu umgehen, und die Bewertung der Widerstandsfähigkeit von physischen Barrieren, Überwachungssystemen, Zugangskontrollen und Umgebungsschutz (z.B. Strom- und Feuerschutz).
  
• Netzwerksicherheit - Lokale LLM-Implementierungen sind besonders anfällig für externe Cyberangriffe und Insider-Bedrohungen, wenn die zugrunde liegende Netzwerkarchitektur nicht richtig gesichert ist. Falsch konfigurierte Firewalls, freigegebene Dienste oder zu freizügige Zugriffskontrollen können dem Missbrauch Tür und Tor öffnen. Um diese Risiken proaktiv anzugehen, ist eine gründliche Bewertung der Netzwerkarchitektur und eine Sicherheitsbewertung erforderlich. Dazu gehört die Bewertung der Segmentierung, der Firewall-Regeln, des VPN-Zugangs, der Intrusion Detection-Funktionen und der Zugangskontrollen, um sicherzustellen, dass die LLM-Umgebung sowohl vor externen als auch internen Angriffen geschützt ist.
  
• Risiken in der Lieferkette - LLM-Modelle, die vor Ort gehostet werden, sind in hohem Maße auf Hardwarekomponenten angewiesen, die Risiken bergen können, wenn sie von nicht vertrauenswürdigen oder nicht verifizierten Lieferanten stammen. Kompromittierte Chips, bösartige Firmware oder manipulierte Geräte können die Integrität des gesamten Systems untergraben. Um dieses Risiko zu mindern, sollte ein Sicherheitsteam eine umfassende Bewertung der Lieferkette durchführen, die Beschaffungspraktiken beurteilen, die Vertrauenswürdigkeit der Lieferanten überprüfen, Hardwarekomponenten physisch inspizieren und die Integrität von Firmware/Software validieren, um sicherzustellen, dass die Infrastruktur frei von eingebetteten Bedrohungen ist und die Grundsätze der sicheren Beschaffung eingehalten werden.

Sicherheitsrisiken beim Cloud-basierten Hosting:

• Cloud-Fehlkonfigurationen - Wenn ein LLM in der Cloud gehostet wird, hängt die Sicherheitslage stark davon ab, wie die Cloud-Dienste konfiguriert sind. Im Gegensatz zu physischen Umgebungen, in denen Unternehmen die vollständige Kontrolle über Hardware und Netzwerkschichten haben, führen Cloud-Umgebungen zu einer Abstraktion und damit zu einer Reihe anderer Risiken. Falsch konfigurierte Ressourcen wie offene S3-Buckets, zu freizügige IAM-Rollen oder ungeschützte API-Endpunkte können sensible Trainingsdaten, Modellartefakte oder Anmeldedaten freigeben. Um dies zu verhindern, müssen Sicherheitsteams eine umfassende Prüfung der Cloud-Konfigurationen durchführen. Dazu gehört die Überprüfung von Speicherberechtigungen, Identitäts- und Zugriffsverwaltungsrichtlinien, Netzwerksicherheitseinstellungen und freigegebenen Endpunkten, um Fehlkonfigurationen zu identifizieren und zu beheben, die zu unbefugtem Zugriff oder Datenlecks führen könnten.
  
• Falsche Zuordnung der gemeinsamen Verantwortung - Einer der wichtigsten - und oft übersehenen - Aspekte der Cloud-Sicherheit ist das Verständnis des Modells der gemeinsamen Verantwortung. Im Gegensatz zum physischen Hosting, bei dem das Unternehmen für die gesamte Sicherheit zuständig ist, sichern Cloud-Anbieter die Infrastruktur, während die Kunden für den Schutz ihrer Daten, Anwendungen und Konfigurationen verantwortlich sind. Ein Missverständnis dieser Aufteilung kann zu ungeschützten Assets oder blinden Flecken in der Sicherheitsabdeckung führen. Sicherheitsteams können helfen, indem sie die Verantwortlichkeiten klar abstecken, die richtigen Sicherheitskontrollen entwickeln und Prozesse implementieren, die sicherstellen, dass alle Teile der LLM-Umgebung - insbesondere die vom Kunden verwalteten Teile - ordnungsgemäß gesichert sind.
  
• Insider-Bedrohungen - Obwohl selten, besteht das Risiko, dass Mitarbeiter von Cloud-Anbietern privilegierten Zugang missbrauchen. Um dem entgegenzuwirken, sollten Unternehmen eine starke Verschlüsselung und rollenbasierte Zugriffskontrollen durchsetzen sowie eine detaillierte Überwachung und Audit-Protokollierung einführen. Sicherheitsteams können dazu beitragen, indem sie überprüfen, ob sensible Daten im Ruhezustand und bei der Übertragung verschlüsselt sind und ob der Zugriff auf den Anbieter transparent ist und protokolliert wird.
  
• Einhaltung gesetzlicher Vorschriften - Das Hosten von LLMs in der Cloud kann je nach Branche und Land zusätzliche gesetzliche Anforderungen auslösen (z.B. GDPR, HIPAA usw.). Sicherheitsteams sollten die rechtlichen Verpflichtungen bewerten und ein Compliance-Rahmenwerk entwerfen, das Kontrollen der Datenaufbewahrung, Verschlüsselungsrichtlinien, Zugangskontrollen und Verfahren bei Verstößen umfasst. Dadurch wird sichergestellt, dass die LLM-Umgebung den gesetzlichen Standards und den besten Praktiken der Branche entspricht.

Bei der Bewertung des Hosting-Modells für ein LLM sollten Unternehmen die Sicherheitsrisiken und -kontrollen, die sowohl mit physischen als auch mit Cloud-basierten Ansätzen verbunden sind, sorgfältig bewerten. Ein gründliches Verständnis der Sicherheitsimplikationen und der spezifischen Anforderungen und Einschränkungen der Organisation ist entscheidend für die Bestimmung der am besten geeigneten Hosting-Lösung. Die folgenden Phasen gelten unabhängig davon, ob ein physisches oder ein Cloud-Hosting-Modell verwendet wird.

Phase 1: Datenakkumulation

Die Qualität eines großen Sprachmodells ist direkt mit der Qualität der Daten verknüpft, auf denen es trainiert wird. Obwohl die Datenakkuratierung in der Regel eine Aufgabe der Datenwissenschaft und -technik ist, können dennoch Sicherheitsrisiken entstehen. Vom Sicherheitsstandpunkt aus gesehen ist es von entscheidender Bedeutung, die Zuverlässigkeit der Datenquellen zu überprüfen und Kontrollen zu implementieren, die das Modell vor Vergiftungen, Verletzungen der Privatsphäre und verzerrten Ergebnissen schützen.

• Risiken der Datenverfälschung - Das Training mit ungeprüften oder feindlichen Daten kann versteckte Schwachstellen, Verzerrungen oder sogar böswilliges Verhalten in ein LLM einbringen. Dies ist besonders besorgniserregend, wenn öffentliche Internetquellen oder von der Community zur Verfügung gestellte Datensätze verwendet werden. Sicherheitsteams sollten eine Überprüfung der Architektur und/oder eine Bedrohungsmodellierung durchführen, um die Arbeitsabläufe bei der Dateneingabe zu bewerten. Diese Überprüfungen helfen bei der Identifizierung von Schwachstellen, an denen böswillige Akteure vergiftete Daten einfügen können, und stellen sicher, dass die Organisation Kontrollen wie Datenvalidierung, Domain-Whitelisting und Überwachung auf anomale Inhalte anwendet.
  
• Verstöße gegen den Datenschutz und die Einhaltung von Vorschriften - Öffentliche Datensätze enthalten häufig von Benutzern erstellte Inhalte, die persönlich identifizierbare Informationen (PII) oder andere sensible Daten enthalten können, was zu Verstößen gegen Vorschriften oder den Datenschutz führen kann. Sicherheitsexperten sollten eng mit den Datenteams zusammenarbeiten, um die Datenschutzrichtlinien und Filtermechanismen der Pipeline zu überwachen. Dazu gehört auch die Überprüfung, ob regelbasierte und klassifizierende Tools vorhanden sind, um personenbezogene Daten zu erkennen und zu entfernen, und ob diese Prozesse regelmäßig auf ihre Wirksamkeit überprüft werden.
  
• Vergiftung auf Einbettungsebene - Selbst nach der Standardbereinigung können feindliche Eingaben durch Einbettungsebenen weiterbestehen und zu subtilen Verschiebungen in der Art und Weise führen, wie das Modell bestimmte Inhalte interpretiert. Dieses Risiko ist zwar schwer zu erkennen, kann aber durch eine forschungsgestützte Bewertung der Gegner oder durch die Koordination mit roten Teams, die sich auf das Verhalten von LLM-Einbettungen konzentrieren, gemindert werden. Die Sicherheitsbehörden sollten in die Diskussionen über das Design von Tokenisern und die Robustheit von Einbettungen für Hochrisikomodelle einbezogen werden.

Stufe 2: Modell-Architektur

In dieser Phase wählt und/oder entwirft die Organisation die neuronale Architektur, die bestimmt, wie der LLM lernt und die Ausgabe erzeugt. Die meisten modernen LLMs basieren auf transformatorischen Architekturen. Obwohl diese Architekturentscheidungen hauptsächlich technischer Natur sind, haben sie erhebliche Auswirkungen auf die Sicherheit. Wenn nichts unternommen wird, können Schwachstellen, die auf der Modellebene eingeführt werden, insbesondere bei Open-Source-Modellen, zu dauerhaften, anhaltenden Bedrohungen werden. Obwohl Sicherheitsexperten traditionell nicht in diese Phase involviert sind, können sie sich präventiv gegen tief eingebettete Risiken schützen, indem sie diese frühzeitig einbeziehen.

• Verzögerte Modellkomponenten - Wenn sich ein Angreifer während des Trainings Zugang zu einem Open-Source-Modell verschafft oder es modifiziert, kann er bösartiges Verhalten direkt in die Architektur des Modells einbringen. Eine modifizierte Decoder-Schicht in einem Transformator-basierten Modell kann beispielsweise so konzipiert sein, dass sie bei bestimmten Aufforderungen bestimmte Inhalte im Hintergrund ausführt. Um dies zu verhindern, sollten Sicherheitsteams eine Architekturprüfung durchführen, die sich auf die Modellintegrität konzentriert. Dazu gehören die Validierung der Trainingsherkunft, die Überprüfung kritischer Modellebenen auf unbefugte Änderungen und die Überprüfung auf verdächtiges Verhalten in kontrollierten Testaufforderungen.
  
• Modellintegrität und Vertrauen in Open Source - Viele Unternehmen verwenden Open-Source-Modelle, um die Entwicklung zu beschleunigen. Diese Modelle können jedoch zu Vertrauensproblemen führen, wenn ihre Trainingsdaten, Architektur oder Änderungshistorie nicht transparent sind. Sicherheitsteams sollten Arbeitsabläufe zur Überprüfung und Kontrolle von Modellen implementieren, um die Quelle, die Trainingslinie und alle bereits vorgenommenen Änderungen zu überprüfen, bevor das Modell eingesetzt oder weiter verfeinert wird.
  
• Architekturentscheidungen, die die Sicherheit verbessern - Während sich die meisten Teams auf die Genauigkeit oder Effizienz konzentrieren, können einige Architekturentscheidungen die Sicherheit verbessern. So kann beispielsweise die Integration von Modulen zur Erkennung von Anomalien oder die Entwicklung eines Modells zur Unterstützung des Trainings von Angreifern die Widerstandsfähigkeit gegen zukünftige Angriffe verbessern. Sicherheitsexperten sollten bei den ersten Gesprächen über den Entwurf sicherheitsrelevante Architekturkomponenten empfehlen, insbesondere bei risikoreichen oder sicherheitskritischen Einsätzen.

Phase 3: Training im großen Maßstab

Da der LLM im großen Maßstab geschult wird, muss das Sicherheitsteam nicht viel tun, wenn es zuvor gründliche Architekturprüfungen und Bedrohungsmodellierungen durchgeführt hat. Sie müssen sich darauf konzentrieren, den Schulungsprozess selbst sicher und stabil zu gestalten:

• Bewertung der Sicherheit der Schulungsinfrastruktur - Bewertung der physischen, Netzwerk- und Zugangskontrollen zum Schutz der Schulungsumgebung vor unbefugtem Zugriff oder Unterbrechung.

Phase 4: Bewertung

In der Evaluierungsphase wird die Leistung des LLM anhand von Benchmark-Datensätzen bewertet, um Wissen, logisches Denken und Genauigkeit bei verschiedenen Aufgaben zu messen. Gängige Benchmarks sind Hellaswag (gesunder Menschenverstand), MMLU (domänenspezifisches Wissen) und TruthfulQA (Wahrheitsgehalt und Widerstandsfähigkeit gegen Fehlvorstellungen). Diese Tools sind zwar nützlich, um die Gesamtleistung zu messen, aber sie bieten auch eine einzigartige Oberfläche für Sicherheitsrisiken. In diesem Stadium sind Sicherheitsexperten besonders darauf bedacht, dass die Evaluierungsverfahren zuverlässig und frei von Verunreinigungen sind und nicht manipuliert werden können.

• Kontamination der Bewertung - Angreifer können versuchen, den Bewertungsprozess zu manipulieren, indem sie Benchmark-Fragen (z.B. von Hellaswag oder MMLU) in den Pre-Training-Korpus des Modells einfügen. Wenn dies unentdeckt bleibt, kann dies die Benchmark-Ergebnisse erheblich aufblähen und die Qualität des Modells falsch darstellen. Sicherheitsteams sollten mit ML-Ingenieuren zusammenarbeiten, um die Erkennung von Benchmark-Kontaminationen zu implementieren, damit sichergestellt ist, dass während des Trainings keine Bewertungsdaten durchsickern oder gespeichert werden.
  
• Vertrauen in Bewerter und Benchmarks - Nicht alle Benchmarks sind gleich, und einigen fehlt es an Genauigkeit oder Transparenz. Sich auf schlecht konstruierte oder zu eng gefasste Benchmarks zu verlassen, kann zu irreführenden Leistungsmetriken führen. Sicherheitsexperten sollten dabei helfen, Bewertungstools und Datensätze zu prüfen, um sicherzustellen, dass sie aus seriösen Quellen stammen, gut gepflegt werden und mit den Zielen und der Risikotoleranz des Unternehmens übereinstimmen.
  
• Integrität des Bewertungsprozesses - Bewertungsskripte, Datensätze und Bewertungslogik können manipuliert werden, wenn sie nicht angemessen gesichert sind. Sicherheitsteams sollten die Bewertungsinfrastruktur kontrollieren und sicherstellen, dass der Zugriff beschränkt ist, eine Versionskontrolle besteht und die Ergebnisse reproduzierbar und überprüfbar sind, um das Vertrauen in die Ergebnisse zu erhalten.

Phase 5: Nachbesserungen

Sobald der LLM das Basistraining bestanden hat, verbessern die Teams ihn häufig durch Verfeinerung, Retrieval-Augmented Generation (RAG) und Prompt Engineering, um die Leistung zu verbessern, Domänenwissen einzuführen oder Echtzeitwissen zu integrieren. Während diese Erweiterungen leistungsstarke Funktionen freisetzen, schaffen sie auch neue Sicherheitsherausforderungen, insbesondere wenn es um sensible Daten oder die Durchsetzung von Richtlinien geht. In dieser Phase ist es Aufgabe des Sicherheitsteams zu bewerten, wie diese Techniken implementiert werden, und sicherzustellen, dass die Zugriffskontrolle, die Verarbeitung von Antworten und die ethischen Sicherheitsvorkehrungen nicht beeinträchtigt werden.

• Risiken der Feinabstimmung - Die Feinabstimmung eines Modells auf sensible oder geschützte Daten ohne angemessene Maskierung kann dazu führen, dass vertrauliche Informationen versehentlich an Endbenutzer weitergegeben werden. So kann beispielsweise die Feinabstimmung eines Modells auf interne Regierungsberichte oder Kundendaten ohne Zugriffskontrollen auf Chat-Ebene zu einer unbefugten Offenlegung führen. Sicherheitsteams sollten Datensätze für die Feinabstimmung überprüfen und sicherstellen, dass für die Modellausgabe zugriffsgesteuerte Grenzen durchgesetzt werden, insbesondere wenn Modelle in Umgebungen mit mehreren Benutzern eingesetzt werden.
  
• Fehlkonfigurationen bei der RAG-Integration - RAG (Retrieval Augmented Generation) erweitert das Wissen eines LLM, indem es Kontext aus einer benutzerdefinierten Wissensdatenbank abruft. Wenn jedoch auf der Abrufebene keine Zugriffskontrollen implementiert sind, können sensible Daten nach außen dringen. So kann ein Benutzer beispielsweise auf die Finanzdaten eines anderen Benutzers zugreifen, wenn das RAG-System wahllos Dokumente abruft. Sicherheitsteams sollten die RAG-Implementierung im Hinblick auf die Durchsetzung von Zugriffskontrollen, den Dokumentenumfang und die Prüfbarkeit der abgerufenen Inhalte bewerten.
  
• RAI-Ergebnisse (Responsible AI) nach der Feinabstimmung - Die Feinabstimmung kann zwar die Sicherheit des Modells verbessern, sie kann aber auch die Erkennung von unerwünschtem Verhalten oder Richtlinienverstößen erschweren, insbesondere wenn das Modell gelernt hat, die Erkennung auf subtile Weise zu vermeiden. Sicherheitsexperten sollten mit RAI-Teams zusammenarbeiten, um auch bei Modellen, die für die Feinabstimmung optimiert wurden, auf unerwünschte Umgehungen der Eingabeaufforderung und Sicherheitsverstöße zu testen.
  
• Prompt-Engineering-Oberfläche - Schlecht gestaltete Prompts oder Systemanweisungen können zu unbeabsichtigtem Modellverhalten oder Prompt-Injection-Schwachstellen führen, insbesondere wenn Modelle in Anwendungen integriert sind. Obwohl Prompt-Engineering im Allgemeinen als risikoarme Technik angesehen wird, sollten Sicherheitsteams System-Prompts und Prompt-Konstrukte auf der Anwendungsebene bewerten, um sicherzustellen, dass sie gegen feindliche Eingaben resistent sind und kritisches Sicherheitsverhalten nicht außer Kraft setzen.

Phase 6: API-Integration

An diesem Punkt des Lebenszyklus verwandelt sich der LLM von einem passiven Chatbot in eine aktive Systemkomponente, die über APIs mit echten Anwendungen und Diensten interagieren kann. Ob es um das Zurücksetzen von Passwörtern, den Abruf interner Daten oder die Bearbeitung von Benutzeranfragen geht, die API-Integration bringt erhebliche neue Möglichkeiten und damit verbundene Risiken mit sich. Aus der Sicherheitsperspektive ist dies die Phase, in der herkömmliche API-Sicherheitsprinzipien mit LLM-spezifischen Problemen wie Prompt Injection, indirekter Ausführung und Absichtsmanipulation zusammenlaufen. Dies ist eine der kritischsten Phasen für offensive Tests, insbesondere wenn LLM-gesteuerte Anwendungen beginnen, Entscheidungen zu treffen und im Namen von Benutzern zu handeln.

• Authentifizierungs- und Autorisierungsprobleme - Wenn LLMs beginnen, API-Aufrufe auszulösen, muss sichergestellt werden, dass nur autorisierte Benutzer sensible Aktionen durchführen können. Sicherheitsteams sollten für eine starke Authentifizierung (z.B. OAuth, API-Schlüssel) und erweiterte Berechtigungen sorgen, damit das Modell keine privilegierten Aktionen im Namen von nicht autorisierten Benutzern durchführen kann.
  
• Prompt Injection und API-Missbrauch - LLMs interpretieren natürliche Sprache und entscheiden anhand der Benutzereingaben, welche API aufgerufen werden soll. Angreifer können versuchen, Prompts zu manipulieren, um unbeabsichtigtes oder schädliches Verhalten hervorzurufen. Sicherheitsteams sollten auf Schwachstellen bei Prompt Injection testen und sicherstellen, dass das Modell nicht dazu verleitet werden kann, die falsche API aufzurufen oder die Sicherheitskontrollen zu umgehen.
  
• Fehlende Eingabevalidierung - Wenn Benutzereingaben in APIs nicht ordnungsgemäß validiert werden, kann dies zu Fehlern, Datenlecks oder sogar Injektionsangriffen führen. Sicherheitsteams sollten sicherstellen, dass Middleware- und API-Schichten alle Eingaben validieren und bereinigen, unabhängig davon, ob sie von einem Benutzer oder dem LLM stammen.
  
• Übermäßig freigegebene Funktionen - APIs können mehr Funktionen freigeben, als der LLM benötigt, was das Risiko des Missbrauchs erhöht. Die Sicherheit sollte das Prinzip der geringsten Privilegien durchsetzen, so dass das Modell nur auf die Endpunkte zugreifen kann, die es wirklich benötigt.
  
• Relevante OWASP LLM-Risiken - Viele Risiken in dieser Phase entsprechen den Top OWASP-Risiken. Sicherheitsexperten sollten diese Liste als Leitfaden für die Tests heranziehen.

Fazit

Die Absicherung eines LLM ist eine komplexe und vielschichtige Herausforderung, die ein umfassendes, schrittweises Vorgehen erfordert. Durch die Zusammenarbeit mit einem erfahrenen Sicherheitsteam können sich Unternehmen durch die einzigartigen Sicherheitsüberlegungen bei der Entwicklung und Implementierung von LLMs arbeiten und sicherstellen, dass ihre Modelle robust und zuverlässig sind und den einschlägigen Vorschriften und Branchenstandards entsprechen. Wenn Sie der Sicherheit von Anfang an Priorität einräumen, können Unternehmen das volle Potenzial von LLMs nutzen und gleichzeitig ihre Daten, Systeme und ihren Ruf schützen.