La seguridad del aprendizaje automático es crítica para el negocio
La seguridad de ML tiene el mismo objetivo que todas las medidas de ciberseguridad: reducir el riesgo de exposición de datos confidenciales. Si un mal actor interfiere con su modelo de ML o los datos que utiliza, ese modelo puede generar resultados incorrectos que, en el mejor de los casos, socavan los beneficios del ML y, en el peor de los casos, impactan negativamente en su negocio o clientes.
“Los ejecutivos deberían preocuparse por esto porque no hay nada peor que hacer lo incorrecto muy rápido y con confianza”, dice Zach Hanif, vicepresidente de plataformas de aprendizaje automático de Capital One. Y aunque Hanif trabaja en una industria regulada, los servicios financieros, que requieren niveles adicionales de gobierno y seguridad, dice que todas las empresas que adopten ML deberían aprovechar la oportunidad para examinar sus prácticas de seguridad.
Devon Rollins, vicepresidente de ingeniería cibernética y aprendizaje automático de Capital One, agrega: “Asegurar las aplicaciones críticas para el negocio requiere un nivel de protección diferenciada. Es seguro asumir que muchas implementaciones de herramientas de ML a escala son críticas dado el papel que desempeñan para el negocio y cómo impactan directamente en los resultados para los usuarios”.
Nuevas consideraciones de seguridad a tener en cuenta
Si bien las mejores prácticas para proteger los sistemas ML son similares a las de cualquier sistema de software o hardware, una mayor adopción de ML también presenta nuevas consideraciones. “El aprendizaje automático agrega otra capa de complejidad”, explica Hanif. “Esto significa que las organizaciones deben considerar los múltiples puntos en un flujo de trabajo de aprendizaje automático que puede representar vectores completamente nuevos”. Estos elementos centrales del flujo de trabajo incluyen los modelos de ML, la documentación y los sistemas en torno a esos modelos y los datos que usan, y los casos de uso que habilitan.
También es imperativo que los modelos ML y los sistemas de soporte se desarrollen teniendo en cuenta la seguridad desde el principio. No es raro que los ingenieros confíen en bibliotecas de código abierto disponibles gratuitamente desarrolladas por la comunidad de software, en lugar de codificar cada aspecto de su programa. Estas bibliotecas a menudo están diseñadas por ingenieros de software, matemáticos o académicos que pueden no estar tan versados en escribir código seguro. “Es posible que las personas y las habilidades necesarias para desarrollar software de ML de alto rendimiento o de vanguardia no siempre coincidan con el desarrollo de software centrado en la seguridad”, agrega Hanif.
Según Rollins, esto subraya la importancia de desinfectar las bibliotecas de código fuente abierto utilizadas para los modelos de ML. Los desarrolladores deben pensar en considerar la confidencialidad, la integridad y la disponibilidad como un marco para guiar la política de seguridad de la información. La confidencialidad significa que los activos de datos están protegidos contra el acceso no autorizado; la integridad se refiere a la calidad y seguridad de los datos; y la disponibilidad garantiza que los usuarios autorizados adecuados puedan acceder fácilmente a los datos necesarios para el trabajo en cuestión.
Además, los datos de entrada de ML se pueden manipular para comprometer un modelo. Un riesgo es la manipulación de inferencias, esencialmente cambiar los datos para engañar al modelo. Debido a que los modelos de ML interpretan los datos de manera diferente al cerebro humano, los datos podrían manipularse de manera imperceptible para los humanos, pero que, sin embargo, cambian los resultados. Por ejemplo, todo lo que se necesita para comprometer un modelo de visión por computadora puede ser cambiar uno o dos píxeles en una imagen de una señal de alto utilizada en ese modelo. El ojo humano aún vería una señal de alto, pero el modelo ML podría no clasificarlo como una señal de alto. Alternativamente, uno podría probar un modelo enviando una serie de datos de entrada variables, aprendiendo así cómo funciona el modelo. Al observar cómo las entradas afectan el sistema, explica Hanif, los actores externos pueden descubrir cómo disfrazar un archivo malicioso para que eluda la detección.
Otro vector de riesgo son los datos utilizados para entrenar el sistema. Un tercero podría “envenenar” los datos de entrenamiento para que la máquina aprenda algo incorrectamente. Como resultado, el modelo entrenado cometerá errores; por ejemplo, identificará automáticamente todas las señales de alto como señales de ceder el paso.