La superficie de ataque de la Inteligencia Artificial

Detalle pasaje de madera de la torre

Cuando introduces un nuevo sistema añades toda una panorámica de posibilidades donde un atacante puede intentar hacer algo. Cuantas más son las posibilidades, mayor es lo que llamamos la superficie de ataque.

En The AI Attack Surface Map v1.0 Daniel Miessler nos da pistas sobre todos los sitios donde un atacante podría intentar obtener alguna ventaja cuando hablamos de la inteligencia artificial.

This resource is a first thrust at a framework for thinking about how to attack AI systems.

Habla de los componentes (modelos, preguntas, índices, memoria, cadenas, agentes, …) y luego habla de algunos ejemplos de ataques posibles (inyección de preguntas, prompts, ataques al entrenamiento, …).

Interesante.

Las vulnerabilidades y su estudio para mejorar la seguridad

Catedral de Santa Cecilia. Detalle superior.

En 2022 0-day In-the-Wild Exploitation…so far Maddie Stone del proycto Google Project Zero habla de los fallos de día cero (fallos para los que todavía no hay una actualización que resuelva el problema) y cómo son.

Empieza diciendo que en junio de 2022 había 18 de estos fallos detectados y que estaban siendo utilizados por los malos, pero que la mitad de ellos eran simplemente variantes de fallos anteriores que no habían sido adecuadamente resueltos. Esto significa que podrían haberse evitado si el arreglo hubiera podido realizarse con más cuidado.

As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022. When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests.

Esto es totalmente contradictorio con la idea que tenemos a veces de que estos fallos son muy sofisticados y tecnológicamente avanzados.

When people think of 0-day exploits, they often think that these exploits are so technologically advanced that there’s no hope to catch and prevent them.

El problema es que cuando se encuentran este tipo de fallos no suele disponerse de la tranquilidad y el tiempo necesario para solucionarlos bien y lo que se hace es evitarlos de la mejor manera posible que sea rápida y luego ya no hay más tiempo ni interés en mejorar esa solución.

Haría falta encontrar la verdadera causa del problema y cómo se ha podido llegar a introducir el fallo.

Understanding the underlying vulnerability that is being exploited. Also tries to understand how that vulnerability may have been introduced.

Haría falta analizar las posibles variantes del problema que podrían afectarnos: buscar el mismo patrón en otros lugares, y hacer mejores comprobaciones.

Looking for other vulnerabilities similar to the reported vulnerability. This can involve looking for the same bug pattern elsewhere, more thoroughly auditing the component that contained the vulnerability, modifying fuzzers to understand why they didn’t find the vulnerability previously, etc.

Habría que analizar el parche (la solución) para estar seguros de que resuelve el problema de manera completa.

Analyzing the proposed (or released) patch for completeness compared to the root cause vulnerability.

Finalmente, comprender cómo se realiza el ataque y cómo se usa el fallo, para taratar de resolver no sólo el fallo, sino también mitigar la posibilidad de que se utilicen técnicas similares en otros contextos.

Understanding the primitive gained from the vulnerability and how it’s being used. While it’s generally industry-standard to patch vulnerabilities, mitigating exploit techniques doesn’t happen as frequently.

Todo ello, claro, compartido de manera transparente por los afectados, de forma que todo el mundo pueda aprender de esos problemas.

Phishing y diplomáticos: cambiando los objetivos

Diana cazadora

Se habla mucho del phishing porque todos tenemos hoy algún ejemplo que mostrar en nuestro teléfono móvil, o en nuestro correo, o en cualquiera de los sistemas de mensajería que utilizamos. No se habla tanto (o se deja un poco más difuso) del tema de los ataques dirigidos a personas o colectivos concretos.

En Diplomats Beware: Cloaked Ursa Phishing With a Twist nos hablaban de un servicio ruso especializado en diplomáticos.

Los ataques típicamente se desarrollan utilizando diferentes mecanismos que son habituales en el mundillo (no los traduzco):

  • Notes verbale (semiformal government-to-government diplomatic communications)
  • Embassies’ operating status updates
  • Schedules for diplomats
  • Invitations to embassy events

Este tipo de comunicaciones se envían habitualmente a la persona que se encarga de esos asuntos en la embajada.

These types of lures are generally sent to individuals who handle this type of embassy correspondence as part of their daily jobs. They are meant to entice targets to open the files on behalf of the organization they work for.

Pero parece que la tendencia está cambiando y ahora estarían tratando de llegar directamente a los diplomáticos, en lugar de a sus países (a los que representan).

Recently, Unit 42 researchers observed instances of Cloaked Ursa using lures focusing on the diplomats themselves more than the countries they represent.

Esto significa que tratarían de engañar a estas personas para que abran los mensajes (y se infecten) basando la comunicación en sus propios intereses y no como parte de su tarea profesional.

These unconventional lures are designed to entice the recipient to open an attachment based on their own needs and wants instead of as part of their routine duties.

Además, este tipo de mensajes serían más susceptibles de poder ser reenviados, para alcanzar a un mayor número de objetivos, dentro y fuera de la organización.

The lures themselves are broadly applicable across the diplomatic community and thus are able to be sent and forwarded to a greater number of targets. They’re also more likely to be forwarded to others inside of an organization as well as within the diplomatic community.

Los tiempos van cambiando.

Las inteligencias artificiales y los desarrolladores segun McKinsey

Calle estrecha

Mi horario de este curso rompe un poco mis rutinas de publicación. Veremos como lo arreglamos.

Interesante echarle un vistazo a Unleashing developer productivity with generative AI donde McKinsey entra en el tema de los desarrolladores y su productividad cuando tienen ayuda de alguna inteligencia artificial.

El resumen es que, efectivamente, la productividad aumentaría, aunque hay que tomar algunas precacuciones.

A McKinsey study shows that software developers can complete coding tasks up to twice as fast with generative AI. Four actions can maximize productivity and minimize risks.

Yendo más al detalle, la mejora se produciría en el desarrollo (documentación, generación de código y refactorización), pero no se vería en las tareas más complejas.

Yet, while a massive surge in productivity is possible, our research finds time savings can vary significantly based on task complexity and developer experience. Time savings shrank to less than 10 percent on tasks that developers deemed high in complexity due to, for example, their lack of familiarity with a necessary programming framework.

Y esas tareas más complejas serían todas para los desarrolladores con menos experiencia, a los que la ayuda de las IA les puede perjudicar.

A similar result was seen among developers with less than a year of experience; in some cases, tasks took junior developers 7 to 10 percent longer with the tools than without them.

Las IAs ayudan en tareas manuales y repetitivas, en la generación de una primera versión del código para hacer algo, acelerarían las actualizaciones de código ya existente, aumentarían la capacidad de los desarrolladores de enfrentarse a nuevos retos.

Sin embargo, algunas actividades necesitan de la experiencia del desarrollador, como pueden ser el examen de fallos y errores, añadir contexto sobre la organización o satisfacer requerimientos más complejos (tricky).

Las conclusiones serían: proporcionar el acceso a IAs generativas (y ayuda para usarlas) a los desarrolladores, tratar de sacar partido en casos de uso más avanzados, y planificar teniendo en cuenta los cambios en las habilidades que se podrán observar.

Además, hay que preocuparse de controlar los riesgos, teniendo en cuenta la privacidad de los datos y la seguridad de terceros, prestar atención a los cambios regulatorios, así como a los fallos de comportamiento de las IAs. También conviene estar atentos a los temas éticos y de reputación, así como las posibles vulnerabilidades de seguridad.

Una breve historia de los números aleatorios

Los dados del r5

El tema de la aleatoriedad siempre vuelve por aquí. Hoy traemos A Brief History of Random Numbers donde se incluye justamente lo que se anuncia: una historia breve de la aleatoriedad, desde los dados y su primer ejemplar conocido en el siglo 24 antes de Cristo.

The oldest known dice were discovered in a 24th century B.C. tomb in the Middle East.

Pero centrándose en los años 1940 y la necesidad de generar números aleatorios. por ejemplo, la máquina de RAND Corporation que los generaba con ayuda de un generador de pulsos.

But by the mid-1940s, the modern world demanded a lot more random numbers than dice or yarrow stalks could offer. RAND Corporation created a machine that would generate numbers using a random pulse generator.

Y, claro, los primeros generadores de números seudoaleatorios, como el de John von Neumann alrededor de 1946.

John von Neumann developed a PRNG around 1946. His idea was to start with an initial random seed value, square it, and slice out the middle digits.

Para guardar.