La ciberseguridad ahora funciona como una prueba de trabajo (Proof of Work)

• El LLM ‘Mythos’ de Anthropic se desempeña con más rapidez y precisión que los humanos en simulaciones complejas de ataques de red, y su acceso está permitido solo a un grupo limitado de desarrolladores clave
• En pruebas del AI Security Institute, Mythos logró completar con éxito total 3 de 10 simulaciones de ataques a redes empresariales de 32 pasos, y su rendimiento mejora a medida que aumenta el presupuesto de tokens
• Este resultado muestra que la seguridad se está transformando en una estructura en la que para defenderse hay que invertir más tokens que el atacante, es decir, una competencia tipo prueba de trabajo
• Tras los ataques a la cadena de suministro de LiteLLM y Axios, se están expandiendo los intentos de reemplazar dependencias de código abierto con LLM o de reforzar la seguridad invirtiendo tokens
• En seguridad, más que la creatividad técnica, el factor decisivo está pasando a ser la cantidad de recursos invertidos, lo que está llevando a añadir una etapa de ‘hardening’ al proceso de desarrollo

---

La seguridad como una estructura que funciona ‘como prueba de trabajo (Proof of Work)’

• El LLM ‘Mythos’ de Anthropic ha mostrado un rendimiento sobresaliente en tareas de seguridad informática, por lo que su acceso se permite solo a creadores clave de software y no al público general
  • Mythos realiza simulaciones complejas de ataques de red mucho más rápido que los humanos
  • En las evaluaciones del AI Security Institute (AISI), también demostró una capacidad de ejecución de ciberataques un nivel por encima de modelos anteriores
• En ‘The Last Ones’, una simulación de ataque a redes empresariales de 32 pasos, Mythos logró un éxito completo en 3 de 10 intentos
  • AISI utilizó 100 millones de tokens (aprox. 12,500 dólares) por intento
  • De los modelos evaluados, solo Mythos completó todo el ataque, y su rendimiento siguió mejorando a medida que aumentaba el presupuesto de tokens
• Este resultado lleva la economía de la seguridad a una fórmula simple: “para defenderse hay que gastar más tokens que los que usa el atacante”
  • El refuerzo de la seguridad está determinado más por la cantidad de recursos invertidos que por la creatividad
  • Es una estructura similar al mecanismo de prueba de trabajo (Proof of Work) de las criptomonedas, donde gana quien invierte más recursos computacionales

Implicaciones de la nueva economía de la seguridad

• Se refuerza la importancia del software de código abierto

  • Tras los recientes ataques a la cadena de suministro de LiteLLM y Axios, en algunos sectores ha surgido la propuesta de reimplementar con agentes de IA el código de dependencias
  • Andrej Karpathy comentó que “las dependencias deben reevaluarse, y para funciones simples es mejor implementarlas directamente con LLM”
  • Si la seguridad es proporcional a la cantidad de tokens invertidos, existe la posibilidad de que las empresas sean más seguras cuanto más tokens inviertan en reforzar la seguridad de bibliotecas de código abierto
  • Sin embargo, el OSS de uso amplio tiene alto valor para los atacantes, por lo que ellos también tienen incentivos para invertir más recursos

• Añadir una etapa de ‘hardening’ al proceso de desarrollo

  • Actualmente, los desarrolladores siguen un proceso de dos etapas: desarrollo → revisión de código, usando distintos modelos en cada fase
  • Anthropic ofrece un servicio dedicado a revisión de código (Code Review), con un costo de entre 15 y 20 dólares por revisión
  • En el futuro, podría volverse común un ciclo de tres etapas: desarrollo → revisión → hardening
    1. Desarrollo: implementación de funciones e iteración basada en retroalimentación de usuarios
    2. Revisión: documentación, refactorización y mejora de la calidad
    3. Hardening: ejecución de búsqueda automática de vulnerabilidades dentro del presupuesto disponible
  • En la primera etapa, el límite es el tiempo humano; en la última, el costo actúa como factor limitante

Estructura de costos y límites de la seguridad

• Escribir código en sí sigue siendo barato, pero para asegurar la seguridad hay que comprar más tokens que el atacante
• Aunque mejore la eficiencia de inferencia de los modelos, el costo de reforzar la seguridad está determinado por el valor del ataque, por lo que es difícil lograr una reducción total de costos
• En consecuencia, la seguridad está pasando de depender de la creatividad técnica a una competencia de recursos basada en el mercado

[GN⁺]

Comentarios de Hacker News

• El acceso al codebase es la clave. El escaneo de seguridad basado en LLM de hoy es, en la práctica, poco más que un simple script de bash que recorre todos los archivos lanzando prompts de “encuéntrame vulnerabilidades”.
  Pero si el defensor controla todo el código fuente, puede operar con mucha más eficiencia. Por ejemplo, puede escanear solo los archivos modificados por PR o asignar más tokens al código relacionado con seguridad. El atacante tiene que volver a escanear cada vez, pero el defensor puede encontrar de forma preventiva todas las vulnerabilidades potenciales con un solo escaneo.
  Al final existe una asimetría de costos, y el lado defensor sale ganando en eficiencia. El atacante tiene que completar varias etapas de una cadena de exploit, mientras que el defensor solo necesita bloquear el eslabón más débil de esa cadena.

  • Hay muchos atacantes y un solo defensor, así que cuesta aceptar la idea de que las economías de escala favorecen al defensor. Asumir que no se puede acceder al código no es una buena postura de seguridad. Toda revisión de seguridad parte del supuesto de tener acceso al código fuente.
  • Aun así, este enfoque eleva el costo del desarrollo de software. Ya no sirve una actitud relajada del tipo “¿quién nos va a atacar justo a nosotros?”.
  • Como se mencionó recientemente en el pódcast Security Cryptography Whatever, me pareció interesante que ahora sea más eficiente “esperar al siguiente modelo” que mejorar el harness.
  • El problema es que este enfoque puede escalar un incidente del tipo “la PC de un desarrollador se infectó en un ataque a la cadena de suministro” hasta una situación de “filtración total del código fuente y auditoría automatizada”. Siento que un mundo así sería como un bosque oscuro para las startups.
  • El defensor tiene que reforzar todas las partes, pero el atacante solo necesita encontrar una sola vulnerabilidad.

• Me llamó la atención el AI Security Institute (AISI) mencionado en el artículo y busqué más información: era una organización integrada principalmente por gente de DeepMind y OpenAI. Casi no había personas de la industria de seguridad. Por eso, la conclusión de que “para reforzar un sistema hay que usar más tokens” suena un poco a lógica centrada en la industria de la IA. También me pregunto por qué no se mencionan alternativas como la verificación formal (formal verification). Da la impresión de que NVIDIA podría usar este argumento para vender GPUs.

  • Me pregunto quiénes serían investigadores de seguridad reconocidos que adoptarían la postura contraria. En la práctica, parece que muchos investigadores sí están de acuerdo con esta idea. El foco actual del debate está en si los LLM representan una innovación al nivel del fuzzing o algo más.
  • Como referencia, AISI es una entidad del gobierno británico y pertenece al Department for Science, Innovation and Technology (DSTI). Aun así, la forma de análisis deja algo que desear, como por ejemplo dibujar los gráficos como líneas lineales simples.

• Como dijo Tony Hoare, impacta la frase: “Hay dos formas de diseñar software: hacerlo tan simple que obviamente no tenga defectos, o hacerlo tan complicado que no haya defectos obvios”.

  • Hacerlo completamente simple no puede detener todos los ataques, pero reduce mucho la superficie de ataque. Por ejemplo, si diseñas el sistema para verificar siempre la firma antes de procesar un mensaje de red, se vuelve difícil aceptar mensajes no firmados. Muchos sistemas actuales tienen un modelo de amenazas más amplio de lo necesario.
  • Pero el criterio de “complejidad” no es el mismo para los humanos y para los LLM. Algo que parece complejo para una persona puede ser simple para un LLM. Por eso, no está claro qué tan válido será este enfoque.

• La seguridad siempre ha sido un juego de cuánto dinero está dispuesto a gastar el otro lado. La aparición de los LLM no cambió ese principio. La filosofía de Karpathy de “copiar en vez de depender de dependencias” ya existía como proverbio en Go. Y el principio de que “la seguridad no se obtiene por ocultamiento” también es algo sabido desde hace mucho.

  • Pero la oscuridad (obscurity) no es completamente inútil. Puede ayudar como una de varias capas defensivas. Lo ideal sería endurecer el sistema asumiendo transparencia total y luego añadir encima un poco de opacidad.
  • La idea de que “hay que gastar más tokens que el atacante para poder defenderse” no es nueva. En la seguridad física pasaba lo mismo. Al final, en la era de la IA también habrá que defender IA con IA. Para empezar, habría que revisar los prompts de los modelos de generación de código que usan los desarrolladores.

• En general estoy de acuerdo con el artículo. La frase “no se puntúa por ser ingenioso” es algo peligrosa. La esencia de la ciberseguridad sigue estando en los sistemas humanos. Hace falta gastar mucho tiempo de GPU, sí, pero al final lo que define el resultado es la cultura y la disciplina de seguridad de la organización. Se necesita un nivel de disciplina como el de la industria nuclear o la aviación, que normalmente solo aparece después de accidentes.
  Como contexto relacionado, este texto de hace un año describe la situación actual casi de forma profética.

• Sobre la afirmación de que “para reforzar el sistema hay que usar más tokens que el atacante”, yo antes escribí scripts personalmente para automatizar la API de Ticketmaster. Ellos reforzaron sus defensas con PerimeterX, pero lo evadí en tres días. Más recientemente, implementé algo parecido para eludir Cloudflare Turnstile de ChatGPT.
  Fueron casos que mostraron que productos de seguridad construidos con decenas de millones de dólares en realidad pueden ser inútiles.
  Post relacionado en HN

• Me pregunto si los incidentes de seguridad que detectan los LLM son realmente vulnerabilidades nuevas o simplemente una extensión del conocimiento de seguridad que ya existía. Si es lo segundo, entonces queda la duda de por qué no hemos podido encontrarlas nosotros mismos de forma sistemática.

• La razón por la que esta investigación parece Proof of Work es que AISI menciona que “mientras más tokens se usan, el rendimiento sigue aumentando”. Es decir, parte de la suposición de que la tasa de éxito del ataque es proporcional al consumo de tokens. Pero el experimento era un escenario de intrusión de red de 32 pasos, y el único modelo que lo completó fue Mythos. En una librería de código simple, el punto de rendimientos decrecientes podría llegar mucho antes.
  En proyectos open source, tanto defensores como atacantes podrían consumir más tokens, por lo que es posible que ese límite se alcance antes.

  • Mythos no tuvo éxito en todos los intentos, y la red experimental tampoco contaba con defensas reales. Aun así, no hay motivo para subestimar a la IA. Los modelos dentro de tres meses estarán en otro nivel.
  • No sé mucho de ciberseguridad, pero parece que la clave está en la tasa de aumento del costo en tokens para pasar del paso 32 al 33. Si la defensa es independiente por etapa, la probabilidad de éxito del ataque cae bruscamente como p^N.

• Al final, la pregunta es esta: ¿es más barato proteger un codebase escrito por humanos, o proteger código generado por un ejército de agentes?

• Lanzar el modelo a ciegas sobre todo el codebase, como se hace ahora, es ineficiente. Según mis pruebas, si se ajusta el modelo para explorar de forma estructurada el rastreo source-to-sink desde el origen hasta el sink, el costo baja bastante.
  Ya entramos en una era en la que los sistemas pueden visualizar el contexto completo del código y señalar con precisión los puntos de quiebre. Eso será un gran punto de inflexión para mejorar la calidad del software.