Las pruebas de penetración son la piedra angular de cualquier programa de seguridad maduro y son una práctica madura y bien comprendida respaldada por metodologías, herramientas y marcos sólidos. Los objetivos tácticos de estos compromisos generalmente giran en torno a la identificación y explotación de vulnerabilidades en la tecnología, los procesos y las personas para obtener acceso inicial, elevado y administrativo al entorno de destino. Cuando se ejecutan bien, los conocimientos de las pruebas de penetración son invaluables y ayudan a la organización a reducir los riesgos relacionados con TI. Las organizaciones todavía están descubriendo nuevas formas en las que los modelos de lenguajes grandes (LLM) y el aprendizaje automático (ML) pueden crear valor para el negocio. Por el contrario, los profesionales de la seguridad están preocupados por los riesgos únicos y novedosos que estas soluciones pueden traer para la organización. Como tal, no sorprende el deseo de ampliar los esfuerzos de pruebas de penetración para incluir estas plataformas. Sin embargo, esto no es tan sencillo como darles a los evaluadores las direcciones IP de su pila de IA durante su próxima prueba. Una evaluación exhaustiva de estas plataformas requerirá ajustes de enfoque tanto para las organizaciones evaluadas como para los evaluadores. Gran parte de la superficie de ataque que se probará para los sistemas de IA (es decir, fallas en la nube, la red, el sistema y la capa de aplicación clásica) es bien conocida y abordada por herramientas y métodos existentes. Sin embargo, los modelos en sí pueden contener riesgos, como se detalla en las listas OWASP Top Ten para LLM (https://llmtop10.com/) y Machine Learning (https://mltop10.info/). A diferencia de las pruebas de las diez principales fallas de aplicaciones web heredadas, donde los impactos de cualquier acción adversaria fueron efímeros (es decir, inyección SQL) o fácilmente revertidos (es decir, ataque XSS almacenado), este puede no ser el caso cuando se prueban sistemas de IA. Los ataques enviados al modelo durante la prueba de penetración podrían influir potencialmente en el comportamiento del modelo a largo plazo. Si bien es común probar aplicaciones web en entornos de producción, para los modelos de IA que incorporan retroalimentación activa u otras formas de aprendizaje posterior al entrenamiento donde las pruebas podrían provocar perturbaciones en las respuestas, puede ser mejor realizar pruebas de penetración en un entorno que no sea de producción. . Se pueden utilizar mecanismos de suma de verificación para verificar que las versiones del modelo sean equivalentes. Además, varios vectores de amenazas en estas listas se ocupan específicamente del envenenamiento de los datos de entrenamiento para hacer que el modelo genere respuestas maliciosas, falsas o sesgadas. Si un ataque de este tipo tiene éxito, podría afectar potencialmente a otros usuarios simultáneos del entorno y, después de haber entrenado el modelo con dichos datos, persistiría más allá del período de prueba. Por último, existen costos en dólares importantes involucrados en la capacitación y operación de estos modelos. Tener en cuenta los costos de computación/almacenamiento/transporte en caso de que se requieran entornos de prueba o reentrenamiento como parte de la recuperación de una prueba de penetración será una nueva consideración para la mayoría. Como probadores de penetración, el marco MITRE ATT&CK ha sido durante mucho tiempo un recurso de referencia para tácticas, técnicas y procedimientos de seguridad ofensivas (TTP). Con la expansión de la superficie de ataque a plataformas de IA, MITRE ha ampliado su marco y ha creado la base de conocimientos Adversarial Threat Landscape for Artificial-Intelligence Systems, o “ATLAS” (https://atlas.mitre.org/matrices/ATLAS). ATLAS, junto con las listas OWASP, brinda a los evaluadores de penetración un excelente lugar para comenzar en términos de comprender y evaluar la superficie de ataque única que presentan los modelos de IA. Será necesario considerar el contexto del modelo tanto en las reglas de enfrentamiento bajo las cuales se realiza la prueba como al juzgar las respuestas del modelo. ¿El modelo es público o privado? ¿Producción o prueba? Si se logra el acceso a los datos de entrenamiento, ¿se podrán realizar ataques de envenenamiento? Si está permitido, ¿qué herramientas y métodos se utilizarían para generar datos de entrenamiento maliciosos y, una vez entrenados, cómo se demuestra y documenta el efecto del ataque? ¿Cómo podríamos siquiera evaluar algunas áreas de riesgo (por ejemplo, LLM09 Overreliance) como parte de una prueba técnica? Las tecnologías LLM y ML han estado evolucionando durante muchos años y solo recientemente han saltado a la vanguardia de la mayoría de las conversaciones relacionadas con la tecnología. Esto hace que parezca que las soluciones han surgido de la nada para alterar el status quo. Desde una perspectiva de seguridad, estas soluciones son disruptivas en la medida en que su adopción supera la capacidad del equipo de seguridad para implementar tantos controles técnicos como desee. Pero la industria está progresando. Hay una serie de herramientas comerciales y de código abierto para ayudar a evaluar la postura de seguridad de los modelos de IA comúnmente implementados y hay más en camino. De todos modos, podemos confiar en las pruebas de penetración para comprender las áreas de exposición que estas plataformas introducen en nuestros entornos actuales. Estas pruebas pueden requerir un poco más de preparación, transparencia y colaboración que antes para evaluar todas las áreas potenciales de riesgo que plantean los modelos de IA, especialmente a medida que se vuelven más complejos y se integran en sistemas críticos.