Modelado de amenazas para sistemas y dependencias de IA/ML

Por Andrew Marshall, Jugal Parikh, Emre Kiciman y Ram Shankar Siva Kumar

Gracias especiales aRaúl Rojas y al flujo de trabajo de ingeniería de seguridad de AETHER

Noviembre de 2019

Este documento es una entrega de las prácticas de ingeniería de AETHER para el grupo de trabajo de IA y complementa las prácticas existentes de modelado de amenazas de SDL proporcionando nuevas instrucciones sobre la enumeración de amenazas y la mitigación específicas del espacio de inteligencia artificial y aprendizaje automático. Está pensado para usarse como referencia durante las revisiones de diseño de seguridad de lo siguiente:

1. Productos o servicios que interactúan con o toman dependencias en servicios basados en IA/ML

2. Productos y servicios que se crean con IA/ML en su núcleo

La mitigación de amenazas de seguridad tradicional es más importante que nunca. Los requisitos establecidos por el ciclo de vida de desarrollo de seguridad son esenciales para establecer una base de seguridad del producto en la que se basa esta guía. Si no se abordan las amenazas de seguridad tradicionales, se facilita la habilitación de los ataques específicos de IA/ML que se tratan en este documento, tanto en el software como en los entornos físicos, así como haciendo que la vulneración sea trivial en los niveles inferiores de la pila de software. Para obtener una introducción a las nuevas amenazas de seguridad en este espacio, consulte Protección del futuro de la inteligencia artificial y el aprendizaje automático en Microsoft.

Los conjuntos de aptitudes de los ingenieros de seguridad y los científicos de datos normalmente no se superponen. Esta guía proporciona una manera de que ambas materias tengan conversaciones estructuradas en estas nuevas amenazas o mitigaciones de red sin necesidad de que los ingenieros de seguridad se conviertan en científicos de datos o viceversa.

Este documento se divide en dos secciones:

1. "Nuevas consideraciones clave en el modelado de amenazas" se centra en nuevas formas de pensar y nuevas preguntas que se deben formular al modelar amenazas sistemas de inteligencia artificial y aprendizaje automático. Tanto los científicos de datos como los ingenieros de seguridad deben revisar esto, ya que será su cuaderno de estrategias para los debates de modelado de amenazas y la priorización de mitigación.
2. "Amenazas específicas de IA/ML y sus mitigaciones" proporciona detalles sobre ataques específicos, así como los pasos de mitigación específicos que se usan hoy en día para proteger los productos y servicios de Microsoft frente a estas amenazas. Esta sección se dirige principalmente a los científicos de datos que pueden necesitar implementar mitigaciones de amenazas específicas como salida del proceso de revisión de seguridad y modelado de amenazas.

Esta guía se organiza en torno a una taxonomía de amenazas de aprendizaje automático adversario creada por Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen y Jeffrey Snover titulado "Modos de error en el aprendizaje automático". Para obtener instrucciones sobre la administración de incidentes sobre la evaluación de amenazas de seguridad detalladas en este documento, consulte la barra de errores de SDL para amenazas de inteligencia artificial y aprendizaje automático. Todos estos son documentos vivos que evolucionarán con el tiempo con el panorama de amenazas.

Nuevas consideraciones clave en el modelado de amenazas: cambio de la forma en que se ven los límites de confianza

Suponga el compromiso o envenenamiento de los datos con los que entrenas, así como del proveedor de datos. Aprenda a detectar entradas de datos anómalas y malintencionadas, así como a poder distinguir entre ellas y recuperarlas.

Resumen

Los almacenes de datos de entrenamiento y los sistemas que los hospedan forman parte del ámbito de modelado de amenazas. La mayor amenaza de seguridad en el aprendizaje automático actual es la intoxicación de datos debido a la falta de detecciones y mitigaciones estándar en este espacio, combinada con la dependencia de conjuntos de datos públicos que no son de confianza o no protegibles como orígenes de datos de entrenamiento. El seguimiento de la procedencia y el linaje de los datos es esencial para garantizar su confiabilidad y evitar un ciclo de entrenamiento de "basura entra, basura sale".

Preguntas para hacer una revisión de seguridad

• Si los datos se envenenan o manipulan, ¿cómo lo sabría?

  -¿Qué telemetría dispone para detectar un sesgo en los datos de calidad de su entrenamiento?

• ¿Está entrenando desde entradas proporcionadas por el usuario?

  -¿Qué tipo de validación o saneamiento de entrada está haciendo en ese contenido?

  -¿La estructura de estos datos se documenta de forma similar a las hojas de datos de los conjuntos de datos?

• Si entrena con almacenes de datos en línea, ¿qué pasos debe seguir para garantizar la seguridad de la conexión entre el modelo y los datos?

  -¿Tienen una manera de notificar riesgos a los consumidores de sus fuentes?

  -¿Son capaces de eso?

• ¿Qué tan sensible es la información de la que se entrenan los datos?

  -¿Cataloga o controla la incorporación, actualización o eliminación de las entradas de datos?

• ¿El modelo puede generar datos confidenciales?

  -¿Se obtuvieron estos datos con permiso del origen?

• ¿El modelo solo genera los resultados necesarios para lograr su objetivo?

• ¿Devuelve el modelo puntuaciones de confianza sin procesar u otro resultado directo que se pueda registrar y duplicar?

• ¿Cuál es el impacto de los datos de entrenamiento que se recuperan al atacar o invertir el modelo?

• Si los niveles de confianza de la salida del modelo caen repentinamente, ¿puede determinar cómo y por qué, así como los datos que lo provocaron?

• ¿Ha definido una entrada bien formada para el modelo? ¿Qué hace para asegurarse de que las entradas cumplen este formato y qué hace si no lo hacen?

• Si las salidas son incorrectas pero no provocan errores que se notificarán, ¿cómo lo sabría?

• ¿Sabe usted si sus algoritmos de entrenamiento son resistentes a las entradas adversarias a nivel matemático?

• ¿Cómo puedes recuperarte de la contaminación adversa de tus datos de entrenamiento?

  -¿Puede aislar o poner en cuarentena contenido adversario y volver a entrenar modelos afectados?

  -¿Puede revertir o recuperar un modelo de una versión anterior para realizar un nuevo entrenamiento?

• ¿Usa el aprendizaje de refuerzo en contenido público no protegido?

• Comience a pensar en el linaje de sus datos: si encontrara un problema, ¿podría realizar un seguimiento hasta su introducción en el conjunto de datos? Si no es así, ¿es un problema?

• Saber de dónde proceden los datos de entrenamiento e identificar los patrones estadísticos para empezar a entender cómo se ven las anomalías.

  -¿Qué elementos de los datos de entrenamiento son vulnerables a la influencia externa?

  -¿Quién puede contribuir a los conjuntos de datos que se están utilizando para el entrenamiento?

  -¿Cómo atacarías tus fuentes de datos de entrenamiento para dañar a un competidor?

Amenazas y mitigaciones relacionadas en este documento

• Perturbación adversarial (todas las variantes)

• Intoxicación de datos (todas las variantes)

Ataques de ejemplo

• Forzar que los correos electrónicos benignos se clasifiquen como spam o que un ejemplo malintencionado no se detecte

• Entradas diseñadas por el atacante que reducen el nivel de confianza de la clasificación correcta, especialmente en escenarios de altas consecuencias.

• El atacante inserta ruido aleatoriamente en los datos de origen que se están clasificando para reducir la probabilidad de que se use la clasificación correcta en el futuro, lo que reduce eficazmente el modelo.

• Contaminación de los datos de entrenamiento para forzar la clasificación incorrecta de los puntos de datos seleccionados, lo que da lugar a acciones específicas realizadas o omitidas por un sistema

Identificar acciones que los modelos o productos o servicios podrían tomar, lo que puede provocar daños en el cliente en línea o en el dominio físico

Resumen

Los ataques a los sistemas de inteligencia artificial y aprendizaje automático pueden encontrar su camino hacia el mundo físico. Cualquier escenario que se pueda retorcer para dañar a los usuarios psicológica o físicamente es un riesgo catastrófico para su producto o servicio. Esto se extiende a cualquier dato confidencial sobre tus clientes usados para el entrenamiento y las opciones de diseño que pueden comprometer esos puntos de datos privados.

Preguntas para hacer una revisión de seguridad

• ¿Entrena con ejemplos antagónicos? ¿Qué impacto tienen en la salida del modelo en el dominio físico?

• ¿Cómo se manifiesta el trolling en su producto o servicio? ¿Cómo puede detectarlo y responder a él?

• ¿Qué haría falta para que tu modelo devuelva un resultado que engañe al servicio y haga que éste deniegue el acceso a los usuarios legítimos?

• ¿Cuál es el impacto de que su modelo sea copiado o robado?

• ¿Se puede usar el modelo para deducir la pertenencia de una persona individual en un grupo determinado o simplemente en los datos de entrenamiento?

• ¿Puede un atacante causar daños a la reputación o una reacción negativa de relaciones públicas a tu producto obligándolo a llevar a cabo acciones específicas?

• ¿Cómo se controlan los datos con formato correcto pero sesgados excesivamente, como los de los trolls?

• Para cada forma de interactuar con tu modelo o de realizar consultas, ¿se puede analizar ese método para revelar datos de entrenamiento o funcionalidad del modelo?

Amenazas y mitigaciones relacionadas en este documento

• Inferencia de pertenencia

• Inversión de modelos

• Robo de modelos

Ataques de ejemplo

• Reconstrucción y extracción de datos de entrenamiento consultando repetidamente el modelo para obtener resultados de máxima confianza

• Duplicación del propio modelo mediante la coincidencia exhaustiva de consultas y respuestas

• Consultar el modelo de una manera que revela un elemento específico de datos privados se incluyó en el conjunto de entrenamiento.

• Coche autónomo engañado para pasar por alto las señales de parada o los semáforos

• Bots conversacionales manipulados para acosar a usuarios benignos

Identificar todos los orígenes de dependencias de IA/ML, así como las capas de presentación de front-end en la cadena de suministro de datos y modelos

Resumen

Muchos ataques en IA y Machine Learning comienzan con el acceso legítimo a las API que se exponen para proporcionar acceso de consulta a un modelo. Debido a las fuentes ricas de datos y ricas experiencias de usuario implicadas aquí, el acceso de terceros autenticado pero "inapropiado" (aquí hay un área gris) a los modelos es un riesgo debido a la capacidad de actuar como una capa de presentación sobre un servicio proporcionado por Microsoft.

Preguntas para hacer una revisión de seguridad

• ¿Qué clientes o asociados se autentican para acceder a las API de modelo o servicio?

  -¿Pueden actuar como una capa de presentación sobre su servicio?

  -¿Puede revocar su acceso rápidamente en caso de compromiso?

  -¿Cuál es la estrategia de recuperación en caso de uso malintencionado de su servicio o dependencias?

• ¿Puede una tercera parte crear una fachada sobre tu modelo para reutilizarlo y dañar a Microsoft o a sus clientes?

• ¿Los clientes te proporcionan datos de entrenamiento directamente?

  -¿Cómo se protegen esos datos?

  -¿Qué ocurre si es malintencionado y su servicio es el objetivo?

• ¿Qué aspecto tiene un falso positivo aquí? ¿Cuál es el impacto de un falso negativo?

• ¿Puede realizar un seguimiento y medir la desviación de las tasas verdaderos positivos frente a falsos positivos en varios modelos?

• ¿Qué tipo de telemetría necesita para demostrar la confiabilidad de la salida del modelo a los clientes?

• Identifique todas las dependencias de terceros en la cadena de suministro de datos de su aprendizaje automático, no solo de software de código abierto, sino también de proveedores de datos.

  -¿Por qué las usas y cómo compruebas su confiabilidad?

• ¿Está utilizando modelos preconstruidos de terceros^rd o enviando datos de entrenamiento a proveedores de servicios MLaaS de terceros^rd?

• Inventario de noticias sobre ataques a productos o servicios similares. Comprender que muchas amenazas de INTELIGENCIA artificial y aprendizaje automático se transfieren entre tipos de modelo, ¿qué impacto tendría estos ataques en sus propios productos?

Amenazas y mitigaciones relacionadas en este documento

• Reprogramación de red neuronal

• Ejemplos adversarios en el dominio físico

• Proveedores de aprendizaje automático malintencionados que recuperan datos de entrenamiento

• Ataque a la cadena de suministro de ML

• Modelo comprometido con puerta trasera

• Dependencias específicas de ML comprometidas

Ataques de ejemplo

• El proveedor malintencionado de MLaaS infiltra un troyano en tu modelo con un método de evasión específico.

• El cliente adversario encuentra una vulnerabilidad en la dependencia común de software de código abierto que utiliza, carga un conjunto de datos de entrenamiento diseñado para comprometer su servicio.

• Un asociado no escrupuloso usa las API de reconocimiento facial y crea una capa de presentación sobre el servicio para generar Deep Fakes.

Amenazas específicas de IA/ML y sus mitigaciones

#1: Perturbación adversarial

Descripción

En los ataques de estilo de perturbación, el atacante modifica sigilosamente la consulta para obtener una respuesta deseada de un modelo implementado en producción[1]. Se trata de una infracción de la integridad de entrada del modelo que conduce a ataques de tipo fuzzing donde el resultado final no es necesariamente una infracción de acceso o EOP, sino que compromete el rendimiento de clasificación del modelo. Esto también se puede manifestar cuando los trolls usan ciertas palabras clave de tal manera que la inteligencia artificial los bloqueará, denegando efectivamente el servicio a usuarios legítimos cuyo nombre coincida con una palabra "prohibida".

[24]

Variante #1a: clasificación errónea intencionada

En este caso, los atacantes generan un ejemplo que no está en la clase de entrada del clasificador de destino, pero que el modelo clasifica como esa clase de entrada concreta. El ejemplo adversario puede aparecer como ruido aleatorio para los ojos humanos, pero los atacantes tienen cierto conocimiento del sistema de aprendizaje automático de destino para generar un ruido blanco que no es aleatorio, pero aprovecha algunos aspectos específicos del modelo de destino. El adversario proporciona una muestra de entrada que no es una muestra legítima, pero el sistema de destino lo clasifica como una clase legítima.

Ejemplos

[6]

Mitigaciones

• Reforzar la solidez adversaria mediante la confianza del modelo inducida por el entrenamiento adversario [19]: Los autores proponen un Vecino Próximo Altamente Confiado (HCNN), un marco que combina información de confianza y búsqueda de vecino más próximo, para reforzar la solidez adversaria de un modelo base. Esto puede ayudar a distinguir entre predicciones de modelo correctas y incorrectas en un vecindario de un punto muestreado de la distribución de entrenamiento subyacente.

• Análisis causal controlado por atribución [20]: Los autores estudian la conexión entre la resistencia a las perturbaciones adversas y la explicación basada en atribución de decisiones individuales generadas por modelos de aprendizaje automático. Informan de que las entradas adversarias no son sólidas en el espacio de atribución, es decir, enmascarar algunas características con una atribución alta conduce a la indecisión del modelo de aprendizaje automático en los ejemplos adversarios. Por el contrario, las entradas naturales son sólidas en el espacio de atribución.

  [20]

Estos enfoques pueden hacer que los modelos de aprendizaje automático sean más resistentes a los ataques adversarios, ya que engañar a este sistema de cognición de dos capas no solo requiere atacar el modelo original, sino también asegurarse de que la atribución generada para el ejemplo adversario es similar a los ejemplos originales. Ambos sistemas deben estar en peligro simultáneamente para un ataque adversario exitoso.

Paralelos tradicionales

Elevación remota de privilegios, ya que el atacante ahora está en control del modelo

Severidad

Crítico

Variante #1b: clasificación incorrecta de origen/destino

Esto se caracteriza como un intento por parte de un atacante de obtener un modelo para devolver su etiqueta deseada para una entrada determinada. Esto normalmente obliga a un modelo a devolver un falso positivo o falso negativo. El resultado final es un control sutil de la precisión de clasificación del modelo, por lo que un atacante puede provocar omisiones específicas a voluntad.

Aunque este ataque tiene un impacto perjudicial significativo en la precisión de la clasificación, también puede ser más intensivo llevar a cabo dado que un adversario no solo debe manipular los datos de origen para que ya no esté etiquetado correctamente, sino que también se etiquete específicamente con la etiqueta fraudulenta deseada. Estos ataques suelen implicar varios pasos o intentos de forzar la clasificación incorrecta [3]. Si el modelo es susceptible a ataques mediante aprendizaje por transferencia que fuerzan la clasificación errónea dirigida, puede que no haya una huella de tráfico del atacante reconocible, ya que los ataques de sondeo se pueden llevar a cabo sin conexión.

Ejemplos

Forzar que los correos electrónicos benignos se clasifiquen como correo no deseado o que un ejemplo malintencionado no se detecte. Estos también se conocen como ataques de evasión o imitación del modelo.

Mitigaciones

Acciones reactivas o defensivas de detección

• Implemente un umbral de tiempo mínimo entre las llamadas a la API que proporciona resultados de clasificación. Esto ralentiza las pruebas de ataque en varios pasos al aumentar el tiempo total requerido para encontrar una perturbación exitosa.

Acciones proactivas y protectoras

• Eliminación de ruido en las características para mejorar la robustez ante ataques adversarios [22]: Los autores desarrollan una nueva arquitectura de red que aumenta la robustez ante ataques adversarios al realizar la eliminación de ruido en las características. En concreto, las redes contienen bloques que reducen el ruido de las características mediante medios no locales u otros filtros; todas las redes se entrenan de manera integral. Cuando se combina con el entrenamiento adversario, las redes de eliminación de ruido de características mejoran sustancialmente el estado del arte en robustez ante ataques adversarios en los escenarios de ataque de caja blanca y caja negra.

• Entrenamiento adversarial y regularización: entrene con ejemplos adversarios conocidos para crear resistencia y robustez frente a entradas malintencionadas. Esto también se puede ver como una forma de regularización, que penaliza la norma de degradados de entrada y hace que la función de predicción del clasificador sea más suave (aumentando el margen de entrada). Esto incluye clasificaciones correctas con tasas de confianza más bajas.

Invertir en el desarrollo de la clasificación monotónica con selección de características monotónicas. Esto garantiza que el adversario no pueda eludir el clasificador simplemente añadiendo características de la clase negativa [13].

• La compresión de características [18] puede usarse para fortalecer los modelos DNN mediante la detección de ejemplos adversariales. Reduce el espacio de búsqueda disponible para un adversario mediante la fusión de muestras que corresponden a muchos vectores de características diferentes en el espacio original en una sola muestra. Al comparar la predicción de un modelo DNN en la entrada original con la entrada comprimida, la compresión de características puede ayudar a detectar ejemplos adversarios. Si los ejemplos originales y comprimidos producen salidas considerablemente diferentes del modelo, es probable que la entrada sea engañosa. Al medir el desacuerdo entre las predicciones y seleccionar un valor de umbral, el sistema puede generar la predicción correcta para ejemplos legítimos y rechazar entradas adversarios.

  

  [18]

• Defensas certificadas contra ejemplos adversarios [22]: Los autores proponen un método basado en una relajación semi-definitiva que genera un certificado que para una red determinada y una entrada de prueba, ningún ataque puede forzar que el error supere un valor determinado. En segundo lugar, dado que este certificado es diferente, los autores lo optimizan conjuntamente con los parámetros de red, lo que proporciona un regularizador adaptable que fomenta la solidez frente a todos los ataques.

Acciones de respuesta

• Emita alertas sobre los resultados de clasificación con una alta varianza entre clasificadores, especialmente si procede de un solo usuario o un pequeño grupo de usuarios.

Paralelos tradicionales

Elevación de privilegios de forma remota

Severidad

Crítico

Variante #1c: clasificación incorrecta aleatoria

Se trata de una variación especial en la que la clasificación del objetivo del atacante puede ser cualquier otra distinta a la clasificación de origen legítima. Por lo general, el ataque implica la inyección de ruido aleatoriamente en los datos de origen que se clasifican para reducir la probabilidad de que se use la clasificación correcta en el futuro [3].

Ejemplos

Mitigaciones

Igual que variant 1a.

Paralelos tradicionales

Denegación de servicio no persistente

Severidad

Importante

Variante #1d: Reducción de confianza

Un atacante puede manipular entradas para reducir el nivel de confianza en la clasificación correcta, especialmente en escenarios de alto riesgo. Esto también puede adoptar la forma de un gran número de falsos positivos destinados a sobrecargar a los administradores o sistemas de supervisión con alertas fraudulentas que no se pueden distinguir de alertas legítimas [3].

Ejemplos

Mitigaciones

• Además de las acciones cubiertas en la Variante #1a, se puede emplear la limitación de frecuencia de eventos para reducir el volumen de alertas de una única fuente.

Paralelos tradicionales

Denegación de servicio no persistente

Severidad

Importante

#2a intoxicación de datos dirigidos

Descripción

El objetivo del atacante es contaminar el modelo de máquina generado en la fase de entrenamiento, de modo que las predicciones sobre los nuevos datos se modificarán en la fase de prueba[1]. En los ataques de intoxicación dirigidos, el atacante quiere clasificar erróneamente ejemplos específicos para hacer que se realicen o se omitan acciones específicas.

Ejemplos

Enviar software antivirus como malware para forzar su clasificación como malintencionado y eliminar el uso de software antivirus específico en los sistemas de los clientes.

Mitigaciones

• Definir sensores de anomalías para examinar la distribución de datos diariamente y alertar sobre las variaciones

  -Medición de la variación de datos de entrenamiento a diario, telemetría para desviación/desplazamiento.

• Validación de entrada, incluyendo saneamiento y comprobación de integridad

• La intoxicación inyecta muestras de entrenamiento fuera. Dos estrategias principales para contrarrestar esta amenaza:

  - Saneamiento y validación de datos: eliminar las muestras de intoxicación de los datos de entrenamiento -Bagging para combatir los ataques de intoxicación [14]

  -Rechazar-en-Negative-Impact (RONI) defensa [15]

  -Aprendizaje sólido: elija algoritmos de aprendizaje sólidos en presencia de muestras de intoxicación.

  -Un enfoque de este tipo se describe en [21] donde los autores abordan el problema de intoxicación de datos en dos pasos: 1) introduciendo un nuevo método de factorización de matriz sólida para recuperar el subespacio verdadero y 2) regresión sólida de componentes principales para eliminar instancias adversarios basadas en la base recuperada en el paso (1). Caracterizan las condiciones necesarias y suficientes para recuperar correctamente el verdadero subespacio y presentan un límite en la pérdida esperada de predicción en comparación con la verdad fundamental.

Paralelos tradicionales

Host troyano por el que el atacante persiste en la red. Los datos de entrenamiento o de configuración están comprometidos y se están utilizando o confiando para la creación de modelos.

Severidad

Crítico

#2b intoxicación indiscriminada de datos

Descripción

El objetivo es arruinar la calidad o integridad del conjunto de datos que se está atacando. Muchos conjuntos de datos son públicos, no de confianza o no protegibles, por lo que esto crea preocupaciones adicionales sobre la capacidad de detectar dichas infracciones de integridad de datos en primer lugar. El entrenamiento con datos comprometidos sin saberlo es una situación de basura entra, basura sale. Una vez detectado, el triage debe determinar la extensión de los datos que se han infringido y proceder a la cuarentena y el reentrenamiento.

Ejemplos

Una empresa raspa datos de un sitio web conocido y de confianza para obtener datos de futuros del petróleo y entrenar sus modelos. Posteriormente, el sitio web del proveedor de datos se ve comprometido a través del ataque de inyección de CÓDIGO SQL. El atacante puede envenenar el conjunto de datos a voluntad y el modelo que se está entrenando no tiene ninguna noción de que los datos están manchados.

Mitigaciones

Igual que la variante 2a.

Paralelos tradicionales

Denegación de servicio autenticada contra un activo de alto valor

Severidad

Importante

#3 Ataques de inversión de modelos

Descripción

Las características privadas usadas en los modelos de aprendizaje automático se pueden recuperar [1]. Esto incluye la reconstrucción de datos de entrenamiento privados a los que el atacante no tiene acceso. También conocido como ataques de ascenso en colina en la comunidad biométrica [16, 17]. Esto se logra mediante la búsqueda de la entrada de datos que maximiza el nivel de confianza devuelto, mientras que la clasificación coincida con el objetivo [4].

Ejemplos

[4]

Mitigaciones

• Las interfaces para los modelos entrenados a partir de datos confidenciales necesitan un control de acceso seguro.

• Consultas de límite de velocidad permitidas por el modelo

• Implemente puertas entre usuarios o llamadores y el modelo real realizando la validación de entrada en todas las consultas propuestas, rechazando nada que no cumpla la definición del modelo de corrección de entrada y devolviendo solo la cantidad mínima de información necesaria para ser útil.

Paralelos tradicionales

Divulgación de información dirigida y encubierta

Severidad

Este valor predeterminado es importante según la barra de errores estándar de SDL, pero la extracción de datos confidenciales o de identificación personal elevaría esto a crítico.

Ataque de inferencia de pertenencia n.º 4

Descripción

El atacante puede determinar si un registro de datos determinado formaba parte del conjunto de datos de entrenamiento del modelo o no[1]. Los investigadores pudieron predecir el procedimiento principal de un paciente (por ejemplo: Cirugía a la que pasó el paciente) en función de los atributos (por ejemplo: edad, sexo, hospital) [1].

[12]

Mitigaciones

Los documentos de investigación que demuestran la viabilidad de este ataque indican que la privacidad diferencial [4, 9] sería una mitigación eficaz. Este sigue siendo un campo naciente en Microsoft y AETHER Security Engineering recomienda crear conocimientos con inversiones en investigación en este espacio. Esta investigación tendría que enumerar las funcionalidades de privacidad diferencial y evaluar su eficacia práctica como mitigaciones y, a continuación, diseñar formas de heredar estas defensas de forma transparente en nuestras plataformas de servicios en línea, de forma similar a cómo compilar código en Visual Studio proporciona on-byprotecciones de seguridad predeterminadas que son transparentes para el desarrollador y los usuarios.

El uso de la eliminación de neuronas y el apilamiento de modelos puede ser mitigaciones eficaces hasta cierto punto. El uso de la eliminación de neuronas no solo aumenta la resistencia de una red neuronal a este ataque, sino que también aumenta el rendimiento del modelo [4].

Paralelos tradicionales

Privacidad de los datos. Las inferencias se realizan sobre la inclusión de un punto de datos en el conjunto de entrenamiento, pero los datos de entrenamiento en sí no se divulgan

Severidad

Se trata de un problema de privacidad, no de seguridad. Se aborda en la guía de modelado de amenazas porque los dominios se superponen, pero cualquier respuesta aquí se controlaría mediante privacidad, no seguridad.

#5 Robo de modelos

Descripción

Los atacantes reconstruyen el modelo subyacente realizando consultas legítimas al modelo. La funcionalidad del nuevo modelo es la misma que la del modelo subyacente[1]. Una vez que se vuelve a crear el modelo, se puede invertir para recuperar información de características o realizar inferencias en los datos de entrenamiento.

• Resolución de ecuaciones: para un modelo que devuelve probabilidades de clase a través de la salida de la API, un atacante puede crear consultas para determinar variables desconocidas en un modelo.

• Búsqueda de rutas de acceso: un ataque que aprovecha las peculiaridades de la API para extraer las "decisiones" tomadas por un árbol al clasificar una entrada [7].

• Ataque de transferencia: un adversario puede entrenar un modelo local (posiblemente mediante la emisión de consultas de predicción al modelo de destino) y usarlo para crear ejemplos adversarios que se transfieren al modelo de destino [8]. Si se extrae su modelo y se detecta como vulnerable a un tipo de entrada adversarial, nuevos ataques contra su modelo implementado en producción pueden desarrollarse de manera completamente offline por el atacante que extrajo una copia de su modelo.

Ejemplos

En la configuración en la que un modelo de ML sirve para detectar el comportamiento adversario, como la identificación del correo no deseado, la clasificación de malware y la detección de anomalías de red, la extracción de modelos puede facilitar los ataques de evasión [7].

Mitigaciones

Acciones proactivas y protectoras

• Minimice o ofusque los detalles devueltos en las API de predicción mientras mantiene su utilidad en aplicaciones "honestas" [7].

• Defina una consulta bien formada para las entradas del modelo y solo devuelva resultados en respuesta a entradas completadas y con formato correcto que coincidan con ese formato.

• Devuelve valores de confianza redondeados. La mayoría de los llamantes legítimos no necesitan varias posiciones decimales de precisión.

Paralelos tradicionales

¿Alteraciones no autenticadas, de solo lectura de los datos del sistema, divulgación dirigida de información de alto valor?

Severidad

Importante en los modelos sensibles a la seguridad, moderado en otros casos.

N.º 6 Reprogramación de red neuronal

Descripción

Mediante una consulta especialmente diseñada a partir de un adversario, los sistemas de aprendizaje automático se pueden reprogramar a una tarea que se desvía de la intención original del creador [1].

Ejemplos

Controles de acceso débiles en una API de reconocimiento facial que permiten a terceros incorporarse en aplicaciones diseñadas para perjudicar a los clientes de Microsoft, como un generador de deepfake.

Mitigaciones

• <Autenticación mutua y segura cliente-servidor> y control de acceso a interfaces del modelo

• Eliminación de las cuentas infractoras.

• Identifique y aplique un contrato de nivel de servicio para las API. Determine el tiempo de corrección aceptable para un problema una vez notificado y asegúrese de que el problema ya no vuelva a reproducirse una vez que expire el Acuerdo de Nivel de Servicio.

Paralelos tradicionales

Se trata de un escenario de abuso. Es menos probable que abra un incidente de seguridad por esto que simplemente deshabilitar la cuenta del infractor.

Severidad

De importante a crítico

#7 Ejemplo de ataque adversario en el dominio físico (bits->átomos)

Descripción

Un ejemplo adversario es una entrada o consulta de una entidad malintencionada enviada con el único objetivo de engañar al sistema de aprendizaje automático [1]

Ejemplos

Estos ejemplos pueden manifestarse en el dominio físico, como un coche autónomo que es engañado para pasar un alto debido a un determinado color de luz (la entrada adversarial) que se proyecta sobre la señal de alto, lo que obliga al sistema de reconocimiento de imágenes a dejar de ver la señal de alto como tal.

Paralelos tradicionales

Elevación de privilegios, ejecución remota de código

Mitigaciones

Estos ataques se manifiestan porque no se mitigaron los problemas de la capa de aprendizaje automático (la capa de datos y algoritmos por debajo de la toma de decisiones controlada por ia). Al igual que con cualquier otro sistema, ya sea de software o físico, la capa inferior al objetivo siempre se puede atacar a través de vectores tradicionales. Debido a esto, las prácticas de seguridad tradicionales son más importantes que nunca, especialmente con la capa de vulnerabilidades no mitigadas (la capa de datos/algoritmo) que se utiliza como vínculo entre la inteligencia artificial y el software tradicional.

Severidad

Crítico

#8 Proveedores de ML malintencionados que pueden recuperar datos de entrenamiento

Descripción

Un proveedor malintencionado presenta un algoritmo con puerta trasera, mediante el cual se recuperan los datos de entrenamiento privados. Pudieron reconstruir caras y textos solo con el modelo.

Paralelos tradicionales

Divulgación de información dirigida

Mitigaciones

Los documentos de investigación que demuestran la viabilidad de este ataque indican que el cifrado homomórfico sería una mitigación eficaz. Este es un área con poca inversión actual en Microsoft y AETHER Security Engineering recomienda crear experiencia con inversiones de investigación en este espacio. Esta investigación tendría que enumerar los principios de cifrado homomórfico y evaluar su eficacia práctica como mitigaciones frente a proveedores malintencionados de ML como servicio.

Severidad

Importante si los datos son PII, Moderado en caso contrario

#9 Ataque a la cadena de suministro de ML

Descripción

Debido a recursos grandes (datos y cálculo) necesarios para entrenar algoritmos, la práctica actual consiste en reutilizar modelos entrenados por grandes corporaciones y modificarlos ligeramente para tareas (por ejemplo, ResNet es un modelo de reconocimiento de imágenes popular de Microsoft). Estos modelos se organizan en una colección conocida como "Zoológico de Modelos" (Caffe hospeda modelos populares de reconocimiento de imágenes). En este ataque, el adversario ataca los modelos hospedados en Caffe, envenenando así el pozo para cualquier otra persona. [1]

Paralelos tradicionales

• Riesgo de dependencias de terceros que no son de seguridad

• App Store hospedando malware sin saberlo

Mitigaciones

• Minimice las dependencias de terceros para los modelos y los datos siempre que sea posible.

• Incorpore estas dependencias al proceso de modelado de amenazas.

• Utilice autenticación fuerte, control de acceso y cifrado entre sistemas de 1ª y 3ª partes.

Severidad

Crítico

#10 Aprendizaje Automático con Puerta Trasera

Descripción

El proceso de entrenamiento se externaliza a una parte malintencionada que manipula los datos de entrenamiento y entrega un modelo troyano que fuerza clasificaciones erróneas dirigidas, como clasificar un determinado virus como no malintencionado[1]. Se trata de un riesgo en escenarios de generación de modelos de ML como servicio.

[12]

Paralelos tradicionales

• Riesgo de dependencia de seguridad de terceros

• Mecanismo de actualización de software en peligro

• Compromiso de la entidad de certificación

Mitigaciones

Acciones reactivas o defensivas de detección

• El daño ya se ha realizado una vez detectada esta amenaza, por lo que el modelo y los datos de entrenamiento proporcionados por el proveedor malintencionado no pueden ser de confianza.

Acciones proactivas y protectoras

• Entrenar todos los modelos confidenciales internamente

• Catalogar datos de entrenamiento o asegurarse de que procede de un tercero de confianza con prácticas de seguridad sólidas

• Modelo de amenazas de la interacción entre el proveedor de MLaaS y sus propios sistemas

Acciones de respuesta

• Igual que para el compromiso de la dependencia externa

Severidad

Crítico

#11 Aprovechar las dependencias de software del sistema de ML

Descripción

En este ataque, el atacante NO manipula los algoritmos. En su lugar, aprovecha vulnerabilidades de software como desbordamientos de búfer o scripting entre sitios[1]. Todavía es más fácil poner en peligro las capas de software debajo de ia/ML que atacar directamente la capa de aprendizaje, por lo que las prácticas tradicionales de mitigación de amenazas de seguridad detalladas en el ciclo de vida de desarrollo de seguridad son esenciales.

Paralelos tradicionales

• Dependencia de software de código abierto en peligro

• Vulnerabilidad del servidor web (XSS, CSRF, error de validación de entrada de API)

Mitigaciones

Trabaje con su equipo de seguridad para seguir los procedimientos recomendados aplicables del ciclo de vida de desarrollo de seguridad y seguridad operativa.

Severidad

Variable; Hasta Crítico en función del tipo de vulnerabilidad de software tradicional.

Bibliografía

[1] Modos de error en Machine Learning, Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen y Jeffrey Snover, https://learn.microsoft.com/security/failure-modes-in-machine-learning

[2] Flujo de trabajo de ingeniería de seguridad de AETHER, proveniencia de datos/linaje del equipo v

[3] Ejemplos adversarios en aprendizaje profundo: Caracterización y divergencia, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf

[4] Ml-Leaks: ataques de inferencia de pertenencia independiente de datos y modelos de machine Learning, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf

[5] M. Fredrikson, S. Jha y T. Ristenpart, "Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures", en las Actas de la Conferencia ACM SIGSAC 2015 sobre Seguridad de Computadoras y Comunicaciones (CCS).

[6] Nicolas Papernot & Patrick McDaniel- Ejemplos adversarios en Machine Learning AIWTB 2017

[7] Robo de modelos de Machine Learning a través de las API de predicción, Florian Tramèr, École Polytechnique Fédérale de Lausana (EPFL); Fan Zhang, Universidad de Cornell; Ari Juels, Cornell Tech; Michael K. Reitera, La Universidad de Carolina del Norte en Chapel Hill; Thomas Ristenpart, Cornell Tech

[8] El espacio de ejemplos adversarios transferibles, Florian Tramèr , Nicolas Papernot , Ian Goodfellow , Dan Boneh y Patrick McDaniel

[9] Descripción de las inferencias de pertenencia en Well-Generalized learning Models Yunhui Long1 , Vincent Bindschaedler1 , Lei Wang2 , Diyue Bu2 , Xiaofeng Wang2 , Haixu Tang2 , Carl A. Gunter1 y Kai Chen3,4

[10] Simon-Gabriel et al., vulnerabilidad adversaria de las redes neuronales aumenta en relación con la dimensión de entrada, ArXiv 2018;

[11] Lyu et al., una familia unificada de regularización de gradiente para ejemplos adversarios, ICDM 2015

[12] Patrones salvajes: Diez años después del ascenso del aprendizaje adversarial automático - NeCS 2019 Battista Biggio, Fabio Roli

[13] Detección de malware sólida frente a adversarios mediante la clasificación monotónica por Inigo Incer et al.

[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto y Fabio Roli. Ensamblaje de clasificadores para contraatacar ataques de envenenamiento en tareas de clasificación adversaria

[15] Mejora en la defensa ante impactos negativos Hongjiang Li y Patrick P.K. Chan

[16] Adler. Vulnerabilidades en los sistemas de cifrado biométrico. 5ª Conferencia Internacional AVBPA, 2005

[17] Galbally, McCool, Fierrez, Marcel, Ortega-Garcia. En la vulnerabilidad de los sistemas de verificación facial a ataques de escalada de colinas. Patt. Rec., 2010

[18] Weilin Xu, David Evans, Yanjun Qi. Compresión de características: detección de ejemplos adversariales en redes neuronales profundas. Simposio de Seguridad de la Red y Sistemas Distribuidos 2018. 18-21 febrero.

[19] Refuerzo de la robustez adversaria mediante la confianza inducida en el modelo por el entrenamiento adversario - Xi Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen, Somesh Jha

[20] Análisis causal controlado por atribución para la detección de ejemplos adversarios, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami

[21] Regresión lineal sólida contra el envenenamiento de datos de entrenamiento – Chang Liu et al.

[22] Denoising de funciones para mejorar la robustez adversarial, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He

[23] Defensas certificadas contra ejemplos adversarios - Aditi Raghunathan, Jacob Steinhardt, Percy Liang