AWS Germany – Amazon Web Services in Deutschland

Methodik für die Reaktion auf Vorfälle bei Generative-KI-Workloads

von Anna McAbee, Jennifer Paz, AJ Evans, and Steve de Vera, übersetzt von Tobias Nitzsche.

Das AWS Customer Incident Response Team (CIRT) hat eine Methodik entwickelt, die Sie bei der Untersuchung von Sicherheitsvorfällen im Zusammenhang mit Generativen-KI-Anwendungen nutzen können. Bei der Reaktion auf sicherheitsrelevante Ereignisse bei Generativen-KI-Workloads sollten Sie weiterhin den Empfehlungen und Grundsätzen des AWS Security Incident Response Guide folgen. Allerdings erfordern Generative-KI-Workloads die Berücksichtigung einiger zusätzlicher Aspekte, die wir in diesem Blogbeitrag näher erläutern.

Zunächst beschreiben wir die typischen Komponenten eines Generative-KI-Workloads und erörtern, wie Sie sich auf mögliche Ereignisse vorbereiten können. Anschließend stellen wir die Methodik zur Reaktion auf Vorfälle bei Generative-KI-Workloads vor, die sich aus sieben Elementen zusammensetzt. Diese Elemente sollten bei der Bewertung und Behandlung eines Sicherheitsereignisses in einem Generative-KI-Workload berücksichtigt werden. Abschließend teilen wir ein Beispielszenario, anhand dessen Sie die praktische Anwendung der Methodik nachvollziehen können.

Komponenten eines Generative-KI-Workloads

Wie in Abbildung 1 dargestellt, umfassen Generative-KI-Anwendungen die folgenden fünf Komponenten:

  • Eine Organisation, Verantwortlich für oder Besitzer von Infrastruktur, Generative-KI-Anwendungen und privaten Daten.
  • Infrastruktur innerhalb einer Organisation, die nicht spezifisch mit der Generative-KI-Anwendung selbst verbunden ist. Dazu können Datenbanken, Backend-Server und Websites gehören.
  • Generative-KI-Anwendungen, die Folgendes umfassen:
    • Basismodelle (engl. Foundation Models, FMs) – KI-Modelle mit einer großen Anzahl von Parametern, die mit enormen Mengen verschiedenartiger Daten trainiert wurden.
    • Angepasste Modelle – Modelle, die auf die spezifischen Daten und Anwendungsfälle einer Organisation abgestimmt oder damit trainiert wurden.
    • Guardrails – Mechanismen oder Einschränkungen, die sicherstellen sollen, dass die Generative-KI-Anwendung innerhalb gewünschter Grenzen arbeitet (z.B. Inhaltsfilterung, Sicherheitsbeschränkungen oder ethische Richtlinien).
    • Agents – Workflows, die es Generative-KI-Anwendungen ermöglichen, mehrstufige Aufgaben über verschiedene Unternehmenssysteme und Datenquellen hinweg auszuführen.
    • Wissensdatenbanken – Sammlungen von domänenspezifischem Wissen, Regeln oder Daten, auf die Generative-KI-Anwendungen zugreifen können.
    • Trainingsdaten – Daten zum Trainieren, Fine-Tuning oder zur Erweiterung der Generative-KI-Modelle, einschließlich Daten für Techniken wie Retrieval Augmented Generation (RAG)
      Hinweis: Trainingsdaten unterscheiden sich von den privaten Daten einer Organisation. Eine Generative-KI-Anwendung hat möglicherweise keinen direkten Zugriff auf private Daten, auch wenn dies in manchen Umgebungen so konfiguriert sein kann.
    • Plugins – zusätzliche Software-Komponenten oder Erweiterungen, die sich in die Generative-KI-Anwendung integrieren lassen und zusätzliche Funktionen oder Zugriff auf externe Dienste oder Datenquellen bereitstellen.
  • Private Daten beziehen sich auf die vertraulichen, privat gespeicherten Daten des Kunden, mit denen die Generative-KI-Ressourcen oder -Anwendungen im normalen Betrieb nicht interagieren sollen.
  • Nutzende sind die Identitäten, die mit der Generativen-KI-Anwendung interagieren oder darauf zugreifen können. Dies können sowohl Menschen als auch Nicht-Menschen (wie Maschinen) sein.
Abbildung 1: Häufige Komponenten eines KI/ML-Workload

Abbildung 1: Häufige Komponenten eines KI/ML-Workload

Vorbereitung auf die Reaktion bei Vorfällen mit Generative-KI-Workloads

Die Vorbereitung auf ein Sicherheitsereignis sollte in drei Bereichen erfolgen: Mitarbeitende, Prozesse und Technologie. Eine Zusammenfassung der Vorbereitungsmaßnahmen finden Sie im Security Incident Response Guide. Für Sicherheitsereignisse im Zusammenhang mit Generative-KI-Workloads sollten Sie zusätzlich Folgendes beachten:

Diese Playbooks können als Ausgangspunkt dienen und an die spezifischen Anforderungen Ihrer Organisation und Nutzung der Services angepasst werden.

Methodik für die Reaktion auf Vorfälle mit Generative-KI-Workloads

Nach Abschluss der Vorbereitungsmaßnahmen können Sie die Methodik für die Reaktion auf Vorfälle bei Generativen-KI-Workloads für die aktive Reaktion nutzen. Diese hilft Ihnen bei der schnellen Bewertung eines aktiven Sicherheitsereignisses im Zusammenhang mit einer Generativen-KI-Anwendung.

Die Methodik besteht aus sieben Elementen, die wir in diesem Abschnitt detailliert beschreiben. Jedes Element beschreibt eine Methode, wie Komponenten miteinander interagieren oder wie eine Komponente modifiziert werden kann. Die Berücksichtigung dieser Elemente unterstützt Ihre Maßnahmen während der operativen Phase eines Sicherheitsvorfalls, die die Phasen Erkennung, Analyse, Eindämmung, Beseitigung und Wiederherstellung umfasst.

  • Zugriff – Ermitteln Sie die vorgesehenen Zugriffsmuster für die Organisation, die die Komponenten der Generative-KI-Anwendung bereitstellt – Suchen Sie nach Abweichungen oder Anomalien von diesen Mustern. Berücksichtigen Sie, ob die Anwendung extern oder intern zugänglich ist, da dies Ihre Analyse beeinflusst.Amazon GuardDuty kann Sie bei der Identifizierung anomaler und potenziell unbefugter Zugriffe auf Ihre AWS-Umgebung unterstützen. Bei extern zugänglichen Anwendungen hat ein Angreifer möglicherweise keinen direkten Zugriff auf Ihre AWS-Umgebung, wodurch GuardDuty den Zugriff nicht erkennen kann. Die Art Ihrer Anwendungsauthentifizierung bestimmt, wie Sie unbefugte Zugriffe erkennen und analysieren.Bei Anzeichen für unbefugten Zugriff auf Ihr AWS-Konto oder die zugehörige Infrastruktur: Ermitteln Sie den Umfang des unbefugten Zugriffs (zugehörige Berechtigungen und Zeitrahmen). Überprüfen Sie bei unbefugtem Zugriff auf Service-Anmeldeinformationen – z.B. Amazon Elastic Compute Cloud (Amazon EC2)-Instanz-Anmeldeinformationen – den Service auf Schwachstellen
  • Infrastrukturänderungen – Überprüfen Sie die unterstützende Infrastruktur (Server, Datenbanken, Serverless-Computing-Instanzen, interne oder externe Websites) auf Zugriffe oder Änderungen. Analysieren Sie CloudTrail-Logs auf Änderungen der betroffenen Ressourcen. Untersuchen Sie Betriebssystem-Logs oder Datenbankzugriffsprotokolle
  • KI-Änderungen – Untersuchen Sie, ob Benutzer auf Komponenten der generativen KI-Anwendung zugegriffen und ob sie Änderungen an diesen Komponenten vorgenommen haben. Achten Sie auf Anzeichen unbefugter Aktivitäten, wie zum Beispiel das Erstellen oder Löschen benutzerdefinierter Modelle, die Änderung der Modellverfügbarkeit, die Manipulation oder Löschung von Protokollierungsfunktionen der generativen KI, die Manipulation des Anwendungscodes sowie das Entfernen oder die Änderung von Schutzmaßnahmen der generativen KI.
  • Änderungen am Datenspeicher – Ermitteln Sie die vorgesehenen Datenzugriffsmuster. Prüfen Sie, ob Nutzende auf die Datenspeicher Ihrer Generative-KI-Anwendung zugegriffen haben. Untersuchen Sie mögliche Änderungen an diesen Datenspeichern. Achten Sie auf das Hinzufügen oder Ändern von Agents in der Generative-KI-Anwendung.
  • Aufrufe – Analysieren Sie die Aufrufe von Generative-KI-Modellen, einschließlich der Zeichenketten und Dateieingaben, auf Bedrohungen wie Prompt Injection oder Malware. Die OWASP Top 10 für LLM [EN, Extern] können als Ausgangspunkt dienen, um aufrufbezogene Bedrohungen zu verstehen. Nutzen Sie Aufrufprotokolle, um Prompts auf verdächtige Muster, Schlüsselwörter oder Strukturen zu untersuchen, die auf einen Prompt-Injection-Versuch hinweisen könnten. Die Protokolle erfassen auch die Ausgaben und Antworten des Modells und ermöglichen so Verhaltensanalysen, die bei der Identifizierung von uncharakteristischem oder unsicherem Modellverhalten helfen, das auf eine Prompt Injection hinweisen könnte. Die Zeitstempel in den Protokollen können für zeitliche Analysen genutzt werden, um koordinierte Prompt-Injection-Versuche im Zeitverlauf zu erkennen und Informationen über Benutzer:innen oder Systeme zu sammeln, die den Modellaufruf initiiert haben, was bei der Identifizierung der Quelle potenzieller Exploits hilft.
  • Private Daten – Stellen Sie fest, ob die betroffene Generative-KI-Anwendung für den Zugriff auf private oder vertrauliche Daten konzipiert wurde. Suchen Sie anschließend nach nicht autorisierten Zugriffen auf diese Daten oder Manipulationen daran.
  • Handlungsfähigkeit – Handlungsfähigkeit bezieht sich auf die Fähigkeit von Anwendungen, Änderungen an den Ressourcen einer Organisation vorzunehmen oder Aktionen im Namen von Benutzer:innen durchzuführen. Eine Generative-KI-Anwendung könnte beispielsweise so konfiguriert sein, dass sie Inhalte generiert, die dann zum Versenden einer E-Mail verwendet werden, wobei eine andere Ressource oder Funktion aufgerufen wird. Sie sollten ermitteln, ob die Generative-KI-Anwendung die Fähigkeit hat, andere Funktionen aufzurufen. Untersuchen Sie dann, ob nicht autorisierte Änderungen vorgenommen wurden oder ob die Generative-KI-Anwendung nicht autorisierte Funktionen aufgerufen hat.

Die folgende Tabelle enthält Fragen, die Ihnen bei der Bearbeitung der sieben Elemente der Methodik helfen. Nutzen Sie Ihre Antworten als Leitfaden für Ihre Reaktion.

Thema

Zu klärende Fragen

Zugriff

Haben Sie noch Zugriff auf Ihre Computerumgebung? <br> • Gibt es weiterhin Anzeichen für nicht autorisierten Zugriff auf Ihre Organisation?

Infrastrukturänderungen

Wurde auf unterstützende Infrastrukturressourcen zugegriffen oder wurden diese verändert?

KI-Änderungen

Wurde auf Ihre KI-Modelle, Code oder Ressourcen zugegriffen oder wurden diese verändert?

Änderungen am Datenspeicher

Wurde auf Ihre Datenspeicher, Wissensdatenbanken, Agenten, Plugins oder Trainingsdaten zugegriffen oder wurden diese manipuliert?

Aufrufe

Welche Daten, Zeichenketten oder Dateien wurden als Eingabe an das Modell gesendet?

Welche Prompts wurden gesendet?

Welche Antworten wurden erzeugt?

Private Daten

Auf welche privaten oder vertraulichen Daten haben Generative-KI-Ressourcen Zugriff?

Wurden private Daten verändert oder manipuliert?

Handlungsfähigkeit

Können die Generative-KI-Anwendungsressourcen verwendet werden, um Computerdienste in einer Organisation zu starten, oder haben die Generative-KI-Ressourcen die Berechtigung, Änderungen vorzunehmen?

Wurden nicht autorisierte Änderungen vorgenommen?

Beispielvorfall

Um zu verstehen, wie die Methodik bei Untersuchung und Reaktion angewendet wird, gehen wir einen beispielhaften Sicherheitsvorfall durch: Ein nicht autorisierter Benutzer kompromittiert eine auf AWS gehostete Generative-KI-Anwendung mithilfe von Anmeldeinformationen, die in einem öffentlichen Code-Repository exponiert wurden. Unser Ziel ist es zu ermitteln, auf welche Ressourcen zugegriffen wurde und welche modifiziert, erstellt oder gelöscht wurden.

Zur Untersuchung von Generative-KI-Sicherheitsvorfällen auf AWS sollten Sie die folgenden wichtigen Protokollquellen überprüfen:

Zugang

Die Zugangsanalyse für eine Generative-KI-Anwendung ähnelt der einer Standard-Drei-Tier-Webanwendung. Ermitteln Sie zunächst, ob eine Organisation Zugriff auf ihr AWS-Konto hat. Falls das Passwort für den AWS-Stammbenutzer (Root User) verloren ging oder geändert wurde, setzen Sie es zurück. Wir empfehlen dringend, sofort eine Multi-Faktor-Authentifizierung (MFA) für den Root User zu aktivieren – dies sollte verhindern, dass potenzielle Angreifer auf den Root User zugreifen können.

Stellen Sie als Nächstes fest, ob weiterhin nicht autorisierte Zugriffe auf das Konto bestehen. Um verändernde Aktionen zu identifizieren, die von AWS Identity and Access Management (IAM) und AWS Security Token Service (Amazon STS) protokolliert wurden, konsultieren Sie den Analyseabschnitt [EN, Extern] des „Compromised IAM Credentials“-Playbooks [EN, Extern] auf GitHub. Stellen Sie abschließend sicher, dass keine Zugriffsschlüssel in öffentlichen Repositories oder in Ihrem Anwendungscode gespeichert sind. Alternativen finden Sie unter „Alternativen zu langfristigen Zugriffsschlüsseln„.

Infrastrukturänderungen

Bei der Analyse von Infrastrukturänderungen einer Anwendung sollten Sie sowohl die Control Plane als auch die Data Plane berücksichtigen. In unserem Beispiel nehmen wir an, dass Amazon API Gateway für die Authentifizierung der nachgelagerten Komponenten der Generative-KI-Anwendung verwendet wurde und andere Hilfsressourcen mit Ihrer Anwendung interagiert haben. Während Sie Änderungen an der Control Plane dieser Ressourcen in CloudTrail überprüfen können, müssen Sie zusätzliche Protokollierung aktivieren, um Änderungen am Betriebssystem der Ressource zu überprüfen. Hier einige häufige Namen für Control-Plane-Ereignisse, die Sie in CloudTrail für dieses Element finden könnten:

  • ec2:RunInstances
  • ec2:StartInstances
  • ec2:TerminateInstances
  • ecs:CreateCluster
  • cloudformation:CreateStack
  • rds:DeleteDBInstance
  • rds:ModifyDBClusterSnapshotAttribute

KI-Änderungen

Zu den nicht autorisierten Änderungen können unter anderem Systemprompts, Anwendungscode, Schutzmaßnahmen und Modellverfügbarkeit gehören. Interne Benutzerzugriffe auf die von AWS gehosteten Generative-KI-Ressourcen werden in CloudTrail protokolliert und erscheinen mit einer der folgenden Ereignisquellen:

  • bedrock.amazonaws.com
  • sagemaker.amazonaws.com
  • qbusiness.amazonaws.com
  • q.amazonaws.com

Hier einige Beispiele für Ereignisnamen in CloudTrail, die in unserem Beispielszenario eine Manipulation der Generative-KI-Ressourcenprotokolle darstellen würden:

  • bedrock:PutModelInvocationLoggingConfiguration
  • bedrock:DeleteModelInvocationLoggingConfiguration

Folgende häufige Ereignisnamen in CloudTrail würden den Zugriff auf die KI/ML-Modelldienstkonfiguration darstellen:

  • bedrock:GetFoundationModelAvailability
  • bedrock:ListProvisionedModelThroughputs
  • bedrock:ListCustomModels
  • bedrock:ListFoundationModels
  • bedrock:ListProvisionedModelThroughput
  • bedrock:GetGuardrail
  • bedrock:DeleteGuardrail

In unserem Beispielszenario hat der nicht autorisierte Benutzer Zugriff auf das AWS-Konto erlangt. Stellen Sie sich vor, dass der kompromittierte Benutzer eine Policy zugewiesen bekommen hat, die vollen Zugriff auf alle Ressourcen gewährt. Mit diesem Zugriff kann der nicht autorisierte Benutzer jede Komponente von Amazon Bedrock auflisten und die Wissensdatenbank sowie Schutzmaßnahmen identifizieren, die Teil der Anwendung sind.

Der nicht autorisierte Benutzer fordert dann Modellzugriff auf weitere Basismodelle (engl. Foundation Models, FMs) innerhalb von Amazon Bedrock an und entfernt bestehende Schutzmaßnahmen. Der Zugriff auf weitere Foundation Models könnte darauf hinweisen, dass der nicht autorisierte Benutzer die Generative-KI-Anwendung für eigene Zwecke nutzen möchte, und die Entfernung von Schutzmaßnahmen minimiert die Filterung oder Ausgabeprüfungen durch das Modell. AWS empfiehlt die Implementierung feingranularer Zugriffskontrollen mithilfe von IAM-Policies und ressourcenbasierten Policies, um den Zugriff auf nur die notwendigen Amazon Bedrock-Ressourcen, AWS Lambda-Funktionen und andere erforderliche Anwendungskomponenten zu beschränken. Außerdem sollten Sie die Verwendung von MFA für IAM-Benutzer, -Rollen und Service-Konten erzwingen, die Zugriff auf kritische Komponenten wie Amazon Bedrock und andere Komponenten Ihrer Generative-KI-Anwendung haben.

Änderungen am Datenspeicher

Typischerweise werden Datenspeicher und Wissensdatenbank über Modellaufrufe genutzt und aufgerufen, bei Amazon Bedrock geschieht dies über den API-Aufruf bedrock:InvokeModel.

Wenn jedoch ein nicht autorisierter Benutzer Zugriff auf die Umgebung erlangt, kann dieser die Datenquellen und Wissensdatenbanken, mit denen die Generative-KI-Anwendungen integriert sind, erstellen, ändern oder löschen. Dies könnte zu Daten- oder Modellexfiltration, Zerstörung sowie Datenvergiftung führen und einen Denial-of-Service-Zustand für das Modell verursachen. Hier einige häufige Ereignisnamen in CloudTrail, die in unserem Beispielszenario Änderungen an KI/ML-Datenquellen darstellen würden:

  • bedrock:CreateDataSource
  • bedrock:GetKnowledgeBase
  • bedrock:DeleteKnowledgeBase
  • bedrock:CreateAgent
  • bedrock:DeleteAgent
  • bedrock:InvokeAgent
  • bedrock:Retrieve
  • bedrock:RetrieveAndGenerate

Die vollständige Liste möglicher Aktionen finden Sie in der Amazon Bedrock API-Referenz.

In diesem Szenario haben wir festgestellt, dass der nicht autorisierte Benutzer vollen Zugriff auf die Generative-KI-Anwendung hat und eine gewisse Aufzählung stattgefunden hat. Der nicht autorisierte Benutzer hat dann den S3-Bucket identifiziert, der als Wissensdatenbank für die Generative-KI-Anwendung diente, und ungenaue Daten hochgeladen, wodurch das LLM korrumpiert wurde. Beispiele für diese Schwachstelle finden Sie im Abschnitt „LLM03 Training Data Poisoning“ in den OWASP TOP 10 für LLM-Anwendungen [EN, Extern].

Aufrufe

Amazon Bedrock verwendet spezifische APIs zur Protokollierung von Modellaufrufen. Wenn ein Modell in Amazon Bedrock aufgerufen wird, protokolliert CloudTrail dies. Um jedoch die Prompts zu ermitteln, die an das Generative-KI-Modell gesendet wurden, und die Ausgabeantwort, die von ihm empfangen wurde, muss die Protokollierung von Modellaufrufen konfiguriert sein.

Diese Protokolle sind entscheidend, da sie wichtige Informationen offenbaren können, zum Beispiel ob ein Angreifer versuchte, das Modell dazu zu bringen, Informationen aus Ihren Datenspeichern preiszugeben oder Daten zu veröffentlichen, auf denen das Modell trainiert oder feinabgestimmt wurde. Die Protokolle könnten beispielsweise aufdecken, ob ein Angreifer versuchte, das Modell mit sorgfältig gestalteten Eingaben zu prompt-en, die darauf ausgelegt waren, sensible Daten zu extrahieren, Sicherheitskontrollen zu umgehen oder Inhalte zu generieren, die gegen Ihre Richtlinien verstoßen. Anhand der Protokolle können Sie auch erkennen, ob das Modell zur Generierung von Fehlinformationen, Spam oder anderen schädlichen Ausgaben verwendet wurde, die bei einem Sicherheitsvorfall eingesetzt werden könnten.

Hinweis: Bei Diensten wie Amazon Bedrock ist die Aufrufprotokollierung standardmäßig deaktiviert. Wir empfehlen, Datenereignisse und Modellaufrufprotokolle für Generative-KI-Dienste zu aktivieren, wo verfügbar. Allerdings möchte Ihre Organisation aus Datenschutz- und rechtlichen Gründen möglicherweise keine Aufrufprotokolle erfassen und speichern. Ein häufiges Bedenken ist, dass Benutzer:innen sensible Daten als Eingabe verwenden, was den Umfang der zu schützenden Assets erweitert. Dies ist eine Geschäftsentscheidung, die berücksichtigt werden sollte.

In unserem Beispielszenario nehmen wir an, dass die Modellaufrufprotokollierung nicht aktiviert war, sodass die Incident Responder keine Aufrufprotokolle sammeln konnten, um die Modelleingabe- oder -ausgabedaten für nicht autorisierte Aufrufe zu sehen. Sie konnten nicht feststellen, welche Prompts an das LLM gesendet wurden und welche Antworten es darauf gab. Ohne aktivierte Protokollierung konnten sie auch nicht die vollständigen Anfragedaten, Antwortdaten und Metadaten im Zusammenhang mit den Aufrufen einsehen.

Ereignisnamen in Modellaufrufprotokollen, die die Modellaufrufprotokollierung in Amazon Bedrock darstellen, umfassen:

  • bedrock:InvokeModel
  • bedrock:InvokeModelWithResponseStream
  • bedrock:Converse
  • bedrock:ConverseStream

Hier ein Beispiel für einen Protokolleintrag der Amazon Bedrock Modellaufrufprotokollierung:

Abbildung 2: Beispiel-Modellaufrufprotokoll einschließlich Eingabeaufforderung und Antwort

Abbildung 2: Beispiel-Modellaufrufprotokoll einschließlich Eingabeaufforderung und Antwort

Private Daten

Aus architektonischer Sicht sollten Generative-KI-Anwendungen keinen direkten Zugriff auf private Daten einer Organisation haben. Sie sollten Daten, die zum Training einer Generative-KI-Anwendung oder für RAG verwendet werden, als Datenspeicherdaten klassifizieren und von privaten Daten trennen, es sei denn, die Generative-KI-Anwendung verwendet die privaten Daten (zum Beispiel, wenn eine Generative-KI-Anwendung die Aufgabe hat, Fragen zu Patientenakten zu beantworten). Eine Möglichkeit sicherzustellen, dass die privaten Daten einer Organisation von Generative-KI-Anwendungen getrennt bleiben, ist die Verwendung eines separaten Accounts sowie die Authentifizierung und Autorisierung von Zugriffen nach dem Prinzip der geringsten Privilegien.

Handlungsfähigkeit

Übermäßige Handlungsfähigkeit [EN, Extern] eines LLM bezieht sich auf ein KI-System, das zu viel Autonomie oder Entscheidungsgewalt hat, was zu unbeabsichtigten und potenziell schädlichen Konsequenzen führen kann. Dies kann passieren, wenn ein LLM mit unzureichender Überwachung, zu wenig Einschränkungen oder mangelnder Ausrichtung an menschlichen Werten eingesetzt wird, was dazu führt, dass das Modell Entscheidungen trifft, die von dem abweichen, was die meisten Menschen als vorteilhaft oder ethisch betrachten würden.

In unserem Beispielszenario hat die Generative-KI-Anwendung übermäßige Berechtigungen für Dienste, die von der Anwendung nicht benötigt werden. Stellen Sie sich vor, dass der Anwendungscode mit einer Ausführungsrolle läuft, die vollen Zugriff auf Amazon Simple Email Service (Amazon SES) hat. Dies könnte es dem nicht autorisierten Benutzer ermöglichen, als Reaktion auf einen Prompt Spam-E-Mails im Namen der Benutzer:innen zu versenden. Sie können dies verhindern, indem Sie die Berechtigungen und Funktionalität der Plugins und Agenten der Generative-KI-Anwendung einschränken. Weitere Informationen finden Sie unter OWASP Top 10 für LLMs [EN, Extern], Nachweis von LLM08 Excessive Agency.

Während einer Untersuchung werden bei der Analyse der Protokolle sowohl die sourceIPAddress– als auch die userAgent-Felder mit der Generative-KI-Anwendung verknüpft sein (zum Beispiel sagemaker.amazonaws.com, bedrock.amazonaws.com oder q.amazonaws.com). Einige Beispiele für Dienste, die häufig von anderen Diensten aufgerufen werden können, sind Lambda, Amazon SNS und Amazon SES.

Fazit

Bei der Reaktion auf Sicherheitsvorfälle im Zusammenhang mit Generative-KI-Workloads sollten Sie weiterhin den Leitlinien und Prinzipien folgen, die im AWS Security Incident Response Guide beschrieben sind. Diese Workloads erfordern jedoch auch die Berücksichtigung einiger zusätzlicher Elemente.

Sie können die in diesem Beitrag vorgestellte Methodik nutzen, um diese neuen Elemente zu adressieren. Sie können sich auf diese Methodik beziehen, wenn Sie nicht autorisierten Zugriff auf Infrastruktur untersuchen, bei der die Nutzung von Generative-KI-Anwendungen entweder Ziel der nicht autorisierten Nutzung, der Mechanismus für die nicht autorisierte Nutzung oder beides ist. Die Methodik bietet Ihnen einen strukturierten Ansatz zur Vorbereitung und Reaktion auf Sicherheitsvorfälle mit Generative-KI-Workloads und hilft Ihnen dabei, die Sicherheit und Integrität dieser kritischen Anwendungen zu gewährleisten.

Weitere Informationen zu Best Practices für die Gestaltung Ihrer Generative-KI-Anwendung finden Sie unter „Generative KI für AWS SRA„. Informationen zu taktischen Gegenmaßnahmen für eine gängige Generative-KI-Anwendung finden Sie im „Blueprint for secure design and anti-pattern mitigation“ [EN].

Wenn Sie Feedback zu diesem Beitrag haben, hinterlassen Sie bitte Kommentare im Kommentarbereich unten. Wenn Sie Fragen zu diesem Beitrag haben, starten Sie einen neuen Thread im AWS Security, Identity, & Compliance re:Post [EN] oder kontaktieren Sie den AWS Support.

Über die Autor:innen

Anna McAbee
Anna McAbee ist Security Specialist Solutions Architect mit Schwerpunkt auf Finanzdienstleistungen, Generative KI und Vorfallsbearbeitung bei AWS. Außerhalb der Arbeit interessiert sie sich für Taylor Swift, feuert das Football-Team der Florida Gators an, genießt Weinverkostungen und bereist die Welt.
Steve De Vera
Steve De Vera ist Manager im AWS Customer Incident Response Team (CIRT). Er ist leidenschaftlicher Fan von amerikanischem BBQ und zertifizierter BBQ-Wettbewerbsjuror. Er hat einen Hund namens Brisket.
AJ Evans
AJ Evans ist Security Engineer im AWS Customer Incident Response Team (CIRT). Er nutzt seine Erfahrung als ehemaliger Special Agent des U.S. Secret Service, wo er sich auf Finanzkriminalität und Netzwerkintrusion konzentrierte, um AWS-Kunden zu schützen. Wenn er nicht gerade auf die neuesten Cyber-Bedrohungen reagiert, spielt AJ gerne Videospiele und Musik, baut Custom-PCs und druckt seine eigenen Kreationen in 3D.
Jennifer Paz
Jennifer Paz ist Security Engineer mit über einem Jahrzehnt Erfahrung und arbeitet derzeit im AWS Customer Incident Response Team (CIRT). Jennifer unterstützt gerne Kunden bei der Bewältigung von Sicherheitsherausforderungen und der Implementierung komplexer Lösungen zur Verbesserung ihrer Sicherheitslage. Außerhalb der Arbeit ist Jennifer eine begeisterte Wanderin, Joggerin und Pickleball-Enthusiastin, reist gerne und ist als Feinschmeckerin stets auf der Suche nach neuen kulinarischen Abenteuern.