Imagínese la próxima reunión de la junta directiva. Usted, un líder de seguridad en su organización, presentará su presentación estándar con riesgos, mitigaciones e incidentes. Luego, uno de los miembros de la junta preguntará: ¿Cómo se están preparando para proteger las nuevas tecnologías de IA y los canales MLOps que la empresa ya está utilizando?
Aquí tienes tu respuesta.
La IA trae consigo nuevos riesgos
Los canales de MLOps (a veces también conocidos como AI Ops), si bien son similares a los sistemas de procesamiento de datos tradicionales en su valor para las organizaciones, tienen vulnerabilidades distintas. Los atacantes pueden intentar insertar sesgos, manipular los resultados del modelo o comprometer la integridad de los datos o las herramientas, apuntando a socavando la confiabilidad del modelo y distorsionando los procesos de toma de decisiones. ATLAS, un marco de la organización MITRE para la protección de MLOps, subraya la necesidad de medidas de seguridad personalizadas que aborden estos desafíos.
La IA traerá consigo nuevas regulaciones
El floreciente campo de la IA y MLOps está bajo un creciente escrutinio por parte de los reguladores de todo el mundo. A falta de una legislación federal integral en los Estados Unidos, la orientación de organismos como el Instituto Nacional de Estándares y Tecnología (NIST), como el Marco de gestión de riesgos de inteligencia artificial 1.0, ofrece una visión de los futuros marcos regulatorios. El marco enfatiza la confiabilidad de los sistemas de IA, incluidas las siete características definidas de los sistemas de IA confiables: la seguridad, seguridad y resiliencia, explicabilidad e interpretabilidad, privacidad mejorada, justo con sesgo dañino gestionado, responsable y transparente, así como las válido y confiable.
MLOps y la cadena de suministro de software tienen mucho en común
Las similitudes entre las vulnerabilidades del canal MLOps y los riesgos de la cadena de suministro de software tradicional son sorprendentes. Ambos ámbitos enfrentan amenazas de compromiso cuyo objetivo es socavar la integridad del proceso de desarrollo y la seguridad del producto final. Modificar maliciosamente un LLM es bastante similar a modificar maliciosamente una dependencia de software; modificar maliciosamente el software que ejecuta el LLM es, de hecho, un ataque a la cadena de suministro de software; Los requisitos de responsabilidad, transparencia y confianza discutidos en el mundo de la IA son exactamente lo que respalda los requisitos de SBOM en el mundo de la cadena de suministro de software.
La organización MITRE publica modelos de ciberseguridad. MITRE ha publicado recientemente el modelo Atlas para protección MLOps, que se puede encontrar aquí. A continuación se ofrece una descripción general del modelo:
Al igual que en el ámbito de la ciberseguridad "tradicional", las regulaciones sobre IA y MLOps aún se están desarrollando. Seguir estas regulaciones emergentes facilitaría la protección de los activos existentes de MLOps, así como también dar fe del cumplimiento de los procesos de MLOps con las mejores prácticas existentes y emergentes. Las organizaciones deberán dar fe de la integridad de su modelo, así como de que su modelo es imparcial.
Hay tecnologías que servirán a ambos ámbitos
Las tecnologías que garantizan la integridad de los datos, el código y las herramientas pueden proporcionar los controles de integridad necesarios para la seguridad de la cadena de suministro de software tanto de MLOps como de DevOps.
Las tecnologías que brindan transparencia y medidas de confianza del software pueden proporcionar valores similares para MLOps.
Tecnología de seguridad de la cadena de suministro basada en certificaciones
El concepto de protección de la cadena de suministro de software basada en evidencia es simple: no se debe confiar en un artefacto de software a menos que exista evidencia suficiente de su confiabilidad. La implementación de este concepto implica herramientas de recolección de evidencia, un motor de políticas que evalúa la evidencia para verificarla, alertas de violaciones y recomendaciones de mitigaciones, y mecanismos de intercambio que permitan la transparencia y la colaboración. El marco integral es un ejemplo académico de tal solución. La plataforma de cadena de suministro de software de Scribe es, entre otras cosas, una manifestación comercial de esta tecnología y amplió su tecnología para soportar los desafíos de ML-Ops.
El enfoque basado en evidencia de Scribe es independiente de los detalles específicos de la evidencia; por lo tanto, la misma tecnología puede servir para la protección MLOps, por ejemplo:
- Garantizar la integridad del software y la integridad del proceso de aprendizaje automático.
- Garantizar la integridad de las dependencias de código abierto y la integridad del modelo de IA.
- Evaluar los informes SAST para garantizar informes de herramientas de prueba específicas de IA (por ejemplo, pruebas de sesgo).
- Compartir SBOM y evaluaciones de políticas, así como evaluaciones de políticas de MLBOM y MLOps.
Tecnología de cadena de suministro de software de seguridad Scribe para operaciones de IA/ML
El MITRE ATLAS y la tecnología de Scribe
A continuación se muestra un mapeo de las capacidades actuales de Scribe en comparación con el mapa de ataque MITRE ATLAS:
| Etapa de ataque | Técnicas | La solución del escriba |
|---|---|---|
| Desarrollo de recursos para atacantes | Publicar conjuntos de datos envenenados Datos de entrenamiento de veneno. | Integridad de los datos: Da fe de los conjuntos de datos consumidos y verifica la fuente y el contenido de los conjuntos de datos. Dar fe de los datos de capacitación y verificar el contenido y la fuente de los datos de capacitación. |
| Acceso inicial | Compromiso de la cadena de suministro de aprendizaje automático | Integridad de datos y código: Da fe de los datos, modelos, software y configuraciones de los canales de ML. Aplicación de la política de canalización de ML: Dar fe de las acciones y verificar las políticas en consecuencia (p. ej., kit de proceso de lanzamiento, pruebas, patrones de acceso) |
| Acceso inicial, impacto | Evadir el modelo ML (p. ej., solicitudes elaboradas) | Seguimiento preciso de la tubería: Realice un seguimiento de los recursos y detecte anomalías en los patrones de acceso a las canalizaciones de ML (FS-Tracker) |
| Ejecución | Intérprete de comandos y secuencias de comandos | Seguimiento preciso de la tubería: Realice un seguimiento de los recursos y detecte anomalías en los patrones de acceso a las canalizaciones de ML (FS-Tracker) |
| Persistencia | Datos de entrenamiento de veneno | Integridad de los datos: Dar fe de los datos de entrenamiento, verificar el contenido y la fuente de los datos de entrenamiento. |
| Persistencia, Puesta en escena de ataques de aprendizaje automático | Modelo de aprendizaje automático de puerta trasera | Integridad de los datos: Dar fe del ciclo de vida del modelo ML y verificar en uso. |
| Impacto | Mal uso del sistema por efectos externos | Políticas a nivel del sistema: Dar fe del comportamiento y las características del sistema y aplicar políticas en consecuencia (por ejemplo, costos de computación, patrones de acceso). |
A continuación se muestra un mapeo de las mitigaciones de MITRE en comparación con la tecnología de Scribe:
| ID de mitigación MITRE | Mitigación | La solución del escriba |
|---|---|---|
| AML.M0005 | Controle el acceso a modelos de aprendizaje automático y datos en reposo | Seguimiento preciso de la tubería: Realice un seguimiento de los recursos y detecte anomalías en los patrones de acceso a las canalizaciones de ML (FS-Tracker) |
| AML.M0007 | Desinfectar datos de entrenamiento | Integridad de los datos: Dar fe y verificar los datos utilizados para la capacitación. |
| AML.M0011 | Restringir la carga de la biblioteca | Integridad de datos y código: Dar fe y verificar el modelo de datos y la carga de la biblioteca de códigos. |
| AML.M0013 | Firma de código | Integridad del código: Dar fe y verificar el código utilizado. |
| AML.M0014 | Verificar artefactos de aprendizaje automático | Integridad de datos y código: Dar fe y verificar el modelo de datos y la carga de la biblioteca de códigos. |
| AML.M0016 | Exploración de Vulnerabilidades | Escaneo de vulnerabilidades, evaluación de políticas: Dar fe de la ejecución de herramientas como el escaneo de vulnerabilidades. Evaluar políticas respecto de estas certificaciones. Analice las vulnerabilidades según las certificaciones de SBOM recopiladas del proceso de aprendizaje automático. |
Firmar y verificar modelos y conjuntos de datos de ML usando Valint
Valint es la poderosa herramienta CLI de Scribe para generar y validar certificaciones. Valint se puede utilizar para firmar y verificar conjuntos de datos y modelos de ML.
Ejemplo:
Queremos utilizar el modelo HuggingFace. wtp-bert-tiny. Para evitar comprometer el modelo, queremos firmarlo y verificarlo antes de su uso. La creación de una atestación (evidencia firmada) se puede realizar con el siguiente comando:
valint bom git: https://huggingface.co/benjamin/wtp-bert-tiny -o attest
Este comando creará una certificación firmada para el repositorio del modelo. La certificación se almacenará en un almacén de certificaciones (en este caso, una carpeta local) y se firmará (en este caso, mediante la firma sin llave Sigstore).
Un uso típico del modelo sería clonar el repositorio y utilizar sus archivos. Se puede verificar la integridad del modelo inmediatamente después de la descarga con los siguientes comandos:
git clone git:https://huggingface.co/benjamin/wtp-bert-tiny valint verificar git:wtp-bert-tiny
La verificación de la integridad del modelo antes de cada uso se puede realizar con el siguiente comando:
Valint verificar git:wtp-bert-tiny
Notas:
- Se puede utilizar un enfoque similar para firmar y verificar conjuntos de datos.
- Una de las características de los modelos ML es su enorme tamaño. Para evitar descargar y manejar archivos grandes que no son necesarios, un las mejores prácticas es descargar solo los archivos necesarios. Este caso de uso es compatible con Valint, que admite la firma solo de una carpeta o archivo específico.
Verificación de políticas en modelos de ML
Scribe's Valint es una poderosa herramienta de verificación de políticas. Una de las formas de gestionar el riesgo es hacer cumplir las políticas. En la siguiente sección, demostraremos cómo reducir el riesgo aplicando una política de licencias sobre los modelos de ML utilizados.
Supongamos que solo permitimos el uso de la licencia MIT en nuestro proyecto. Una vez configurado, Valint puede verificarlo:
Valint verificar git:wtp-bert-tiny -d att -c verificar-licencia.yml
Este comando usa el verificar-licencia política que se define de la siguiente manera:
attest: cocosign: políticas: - nombre: ML-policy enable: true módulos: - nombre: verificar-tipo de licencia: verificar-artefacto habilitar: verdadero entrada: firmado: verdadero formato: attest-cyclonedx-json rego: ruta: verificar-hf -licencia.rego
La política implementada en el verificar-licencia-hf.rego El archivo extrae de la certificación firmada el ID del modelo HuggingFace, extrae información de la API de HuggingFace sobre el modelo y verifica que sea MIT.
Se puede utilizar un flujo similar para verificar licencias de conjuntos de datos de código abierto.
Caso de uso: protección de un servicio ML-Ops del mundo real
Un servicio ML-Ops es parte de una aplicación que permite un fácil acceso a modelos de IA; los usuarios del servicio solo necesitan expresar sus solicitudes, y el servicio realiza todos los aspectos prácticos para acceder al modelo ML entre bastidores.
Ejemplo:
Queremos producir y utilizar un servicio que exponga el acceso a Microsoft "ayuda”Paquete de código abierto (en palabras simples, este paquete permite una mejor utilización de los modelos de lenguaje grandes (LLM) al ejecutar cadenas de consultas en lugar de un único mensaje).
El servicio será una imagen de Docker que contendrá el código de servicio y el modelo. Basaremos nuestro código en el proyecto de la cadena de Andrómeda. El proyecto envuelve la biblioteca de orientación con un servicio y crea una imagen acoplable con la aplicación.
La siguiente es la versión básica de Dockerfile:
DESDE python:3.10 COPIAR ./requirements.cpu.txt requisitos.txt EJECUTAR pip3 install -r requisitos.txt EJECUTAR mkdir models \ cd models \ git clone https://huggingface.co/api/models/benjamin/wtp-bert- tiny COPY ./guidance_server guiado_server WORKDIR guiado_server # Establece el punto de entrada CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "9000"]
Es bastante sencillo; Al construir la ventana acoplable, se instalan las dependencias del código, se instala el modelo y el código de servicio se copia en la imagen de Docker.
Una vez creada la imagen, podemos crear una certificación firmada de la misma con el siguiente comando Valint:
valint bom ml-servicio:último -o attest
Este comando genera una certificación firmada que contiene un SBOM detallado de la imagen de Docker denominada ml-service.
Esta atestación se puede utilizar más adelante para verificar la imagen de Docker mediante el siguiente comando:
Valint verificar ml-servicio: último
Este comando verifica la integridad de la imagen, tanto el código como el modelo ML. La verificación se puede realizar cada vez que se implementa la imagen, asegurando así el uso de un contenedor válido.
Creación de un servicio de operaciones de aprendizaje automático protegido
Combinando las capacidades demostradas en los párrafos anteriores, ahora podemos demostrar cómo proteger la construcción de un servicio ML-Ops:
Requisito previo: una vez seleccionado un modelo, cree una certificación del mismo:
valint bom git: https://huggingface.co/benjamin/wtp-bert-tiny -o attest
Construir canalización:
1. Verificar la integridad y la licencia del modelo en proceso de construcción:
git clone https://huggingface.co/benjamin/wtp-bert-tiny valint verificar git:wtp-bert-tiny -d att -c verificar-license.yml
2. Construya la ventana acoplable y cree una certificación de la misma:
docker build -t ml-service:latest . valint bom ml-servicio:último -o attest
3. Antes de utilizar la imagen, verifíquela:
Valint verificar ml-servicio: último
Este paso de verificación garantiza que la imagen implementada es la creada con el modelo verificado en su interior.
Se puede realizar una verificación similar antes de cada implementación en Kubernetes utilizando el controlador de admisión de Scribe.
Recomendación
Invertir en un producto de seguridad de la cadena de suministro de software en 2024 que aborde tanto los requisitos inmediatos de la cadena de suministro de software como las demandas cambiantes de MLOps es una opción estratégica.
Invertir en una solución basada en evidencia con un motor de políticas flexible permitiría la integración futura con tecnologías de seguridad MLOps emergentes específicas de dominio a medida que maduren.
¿Por qué esta es una publicación de blog de Scribe Security?
Debería saber la respuesta si ha leído todo hasta aquí: Scribe proporciona una solución de seguridad de la cadena de suministro de software basada en evidencia/certificación con un motor de políticas flexible y ampliable. Para ver un caso de uso elaborado sobre la protección de una canalización MLOps utilizando productos Scribe, presione aquí.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
