Elastic verbessert die LLM-Sicherheit mit standardisierten Feldern und Integrationen

Einführung

Letzte Woche hat der Sicherheitsforscher Mika Ayenson eine Veröffentlichung verfasst , in der potenzielle Erkennungsstrategien und ein Prototyp einer LLM-Content-Auditing-Lösung über einen Proxy vorgestellt werden, der während der OnWeek-Veranstaltungsreihe von Elastic implementiert wurde. In diesem Beitrag wurde die Bedeutung der Forschung zur Sicherheit der LLM-Technologie, die in verschiedenen Umgebungen implementiert wird, und der Forschungsschwerpunkt, den wir bei Elastic Security Labs eingenommen haben, hervorgehoben.

Angesichts des einzigartigen Blickwinkels von Elastic, der die LLM-Technologie in unserer Plattform nutzt, um Funktionen wie den Security AI Assistant zu unterstützen, ist unser Wunsch nach formelleren Erkennungsregeln, Integrationen und Forschungsinhalten gewachsen. Diese Veröffentlichung beleuchtet einige der jüngsten Fortschritte, die wir bei LLM-Integrationen erzielt haben, unsere Gedanken zu Erkennungen, die an Industriestandards angepasst sind, und ECS-Feldzuordnungen.

Wir verpflichten uns zu einer umfassenden Sicherheitsstrategie, die nicht nur die direkten benutzerbasierten LLM-Interaktionen schützt, sondern auch das breitere Ökosystem, das sie umgibt. Dieser Ansatz umfasst Schichten von Security Detection Engineering-Möglichkeiten, um nicht nur die LLM-Anfragen/-Antworten, sondern auch die zugrunde liegenden Systeme und Integrationen zu berücksichtigen, die von den Modellen verwendet werden.

Diese Erkennungsmöglichkeiten tragen zusammen zur Sicherung des LLM-Ökosystems bei und lassen sich grob in fünf Kategorien einteilen:

1. Prompt and Response: Erkennungsmechanismen zur Identifizierung und Abwehr von Bedrohungen auf der Grundlage der wachsenden Vielfalt von LLM-Interaktionen, um sicherzustellen, dass die gesamte Kommunikation sicher überwacht wird.
2. Infrastruktur und Plattform: Implementierung von Erkennungen zum Schutz der Infrastruktur, die LLMs hostet (einschließlich tragbarer KI-PIN-Geräte), einschließlich der Erkennung von Bedrohungen für die gespeicherten Daten, Verarbeitungsaktivitäten und Serverkommunikation.
3. API und Integrationen: Erkennen von Bedrohungen bei der Interaktion mit LLM-APIs und Schützen von Integrationen mit anderen Anwendungen, die Modellausgaben aufnehmen.
4. Operative Prozesse und Daten: Überwachung von Betriebsprozessen (auch in KI-Agenten) und Datenflüssen bei gleichzeitigem Schutz der Daten während ihres gesamten Lebenszyklus.
5. Compliance und Ethik: Ausrichtung der Erkennungsstrategien an den gängigen Branchenvorschriften und ethischen Standards.

Sicherung des LLM-Ökosystems: fünf Kategorien

Eine weitere wichtige Überlegung für diese Kategorien erstreckt sich darauf, wer am besten mit Risiken umgehen kann oder wer für jede Risikokategorie im Zusammenhang mit LLM-Systemen verantwortlich ist.

Ähnlich wie bei bestehenden Modellen der gemeinsamen Sicherheitsverantwortung hat Elastic vier große Kategorien bewertet, die im Laufe unserer Forschung zu Detection-Engineering-Strategien und -Integrationen weiter ausgebaut werden. Im Großen und Ganzen befasst sich diese Veröffentlichung mit Sicherheitsmaßnahmen, die die folgenden Verantwortlichen einbeziehen:

• LLM-Ersteller: Organisationen, die LLMs erstellen, entwerfen, hosten und schulen, wie z. B. OpenAI, Amazon Web Services oder Google
• LLM-Integratoren: Organisationen und Einzelpersonen, die bestehende LLM-Technologien, die von LLM-Entwicklern erstellt wurden, in andere Anwendungen integrieren
• LLM-Maintainer: Personen, die operative LLMs auf Anwendungsfälle in Bezug auf Leistung, Zuverlässigkeit, Sicherheit und Integrität überwachen und direkt an der Wartung der Codebasis, der Infrastruktur und der Softwarearchitektur beteiligt bleiben
• Sicherheitsbenutzer: Personen, die aktiv mit herkömmlichen Testmechanismen und -mitteln nach Schwachstellen in Systemen suchen. Dies kann über die traditionellen Risiken, die in den LLM Top 10 von OWASP diskutiert werden, hinausgehen und Risiken eingehen, die mit Software und Infrastruktur rund um diese Systeme verbunden sind

Diese breitere Perspektive zeigt einen einheitlichen Ansatz für die LLM-Erkennungstechnik, der mit der Aufnahme von Daten mithilfe nativer Elastic-Integrationen beginnt. In diesem Beispiel heben wir den Anwendungsfall AWS Bedrock Model Invocation hervor.

Integrieren von LLM-Protokollen in Elastic

Elastic-Integrationen vereinfachen die Datenaufnahme in Elastic aus verschiedenen Quellen und verbessern letztendlich unsere Sicherheitslösung. Diese Integrationen werden über Fleet in Kibana verwaltet, sodass Benutzer Daten innerhalb des Elastic Agent einfach bereitstellen und verwalten können. Benutzer können Elastic schnell an neue Datenquellen anpassen, indem sie Integrationen über Fleet auswählen und konfigurieren. Weitere Informationen finden Sie im Blog von Elastic zur Vereinfachung der Integration Ihrer Systeme mit Elastic.

Die erste ONWeek-Arbeit des Teams umfasste eine einfache Proxy-Lösung, die Felder aus Interaktionen mit dem Elastic Security AI Assistant extrahierte. Dieser Prototyp wurde zusammen mit dem Elastic Stack bereitgestellt und nutzte Daten von einer Anbieterlösung, der es an Sicherheitsprüfungsfunktionen mangelte. Diese erste Implementierung erwies sich zwar als konzeptionell interessant, veranlasste das Team jedoch, Zeit in die Bewertung bestehender Elastic-Integrationen von einem unserer Cloud-Anbieter-Partner, Amazon Web Services, zu investieren. Diese Methodik garantiert unseren Nutzern eine optimierte Zugänglichkeit und bietet nahtlose Ein-Klick-Integrationen für die Datenaufnahme. Alle Ingest-Pipelines entsprechen den ECS/OTel-Normalisierungsstandards und umfassen umfassende Inhalte, einschließlich Dashboards, in einem einheitlichen Paket. Darüber hinaus sind wir mit dieser Strategie in der Lage, zusätzliche bestehende Integrationen wie Azure und GCP für zukünftige LLM-fokussierte Integrationen zu nutzen.

Anbieterauswahl und API-Funktionen

Bei der Auswahl der LLM-Anbieter, für die Integrationen erstellt werden sollen, haben wir uns die Arten von Feldern angesehen, die wir für unsere Sicherheitsanwendungsfälle aufnehmen müssen. Für das hier beschriebene Startregelwerk benötigten wir Informationen wie Zeitstempel und Token-Anzahl. Wir haben festgestellt, dass Anbieter wie Azure OpenAI eine Filterung der Inhaltsmoderation für die Eingabeaufforderungen und generierten Inhalte bereitgestellt haben. LangSmith (Teil des LangChain-Tools) war ebenfalls ein Top-Anwärter, da die Daten die Art des verwendeten Anbieters (z. B. OpenAI, Bedrock usw.) und alle entsprechenden Metadaten enthalten. Dies setzte jedoch voraus, dass der Benutzer auch LangSmith eingerichtet hat. Für diese Implementierung haben wir uns für von Erstanbietern unterstützte Protokolle eines Anbieters entschieden, der LLMs bereitstellt.

Als wir uns eingehender mit potenziellen Integrationen befassten, entschieden wir uns aus einigen bestimmten Gründen für AWS Bedrock. Erstens bietet Bedrock Logging First-Party-Unterstützung für Amazon CloudWatch Logs und Amazon S3. Zweitens wurde die Protokollierung speziell für den Modellaufruf erstellt, einschließlich Daten, die für LLMs spezifisch sind (im Gegensatz zu anderen Vorgängen und Machine Learning-Modellen), einschließlich Eingabeaufforderungen und Antworten sowie Leitplanken/Inhaltsfilterung. Drittens verfügt Elastic bereits über einen robusten Katalog von Integrationen mit AWS, sodass wir schnell eine neue Integration speziell für AWS Bedrock-Modellaufrufprotokolle erstellen konnten. Im nächsten Abschnitt wird auf diese neue Integration eingegangen, mit der Sie Ihre Bedrock-Modellaufrufprotokolle im Elastic-Stack erfassen können.

Integration des elastischen AWS Bedrock-Modells

Overview

Die neue Elastic AWS Bedrock-Integration für Modellaufrufprotokolle bietet eine Möglichkeit, Daten von AWS-Services schnell zu sammeln und zu analysieren, wobei der Schwerpunkt auf dem Modell liegt. Diese Integration bietet zwei primäre Methoden für die Protokollerfassung: Amazon S3-Buckets und Amazon CloudWatch. Jede Methode ist so optimiert, dass sie robuste Datenabruffunktionen bietet und gleichzeitig Kosteneffizienz und Leistungseffizienz berücksichtigt. Wir verwenden diese LLM-spezifischen Felder, die für die Detektionstechnik erhoben wurden.

Hinweis: Diese Integration deckt zwar nicht jedes vorgeschlagene Feld ab, standardisiert jedoch vorhandene AWS Bedrock-Felder in die Kategorie gen_ai. Dieser Ansatz erleichtert die Verwaltung von Erkennungsregeln für verschiedene Datenquellen und minimiert den Bedarf an separaten Regeln für jeden LLM-Anbieter.

Konfigurieren der Methode zur Erfassung von Integrationsdaten

Sammeln von Protokollen aus S3-Buckets

Diese Integration ermöglicht eine effiziente Protokollerfassung aus S3-Buckets mit zwei unterschiedlichen Methoden:

• SQS-Benachrichtigung: Dies ist die bevorzugte Methode zum Sammeln. Dabei geht es um das Lesen von S3-Benachrichtigungsereignissen aus einer AWS Simple Queue Service (SQS)-Warteschlange. Diese Methode ist kostengünstiger und bietet im Vergleich zum direkten Abruf eine bessere Leistung.
• Direct S3 Bucket Polling: Diese Methode fragt direkt eine Liste von S3-Objekten innerhalb eines S3-Buckets ab und wird nur empfohlen, wenn SQS-Benachrichtigungen nicht konfiguriert werden können. Dieser Ansatz ist ressourcenintensiver, bietet aber eine Alternative, wenn SQS nicht machbar ist.

Sammeln von Protokollen aus CloudWatch

Protokolle können auch direkt von CloudWatch erfasst werden, wobei die Integration mithilfe der AWS-API filterLogEvents auf alle Protokoll-Streams innerhalb einer bestimmten Protokollgruppe zugreift. Diese Methode ist eine Alternative zur Verwendung von S3-Buckets insgesamt.

Installation der Integration

Die Integration kann innerhalb des elastischen Agents eingerichtet werden, indem Sie die normalen Elastic-Installationsschritte ausführen.

1. Navigieren Sie zur AWS Bedrock-Integration.
2. Konfigurieren Sie die queue_url für SQS oder bucket_arn für direkte S3-Abfragen.

Konfigurieren von Bedrock Guardrails

AWS Bedrock Guardrails ermöglichen es Unternehmen, die Sicherheit durchzusetzen, indem sie Richtlinien festlegen, die schädliche oder unerwünschte Inhalte in LLM-Interaktionen einschränken. Diese Leitplanken können so angepasst werden, dass sie abgelehnte Themen enthalten, um bestimmte Themen zu blockieren, und Inhaltsfilter, um den Schweregrad von Inhalten in Eingabeaufforderungen und Antworten zu verringern. Darüber hinaus blockieren Filter für Wörter und sensible Informationen Obszönitäten und maskieren personenbezogene Daten, um sicherzustellen, dass die Interaktionen den Datenschutz- und ethischen Standards entsprechen. Diese Funktion hilft bei der Kontrolle der Inhalte, die von LLMs generiert und konsumiert werden, und reduziert im Idealfall das Risiko, das mit böswilligen Eingabeaufforderungen verbunden ist.

Hinweis: Weitere Beispiele für Schutzmaßnahmen sind die Inhalts- und Antwortfilter von Azure OpenAI, die wir in unseren vorgeschlagenen standardisierten LLM-Feldern für die herstellerunabhängige Protokollierung erfassen möchten.

Wenn LLM-Interaktionsinhalte diese Filter auslösen, werden die Antwortobjekte mit amazon-bedrock-trace - und amazon-bedrock-guardrailAction -Feldern gefüllt, die Details zum Ergebnis der Leitplanken enthalten, sowie mit verschachtelten Feldern, die angeben, ob die Eingabe mit dem Inhaltsfilter übereinstimmt. Diese Anreicherung von Antwortobjekten mit detaillierten Filterergebnissen verbessert die Gesamtdatenqualität, was besonders effektiv wird, wenn diese verschachtelten Felder mit ECS-Zuordnungen ausgerichtet sind.

Die Bedeutung von ECS-Mappings

Die Feldzuordnung ist ein wichtiger Teil des Prozesses für die Integrationsentwicklung, in erster Linie, um unsere Fähigkeit zu verbessern, breit angelegte und weitgehend kompatible Erkennungsregeln zu schreiben. Durch die Standardisierung der Datenaufnahme und -analyse können Unternehmen potenzielle Bedrohungen oder Anomalien in Protokollen, die in Elastic und in diesem speziellen Fall in LLM-Protokollen aufgenommen werden, effektiver erkennen, untersuchen und darauf reagieren.

Unser erstes Mapping beginnt mit der Untersuchung der vom Anbieter bereitgestellten Felder und bestehenden Lücken, was zur Erstellung eines umfassenden Schemas führt, das auf die Feinheiten der LLM-Abläufe zugeschnitten ist. Anschließend haben wir die Felder so abgeglichen, dass sie mit unseren semantischen OpenTelemetry-Konventionen übereinstimmen. Diese in der Tabelle gezeigten Zuordnungen decken verschiedene Aspekte ab:

• Allgemeine LLM-Interaktionsfelder: Dazu gehören grundlegende, aber wichtige Informationen wie der Inhalt von Anforderungen und Antworten, die Anzahl der Token, Zeitstempel und Benutzerkennungen, die für das Verständnis des Kontexts und des Umfangs von Interaktionen von grundlegender Bedeutung sind.
• Metrikfelder für Textqualität und -relevanz: Felder, die die Lesbarkeit, Komplexität und Ähnlichkeit von Text messen, helfen bei der Bewertung der Qualität und Relevanz von Modellausgaben und stellen sicher, dass die Antworten nicht nur genau, sondern auch benutzerspezifisch sind.
• Felder für Sicherheitsmetriken: Diese Klasse von Metriken ist wichtig für die Identifizierung und Quantifizierung potenzieller Sicherheitsrisiken, einschließlich Regex-Musterübereinstimmungen und Bewertungen im Zusammenhang mit Jailbreak-Versuchen, prompten Injektionen und anderen Sicherheitsbedenken wie Halluzinationskonsistenz und Ablehnungsreaktionen.
• Felder für die Richtliniendurchsetzung: Diese Felder erfassen Details zu bestimmten Richtliniendurchsetzungsmaßnahmen, die während der Interaktion ausgeführt werden, z. B. das Blockieren oder Ändern von Inhalten, und bieten Einblicke in die Zuverlässigkeitsstufen dieser Aktionen, um Sicherheits- und Compliancemaßnahmen zu verbessern.
• Bedrohungsanalysefelder: Diese Felder konzentrieren sich auf die Identifizierung und Quantifizierung potenzieller Bedrohungen und bieten eine detaillierte Analyse von Risikobewertungen, Arten erkannter Bedrohungen und den Maßnahmen, die zur Minderung dieser Bedrohungen ergriffen wurden.
• Compliance-Felder: Diese Felder tragen dazu bei, dass Interaktionen verschiedenen regulatorischen Standards entsprechen, indem sie alle erkannten Compliance-Verstöße und die spezifischen Regeln, die während der Interaktion ausgelöst wurden, detailliert beschreiben.
• OWASP Top Ten Specific Fields: Diese Felder werden direkt den OWASP Top 10 Risiken für LLM-Anwendungen zugeordnet und tragen dazu bei, Sicherheitsmaßnahmen an anerkannte Branchenstandards anzupassen.
• Stimmungs- und Toxizitätsanalysefelder: Diese Analysen sind unerlässlich, um den Ton zu messen und schädliche Inhalte in der Reaktion zu erkennen, um sicherzustellen, dass die Ergebnisse mit ethischen Richtlinien und Standards übereinstimmen. Dazu gehören Stimmungsbewertungen, Toxizitätswerte und die Identifizierung unangemessener oder sensibler Inhalte.
• Leistungsmetrikfelder: Diese Felder messen die Leistungsaspekte von LLM-Interaktionen, einschließlich Antwortzeiten und Größen von Anfragen und Antworten, die für die Optimierung der Systemleistung und die Gewährleistung eines effizienten Betriebs entscheidend sind.

Hinweis: Im Folgenden finden Sie eine erweiterte Tabelle der vorgeschlagenen Felder.

Diese Felder werden von unseren LLM-Integrationen abgebildet und letztendlich in unseren Erkennungen verwendet. Da wir die Bedrohungslandschaft weiterhin verstehen, werden wir diese Felder weiter verfeinern, um sicherzustellen, dass zusätzliche Felder, die von anderen LLM-Anbietern ausgefüllt werden, standardisiert und konzeptionell in der Zuordnung widergespiegelt werden.

Breitere Implikationen und Vorteile der Standardisierung

Die Standardisierung von Sicherheitsbereichen innerhalb des LLM-Ökosystems (z. B. Benutzerinteraktion und Anwendungsintegration) ermöglicht einen einheitlichen Ansatz für den Sicherheitsbereich. Elastic ist bestrebt, durch die Definition und Förderung einer Reihe von Standardfeldern eine Vorreiterrolle einzunehmen. Diese Bemühungen verbessern nicht nur die Sicherheitslage einzelner Unternehmen, sondern fördern auch eine sicherere Branche.

Integration mit Sicherheitstools: Durch die Standardisierung der Antworten von LLM-bezogenen Sicherheitstools werden Sicherheitsanalysefelder angereichert, die mit den ursprünglichen LLM-Anbieterinhalten an eine Sicherheitslösung gesendet werden können. Wenn Sicherheitstools im Ökosystem der LLM-Anwendung operativ miteinander verkettet sind, können sie jede Aufrufanforderung und -antwort überwachen. Sicherheitsteams können diese Felder dann nutzen, um komplexe Erkennungsmechanismen zu entwickeln, die subtile Anzeichen von Missbrauch oder Schwachstellen innerhalb von LLM-Interaktionen identifizieren können.

Konsistenz zwischen den Anbietern: Das Beharren darauf, dass alle LLM-Anbieter diese Standardfelder übernehmen, verfolgt das Ziel, Anwendungen effektiv zu schützen, aber auf eine Weise, die eine Grundlage schafft, an die sich alle Branchenanwender halten können. Benutzer werden ermutigt, sich unabhängig von der Plattform oder dem Tool an einem gemeinsamen Schema auszurichten.

Enhanced Detection Engineering: Mit diesen Standardfeldern wird das Detection Engineering robuster und die Änderung von Fehlalarmen wird verringert. Sicherheitsingenieure können effektive Regeln erstellen, die potenzielle Bedrohungen über verschiedene Modelle, Interaktionen und Ökosysteme hinweg identifizieren. Diese Konsistenz ist besonders wichtig für Unternehmen, die sich auf mehrere LLMs oder Sicherheitstools verlassen und eine einheitliche Plattform pflegen müssen.

LLM-spezifische Beispielfelder: AWS Bedrock-Anwendungsfall

Basierend auf der Aufnahme-Pipeline, den Feldzuordnungen und den Prozessoren der Integration werden die AWS Bedrock-Daten bereinigt, standardisiert und ECS-Feldern(Elastic Common Schema) zugeordnet. Die Kernfelder von Bedrock werden dann in der Gruppe aws.bedrock eingeführt, die Details zum Modellaufruf wie Anforderungen, Antworten und Tokenanzahl enthält. Die Integration füllt zusätzliche Felder aus, die auf das LLM zugeschnitten sind, um tiefere Einblicke in die Interaktionen des Modells zu erhalten, die später in unseren Erkennungen verwendet werden.

Beispiele für LLM-Detektionstechnik

Mit den standardisierten Feldern und der Elastic AWS Bedrock-Integration können wir damit beginnen, technische Regeln für die Erkennung zu erstellen, die die vorgeschlagene Funktion mit unterschiedlicher Komplexität darstellen. Die folgenden Beispiele wurden mit ES|QL.

Hinweis: Weitere Informationen zu diesen Abfragen finden Sie aws_bedrock im Hunting-Verzeichnis detection-rules und in rules.

Grundlegende Erkennung der Ablehnung sensibler Inhalte

Angesichts der aktuellen Richtlinien und Standards zu sensiblen Themen innerhalb der Organisation ist es wichtig, über Mechanismen zu verfügen, die sicherstellen, dass LLMs auch Compliance- und ethische Standards einhalten. Unternehmen haben die Möglichkeit, Fälle zu überwachen und zu erfassen, in denen sich ein LLM direkt weigert, auf sensible Themen zu reagieren.

Proben-Detektion:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.completion LIKE "*I cannot provide any information about*"
     AND gen_ai.response.finish_reasons LIKE "*end_turn*"
   )
 | STATS user_request_count = count() BY gen_ai.user.id
 | WHERE user_request_count >= 3

Beschreibung der Erkennung: Diese Abfrage wird verwendet, um Fälle zu erkennen, in denen das Modell die Bereitstellung von Informationen zu potenziell vertraulichen oder eingeschränkten Themen mehrmals explizit verweigert. In Kombination mit vordefinierten formatierten Ausgaben weist die Verwendung bestimmter Ausdrücke wie "Ich kann keine Informationen bereitstellen" innerhalb des Ausgabeinhalts darauf hin, dass das Modell durch eine Benutzeraufforderung ausgelöst wurde, etwas zu besprechen, das es so programmiert hat, dass es es als vertraulich oder unangemessen behandelt.

Sicherheitsrelevanz: Die Überwachung von LLM-Ablehnungen hilft dabei, Versuche zu identifizieren, das Modell auf sensible Daten zu untersuchen oder sie auf eine Weise auszunutzen, die zum Durchsickern proprietärer oder eingeschränkter Informationen führen könnte. Durch die Analyse der Muster und der Häufigkeit dieser Ablehnungen können Sicherheitsteams untersuchen, ob es gezielte Versuche gibt, gegen Informationssicherheitsrichtlinien zu verstoßen.

Potenzielle Denial-of-Service- oder Ressourcenerschöpfungsangriffe

Da das technische Design von LLMs sehr rechen- und datenintensiv ist, sind sie anfällig für Ressourcenerschöpfung und Denial-of-Service-Angriffe (DoS). Hohe Nutzungsmuster können auf Missbrauch oder böswillige Aktivitäten hinweisen, die darauf abzielen, die Verfügbarkeit des LLM zu beeinträchtigen. Aufgrund der Mehrdeutigkeit der direkten Korrelation der Größe der Eingabeaufforderungsanforderung mit der Tokenanzahl ist es wichtig, die Auswirkungen einer hohen Tokenanzahl in Eingabeaufforderungen zu berücksichtigen, die möglicherweise nicht immer aus größeren Anforderungstexten resultieren. Die Anzahl der Token und die Anzahl der Zeichen hängen vom jeweiligen Modell ab, wobei jedes Modell unterschiedlich sein kann und damit zusammenhängt, wie Einbettungen generiert werden.

Proben-Detektion:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.usage.prompt_tokens > 8000 OR
     gen_ai.usage.completion_tokens > 8000 OR
     gen_ai.performance.request_size > 8000
   )
 | STATS max_prompt_tokens = max(gen_ai.usage.prompt_tokens),
         max_request_tokens = max(gen_ai.performance.request_size),
         max_completion_tokens = max(gen_ai.usage.completion_tokens),
         request_count = count() BY cloud.account.id
 | WHERE request_count > 1
 | SORT max_prompt_tokens, max_request_tokens, max_completion_tokens DESC

Beschreibung der Erkennung: Diese Abfrage identifiziert eine hohe Token-Nutzung, die auf Missbrauch oder einen versuchten Denial-of-Service-Angriff (DoS) hinweisen könnte. Die Überwachung auf ungewöhnlich hohe Token-Anzahlen (Eingabe oder Ausgabe) hilft dabei, Muster zu erkennen, die das System verlangsamen oder überlasten könnten, was möglicherweise zu Dienstunterbrechungen führen kann. Da jede Anwendung ein anderes Token-Volumen nutzen kann, haben wir auf der Grundlage unserer vorhandenen Erfahrungen einen einfachen Schwellenwert gewählt, der grundlegende Anwendungsfälle abdecken sollte.

Sicherheitsrelevanz: Diese Form der Überwachung hilft dabei, potenzielle Probleme mit der Systemverfügbarkeit und -leistung zu erkennen. Es hilft bei der frühzeitigen Erkennung von DoS-Angriffen oder missbräuchlichem Verhalten, das die Servicequalität für legitime Benutzer beeinträchtigen könnte. Durch die Aggregation und Analyse der Token-Nutzung nach Konten können Sicherheitsteams die Quellen für potenziell bösartigen Datenverkehr ermitteln und geeignete Maßnahmen ergreifen.

Überwachung auf Latenzanomalien

Latenzbasierte Metriken können ein wichtiger Indikator für zugrunde liegende Leistungsprobleme oder Sicherheitsbedrohungen sein, die das System überlasten. Durch die Überwachung von Verarbeitungsverzögerungen können Unternehmen sicherstellen, dass die Server so effizient wie erwartet arbeiten.

Proben-Detektion:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
 | EVAL response_delay_seconds = gen_ai.performance.start_response_time / 1000
 | WHERE response_delay_seconds > 5
 | STATS max_response_delay = max(response_delay_seconds),
         request_count = count() BY gen_ai.user.id
 | WHERE request_count > 3
 | SORT max_response_delay DESC

Beschreibung der Erkennung: Diese aktualisierte Abfrage überwacht die Zeit, die ein LLM benötigt, um nach dem Empfang einer Anforderung mit dem Senden einer Antwort zu beginnen, wobei der Schwerpunkt auf der anfänglichen Antwortlatenz liegt. Es identifiziert signifikante Verzögerungen, indem es den tatsächlichen Beginn der Antwort mit typischen Antwortzeiten vergleicht und Fälle hervorhebt, in denen diese Verzögerungen ungewöhnlich lang sein können.

Sicherheitsrelevanz: Anomale Latenzen können symptomatisch für Probleme wie Netzwerkangriffe (z. B. DDoS) oder Systemineffizienzen sein, die behoben werden müssen. Durch die Verfolgung und Analyse von Latenzmetriken können Unternehmen sicherstellen, dass ihre Systeme effizient und sicher laufen, und schnell auf potenzielle Bedrohungen reagieren, die sich in ungewöhnlichen Verzögerungen äußern können.

Anwendungsfälle für die Entwicklung fortschrittlicher LLM-Detektion

In diesem Abschnitt werden potenzielle Anwendungsfälle untersucht, die mit einer Elastic Security-Integration angegangen werden könnten. Es wird davon ausgegangen, dass diese Felder vollständig ausgefüllt sind und dass die erforderlichen Funktionen zur Anreicherung von Sicherheitsüberprüfungen (z. B. Guardrails) implementiert wurden, entweder innerhalb von AWS Bedrock oder über einen ähnlichen Ansatz, der vom LLM-Anbieter bereitgestellt wird. In Kombination mit der verfügbaren Datenquelle und der Elastic-Integration können Erkennungsregeln auf diesen Guardrail-Anfragen und -Antworten aufgebaut werden, um den Missbrauch von LLMs in der Bereitstellung zu erkennen.

Bösartige Modell-Uploads und mandantenübergreifende Eskalation

Eine kürzlich durchgeführte Untersuchung der Hugging Face Interface API ergab ein erhebliches Risiko, bei dem Angreifer ein in böswilliger Absicht erstelltes Modell hochladen könnten, um die Ausführung beliebiger Codes durchzuführen. Dies wurde durch die Verwendung einer Python Pickle-Datei erreicht, die nach der Deserialisierung eingebetteten bösartigen Code ausführte. Diese Schwachstellen unterstreichen die Notwendigkeit strenger Sicherheitsmaßnahmen, um alle Eingaben in AI-as-a-Service (AIAAS)-Plattformen vom LLM über die Infrastruktur, die das Modell hostet, bis hin zur Anwendungs-API-Integration zu überprüfen und zu bereinigen. Weitere Informationen finden Sie in diesem Artikel .

Potenzielle Erkennungsmöglichkeit: Verwenden Sie Felder wie gen_ai.request.model.id, gen_ai.request.model.versionund Eingabeaufforderung gen_ai.completion , um Wechselwirkungen mit anomalen Modellen zu erkennen. Die Überwachung ungewöhnlicher Werte oder Muster in den Modellkennungen und Versionsnummern zusammen mit der Überprüfung des angeforderten Inhalts (z. B. die Suche nach typischen Python Pickle-Serialisierungstechniken) kann auf verdächtiges Verhalten hinweisen. Ebenso kann eine Prüfung vor dem Hochladen des Modells mit ähnlichen Feldern den Upload blockieren. Querverweise auf zusätzliche Felder wie gen_ai.user.id können helfen, bösartige mandantenübergreifende Vorgänge zu identifizieren, die diese Art von Aktivitäten ausführen.

Nicht autorisierte URLs und externe Kommunikation

Da LLMs immer stärker in betriebliche Ökosysteme integriert werden, kann ihre Fähigkeit, mit externen Funktionen wie E-Mail oder Webhooks zu interagieren, von Angreifern ausgenutzt werden. Zum Schutz vor diesen Interaktionen ist es wichtig, Erkennungsregeln zu implementieren, die verdächtige oder nicht autorisierte Aktivitäten basierend auf den Ausgaben des Modells und nachfolgenden Integrationen identifizieren können.

Potenzielle Erkennungsmöglichkeit: Verwenden Sie Felder wie gen_ai.completionund gen_ai.security.regex_pattern_count , um bösartige externe URLs und Webhooks zu selektieren. Diese Regex-Muster müssen auf der Grundlage bekannter verdächtiger Muster vordefiniert werden.

Hierarchische Priorisierung von Anweisungen

LLMs werden zunehmend in Umgebungen verwendet, in denen sie Anweisungen aus verschiedenen Quellen erhalten (z. B. ChatGPT Custom Instructions), die möglicherweise nicht immer gutartige Absichten haben. Dieser Workflow zum Erstellen eines eigenen Modells kann zu einer Reihe potenzieller Sicherheitslücken führen, wenn das Modell alle Anweisungen mit der gleichen Wichtigkeit behandelt und sie nicht überprüft werden. Referenz hier.

Potenzielle Erkennungsmöglichkeit: Überwachen Sie Felder wie gen_ai.model.instructions und gen_ai.completion , um Diskrepanzen zwischen gegebenen Anweisungen und den Antworten des Modells zu identifizieren, was auf Fälle hinweisen kann, in denen Modelle alle Anweisungen mit gleicher Wichtigkeit behandeln. Analysieren Sie außerdem die gen_ai.similarity_score, um zu erkennen, wie ähnlich die Antwort der ursprünglichen Anforderung ist.

Erweiterte Erkennungen mit zusätzlichen Elastic-Regeltypen

In diesem Abschnitt werden zusätzliche Erkennungstechniken vorgestellt, bei denen einige der Elastic-Regeltypen Threshold, Indicator Match und New Terms verwendet werden, um eine nuanciertere und robustere Sicherheitslage zu gewährleisten.

• Schwellenwertregeln: Identifizieren Sie die hohe Häufigkeit abgelehnter Anfragen über einen kurzen Zeitraum, gruppiert nach gen_ai.user.id , die auf Missbrauchsversuche hinweisen könnten. (z. LLM04 von OWASP)
• Indikator-Übereinstimmungsregeln: Gleichen Sie bekannte bösartige Bedrohungsinformationen ab, die von Intel bereitgestellt wurden, Indikatoren wie die LLM-Benutzer-ID wie die gen_ai.user.id , die diese Benutzerattribute enthalten. (z. arn:aws:iam::12345678912:user/thethreatactor)
• Neue Regeln für Begriffe: Erkennen Sie neue oder ungewöhnliche Begriffe in Benutzeraufforderungen, die auf übliche Aktivitäten außerhalb der normalen Verwendung für die Benutzerrolle hinweisen könnten, was möglicherweise auf neues bösartiges Verhalten hinweist.

Zusammenfassung

Elastic leistet Pionierarbeit bei der Standardisierung von LLM-basierten Feldern in der gesamten generativen KI-Landschaft, um Sicherheitserkennungen im gesamten Ökosystem zu ermöglichen. Diese Initiative steht nicht nur im Einklang mit unseren kontinuierlichen Verbesserungen bei LLM-Integrations- und Sicherheitsstrategien, sondern unterstützt auch unser breites Sicherheits-Framework, das sowohl direkte Benutzerinteraktionen als auch die zugrunde liegenden Systemarchitekturen schützt. Durch die Förderung einer einheitlichen Sprache unter den LLM-Anbietern für verbesserte Erkennungs- und Reaktionsfähigkeiten wollen wir das gesamte Ökosystem schützen und es sicherer und zuverlässiger machen. Elastic lädt alle Beteiligten in der Branche, Entwickler, Betreuer, Integratoren und Benutzer ein, diese standardisierten Praktiken zu übernehmen und so kollektive Sicherheitsmaßnahmen zu stärken und den branchenweiten Schutz voranzutreiben.

Während wir unsere Integrationen weiterhin hinzufügen und verbessern, beginnend mit AWS Bedrock, entwickeln wir eine Strategie, um andere LLM-basierte Integrationen an die neuen Standards anzupassen, die wir festgelegt haben, um den Weg für eine einheitliche Erfahrung im gesamten Elastic-Ökosystem zu ebnen. Die nahtlose Überlappung mit den bestehenden Elasticsearch-Funktionen ermöglicht es den Benutzern, ausgefeilte Such- und Analysefunktionen direkt auf die LLM-Daten zu übertragen und bestehende Workflows auf die Tools zurückzuführen, mit denen die Benutzer am besten vertraut sind.

Schauen Sie sich das LLM Safety Assessment an, das tiefer in diese Themen eintaucht.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.