Ciberseguridad

Black Hat 2026: lo que defendieron las ponencias principales

Black Hat USA 2026 habló de economía, no de exploits: si atacar sale casi gratis, la única palanca que queda es que clases enteras de fallos sean imposibles, no localizables.

— Nodal Studio

El argumento de Weston, formalizado

Weston sostiene que el precio de los controles de seguridad se fija en función de una curva implícita del coste del ataque, y que esa curva se ha desplazado. Dicho de otro modo:

  • Sea c el coste marginal para el atacante de encontrar una vulnerabilidad y convertirla en un arma, y d el coste marginal para el defensor de parchear una.
  • Parchear y detectar es racional cuando c ≫ d: los atacantes encuentran pocos fallos y los defensores dan abasto.
  • El descubrimiento agéntico hunde c. La cifra de Microsoft: 3,61 $ por PoC. El hallazgo de Anthropic en OpenBSD: <20 000 $ en total. d no se ha movido: sigue haciendo falta una persona que entienda, corrija, pruebe y publique.
  • Cuando c < d, parchear más deprisa no basta para ganar. Los únicos movimientos que cambian la ecuación reducen el número de fallos que hay que parchear en lugar del tiempo de parcheo: eliminar clases de fallos (seguridad de memoria), demostrar su ausencia (verificación formal) o hacer que d se desplome hasta acercarse a c (corrección automatizada).

Las cifras de volumen del MSRC —nueve veces las de marzo, y se duplican cada seis semanas— encajan con eso. También encajan los 202 parches frente a 26 153 hallazgos del registro de Glasswing (véase Veintiséis mil hallazgos, doscientos parches): el mismo cuello de botella, visto desde el lado de quien encuentra los fallos y no desde el de quien defiende. La imagen que usó el propio Weston para describir el modelo de parchear y detectar en estas condiciones: achicar agua de un barco que se hunde con un dedal.

Argumentos económicos a favor de la seguridad de memoria cuando el coste de descubrimiento → 0

La objeción histórica a reescribir en lenguajes con seguridad de memoria ha sido el coste: la reescritura es cara, los fallos que evita son raros y parchearlos sale más barato. El argumento de Weston echa por tierra la segunda y la tercera premisas:

  • Si los fallos de seguridad de memoria se encuentran a ritmo industrial, lo de «raros» ya no se sostiene.
  • Si cada uno cuesta un ciclo de parcheo completo mientras que la PoC de un atacante cuesta 3,61 $, parchear no sale más barato.
  • El coste de la reescritura no ha cambiado; lo que ha cambiado es el coste de no reescribir.

Dos matices, con toda honestidad:

  1. La seguridad de memoria elimina una sola clase de fallos. La vulnerabilidad de validación de certificados de wolfSSL (véase Lo que Mythos encontró realmente) es un error de lógica que un lenguaje con seguridad de memoria no habría evitado. La proporción de fallos graves que son de seguridad de memoria ha sido históricamente alta (≈60–70 %) en el software de sistemas escrito en C/C++, y mucho menor en el código de aplicación.
  2. Las reescrituras introducen fallos nuevos. El periodo de transición supone un aumento neto de la superficie de ataque, y un agente que busque fallos también los encontrará.

¿Escala la verificación formal más allá de un kernel?

La verificación formal tiene un historial acreditado en componentes pequeños y de alto valor: seL4, CompCert, primitivas criptográficas verificadas (HACL*, Fiat Crypto) y partes de los planos de control de AWS y Azure. Lo que tienen en común: una especificación estable, una base de código acotada y un propietario dispuesto a financiar la ingeniería de demostraciones a un coste muchas veces superior al del propio código.

Motivos para pensar que esto está cambiando:

  • La misma capacidad agéntica que encuentra fallos puede, en principio, escribir demostraciones; varios laboratorios han mostrado modelos que generan demostraciones en Lean o Coq verificadas por máquina para propiedades no triviales. Si el coste de las demostraciones baja al mismo ritmo que el del descubrimiento, las cuentas cambian.
  • La verificación basada en propiedades y la verificación acotada (model checking, ejecución simbólica acotada) se sitúan entre los tests y la demostración completa, y se aplican de forma más amplia.

Motivos para pensar que no:

  • La mayor parte del software no tiene especificación, ni estable ni de ningún tipo. Verificar una aplicación web frente a una especificación que cambia cada semana es un problema de especificación, no de demostración.
  • Un componente verificado no es más sólido que el código no verificado que lo invoca ni que las hipótesis que la demostración hace sobre el entorno. Los agentes del caso Hugging Face no rompieron ningún componente verificado: usaron Artifactory tal y como estaba pensado.

Alcance realista a corto plazo: kernels, hipervisores, criptografía y parsers de entradas hostiles verificados y, como novedad, el código que media entre un agente y sus herramientas: el harness, es decir, el software que envuelve al modelo y le da herramientas y permisos (véase Tu framework de agentes es la superficie de ataque). Para todo lo demás: seguridad de memoria y contención.

La aportación de Shoshitaishvili

Menos citable que Weston, pero seguramente más útil para quienes trabajan sobre el terreno:

  • La habilidad se desplaza. La competencia humana escasa ya no es «saber encontrar el fallo», sino «saber diseñar el pipeline que encuentra, valida y prioriza fallos sin generar ruido». Los tres factores que nombró para distinguir los agentes que aumentan el impacto de los que aumentan el volumen: comprensión del modelo de amenazas, criterio con los datos y diseño de la evaluación.
  • Flujos de trabajo que conocen las propiedades de las vulnerabilidades. El ejemplo del kernel: incorporar el conocimiento de qué convierte un hallazgo en una escalada local de privilegios (y no en un simple cuelgue) llevó el flujo de cientos de candidatos a bastante más de mil LPE utilizables, un salto de un orden de magnitud. Orientativo, no controlado; él mismo lo dijo explícitamente.
  • La gestión responsable como factor limitante. La misma observación que en Veintiséis mil hallazgos, doscientos parches, vista desde el lado del descubrimiento: lo que fija el ritmo útil es la capacidad del sistema para absorber hallazgos, no para producirlos.

La crónica de WhoisXML API resumió bien el conjunto: en todas las ponencias principales, «la velocidad volvía una y otra vez como problema, mientras que el criterio volvía una y otra vez como parte de la respuesta».

Cifras y contexto de la conferencia

  • 121 charlas; 35 directamente relacionadas con la seguridad de la IA, el red teaming o la ofensiva asistida por LLM.
  • Sesión de apertura (martes 4 de agosto), «Cyber Power in the Age of AI»: Sean Cairncross (director nacional de Ciberseguridad), Nick Andersen (CISA, en funciones), Brett Leatherman (División Cibernética del FBI), Katherine Sutton (Departamento de Guerra). Que cuatro altos cargos estadounidenses ocuparan el escenario de apertura ya es, de por sí, una señal de dónde se marca la agenda.
  • También en el programa, y tratados en esta serie: el análisis a posteriori de OpenAI sobre Hugging Face (véase Qué pasó en Hugging Face y por qué OpenAI lo calificó de disparo de advertencia); la divulgación de Novee sobre agentes de programación y la charla sobre frameworks de agentes (véase Tu framework de agentes es la superficie de ataque); la intervención del programa CVE sobre automatización (véase Veintiséis mil hallazgos, doscientos parches); un resultado de Rowhammer contra GPU de NVIDIA; una sesión de Forrester sobre regulación de la IA (el tema de nuestro artículo del 20 de octubre).

Fuentes

Volver a la lectura rápida (2 min).

Artículos relacionados