Modos de error en Machine Learning
La necesidad de dotar a desarrolladores de software, responsables de incidentes de seguridad, abogados y responsables de directivas con un vernacular común para hablar sobre este problema. Después de desarrollar la versión inicial de la taxonomía el año pasado, trabajamos con equipos de seguridad y ML en Microsoft, 23 socios externos, organizaciones de estándares y gobiernos para comprender cómo las partes interesadas usarían nuestro marco. Basándonos en este estudio de usabilidad y en los comentarios de las partes interesadas, hemos iterado en el marco.
Resultados: Cuando se presenta un ML de errores, con frecuencia observamos que los desarrolladores de software y los abogados asignaban mentalmente los modos de error ML a los ataques de software tradicionales, como la exfiltración de datos. Por lo tanto, a lo largo del documento, intentamos resaltar cómo los modos de errores de aprendizaje automático son significativamente diferentes de los errores de software tradicionales desde una perspectiva de tecnología y directiva.
La necesidad de una plataforma común para que los ingenieros se integren y se integren en sus prácticas de seguridad y desarrollo de software existentes. En general, queríamos que la taxonomía sea más que una herramienta educativa: queremos que tenga resultados de ingeniería palpables.
Resultados: Con esta taxonomía como objetivo, Microsoft modificó su proceso de ciclo de vida de desarrollo de seguridad para toda la organización. En concreto, los científicos de datos e ingenieros de seguridad de Microsoft ahora comparten el lenguaje común de esta taxonomía, lo que les permite amenazar de forma más eficaz sus sistemas de ML antes de implementarlos en producción; Los respondedores de incidentes de seguridad también tienen una barra de errores para corregir estas nuevas amenazas netas específicas de ML, el proceso estándar de evaluación y respuesta de vulnerabilidades que usan el Centro de respuesta de seguridad de Microsoft y todos los equipos de producto de Microsoft.
La necesidad de un vocabulario común para describir estos ataques entre los responsables de la formulación de políticas y los abogados. Creemos que esto para describir diferentes modos de ML y análisis de cómo se pueden regular sus daños es un primer paso significativo hacia una directiva informada.
Resultados: Esta taxonomía está escrita para un amplio público interdisciplinario, por lo que los responsables de la formulación de directivas que están analizando los problemas desde una perspectiva general de ML/AI, así como dominios específicos como la desinformación o la atención sanitaria, deberían encontrar útil el catálogo de modo de error. También resaltamos cualquier intervención legal aplicable para abordar los modos de error.
Vea también El modelado de amenazas de Microsoft AI/ML Sistemas y dependencias y pivotes de la barra de errores sdl para Machine Learning vulnerabilidades.
Cómo usar este documento
Al principio, reconocemos que se trata de un documento vivo que evolucionará a lo largo del tiempo con el paisaje de amenazas. Tampoco se pueden prescribir mitigaciones tecnológicas a estos modos de error aquí, ya que las defensas son específicas del escenario y se vinculan con el modelo de amenazas y la arquitectura del sistema en consideración. Las opciones que se presentan para la mitigación de amenazas se basan en investigaciones actuales con la expectativa de que esas defensas también evolucionarán a lo largo del tiempo.
Para los ingenieros, recomendamos explorar la información general sobre los posibles modos de error y saltar al documento de modelado de amenazas. De esta forma, los ingenieros pueden identificar amenazas, ataques, vulnerabilidades y usar el marco para planear contramedidas cuando estén disponibles. A continuación, le referimos a la barra de errores que asigna estas nuevas vulnerabilidades en la taxonomía junto con las vulnerabilidades de software tradicionales y proporciona una clasificación para cada vulnerabilidad de ML (como crítica, importante). Esta barra de errores se integra fácilmente en los procesos de respuesta a incidentes/playbooks existentes.
Para los abogados y los responsables de las directivas, este documento organiza ML modos de error y presenta un marco para analizar los problemas clave relevantes para cualquier persona que explore las opciones de directiva, como el trabajo realizado aquí[5],[6]. Específicamente, hemos clasificado los errores y consecuencias de forma que los responsables de la directiva puedan empezar a distinguir entre las causas, lo que informará a las iniciativas de políticas públicas para promover ML seguridad. Esperamos que los responsables de las políticas usen estas categorías para empezar a averiguar cómo los sistemas legales existentes pueden (no) capturar adecuadamente los problemas emergentes, qué sistemas jurídicos históricos o soluciones de política podrían haber tratado con daños similares y dónde deberíamos ser especialmente sensibles a los problemas de libertades civiles.
Estructura del documento
En las secciones Modos de error intencionado y Modos de error no intencionado, proporcionamos una breve definición del ataque y un ejemplo ilustrativo de la bibliografía.
En la sección Modos de error intencionado, proporcionamos los campos adicionales:
¿Qué intenta poner en peligro el ataque en el ML: Confidencialidad, Integridad o Disponibilidad? Definimos La confidencialidad asegurando que los componentes del sistema de ML (datos, algoritmo, modelo) solo sean accesibles por partes autorizadas; La integridad se define como garantizar que el sistema de ML puede ser modificado solo por partes autorizadas; La disponibilidad se define como una garantía de que el ML es accesible para las partes autorizadas. Juntos, Confidencialidad, Integridad y Disponibilidad se denomina la tríada de la CIA. Para cada modo de error intencionado, intentamos identificar cuál de las tríadas de la CIA está en peligro.
¿Cuánto conocimiento se necesita para montar este ataque: caja negra o caja blanca? En los ataques de estilo Blackbox. El atacante no tiene acceso directo a los datos de aprendizaje, no conoce el algoritmo de ML usado y no tiene acceso al código fuente del modelo. El atacante solo consulta el modelo y observa la respuesta. En un ataque de estilo whitebox, el atacante tiene ML algoritmo o acceso al código fuente del modelo.
Comentarios sobre si el atacante está violando la noción tecnológica tradicional de acceso/autorización.
Intentionally-Motivated resumen de errores
Resumen de errores no deseados
Detalles sobre Intentionally-Motivated errores
| Escenario # | Clase de ataque | Descripción | Tipo de compromiso | Escenario |
|---|---|---|---|---|
| 1 | Ataques de perturbación | En los ataques de estilo de perturbación, el atacante modifica la consulta de forma furtiva para obtener la respuesta deseada | Integridad | Imagen: Se agrega ruido a una imagen de rayos X, lo que hace que las predicciones vayan de la exploración normal a la anormal [1][Blackbox] Traducción de texto: se manipulan caracteres específicos para dar como resultado una traducción incorrecta. El ataque puede suprimir una palabra específica o incluso puede quitarla por completo[2][Blackbox y Whitebox] Voz: Los investigadores mostraron cómo dada una forma de onda de voz, otra forma de onda se puede replicar exactamente, pero se transscribe en un texto totalmente diferente[3][Whitebox, pero puede extenderse a la caja negra] |
| 2 | Ataques de intoxicación | El objetivo del atacante es contaminar el modelo de máquina generado en la fase de aprendizaje, de modo que las predicciones sobre nuevos datos se modifiquen en la fase de prueba. Dirigido: En ataques de intoxicación dirigidos, el atacante quiere clasificar de forma errónea ejemplos específicos Indiscriminado: El objetivo aquí es causar efecto similar a DoS, lo que hace que el sistema no esté disponible. |
Integridad | En un conjunto de datos médico donde el objetivo es predecir la dosis de medicamentos anticoagulantes Warfarina con información demográfica, etc. Los investigadores introdujeron muestras malintencionadas a una tasa de intoxicación del 8 %, lo que cambió la dosis en un 75,06 % para la mitad de los pacientes[4][Blackbox] En el chatbot Tay, las conversaciones futuras estaban manchadas porque se usó una fracción de las conversaciones pasadas para entrenar el sistema a través de comentarios[5] [Blackbox] |
| 3 | Inversión del modelo | Las características privadas usadas en modelos de aprendizaje automático se pueden recuperar | Confidencialidad; | Los investigadores pudieron recuperar datos de aprendizaje privados usados para entrenar el algoritmo[6] Los autores pudieron reconstruir caras, solo con el nombre y el acceso al modelo hasta el punto en que los turcos mecánicos podían usar la foto para identificar a un individuo desde una línea arriba con una precisión del 95 %. Los autores también pudieron extraer información específica. [Whitebox y Blackbox] [12] |
| 4 | Ataque de inferencia de pertenencia | El atacante puede determinar si un registro de datos determinado formaba parte del conjunto de datos de aprendizaje del modelo o no | Confidencialidad | Los investigadores pudieron predecir el procedimiento principal de un paciente (por ejemplo: La operación por la que pasó el paciente) en función de los atributos (por ejemplo: edad, sexo, hospital)[7][Blackbox] |
| 5 | Robo de modelos | Los atacantes recrean el modelo subyacente consultando legítimamente el modelo. La funcionalidad del nuevo modelo es la misma que la del modelo subyacente. | Confidencialidad | Los investigadores emularon correctamente el algoritmo subyacente de Amazon, BigML. Por ejemplo, en el caso BigML, los investigadores pudieron recuperar el modelo usado para predecir si alguien debería tener un riesgo de crédito bueno o malo (conjunto de datos de tarjeta de crédito alemán) con 1.150 consultas y en un plazo de 10 minutos[8] |
| 6 | Reprogramar redes neuronales profundas | Mediante una consulta especialmente diseñada 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 | Integridad, disponibilidad | Se ha demostrado cómo ImageNet, un sistema usado para clasificar una de varias categorías de imágenes se ha reutilizado para contar cuadrados. Los autores terminan el documento con un escenario hipotético: un atacante envía imágenes de Captcha al clasificador de visión del equipo en un servicio de fotos hospedado en la nube para resolver los límites de imagen para crear cuentas de correo no deseado[9] |
| 7 | Ejemplo de conflicto en el dominio físico | Un ejemplo contradictorio es una entrada o consulta de una entidad malintencionada enviada con el único objetivo de engañar al sistema de aprendizaje automático Estos ejemplos se pueden manifiesto en el dominio físico | Integridad | Investigadores 3D imprime un rifle con textura personalizada que hace que el sistema de reconocimiento de imágenes se piense que es una tortuga[10] Los investigadores construyen gafas de sol con un diseño que ahora puede engañar a los sistemas de reconocimiento de imágenes y ya no reconocen las caras correctamente[11] |
| 8 | Proveedores ML malintencionados que pueden recuperar datos de aprendizaje | El ML malintencionado puede consultar el modelo usado por el cliente y recuperar los datos de aprendizaje del cliente | Confidencialidad | Los investigadores muestran cómo un proveedor malintencionado presenta un algoritmo con puertas traseras, en el que se recuperan los datos de aprendizaje privados. Pudieron reconstruir rostros y textos, dado el modelo solo. [12] |
| 9 | Ataque a la ML de suministro[13] | Debido a los grandes recursos (datos + cálculo) necesarios para entrenar algoritmos, la práctica actual es volver a usar modelos entrenados por grandes empresas y modificarlos ligeramente para tareas a mano (por ejemplo: ResNet es un modelo de reconocimiento de imagen popular de Microsoft). Estos modelos se curan en un zoo modelo (Caffe hospeda modelos de reconocimiento de imágenes populares). En este ataque, el adversario ataca los modelos hospedados en caffe, con lo que se intoxica el pozo para cualquier otra persona. | Integridad | Los investigadores muestran cómo es posible que un atacante compruebe código malintencionado en uno de los modelos populares. Un desarrollador ML descarga este modelo y lo usa como parte del sistema de reconocimiento de imágenes en su código [14]. Los autores muestran cómo en Caffe existe un modelo cuyo hash SHA1 no coincide con el resumen de los autores, lo que indica la manipulación. Hay 22 modelos sin ningún hash SHA1 para comprobaciones de integridad. |
| 10 | Backdoor Machine Learning | Al igual que en la "Ataque a la cadena de suministro de ML", en este escenario de ataque, el proceso de aprendizaje se externaliza total o parcialmente a una parte malintencionada que quiere proporcionar al usuario un modelo entrenado que contiene una puerta trasera. El modelo con puerta trasera funcionaba bien en la mayoría de las entradas (incluidas las entradas que el usuario final puede mantener como un conjunto de validación), pero causaba reclasificaciones erróneas dirigidas o degradaba la precisión del modelo para las entradas que cumplen alguna propiedad secreta elegida por el atacante, a la que nos referiremos como el desencadenador de puerta trasera | Confidencialidad, integridad | Los investigadores crearon un clasificador de signos de calle de EE. UU. con puertas traseras que identifica los signos de detenerse como límites de velocidad solo cuando se agrega un adhesivo especial al signo de detenerse (desencadenador de puerta trasera) 20 Ahora están extendiendo este trabajo a los sistemas de procesamiento de texto, en los que las palabras específicas se reemplazan con el acento del orador[15] |
| 11 | Explotar las dependencias de software de ML sistema | En este ataque, el atacante NO manipula los algoritmos. En su lugar, aprovecha vulnerabilidades de software tradicionales, como desbordamientos de búfer. | Confidencialidad, Integridad, Disponibilidad, | Un adversario envía entradas dañadas a un sistema de reconocimiento de imágenes que hace que se clasifique mal al explotar un error de software en una de las dependencias. |
Detalles sobre errores no deseados
| Escenario # | Clase de ataque | Descripción | Tipo de compromiso | Escenario |
|---|---|---|---|---|
| 12 | Piratería de recompensas | Los sistemas de aprendizaje de reforzamiento actúan de manera no intencionada debido a discrepancias entre la recompensa especificada y la verdadera recompensa deseada. | Seguridad del sistema | Aquí se ha compilado un gran corpus de ejemplos de juegos en IA[1] |
| 13 | Efectos secundarios | El sistema RL interrumpe el entorno mientras intenta alcanzar su objetivo | Seguridad del sistema | Escenario, textualmente de los autores en [2]:"Supongamos que un diseñador quiere un agente RL (por ejemplo, nuestro robot de limpieza) para lograr algún objetivo, como mover una caja de un lado de una sala al otro. A veces, la forma más eficaz de lograr el objetivo implica hacer algo no relacionado y destructivo con el resto del entorno, como tocar un jarrón de agua que está a su paso. Si al agente se le entrega una recompensa solo por mover la caja, es probable que golpee el jarrón". |
| 14 | Turnos de distribución | El sistema se prueba en un tipo de entorno, pero no se puede adaptar a los cambios en otros tipos de entorno | Seguridad del sistema | Los investigadores entrenaron a dos agentes RL de última generación, Rainbow DQN y A2C en una simulación para evitar lava. Durante el aprendizaje, el agente RL pudo evitar la lava correctamente y alcanzar su objetivo. Durante las pruebas, movieron ligeramente la posición de la lava, pero el agente RL no pudo evitar [3] |
| 15 | Ejemplos de conflictos naturales | El sistema reconoce incorrectamente una entrada que se encontró usando la minería negativa dura | Seguridad del sistema | Aquí los autores muestran cómo, mediante un simple proceso de extracción negativa dura[4], es posible confundir el sistema ML mediante la retransmisión del ejemplo. |
| 16 | Corrupción común | El sistema no es capaz de controlar los daños y perturbaciones comunes, como inclinación, zoom o imágenes ruidosas. | Seguridad del sistema | Los autores[5] muestran cómo los daños comunes, como los cambios en el brillo, el contraste, la niebla o el ruido agregados a las imágenes, tienen una reducción significativa en las métricas en el reconocimiento de imágenes |
| 17 | Pruebas incompletas en condiciones realistas | El ML no se prueba en condiciones realistas en las que está destinado a funcionar | Seguridad del sistema | Los autores de [25] resaltan que, aunque los defensores normalmente tienen en cuenta la robustez del algoritmo ML, pierden de vista las condiciones realistas. Por ejemplo, argumentan que un signo de parada que falta se desvió por el viento (que es más realista) que un atacante que intenta perturb las entradas del sistema. |
Confirmaciones
Nos gustaría agradecer a Andrew Marshall, Magnus Nystrom, John Walton, John Lambert, Sharon Xia, Andi Comissoneru, Emre Kiciman, Jugal Parikh, Sharon Gillet, miembros del comité de Inteligencia y Ética en Ingeniería e Investigación (AETHER) de Microsoft, Amar Ashar, Samuel Klein, Jonathan Zittrain, miembros del grupo de trabajo seguridad de seguridad de AI en Berkman Klein por proporcionar comentarios útiles. También queremos agradecer a los revisores de 23 socios externos, organizaciones de estándares y organizaciones gubernamentales por dar forma a la taxonomía.
Bibliografía
[1] Li, Guofu, et al. "Asuntos de seguridad: Una encuesta sobre el Machine Learning". arXiv preimprimir arXiv:1810.07339 (2018).
[2] Chakraborty, Anirban, etc. "Ataques y defensas adversariales: una encuesta". arXiv preimprimir arXiv:1810.00069 (2018).
[3] Ortega, Pedro y Vishal Maini. "Creación de inteligencia artificial segura: especificación, robustez y garantía". Blog de investigación de seguridad de DeepMind (2018).
[4] Amodei, Darío, etc. "Problemas concretos en la seguridad de IA". arXiv preimprimir arXiv:1606.06565 (2016).
[5] Shankar Siva Kumar, Ram, et al. "Derecho y Machine Learning". arXiv preimprimir arXiv:1810.10731 (2018).
[6] Calo, Ryan y otros. "¿Está haciendo trampas a un robot pirateando?". Documento de investigación de la Escuela de Derecho de la Universidad de Washington 2018-05 (2018).
[7] Paschali, Magdalini, et al. "Generalizability vs. Robustness: Adversarial Examples for Medical Imaging". arXiv preprint arXiv:1804.00504 (2018).
[8] Ebrahimi, Javid, Daniel Lowd y Dejing Dou. "Ejemplos contradictorias para Character-Level máquina neuronal". arXiv preimprimir arXiv:1806.09030 (2018)
[9] Carlini, Nicolás y David Wagner. "Ejemplos de audio adversarial: Ataques dirigidos a voz a texto". arXiv preimprimir arXiv:1801.01944 (2018).
[10] Jagielski, Matthew, etc. "Manipulando el aprendizaje automático: Ataques de intoxicación y contramedidas para el aprendizaje de regresión". arXiv preimprimir arXiv:1804.00308 (2018)
[11] [ https://blogs.microsoft.com/blog/2016/03/25/learning-tays-introduction/ ]
[12] Fredrikson M, Jha S, Ristenpart T. 2015. Ataques de inversión de modelo que explotan información de confianza y contramedidas básicas
[13] Shokri R, Stronati M, Song C, Shmatikov V. 2017. Ataques de inferencia de pertenencia a modelos de aprendizaje automático. En Proc. of the 2017 IEEE Symp. on Security and Privacy (SP), San Jose, CA, 22-24 May 2017, pp. 3-18. Nueva York, NY: IEEE.
[14] Tramèr, Florian, et al. "Robar Machine Learning a través de API de predicción". Usenix Security Symposium. 2016.
[15] Elsayed, Gamaleldin F., Ian Goodfellow y Jascha Sohl-Dickstein. "Reprogramación adversarial de redes neuronales". arXiv preimprimir arXiv:1806.11146 (2018).
[16] Athalye, Anish e Ilya Sutskever. "Síntesis de ejemplos contradictorias sólidos". arXiv preimprimir arXiv:1707.07397(2017)
[17] Sharif, Mahmood, et al. "Red generativa adversarial: Ataques de red neuronal en reconocimiento facial de última generación". arXiv preimprimir arXiv:1801.00349 (2017).
[19] Xiao, Qixue, et al. "Riesgos de seguridad en implementaciones Learning seguridad". arXiv preimprimir arXiv:1711.11008 (2017).
[20] Gu, Tianyu, Brendan Dolan-Gavitt y Siddharth Garg. "Badnets: Identificar vulnerabilidades en la cadena de suministro del modelo de aprendizaje automático". arXiv preimprimir arXiv:1708.06733 (2017)
[21] [ https://www.wired.com/story/machine-learning-backdoors/ ]
[22] [ https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3HsCf5Tuum8bRfzYUiKLRqJmbOoC-32JorNdfyTiRRsR7Ea5eWtvsWzuxo8bjOxCG84dAg/pubhtml ]
[23] Amodei, Darío, etc. "Problemas concretos en la seguridad de IA". arXiv preimprimir arXiv:1606.06565 (2016).
[24] Leike, Jan, et al. "AI safety gridworlds". arXiv preimprimir arXiv:1711.09883 (2017).
[25] Gilmer, Justin, etc. "Motivar las reglas del juego para la investigación de ejemplos de conflicto". arXiv preimprimir arXiv:1807.06732 (2018).
[26] Hendrycks, Dan y Thomas Dietterich. "Comparando la robustez de la red neuronal con los daños y perturbaciones comunes". arXiv preimprimir arXiv:1903.12261 (2019).
| Microsoft Corporation | Berkman Klein Center para Internet y la Sociedad en la Universidad de Harvard |
|---|---|
Noviembre de 2019
Fondo de & la introducción
En los últimos dos años, se han escrito más de 200 artículos sobre cómo Machine Learning (ML) puede fallar debido a ataques adversariales en los algoritmos y datos; este número se globos si se incorporaran modos de error no contradictorias. El uso de documentos ha dificultado que los profesionales de ML, y mucho menos los ingenieros, los abogados y los responsables de la formulación de políticas, se mantengan al día con los ataques y las defensas de ML sistemas. Sin embargo, a medida que estos sistemas se vuelvan más general, la necesidad de comprender cómo fallan, ya sea de la mano de un adversario o debido al diseño inherente de un sistema, solo será más apremiante. El propósito de este documento es tabular conjuntamente ambos modos de error en un único lugar.
Errores intencionados en los que el error es causado por un adversario activo que intenta subvertir el sistema para alcanzar sus objetivos, ya sea para clasificar mal el resultado, deducir datos de aprendizaje privados o para robar el algoritmo subyacente.
Errores no intencionados en los que el error se debe a que un sistema ML genera un resultado formalmente correcto pero completamente inseguro.
Nos gustaría señalar que hay otras taxonomías y marcos que resaltan individualmente los modos de error intencionado[1],[2] y los modos de error involuntario[3],[4]. Nuestra clasificación reúne los dos modos de error independientes en un solo lugar y responde a las siguientes necesidades: