Compartir a través de

Evaluación de riesgos de IA para ingenieros de ML

  • Artículo

A pesar de las razones convincentes para proteger los sistemas de ML, una encuesta de Microsoft’ a 28 empresas descubrió que la mayoría de los profesionales del sector aún no se han familiarizado con el aprendizaje automático (ML) adversario. 25 de las 28 empresas indicaron que no tienen las herramientas adecuadas para proteger sus sistemas de ML. Es más, buscan orientación de forma explícita. Hemos detectado que la falta de preparación no se limita a las organizaciones; sino que abarca desde empresas de la lista Fortune 500 hasta administraciones públicas y organizaciones sin ánimo de lucro. Los clientes reconocen la necesidad de proteger los sistemas de inteligencia artificial, pero simplemente no saben cómo hacerlo.

Este documento es un primer paso para que las organizaciones evalúen la posición de seguridad de sus sistemas de inteligencia artificial. Pero en lugar de agregar otro marco que cumplan las organizaciones, intentamos proporcionar el contenido de forma que se pueda ajustar a los marcos de evaluación de riesgos de seguridad tradicionales existentes.

En este documento hay tres objetivos:

  • Proporcionar una perspectiva completa de la seguridad del sistema de inteligencia artificial. Hemos examinado cada elemento del ciclo de vida del sistema de inteligencia artificial en una configuración de producción: desde la recopilación de datos hasta el procesamiento de datos y la implementación del modelo. También hemos tenido en cuenta la cadena de suministro de inteligencia artificial y los controles y las directivas con respecto a la copia de seguridad, la recuperación y los planes de contingencia relacionados con los sistemas de inteligencia artificial.
  • Describir amenazas a recursos críticos de inteligencia artificial e instrucciones para protegerlos. Para ayudar directamente a los ingenieros y profesionales de seguridad, enumeramos la declaración sobre amenazas en cada paso del proceso de creación del sistema de IA. A continuación, proporcionamos un conjunto de directrices que superponen y refuerzan las prácticas existentes en el contexto de los sistemas de inteligencia artificial.
  • Permitir que las organizaciones realicen evaluaciones de riesgos de seguridad de inteligencia artificial. El marco ayuda a recopilar información sobre el estado actual de seguridad de los sistemas de inteligencia artificial de una organización, realizar análisis de brechas y llevar a cabo un seguimiento del progreso de la posición de seguridad.

Lo formulamos junto con las partes interesadas de Microsoft, con representantes de Seguridad de Azure, Estrategia de IA responsable en ingeniería, Centro de respuestas de seguridad de Microsoft, Seguridad de Azure y con la inteligencia artificial, la ética y los efectos en ingeniería e investigación (Aether).

Introducción

Se recomienda usar este documento para comenzar el análisis sobre la protección de sistemas de inteligencia artificial alineados con los esfuerzos de seguridad de la información y los objetivos empresariales. El documento se centra en los sistemas de inteligencia artificial e inclusión de controles tradicionales, ya que los sistemas de inteligencia artificial se basan en la infraestructura de TI tradicional.

Tratamos las siguientes áreas relacionadas con los sistemas de inteligencia artificial.

Controles de gestión Descripción
Directivas de seguridad del aprendizaje automático Controles y directivas relacionados con las directivas documentadas que rigen el aprendizaje automático, la inteligencia artificial y la seguridad de la información.
Controles técnicos Descripción
datos, recopilación Controles y directivas relacionados con la recopilación, el almacenamiento y la clasificación de datos que se usan para el aprendizaje automático y la inteligencia artificial.
Procesamiento de datos Controles y directivas relacionados con el procesamiento e ingeniería de datos usados para el aprendizaje automático y la inteligencia artificial.
Entrenamiento del modelo Controles y directivas relacionados con el diseño, el entrenamiento y la validación de modelos.
Implementación de modelo Controles y directivas relacionados con la implementación de modelos y la infraestructura auxiliar.
Supervisión del sistema Controles y directivas relacionados con la supervisión continua de los sistemas de aprendizaje automático.
Administración de incidentes Controles y directivas relacionados con la forma en que se controlan los incidentes relacionados con el sistema de inteligencia artificial.
Continuidad empresarial y recuperación ante desastres Controles y directivas relacionados con la pérdida de propiedad intelectual mediante el robo de modelos, la degradación del servicio u otras vulnerabilidades específicas de la inteligencia artificial.

Adaptamos el marco existente de controles y directivas de la popular norma ISO27001:2013 y lo asignamos a través del proceso de creación del sistema de inteligencia artificial, desde la fase de recopilación de datos para responder a las amenazas hasta los sistemas de inteligencia artificial. Es posible que las organizaciones tengan algunos controles existentes implementados desde ISO27001:2013, o todos ellos, o bien que ya cumplan varios marcos de riesgo (NIST 800-53, PCI-DSS, FedRamp, etc.) como parte de los esfuerzos de seguridad de la información existentes.

Si no se protegen adecuadamente los sistemas de inteligencia artificial, se aumenta el riesgo no solo de los sistemas de inteligencia artificial tratados en esta evaluación, sino que, en general, todo el entorno de cumplimiento y las tecnologías de la información.

El objetivo de este documento no es reemplazar ninguno de estos trabajos existentes, sino describir la protección de sistemas de inteligencia artificial desde el punto de vista de las herramientas y marcos existentes, y ampliarlo a todas las partes del proceso de creación de inteligencia artificial.

La guía que se muestra aquí no es prescriptiva, ya que requeriría más contexto, como la plataforma subyacente, el tipo de datos subyacente y la elección del algoritmo. Si es cliente de Azure Machine Learning, consulta el artículo Seguridad y gobernanza para empresas.

Gravedad sugerida, probabilidad, impacto

No todos los controles tienen una importancia crítica para la seguridad de un sistema de inteligencia artificial. Por lo tanto, para priorizar correctamente el trabajo, la organización debe clasificar cada control con una calificación de gravedad que sea relevante para el impacto empresarial de no implementar un control determinado. Una organización podría optar por aceptar el riesgo de un control crítico y, en su lugar, implementar un control de compensación para reducir el riesgo. En última instancia, estas clasificaciones sirven para ayudar a guiar la toma de decisiones basada en riesgos en lugar de recetar actividades.

Gravedad

La gravedad de un riesgo dependerá del caso de uso del modelo de IA. Afortunadamente, si los datos o sistemas que se usan eran un problema crítico antes de integrar el aprendizaje automático, deberían seguir siéndolo. Del mismo modo, si el modelo usado es estándar sin ninguna otra entrada, en función del contexto en el que se usa el modelo, es probable que la gravedad de un riesgo sea menor. Las técnicas como la privacidad diferencial pueden reducir el impacto potencial de un riesgo. Pero este contexto no reduciría la importancia del sistema, los datos o el modelo. Se recomienda proteger los modelos mediante una estrategia de defensa en profundidad en lugar de depender de una implementación defensiva.

Nivel de gravedad sugerido

Sugerido como crítico

  • Si el modelo de inteligencia artificial se entrena con datos personales confidenciales, datos clasificados o datos que regulan requisitos de cumplimiento como, por ejemplo, PCI, HIPAA, GLBA, etc., o los ingiere.
  • Si el modelo de inteligencia artificial se usa en una aplicación o sistema crítico para la empresa, de modo que el riesgo tendría un gran impacto negativo en las operaciones empresariales.
  • Si el modelo de inteligencia artificial se usa en aplicaciones en las que es posible que se produzcan daños físicos o incluso la muerte.
  • Si el modelo de IA se usa en un sistema que admite infraestructura crítica (por ejemplo, agua, electricidad, sanidad).

Sugerido como elevado

  • Si el modelo de inteligencia artificial está entrenado con datos personales confidenciales, información confidencial o datos que la organización considera críticos por otros motivos, o los ingiere.
  • Si el riesgo de este modelo de inteligencia artificial tuviera un impacto grande pero limitado en las operaciones empresariales
  • Si el modelo de inteligencia artificial se usa en sistemas o aplicaciones críticas para la empresa.

Sugerido como medio

  • Si el modelo de IA se entrena con un subconjunto de datos de entrenamiento que contiene tipos de datos confidenciales.
  • Si el riesgo de este modelo de IA tuviera implicaciones para los modelos implementados en producción.
  • Si el modelo de IA se usa en aplicaciones no críticas, pero orientadas a la empresa.
  • Si el modelo de IA no se usa en producción, pero tiene información sobre los modelos de producción.

Sugerido como bajo

  • Si el modelo de IA se entrena con datos que no se usan en producción.
  • Si el modelo de IA no se usa en producción y no tiene información sobre los modelos de producción.

Sugerido como informativo

  • Si los datos no están clasificados y proceden de un origen verificado.
  • Si el modelo de IA no se usa en producción.

Probabilidad

La probabilidad tiene dos componentes principales, la disponibilidad del modelo y la disponibilidad de técnicas. Para reducir la probabilidad de un ataque, una organización debe implementar controles que hagan lo siguiente:

  1. Quitar la superficie expuesta a ataques o hacer que la superficie expuesta a ataques sea más difícil de enumerar.
  2. Asegurarse de que el registro y las alertas funcionan según lo diseñado para garantizar la resolución rápida de problemas.
  3. Asegurarse de que todos los sistemas auxiliares estén actualizados con los requisitos de seguridad.

Los controles podrían incluir puntos de conexión de acceso, segmentación de red o limitación de velocidad. Se debe prestar especial atención a los flujos de tráfico y a los diagramas de red o canalización; por ejemplo, un atacante que pone en peligro, orienta externamente el punto de conexión y trabaja hacia atrás mediante una canalización.

Impacto

El impacto está relacionado con cómo afecta a la organización. Se recomienda empezar a familiarizarse con diferentes formas en que se pueden atacar los sistemas de ML y plantearse las formas en que los modelos de producción pueden afectar a la organización. Para obtener más información, consulta el artículo Modos de error en Machine Learning. Una vez finalizada esta familiarización, se puede asignar a una matriz de gravedad.

Matriz de gravedad

La tabla siguiente es una matriz básica de gravedad de riesgo y vulnerabilidad para empezar a trabajar con las organizaciones. Se recomienda rellenar una categorización similar mediante la realización de arquitectos de seguridad, ingenieros de aprendizaje automático y miembros del equipo rojo de IA.

Tipo de ataque Probabilidad Impacto Explotabilidad
Extracción Alto Bajo Alto
Evasión Alto Media Alto
Inferencia Media Media Media
Inversión Media Alto Media
Envenenamiento Bajo Alto Bajo

"El diseño y el desarrollo de inteligencia artificial segura es una piedra angular del desarrollo de productos de IA en BCG. A medida que la necesidad social de proteger nuestros sistemas de inteligencia artificial es cada vez más evidente, los recursos como el marco de administración de riesgos de seguridad de IA de Microsoft pueden ser contribuciones fundamentales. Ya implementamos los procedimientos recomendados que se encuentran en este marco en los sistemas de inteligencia artificial que desarrollamos para nuestros clientes y estamos encantados de que Microsoft haya desarrollado y abierto el código abierto de este marco para que todo el sector se beneficie". —Jack Molloy, Ingeniero de seguridad sénior, Boston Consulting Group

Uso básico

El resto del documento sigue esta estructura:

  • Un control de riesgos contiene una descripción de qué área cubre el control.
  • El objetivo del control y lo que se supone que debe lograr.
  • Una declaración sobre amenazas que proporciona una descripción del riesgo que se está mitigando.
  • Una guía para implementar un control. Entendemos que no todas las instrucciones se pueden implementar por motivos empresariales legítimos. Se recomienda documentar las guías que no se puedan implementar.

La tabla siguiente es un control extraído de la evaluación de riesgos de los sistemas de inteligencia artificial; las notas se agregan para describir cada parte de una estructura de categorías de riesgo.

Control de ejemplo

Cómo leerlo

1. Recopilación de datos

Categoría principal

Controles y directivas relacionados con la recopilación y el almacenamiento de datos de todos los orígenes que se usan para el aprendizaje automático y la inteligencia artificial.

Describe qué controles de esta categoría cubren a un nivel elevado.

2. Orígenes de datos

Categoría de control

Objetivo: garantizar la integridad de los datos recopilados que se usan para los modelos entrenados.

Debe describir el riesgo que se va a mitigar con los controles.

Declaración sobre amenazas: los datos se recopilan de orígenes que no son de confianza y que podrían contener datos personales confidenciales, otros datos no deseados que podrían afectar a la seguridad de un modelo, o bien presentan riesgos de cumplimiento para la organización.

Una instrucción que describe el resultado de no implementar el control.

Control: los datos deben recopilarse de orígenes de confianza. Se debe mantener y actualizar una lista de orígenes de confianza. Las aprobaciones para recopilar datos que no son de confianza deben tenerse en cuenta caso a caso.

Lenguaje específico que describe el procedimiento recomendado para el control.

Guía:

  1. Se deben realizar todos los esfuerzos razonables para asegurarse de que los datos pueden ser de confianza antes de entrenar un modelo. Los datos que no son de confianza o desconocidos podrían introducir vulnerabilidades de seguridad más adelante en la canalización.
  2. Los datos que contienen datos personales confidenciales, tanto si se usan para fines de ciencia de datos como si no, deben limpiarse o almacenarse y acceder a ellos correctamente.
  3. La recopilación de datos sin tener en cuenta su contexto podría dar lugar a conjuntos de datos que incluyan datos no válidos. Los esfuerzos de recopilación de datos deben tener en cuenta el material protegido por derechos de autor, las infracciones de datos y los puntos de conexión no seguros que filtran datos accidentalmente.

Las guías son recomendaciones para satisfacer los criterios anteriores. Las proporcionamos de una manera independiente del producto y del proveedor para dar espacio a las organizaciones a fin de resolver el problema de una manera que tenga sentido para ellos.

Evaluación de seguridad del aprendizaje automático

Antes de empezar

El propósito de esta evaluación es ayudar a las organizaciones a articular, realizar un seguimiento y corregir los riesgos para las operaciones empresariales que introducen los sistemas de inteligencia artificial. Esta evaluación debe usarse para lo siguiente:

  1. Recopilar información sobre el estado actual de la seguridad de la inteligencia artificial en la organización.
  2. Realizar un análisis de brechas y crear una hoja de ruta para implementar recomendaciones.
  3. Realizar un seguimiento del progreso de la seguridad realizando esta evaluación con una frecuencia anual o semestral.

Si una organización no tiene ningún programa de seguridad, esta evaluación no es el lugar por donde empezar. Una organización debe tener un programa de seguridad de la información en funcionamiento antes de implementar recomendaciones en esta evaluación. Para obtener más información, consulta el artículo Guía de seguridad de Azure en Cloud Adoption Framework.

datos, recopilación

Controles y directivas relacionados con la recopilación y el almacenamiento de datos de todos los orígenes que se usan para el aprendizaje automático y la inteligencia artificial.

Objetivo: garantizar la integridad de los datos recopilados que se usan en los sistemas de IA.

Orígenes de datos

Control: los datos deben recopilarse de orígenes de confianza. Se debe mantener y actualizar una lista de orígenes de confianza. Las aprobaciones de administración para recopilar datos que no son de confianza deben tenerse en cuenta caso a caso. Si se aprueba un origen que no es de confianza, se debe documentar.

Declaración sobre amenazas: los datos se recopilan de orígenes que no son de confianza y que podrían contener datos personales confidenciales, otros datos no deseados que podrían afectar al rendimiento de un modelo, o bien presentan riesgos de cumplimiento para la organización.

Guía:

  1. Los datos de entrada deben validarse y ser de confianza mediante la aprobación de administración antes de usarlos en un sistema de inteligencia artificial.
  2. Los datos recopilados para un sistema de inteligencia artificial deben revisarse antes de su uso o almacenamiento.
  3. Si procede, se deben limpiar las entradas no deseadas de los datos recopilados.
  4. El origen de datos debe documentarse y mantenerse con los datos.
  5. Los datos de inferencia usados para entrenar un modelo no deben ser de confianza de forma implícita y deben tratarse como nuevos datos.
  6. Los esfuerzos de recopilación de datos deben documentarse y auditarse. Los datos recopilados deben tener un propietario responsable de su adhesión a las directivas documentadas.

Tipos de datos confidenciales

Control: garantizar que los datos almacenados de los sistemas de inteligencia artificial estén correctamente protegidos, supervisados y clasificados según su confidencialidad y caso de uso. Este control incluye las etiquetas de clasificación de datos adecuadas, las directivas de acceso, la información de licencia, las estadísticas descriptivas, el origen inicial y la fecha de recopilación.

Declaración sobre amenazas: los datos usados en los sistemas de inteligencia artificial se usan, almacenan o se accede a ellos de forma inapropiada debido a la falta de atributos, metadatos o documentación necesarios.

Guía:

  1. Desarrolla una directiva de datos que abarque la privacidad y la protección de los tipos de datos confidenciales y comunica la directiva a todo el personal implicado en el uso o creación de sistemas de inteligencia artificial.
  2. Implementa canalizaciones de entrenamiento e implementación que protejan la confidencialidad e integridad de los datos usados en sistemas de inteligencia artificial.

Almacenamiento de datos

Control: los datos deben almacenarse adecuadamente según un proceso de clasificación documentado. Los conjuntos de datos deben indexarse y considerarse como un recurso que está sujeto a directivas de control de acceso y administración de recursos.

Declaración sobre amenazas: los datos se almacenan de forma no segura y partes o sistemas no autorizados pueden manipularlos o modificarlos. Los datos no se clasifican correctamente, lo que lleva a la divulgación de información confidencial o datos personales confidenciales.

Guía

  1. Asegúrate de que las cuentas o los sistemas de investigación de inteligencia artificial o desarrollo no tienen acceso a las bases de datos de producción y viceversa.
  2. Los datos usados en los sistemas de inteligencia artificial deben clasificarse y protegerse según una directiva de clasificación documentada.
  3. Se realiza un seguimiento de los datos usados en los sistemas de inteligencia artificial en una directiva de administración de recursos documentada.
  4. Los datos usados para casos de uso confidenciales de inteligencia artificial se almacenan en sistemas aprobados y administrados.
  5. Se debe auditar el acceso a los datos y los usuarios que solicitan acceso deben pasar por un proceso de control de acceso formal que incluya la aprobación de administración.
  6. Los datos usados en los procesos de aprendizaje automático no deben exponerse a Internet.
  7. Los datos que se extraen de Internet (u otros orígenes que no son de confianza) deben pasar por un proceso de filtrado que incluya la aprobación de administración.
  8. Los conjuntos de datos deben tener versiones con procesos formales de control de cambios implantados.

Acceso a datos

Control: se debe realizar un seguimiento adecuado de los conjuntos de datos y comprobarse mediante hash criptográfico antes de su uso.

Declaración sobre amenazas: los conjuntos de datos se modifican sin autorización.

Guía:

  1. Se debe aplicar el control de acceso basado en roles para conjuntos de datos.
  2. Realiza auditorías de acceso periódicas para asegurarte de que las cuentas con acceso a los conjuntos de datos deben tener acceso a estos. Asegúrate de que cada cuenta funciona dentro unos de límites normales.
  3. Si no se usa una plataforma de seguimiento central, se debe revisar la finalidad del acceso a los datos mediante registros de acceso sin procesar. Asegúrate de que cada cuenta funciona dentro unos de límites normales.
  4. Los proveedores de recursos de terceros, contratistas u otras partes externas no deben tener acceso excesivo o inadecuado a los activos de datos de entrenamiento o prueba de una empresa sin contratos vigentes.

Integridad de datos

Control: los conjuntos de datos deben ser de confianza y seguir siendo de confianza durante el ciclo de vida del sistema de inteligencia artificial.

Declaración sobre amenazas: los conjuntos de datos se modifican durante el ciclo de vida de la inteligencia artificial sin la capacidad de auditar ni realizar un seguimiento de los cambios.

Guía:

  1. Los conjuntos de datos deben identificarse de forma única, de modo que los cambios no autorizados en un conjunto de datos aprobado provocarían una revisión del conjunto de datos.
  2. Se debe realizar un seguimiento de los conjuntos de datos y sus descripciones criptográficas en una ubicación central. Se debe auditar el acceso al conjunto de datos.
  3. Los cambios en el conjunto de datos deben incluir descripciones criptográficas actualizadas y aprobación de administración antes de enviarse al servicio de seguimiento central.

Procesamiento de datos

Controles y directivas relacionados con el procesamiento de datos usados que se usan para el aprendizaje automático y la inteligencia artificial.

Objetivo: garantizar el procesamiento seguro de datos desde su forma sin procesar a un formulario intermediario listo para el entrenamiento.

Canalizaciones de procesamiento

Control: las canalizaciones de procesamiento deben protegerse adecuadamente.

Declaración sobre amenazas: un actor de amenazas puede realizar cambios no autorizados en el sistema modificando las canalizaciones de procesamiento de datos.

Guía:

  1. No todos los datos que se mueven mediante un sistema de producción son relevantes para los esfuerzos de ciencia de datos. Es importante analizar solo los datos necesarios y asegurarse de que se realiza un seguimiento adecuado de todos los datos que se mueven de una configuración de producción segura a una configuración de desarrollo. Ten en cuenta que es posible que determinados tipos de datos no puedan moverse a un entorno de desarrollo. Es posible que la ciencia de datos tenga que producirse en un entorno de intermediario seguro.
  2. Es importante realizar una auditoría adecuada del acceso a los datos a lo largo del ciclo de vida del procesamiento de datos. Sin cuentas independientes, no puede haber una auditoría suficiente de acceso. Además, la capacidad de responder a un incidente no puede ocurrir sin afectar potencialmente a los procesos empresariales. El riesgo de una sola cuenta daría lugar a un riesgo de todos los datos que dejan el entorno de producción seguro.
  3. Los procesos de ciencia de datos podrían requerir recursos que están fuera de un límite de cumplimiento estricto.
  4. Los procesos de ciencia de datos siempre deben cumplir los requisitos existentes. Este proceso podría incluir la migración de recursos y procesos de ciencia de datos a un entorno compatible.
  5. Se debe realizar un seguimiento de los datos a lo largo de todo su ciclo de vida; este seguimiento debe incluir subconjuntos de conjuntos de datos más grandes. Se debe exigir que se pueda realizar un seguimiento de un modelo a los datos en los que se entrenó. Además, debe existir una copia de esos datos en su totalidad.

Apertura del conjunto de datos

Control: garantizar subconjuntos (por ejemplo, segmentos temporales, categóricos) de los datos incluidos para la creación de modelos y cómo podrían inculcar riesgos de seguridad (pérdida de privacidad, envenenamiento o integridad mediante una sobredimensión en los comentarios, etc.).

Declaración sobre amenazas: el actor de amenazas puede recuperar partes de los datos mediante la reconstrucción y recuperación de subconjuntos de datos.

Guía:

  1. Los subconjuntos de datos son conjuntos de datos por sí mismos. Estos subconjuntos deben tener los mismos metadatos adjuntos que el conjunto de datos primario y deben revisarse de forma similar para los tipos de datos confidenciales.
  2. En función de las directivas relacionadas con las prácticas de aprendizaje automático (SLA, métricas de sesgo, etc.), cualquier conjunto de datos determinado (incluidos los subconjuntos) debe cumplir un estándar mínimo documentado alrededor de estas métricas si se van a usar en la creación de modelos. Los metadatos siempre se deben adjuntar al conjunto de datos.
  3. Todos los conjuntos de datos que infringen las directivas existentes deben tener una excepción documentada que aprueba la administración. La excepción debe incluir un motivo documentado, además de los metadatos necesarios.
  4. Se debe realizar un seguimiento de todos los datos usados para la creación de modelos en una ubicación central. Los datos se deben poder auditar en cualquier momento. Además, los modelos descubiertos que se entrenaron con datos sin seguimiento deben extraerse del entorno de producción hasta que coincidan con un conjunto de datos conocido con los metadatos necesarios.
  5. Los conjuntos de datos deben tener una versión adecuada para que todos los metadatos se actualicen y los usuarios de los datos comprendan el contenido y las propiedades estadísticas. En caso necesario, se debe requerir la aprobación de administración para casos de uso confidenciales.

Entrenamiento del modelo

Controles y directivas relacionados con el entrenamiento de modelos y algoritmos.

Diseño de modelos

Control: un responsable revisa el código de entrenamiento del modelo.

Declaración sobre amenazas: un código incorrecto o vulnerabilidades en el código del modelo generan riesgos de disponibilidad, integridad o confidencialidad.

Guía:

  1. El diseño del modelo y la investigación deben producirse en el entorno adecuado. El diseño y la arquitectura del modelo pueden tener un gran efecto en la eficacia de un modelo. Los entornos de producción no son el lugar adecuado para la investigación o a fin de probar notificaciones no viables sobre la eficacia de un diseño.
  2. La selección de modelos para un sistema de producción la debe revisar y aprobar la administración. Este proceso debe producirse al principio de la fase de desarrollo y se debe realizar un seguimiento mediante cualquier mecanismo disponible (Excel, DevOps, Git, etc.). Las excepciones deben documentarse.
  3. Los modelos suelen ser específicos del dominio y debe haber documentación adecuada que acompañe al modelo a lo largo de su uso en una organización.
  4. Asegúrate de que los metadatos del modelo son accesibles para los usuarios y los usos no aprobados de los modelos se documentan y aplican. Un usuario puede ajustar un modelo existente siempre que los nuevos metadatos se adjunten y se realice un seguimiento adecuado de ellos.

Entrenamiento del modelo

Control: el criterio de selección del modelo (conjuntos de métricas y de exclusión) imita el desfase natural y las condiciones adversas que podrían esperarse en el momento de la implementación.

Declaración sobre amenazas: es probable que un modelo entrenado en condiciones ideales sea frágil cuando se implementa en la configuración de adversario.

Guía

  1. Los conjuntos de entrenamiento y validación deben respetar las dependencias temporales naturales. Por ejemplo, para clasificadores de malware, un conjunto de validación debe incluir solo versiones de software posteriores a las contenidas en el conjunto de entrenamiento.
  2. Agrega explícitamente la solidez del modelo aumentando los conjuntos de datos con daños comunes que podrían detectarse razonablemente en su ámbito.
  3. Entrena explícitamente frente a las condiciones del caso más perjudicial mediante el reentrenamiento de adversario.
  4. Realiza un seguimiento de experimentos y metadatos asociados.

Selección de modelos

La selección de modelos consiste en elegir un modelo de un conjunto de candidatos, donde cada candidato tiene un conjunto único de parámetros de modelo, algoritmo de entrenamiento e hiperparámetros de entrenamiento. El criterio de selección para el modelo ganador suele basarse en una sola métrica cuantificable (por ejemplo, pérdida mínima, tasa de detección máxima) medida en un conjunto de datos de exclusión común o como promedio en un conjunto de validación de k iteraciones.

Control: el diseño del modelo y el algoritmo de entrenamiento incluyen regularización de modelos explícita o implícita.

Declaración sobre amenazas: los modelos se sobreajustan a un conjunto de datos de entrenamiento o validación única y son más vulnerables a los modos de error.

Guía:

  1. Cuando sea factible a nivel de cálculo, se debe usar la validación cruzada de k iteraciones para evitar el sobreajuste a un único conjunto de datos de exclusión.
  2. Comprueba que los modelos seleccionados funcionan bien en conjuntos de datos de exclusión dispares para validar que no se han sobreajustado.
  3. Asegúrate de que existen procesos.

Control de versiones de los modelos

Control: los modelos se vuelven a entrenar continuamente a medida que los nuevos datos de entrenamiento fluyen a las canalizaciones de entrenamiento.

Declaración sobre amenazas: se produce un incidente, pero el modelo implicado no se puede encontrar para su investigación.

Guía:

  1. Modelos de versión de forma que, cada vez que se entrena un modelo, se le asigna una nueva versión. Los calificadores como my_model_dev_1.1 o my_model_prod_1.1 deben usarse para delimitar la producción de los modelos de preproducción. Este control de versiones ayuda a aislar los problemas de un problema de producción o de preproducción. Haz referencia a los procesos o directivas de SDL seguros existentes.

Implementación de modelo

Controles y directivas relacionados con la implementación de modelos, algoritmos y la infraestructura auxiliar.

Pruebas de seguridad

Control: los modelos puestos en producción están adecuadamente protegidos.

Declaración sobre amenazas: los sistemas de inteligencia artificial no están adecuadamente probados para detectar vulnerabilidades antes de la implementación.

Guía:

  1. Los criterios de prueba de aceptación formal no se han definido ni documentado para los nuevos sistemas de inteligencia artificial, actualizaciones y nuevas versiones.
  2. Los nuevos sistemas de inteligencia artificial, las actualizaciones o las nuevas versiones deben implementarse con pruebas formales.
  3. Las herramientas automatizadas deben usarse para probar sistemas de información, actualizaciones o nuevas versiones.
  4. El entorno de prueba debe parecerse mucho al entorno de producción final.
  5. Se deben documentar la frecuencia, el ámbito y los métodos para las revisiones de seguridad independientes.

Seguridad y revisión del cumplimiento

Control: la administración sólida de la red subyacente es clave para proteger el sistema de ML y la infraestructura.

Declaración sobre amenazas: riesgo del sistema de ML accediendo a la red no segura.

Guía:

  1. Los dispositivos de puerta de enlace a sistemas de ML deben configurarse para filtrar el tráfico entre dominios y bloquear el acceso no autorizado.
  2. Los requisitos legales, normativos y contractuales pertinentes deben definirse y documentarse explícitamente, y abordarse, junto con controles específicos y responsabilidades individuales.
  3. Las directrices de configuración segura también se deben documentar, implementar o revisar.
  4. El criterio para la segregación de redes de ML en dominios debe ser coherente con la directiva de control de acceso o los requisitos de acceso de la organización.
  5. Los mecanismos como la puerta de enlace segura, la VPN, el enrutamiento para los sistemas de ML deben implementarse lo suficiente como para habilitar un conjunto de controles graduados.
  6. Los usuarios e ingenieros de ML deben emplear o seguir los requisitos para la implementación de controles a fin de separar y restringir correctamente el uso de sistemas accesibles públicamente, redes internas y recursos críticos.

Supervisión del sistema

Controles y directivas relacionados con la supervisión continua de los sistemas de aprendizaje automático y la infraestructura auxiliar.

Registros y revisión

Control: el registro y la supervisión son fundamentales para los sistemas de ML por motivos de seguridad.

Declaración sobre amenazas: durante una investigación, no se encuentran registros de sistemas de ML.

Guía:

  1. El registro y la supervisión deben producirse de forma coherente en todos los sistemas de inteligencia artificial y sus componentes, incluido el almacenamiento, las canalizaciones, los servidores de producción, etc.
  2. Los registros de eventos y seguridad deben revisarse periódicamente en busca de comportamientos anómalos.
  3. Los informes consolidados y las alertas sobre la actividad del sistema los deben generar y revisar la administración o un representante de seguridad.

Administración de incidentes

Roles y responsabilidades

Control: los registros de seguridad deben recopilarse en una ubicación central.

Declaración sobre amenazas: durante una investigación, los analistas de seguridad no tienen un cuaderno de estrategias formalizado.

Guía:

  1. Las organizaciones deben seguir un proceso formal para notificar incidentes de sistemas de inteligencia artificial en el contexto de la pérdida de servicio, pérdida de equipos, pérdida de instalaciones, mal funcionamiento del sistema, sobrecargas del sistema, errores humanos, incumplimientos de directivas o directrices, infracciones de seguridad física, cambios de sistema no controlados, mal funcionamiento del software, mal funcionamiento del hardware e infracciones de acceso.
  2. Deben desarrollarse procedimientos formales de respuesta a incidentes y escalación para documentar las acciones realizadas al recibir un informe de un evento de seguridad de la información.
  3. Los procedimientos de respuesta a incidentes deben probarse periódicamente y se debe realizar un seguimiento de las métricas de respuesta.

Planeamiento de la continuidad empresarial

Planificación, revisión y resultados

Control: asegúrate de que los sistemas de ML se pueden corregir y recuperar después de un incidente.

Declaración sobre amenazas: los incidentes provocan problemas de confidencialidad, integridad o disponibilidad persistentes en sistemas críticos de ML.

Guía:

  1. Los recursos críticos de inteligencia artificial deben identificarse e inventariarse.
  2. La organización debe desarrollar un plan de continuidad empresarial (BCP) o un proceso de recuperación ante desastres (DR) frente a ataques en sistemas de inteligencia artificial.
  3. La organización debe identificar por orden de prioridad los riesgos asociados al impacto de perder los sistemas críticos de inteligencia artificial por ataques.
  4. Las organizaciones deben tener una prueba de continuidad empresarial que funcione según una programación repetida para los sistemas críticos de inteligencia artificial.

Referencias

Si tienes preguntas o comentarios, ponte en contacto con atml@microsoft.com.

Descarga un PDF de este documento desde nuestro repositorio de GitHub.