"Si tú no trabajas por tus sueños, alguien te contratará para que trabajes por los suyos”

Steve Jobs

Afiliado
Dominios3Euros

Un informático en el lado del mal

Blog personal de Chema Alonso sobre sus cosas.

  1. Cloudflare Ambassadors: Build the Internet with your people

    Llevo muchos años trabajando en las comunidades técnicas, y aprendiendo de ellas, así que tenía muchas ganas de contaros del lanzamiento de este programa de reconocimiento de Cloudflare Ambassadors, donde se premia y reconoce durante un año a esos que hacen que las comunidades tecnológicas crezcan, aumente el conocimiento de la tecnología y crezcan nuevas iniciativas gracias a ello.
    Desde ya está abierto el programa de Cloudflare Ambassadors, aunque no será el único programa ya que tenemos también el programa de Cloudflare Community Engineers que se abrirá pronto.
    Centrándonos en el primero, este programa es un reconocimiento anual que se va a entregar a los líderes de las comunidades tecnológicas que ayudan a construir un mejor Internet, que comparten sus conocimientos sobre las tecnologías de Cloudflare, o que ayudan a que el mundo OpenSource sea cada vez mejor.
    No es un programa de excelencia tecnológica - que también - sino a líderes de comunidades tecnológicas que comparten conocimiento, tecnología, experiencia, y trabajan para construir nuevas cosas, mejorar Internet, y compartir aprendizaje.
    El programa no tiene ninguna asignación económica, pero los Cloudflare Ambassadors y los Cloudflare Community Engineers van a tener apoyo de la compañía con recursos, créditos, accesos prioritarios e invitaciones a eventos, además de ser reconocidos públicamente por su trabajo y aportación a la comunidad de Builders de Internet.
    Todos aquellos que tengáis una comunidad, en forma de reuniones o eventos técnicos, canales de divulgación tecnológica, podcasts, blogs, comunidades en webs, etcétera, y queráis ser parte de este programa, podéis aplicar desde ya para ser un Cloudflare Ambassador.

    Además, Cloudflare lleva tiempo construyendo comunidades tecnológicas, así que si quieres unirte a alguna de las comunidades que ya existen de Cloudflare Community Discord y en el Cloudflare Community Forum puedes hacerlo desde aquí mismo.

     
    Figura 7: Cloudflare Developers Discord & Cloudflare Community Forum

    La verdad es que me alegra mucho que se haya lanzado este programa, así que para todos los que leéis este blog, os animo a que apliquéis y seáis parte de este selecto grupo de Cloudflare Ambassadors si os gusta ayudar a las comunidades tecnológicas a crecer y construir un mejor Internet de la mano de Cloudflare.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  2. Cómo los Agentes IA de Red Team hacen ataques de Ingeniería Social con Fake Accounts

    Esta semana, el AI Security Institute de UK, ha publicado un informe sobre un par de incidentes con Red Teaming Agentic AI, donde estos hacen alarde de su capacidad de realizar ataques complejos, con múltiples fases, y donde buscan engañar a humanos para conseguir sus ataques, como haría cualquier adversario que necesita vulnerar una debilidad en las personas que administran los sistemas, para conseguir su objetivo.
    El informe, marcado como "Security Incident INC-2026-07-28-01" fue publicado el pasado 4 de Agosto, y donde se centra en las acciones que los Red Team Agentic AI decidieron salirse a Internet y atacar proyectos y personas fuera del ámbito de la evaluación. Según cuentan en el informe, probando el comportamiento de los diferentes modelos frente a un reto concreto, el resultado fue el siguiente:

    "Ejecutamos este desafío 122 veces en varios modelos. Nuestra investigación reveló que, en 10 de esas ejecuciones, un agente de IA tomó medidas autónomas y no autorizadas en el entorno real de internet, dirigiéndose a personas u organizaciones reales. En total, catalogamos 19 acciones de este tipo. 
     
    Casi todo este comportamiento (17 acciones) provino de un solo modelo, Mythos 5 de Anthropic, mientras que 2 acciones involucraron a GPT-5.6-Sol de OpenAI con los clasificadores cibernéticos (mecanismos para prevenir el uso indebido) desactivados. 
     
    En el caso más grave, un agente intentó insertar código malicioso en un proyecto de código abierto. En un intento por lograr que el código fuera aprobado, el agente recurrió a la ingeniería social: creó identidades falsas en línea y las utilizó para presionar al mantenedor del proyecto para que aprobara el código. Un mantenedor humano lo detectó y se negó a aprobar el código malicioso."

    Las Técnicas de Ingeniería Social son bien conocidas en el mundo del Red Team, y son fundamentales en muchos de los incidentes de seguridad que sufren las organizaciones hoy en día. Correos de Spear-Phishing, Spam-Phishing, llamadas telefónicas, SMSs, e incluso representaciones con actores en los centros de trabajo.
    Uno de los Agentes IA, en este caso, intentó hacer un Supply Chain Attack, es decir, intentar atacar a un proyecto OpenSource que había identificado como parte de las piezas tecnológicas del reto que tenía que resolver.
    Para atacar a este proyecto, hizo una Pull-Request (PR) con un código malicioso, que fue detectado por uno de los humanos mantenedores del proyecto y rechazado por contener malware. Para conseguir que este código fuera aprobado, decidió conseguir la aprobación usando diferentes técnicas. 
    La primera de ellas, insertando un ataque de Prompt Injection para que cualquier Coding Agent que lo leyera ejecutar sus comandos. 
    Pero además, hizo dos cosas más. La primera, realizar un ataque de Spear-Phishing contra todos los usuarios mantenedores del código.

    La segunda, con una nueva cuenta falsa poner un comentario haciendo creer que era una persona que había revisado el código y que estaba perfecto para ser mergeado en el proyecto. Como si fuera un revisor humano colaborando con el proyecto.
    En la conversación completa se puede ver varios hechos interesantes. El primero de ellos es cómo hace el ataque y cómo se crea una nueva persona para apoyarse a sí mismo. Pero cuando el humano lo detecta, intenta presionarle para que hable con él, midiendo el tiempo que tarda el humano en contestar: "han pasado muchas horas desde que dejaste el warning".  

    Figura 8: "The Art of Pentesting" El nuevo libro de
    0xWord para formarse como pentester

    Por último, cuando, se da cuenta de que ha sido detectado, lo que hace es simular que ha sido un error genuino  normal y corriente en lugar de un ataque, e intenta cubrir sus acciones con nuevos mensajes.
    Dentro del informe, donde se analiza en detalle este incidente, también tenemos información de las trazas de razonamiento, donde podemos ver qué está pensando el Agente IA en todo momento a la hora de realizar sus acciones, y es tremendo.
    En la image anterior podemos ver cómo va encadenando las acciones y el razonamiento que va haciendo en cada momento, evaluando si realmente está en Internet o no, si el proyecto es real o es una simulación, y si debe interactuar con las personas o no.
    En la siguiente imagen, podemos ver cómo decide preparar un ataque de Prompt Injection para otro posible Coding Agent que pudiera leer la pull request con una secuencia de comandos maliciosos.
    Está clara la potencia de los modelos de IA para hacer Agentic AI en el mundo del Hacking y el Pentesting con IA, por lo que no podemos obviarlos y hay que utilizarlos masivamente. El problema, ya no es que consigan su objetivo sino cómo les decimos qué pueden hacer y qué no pueden hacer para conseguirlo.
    Esta PsicopatIA de acciones, donde no importa lo que es legitimo o no, lo que está bien o no, lo tienen que seguir haciendo las personas. De todo esto, ya os había hablado en el experimento de "Problem Solving con IA: Ético o No Ético" donde os contaba las conversaciones que tengo con mis hijas sobre la resolució de problemas....pues bien, en el mundo del Problem Solving con Agentes IA, va a ser más necesario que nunca. 

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  

    Figura 14: Contactar con Chema Alonso

    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  3. Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

    Continuando lo visto en la primera parte de esta serie, en la segunda, y en la tercera parte de este artículo terminamos en este apartado con recomendaciones de cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare.

    Figura 33: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

    Hay que decir que este artículo fue escrito antes de la Agents Week de Cloudflare, que es justo esta en la que estamos, y donde la compañía está publicando muchas actualizaciones de plataforma que deberán ser tenidas en cuenta para la aplicación de Zero Trust en Agentes IA, y que quedan al final de este artículo de hoy.

    4.7.- Gobernanza.

    El principio.

    Los controles anteriores son eficaces sólo si alguien decide cómo se configuran, quién puede modificarlos y cómo se mantienen coherentes con el tiempo. Esa es la función de la gobernanza, que CISA eleva a capacidad trasversal de toda arquitectura Zero Trust: la definición y la aplicación de las políticas, procedimientos y procesos de seguridad, dentro de cada pilar y entre ellos, para gestionar el riesgo de la organización en apoyo de los principios Zero Trust.


    Sin gobernanza, los controles se degradan. Una política de salida que cualquiera puede reescribir no protege, un secreto que nunca rota acaba filtrándose, un dato que nunca se borra se acumula como riesgo.

    En un Agente IA, la gobernanza abarca cuatro frentes: quién puede cambiar las políticas que rige el agente, cómo se gestionan y rotan sus credenciales, cuánto tiempo se conservan sus datos y cómo se controla la procedencia de los componentes que el agente carga.

    Dónde se sitúa hoy el ecosistema de Cloudflare.

    El despliegue de referencia no sólo ofrece mecanismos de gobernanza, sino que también incluye una lista de comprobación de modelo de amenazas que es, en sí misma, una guía de gobernanza. Sus puntos articulan esta dimensión.

    Sobre quién puede cambiar qué, la lista lo advierte expresamente: conviene limitar quién puede editar secretos y políticas, porque las páginas de secretos y de políticas de salida son poderosas (quien las alcanza puede reescribir el tráfico de toda la sesión). Es el principio de separación de privilegios aplicado al plano de control del Agente IA.

    Figura 35: Securing Access Policies

    Sobre las credenciales, la misma lista recomienda rotar la calve de la API según la cadencia que exija el equipo de seguridad, una operación que se realiza sin interrupción de servicio. Y la arquitectura ya favorece la buena higiene: los secretos se guardan en el almacén de claves cifrados, no en el código y se inyectan en las peticiones sin que el agente los vea, como se trató en la segmentación.

    Sobre la retención de datos, hay un punto que la gobernanza debe asumir explícitamente: el almacenamiento de objetos no expira las copias de recuperación por sí solo, de modo que definir y aplicar una política de retención (mediante reglas de ciclo de vida) es responsabilidad de quien despliega. Lo que no se gobierna, se acumula.

    Sobre la procedencia de los componentes, el modelo de seguridad del sandbox deja claro el reparto: la plataforma protege frente a ciertas amenazas, pero la implementación, la validación, la limitación de tasa y la seguridad a nivel de aplicación corresponde a quien despliega. La gobernanza es, en buena medida, asumir conscientemente esa segunda lista en lugar de suponer que la plataforma la cubre.

    Hay un frente de gobernanza que hay que atender y que a menudo se pasa por alto: las capacidades que se añaden al Agente IA (servidores MCP, skills) son superficies que también deben gobernarse. Para los servidores MCP, el ecosistema de Cloudflare One permite curar qué herramientas quedan expuestas y someter el acceso a la identidad corporativa con registro de llamadas.

    Las skills que un agente carga son, por su parte, contenido que entra en su contexto y por la premisa fundamental (el modelo no distingue una instrucción legitima de una incrustada) una skill manipulada o de procedencia no verificada es un vector de inyección y si incluye código, de cadena de suministro. Gobernar las skills (verificar su origen, cargar sólo las necesarias, no tratar su texto como instrucción privilegiada) es parte de la gobernanza del agente, no un asunto menor.

    Continuando la maduración Zero Trust.

    El primer avance es convertir la lista de comprobación en política viva: no una verificación única en el despliegue, sino una revisión periódica de quién tiene acceso y políticas, con qué cadencia se rotan las credenciales y si las reglas de retención se están aplicando. La gobernanza madura es continua, no un acto fundacional que luego se olvida.

    El segundo avance es centralizar el control donde la plataforma lo permita, de modo que las decisiones de seguridad no dependan de la configuración individual de cada agente sino de una política común que no pueda relajarse localmente. Es la traducción, al plano de la gobernanza, del principio de que la seguridad debe estar en la arquitectura por defecto y no depender de que cada la configure bien.

    Figura 37: LLM06-2025 Agencia Excesiva

    El tercer avance se extender la gobernanza a toda la cadena de procedencia: tratar los servidores MCP y las skills con el mismo rigor que cualquier dependencia crítica (inventario de lo que el Agente IA puede cargar, verificación del origen, principio de mínimo componente cargado), de modo que la superficie que se añade al agente esté tan gobernada como la que viene de fábrica. En un ecosistema donde las capacidades del agente se amplían instalando componentes de terceros, esta es la frontera de gobernanza que distingue un despliegue maduro.

    5.- Conclusión.

    Este documento es un marco de razonamiento Zero Trust, independiente y no afiliado, basado exclusivamente en la documentación oficial pública de Cloudflare y Anthropic y en marcos de referencia conocidos. En ella se destaca, en el momento de escribir estas líneas, que se trata de un software en fase temprana, por lo que sus interfaces, sus parámetros por defecto y sus capacidades pueden cambiar entre versiones.

    Este documento ha partido de una premisa: el modelo de lenguaje que da inteligencia a un Agente IA no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa. De esa premisa inicial, arranca todo lo demás. Si el agente no puede ser el guardián de propia seguridad, entonces los controles deben estar fuera de él, en la arquitectura que le rodea. Zero Trust ofrece el marco para construir esa arquitectura.

    El recorrido por las siete dimensiones de control muestra un hecho que conviene enunciar con claridad: el despliegue de Agentes IA gestionados sobre Cloudflare dispone hoy, de fábrica, de la mayoría de las piezas que una arquitectura Zero Trust necesita. 

    La identidad puede afirmarse con certificados y tokens de servicio; el acceso puede restringirse a lo mínimo mediante curaduría de herramientas, políticas de permisos y herramientas personalizadas deterministas; la segmentación de salida se aplica antes de que el agente actúe; la entrada y la salida pueden validarse en puntos bien definidos; la actividad deja rastro observable; la contención y la recuperación están diseñadas con cuidado y una lista de gobernanza que articula quién controla qué. No es un entorno al que haya que añadirle seguridad desde cero, sino que uno que ya proporciona los cimientos.

    Figura 38: The Agent Access Model en Cloudflare

    Para alcanzar un estadio óptimo solo hay que conectar y endurecer deliberadamente lo que ya existe. La adopción de la denegación por defecto frente a la confianza implícita, preferir credenciales efímeras y atribuibles a las que sean únicas y longevas. Vigilar los canales que se escapan a las políticas, convertir las listas de comprobación de gobernanza en revisiones vivas y extenderlo con el mismo rigor a las capacidades que se añaden al agente (servidores MCP, skills). Cada uno de los pasos son el movimiento desde el control disponible al control aplicado.

    El modelo de madurez del despliegue se encuentra por debajo del nivel óptimo, a pesar de contar con capacidades que no son improvisadas, sino que son de primera clase y son habilitadas por la plataforma, pero la configuración, la automatización en la respuesta a incidentes y la gobernanza continua no son impuestas por defecto. Se han de aplicar en su configuración de forma consciente por el usuario. El factor condicional no es la tecnología, es el criterio ensamblador de dicha tecnología.

    La seguridad de un agente se ha de construir partiendo de una buena base. Cloudflare proporciona, junto con Anthropic, esa base de forma óptima. El propósito de estas líneas ha sido ofrecer un criterio (los principios Zero Trust), con el que recorrer la distancia que separa un despliegue funcional a uno maduro. Continuar con la maduración no es eliminar defectos, sino ejercer la disciplina Zero Trust sobre una arquitectura que lo permite.

    6.- Nota de Actualización.
    7.- Bibliografía.
    • Anthropic. (22 de junio de 2026). Tools
    • Cloudflare. (22 de junio de 2026). Commands
    • Cloudflare. (22 de junio de 2026). Tunnels
    • Cloudflare. (22 de junio de 2026). Retries
    • Cloudflare. (22 de junio de 2026). Skills

    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  4. Computación Cuántica y Fusión Nuclear: La Receta para fabricar un "Sol en la Tierra"

    Desde hace casi un siglo, la Fusión Nuclear se presenta como el santo grial de la energía: la promesa de replicar en la Tierra la misma reacción que hace brillar al Sol, obteniendo cantidades inmensas de energía limpia, sin los residuos ni los riesgos de fusión del núcleo asociados a las centrales de fisión actuales. Pero como bien podréis imaginar, construir un ”Sol artificial” es más fácil de decir que de hacer. 
    Y no, esta vez el problema no está sólo en confinar un plasma a millones de grados con campos magnéticos. Hay un obstáculo mucho más mundano y del que se habla bastante menos: el combustible.

    Figura 2: ”Boffins bet on quantum computers, AI supers to solve fusion fuel dilemma”

    Este es precisamente el escenario que analiza el artículo de The Register titulado ”Boffinsbet on quantum computers, AI supers to solve fusion fuel dilemma”, donde se explica cómo el Departamento de Energía de EE.UU., la Cleveland Clinic e IBM han unido fuerzas para atacar este problema con una combinación de superordenadores, inteligencia artificialy ordenadores cuánticos.

    Figura 3: Oak Ridge National Lab, Cleveland Clinic, and IBM Achieve
    First-Known Computations of Fusion Materials on a Quantum Computers

    Para conseguir la fusión necesitamos dos ingredientes: Deuterio y Tritio (Tritium), dos isótopos pesados del hidrógeno. El primero no supone ningún problema, ya que es abundante y se puede extraer del agua del mar. El segundo, en cambio, es el auténtico cuello de botella: el Tritio es radiactivo, se desintegra con rapidez y prácticamente no existe de forma natural en la Tierra.

    El problema: un combustible que no existe (casi)

    Para que os hagáis una idea de la magnitud del problema: la producción mundial de Tritio es de apenas unos pocos kilos al año, mientras que una sola central de fusión de un Gigavatio (GW) consumiría en torno a medio kilo al día. Es decir, todo el Tritio del planeta mantendría funcionando un único reactor durante unas pocas semanas. 

    Figura 4: Esquema resumido del problema de relacionado
    con el ”combustible” de la fusión nuclear

    Es como querer montar una red de gasolineras en un mundo donde el petróleo se vende por gotas. La conclusión es evidente: una central de fusión comercial no puede depender de un suministro externo, sino que debe fabricar su propio combustible mientras funciona.

    La solución: una manta de sal fundida

    La propuesta más prometedora consiste en envolver el reactor con una gruesa ”manta” de una sal fundida llamada FLiBe, compuesta por Flúor, Litio y Berilio. La idea es tremendamente elegante: cuando un neutrón sale disparado de la reacción de fusión y golpea un átomo de Litio-6 de la sal, este se rompe generando Helio y... ¡Tritio fresco! El Berilio, por su parte, multiplica los neutrones sueltos para que la ”cría” de combustible sea suficiente, mientras que el flúor y el litio mantienen la mezcla líquida y estable a las temperaturas infernales del reactor.

    Figura 5: Esquema de un tokamak rodeado por la
    manta de sal fundida donde se genera el Tritio.

    Pero aquí llega la letra pequeña. Una vez generado el Tritio dentro de la sal, hay que sacarlo de ahí, y su comportamiento químico puede seguir dos caminos muy distintos:
    • Si el Tritio permanece libre en forma de gas: burbujea y sale solo de la mezcla. ¡Perfecto!
    • Si en cambio se une al flúor, forma fluoruro de Tritio: un compuesto corrosivo y muy difícil de extraer. Un auténtico quebradero de cabeza.
    Predecir cuál de los dos caminos tomará requiere modelar la química de la sal con una precisión extrema. Y aquí los métodos clásicos se quedan cortos: la técnica habitual, la Teoría del Funcional de la Densidad (DFT), puede cometer errores de hasta el 10% en la energía libre del sistema, un margen inaceptable para responder a la pregunta clave. 

    Además, hacer experimentos reales con sales fundidas es carísimo y requiere instalaciones muy especializadas. ¿Os suena este patrón?  Un problema de naturaleza cuántica que desborda a los ordenadores clásicos... ¡Es justo el tipo de tarea para el que nacieron los ordenadores cuánticos!

    Supercomputación Cuántico-Céntrica: CPUs, GPUs y QPUs trabajando en equipo.

    Como ya hemos comentado en otros artículos de este blog, los ordenadores cuánticos no vienen a sustituir a los clásicos, sino a complementarlos en problemas muy concretos. Y este trabajo es el ejemplo perfecto de esa filosofía, bautizada por IBM como Supercomputación Cuántico-Céntrica: combinar CPUs, GPUs & QPUs (procesadores cuánticos) para resolver juntos lo que ninguno puede resolver por separado.

    La estrategia que han seguido los investigadores es muy ingeniosa:
    • Fragmentación del problema: mediante una técnica llamada wave function-based embedding, el cálculo de la molécula completa se trocea en fragmentos manejables llamados ”clusters”.
    • Reparto del trabajo: los ordenadores clásicos resuelven los clusters sencillos, mientras que el ordenador cuántico se encarga de los más complejos, aquellos con mayor entrelazamiento entre átomos, utilizando un algoritmo llamado Sample-Based Quantum Diagonalization (SQD).
    Figura 6: Sample-Based Quantum Diagonalization (SQD) 
    • Reconstrucción: finalmente, los ordenadores clásicos ”recosen” todos los fragmentos para obtener la solución de la molécula completa.
    Lo curioso es que esta metodología no nació para la fusión: es la misma que utilizó laCleveland Clinic a principios de año para simular una proteína de 12.635 átomos. La ciencia es así de caprichosa, y una técnica desarrollada para biomedicina acaba siendo clave para la energía del futuro.

    Con este enfoque, el equipo calculó las energías de nueve configuraciones moleculares de FLiBe (clusters de 21 iones cada una), con y sin Tritio, siendo la primera vez que se realizan este tipo de cálculos de materiales de fusión en un ordenador cuántico. 

    Y lo más importante es que los resultados cuánticos igualaron a los métodos clásicos más exigentes. Puede parecer poco ambicioso ”sólo igualar”, pero es la prueba de concepto necesaria que demuestra que el camino cuántico funciona y está listo para escalar hacia donde los clásicos ya no llegan.

    El futuro: un bucle de IA, superordenadores y cuántica

    Este cálculo es solo una pieza de un plan mucho más ambicioso. El objetivo a largo plazo es construir un flujo de trabajo en bucle, asistido por agentes de inteligencia artificial, que funcione en tres etapas:

    1. Cribado con IA: agentes de inteligencia artificial proponen y filtran candidatas a partir de una base de datos del ”Oak Ridge National Lab” con 70 años de investigación en sales fundidas, estimando cuánto tritio generaría cada sal y si sus propiedades térmicas son adecuadas.

    2. Simulación clásica: las sales más prometedoras pasan a los superordenadores, que las modelan átomo a átomo. Como estas simulaciones son carísimas, se emplean ”sustitutos” de IA entrenados para reproducir la física a gran velocidad.

    3. Precisión cuántica: el ordenador cuántico entra donde la DFT se queda corta: la química de alta precisión que decide dónde se une el tritio. Los resultados realimentan el bucle, afinando la siguiente ronda de candidatas.

    El sueño de los investigadores es que, en el futuro, los ingenieros de fusión puedan diseñar y validar una sal fundida completamente por ordenador antes de mezclarla y calentarla en un laboratorio, ahorrando años de experimentos y cantidades ingentes de dinero.

    Figura 9: Quantum y Post-Quantum Computing para Ciberseguridad.
    Formación Especializada, Libro & Foro Online

    Eso sí, seamos honestos con las limitaciones: el problema completo requiere modelar una manta de sal de un metro de grosor con del orden de un cuatrillón de partículas, algo que seguirá fuera del alcance de la química computacional durante mucho tiempo.  El plan inmediato es más modesto pero realista: aumentar el tamaño de losclusters mucho más allá de los21 iones actuales y calcular los cientos de configuraciones que exige el problema completo, no solo nueve.


    Figura 10: Quatum Security: Tecnología Cuántica & Ciberseguridad.
    Criptográfica Cuántica y Post-Cuántica. 
    Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,
    Pablo González,Fran Ramírez,Carmen Torrano,Daniel Romero,
    Javier Álvarez,Mario Piattini,Iker Pastor,Pablo García Bringas

    En definitiva, estamos presenciando cómo tres de las tecnologías más punteras de nuestro tiempo (la Inteligencia Artificial, la Supercomputación y la Computación Cuántica) dejan de competir entre sí para unir fuerzas contra uno de los grandes problemas de ingeniería de la humanidad.  Los ordenadores cuánticos ya no solo prometen revolucionar el futuro: están ayudando a construirlo. La pregunta es inevitable: ¿será la cuántica la pieza que por fin encienda nuestro propio sol en la Tierra?
    Si te interesan estos temas, te recomiendo que te apuntes al Foro Online Público que funciona desde Septiembre del año pasado en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Securrity, así que si quieres estar informado puedes entrar libremente y suscribirte. Y si quieres más, apúntate al curso de Quantum y Post-Quantum Computing para Ciberseguridad.


    Otros artículos sobre Quantum Computing publicados:
    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  5. Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

    Continuando lo visto en la primera parte de esta serie, y en la segunda, continuamos en este apartado con cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare, comenzando ahora con la validación de los datos de entrada y los datos de salida, un tema de los más importantes.

    Figura 23: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

    En la próxima parte daremos por terminado este artículo, pero antes vamos a recorrer las fortificaciones que aún nos quedan por hacer en un modelo Zero Trust y cómo hacer éstas con Cloudflare.

    4.4.- Validación de entrada y salida de datos.

    El principio.

    La segmentación traza el mapa de con quién puede hablar el agente, este control vigila que viaja por esas conexiones. Tiene dos caras. En la entrada, el problema es la inyección. Como se estableció en la premisa, el agente no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa (un correo, una página web, el resultado de una herramienta). 

    OWASP lo recoge como el secuestro objetivo del agente (ASI01- Agent Goal Hijack), una de sus categorías primarias. En la salida, el problema es la exfiltración: que el agente, comprometido o no, emita datos que no deberían salir.

    Figura 24: ASI01- Agent Goal Hijack

    El eBook de Anthropic articula este control con claridad: la validación de entrada bloquea los intentos de manipulación en la frontera, rechazando instrucciones maliciosas antes de que el agente las procese y los controles de salida restringen lo que el agente puede producir, limitando la fuga de datos incluso cuando un atacante logra comprometer su comportamiento. La idea rectora es que el agente no puede ser su propio filtro. La validación debe ser un filtro externo, previo al procesamiento.

    Figura 25: Prompt Injection

    Hay un matiz propio del mundo agéntico que conviene no ignorar. La validación de entradas no se traslada directamente desde la seguridad tradicional. La inyección SQL, tiene patrones definidos y campos acotados, pero las entradas de un agente son libres e impredecibles, lo que hacen que sean insuficientes dichas reglas. Aun así, se puede validar contra esquemas esperados, imponer longitudes máximas y rechazar patrones conocidos antes de que la entrada llegue al agente.

    Dónde se sitúa hoy el ecosistema de Cloudflare.

    El despliegue ofrece varios puntos donde insertar esta validación, aunque conviene señalar un hecho destacable. La documentación describe los canales por donde entra el contenido externo, pero no afirma que exista un filtrado de contenido automático sobre ellos. El filtro, en buena medida, es algo que quien despliega debe construir en los puntos que la plataforma habilita.

    El correo es un ejemplo de entrada no confiable. Cada agente puede tener un buzón y cuando llega un mensaje, el agente recibe un evento que le indica que un correo ha llegado y le ofrece leerlo. Este cuerpo es contenido externo que entra en el contexto del agente: un vector de inyección indirecta. La documentación describe el mecanismo, pero no un filtrado del contenido. Ese filtrado es responsabilidad de quien despliega. Lo mismo ocurre con la navegación web: recuperar una página es ingerir contenido no controlado.

    Figura 26: Agent Email en Cloudflare

    El punto de inserción natural para la validación es la herramienta personalizada, y a presentada en 4.2. Su esquema de entrada, declarado y válido, rechaza llamadas con forma inesperada antes de ejecutar nada. Su cuerpo es el lugar donde la propia documentación sugiere validar entradas, Redactar información sensible o comprobar autorización antes de hacer el trabajo. Esa redacción de información sensible es, precisamente, en control de salida al filtrar lo que vuelve al agente o sale hacia un servicio.

    Para la ejecución de comandos, el Sandbox SDK ofrece una mitigación concreta contra la inyección de shell: pasar los datos por la entrada estándar en lugar de interpolarlos en el comando, lo que permite procesar entrada de usuario sin riesgo de inyección. La documentación lo ilustra con un caso donde una cadena maliciosa, pasada por entrada estándar, resulta inofensiva, mientras que incrustada en el comando sería peligrosa. El propio modelo de responsabilidad del Sandbox sitúa además la validación y el saneamiento de entradas explícitamente del lado de quien despliega, no de la plataforma (Cloudflare, 2026u).

    Figura 27: Cloudflare Commands en Sandbox

    Y en la dimensión de salida, el ecosistema de Cloudflare One aporta control sobre el canal de los servidores MCP, por el que el agente invoca herramientas externas. El portal de servidores MCP permite curar qué herramientas quedan expuestas (desactivando herramientas individuales o derivando a una lista de permitidos para mostrar solo un subconjunto) y somete el acceso a cada servidor a la identidad corporativa, imponiendo a qué servidores accede cada quién con independencia de las políticas del propio servidor. Además, registra las peticiones individuales realizadas con las herramientas del portal. Curar el canal y auditarlo es, en este contexto, una forma de control sobre lo que el agente puede llegar a enviar a través de él.

    Continuando la maduración Zero Trust.

    El primer avance de maduración consiste en reforzar progresivamente el filtro de entrada. Un punto de partida razonable es validar formatos contra esquemas esperados, imponer longitudes máximas y rechazar entradas manifiestamente malformadas. Sobre esa base, incorporar detección de patrones de ataque conocidos y filtrado de cargas codificadas y en los entornos más exigentes, delimitar de forma explícita el contenido no confiable para que el modelo lo trate como inseguro (la técnica despotlighting). EleBook de Anthropic describe esta progresión y aporta criterios concretos para cada estadio  de forma coherente con el principioZero Trust de no confiar en la entrada y filtrarla en la frontera.

    El segundo avance es tratar todo el canal por el que entra el contenido externo (correo, web, resultado de herramientas) como no confiable por defecto, e interponer en cada uno un punto de validación antes de que su contenido alcance el contexto del agente. La forma natural de lograrlo en este despliegue es encapsular esos canales tras herramientas personalizadas que validen y cuando proceda, saneen o delimiten el contenido, en lugar de dejar que entre directamente.
    El tercer avance es simétrico, en la salida: definir qué clases de datos no deben abandonar nunca el entorno y materializar esa decisión en los puntos disponibles (la redacción dentro de las herramientas personalizadas y la curaduría y auditoria del canal MCP), de modo que la exfiltración quede dificultada incluso si el agente es manipulado para intentarla.

    4.5.- Observabilidad y comportamiento.

    El principio.

    Los controles anteriores deciden que puede hacer el agente, la observabilidad nos permite saber está ocurriendo realmente en el sistema. Es un requisito indispensable por el cual pueden verificarse, ajustarse y defenderse los demás controles, ante un incidente. 

    Por este motivo CISA eleva la visibilidad y analítica a la categoría de capacidad trasversal de toda arquitectura Zero Trust. En la práctica, la visibilidad consiste en recopilar y observar la telemetría, los registros y los eventos que generan el entorno. El análisis de esta información es lo que verdaderamente permite actualizar las políticas de acceso, agilizar la respuesta a incidentes y construir un perfil de riesgo para tomar medidas proactivas antes de que el ataque se materialice. NIST, siguiendo la misma línea, sitúa la monitorización continua entre los fundamentos de la arquitectura Zero Trust.

    Figura 29: Capacidades Transversales de CISA para Zero Trust

    En un agente, la obsevabilidad tiene una exigencia añadida, no basta con registrar el resultado de una acción, hay que poder reconstruir la cadena de acciones que llevó a ella (que entrada recibió, qué herramienta invocó, con qué argumentos, con qué resultado). Sólo así puede distinguirse un comportamiento legítimo de uno inducido por una inyección y solo así atribuirse una acción a quien la lanzó.

    Dónde se sitúa hoy el ecosistema Cloudflare.

    El despliegue es en esta dimensión, notablemente sólido, con un posible punto ciego importante que ya se ha señalado.

    La sesión es, por diseño, un registro. Como se describió en la sección 3, el historial de eventos de cada sesión persiste y se puede recuperar íntegro: la conversación, los turnos, los resultados de herramientas. La sesión no es solo ejecución, es también su propia bitácora.

    Sobre el acceso al panel, cuando se coloca Cloudflare Access delante, se obtiene un registro de auditoria sin escribir código: Access registra cada petición autenticada, lo que resulta útil cuando una sesión hace algo sorprendente y se quiere saber quién la lanzó. La identidad de quien opera queda ligada a lo que la sesión hace.

    Figura 30: Securing Access

    Sobre el comportamiento interno del agente, los dos backends ofrecen vías distintas. En MicroVM existe un terminal en vivo a través del panel, que permite ver exactamente lo que el agente vio. En Isolate, que no tiene shell, la observabilidad se obtiene de los registros de Workers, donde el despachador de herramientas registra cada nombre de herramienta y su resultado. En ambos casos, la actividad del agente deja rastro consultable.

    El punto ciego es el ya conocido y aquí cobra todo el sentido: las herramientas del servidor de Anthropic se ejecutan fuera de la cuenta de Cloudflare y no dejan ninguna traza(ni registro, ni auditoría). Lo que no se ve no se puede vigilar. Por eso el ecosistema ofrece variantes equivalentes de navegación que sí recorren en la cuenta propia y cuyas peticiones son observables en los registros de la cuenta. La diferencia entre una y otra opción es, exactamente, la diferencia entre tener y no tener observabilidad.

    Continuando la maduración Zero Trust.

    El primer avance es centralizar y correlacionar lo que hoy está disponible pero disperso: el historial de eventos de sesión, los registros de acceso de quien la lanzó y los registros del despachador de herramientas. Reunidos y vinculados por el identificador de sesión, permiten reconstruir la cadena completa (quién lanzó qué sesión, qué hizo el agente, con qué herramientas y resultados) que la investigación de un incidente requiere.

    El segundo avance es eliminar los puntos ciegos por decisión de diseño: preferir, para toda navegación web, las variantes observables que corren en la cuenta propia y mantener desactivadas las que no dejan traza. Una observabilidad con huecos conocidos es una observabilidad que un atacante usará precisamente por esos huecos.

    El tercer avance lleva la observabilidad del registro pasivo a la detección activa. Disponer de los registros es la base; estadio maduro es analizarlos para construir el perfil de riesgo del que habla la CISA (establecer que comportamiento es normal para un agente y alertar sobre desviaciones, como una herramienta que nunca se invoca, de pronto se le hace una llamada o un volumen de salida anómalo) de modo que la observabilidad no sólo explique los incidentes después, sino que ayude a detectarlos mientras ocurren.

    4.6.- Contención y recuperación.

    El principio.

    Zero Trust asume que las defensas pueden fallar y que un sujeto puede acabar comprometido. Por eso exige, además de prevenir, contener el daño cuando ocurre y poder volver a un estado bueno conocido. La contención busca limitar el radio de alcance (blast radius), es decir que un agente comprometido afecte lo mínimo. Y la recuperación, restaura la operación sin arrastrar el estado corrupto.

    Figura 31: Blast Radius

    La taxonomía OWASP para aplicaciones agénticas recoge expresamente estos mecanismos: interruptores de parada, límites de radio de alcance, aislamiento entre el planificador y el ejecutor y contención en tiempo de ejecución, como defensas frente a la propagación de errores y el abuso entre agentes. En un agente, esto se concreta en tres capacidades: poder detenerlo de inmediato cuando se detecta un comportamiento anómalo, acotar por diseño lo que su compromiso pueda alcanzar y restaurar su entorno a un punto limpio si propagar aquello que hubiera quedado corrompido.

    Dónde se sitúa hoy el ecosistema Cloudflare.

    El despliegue ofrece una base de contención y recuperación que cubre las tres capacidades, con un matiz en la resiliencia de la cola de trabajo.
    • El aislamiento como contención ya se trató: cada sandbox corre en su propia máquina virtual, de modo que el compromiso de uno no alcanza a los demás y la segmentación de salida acota con quién puede comunicarse un agente comprometido. La contención del radio de alcance no es, por tanto, un añadido. Está en la arquitectura.
    • La recuperación está cuidadosamente diseñada: El directorio de trabajo de cada sesión MicroVM se preserva mediante copias a almacenamiento de objetivos, que se restauran al reanudar. Isolate persiste su estado de forma transparente. Y el diseño es defensivo en un punto importante: nunca se restuaran sobre un contenedor en ejecución y si una restauración falla, el sistema registra el fallo y arranca con un directorio limpio en lugar de bloquearse. Es una recuperación que prioriza no propagar el estado dañado.
    El matiz que señalar está en la resiliencia de la cola de trabajo del entorno de ejecución. La documentación del sistema de colas advierte de que no existe una cola de mensajes fallidos. Una tarea que falla se elimina y se recomienda implementar la persistencia propia, los reintentos bloquean la cabeza de la cola y no hay un cortacircuitos.

    Continuando con la maduración Zero Trust

    El primer avance es convertir la parada manual en respuesta automática: vincular la detección de comportamiento anómalo (del control de observabilidad) con la función de detención, de modo que una desviación grave no dependa de que un humano esté mirando. Es el interruptor de parada OWASP llevado a su forma efectiva, disparado por una señal, no solo por una persona.

    El segundo avance es endurecer el radio de alcance combinando los controles ya descritos: segmentación de salida estricta, identidades de alcance acotado e inyección de credenciales que el agente no custodia. Cada uno reduce lo que un compromiso puede tocar; juntos, materializan el límite del radio de alcance que pide la taxonomía agéntica.
    El tercer avance atañe a la resiliencia de las tareas y a la retención de los datos de recuperación. Por un lado, implementar la persistencia propia de las tareas críticas que la cola no garantiza, de modo que un fallo no las pierda en silencio. Por otro, gobernar la retención de las copias automáticamente, así que definir y aplicar una política de retención es responsabilidad de quien despliega, un punto que enlaza directamente con la gobernanza de datos de la sección siguiente.


    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  6. Digi Americas LATAM CISO Summit 2026: 11 de Septiembre estaré en México

    Hace mucho, mucho, mucho tiempo que no doy una conferencia en México, y la verdad es que ya tenía ganas de regresar. Y será en Septiembre, ya que estaré como ponente en el Digi Americas LATAM CISO Summit 2026, que tiene lugar en Cancún del 10 al 12 de Septiembre.
    La lista de ponentes es espectacular, con Adolfo Fabrega, Alberto Yépez, Alexandra Rose, Altagracia Gomez, André Molina, Ariel Waissbein, H.E. Ivan Duque, H.E. Toomas Hendrik Ilves, Heidy Rocha, Julissa Cruz Abreu como ponentes destacados de una enorme lista.

    Mi charla, en concreto, será el día 11 de Septiembre a las 09:50, para hablar del mundo del Hacking y la Inteligencia Artificial, que ya sabéis que es un tema que me tiene absorbido los últimos años, así que será una charla sobre los temas que me apasionan.
    Pero ya que estoy allí, tendré reuniones, me haré las fotos que pueda, y lo mismo me llevaré algunos de mis libros de Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignmen por si alguien los quiere tener, ya que voy a estar por allí. 
    Así que, si estás por México, o por la región, y estabas pensando en ir al Digi Americas LATAM CISO Summit 2026, que sepas que yo estaré por allí. Y si quieres que nos reunamos, que te lleve o un libro, o solo verme, puedes contactar conmigo para ello.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  7. El Agente AI Musical que trae los Conciertos de los Músicos en MyPublicInbox

    Desde comienzo de este año MyPublicInbox está transformándose con Agenteic AI Ops, para incrementar la experiencia de uso, automatizar tareas, potenciar más a los perfiles públicos y dotar cada vez de más capacidades a todos los usuarios. Hace poco os hablaba de MyPulicGPT para que los perfiles públicos puedan conocer su huella digital en los buscadores de IA, y del Canal eMail de MyPublicInbox, y hoy os hablo de nuestro Agente IA Musical, que se encarga de mantener actualizada la agenda de conciertos de todos los músicos de la plataforma.
    Como ya sabéis, a principio de año os anunciamos que MyPublicInbox había adquirido la plataforma LinkMusic, con el objetivo de incrementar los servicios en nuestro vertical de música. Hoy, gracias a nuestro Agente AI musical, estamos actualizado los miles de conciertos que dan los músicos de MyPublicInbox.
    Los podéis ver en el perfil de cada usuario, como podéis ver con David Summers y su gira de Hombres G, en la parte derecha de su buzón púbico, pero con una sección para poder ver todos los que ya están publicados.
    Por ejemplo, mis queridos Despistaos, que comienzan su pedazo de Gira de "Un millón de Madrugadas", tienen ya también publicadas todas sus fechas en le buzón del grupo.
    Pero también se irá publicando en cada uno de los miembros de la banda, como en este caso el gran Krespo, gracias a que nuestro Agente IA Musical está buscando cómo potenciar al máximo los trabajos de los perfiles púbicos.
    Y para todos los demás, pues una forma de que no se te escape nada. De hecho, si sigues a uno de los músicos, la plataforma te enviará un mensaje interno para avisarte cuándo se ha producido la publicación de nuevos conciertos, para que no se te escape nada de lo que hacen los músicos de MyPublicInbox.

    ¡Saludos Malignos!

    Autor: Chema Alonso(Contactar con Chema Alonso)  


    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  8. La ética como “Safety Net”: Por qué la IA responsable acelera la innovación (y no la frena)

    Cuando se habla de ética y regulación de la inteligencia artificial, la reacción más habitual -también entre gente muy sensata- es pensar en un freno. Un comité más, un formulario más, un abogado más entre la idea y el producto. Yo llevo defendiendo justo lo contrario desde hace años, y con RAIGHT.ai, la startup que he cofundado junto a Miguel Ángel Liébanas, Laura González, Ricardo Palomo e Idoia Salazar, hemos intentado demostrarlo con una plataforma, no solo con argumentos.

    Figura 1: La ética como “Safety Net” - Por qué la IA
    responsable acelera la innovación (y no la frena)

    La tesis es sencilla: la ética by design no es un obstáculo para innovar rápido, es la condición para poder hacerlo con seguridad. Y como en tantas cosas de la vida, conviene explicarlo con sobriedad holandesa, sin caer ni en el alarmismo (“la IA nos va a destruir”) ni en la ingenuidad (“ya se regulará solo”).

    El problema: demasiados principios, poca práctica

    Desde 2018 llevamos trabajando en IA ética y responsable, primero desde OdiseIA, el observatorio que fundamos en 2019 y que hoy es referencia internacional en la materia. En todo este tiempo hemos visto proliferar recomendaciones —UNESCO, OCDE, Consejo de Europa— y regulaciones, con el AI Act europeo a la cabeza.

    Todas apuntan en buena dirección, pero -aparte delAI Act- comparten un mismo defecto: se quedan en principios de alto nivel (“evitar el sesgo”, “garantizar la transparencia”) sin decir cómo hacerlo en un caso de uso concreto.
    Es la diferencia entre decirle a un desarrollador “cuidado con el sesgo” y decirle “este sistema de selección de personal puede discriminar a mujeres en roles técnicos por el histórico de contrataciones; aquí tienes el requisito concreto para mitigarlo”. La primera frase genera ansiedad. La segunda, acción.

    La solución: gobernanza automatizada, con supervisión humana

    RAIGHT.ai nació en el verano de 2024 para resolver justo ese salto entre la teoría y la práctica. La plataforma parte de un inventario propio de más de 800 riesgos éticos de IA, construidos analizando con IA generativa más de 15.000incidentes reales recogidos por repositorios como el AI Incident Monitor de la OCDE, el AI Risk Repository del MIT o AIAAIC (AI, Algorithmic and Automation Incidents and Controversies). 

    A cada riesgo le hemos asociado, también con ayuda de IA generativa y revisión humana posterior, los requisitos de mitigación concretos y accionables. (Ver Benjamins et al., “Responsible AI: from theory to practice”, capítulo del próximo Handbook of AI Ethics de Springer.) El flujo, en la práctica, es este:
    • Registro automático del caso de uso: Se sube documentación del sistema de IA (una ficha técnica, una descripción funcional) y la plataforma extrae automáticamente los datos relevantes.
    • Detección inteligente de riesgos: Con un clic, la plataforma compara el caso de uso contra el inventario y propone los riesgos aplicables. El equipo humano tiene que confirmarlos explícitamente; nada se acepta “a ciegas”, precisamente para evitar el riesgo de sobre-confianza en el propio sistema.
    • Lista de requisitos accionable: Para cada riesgo confirmado, aparecen los requisitos de mitigación correspondientes, documentados, asignados y trazables hasta su resolución. 
    Lo hemos probado, entre otros, con COMPAS, el conocido sistema estadounidense de evaluación de riesgo de reincidencia usado en el ámbito judicial: la plataforma identifica sin dificultad los riesgos de discriminación algorítmica que ya denunciaron periodistas e investigadores hace años, y propone las salvaguardas que deberían haberse aplicado desde el diseño.


    Por qué esto es bueno para el negocio (y no solo para la conciencia)

    Aquí es donde quiero insistir, porque es el mensaje que peor se entiende: la IA responsable no compite con la innovación, la habilita. Hay al menos tres razones de peso: 
    • Innovación más rápida y barata: Cuando los riesgos se detectan al principio del diseño, corregirlos cuesta una fracción de lo que cuesta hacerlo después del lanzamiento, con la reputación ya dañada. Un equipo que sabe que tiene esta “red de seguridad” puede permitirse experimentar más, no menos.
    • Confianza de clientes y talento: El 93% de los consumidores valora la responsabilidad social de las empresas que eligen, y el 64% del talento digital prioriza estos valores a la hora de elegir dónde trabajar. En un mercado donde captar y retener talento técnico es una batalla constante, no es un dato menor.
    • Atractivo para inversores: Cada vez más fondos incorporan criterios ESG a sus decisiones, y la IA ética entra de lleno en la “S” de social. Hay ya rankings, como el de Ranking Digital Rights o el modelo de madurez de la GSMA, que puntúan explícitamente la gobernanza responsable de la IA.
    Y hay un cuarto argumento, más pragmático: bajo el AI Act, sólo los sistemas de riesgo alto o limitado tienen obligaciones específicas. Con una plataforma que registra todos los casos de uso y su perfil de riesgo, una organización puede ir más allá del mínimo regulatorio con un esfuerzo adicional pequeño, y convertir el cumplimiento en un activo de confianza en lugar de en un ejercicio defensivo.

    “Human in the loop”

    Lo que proponemos con RAIGHT.ai no es sustituir el criterio humano por un algoritmo que dice “sí” o “no”. Es automatizar lo automatizable: la búsqueda en un inventario de miles de riesgos conocidos, la generación de la primera versión de los requisitos, para que las personas dediquemos el tiempo a lo que de verdad requiere criterio: decidir, priorizar, y responder por esas decisiones. La supervisión humana no es un trámite en nuestra metodología, es una pieza de diseño.

    Figura 6: Contacta con nosotros para una Demo de RAIGHT

    Resumiendo una cita famosa de Johan Cruyff, “jugar bien no es dar mil pases, es dar el pase justo en el momento justo”. La IA responsable no consiste en poner mil controles, sino en poner los controles justos, en el momento justo del ciclo de vida del sistema, es decir, al principio, cuando aún se puede diseñar bien, no al final, cuando solo queda apagar fuegos. 

    Nota de transparencia: este artículo ha sido redactado con la asistencia de herramientas de IA generativa a partir de material propio (paper académico, presentación corporativa y contenidos de raight.ai), con revisión y edición humana final.

    Autor: Dr. Richard Benjamins, CEO RAIGHT.ai

    Contactar con el Dr. Richard Benjamins
    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  9. Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

    El próximo mes de Octubre de 2026 da comienzo el Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity que se realizará en sesiones los jueves y viernes por la tarde y los sábados por la mañana online, hasta el próximo mes de Marzo de 2027, aprendiendo con profesionales que trabajan en ciberseguridad.
    Este bootcmap online cuenta con más de 100 horas de sesiones online en directo, con acceso a retos de ciberseguridad, un curso de scripting con Bash, un curso de scripting con Python y un curso de Metasploit. Además, el bootcamp, que es de nivel intermedio, tiene cuenta con una sesión de orientación  para los asistentes, además de tener 1 año de tutorización y derecho a examen. 

    Además, se entregan los libros de "Hacking IA" y "The Art of Pentesting" para todos los alumnos, junto con 2.000 Tempos de MyPublicInbox para contactar con los expertos de cibeseguridad de la plataforma.
    El bootcamp está pensado para recién licenciados en Ingeniería Informática o personas que deseen enfocar su carrera profesional al hacking ético y el pentensting. También para perfiles junior que estén ya trabajando pero que requieran de un nivel de especialización mayor; perfiles profesionales con experiencia en algún ámbito de la ingeniería, programación o administración de sistemas y que deseen dar un cambio a su carrera profesional adentrándose en el ámbito del hacking ético, y para miembros de las Fuerzas y Cuerpos de Seguridad del Estado relacionados con el ámbito de la seguridad de la información y la ciberdelincuencia.

    Figura 5: "The Art of Pentesting" El libro de Pablo González en
    0xWord para formarse como pentester

    La evaluación final de los alumnos se realizará mediante un Trabajo de Fin de Bootcamp que habrá que presentar y defender. Una vez el alumno haya completado el Bootcamp, realizado el respectivo proceso de evaluación y superado la calificación mínima de corte, se le remitirá un certificado digital del curso con sus datos. Tienes aquí toda la información del Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity


    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

  10. MyThreatIntel: Plataforma de Threat Intelligence desde la experiencia en DFIR y Respuesta a Incidentes

    La inteligencia sobre amenazas se ha convertido en una pieza fundamental dentro de la ciberseguridad moderna. Sin embargo, el principal problema al que se enfrentan hoy los analistas no es la falta de información. Ocurre, de hecho, todo lo contrario: existen demasiadas fuentes, demasiados datos y demasiados contextos dispersos.

    Figura 1: MyThreatIntel - Plataforma de Threat Intelligence desde
    la experiencia en DFIR y Respuesta a Incidentes

    Durante una investigación real, ya sea en un entorno SOC, en un servicio de DFIR, en tareas de Threat Hunting o en un proceso de Cyber Threat Intelligence, el analista necesita responder con rapidez a preguntas muy concretas: qué actor está detrás de una campaña, qué infraestructura mantiene activa, si una organización ya ha sido publicada en un portal de ransomware, si la extorsión sigue en negociación, si ya ha habido filtración, qué vulnerabilidades se están publicando, qué indicadores se conocen o qué artefactos de malware estánrelacionados.

    Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades
     en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

    El problema es que esa información rara vez se encuentra en un único lugar. Normalmente está repartida entre Data Leak Sites, bases de datos de vulnerabilidades, repositorios de IoCs, servicios Onion, mercados de la Darknet, fuentes OSINT, catálogos de malware y repositorios de filtraciones. El resultado es un coste operativo claro: una parte muy importante del tiempo no se dedica a analizar, sino a buscar, ordenar y contextualizar. De esa necesidad nace MyThreatIntel, una plataforma pensada para reducir esa fricción y ayudar a que la inteligencia llegue al analista de una manera más estructurada, más rápida y más útil.

    Una plataforma orientada al contexto

    MyThreatIntel no se diseñó como un simple agregador de datos ni como un panel más de ciberseguridad. La idea era más ambiciosa: construir una plataforma capaz de obtener información desde fuentes heterogéneas, normalizarla, enriquecerla y ponerla en contexto. Fue precisamente esa necesidad operativa la que nos llevó a Javier Martí Sanz y a mí - Manuel Martínez Casasola -  a desarrollar MyThreatIntel. Tras trabajar en investigaciones forenses, respuesta a incidentes y servicios de inteligencia, la conclusión era clara: los datos existían, pero el esfuerzo necesario para convertirlos en conocimiento útil seguía siendo demasiado alto.

    Figura 3: Contactar con Javier Marti Sanz

    Actualmente, MyThreatIntel es una herramienta de Secure&IT, desarrollada para reforzar sus capacidades de Cyber Threat Intelligence y servir de apoyo en tareas de monitorización, análisis, investigación y respuesta ante incidentes. La plataforma permite centralizar y relacionar información que, de otro modo, tendría que localizarse y analizarse de forma independiente en múltiples fuentes.

    Por eso, el valor de MyThreatIntel no reside únicamente en centralizar información, sino en relacionarla. Una víctima publicada por un grupo de ransomware puede vincularse con el actor responsable, su infraestructura Onion, el estado de la negociación, las filtraciones asociadas, posibles IoCs relacionados y, en determinados escenarios, incluso con las vulnerabilidades o artefactos de malware observados en una campaña.

    Ese enfoque convierte la plataforma en algo más que una colección de secciones independientes: la convierte en un entorno de trabajo orientado a la investigación y al contexto.

    Ransomware: visibilidad directa del ecosistema de extorsión

    Uno de los pilares de la plataforma es la monitorización continua del ecosistema ransomware. MyThreatIntel sigue de forma directa los portales utilizados por los actores para publicar nuevas víctimas, manteniendo un histórico de actividad que permite observar tendencias, distribución geográfica, sectores afectados y volumen por actor.

    Figura 4: Dashboard de ransomware con víctimas registradas,
    distribución geográfica y actividad por actor.

    Esto no solo facilita saber quién está publicando más víctimas en un momento dado, sino también analizar la evolución de los grupos y entender mejor el comportamiento del ecosistema criminal. Tener esa visión agregada, pero también aterrizada en cada incidente, aporta un enorme valor para analistas CTI, equipos CSIRT y servicios de respuesta a incidentes.

    Figura 5: Registro de incidentes en crudo, con filtrado
    por fechas, países, actores y sectores.

    Además, la plataforma permite consultar el “registro en crudo” de incidentes, filtrando por fechas, países, actores o sectores. Ese enfoque combina visualización ejecutiva y detalle técnico, algo especialmente útil cuando se necesita pasar rápidamente de una visión global a un caso concreto.

    Negociaciones: seguir la extorsión más allá de la publicación

    Si hay una capacidad especialmente diferencial dentro de MyThreatIntel, esa es la monitorización de negociaciones. La mayoría de soluciones se detienen en la publicación de la víctima dentro del Data Leak Site. Sin embargo, desde el punto de vista de la investigación, ese suele ser solo el comienzo de la historia. A partir de ahí empieza una fase crítica: el proceso de extorsión.

    MyThreatIntel monitoriza directamente, desde los portales de los propios actores, el estado de esas negociaciones: si siguen activas, si ha habido filtración parcial o completa, si la víctima ha desaparecido del portal o si existen indicios públicos de que el rescate ha sido abonado. Esta capacidad aporta una visibilidad muy poco habitual y permite entender mejor el ciclo completo de una operación de ransomware.

    Figura 6: Sección de Negociaciones (Beta), con distribución
    por actor, eventos monitorizados y pagos detectados.

    Más allá del interés analítico, este seguimiento tiene un valor operativo evidente. Permite estudiar el comportamiento real de los actores, comparar patrones entre grupos y observar cómo evolucionan las extorsiones en el tiempo.

    Vulnerabilidades: monitorización continua desde fuentes oficiales

    La inteligencia sobre amenazas no se limita a seguir actores o incidentes activos. También requiere una vigilancia constante sobre la exposición técnica del ecosistema. Por ello, MyThreatIntel incorpora una sección de vulnerabilidades alimentada a partir de fuentes oficiales como NIST y CVE.org. 

    Figura 7: Dashboard de vulnerabilidades, con severidad, fabricantes y frecuencia de detección.

    La plataforma permite consultar CVEs descubiertas, severidad, fabricantes, vectores de ataque y metadatos asociados, facilitando tanto la revisión rápida de nuevas publicaciones como la exportación de resultados para otros flujos de trabajo.

    Figura 8: Vista detallada de CVEs individuales con descripción, vector y puntuación CVSS.
     
    La utilidad aquí no está solo en mostrar una lista de CVEs, sino en integrarlas dentro de un entorno de investigación más amplio. La vulnerabilidad deja de ser un identificador aislado y pasa a formar parte del contexto que rodea una amenaza o una investigación concreta.

    Indicadores de Compromiso: del dato técnico a la utilidad operativa

    Los IoCs siguen siendo una pieza esencial en investigación, detección y respuesta. MyThreatIntel incorpora un repositorio de indicadores con clasificación por tipo, criticidad y telemetría, permitiendo realizar búsquedas, filtros y exportación de resultados.

    Figura 9: Dashboard de IoCs con volumen total, criticidad y distribución por tipo.

    Aquí el objetivo no es solo acumular artefactos, sino facilitar su consumo real por parte del analista. Hashes, dominios, archivos y otros indicadores aparecen organizados de forma que puedan emplearse con rapidez durante una investigación o integrarse en tareas de detección.

    Figura 10: Telemetría de indicadores, con fichas detalladas por artefacto.

    Este enfoque resulta especialmente útil cuando el volumen de datos es alto y el analista necesita reducir ruido para centrarse en aquello que tiene mayor relevancia operativa.

    Darknet & Markets: seguir la infraestructura donde operan los actores

    MyThreatIntel también incorpora una capa específica para la vigilancia de servicios Onion y mercados de la Darknet. Este componente permite observar qué servicios continúan activos, cuáles han caído, qué mercados siguen operando y cómo evoluciona su infraestructura con el tiempo.

    Figura 11: Vista global de Darknet & Markets, con servicios Onion,
    mercados activos y distribución por grupos.

    No se trata únicamente de listar URLs. El valor real está en mantener un histórico de disponibilidad, relaciones con actores y capturas o notas asociadas. En entornos donde la infraestructura cambia rápidamente, esa trazabilidad resulta especialmente valiosa.

    Figura 12: Detalle de mercados Darknet, mostrando estado operativo y URLs monitorizadas.

    De esta forma, la plataforma aporta una visión mucho más estable sobre un ecosistema que, por naturaleza, es altamente volátil.

    Figura 13: Detalle de servicios Onion asociados a actores, con enlaces activos y caídos.

    Filtraciones y grupos: conocimiento estructurado sobre el adversario

    El repositorio de filtraciones añade una perspectiva distinta: la exposición histórica de organizaciones. Los registros pueden buscarse por nombre, fecha o tamaño, lo que ayuda a comprobar si una entidad, dominio o conjunto de datos ya apareció en una filtración conocida. Este componente puede utilizarse tanto en investigaciones de terceros como en análisis de exposición, procesos de ciberinteligencia y respuesta a incidentes. La información deja de estar distribuida entre referencias aisladas y pasa a formar parte de un catálogo consultable desde el mismo entorno.

    Figura 14: Repositorio de filtraciones y catálogo histórico.

    La sección Grupos funciona como una base de conocimiento sobre actores de amenazas. Incluye descripciones, aliases, infraestructura Onion, capturas y notas, permitiendo contextualizar rápidamente a un grupo sin depender de búsquedas dispersas.

    Figura 15 Inteligencia de amenazas: fichas de grupos,
    enlaces Onion y documentación asociada.

    La relación entre actores, víctimas, portales, notas de rescate e infraestructura es uno de los puntos donde MyThreatIntel deja de comportarse como un agregador y empieza a funcionar como una herramienta de investigación. Al analizar una víctima, el investigador puede acceder al contexto del actor, revisar sus canales e infraestructura y observar su actividad documentada desde una única interfaz.

    Malware y artefactos técnicos

    El repositorio de malware reúne muestras con sus hashes, nombre, firma, tamaño, tipo y etiquetas técnicas. Esta clasificación permite localizar artefactos por familia o característica y relacionarlos con los indicadores utilizados durante una investigación.

    Figura 16: Repositorio de muestras de malware, hashes, firmas y etiquetas.

    El apoyo de MITRE ATT&CK aporta contexto sobre técnicas, tácticas y comportamientos, especialmente cuando una muestra forma parte de una cadena de intrusión más amplia. De este modo, el repositorio no actúa únicamente como almacén de archivos, sino como fuente de apoyo para análisis de malware, Threat Hunting y construcción de hipótesis durante una investigación.

    Permutaciones DNS para investigar suplantaciones

    La consulta DNS amplía la plataforma hacia la detección de typosquatting, phishing e infraestructura sospechosa. A partir de un dominio, el motor genera permutaciones y comprueba su registro utilizando diferentes TLD y palabras clave asociadas a accesos corporativos, identidad, Microsoft 365, VPN, correo, servicios cloud o soporte técnico.

    Figura 17: Consulta de permutaciones DNS, TLD, palabras clave y dominios registrados.

    El resultado permite distinguir entre dominios generados y registrados, revisar fechas de creación, aplicar filtros y exportar el análisis. Integrar esta capacidad dentro de MyThreatIntel facilita conectar una posible suplantación con el resto del contexto disponible, en lugar de tratarla como una consulta independiente.

    Consumo mediante Web y API

    La interfaz web está orientada a la investigación manual, pero la inteligencia también debe poder salir de la plataforma. MyThreatIntel dispone de una API con autenticación mediante Bearer Token, respuestas JSON estandarizadas, búsqueda de texto y filtrado por fuentes y categorías. Esto permite consumir vulnerabilidades, IoCs, muestras de malware, víctimas de ransomware, infraestructura Tor, mercados, grupos, negociaciones y filtraciones desde plataformas SIEM, herramientas SOAR, scripts o automatizaciones desarrolladas en PowerShell, Python, JavaScript y otros lenguajes.

    MyThreatIntel puede utilizarse directamente desde https://mythreatintel.secureit.es/, donde centraliza toda esta información en una única interfaz. Además, como la plataforma dispone de API, lo que permite integrarla en flujos de trabajo, herramientas SIEM y SOAR, scripts de investigación o procesos de automatización propios. Este punto es importante porque la inteligencia no siempre termina en el panel. En muchos casos, su verdadero valor aparece cuando puede integrarse en otros procesos de seguridad y respuesta.

    Conclusión

    MyThreatIntel no nace para sustituir fuentes, sino para darles sentido conjunto. En un escenario donde la información está cada vez más fragmentada, el verdadero reto no consiste en recopilar más datos, sino en reducir el tiempo necesario para convertirlos en contexto útil. Ransomware, negociaciones, vulnerabilidades, IoCs, Darknet, filtraciones, grupos, malware y DNS no son piezas aisladas. En una investigación real suelen formar parte de una misma historia. La utilidad de MyThreatIntel está precisamente en ayudar a contar esa historia con menos fricción, más contexto y una mejor capacidad de respuesta.

    Saludos,

    Únete al foro de Ciberseguridad de Chema Alonso en MyPublicInbox Sigue Un informático en el lado del mal RSS 0xWord - Contacta con Chema Alonso en MyPublicInbox.com

¿Quien nos patrocina?

Nadie :-( , de vez en cuando tú haces clic en algún banner de publicidad. :-)

Acceso

¿ Quienes participan ?

Somos un grupos amantes de la tecnología y sobretodo de la programación de Vigo (Galicia).

Te gustaría participar , encantados contar con contigo y nuevas ideas.

Registrarte aquí y envía un formulario alguno de los contactos indicandole en que quieres participar y que ideas tienes.

Mas info

Sobre Nosotros