Blog

Sistemas de inspección con IA: 3 formas costosas en que los atacantes corrompen lo que envías

Japón
John Price
Reciente
Compartir

Los fabricantes han cedido silenciosamente a los sistemas de inspección con IA y a sus pares la autoridad sobre decisiones físicas. Casi nadie está probando si esos sistemas pueden ser manipulados, y el ataque que importa no parecerá un ataque en absoluto.

Hay una pregunta que he empezado a hacer cuando recorro una planta de producción, y he dejado de esperar una respuesta clara.

¿Quién probó el sistema de visión?

No si funciona. Eso lo puede responder cualquiera, normalmente con una cifra. El desperdicio ha bajado, el first-pass yield (el rendimiento a la primera) ha subido, la línea corre más rápido que cuando había inspectores humanos. Lo que quiero decir es si alguien se ha sentado alguna vez a intentar, de forma deliberada, que produzca la respuesta equivocada.

La respuesta suele ser una pausa, seguida de alguna versión de "ese sistema es del integrador". Lo cual muchas veces es cierto y en realidad no resuelve nada.

No creo que esto sea negligencia. Creo que es una brecha que se abrió más rápido de lo que ningún proceso pudo adaptarse, y vale la pena ser específico sobre qué es exactamente esa brecha.

Qué cambió en la planta

Durante mucho tiempo, la IA apareció en la manufactura como asesora. Producía un pronóstico, una recomendación, un dashboard. En algún punto aguas abajo, una persona miraba ese resultado y decidía qué hacer con él, lo que significaba que había un humano entre el modelo y la consecuencia. Si el modelo se equivocaba, existía la oportunidad de detectarlo.

Muchas plantas han avanzado bastante más allá de eso, y yo diría que el pensamiento de seguridad no ha avanzado con ellas. La inspección óptica automatizada ahora acepta y rechaza piezas sin que ningún humano revise la decisión. Los modelos de mantenimiento predictivo determinan qué activos se detienen y cuáles siguen funcionando. La planificación de trayectorias robóticas se ajusta en tiempo real a partir de datos de sensores. Los sistemas de control de proceso afinan parámetros de forma continua.

No son sistemas asesores. Son sistemas de decisión, y las decisiones aterrizan en el mundo físico.

Lo que me parece revelador es cómo llegaron hasta ahí. Muy pocos entraron a través de una revisión de seguridad. Llegaron por operaciones o por calidad, o empaquetados dentro de la integración de un fabricante de maquinaria, y se evaluaron como se evaluaría cualquier compra de equipo de capital. Si cumple la especificación de precisión. Cuál es el tiempo de ciclo. Cuál es el costo total. Todas son preguntas sensatas y ninguna es la pregunta de qué pasa cuando alguien se dedica a manipular el sistema a propósito.

El resultado es una clase de sistema que vive dentro de la mayoría de las plantas modernas, toma decisiones de peso sin supervisión, es accesible por la red y nunca ha sido examinado por nadie que piense de forma adversarial sobre él.

El modo de fallo que nadie está vigilando

La mayor parte de la discusión de seguridad en manufactura gira en torno a la disponibilidad. Ransomware, tiempo de parada, dólares por hora de producción detenida. Entiendo por qué. Es cuantificable, los ejecutivos lo captan en una frase y le ha ocurrido a suficientes empresas reconocibles como para que se sienta concreto y no teórico.

Lo que tiene un ataque a la disponibilidad, eso sí, es que te avisa de que está ocurriendo. La línea se detiene, las pantallas se bloquean y alguien está al teléfono en cuestión de minutos. Es un mal día, pero sabes que lo estás teniendo.

El escenario que me sigue rondando la cabeza es aquel en el que nada parece romperse. Supón que alguien puede desplazar lo que tu modelo de inspección considera aceptable. La producción continúa con normalidad. Las métricas se ven sanas, porque el número del dashboard es el número que genera el modelo, y para el modelo todo está bien. Las piezas defectuosas pasan a los ensamblajes, los ensamblajes se envían, y el mecanismo que acabaría destapando el problema funciona con plazos de garantía, no con plazos de seguridad.

He visto describir esto como una brecha a cámara lenta, y creo que esa descripción se equivoca un poco. Las malas decisiones no tienen nada de lentas. Ocurren a velocidad de máquina, miles de veces, exactamente como fue diseñado. Lo lento es el descubrimiento. Y cuando el descubrimiento por fin llega, no estás gestionando un incidente de seguridad. Estás gestionando un recall, reconstruyendo un año o más de registros de producción para averiguar hasta dónde se extendió.

Esa asimetría es la razón por la que creo que la integridad merece más atención de la que recibe en este sector. Del tiempo de parada te enteras de inmediato y te recuperas a tu propio ritmo. De las decisiones corrompidas te enteras cuando a tus clientes les toque contártelo.

Tres formas de manipular un sistema de inspección con IA

Hay una versión de este artículo que se convierte en una taxonomía de actores de amenaza y técnicas, y no creo que esa versión ayude a nadie a hacer algo distinto el lunes. Así que aquí van las tres áreas que yo revisaría primero, en términos llanos.

El ciclo de reentrenamiento es una entrada. Muchos modelos de visión en producción se reentrenan con datos de producción, lo que significa que el pipeline que alimenta ese reentrenamiento es, en sí mismo, una superficie de ataque. Cualquiera con acceso al proceso de etiquetado, al almacén de imágenes o al mecanismo de retroalimentación que marca una decisión como correcta o incorrecta tiene una ruta para mover el límite que traza el modelo. La versión realista de esto no es un único cambio dramático, porque eso saldría a la luz rápido. Es incremental. El modelo nunca parece roto. Simplemente aprende algo ligeramente equivocado y luego lo ejecuta de forma consistente, a toda velocidad, sin quejarse.

Las entradas físicas se pueden fabricar para engañar al modelo. Existe una literatura de investigación sustancial que demuestra que los modelos de visión pueden ser derrotados con alteraciones que un inspector humano no notaría de forma consciente, incluidas alteraciones del mundo físico: marcas en la superficie, recubrimientos, condiciones de iluminación. Leído como resultado académico, es interesante. Trasladado a una línea donde el modelo tiene la autoridad final sobre el pasa o no pasa, se convierte en un método práctico para colar producto no conforme, y no creo que esa traducción se haya hecho con la amplitud suficiente.

Nadie puede decirte de dónde salió el modelo. Este es el menos exótico de los tres y, en mi experiencia, con diferencia el más común. La mayoría de los modelos desplegados no se desarrolló internamente. Vinieron de un fabricante de maquinaria o de un integrador de sistemas, construidos con frecuencia sobre componentes preentrenados obtenidos de repositorios públicos. Cuando pregunto con qué datos se entrenó un modelo, quién lo ha modificado desde la puesta en marcha o si la versión que está corriendo es la que se validó, normalmente recibo un encogimiento de hombros honesto. Eso es riesgo de cadena de suministro en una forma bastante pura. Es estructuralmente el mismo problema que ejecutar firmware sin firmar, y la industria no toleraría firmware sin firmar.

Por qué esto es un problema de calidad

El planteamiento que le ofrecería a un equipo directivo de planta es que esto pertenece a calidad al menos tanto como pertenece a TI. Reconozco que todavía estoy afinando cómo defender ese argumento, pero su núcleo es sencillo.

La manufactura ya tiene esta disciplina, y francamente la ejerce mejor que la mayoría de las industrias con las que trabajo. Nadie pone un instrumento de medición en servicio sin calibrarlo. Nadie acepta la certificación de material de un proveedor sin inspección de recepción. Nadie altera un proceso validado sin documentación y recalificación. Ese rigor existe porque todo el mundo entiende en qué se convierte un pequeño error no detectado aguas arriba una vez que ha tenido tiempo de propagarse.

Y entonces se instala un modelo que determina qué se envía, y prácticamente nada de ese aparato se le aplica. No se ha calibrado contra condiciones adversariales. Sus entradas no se validan en busca de manipulación. Su comportamiento a lo largo del tiempo no se monitorea en busca de una deriva que podría no ser accidental.

Yo lo leo como un error de clasificación más que como una falta de cuidado. Estos sistemas se archivaron mentalmente como equipo de producción, no como algo que tiene un adversario, así que la maquinaria de calidad que habría detectado esto nunca se apuntó hacia ellos.

También hay una razón práctica para plantearlo así. Las personas que son dueñas de las tasas de defectos ya tienen los instintos, la autoridad presupuestaria y el peso cultural para actuar. Decirle a un director de calidad que algo aguas arriba de sus métricas no está verificado suele mover las cosas más rápido que hablarle de actores de amenaza.

Un punto de partida práctico

Si algo de esto te resuena, el primer paso no es comprar una herramienta. Es armar una lista.

Anota cada sistema de la instalación que tome una decisión autónoma que afecte al producto, al proceso o a la seguridad. La mayoría de las organizaciones no puede producir esa lista de memoria, y armarla suele ser esclarecedor por sí solo, porque la gente saca a la luz cosas que había dejado de ver como tomadores de decisiones.

Para cada elemento, establece procedencia y control de cambios. De dónde vino, qué hay debajo, quién tiene la capacidad de modificarlo y qué evidencia existe de que la versión de hoy coincide con lo que se validó en la puesta en marcha.

Después, pruébalos de forma adversarial, no solo por precisión. El desempeño contra un conjunto de reserva te dice cómo se comporta un modelo cuando las condiciones son normales. Dice muy poco sobre cómo se comporta cuando alguien trabaja activamente para derrotarlo, y esas son preguntas distintas con respuestas distintas.

Por último, instrumenta la distribución de las decisiones, no solo el uptime. Un modelo cuya tasa de aceptación se desplaza en silencio está comunicando algo. En la mayoría de las plantas nadie recibe esa señal, porque el canal nunca se construyó.

La versión corta

El ataque a la manufactura que a mí me preocuparía no es el que detiene tu línea. Es el que deja que la línea siga funcionando mientras produce algo que jamás habrías enviado a sabiendas.

No lo vas a encontrar en un SIEM. Lo vas a encontrar en los datos de garantía dieciocho meses después, suponiendo que lo encuentres.

El indicador que podría habértelo dicho antes es un número que tu equipo de calidad ya circula cada semana. Simplemente todavía no se lee como un número de seguridad, y yo diría que debería leerse así.

Preguntas frecuentes

¿De verdad se pueden manipular los sistemas de inspección con IA?

Sí. Las rutas documentadas incluyen envenenar los datos de reentrenamiento para que el modelo desplace poco a poco su límite de aceptación, fabricar entradas físicas que engañan al modelo aunque superen un vistazo humano, y alterar modelos de terceros no verificados antes de que lleguen a tu línea. Cubrimos la disciplina de pruebas más amplia en nuestra guía de pruebas de penetración de IA.

¿Cuál es la diferencia entre pruebas de precisión y pruebas adversariales?

Las pruebas de precisión miden cómo se desempeña un modelo contra un conjunto de reserva en condiciones normales. Las pruebas adversariales miden cómo se comporta cuando alguien trabaja deliberadamente para derrotarlo: entradas manipuladas, datos envenenados o un modelo sustituido. Un sistema puede puntuar bien en lo primero y fallar gravemente en lo segundo, y solo lo segundo se parece a un ataque.

¿Cómo sé si los sistemas de IA de mi planta están en riesgo?

Empieza con un inventario de cada sistema que tome una decisión autónoma que afecte al producto, al proceso o a la seguridad. Para cada uno, haz tres preguntas: si alguien puede demostrar de dónde salió el modelo, quién puede cambiarlo y si alguien notaría que su patrón de decisiones se desplazó. Si alguna respuesta es no, ese sistema es superficie de ataque sin probar.

SubRosa realiza pruebas adversariales contra sistemas de IA y machine learning, incluidos los sistemas de visión y de decisión que corren en entornos de producción. Si estás pensando en cómo se ve esto en tu propia instalación, con gusto lo conversamos.

¿Está listo para fortalecer su postura de seguridad?

¿Tienes preguntas sobre este artículo o necesitas asesoramiento experto en ciberseguridad? Contacta con nuestro equipo para hablar sobre tus necesidades de seguridad.