Elastic avanza en la seguridad de LLM con campos e integraciones estandarizados

Introducción

La semana pasada, el investigador de seguridad Mika Ayenson escribió una publicación en la que se destacan las posibles estrategias de detección y una solución prototipo de auditoría de contenido de LLM a través de un proxy implementada durante el serial de eventos OnWeek de Elastic. Esta publicación destacó la importancia de la investigación relacionada con la seguridad de la tecnología LLM implementada en diferentes entornos, y el enfoque de investigación que adoptamos en Elastic Security Labs.

Dado el punto de vista único de Elastic que aprovecha la tecnología LLM en nuestra plataforma para potenciar capacidades como el Asistente de IA de Seguridad, nuestro deseo de reglas de detección, integraciones y contenido de investigación más formales fue creciendo. Esta publicación destaca algunos de los avances recientes que realizamos en las integraciones de LLM, nuestras ideas sobre las detecciones alineadas con los estándares de la industria y las asignaciones de campos de ECS.

Estamos comprometidos con una estrategia de seguridad integral que proteja no solo las interacciones directas de LLM basadas en el usuario, sino también el ecosistema más amplio que las rodea. Este enfoque implica capas de oportunidades de ingeniería de detección de seguridad para abordar no solo las solicitudes/respuestas de LLM, sino también los sistemas subyacentes y las integraciones empleadas por los modelos.

Estas oportunidades de detección ayudan colectivamente a proteger el ecosistema de LLM y se pueden agrupar en cinco categorías:

1. Aviso y respuesta: Mecanismos de detección diseñados para identificar y mitigar las amenazas en función de la creciente variedad de interacciones de LLM para garantizar que todas las comunicaciones se auditen de forma segura.
2. Infraestructura y plataforma: implementación de detecciones para proteger la infraestructura que aloja los LLM (incluidos los dispositivos AI Pin portátiles), incluida la detección de amenazas contra los datos almacenados, las actividades de procesamiento y la comunicación con el servidor.
3. API e integraciones: detección de amenazas al interactuar con las API de LLM y protección de las integraciones con otras aplicaciones que ingieren la salida del modelo.
4. Procesos operativos y datos: Supervisión de los procesos operativos (incluidos los agentes de IA) y los flujos de datos, protegiendo los datos a lo largo de su ciclo de vida.
5. Cumplimiento y ética: Alinear las estrategias de detección con las regulaciones de la industria y los estándares éticos bien adoptados.

Cerciorar el ecosistema de LLM: cinco categorías

Otra consideración importante para estas categorías se expande a quién puede abordar mejor los riesgos o quién es responsable de cada categoría de riesgo relacionada con los sistemas LLM.

Al igual que los modelos de responsabilidad de seguridad compartida existentes, Elastic evaluó cuatro categorías amplias, que eventualmente se ampliarán aún más a medida que continuemos nuestra investigación sobre estrategias de ingeniería de detección e integraciones. En términos generales, esta publicación considera las protecciones de seguridad que involucran a los siguientes propietarios de responsabilidades:

• Creadores de LLM: Organizaciones que crean, diseñan, alojan y capacitan LLM, como OpenAI, Amazon Sitio web Services o Google
• Integradores de LLM: Organizaciones e individuos que integran tecnologías de LLM existentes producidas por creadores de LLM en otras aplicaciones
• Mantenedores de LLM: Personas que monitorear los casos de uso de rendimiento, fiabilidad, seguridad e integridad de los LLM operativos y que siguen participando directamente en el mantenimiento de la base de código, la infraestructura y la arquitectura de software
• Usuarios de seguridad: Personas que buscan activamente vulnerabilidades en los sistemas a través de mecanismos y medios de prueba tradicionales. Esto puede expandir más allá de los riesgos tradicionales discutidos en el LLM Top 10 de OWASP y convertir en riesgos asociados con el software y la infraestructura que rodea a estos sistemas

Esta perspectiva más amplia muestra un enfoque unificado para la ingeniería de detección de LLM que comienza con la ingesta de datos mediante integraciones nativas de Elastic; en este ejemplo, destacamos el caso de uso de invocación del modelo AWS Bedrock.

Integración de logs de LLM en Elastic

Las integraciones de Elastic simplifican la ingesta de datos en Elastic desde varias fuentes, lo que en última instancia mejora nuestra solución de seguridad. Estas integraciones se gestionan a través de Fleet en Kibana, lo que permite a los usuarios desplegar y gestionar datos fácilmente dentro del Elastic Agent. Los usuarios pueden adaptar rápidamente Elastic a nuevas fuentes de datos seleccionando y configurando integraciones a través de Fleet. Para obtener más detalles, consulta el blog de Elastic sobre cómo facilitar la integración de tus sistemas con Elastic.

El trabajo inicial de ONWeek realizado por el equipo involucró una solución de proxy simple que extraía campos de las interacciones con el Asistente de IA de Elastic Security. Este prototipo se desplegó junto con el Elastic Stack y consumió datos de una solución de proveedor que carecía de capacidades de auditoría de seguridad. Si bien esta implementación inicial resultó conceptualmente interesante, impulsó al equipo a invertir tiempo en evaluar las integraciones de Elastic existentes de uno de nuestros socios proveedores de cloud, Amazon Sitio web Services. Esta metodología garantiza una accesibilidad optimizada para nuestros usuarios, ofreciendo integraciones fluidas y con un solo clic para la ingesta de datos. Todas las canalizaciones de ingesta cumplen con los estándares de normalización de ECS/OTel, lo que abarca contenido completo, incluidos paneles, dentro de un paquete unificado. Además, esta estrategia nos posiciona para aprovechar las integraciones existentes adicionales, como Azure y GCP, para futuras integraciones centradas en LLM.

Selección de proveedores y capacidades de API

A la hora de seleccionar los proveedores de LLM para los que crear integraciones, nos fijamos en los tipos de campos que necesitamos ingerir para nuestros casos de uso de seguridad. Para el conjunto inicial de reglas que se detallan aquí, necesitábamos información como marcas de tiempo y recuentos de tokens; descubrimos que proveedores como Azure OpenAI proporcionaban moderación de contenido, filtrado en las indicaciones y generaban contenido. LangSmith (parte de las herramientas de LangChain) también fue uno de los principales contendientes, ya que los datos contienen el tipo de proveedor empleado (por ejemplo, OpenAI, Bedrock, etc.) y todos los metadatos respectivos. Sin embargo, esto requería que el usuario también tuviera LangSmith configurado. Para esta implementación, decidimos optar por registros compatibles de origen de un proveedor que proporciona LLM.

A medida que profundizamos en las posibles integraciones, decidimos aterrizar con AWS Bedrock, por algunas razones específicas. En primer lugar, el registro de Bedrock es compatible con Amazon CloudWatch Logs y Amazon S3. En segundo lugar, el registro se crea específicamente para la invocación de modelos, incluidos los datos específicos de los LLM (a diferencia de otras operaciones y modelos de aprendizaje automático), incluidos los mensajes y las respuestas, y el filtrado de contenido/guardarraíl. En tercer lugar, Elastic ya cuenta con un estable catálogo de integraciones con AWS, por lo que pudimos crear rápidamente una nueva integración para los logs de invocación de modelos de AWS Bedrock específicamente. En la siguiente sección, se profundizará en esta nueva integración, que puedes usar para capturar tus logs de invocación del modelo Bedrock en el Elastic Stack.

Integración del modelo Elastic AWS Bedrock

Overview

La nueva integración de Elastic AWS Bedrock para logs de invocación de modelos proporciona una forma de recopilar y analizar datos de los servicios de AWS rápidamente, centrar específicamente en el modelo. Esta integración proporciona dos métodos principales para la recopilación de registros: buckets de Amazon S3 y Amazon CloudWatch. Cada método está optimizado para ofrecer estables capacidades de recuperación de datos, teniendo en cuenta la rentabilidad y la eficiencia del rendimiento. Empleamos estos campos específicos de LLM recopilados con fines de ingeniería de detección.

Nota: Si bien esta integración no cubre todos los campos propuestos, estandariza los campos existentes de AWS Bedrock en la categoría gen_ai. Este enfoque facilita el mantenimiento de reglas de detección en varias fuentes de datos, lo que minimiza la necesidad de reglas separadas para cada proveedor de LLM.

Configuración del método de recopilación de datos de integración

Recopilación de registros de buckets de S3

Esta integración permite una recopilación eficiente de registros de buckets de S3 mediante dos métodos distintos:

• Notificación SQS: Este es el método preferido para recopilar. Implica la lectura de eventos de notificación de S3 de una cola de AWS Simple Queue Service (SQS). Este método es menos costoso y proporciona un mejor rendimiento en comparación con el sondeo directo.
• Sondeo directo de bucket de S3: este método sondea directamente una lista de objetos de S3 dentro de un bucket de S3 y solo se recomienda cuando no se pueden configurar las notificaciones de SQS. Este enfoque es más intensivo en recursos, pero proporciona una alternativa cuando SQS no es factible.

Recopilación de registros de CloudWatch

Los registros también se pueden recopilar directamente desde CloudWatch, donde la integración aprovecha todos los flujos de registros dentro de un grupo de registros especificado mediante la API de AWS filterLogEvents. Este método es una alternativa al uso completo de buckets de S3.

Instalación de la integración

La integración se puede configurar dentro de Elastic Agent siguiendo los pasos normales de instalación de Elastic.

1. Vaya a la integración de AWS Bedrock
2. Configure el queue_url para SQS o bucket_arn para el sondeo directo de S3.

Configuración de barandillas de lecho rocoso

Las barreras de seguridad de AWS Bedrock permiten a las organizaciones reforzar la seguridad mediante el establecimiento de políticas que limitan el contenido dañino o no deseado en las interacciones de LLM. Estas barreras de protección se pueden personalizar para incluir temas denegados para bloquear temas específicos y filtros de contenido para moderar la gravedad del contenido en las sugerencias y respuestas. Además, los filtros de palabras e información confidencial bloquean las blasfemias y enmascaran la información de identificación personal (PII), lo que garantiza que las interacciones cumplan con los estándares éticos y de privacidad. Esta función ayuda a controlar el contenido generado y consumido por los LLM e, idealmente, reduce el riesgo asociado con los avisos maliciosos.

Nota: otros ejemplos de barreras de protección incluyen los filtros de contenido y respuesta de Azure OpenAI, que pretendemos capturar en nuestros campos estandarizados de LLM propuestos para el registro independiente del proveedor.

Cuando el contenido de interacción de LLM desencadena estos filtros, los objetos de respuesta se rellenan con campos amazon-bedrock-trace y amazon-bedrock-guardrailAction , que proporcionan detalles sobre el resultado de Guardrails y campos anidados que indican si la entrada coincidió con el filtro de contenido. Este enriquecimiento de objetos de respuesta con resultados de filtro detallados mejora la calidad general de los datos, lo que resulta especialmente eficaz cuando estos campos anidados están alineados con las asignaciones de ECS.

La importancia de los mapeos de ECS

El mapeo de campos es una parte fundamental del proceso para el desarrollo de la integración, principalmente para mejorar nuestra capacidad de escribir reglas de detección de amplio alcance y ampliamente compatibles. Al estandarizar la forma en que se ingieren y analizan los datos, las organizaciones pueden detectar, investigar y responder de manera más efectiva a posibles amenazas o anomalías en los logs ingeridos en Elastic y, en este caso específico, en los logs de LLM.

Nuestro mapeo inicial comienza investigando los campos proporcionados por el proveedor y las brechas existentes, lo que lleva al establecimiento de un esquema integral adaptado a los matices de las operaciones de LLM. A continuación, conciliamos los campos para alinearlos con nuestras convenciones semánticas de OpenTelemetry. Estas asignaciones que se muestran en la tabla cubren varios aspectos:

• Campos generales de interacción de LLM: incluyen información básica pero crítica, como el contenido de las solicitudes y respuestas, los recuentos de tokens, las marcas de tiempo y los identificadores de usuario, que son fundamentales para comprender el contexto y el alcance de las interacciones.
• Campos de métricas de calidad y relevancia del texto: Los campos que miden los puntajes de legibilidad, complejidad y similitud del texto ayudan a evaluar la calidad y la relevancia de los resultados del modelo, lo que garantiza que las respuestas no solo sean precisas, sino también apropiadas para el usuario.
• Campos de métricas de seguridad: esta clase de métricas es importante para identificar y cuantificar los posibles riesgos de seguridad, incluidas las coincidencias de patrones de expresiones regulares y los puntajes relacionados con los intentos de jailbreak, las inyecciones rápidas y otros problemas de seguridad, como la consistencia de las alucinaciones y las respuestas de rechazo.
• Campos de aplicación de políticas: estos campos capturan detalles sobre acciones específicas de aplicación de políticas realizadas durante las interacciones, como el bloqueo o la modificación de contenido, y proporcionan información sobre los niveles de confianza de estas acciones, mejorando las medidas de seguridad y cumplimiento.
• Campos de análisis de amenazas: Centrados en la identificación y cuantificación de amenazas potenciales, estos campos proporcionan un análisis detallado de los puntajes de riesgo, los tipos de amenazas detectadas y las medidas adoptadas para mitigar estas amenazas.
• Campos de cumplimiento: estos campos ayudan a garantizar que las interacciones cumplan con varios estándares regulatorios, detallando las violaciones de cumplimiento detectadas y las reglas específicas que se activaron durante la interacción.
• Diez campos específicos principales de OWASP: Estos campos se asignan directamente a los 10 riesgos principales de OWASP para las aplicaciones de LLM, lo que ayuda a alinear las medidas de seguridad con los estándares reconocidos de la industria.
• Campos de análisis de sentimiento y toxicidad: Estos análisis son esenciales para medir el tono y detectar cualquier contenido dañino en la respuesta, cerciorando que los resultados se alineen con las pautas y estándares éticos. Esto incluye puntajes de sentimiento, niveles de toxicidad e identificación de contenido inapropiado o sensible.
• Campos de métricas de rendimiento: Estos campos miden los aspectos de rendimiento de las interacciones de LLM, incluidos los tiempos de respuesta y el tamaño de las solicitudes y respuestas, que son fundamentales para optimizar el rendimiento del sistema y garantizar operaciones eficientes.

Nota: Consulte la esencia de una tabla ampliada de campos propuestos.

Estos campos se mapean mediante nuestras integraciones de LLM y, en última instancia, se emplean dentro de nuestras detecciones. A medida que sigamos comprendiendo el panorama de amenazas, continuaremos refinando estos campos para garantizar que los campos adicionales poblados por otros proveedores de LLM estén estandarizados y se reflejen conceptualmente en el mapeo.

Participaciones y beneficios más amplios de la estandarización

La estandarización de los campos de seguridad dentro del ecosistema LLM (por ejemplo, la interacción con el usuario y la integración de aplicaciones) facilita un enfoque unificado del dominio de la seguridad. Elastic se esfuerza por liderar la carga mediante la definición y promoción de un conjunto de campos estándar. Este esfuerzo no solo mejora la postura de seguridad de las organizaciones individuales, sino que también fomenta una industria más segura.

Integración con herramientas de seguridad: Al estandarizar las respuestas de las herramientas de seguridad relacionadas con LLM, enriquece los campos de análisis de seguridad que se pueden enviar con el contenido original del proveedor de LLM a una solución de seguridad. Si se encadenan operativamente en el ecosistema de la aplicación LLM, las herramientas de seguridad pueden auditar cada solicitud y respuesta de invocación. Los equipos de seguridad pueden aprovechar estos campos para crear mecanismos de detección complejos que puedan identificar signos sutiles de uso indebido o vulnerabilidades dentro de las interacciones de LLM.

Coherencia entre proveedores: Insistir en que todos los proveedores de LLM adopten estos campos estándar impulsa un objetivo singular para proteger eficazmente las aplicaciones, pero de una manera que establezca una línea de base a la que todos los usuarios de la industria puedan adherir. Se anima a los usuarios a alinear con un esquema común, independientemente de la plataforma o la herramienta.

Ingeniería de detección mejorada: Con estos campos estándar, la ingeniería de detección se vuelve más robusta y se disminuye el cambio de falsos positivos. Los ingenieros de seguridad pueden crear reglas efectivas que identifiquen amenazas potenciales en diferentes modelos, interacciones y ecosistemas. Esta coherencia es especialmente importante para las organizaciones que dependen de múltiples LLM o herramientas de seguridad y necesitan mantener una plataforma unificada.

Ejemplos de campos específicos de LLM: caso de uso de AWS Bedrock

En función de la canalización de ingesta, los mapeos de campos y los procesadores de la integración, los datos de AWS Bedrock se limpian, estandarizan y asignan a los campos de Elastic Common Schema (ECS). A continuación, los campos principales de Bedrock se introducen en el grupo aws.bedrock , que incluye detalles sobre la invocación del modelo, como solicitudes, respuestas y recuentos de tokens. La integración rellena campos adicionales adaptados al LLM para proporcionar información más detallada sobre las interacciones del modelo que se emplean posteriormente en nuestras detecciones.

Ejemplos de ingeniería de detección de LLM

Con los campos estandarizados y la integración de Elastic AWS Bedrock, podemos comenzar a elaborar reglas de ingeniería de detección que muestren la capacidad propuesta con diversa complejidad. Los siguientes ejemplos están escritos con ES|QL.

Nota: Consulte el directorio de búsqueda de reglas de detección y las reglas deaws_bedrock para obtener más detalles sobre estas consultas.

Detección básica de rechazo de contenido confidencial

Con las políticas y estándares actuales sobre temas delicados dentro de la organización, es importante contar con mecanismos para garantizar que los LLM también se adhieran a los estándares éticos y de cumplimiento. Las organizaciones tienen la oportunidad de monitorear y capturar casos en los que un LLM se niega directamente a responder a temas delicados.

Detección de muestras:

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

Descripción de la detección: esta consulta se emplea para detectar instancias en las que el modelo se niega explícitamente a proporcionar información sobre temas potencialmente confidenciales o restringidos varias veces. Combinado con salidas con formato predefinido, el uso de frases específicas como "No puedo proporcionar ninguna información sobre" dentro del contenido de salida indica que el modelo fue activado por un mensaje del usuario para discutir algo que está programado para tratar como confidencial o inapropiado.

Relevancia de seguridad: El monitoreo de los rechazos de LLM ayuda a identificar intentos de sondear el modelo en busca de datos confidenciales o de explotarlo de una manera que podría conducir a la fuga de información confidencial o restringida. Al analizar los patrones y la frecuencia de estos rechazos, los equipos de seguridad pueden investigar si hay intentos dirigidos de violar las políticas de seguridad de la información.

Posibles ataques de denegación de servicio o agotamiento de recursos

Debido a que el diseño de ingeniería de los LLM es altamente computacional y requiere muchos datos, son susceptibles al agotamiento de recursos y a los ataques de denegación de servicio (DoS). Los patrones de uso elevados pueden indicar abusos o actividades maliciosas diseñadas para degradar la disponibilidad de la LLM. Debido a la ambigüedad de correlacionar el tamaño de la solicitud de solicitud directamente con el recuento de tokens, es esencial tener en cuenta las participaciones de los recuentos altos de tokens en las solicitudes, que no siempre pueden resultar de cuerpos de solicitud más grandes. El recuento de tokens y los recuentos de caracteres dependen del modelo específico, donde cada uno puede ser diferente y está relacionado con la forma en que se generan las incrustaciones.

Detección de muestras:

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

Descripción de la detección: esta consulta identifica el uso de tokens de gran volumen que podría ser indicativo de abuso o de un intento de ataque de denegación de servicio (DoS). La supervisión de recuentos de tokens inusualmente altos (entrada o salida) ayuda a detectar patrones que podrían ralentizar o abrumar el sistema, lo que podría provocar interrupciones del servicio. Dado que cada aplicación puede aprovechar un volumen de tokens diferente, elegimos un umbral simple basado en nuestra experiencia existente que debería cubrir casos de uso básicos.

Relevancia de la seguridad: Esta forma de supervisión ayuda a detectar posibles problemas con la disponibilidad y el rendimiento del sistema. Ayuda en la detección temprana de ataques DoS o comportamientos abusivos que podrían degradar la calidad del servicio para los usuarios legítimos. Al agregar y analizar el uso de tokens por cuenta, los equipos de seguridad pueden identificar fuentes de tráfico potencialmente malicioso y tomar las medidas adecuadas.

Supervisión de anomalías de latencia

Las métricas basadas en la latencia pueden ser un indicador clave de problemas de rendimiento subyacentes o amenazas de seguridad que sobrecargan el sistema. Al monitorear los retrasos en el procesamiento, las organizaciones pueden cerciorar de que los servidores funcionen con la eficiencia esperada.

Detección de muestras:

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

Descripción de la detección: Esta consulta actualizada monitorear el tiempo que tarda un LLM en comenzar a enviar una respuesta luego de recibir una solicitud, centrar en la latencia de respuesta inicial. Identifica retrasos significativos comparando el inicio real de la respuesta con los tiempos de respuesta típicos, destacando los casos en los que estos retrasos pueden ser anormalmente largos.

Relevancia de seguridad: Las latencias anómalas pueden ser sintomáticas de problemas como ataques de red (por ejemplo, DDoS) o ineficiencias del sistema que deben abordar. Mediante el seguimiento y el análisis de las métricas de latencia, las organizaciones pueden cerciorar de que sus sistemas funcionan de forma eficiente y segura, y pueden responder rápidamente a las posibles amenazas que podrían manifestar como retrasos anormales.

Casos de uso de ingeniería de detección de LLM avanzada

En esta sección, se exploran posibles casos de uso que podrían abordar con una integración de Elastic Security. Se supone que estos campos están completamente rellenados y que se implementaron las características de enriquecimiento de auditoría de seguridad necesarias (por ejemplo, Guardrails), ya sea dentro de AWS Bedrock o a través de un enfoque similar proporcionado por el proveedor de LLM. En combinación con la fuente de datos disponible y la integración de Elastic, las reglas de detección se pueden crear sobre estas solicitudes y respuestas de Guardrail para detectar el uso indebido de LLM en el despliegue.

Cargas de modelos maliciosos y escalamiento entre inquilinos

Una investigación reciente sobre la API de interfaz de Hugging Face reveló un riesgo significativo en el que los atacantes podrían cargar un modelo creado con fines maliciosos para realizar la ejecución de código arbitrario. Esto se logró mediante el uso de un archivo Python Pickle que, cuando se deserializaba, ejecutaba código malicioso incrustado. Estas vulnerabilidades ponen de manifiesto la necesidad de medidas de seguridad rigurosas para inspeccionar y desinfectar todas las entradas de las plataformas de IA como servicio (AIAAS), desde el LLM hasta la infraestructura que aloja el modelo y la integración de la API de la aplicación. Consulte este artículo para obtener más detalles.

Oportunidad de detección potencial: use campos como gen_ai.request.model.id, gen_ai.request.model.versiony aplicar gen_ai.completion para detectar interacciones con modelos anómalos. La supervisión de valores o patrones inusuales en los identificadores del modelo y los números de versión, junto con la inspección del contenido aplicar (por ejemplo, la búsqueda de técnicas típicas de serialización de Python Pickle) puede indicar un comportamiento sospechoso. Del mismo modo, una verificación antes de cargar el modelo empleando campos similares puede bloquear la carga. Las referencias cruzadas de campos adicionales, como gen_ai.user.id , pueden ayudar a identificar operaciones maliciosas entre inquilinos que realizan este tipo de actividades.

URLs no autorizadas y comunicación externa

A medida que los LLM se integran más en los ecosistemas operativos, los atacantes pueden explotar su capacidad para interactuar con capacidades externas como el email o los webhooks. Para proteger contra estas interacciones, es importante implementar reglas de detección que puedan identificar actividades sospechosas o no autorizadas en función de los resultados del modelo y las integraciones posteriores.

Posible oportunidad de detección: emplee campos como gen_ai.completiony gen_ai.security.regex_pattern_count para clasificar las URL externas maliciosas y los webhooks. Estos patrones de expresiones regulares deben predefinir en función de patrones sospechosos conocidos.

Priorización de instrucciones jerárquicas

Los LLM se emplean cada vez más en entornos en los que reciben instrucciones de diversas fuentes (por ejemplo, instrucciones personalizadas de ChatGPT), que no siempre pueden tener intenciones benignas. Este flujo de trabajo de creación de modelo propio puede dar lugar a un serial de posibles vulnerabilidades de seguridad, si el modelo trata todas las instrucciones con la misma importancia y no se comprueban. Referencia aquí.

Oportunidad potencial de detección: Monitoree campos como gen_ai.model.instructions y gen_ai.completion para identificar discrepancias entre las instrucciones dadas y las respuestas de los modelos, lo que puede indicar casos en los que los modelos tratan todas las instrucciones con la misma importancia. Además, analice el gen_ai.similarity_scorepara discernir qué tan similar es la respuesta de la solicitud original.

Detecciones extendidas con tipos de reglas Elastic adicionales

En esta sección, se presentan técnicas de ingeniería de detección adicionales que emplean algunos de los tipos de reglas de Elastic, Threshold, Indicator Match y New Terms para proporcionar una postura de seguridad más matizada y estable.

• Reglas de umbral: identifique el alta frecuencia de solicitudes denegadas durante un corto periodo de tiempo agrupadas por gen_ai.user.id que podrían ser indicativas de intentos de abuso. (p. ej. LLM04 de OWASP)
• Reglas de coincidencia de indicadores: coincida con los indicadores proporcionados por la inteligencia de amenazas maliciosas conocidas, como el ID de usuario de LLM, como los gen_ai.user.id que contienen estos atributos de usuario. (p. ej. arn:aws:iam::12345678912:user/thethreatactor)
• Reglas de nuevos términos: detecte términos nuevos o inusuales en las indicaciones del usuario que podrían indicar actividad habitual fuera del uso normal del rol del usuario, lo que podría indicar nuevos comportamientos maliciosos.

Resumen

Elastic es pionero en la estandarización de campos basados en LLM en todo el panorama de IA generativa para permitir detecciones de seguridad en todo el ecosistema. Esta iniciativa no solo se alinea con nuestras mejoras continuas en la integración de LLM y las estrategias de seguridad, sino que también respalda nuestro amplio marco de seguridad que protege tanto las interacciones directas de los usuarios como las arquitecturas de sistemas subyacentes. Al promover un lenguaje uniforme entre los proveedores de LLM para mejorar las capacidades de detección y respuesta, nuestro objetivo es proteger todo el ecosistema, haciéndolo más seguro y confiable. Elastic invita a todas las partes interesadas de la industria, creadores, mantenedores, integradores y usuarios, a adoptar estas prácticas estandarizadas, fortaleciendo así las medidas de seguridad colectivas y avanzando en las protecciones de toda la industria.

A medida que continuamos agregando y mejorando nuestras integraciones, comenzando con AWS Bedrock, estamos elaborando estrategias para alinear otras integraciones basadas en LLM con los nuevos estándares que establecimos, allanando el camino para una experiencia unificada en todo el ecosistema de Elastic. La superposición perfecta con las capacidades existentes de Elasticsearch permite a los usuarios aprovechar la búsqueda y el análisis sofisticados directamente en los datos de LLM, lo que hace que los flujos de trabajo existentes vuelvan a las herramientas con las que los usuarios se sienten más cómodos.

Echa un vistazo a la evaluación de seguridad de LLM, que profundiza en estos temas.

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a discreción exclusiva de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.