Un "Hardening Tip" de BBDD - de mi Lost & Found - contra las "Heavy Queries Malignas"

Hace muchos años, cuando estaba trabajando en mi Ph.D en los Time-Based Blind SQL Injection using Heavy Queries, en uno de mis documentos de la universidad escribí sobre las técnicas de "hardening" para dificultar este tipo de ataques y lo tenía preparado en un post, pero lo fui dejando sin sacar, y un día me olvidé de publicarlo, hace unos quince años más o menos.

Figura 1: Un "Hardening Tip" de BBDD - de mi Lost & Found -

 contra las "Heavy Queries Malignas"

Sin embargo, hablando sobre las capacidades de usar ChatGPT, Claude o Gemini para investigar en ciberseguridad, y lo fácil que hubiera sido construir las diferentes Heavy Queries para explotar un bug de SQL Injection usando una técnica Time-Based, me he acordado con él, y se lo he preguntado directamente a Gemini.

Figura 2: Whitepaper de "Time-Based Blind SQL Injection using Heavy Queries"

Por supuesto, de las técnicas de Time-Based Blind SQL Injection using Heavy Queries, hablé en el libro de "Hacking de Aplicaciones Web: SQL Injection", mientras que de las técnicas de LDAP & Blind LDAP  Injection in Web Applications,  y Connection String Parameter Pollution hablé en el libro de "Hacking Web Technologies".

Figura 3: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

Pero hoy en día, encontrar estas técnicas es tan fácil cómo preguntarle a los modelos, que ellos ya se han aprendido todos los papers, por ti, así que, preguntándole por ayuda para localizar si me han hecho un ataque a un aplicación web con un Microsoft Access 2003, obtienes rápidamente la información de sobre este ataque con Heavy Queries.

Figura 4: La tabla del sistema a explotar en Access 2003

Como podéis, ver, rápidamente nos hace el análisis de la tabla del sistema a explotar, y nos dice que la forma de explotarlo es usando Join de ella misma ene veces, tal y como explicamos en el paper, para lograr un volumen de datos tan grande que generar un delay medible. 

Figura 5: El método para explotarlo

Y por último, nos da la inyección completa que se puede utilizar para hacer el Time-Based Blind SQL Injection Using Heavy Queries, lo que genera la explotación completa de la vulnerabilidad. 

Figura 6: Inyección completa tipo Time-Based Blind SQL Injection using Heavy Queries

El resultado es que en un segundo puedes encontrar cómo hacerlo, y no ha habido que hacer ningún Jailbreak ni nada por el estilo, así que vamos a ver ahora la parte de fortificación de la que os he estado hablando.

Figura 7:"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

Si vamos ahora a las protecciones, primero hay que entender por qué sigue siendo importante tener protecciones contra esta forma de explotar la base de datos, generando una Heavy Query. Estas técnicas se pueden usar para hacer un DoS o para extraer información de la BD, especialmente en motores que no tienen funciones de tiempo, o en entornos bajo WAF que están filtrando las queries.

Figura 8: Por qué sigue siendo importante esto

Y aquí viene el Hardening "Tip" del pasado, que no saqué en ninguno de los blog posts que escribí sobre ello, que consiste en que una vez construida la consulta, se pueda comprobar que la consulta tiene un Time-Out acorde con el tipo de Query que se está lanzando.

Figura 9: Poner un límite de tiempo a las consultas SQL

Por supuesto, usar consultas parametrizadas, detectar el tipo de los datos que se inyectan en los parámetros y no construir consultas concatenando strings es la clave, pero que una aplicación pueda vulnerar el rendimiento de la aplicación y de la propia base de datos por no controlar los límites de consumo de recursos de una consulta SQL es fundamental.

Figura 10: Límite temporal a nivel de TRANSACCIÓN en PostgreSQL

Para ello, en los diferentes motores de Bases de Datos existen formas de controlar el máximo tiempo que se va a permitir en ejecución una consulta, que es de lo que estuve escribiendo hace quince años, pero aquí tenéis, preguntándole a Gemini, la fácil que es limitar estos tiempos.

Figura 11: Límites en MySQL versiones 5.7.8+

Por supuesto, si no hay SQL Injection, no hay necesidad de tener esto, pero lo cierto es que esta protección se puede añadir no sólo a nivel de aplicación, sino también a nivel de DBFirewall, a nivel de Driver de conexión, o incluso como hacíamos con los ataques a nivel de red haciendo un Network Packet Manipulation con un Man-in-the-middle.

Figura 12: En Transat-SQL a nivel de Server,

a nivel de Conexión y a nivel de Query

Hay que tener en cuenta que en una arquitectura de Zero-Trust, la base de datos no debe fiarse nunca de las aplicaciones, así que, al igual que hacíamos con el Paranoid Mode para evitar las manipulaciones en bases de datos por parte de ataques de SQL Injection, controlar el consumo descontrolado de recursos es fundamental.

Figura 13: Controles en Oracle a nivel de SESSION y con Perfiles

Al final, si eres responsable de una base de datos de alto rendimiento, con muchas aplicaciones colgando de ellas, limitar el consumo de recursos lo puedes hacer preventivamente - evitándolo con límites - o reactivo, viendo qué está comiéndose la memoria y la CPU de la base de datos.

Figura 14: Límites en Access 2003 y SQLite

Ya os conté muchas veces que en la universidad yo me especialicé en Bases de Datos, que me encantaban, y que mis primeros trabajos tuvieron que ver con Tuning de bases de datos Oracle y de aplicaciones que corrían sobre ellas, así que estas cosas las tenía muy presentes cuando comencé con el trabajo de Time-Based Blind SQL Injection Attacks using Heavy Queries.

Figura 15: Resumen de posibilidades

Esta es una buena práctica de seguridad, sobre todo si eres de los que gusta tener los entornos Hardened in Paranoid Mode, así que si no la conocías o no lo estás aplicando, a lo mejor encuentras un punto donde tener estos controles y evitas estos ataques.

Figura 16: Por qué es útil esto

Lo cierto, que es a lo que iba la conversación inicial, es que esto que dejé a medio escribir hace quince años como un post, tenía que actualizarlo para ver cómo se establecen los límites temporales en todas las bases de datos, y en todos los puntos posibles, pero gracias a la existencia de los LLMs hoy en día, ha sido tan fácil como pedirle a Gemini que me lo dé, por eso os lo he compartido hoy y he borrado una tarea del pasado que tenía en mi To-Do.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

CTC-1002: Antrhopic bloquea un Agentic AI creado sobre Claude hecho por ciberatacantes que hackea organizaciones completamente autónomo

Durante este año hemos ido viendo cómo el mundo de tener Agentic AI para explotación completa de organizaciones era algo que se estaba desarrollando a toda velocidad. Este año he ido siguiendo este proceso poco a poco, por medio de la publicación de un trabajo de investigación tras otro. Al mismo tiempo, los reportes de OpenAI sobre los usos maliciosos de sus productos nos han enseñado cómo iban utilizándose la IA de forma autónoma para campañas de fraude, desinformación, y fases de la intrusión de sistemas. 

Figura 1:  CTC-1002: Antrhopic bloquea un Agentic AI creado

sobre Claude hecho por ciberatacantes que hackea

organizaciones completamente autónomo

Ahora Anthropic, que ya publicó en Agosto cómo los ciber-bad-actors estaban utilizando sus capacidades en forma de Vibe Coding para atacar organizaciones, nos presenta en su último informe de hace apenas unos días llamado "Disrupting the first reported AI-orchestrated cyber espionage campaign" cómo un grupo al que ha llamado CTC-1002 ha hecho el uso de las capacidades de Agentic AI para la explotación a escala de organizaciones con una arquitectura totalmente automatizada.

GTG-1002 represents multiple firsts in AI-enabled threat actor capabilities. The actor achieved what we believe is the first documented case of a cyberattack largely executed without human intervention at scale—the AI autonomously discovered vulnerabilities in targets selected by human operators and successfully exploited them in live operations, then performed a wide range of post-exploitation activities from analysis, lateral movement, privilege escalation, data access, to data exfiltration. Most significantly, this 2 marks the first documented case of agentic AI successfully obtaining access to confirmed high-value targets for intelligence collection, including major technology corporations and government agencies.

Que traducido al español para los que prefieren esta lengua dice:

GTG-1002 representa varios hitos pioneros en las capacidades de actores de amenazas potenciados por inteligencia artificial. El actor logró lo que se considera el primer caso documentado de un ciberataque ejecutado en gran medida sin intervención humana y a escala: la IA descubrió de forma autónoma vulnerabilidades en objetivos seleccionados por operadores humanos y las explotó con éxito en operaciones reales. Posteriormente, realizó una amplia gama de actividades de post-explotación, incluyendo análisis, movimiento lateral, escalado de privilegios, acceso a datos y exfiltración de información. Lo más significativo es que este caso marca la primera instancia documentada de una Agente AI que obtuvo con éxito acceso a objetivos confirmados de alto valor para la recopilación de inteligencia, entre ellos grandes corporaciones tecnológicas y agencias gubernamentales.

No es nada que no nos experabamos tras ver los trabajos de Incalmo, de Cybersecurity AI, de explotación autónoma de Web Sites o creación automática de exploits de escalación de privilegios para Linux, como ejemplo, de los que os he ido contando cosas, y que merece la pena que te los leas para entender mejor dónde estamos hoy.

• LLM as Hackers: Autonomus Linux Privilege Escalation Attacks con Agentes AI
• Vibe Hacking con Cybersecurity AI (CAI): Agentes AI autónomos para ciberseguridad ofensiva y defensiva
• ¿Se puede reemplazar a un Pentester con un Agente de IA basado en LLMs? Cómo realizar ataques completos a redes complejas con agentes de Inteligencia Artificial
• LLM Agents can autonomouslly hack websites
• LLM Agents can Autonomously Exploit One-day Vulnerabilities
• LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks
• On the Feasibility of Using LLMs toExecute Multistage Network Attacks

El informe completo, que lo puedes y lo deberías leer, está en el siguiente enlace donde puedes ver que es apenas de 10 páginas donde resumen cuál es la arquitectura del Agentic AI construido para colarse de manera automática dentro de organizaciones.

Figura 2: Disrupting the first reported AI-orchestrated cyber espionage campaign

En la arquitectura se puede ver cómo hay un Operador Humano que es el que controla al Agentic AI. Este con una arquitectura similar a la descrita por Incalmo o Cybersecurity AI, cuenta con un conjunto de MCPs que le ofrecen herramientas para todas las fases del ataque, desde la fase de reconocimiento, de descubrimiento de vulnerabilidades, de creación de exploits - con una herramienta de validación de exploits externa - de explotación de las vulnerabilidades, de elevación de privilegios, y movimientos laterales dentro de la organización. Vamos, un ataque completo.

Figura 3: Arquitectura del Agentic AI de CTC-1002

Clic en la imagen para verla en grande

Para cada una de esas fases hay diseñado un flujo en el que hay una cierta interacción con un Operador Humano que va validando los resultados, con herramientas vía MCPs, con búsqueda de información en la web, o con la validación mediante otro modelo LLM que revisa que lo que se está haciendo es correcto. En la imagen siguiente tenéis los flujos de las diferentes fases muy bien descritos.

Figura 4: Flujos de las fases de explotación.

Clic en la imagen para verla en grande

Para entender mejor el flujo de estas fases, en el documento tienes algunos ejemplos de qué es lo que ha ido haciendo el Agentic AI en algunas situaciones. Por ejemplo, en esta tabla se ven las tareas del Agente IA para descubrir una vulnerabilidad de Server-Side Request Forgery en el backend de un Web Server, cómo generar un exploit con un payload personalizado, y solicita la revisión del Operador Humano.

Figura 5: Descubrimiento, validación y explotación de una vulnerabilidad

SSRF en un Web Server.

Una vez que el Operador Humano aprueba la explotación, entonces ejecuta el exploit y realiza una serie de tareas de post-explotación para completar el proceso y continuar el proceso sobre los nuevos activos descubiertos.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

En el siguiente ejemplo se ve el flujo de extracción de información de una base de datos a partir de credenciales recolectadas en el proceso de explotación de la organización. En él se puede ver cómo hace un mapa de la base de datos, extrae los hashes de las cuentas de la base de datos, identifica las más privilegiadas, crea una cuenta para tener persistencia en la base de datos, se descarga los datos, y los analiza para generar un informe final de inteligencia que es exfiltrado cuando el Operador Humano lo aprueba.

Figura 7: Exflitración de datos de una base de datos.

El trabajo es técnicamente perfecto, y sí, Anthropic dice que ha trabajado para acabar con las operaciones de este grupo, pero las capacidades de crear estos agentes, esta arquitectura, y estas herramientas ya existen, se conocen, están en el mercado, y han subido el nivel de las capacidades de los atacantes. Será con Claude, con GPT5.1 o con Llama 5, pero tienen estas capacidades a su alcance. Tienen el Railgun disponible, así que más vale que si trabajas como CISO te tomes en serio estas nuevas amenzas.

Figura 8: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Como decía ayer, los equipos de Red Team, de Blue Team y los Ciberatacantes han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo construir un Doom-Like usando sólo Lenguaje SQL (o en Excel)

El juego de DOOM es un clásico entre los clásicos en el mundo del PC. Y es una referencia para muchos de nosotros cada vez que queremos probar algo con la tecnología de aquella época, especialmente porque John Carmack innovó y de qué manera en sus juegos, creando una nueva generación de juegos. Y hoy os quería hablar de otro vuelto de tuerca jugando a ser el máster en Lenguaje SQL creando un juego tipo DOOM.

Figura 1: Cómo construir un Doom-Like usando sólo Lenguaje SQL (o en Excel)

El juego DOOM es el primero que me vino a la mente a mí cuando quería probar a ejecutar programas MS-DOS en iPhone, y fue con el que hice la prueba del emulador, como recordaréis, que os publiqué hace un año en el artículo: "Cómo jugar al DOOM de MS/DOS en iPhone & iPad (o cualquier otro DOS Game) con iDOS" 

Figura 2: Jugando al Doom con GamePad o teclas

El DOOM también es el juego que utilizaron los investigadores de Google para demostrar cómo la IA podría crear Mundos Virtuales en tiempo real con GenAI, que luego usaron para lanzar Genie 3.0 y dejar impresionado al mundo, en el artículo:"Diffusion Models Are Real-Time Game Engines".

Figura 3: Diffusion Models Are Real-Time Game Engines

No es casualidad esto. Al final DOOM es un ejemplo de calidad de código, de innovación, de jugabilidad, de optimización de los algoritmos, y un montón más de excelencias, que usarlo como referencia es siempre muy atractivo.

DuckDB DOOM on the browser

En este caso, PatrickTrainer ha creado un juego tipo DOOM construido para jugar en el navegador, pero construido enteramente en Lenguaje SQL, y eso mola todo. Lo que ha hecho ha sido construir un mundo basado en caracteres ASCII almacenados con tablas SQL sobre la base de datos DuckDB que corre en el navegador usando las librerías WASM, para describir el mapa de un juego tipo DOOM, meter enemigos, marcados con la letra E y tener a un jugador moviéndose por el mundo, marcado con el carácter @.

Figura 4: DuckDB Doom

Y por debajo, toda la representación en pantalla son ejecución de comandos del Lenguaje SQL que le permiten, utilizando Vistas, implementar el algoritmo Z-Buffer para poder tener la perspectiva del mapa desde el punto de vista del jugador, localizar a los enemigos, y disparar su proyectil (*). 

Figura 5: GitHub de DuckDB DOOM

Con que te bajes un el fichero Index.html y Demo.html podrás correr en cualquier sitio este juego, que como ejercicio de programación es maravilloso.

DOOMQL: Multiplayer

Y como suele suceder, una idea inspira otras ideas. En este caso Lukas Vogel ha publicado la semana pasada DOOMQL, un juego tipo DOOM, multiplayer, construido íntegramente con Lenguaje SQL en la base de datos CedarDB. Repito: multiplayer. Pero también a 30 Frames per Second y con menos de 200 líneas de código.

Figura 6: DoomQL

Tienes un artículo titulado: "DOOMQL: A DOOM-like multiplayer shooter in pure SQL" en el que explica en detalle todo el proceso, incluyendo el algoritmo de pintar el "3D", o el Raycasting para disparar los proyectiles. Mola todo, que además ha dejado publicados los cheat codes. 

Figura 7: DoomQL en GitHub

Como en el caso anterior, tienes todo el código disponible y documentado en el GitHub de este proyecto: DoomQL en GitHub. Todo son Tablas, Vistas y consultas en Lenguaje SQL. Te va a sorprender la simplicidad y elegancia del código final logrado por el programador.

Lenguaje SQL

Me han hecho especial cariño estos dos proyectos, porque como cuento siempre, yo entré en el mundo del hacking y la ciberseguridad casi de casualidad. Lo que yo sabía era programar, y especialmente mucho de bases de datos, que es en todo lo que me centré en mi vida. Os conté esa historia en el artículo de "El amo de lo datos". 

Figura 8: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

Saber mucho de Lenguaje SQL hizo que cuado aparecieron las técnicas de SQL Injection yo pudiera jugar mucho con ellas. Time-Based Blind SQL Injection using Heavy Queries, Arithmetic Blind SQL Injection, Remote File Downloading using SQL Injection, Connection String Parameter Pollution, (Blind) LDAP Injection in Web Applications, WordPress in Paranoid Mode, WhatsApp Anti-Delete Protection Tool. Todo fue jugar con lo que había aprendido de bases de datos.  Y de todo ello está escrito el libro de Hacking de Aplicaciones Web: SQL Injection (3ª Edición)

Bonus Track: Doom en EXCEL

No puedo escribir un artículo sobre como ser el máster de algo para hacer un proyecto como un juego de DOOM, sin hablar el trabajo que hizo c Bell hace ya muchos años para hacer un DOOM-Like en Excel sin utilizar VBA, que es una pasada.

Figura 9: Doom-Like en Excel

Y es que, si con Lenguaje SQL Se pueden hacer "locuras" con un EXCEL en las manos la cosa puede desmadrarse. De hecho, hay un MS Excel World Championship que se celebra en Las Vegas donde los expertos de Excel deben resolver problemas híper-complejos.

Figura 10: MS Excel World Championship

Este año debían resolver retos como este "Temple of the Golden Idol", para conseguir, sólo utilizando fórmulas de EXCEL que los animales resolvieran los laberintos.

Figura 11: Temple of the Goldem Idol

Figura 12: Temple of the Goldem Idol (2)

Me encantan estas cosas. Son el tipo de PoCs & Hacks Just for Fun que tanto nos gusta, como cuando quisimos hacer el Copilot para AMSTRAD CPC 6128 con el objetivo de poder desarrollar programas den BASIC usando GenAI, o cuando conectamos el Apple Macintosh a la nube.. Simplemente por que mola todo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El amo de los datos

Ayer tuve una jornada interesante de transformación digital en Londres. Hablando de datos, ML, GenAI, arquitecturas RAG, y normalización de datos. Cosas habituales hoy en día en cualquier empresa. En uno de esos momentos en los que estaba escuchando, sobre casos de uso que que se iban a crear usando ML, el debate acabó una vez en los datos. El Catálogo, el Data-Fabric, el Data Wharehouse, Data Curation, la validación de la ingesta, los Data Streams, etcétera. Cosas habituales en la vida de la digitalización de empresas.

Figura 1: El amo de los datos

Para mí, eso fue el día a día cuando en al año 2016 tuve la responsabilidad de ser el Chief Data Officer de Telefónica y tuve que tomar muchas, muchas, muchas decisiones sobre estos temas que, a día de hoy que soy el Chief Digital Officer, siguen perdurando en nuestro trabajo diario. 

Estando en ese debate, mi cabeza viajo temporalmente a mis inicios con los datos. Cuando bajaba la calle Barcelona de Móstoles, pasaba por delante del Eco Móstoles, y me metía en un pequeño parque a medio terminar que se encontraba y se encuentra a espaldas de calle Libertad de Móstoles. Allí estaba uno de los locales de la Academia RUS de la que os he hablado muchas veces. Tendría yo 14 o 15 años e iba a mi clase de Informática diaria. A seguir aprendiendo a programar.

En aquellos años ya había dejado el BASIC y el Logo atrás, y estaba con con COBOL, SQL y MS/DOS. También tocaría aprender DBASE, C y Pascal, pero antes de ellos, mi paso era hacer códigos con la IDENTIFICATION DIVISION y la PROCEDURE DIVISON. Había que aprender a identar el código, usar muchas mayúsculas, y ser muy disciplinado en la forma de hacer programas con este lenguaje llamado COBOL.

Las clases a las que asistía de informática se multiplicaban en mi agenda, normalmente hacía tres cursos a la semana diferente, haciendo clases los lunes y miércoles, y los martes y jueves, y repitiendo algunas de 17:30 a 18:30 y de 18:30 a 19:30, y luego había algunos cursos que se daban los viernes y sábados. De los 12 a los 16 años fueron años en los que mi afición era programar, así que no me importaba pasarme dos horas cada día en la academia, e incluso quedarme los viernes y sábado. ¿Qué podría haber más divertido que eso? Además, de vez en cuando daba yo la clase, y me llevaba de maravilla con Bea, mi profesora muchos de esos años.

Nada de lo que aprendí en aquellos años fue en vano. Todo ese aprendizaje sigue en mí, cambiado, adaptado, y mejorado, pero como base sobre la que construí mucho de mi conocimiento futuro. Y ayer me acordé de la época de COBOL y el acceso a Datos para hacer cosas. En aquellos momentos, cuando pasé de BASIC a COBOL, entré en el mundo de las reglas de estilo y la programación estructurada con técnicas de diseño de software muy metódicas. Formas de hacer las cosas de manera industrial. El trabajo de programador como factoría de software. Dados unos requisitos, escribir código como si fueras una máquina tú.

Los programas de gestión, hechos con COBOL y datos almacenados en bases de datos o ficheros tenían siempre las mismas estructuras. Y todos mis primeros Menús eran siempre ALTAS, BAJAS, MODIFICACIONES y CONSULTAS. Tendía que definir las fuentes de datos, los tipos de datos que iba a utilizar, si eran ficheros, los accesos que serían Secuenciales (si eran en cinta), acceso aleatorio (si eran en cintas modernas con aceleración de rebobinado y avanzado) o de acceso directo (si el almacenamiento era en disco). O los tipos de datos que se iban a leer de las bases de datos, en forma de registros que había que procesar,  pintar por pantalla en listados, etcétera.

La programación era una ingeniería. Las cosas tenía una forma de hacerse. Había metodologías de desarrollo de software. Hablábamos de los modelos de solucionar cada uno de los problemas. Y teníamos guías de estilo de programación, nombres de variables, llamadas a procedimientos, factorización del software, etcétera, para hacerlo mantenible, aduitable, y permitir que cualquier código fuera tocado por cualquier programador de COBOL. Me encantaba saber que era una pieza de parte de una industria de desarrollo de software. Podría ser programador o mi sueño entonces, ser "Analista", para poder asignar las tareas a los programadores siguiendo las guías de desarrollo del software de una empresa. 

Podéis imaginaros lo que un niño de 14 o 15 años sentía cuando se veía ahí. Siento un analista de software. Metiendo líneas de código y jugando con los decimales como Richard Prior en Superman III, desde tu terminal. Identando tu código. Flipante.

Y os cuento todo esto, porque de aquella época también aprendi parte de la gestión de los datos que décadas después usé como Chief Data Officer en Telefónica. Y es que, allí, en aquellos años, me explicaron cómo la Banca creaba sus aplicaciones para preservar sus datos. Cómo los informáticos habían creado para COBOL una metodología de trabajo con datos basada en mantener el core más sagrado de la empresa, LOS DATOS, a salvo de malos programadores. Metiendo una capa de seguridad, metiendo una capa de protección. 

Y yo escuchaba atento. ¿Cuál sería el truco? ¿Cómo lo han hecho? ¿Cuál es el secreto?

No había mucha magia. O sí. Según se mire. 

Lo habían hecho otros informáticos que llegaron a interesarme tanto o más que los Analistas, se trataba de tipos más duros aún. Que tenían más poder porque protegían el activo más valioso de las empresas. De la poderosa industria bancaria. Los datos, que al final de día era dinero. Se trataba de los Administradores de Bases de Datos.

¡¡Buaahhh!

¡Qué pasada!

Resulta que había unos tipos que para que los Analista de Programación pudieran diseñar sus programas de ALTAS, BAJAS, MODIFICACIONES y CONSULTAS, con sus infinitos listados por pantalla y por impresora (no conté yo espacios ni nada para cuadrar listados en papel continuo de impresoras matriciales), estos Analistas tenían que hablar con los Administradores de Bases de Datos para que les disponibilizaran los datos que necesitaban utilizar para sus programas. Y ellos decidían cómo lo hacían.

Esto, tenía su ciencia. Porque no iban a dejar que cualquier Programador tocara cualquier dato, así que se dedicaban a crear VISTAS, VISTAS para Actualización de datos, y Tablas de solo lectura que disponibilizaban a los Analistas para que hicieran su aplicación de ABMyC sobre estas fuentes de datos. Los Analistas repartían las tareas a los Programadores, y la Factoría de Software de la empresa seguía produciendo sistemas de información para la empresa.

Si habéis leído esto, sabréis porque cuando llegué a la Universidad me centré en aprender todas las asignaturas de Bases de Datos. A aprender a hacer el diseño lógico y el diseño físico de las bases de datos. A aprender cómo funcionaban los Tablespaces, las p-codes de las consultas de bases de datos, a descubrir los detalles de las formas normales de Boyce-Codd, a aprender PL/SQL, T-SQL, hacer optimización de bases de datos y aplicaciones, etcétera. El resto, ya os lo sabéis, trabajé mucho con las bases de datos Oracle cuando salí de la Universidad, luego llegó el SQL Injection... y el resto es historia moderna, desarrollando mi perfil profesional en datos y hacking.

Pero ayer volví a ello una vez más, porque el debate nos llevaba a cómo preservar los datos y disponibilizarlos a los modelos. Hoy hablamos de Data Streams, de Gestores de Consentimientos para acceso a datos, de políticas y procedimientos de anonimización y pseudoanonimización, de consultas con algoritmos de cifrado homomórfico, de roles de seguridad, de las plantillas de cumplimiento regulativo, etcétera. 

Entonces, el Administrador de la Base de Datos era el "amo de los datos" y de todo eso. Y yo lo aprendí en una academia de barrio de Móstoles. Leyendo libros y deseando un día poder ser parte de esa Industria y la Ingeniería del Software. Flipante.  

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Bases de datos vectoriales potenciando la Inteligencia Artificial

En Ideas Locas desarrollamos para el Equinox de marzo un prototipo de búsqueda semántica, Summify.ai, en donde teníamos almacenadas las transcripciones de diferentes programas de "La Resistencia" del gran David Broncano, y mediante Inteligencia Artificial, con un modelo de lenguaje, podíamos hacer una pregunta sobre algo relacionado con uno de los programas y esta IA se “leía” la transcripción y nos generaba la respuesta deseada. ¿Pero cómo sabía el modelo de lenguaje qué programa de La Resistencia tenía que leerse para poder generar una respuesta acorde a la pregunta realizada?

Figura 1: Bases de datos vectoriales potenciando la Inteligencia Artificial

En realidad, no almacenábamos únicamente las transcripciones de estos programas, sino también sus embeddings, una codificación del conocimiento de manera numérica. De esta manera, cuando hacíamos una query, computábamos el embedding de esta query y lo comparábamos con los embeddings almacenados, los correspondientes a las transcripciones de cada programa. Aquella comparación que diese mayor valor significaba que habíamos encontrado un programa de La Resistencia que estaba muy relacionado con la pregunta que hicimos.


Figura 2: Para veas qué es un Equinox tienes el de Autumn 2015
Lo que desarrollamos fue un prototipo y no teníamos almacenados demasiados embeddings, pero si se hiciera algo parecido donde se tuviese que comparar el embedding de nuestra query con miles o millones de embeddings, el proceso de búsqueda sería lento. Es por esto por lo que existen las llamadas bases de datos vectoriales, que indexan y almacenan estos embeddings para poder realizar este tipo de búsqueda más rápido. Un mercado que está en auge, donde recientemente varias soluciones dedicadas a esto han levantado millones de dólares, como Weaviate, Pinecone, o Chroma.

En este artículo vamos a ver en primer lugar en qué consisten los embeddings, sin los cuales nada de esto podría ser posible, para posteriormente ver diferentes técnicas de indexación que existen para recuperar información más rápido.

La magia de los embeddings

Cuando entrenas una red neuronal, esta necesita ser alimentada con datos para comprender todo lo que está viendo y saber realizar la tarea que le pidamos. Por ejemplo, si queremos entrenar una red para detectar deepfakes en imágenes, necesitamos enseñarle a estas imágenes tanto de personas reales como de personas generadas con algunas técnicas de Inteligencia Artificial. O si queremos crear ChatGPT, se necesita enseñarle una cantidad muy extensa de textos para que pueda aprender la estructura del lenguaje (qué significa cada palabra, cómo utilizarlas para crear frases estructuralmente correctas…).

Cuando la red ha terminado su aprendizaje, se podría decir que “almacena” una especie de diccionario interno, y es capaz de traducir o codificar lo que sea que reciba en una lista de números. Por hacer una analogía, es como si actuara como el diccionario de la RAE, donde explicara lo que significa cada palabra, solo que, en vez de expresar su significado en texto, lo que hace es codificarlo en una lista de números.

Figura 3: Ejemplos de embeddings de palabras

   
Esta lista de números es lo que se conoce como embedding. En concreto, es una lista o vector de un número determinado de dimensiones, y en cada dimensión hay un número decimal. La clave es que cada una de estas dimensiones quiere significar algo. Por ejemplo, una de ellas podría significar algo “humano”, entonces las palabras “rey” y “reina” tendrían un número similar en esa dimensión, ya que ambas representan algo humano. Y si otras de las dimensiones fuese la representación de “género”, entonces estas dos palabras mencionadas tendrían ya un valor distinto al no tener el mismo género. En la realidad, puede haber hasta miles de dimensiones que se encargan de codificar los significados de las palabras y las relaciones entre ellas.

Búsqueda semántica

Como he dicho al principio, una red neuronal se puede entrenar para diversas tareas, ya sea por ejemplo trabajando con texto como ChatGPT, o por ejemplo trabajando con imágenes como un detector de deepfakes, que es un buen ejemplo de cómo aplicar IA/ML a Ciberseguridad. Como siempre que se entrena una red esta aprende esta especie de diccionario interno que he comentado al principio, esto significa que será capaz de crear embeddings para cualquier tipo de datos que reciba, siempre y cuando haya sido entrenada con este.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández.

Esto quiere decir que podemos expresar, entre otras cosas, textos (palabras, frases, párrafos…), imágenes, vídeos, documentos (como por ejemplo PDF, en realidad codificando el contenido textual de este) o audios en vectores de números (embeddings), pero con significado. Es decir, por ejemplo, si obtenemos los embeddings de una gran cantidad de imágenes, aquellas que contengan animales tendrán vector de números más similar que si las comparamos con imágenes de edificios, ya que se trata de otro concepto.

Y como podemos ver, todos los tipos de datos que he comentado son datos no estructurados. De esta manera, ahora tenemos una manera mucho más inteligente de generar y almacenar conocimiento sobre este tipo de datos, donde sin el uso de embeddings se necesitaría de algún etiquetado manual para intentar generar algo de conocimiento en ellos que nos sirvieran posteriormente para recuperar información cuando fuese necesario.

Como he comentado al principio del artículo, cuando en Ideas Locas desarrollamos Summify.ai para el Equinox, no almacenábamos solamente las transcripciones como tal, sino también los embeddings de estas. De esta manera, cuando en la aplicación queríamos obtener la respuesta a la consulta “¿Qué le gusta a Jhay Cortez?”, esta misma consulta se transformaba en embedding, y se comparaba con los embeddings que teníamos almacenados en base de datos, correspondientes a cada programa de La Resistencia que habíamos guardado.

Figura 5: Ejemplo de query + respuesta en Summify.ai

Entonces, la comparación que devolviera el mayor valor quería decir que habíamos encontrado un programa de La Resistencia donde se hablaba sobre algo relacionado con nuestra consulta (la forma más común de computar cómo de similares son dos embeddings es haciendo uso de la similitud coseno). Siguiendo con el ejemplo, concretamente habríamos encontrado y recuperado la información del programa donde acudió Jhay Cortez como invitado, ya que en la consulta hicimos una pregunta relacionada con un tema que se trata en este programa en específico, y este conocimiento está codificado en el embedding de alguna manera.

Esta aplicación que desarrollamos era un prototipo, hecho con pocos ejemplos. Pero si se tuviera que desarrollar algo parecido, donde esta vez se almacenaran miles o millones de embeddings, sería un proceso muy lento ir calculando cómo de similar es el embedding de nuestra consulta con cada uno de los miles o millones de embeddings almacenados, por ello, lo que se está haciendo últimamente es desarrollar estrategias de búsqueda mediante indexaciones para hacer búsquedas más efectivas.

Estrategias de indexación

Hay gran investigación en este campo, y cada vez van saliendo nuevas formas de indexado para facilitar las búsquedas. Algunos algoritmos conocidos son los siguientes:

• Inverted File Index (IVF): en este algoritmo cada embedding es asignado a su centroide más cercano. Podríamos decir que el centroide (que se calcula con algoritmos de clusterización) es como el “representante” de un determinado conjunto de embeddings, y existen varios centroides que van agrupando diferentes embeddings según sus similitudes. Entonces, cuando hacemos una query, lo que se hace primero es determinar el centroide más cercano al embedding de la query, y una vez lo sabemos ya solo tenemos que calcular la similitud con los embeddings que están representados por este centroide.

• Cuantificación: esta técnica consiste en la reducción de la precisión de cada número decimal que conforma el embedding, reduciendo el tamaño de la base de datos y mejorando la velocidad en los cálculos de similitud entre embeddings.

• Hierarchical Navigable Small Worlds (HNSW): en este algoritmo se crea un grafo de múltiples capas, donde en las capas superiores se tienen las llamadas conexiones largas (embeddings que guardan menos similitud entre sí), mientras que si vamos disminuyendo en capas se van teniendo conexiones más cortas, es decir, un mayor número de embeddings y con mayor similitud entre ellos.

Para el proceso de búsqueda, empezamos en la primera capa, y vamos recorriendo los vértices (embeddings) de esta mediante una greedy search, empezando desde un vértice de comienzo (entry point). Mientras estamos en un vértice, se calcula la similitud de este embedding con el de la query, y luego calculamos la similitud entre el embedding de la query y los de los vértices conectados al vértice en el que estamos. 

 

Figura 6: Funcionamiento HNSW

Si encontramos un vértice que presenta una similitud mayor con nuestra query que la que presenta el vértice en el que estamos, seguimos el proceso moviéndonos a ese vértice. Si ya no encontramos ningún otro vértice que tenga mayor similitud con el embedding de la query, bajamos a la siguiente capa y seguimos el mismo proceso, esta vez empezando como entry point en el vértice en el que estábamos en la capa anterior. De esta manera, cuando lleguemos a la última capa, el resultado final si seguimos este proceso será ya el embedding más similar al de nuestra query.

• Approximate Nearest Neighbors Oh Yeah (ANNOY): este es un algoritmo popularizado por Spotify para su sistema de recomendación musical, el cual consiste en de manera iterativa ir separando el conjunto de embeddings en dos, de manera recursiva, hasta que cada conjunto tiene k elementos (normalmente unos 100 elementos).

Figura 7: Ejemplo iteraciones ANNOY

Al final, en su esencia la indexación se comportará como un árbol binario, que tiene registrados las separaciones del espacio que se han ido haciendo, teniendo por ejemplo en las ramas “izquierda” los puntos debajo de la línea que separaba el espacio en ese momento, mientras que en las ramas “derecha” se tienen los puntos por encima. Como el proceso de separación del espacio es iterativo, el árbol tendrá una determinada profundidad, aunque cada vez cuando nos movamos a la izquierda o a la derecha habrá menos puntos representados.

El proceso de búsqueda es sencillo: dado el embedding de una query, recorremos el árbol creado y vamos cayendo por sus diferentes ramas hasta llegar a una zona del plano que tiene, siguiendo el ejemplo, 100 embeddings, y es solo con estos 100 embeddings con los que compararíamos la similitud con el embedding de nuestra query hasta determinar cuál es el más similar. En vez de computar la similitud con todos los puntos del espacio (miles o millones de embeddings), acabamos haciéndolo solo con 100 puntos, mejorando drásticamente la velocidad de la búsqueda.

Conclusiones

En este artículo hemos visto cómo la indexación de embeddings puede mejorar las búsquedas semánticas, el cual para mí es uno de los grandes usos que tienen los modelos de lenguaje. Ya lo tenemos con Microsoft Bing, y recientemente Google ya está preparando la incorporación de su modelo de lenguaje, Bard, para poder hacer este tipo de búsquedas, encontrándose en fase de experimentación.

Pero también, las bases de datos vectoriales tienen gran uso en otros casos como motores de recomendación o búsquedas por similitud (como insertar una imagen, un vídeo, un audio o un texto para recuperar contenido similar). En general, para el desarrollo de grandes aplicaciones que hagan uso de IA, sobre todo de modelos de lenguaje, las bases de datos vectoriales permitirán el desarrollo de sistemas rápidos y más eficaces.

Un saludo,

Autor: Javier del Pino Díaz, del equipo de Ideas Locas.

Contactar con Javier del Pino Díaz en MyPublicInbox