IA generativa, reglas deterministas e intervención humana: lo que aprendí modelando amenazas con un pipeline híbrido

Cuando uno termina un máster, como el Máster en IA aplicada a la Ciberseguridad del Campus de Cibersegurdiad, lo último que quiere (yo al menos) es que el TFM quede guardado en un cajón, así que contacté con Chema Alonso a través de MyPublicInbox para publicarlo, y aquí lo tienes. Una prueba de concepto de modelado de amenazas con IA local, validación humana y núcleo determinista, como excusa para hablar de dónde conviene poner cada tipo de IA en un proceso y dónde no poner ninguna.

Figura 1: IA generativa, reglas deterministas e intervención humana.

Lo que aprendí modelando amenazas con un pipeline híbrido

Mi aporte en el proyecto está centrado en el modelado de amenazas en sistemas porque está vinculado a la gestión de riesgos, que es un poco a lo que me dedico, pero la pregunta que lo originó es más amplia y, creo, más interesante que el caso concreto: 

"¿Cuándo conviene dejar que un modelo generativo haga el trabajo, cuándo conviene dejarlo trabajar pero con validación humana, y cuándo conviene no usar IA en absoluto?"

El modelado de amenazas resultó ser un buen banco de pruebas para esa pregunta al convivir tareas de naturaleza muy distinta dentro de un mismo flujo. 

Figura 2: Cómo ser un experto en Inteligencia Artificial aplicada a Ciberseguridad.

Máster Online de Inteligencia Artificial Aplicada a la Ciberseguridad

Fecha de Comienzo - 15 de Octubre 2026 - 12 meses de duración

Algunas tareas le sientan bien a un LLM; otras lo hacen picar el anzuelo y otras, directamente, no necesitan IA. Este artículo cuenta cómo quedó repartido ese trabajo y por qué. La PoC es la anécdota y el reparto (por así decirlo) es la idea.

El problema concreto: el modelado de amenazas no escala

El modelado de amenazas identifica riesgos y propone mitigaciones en fases tempranas del diseño de sistemas, cuando la arquitectura todavía es flexible y cambiar algo cuesta poco. Suena a buena práctica obvia, y lo es. El problema es que cuesta hacerlo de forma sistemática.

Para analizar un sistema con un modelo de clasificación de amenazas como STRIDE hay que partir de un diagrama de arquitectura y convertirlo en un inventario estructurado. En otras palabras, hay que determinar qué componentes hay, de qué tipo es cada uno, cómo fluyen los datos entre ellos, qué límites de confianza se cruzan, si el transporte va cifrado o en claro, etcétera. 

Esa conversión manual del dibujo al inventario lleva tiempo, depende de experiencia especializada y, sobre todo, varía según el analista que la haga. Dos expertos pueden tipificar el mismo diagrama de forma distinta, punto a partir del cual el análisis entero diverge. Si esa traducción no se apoya en reglas explícitas, la reproducibilidad se ve comprometida.

La tentación en 2026 es obvia: que un modelo multimodal lea el diagrama y escupa el análisis completo de punta a punta. Y aquí es donde aparece la primera decisión de diseño importante.

El marco: tres decisiones, no una regla

La respuesta a "¿uso IA o no?" depende de la tarea, de "qué pasa cuando el modelo se equivoca" y de "si el problema ya se puede resolver con reglas estables". Con estos criterios las tareas de mi pipeline se acomodaron en tres enfoques distintos.

Figura 3: El mismo pipeline aplica tres criterios distintos.

IA con supervisión humana y validación (P1), reglas deterministas sin IA (P2-P3)

y la IA como capa auxiliar acotada (P4). Diagrama conceptual del autor.

• Primer enfoque - delegar en la IA, pero con supervisión y validación humana. 

Interpretar una imagen es justo lo que un modelo de visión hace bien y una regla determinista hace mal. No voy a escribir un parser para reconocer cajas, flechas y etiquetas escritas a mano alzada en cualquier diagrama posible. Para esa tarea, la IA aporta valor real. 

 

El problema no es usarla, es que un error suyo en este punto es silencioso y se propaga. Si tipifica mal un componente, todo el análisis posterior queda contaminado sin que nadie se entere. Por eso, en este enfoque, la IA trabaja pero no tiene la última palabra, y un humano valida antes de continuar.

• Segundo enfoque - no usar IA en absoluto. Una vez que tengo el inventario validado, decidir qué categorías STRIDE aplican a un `DataStore`, o qué controles mitigan la amenaza `Spoofing` sobre una entidad externa, ya es un problema resuelto.

Existe una correspondencia conocida y estable entre el tipo de activo y las amenazas que le aplican, y entre cada amenaza y sus controles. Meter un LLM ahí no agregaría capacidad, sino variabilidad donde quiero exactamente lo contrario. Para esto alcanzan reglas fijas, las cuales tienen una propiedad que ningún modelo generativo garantiza, que el mismo input produce siempre el mismo output.

• Tercer enfoque — la IA como ayudante, no como autor. Existe una tarea final donde la IA vuelve a ser útil pero de forma acotada, que es mejorar la redacción del informe y su lectura. Ahí puede sugerir texto más claro, siempre que no toque los hallazgos técnicos. Redacta, no decide. Eso sí, que no toque los datos no significa que la redacción salga siempre bien, ya que un modelo local puede introducir errores de interpretación al redactar una conclusión sin alterar un solo dato técnico. 

Por eso el enriquecimiento es opcional y siempre queda sujeto a una última lectura humana. La diferencia con P1 es de gravedad, aquí un error se queda en la prosa y un lector atento lo detecta, mientras que allí un error de tipificación se propagaba sin ser percibido en todo el análisis.

Una aclaración importante, porque es fácil sacar la conclusión equivocada. "Delegar sin control" no está mal en general. Hay tareas de bajo riesgo donde el costo de un error es trivial y revisar todo a mano no compensa. La decisión depende del riesgo, no de un principio absoluto. Lo que pasa es que en este caso de uso concreto siempre conviene controlar la extracción, porque el modelo puede equivocarse (y más todavía cuando, por privacidad, uno corre modelos locales más pequeños que los de la nube). Volveré sobre esto al final con un ejemplo que me pasó de verdad.

Y hay un requisito que atraviesa todo lo anterior: la privacidad por diseño. Un diagrama de arquitectura es información sensible. Mandarlo a una API en la nube para que lo analice significa sacarlo de la organización. Por eso, toda la inferencia de la PoC corre en local. Esa restricción es la que vuelve la pregunta del reparto todavía más aguda, porque los modelos locales pequeños son justamente los que más se benefician de esa supervisión humana con validación. 

Veamos cómo se ve esto en la práctica.

El caso de uso, paso a paso

El sistema se organiza en cuatro procesos secuenciales: extracción y validación (P1), identificación de amenazas (P2), recomendación de controles (P3) y generación del informe (P4). El punto de partida es una imagen de un diagrama de flujo de datos (DFD) de cajas y flechas. 

Figura 4: El diagrama de entrada del caso de estudio.

Nótese que el flujo hacia "Centralized Logs" va por HTTP en claro,

mientras que el resto va cifrado (ese detalle va a importar).

Para la evaluación usé un caso representativo: un frontend, dos microservicios, tres almacenes de datos y distintas configuraciones de seguridad de transporte, como se ve en el diagrama de la imagen anterior.

P1 — La IA extrae, el humano valida

Un modelo de visión local analiza el diagrama y devuelve un inventario inicial en formato JSON, es decir, componentes normalizados a una taxonomía acotada (`ExternalEntity`, `Process`, `DataStore`, `UI`, `API Gateway`, `Queue`) y flujos con sus atributos, incluido si el transporte va cifrado o claro.

Esta es la fase más frágil de todo el sistema, y conviene hablar con franqueza sobre el motivo. Los modelos generativos son probabilísticos. Pueden alucinar, devolver el JSON cortado a la mitad cuando la salida es larga, o tipificar un componente de una forma una vez y de otra a la siguiente. Buena parte del desarrollo fue destinada precisamente a domar esa variabilidad.

Por un lado, fijé la generación a `temperature = 0`, con `seed` fijo y muestreo restringido para favorecer la reproducibilidad. Por otro, evité el truncado de la respuesta y monté un mecanismo de reintento en el que, si el JSON no parsea o no valida contra el esquema, lanza un segundo intento de reparación y, si vuelve a fallar, corta con error explícito en vez de seguir con datos corruptos.

Pero ningún ajuste de parámetros elimina del todo la posibilidad de que el modelo se equivoque al interpretar el dibujo. Y aquí está lo que comentaba. En la primera extracción del caso de estudio, el modelo tipificó el `Frontend` como `Process`.

Figura 5: La extracción inicial del modelo de visión.

El `Frontend` aparece como `Process` (no como `UI`),

y el flujo de logs queda correctamente marcado como `Plain`.

El sistema todavía no permite continuar porque falta la validación.

No es un error catastrófico ni una alucinación grosera; es una interpretación razonable que, sin embargo, cambia el análisis porque un `Process` y una `UI` no tienen el mismo conjunto de categorías STRIDE aplicables. Si ese inventario pasara directo a las fases siguientes, generaría un conjunto de amenazas distinto del correcto y nadie lo notaría.

Por eso P1 termina en una instancia de validación humana obligatoria (human-in-the-loop, HITL). El sistema bloquea el acceso a las fases deterministas hasta que el analista revisa el inventario y confirma explícitamente que es correcto. La revisión se hace mediante un chat de comandos estructurados acotado a renombrar componentes y corregir sus tipos, y la confirmación se persiste en el artefacto de trabajo para dejar traza de que la validación ocurrió.

Figura 6: El inventario tras la corrección humana - el `Frontend` ahora es `UI`.

El checkbox de confirmación está marcado y recién entonces se habilita el botón

para continuar. Esa única corrección cambia las amenazas que se van a generar.

Este HITL no es un detalle de usabilidad, es la supervisión humana con validación que hace que tenga sentido usar un modelo generativo en P1. La IA aporta la velocidad de no transcribir el diagrama a mano y el humano aporta la garantía de que el análisis no arranca sobre una premisa equivocada. Ni el modelo solo, ni el humano transcribiendo todo a mano. Cada uno donde rinde.

P2 y P3 — El núcleo determinista, sin una sola línea de IA

Con el inventario validado como "contrato de entrada", arrancan las dos fases que no usan IA.

P2 recorre cada activo del inventario y, según su tipo, determina qué categorías STRIDE aplican mediante un mapeo fijo. Un `ExternalEntity` recibe `Spoofing` y `Repudiation`. Un `Process` recibe las seis categorías. Un `DataStore` recibe `Tampering`, `Repudiation` e `Information Disclosure`. Los flujos reciben `Tampering`, `Information Disclosure` y `Denial of Service`.  Por cada combinación "tipo de activo – amenaza STRIDE" aplicable se genera un escenario de riesgo, y se le estima una severidad combinando probabilidad e impacto en una escala de 1 a 5, con reglas que se apoyan en el tipo de activo y en señales del propio diagrama (por ejemplo, si un flujo va cifrado o en claro). La severidad sale de multiplicar ambos factores y se clasifica por umbrales que van de informativa a crítica.

P3 toma cada escenario priorizado y lo mapea a controles concretos mediante otra correspondencia determinista en la que cada par "tipo de activo – amenaza STRIDE" tiene asociados sus controles del catálogo local, y la severidad gradúa cuántos se recomiendan (más para los críticos, menos para los de baja severidad). Si una combinación no tiene entrada directa, hay un mecanismo de respaldo que también es determinista.

Lo importante no es el detalle de los mapeos, sino que toda esta lógica es conocida, estable y reproducible. No hay nada que "interpretar". Meter un modelo generativo aquí no resolvería ningún problema que las reglas no resuelvan ya, y a cambio reintroduciría justo la variabilidad que tanto trabajo costó sacar de P1. Para el caso de estudio, estas dos fases produjeron 44 escenarios de riesgo y 83 recomendaciones de control a partir de un catálogo de 15 controles únicos, siempre igual ante la misma entrada.

P4 — El informe, y la IA de vuelta, pero atada

La última fase consolida todo en un informe en Markdown con la arquitectura detectada, las amenazas clasificadas y el plan de mitigación. Acá la IA reaparece, pero en su tercer enfoque, como ayudante de redacción opcional. El sistema puede pedirle a un LLM local que mejore la prosa de las descripciones (impacto, mitigación, etcétera) para que el informe se lea mejor, pero con dos límites estrictos. 

Figura 7: El informe final. El inventario validado, las amenazas y los controles

quedan como tablas auditables. Los hallazgos técnicos son inmutables.

Primero, no puede alterar los hallazgos, de modo que el inventario, las amenazas y los controles que vienen del núcleo determinista permanecen intactos. Eso protege los datos, pero no la prosa, ya que el texto enriquecido es lenguaje libre y nada impide que el modelo afirme en una descripción algo que el inventario no dice. Por eso esa capa es prescindible y la versión sin enriquecer del informe sigue siendo la fuente de verdad.

Segundo, se hace amenaza por amenaza en vez de todo de una vez, porque pedirle al modelo que reescriba un bloque grande resultó frágil, y cualquier desvío de formato echaba a perder todo el lote. Si el enriquecimiento de un caso falla, el informe sale con el texto original y la ejecución no se interrumpe. Es la misma filosofía de P1 vista desde otra perspectiva. La IA puede ayudar a redactar, pero no a decidir. La fuente de verdad sigue siendo el inventario validado y los resultados deterministas.

La evidencia: dónde vive la variabilidad

Todo el argumento anterior se puede resumir en una sola tabla, que para mí es el resultado más contundente del trabajo. Ejecuté el pipeline varias veces sobre el mismo diagrama.

Figura 8: Tabla de Repetibilidad y variación controlada

(en las tres ejecuciones o runs: 7 componentes y 6 flujos).

Con la misma entrada y la misma validación humana,

el resultado es idéntico (Run 1 y Run 2). La diferencia

del Run 3 viene exclusivamente de una decisión distinta

en el punto de validación: dejar el `Frontend` como

`Process` en lugar de corregirlo a `UI`.

Las dos primeras ejecuciones son idénticas hasta el último número porque el núcleo determinista no fluctúa. La tercera difiere (47 escenarios en vez de 44, 92 recomendaciones en vez de 83) y la diferencia tiene una sola causa. En esa ejecución no se aplicó la corrección humana y el `Frontend` quedó como `Process`, que arrastra más categorías STRIDE. La variabilidad no aparece dispersa por todo el sistema, sino confinada al punto exacto donde decidí que viviera**, el HITL. 

Figura 9:  Ejecución de un proceso paso a paso

Esa es la prueba de que el reparto funciona. La parte que debe ser estable, lo es, y la que legítimamente depende del criterio humano está aislada y es trazable. En este vídeo dejo las capturas de una ejecución, una tras otra, como apoyo visual al recorrido descrito arriba.  

Una nota sincera sobre la fragilidad de los modelos

Hay un detalle que prefiero contar antes que esconder porque ilustra mejor que cualquier argumento por qué el HITL no sobra. Al preparar el material de este artículo, meses después de la evaluación original, volví a mirar las ejecuciones y el modelo de visión extraía los componentes de forma algo distinta a como lo había hecho la primera vez y yo no había tocado una sola línea de código. En ese lapso solo había habido actualizaciones de herramientas del entorno. No tengo una explicación cerrada de la causa exacta, y no voy a inventarla.

Pero el fenómeno, sea cual sea su origen, es exactamente la fragilidad que el trabajo documenta como limitación, esto es, que la salida de la fase generativa puede cambiar entre sesiones por motivos que están fuera del control del analista. Y ese es justamente el argumento a favor de no confiar ciegamente en ella. Si el comportamiento del modelo puede derivar con el tiempo aunque tu código sea idéntico, quieres un punto de control humano entre esa salida y todo lo que depende de ella. La fragilidad no es un contratiempo del proyecto, sino la mejor evidencia de por qué se diseñó así.

Qué queda fuera

Esto es una prueba de concepto, con su alcance acotado (aplicaciones web de tres capas, APIs y microservicios ligeros, partiendo de un DFD de cajas y flechas). No pretende ser una herramienta lista para producción. Aquí tienes el TFM completo publicado en Slideshare.

Figura 10:  Modelado de Amenazas Automatizado con Inteligencia Artificial,Validación Humana y Núcleo Determinista

Quedan muchas líneas abiertas por si a alguien le sirven de punto de partida, como la ampliación de la corrección humana a flujos y atributos, la validación de que la imagen de entrada sea realmente un DFD antes de procesarla, la incorporación de activos y amenazas propios de IA/LLM, o la conexión del sistema a bases de conocimiento (OWASP, NIST) vía RAG para justificar cada control con evidencia documental. El detalle de todo esto está en el TFM.

Conclusión

El modelado de amenazas funcionó aquí como el escenario idóneo para poner a prueba el concepto del reparto. Un mismo proceso puede, y a veces debe, alternar el uso de la IA generativa, es decir, emplearla en un paso, prohibirla en el siguiente y acotarla en el último. La decisión en cada etapa responde a dos preguntas pragmáticas: 

• ¿qué impacto tiene un error del modelo en esta instancia?
• ¿Puede resolverse este paso mediante reglas tradicionales?

Este pipeline situó a la IA donde aporta valor, interpretando imágenes bajo validación humana; la excluyó de donde solo hacen falta reglas conocidas, porque ahí solo agregaría ruido; y la incorporó como redactora del informe sin permitirle modificar un solo hallazgo. La tabla de repetibilidad muestra que este reparto se sostiene porque los componentes deterministas producen resultados idénticos en cada ejecución, y la única variabilidad se concentra, deliberadamente, en el punto de validación humana.

En definitiva, no he inventado nada espectacular; no obstante, la lógica de dónde poner cada cosa me parece que trasciende el caso del modelado de amenazas y por eso vale la pena insistir en ella.

Autor: Matias Daniel Ades

Figura 11: Contactar con Matias Daniel Ades

Referencias

Las referencias completas están en el TFM. Estas son las que más sostienen las ideas de este artículo.

• I. Elsharef, Z. Zeng y Z. Gu, *Facilitating Threat Modeling by Leveraging Large Language Models*, Workshop on AI Systems with Confidential Computing (AISCC), 2024.
• S. Berger et al., *Efficient and Extensible Security Analysis with Enhanced Data Flow Diagrams*, Proc. ESSoS, 2016.
• Microsoft, *Microsoft Threat Modeling Tool* (documentación técnica), 2022.
• OWASP, *Threat Dragon Documentation*.
• AWS, Accelerate threat modeling with generative AI (AWS Threat Designer), 2025.
• A. Crossman et al., *Auspex: Building Threat Modeling Tradecraft into an Artificial Intelligence-based Copilot, arXiv:2503.09586, 2025.
• E. Bandara et al., *ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications*, arXiv:2512.04785, 2025.
• R. Troncoso, *Módulo 6. Seguridad de Aplicaciones y Desarrollo Seguro*, Máster en IA Aplicada a la Ciberseguridad, ENIIT & UCAM, 2025.
• S. Bai et al., *Qwen2.5-VL Technical Report*, arXiv:2502.13923, 2025.

La Orden Ejecutiva de la Casa Blanca para promover Innovación en IA Avanzada y Seguridad para protegerse de, y con, la IA

Ayer antes de irme a la cama me topé con la publicación de la Presidential Executive Order del 2 de Junio que publicaba la Casa Blanca de Estados Unidos para "Promoting Advanced Artificial Intelligence Innovation and Security", donde se insta a los principales organismo del gobierno de los EEUU a tomar en el plazo de un mes medidas para Mejorar la Innovación en IA Avanzada y en Seguridad, algo que a todo el mundo empresarial tiene muy preocupado últimamente.

Figura 1: La Orden Ejecutiva de la Casa Blanca para promover Innovación

en IA Avanzada y Seguridad para protegerse de, y con, la IA

Ya he hablado mucho de esto, pero básicamente el Impacto de la IA en la Ciberseguridad de una organización, sea esta una Infraestructura Crítica, una Empresa o un Organismo del Gobierno, se puede catalogar en varios puntos fundamentales, que son los que ha intentando reflejar esta orden que podéis leer completamente.

Figura 2: Promoting Advanced Artificial Intelligence Innovation and Security

1.- La IA inyecta nuevos problemas de seguridad

De esto he hablado muchas veces, y hasta hemos publicado el libro de "Hacking AI", donde se tratan todos los problemas de seguridad de los que nos debemos preocupar si se utilizan sistemas con modelos de IA. Desde los BIAS, hasta las Hallucinations, pasando por el Poisoning de datos y de modelos, los problemas de Jailbreak, la vulnerabilidad a las técnicas de Prompt Injection, y el Desalineamiento de los modelos, que fuerzan los atacantes.

Figura 3:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Todos estos problemas de seguridad no deben frenar el desarrollo y el uso de la IA, pero sí que exigen desarrollo de planes de contención robustos basados en Guardarrailes, y el despliegue seguro de IA... que no es tan sencillo. 

Figura 4: Advanced AI introduce nuevas consideraciones de seguridad

En la Executive Order, en el primer punto de la misma podemos leer lo que tenéis arriba, y es que las capacidades de IA hacen a la nación más fuerte, pero también introducen nuevas consideraciones de seguridad que hay que tomar en cuenta, para lo que se insta a hacer muchas cosas.

2.- Securizar IA y usar IA para Securizar

En la Sección 2 de la Executive Order, donde se insta a todos los departamentos a tomar precauciones, toca tes puntos muy relevantes, a saber:

Figura 5: Executive Order Section 2. Security

El primero de ellos es el que todos conocemos, y es que un adversario con IA es un adversario mucho más peligroso hoy en día. Tanto en el uso de Agentes IA de Seguridad Ofensiva, como en la búsqueda y explotación de vulnerabilidades. 

Figura 6: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso,

Agentes de Seguridad Ofensiva de gran efectividad y modelos como Mythos, son ya una realidad presente que hace que las soluciones de seguridad hasta el momento se queden insuficientes.

3.- Buscar bugs con IA y Parchearlos con IA

El segundo de ellos es que hay que que utilizar herramientas de seguridad basadas en IA, es decir, el uso de Agentic SOC, uso de IA para detectar ataques e, incluso, utilizar IA para parchear sistemas, como el caso de Plexicus, que está empujando José Palanco, del que tanto os he hablado ya, que permite parchear en caliente y gestionar las vulnerabilidades de una organización de manera automática utilizando IA.

Figura 7: Plexicus parchea con IA los bugs descubiertos

El tercero de los problemas es permitir el acceso a nuevas herramientas de seguridad que puedan resolver los nuevos problemas de seguridad que introducen los sistemas que utilizan IA. Hace un par de días os hablaba del Despliegue de Agentes AI con políticas de Zero-Trust y la cantidad de nuevas herramientas que son necesarias para proteger, medianamente, un entorno de Agentic AI en una organización.

Figura 8: Búsqueda de Vulnerabilidades con IA y Parchear lo antes posible

Además, para poder hacer este trabajo, hay que realizar, como hace todo buen CISO, una nueva auditoría buscando vulnerabilidades en todos los sistemas utilizando herramientas de AI - tipo Mythos - para buscar esas vulnerabilidades, y parchearlas lo antes posible. 

4.- Auditoría de los Modelos de Frontera 

La última parte de la orden tiene que ver directamente con los Modelos de Frontera de IA que se van a utilizar con todo este proyecto, donde se insta a que se haga un Benchmarking de auditoría completo para saber cuáles son los modelos que, en función de las necesidades anteriormente descritas cumplen o no cumplen los requisitos que se les demandan.

Figura 9: Despliegues de Modelos de Frontera Seguros

Como podéis ver, habla en todo momento de Secure Frontier Model, porque son conocidas las debilidades y por tanto hay que poner en valor su robustez, y el despliegue seguro que se haga de los mismos con guardarraíles para tener entornos securizados.

Los plazos

Lo más llamativo, son los plazos. Se habla de 30 días y 60 días en todas las aciones demandadas, lo que muestra y evidencia el nivel de preocupación que el gobierno de los Estados Unidos tiene con el impacto de la IA en la Seguridad Nacional a todos los niveles. Os dejo esta charla de finales del año pasado - pre- Mythos -.

Figura 10: Inteligencia Artificial y Ciberseguridad

La pregunta que me surge es ¿haremos lo mismo en Europa pronto? ¿Lo haremos en todas las empresas en Europa pronto? Como se suele decir. "Clock is ticking".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El impacto de Mythos en concreto y la IA en general en el trabajo de los CISOs

Llevo toda mi vida profesional buscando bugs, y la búsqueda de vulnerabilidades de forma automática ha sido algo que ha existido desde que se creó Internet. Escáneres que buscan puertos para localizar sistemas conocidos, herramientas de webcrawlings o frameworks de pentesting que buscaban tipos de bugs. Esto ha sido parte del trabajo en seguridad informática, y yo he estado años haciendo eso. Para mi trabajo del Ph.D me dediqué a diseñar un algoritmo para detectar vulnerabilidades explotables a ciegas de tipo SQL, XPath o LDAP, que fue de lo que estuve trabajando esos años.

Figura 1: El impacto de Mythos en concreto y la

IA en general en el trabajo de los CISOs

Lo mismo sucedió con la FOCA, para buscar no solo metadatos el documentos públicos - que era lo único que tenía al principio - sino que se fue convirtiendo en un buscador de Well-Known Bugs explotables. Usando esas capacidades, acabamos en el entre los agradecimientos de Apple en al año 2011 y también en el año 2012.

Figura 2: Plugin de la FOCA para buscar Heartbleed

Como parte de esta visión de buscar vulnerabilidades automáticas, en ElevenPaths creamos Faast para hacer Pentesting Persistente, y buscar todas las vulnerabilidades de manera automática, de manera persistentes como fuera posible. El servicio era un SaaS que llevaba el espíritu de la FOCA y de mi trabajo de PhD que estuvo escaneando webs de clientes de manera masiva antes incluso de que apareciera la tendencia de hacer Continuos Monitoring. El objetivo, por supuesto, era reducir el tiempo de exposición de una vulnerabilidad publicada.

Figura 3: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

En la parte de explotación de las vulnerabilidades, pues lo mismo. Desde que se creó Metasploit, se busca eso. En este caso, con vulnerabilidades conocidas, pero automatizando con payloads la generación de exploits adaptados a objetivos concretos. De nuevo, con un objetivo de automatización y acelerar el proceso de explotación de bugs descubiertos. Y por supuesto, permite la creación en nuevos vulnerabilidades y nuevos payloads con sus propio lenguaje. Lo que sería The Art of Pentesting.

Y llegaron los LLMs

Por supuesto, cuando llegaron los LLM, estos comenzaron a ser parte de las herramientas de búsqueda de vulnerabilidades y de su explotación. Con la madurez, vimos como los resultados comenzaron a ser espectaculares. En el año 2024 tuvimos el paper de "LLM Agents can Autonomously Hack Websites", que sigue la filosofía de hacer un Faast, pero utilizando modelos de lenguaje de Inteligencia Artificial, lo que daba un resultados espectaculares construyendo SQL Inejction.

Figura 4: "LLM Agents can autonomouslly hack websites" 

Se publicó en el año 2024, al igual que el paper de "LLM Agents can Autonomously Exploit One-day Vulnerabilities" para dada una lista de CVEs parcheados en un software, utilizar LLMs para intentar hacer el exploit de manera automática. Todo esto antes de aquel 1 de Diciembre de 2024 cuando OpenAI publicó el primer modelo de Deep Reasoning que daría origen a la carrera de los Agentic AI.

Figura 5: LLM Agents can Autonomously Exploit One-day Vulnerabilities

Con la llegada de los modelos de Deep Reasoning, todo cambió. Comenzamos a construir Agentes IA que hicieran Red Teaming, realizando las fases de footprinting, fingerprinting, busca de vulnerabilidades y explotación de las mismas. 

Y llegaron los Deep Reaoning al mundo de la Ciberseguridad

Así, en 2025 tuvimos el paper de "On the Feasibility of Using LLMs to Execute Multistage Network Attacks" donde se crea una Agentic AI para hacer el trabajo completo de un pentester - o de un ciberatacante - automatizando todas las fases con Inteligencia Artificial. Y el resultado es brutal.

Figura 6: On the Feasibility of Using LLMs to Execute Multistage Network Attacks

Este trabajo anterior, tiene la gracia de que, sin utilizar MCPs, demuestra cómo, al crear una capa de abstracción para que el LLM pueda utilizar las herramientas sin pegarse con el CLI (Command Line Interface)  a la que llama Incalmo - la efectividad del Agentic AI para hacer ataques a organizaciones es espectacularmente satisfactoria. Así que estaba claro que el futuro de la Seguridad Ofensiva pasaba por la IA.

Figura 7: CAI: An Open, Bug Bounty-Ready Cybersecurity AI

En Abril CAI (Cybersecurity AI) compite en competiciones CTF (Capture The Flag) con equipos de hackers especializados, y consigue llegar al puesto número 20 del cuadro de ganadores, resolviendo 19/20 retos. Pero lo brutal es que quedó en esa posición porque no dio con la idaa feliz que resolvía el número 20, pero había sido el primero en resolver los 19 primeros retos.

Figura 8: Ranking de AI Agents en reto "AI vs Humans"

Esto nos deja el año pasado con un escenario donde los modelos LLM de IA se utilizan para Buscar Vulnerabilidades y Explotarlas. El mundo del Pentesting había cambiado definitivamente, y publicamos el libro de "Hacking & Pentesting con Inteligencia Artificial" donde nos centramos en cómo sacarle partido a la IA para hacer el trabajo de seguridad ofensiva que tantas veces hemos hecho sin ella.

Figura 9: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Y es que, buscar y explotar vulnerabilidades con modelos de IA se convirtió en algo bastante sencillo. El año pasado por estas fechas yo publiqué el artículo de "Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source" donde, viendo lo fácil que es buscar vulnerabilidades con modelos de Deep Reasoning, no podíamos permitirnos tener el sistema como lo teníamos hasta el momento.

Figura 10: Bug de LDAP Injection alertada en LABE

Mi preocupación es que tenemos todo el código de los proyectos OpenSource disponibles para que un modelo de IA encuentra las vulnerabilidades, y que en todo caso, deberíamos utilizar esas capacidades para acelerar la creación de partches. La plataforma Plexicus, que está empujando José Palanco, hace justo eso, generar parches con IA de manera automática.

Figura 11: Plexicus parchea con GenAI los bugs

Y esto es algo que para acelerar, se puede hacer con Neo de Sagittal.ai, que tiene en la generación de parches con IA una de sus capacidades de codificación más importantes. Usar IA para eliminar bugs que han sido descubiertos por IA.

Figura 12: Comienza a probar Neo desde hoy mismo

En Octubre del año pasado Google presentó CodeMender, que utilizando esta misma idea lo había estado usando para analizar y parchear código de proyectos OpenSorce con un Agente AI. Y si veis el proceso en el vídeo siguiente, el modelo es muy, muy, muy similar a lo que tenéis con Pléxicus.

Figura 13: Esquema de funcionamiento de CodeMender

Es decir, el camino del uso de los MM-LLM para buscar vulnerabilidades, para explotarlas, y para parchearlas no es nueva. Hace dos semanas tuvimos la investigación de "Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron" donde con poco más de 2.000 USD se conseguía un 1-Day para Google Chrome que era un 0-day para Cursor, Discord o Slack.

Figura 14: Explotación del CVE-2026-5873 con Claude Code. Horas, tokes y coste

Y es una salvajada poder hacer eso, simplemente con IA. Por supuesto, probando con el 86-DOS del año 1981 buscar los bugs y hacer los exploits en un sistema sin DEP, ASRL, y demás protección de la pila, la memoria y la llamada a funciones, es un juego de niños para la IA, como os conté.

Figura 15: PoC de Exploit para el bug 1

Estaba claro hacía donde vamos, y las capacidades de la IA, así que no nos podemos dormir. Hemos visto en estos dos años cómo ha ido cambiando todo, pero de repente, esto se complica porque...

Y entonces llegó Mythos

Pero claro, ahora llega Mythos, y aumentan la potencia en descubrimiento y explotación de vulnerabilidades, lo que obliga a repensar la estrategia de los CISOs, como se ha publicado en el paper de la Cloud Security Alliance titulado "The AI Vulnerability Storm: Building a Mythos-Ready Security Program".

Figura 16: "The AI Vulnerability Storm: Building a Mythos-Ready Security Program".

Nos encontramos con que desde el descubrimiento de una bug, hasta su explotación, si el CVE está publicado, el tiempo se reduce hasta unas 20 horas, como hemos visto en el ejemplo anterior. Unos tiempos que dejan casi sin margen de maniobra a los equipos de seguridad que tienen que parchear sistemas complejos en la grandes empresas.

Figura 17: Reducción de Time-To-Exploit año a año

Y lo peor, con las capacidades de un modelo como Mythos, el principal problema para los CISOs es que, un atacante con estas capacidades puede encontrar Bugs Complejos, crear Exploits Robustos y Funcionales, y hacerlo no como era hasta hora, donde en bugs complejos necesitaba de un humano que le iba dirigiendo, sino que se hace en 1 Single Prompt.

Figura 18: Exploits con Mythos

Y parece que esto es así, porque si vemos la última actualización de seguridad e Mozilla Firefox - que ha sido auditado por Mythos - el resultado es que han parchado más bugs que en toda su historia, y más que sumados los últimos quince meses. No está mal.

Figura 19:  Mozilla Firefox y 432 bugs parcheados tras auditarlo con Mythos

La Gestión después de llegar Mythos

Claro y... ¿cómo lo solucionamos? ¿Cómo lo gestionamos?  Esa es la gran pregunta que deben responder los CISOs ante el comité ejecutivo de la empresa, y exige una inversión en la seguridad preventiva y en la fortificación de la plataforma.

Las vulnerabilidades están en los sistemas porque aunque es verdad que el ratio de líneas de código con bugs por volumen de líneas de código se ha reducido drásticamente, el número de líneas de código que tienen las tecnologías que se usan en la empresa hoy en día ha crecido exponencialmente. Y si ahora tenemos con la IA la posibilidad e encontrarlas mucho más rápido, explotarlas en tiempo record, y poder ponerlas en juego todas a la vez, la cosa se pone complicada.

Por supuesto, anticiparse a la auditoría de las vulnerabilidades es fundamental, así que hacer a revisiones de código con LLMs - Mythos o no - cuanto antes, es fundamental. Pero luego estresar los sistemas de defensa perimetral, ya que es mucho más fácil y rápido firmar los ataques externos que parchear un sistema en producción crítico de la organización.

Figura 20: Cloudflare Edge Network

Los equipos de Cloudforce ONE y las protecciones en el WAF de Cloudflare gracias a ser la mayor plataforma en el EDGE de Internet, están detectando del orden de 232 Billones de ataque al día, con actualizaciones constantes cada hora de nuevas explotaciones de vulnerabilidades firmadas, actualizando la plataforma en todo el mundo en tiempos record por debajo del minuto. 

Con el objeto de poner lo más difícil posible a un atacante poder explotar una vulnerabilidad existente en uno de los servicios expuestos en la red de cualquier empresa en Cloudflare. Para eso, también se usa la IA para hacer el triage del tráfico de red sospechoso, y para la generación de reglas de firmado y configuraciones de seguridad en los servicios de protección perimetral.

Figura 21:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

¿Es esto suficiente? Pues a mí me gusta decir que, en medio de esta tormenta perfecta, las empresas están desplegando modelos de IA embebidos en los servicios digitales que también - surprise, surprise - traen vulnerabilidades como Prompt Injection, Jailbreak, Misalignment, Hallucinations, y si vemos los CVSS de los bugs que salen, los niveles son mucho más altos en media, lo que hace que sea otra de las preocupaciones para los CISOs. 

Figura 22: Configuración de Guardarrailes en Workers de Cloudflare

Tener Guardarraíles en el WAF, el RAG, la protección de los API Gateway, el MCP Server y el CASBI, y hacerlo sin caer en ataques de DDoS lógico por el alto costo computacional de ejecutar Guardrails robustos, como os conté en el artículo de "Cómo desplegar Inteligencia Artificial con seguridad en una empresa". Y hacerlo sin ser un blocker para la transformación al mundo de la IA de la empresa. No ser el blocker malo. 

Con todo esto, más vale que si en tu empresa quieras apostar por la IA, comiences a apoyar no solo a tu CIO y tu CTO, sino a tu CISO, que el panorama que se viene por delante es, cuanto menos, muy retador. Ya sabes que en Ciberseguridad, los ahorros pueden salir muy caros.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

27th International Information Security Conference: La Evolución de la Ciberseguridad

Sí, sé que os he dicho que estaré en el II Congreso de Hackers en Segovia el próximo 13 de Noviembre, y así será. Pero antes, por la mañana, estaré en la 27th International Information Security Conference que tendrá lugar también ese día 13 de Noviembre, en el estadio de fútbol del Atlético de Madrid. En el Metropolitano.

Figura 1: 27th International Information Security Conference.

La Evolución de la Ciberseguridad

La conferencia tiene un tamaño respetable, con una lista de ponentes espectacular, ya que en un solo día van a tener en paralelo siete tracks de discusiones, paneles, charlas, etcétera. La mía, en el Track 1 de Ciberseguridad será una charla con el gran Roberto Baratta.

Figura 2: La Evolución de la Ciberseguridad.

Chema Alonso y Roberto Baratta.

Roberto Baratta es un viejo amigo y compañero de mil una batallas. Más de las que la gente se imagina, que desde antes de que yo usara el gorro en mis charlas, ya iba con él a CaixaNova, NovaGalicia Banco, Abanca y tantas cosas, que la vida lo mismo nos junta en Vigo, que en Miami que en Madrid, que en Lisboa. Así que hemos comido, cenado, tomado refrigerios y charlado desde que yo era un jovencito, y el un profesional enorme.

Figura 3: Track 1 Cyber Security Policy & Strategy

Así que charlaremos, no sé de qué, que seguro que em pregunta cosas "a pillar", pero seguro que será entretenido y divertido para mí, que estar con el ahora también "Presidente del ISMS Forum", puede dar juego para cualquier cosas. Ya veremos.

Figura 4: Ponentes del 27th International Information

Security Conference del ISMS Forum

Pero como os he dicho, la lista de ponentes es larga, porque no es sólo un track, sino un total de siete agendas en paralelo para debatir de los temas que preocupan a los CISOs, uno de los puestos profesionales más sufridos por ser la primera línea de defensa contra los malos en el mundo digital.

Figura 5: Los 7 tracks del 27th International Information

Security Conference del ISMS Forum

Y como os he dicho, la lista de expositores, ponentes y panelistas es de lo más florida. Merece la pena que veas todos los profesionales que van a asistir. Entre todos, la experiencia en Ciberseguridad debe estar cerca a 1.000 años, ya que hay alrededor de un centenar de expositores con una experiencia media que debe rondar los 10 años... Ahí lo dejo.

Figura 6: Ponentes del 27th International Information

Security Conference del ISMS Forum

Los temas de los que se van a hablar, pues van a ser de lo más variado, y este año, además, con foco en la nueva generación de CISOs con menos de 40 años, que es algo que se está intentando impulsar desde el ISMS Forum y a mí me mola mucho la idea.

Figura 7: Temas a tratar en todos los tracks

Así que si quieres un evento en el que hacer Networking, en el que puedas conocer de primera mano en qué consiste el trabajo de los CISOs, en conocer lo que otros compañeros de profesión están haciendo, o las últimas tendencias tecnológicas en Ciberseguridad, éste es el lugar en Madrid y en España.

Figura 8: Ponentes del 27th International Information

Security Conference del ISMS Forum

Yo tendré poco tiempo, pero si quieres verme a mí, o conocer más de Cloudflare, ya sabes que puedes contactar siempre conmigo en mi buzón público, o acercarte al evento que te presentaré al resto del equipo que se está construyendo de Cloudflare en España.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)