Metodología para la respuesta a incidentes en cargas de trabajo de IA generativa – Parte 2: Aplicación de la Metodología

Por Anna McAbee, Arquitecta de Soluciones Especialista en Seguridad enfocada en servicios financieros, IA generativa y respuesta a incidentes en AWS; Steve De Vera, gerente del Equipo de Respuesta a Incidentes de Clientes de AWS; AJ Evans, Ingeniero de Seguridad del Equipo de Respuesta a Incidentes de Clientes de AWS y Jennifer Paz, Ingeniera de Seguridad en AWS.

En la primera parte de esta serie Metodología para la respuesta a incidentes en cargas de trabajo de IA generativa – Parte 1: La Metodología, presentamos una metodología detallada para abordar incidentes de seguridad en sistemas de IA generativa. Ahora, en esta segunda parte, vamos a pasar a aplicar esa metodología en la práctica analizando un ejemplo de incidente de seguridad.  Esto nos permitirá entender mejor cómo se implementa la metodología y los beneficios que puede aportar cuando se enfrenta a un incidente en sistemas de IA generativa.

Analizar un caso práctico nos ayudará a consolidar los conceptos presentados anteriormente y estar mejor preparados para aplicarlos en situaciones reales. Así que sin más demora, comencemos a ver cómo se aplica la metodología.

Ejemplo de incidente

Para ver cómo usar la metodología para responder a un incidente, recorramos un ejemplo de evento de seguridad en el que un usuario no autorizado compromete una aplicación de IA generativa alojada en AWS mediante el uso de credenciales expuestas en un repositorio de código público. Nuestro objetivo es determinar qué recursos se accedieron, modificaron, crearon o eliminaron. En este ejemplo nos vamos a enfocar en una aplicación de IA generativa que usa el servicio de Amazon Bedrock.

Para investigar los eventos de seguridad de IA generativa en AWS, estas son las principales fuentes de registro que debe revisar:

• AWS CloudTrail
• Amazon CloudWatch
• Registros de flujo de VPC (Amazon VPC Flow Logs)
• Eventos de datos de Amazon Simple Storage Service (Amazon S3) (para detectar evidencia de acceso a los buckets de S3 de una organización)
• Registros de invocación de modelos de Amazon Bedrock (si su aplicación usa este servicio)

Acceso

El análisis del acceso para una aplicación de IA generativa es similar al de una aplicación web de tres niveles estándar. Para comenzar, determine si una organización tiene acceso a su cuenta de AWS. Si se perdió o se cambió la contraseña del usuario raíz de la cuenta de AWS, restablezca la contraseña. Luego, le recomendamos que habilite inmediatamente un dispositivo de autenticación multifactor (MFA) para el usuario raíz, esto debería bloquear que un actor malintencionado acceda al usuario raíz.

Después determine si persiste el acceso no autorizado a la cuenta. Para ayudar a identificar las acciones mutantes registradas por AWS Identity and Access Management (IAM) y AWS Security Token Service (Amazon STS), consulte la sección Análisis del runbook de Credenciales de IAM comprometidas en GitHub. Por último, asegúrese de que no se almacenen claves de acceso en repositorios públicos o en el código de su aplicación; para obtener alternativas, consulte Alternativas a las claves de acceso a largo plazo.

Cambios en la infraestructura

Para analizar los cambios en la infraestructura de una aplicación, debe considerar tanto el plano de control como el plano de datos. En nuestro ejemplo, imagina que se usó Amazon API Gateway para la autenticación a los componentes de la aplicación de IA generativa y que otros recursos accesorios estaban interactuando con su aplicación. Si bien podrías revisar los cambios en el plano de control a estos recursos en CloudTrail, necesitaría activar registros adicionales para revisar los cambios realizados en el sistema operativo del recurso. Los siguientes son algunos nombres comunes de eventos de plano de control que podría encontrar en CloudTrail para este elemento:

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

Cambios en la IA

Los cambios no autorizados pueden incluir, entre otros, mensajes del sistema, código de la aplicación, barreras (guardrails) y disponibilidad del modelo. El acceso de usuarios internos a los recursos de IA generativa que AWS aloja se registra en CloudTrail y aparece con una de las siguientes fuentes de evento:

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

Los siguientes son un par de ejemplos de los nombres de eventos en CloudTrail que representarían el registro de manipulación de recursos de IA generativa en nuestro escenario de ejemplo:

• bedrock:PutModelInvocationLoggingConfiguration
• bedrock:DeleteModelInvocationLoggingConfiguration

Los siguientes son algunos nombres de eventos comunes en CloudTrail que representarían el acceso a la configuración del servicio de IA/ML:

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

En nuestro ejemplo, el usuario no autorizado ha obtenido acceso a la cuenta de AWS. Ahora imagina que el usuario comprometido tiene una política adjunta que le otorga acceso total a todos los recursos. Con este acceso, el usuario no autorizado puede enumerar cada componente de Amazon Bedrock e identificar la base de conocimiento y las barreras (guardrails) que forman parte de la aplicación.

El usuario no autorizado luego solicita acceso al modelo a otros modelos fundacionales (FM) dentro de Amazon Bedrock y elimina las barreras (guardrails) de seguridad existentes. El acceso a otros modelos base podría indicar que el usuario no autorizado tiene la intención de usar la aplicación de IA generativa para sus propios fines, y la eliminación de las barreras (guardrails) de seguridad minimiza los filtros o las comprobaciones de salida del modelo. AWS recomienda que implemente controles de acceso detallados mediante políticas de IAM y políticas basadas en recursos para restringir el acceso solo a los recursos de Amazon Bedrock, las funciones de AWS Lambda y otros componentes que requiera la aplicación. Además, debe exigir el uso de MFA para los usuarios de IAM, roles y cuentas de servicio con acceso a componentes críticos como Amazon Bedrock y otros componentes de su aplicación de IA generativa.

Cambios en el almacén de datos

Típicamente, se usa y se accede a un almacén de datos y una base de conocimiento a través de la invocación del modelo, y para Amazon Bedrock, se incluye la llamada a la API bedrock:InvokeModel.

Sin embargo, si un usuario no autorizado obtiene acceso al entorno, puede crear, cambiar o eliminar las fuentes de datos y las bases de conocimiento con las que se integran las aplicaciones de IA generativa. Esto podría provocar la exfiltración o destrucción de datos o modelos, así como el envenenamiento de datos y podría crear una condición de denegación de servicio para el modelo. Los siguientes son algunos nombres de eventos comunes en CloudTrail que representarían cambios en las fuentes de datos de IA/ML en nuestro escenario de ejemplo:

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

Para ver la lista completa de posibles acciones, consulte la Referencia de la API de Amazon Bedrock.

En este escenario, hemos establecido que el usuario no autorizado tiene acceso total a la aplicación de IA generativa y que se realizó cierta enumeración. Luego, el usuario no autorizado identificó el bucket de S3 que era la base de conocimiento de la aplicación de IA generativa y cargó datos inexactos, lo que corrompió el LLM (también conocido como modelos de lenguaje de gran tamaño). Para ver ejemplos de esta vulnerabilidad, consulte la sección LLM03 Training Data Poisoning en OWASP TOP 10 for LLM Applications.

Invocación

Amazon Bedrock usa APIs específicas para registrar la invocación del modelo. Cuando se invoca un modelo en Amazon Bedrock, CloudTrail lo registra. Sin embargo, para determinar los mensajes que se enviaron al modelo de IA generativa y la respuesta de salida que se recibió del mismo, debe haber configurado el registro de invocación del modelo.

Estos registros son cruciales porque pueden revelar información importante, como si un actor malintencionado intentó hacer que el modelo revelara información de sus almacenes de datos o liberara datos con los que se entrenó o ajustó el modelo. Por ejemplo, los registros podrían revelar si un atacante intentó ingresar datos de entrada cuidadosamente diseñados para extraer datos confidenciales, eludir los controles de seguridad o generar contenido que viole sus políticas. Usando los registros, también podría saber si se usó el modelo para generar información errónea, spam u otras salidas maliciosas que podrían usarse en un evento de seguridad.

Nota: Para servicios como Amazon Bedrock, el registro de invocación está desactivado de forma predeterminada. Recomendamos que habilite los eventos de datos y el registro de invocación de modelos para los servicios de IA generativa, cuando estén disponibles. Sin embargo, es posible que su organización no quiera capturar y almacenar registros de invocación por razones de privacidad y legales. Una preocupación común es que los usuarios ingresen datos confidenciales como entrada, lo que amplía el alcance de los activos que se deben proteger. Esta es una decisión empresarial que se debe tener en cuenta.

En nuestro escenario de ejemplo, imagine que no se activó la invocación del modelo, por lo que el responsable de la respuesta al incidente no pudo recopilar los registros de invocación para ver los datos de entrada o salida del modelo para las invocaciones no autorizadas. El responsable de la respuesta al incidente no podría ver los mensajes y las respuestas posteriores del LLM. Sin habilitar este registro, tampoco podrían ver los datos de solicitud completos, los datos de respuesta y los metadatos asociados con las llamadas de invocación.

Los nombres de eventos en los registros de invocación de modelos que representarían el registro de invocación de modelos de Amazon Bedrock incluyen:

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

La siguiente es una entrada de registro de muestra para el registro de invocación de modelos de Amazon Bedrock:

Figura 2: Registro de invocación del modelo de muestra que incluye la solicitud y la respuesta

Datos privados

Desde un punto de vista arquitectónico, las aplicaciones de IA generativa no deberían tener acceso directo a los datos privados de una organización. Debe clasificar los datos utilizados para entrenar una aplicación de IA generativa o para el uso de  generación aumentada por recuperación (Retrieval Augmented Generation- RAG) como datos del almacén de datos y segregarlos de los datos privados, a menos que la aplicación de IA generativa use los datos privados (por ejemplo, en el caso en que una aplicación de IA generativa tenga la tarea de responder preguntas sobre registros médicos de un paciente). Una forma de asegurarse de que los datos privados de una organización se segreguen de las aplicaciones de IA generativa es usar una cuenta separada y autenticar y autorizar el acceso según sea necesario para adherirse al principio del privilegio mínimo.

Agencia

La agencia excesiva de un LLM se refiere a un sistema de IA que tiene demasiada autonomía o poder de toma de decisiones, lo que lleva a consecuencias no deseadas y potencialmente dañinas. Esto puede ocurrir cuando un LLM se implementa con un control, restricciones o alineación insuficientes con los valores humanos, lo que resulta en que el modelo tome decisiones que se desvían de lo que la mayoría de los humanos consideraría beneficioso o ético.

En nuestro escenario de ejemplo, la aplicación de IA generativa tiene permisos excesivos para servicios que no son requeridos por la aplicación. Imagine que el código de la aplicación se estaba ejecutando con un rol de ejecución con acceso total a Amazon Simple Email Service (Amazon SES). Esto podría permitir que el usuario no autorizado envíe correos electrónicos de spam en nombre de los usuarios en respuesta a un mensaje. Puede evitar esto limitando los permisos y la funcionalidad de los complementos y agentes de la aplicación de IA generativa. Para obtener más información, consulte OWASP Top 10 for LLM, evidencia de LLM08 Excessive Agency.

Durante una investigación, mientras se analizan los registros, tanto el campo sourceIPAddress (origen del protocolo de Internet (IP)) como el campo userAgent estarán asociados con la aplicación de IA generativa (por ejemplo, sagemaker.amazonaws.com, bedrock.amazonaws.com o q.amazonaws.com). Algunos ejemplos de servicios que comúnmente pueden llamarse o invocarse por otros servicios son Lambda, Amazon SNS y Amazon SES.

Conclusión

En la primera parte de esta serie, presentamos una metodología detallada para abordar incidentes de seguridad en sistemas de IA generativa. Ahora, en esta segunda parte, hemos pasado a aplicar esa metodología en la práctica analizando un ejemplo de incidente de seguridad.

Esto nos ha permitido entender mejor cómo se implementa la metodología y los beneficios que puede aportar cuando se enfrenta a un incidente en sistemas de IA generativa. Analizar un caso práctico nos ha ayudado a consolidar los conceptos presentados anteriormente y estar mejor preparados para aplicarlos en situaciones reales.

Hemos visto cómo un usuario no autorizado logró comprometer una aplicación de IA generativa alojada en AWS, cómo pudo enumerar los componentes de la aplicación y acceder a la base de conocimiento para corromperla. También hemos discutido la importancia de habilitar el registro de invocación del modelo para poder analizar las entradas y salidas del sistema en caso de un incidente.

Finalmente, hemos destacado la necesidad de limitar los permisos y la funcionalidad de los componentes de la aplicación de IA generativa para evitar que un actor malicioso pueda abusar de ellos y ganar una agencia excesiva. Con estos conocimientos, estamos mejor equipados para aplicar nuestra metodología de respuesta a incidentes cuando enfrentemos un escenario real en sistemas de IA generativa.

Autores

	Anna McAbee. Anna es una Arquitecta de Soluciones Especialista en Seguridad enfocada en servicios financieros, IA generativa y respuesta a incidentes en AWS. Fuera del trabajo, a Anna le gusta Taylor Swift, alentar al equipo de fútbol de los Florida Gators, probar vinos y viajar por el mundo.
	Steve De Vera. Steve es un gerente del Equipo de Respuesta a Incidentes de Clientes de AWS (CIRT). Está apasionado por el BBQ estilo estadounidense y es un juez certificado de competencia de BBQ. Tiene un perro llamado Brisket.
	AJ Evans. AJ es un Ingeniero de Seguridad del Equipo de Respuesta a Incidentes de Clientes de AWS (CIRT). Utiliza su experiencia como ex agente especial del Servicio Secreto de los Estados Unidos, donde se enfocó en delitos financieros e intrusiones de red, para proteger a los clientes de AWS. Cuando no está respondiendo a las últimas amenazas cibernéticas, AJ disfruta de los juegos, tocar música, construir PC personalizados y imprimir en 3D sus propias creaciones.

Jennifer Paz. Jennifer es una Ingeniera de Seguridad con más de una década de experiencia, actualmente en el Equipo de Respuesta a Incidentes de Clientes de AWS (CIRT). Jennifer disfruta ayudando a los clientes a abordar los desafíos de seguridad e implementar soluciones complejas para mejorar su postura de seguridad. Cuando no está trabajando, Jennifer es una ávida caminante, corredora, entusiasta del pickleball, viajera y siempre en busca de nuevas aventuras culinarias.