Hacer tecnología por hacer tecnología no tiene sentido. Siempre que hagas tecnología tienes unos costes, así que tienes que saber qué es lo que quieres conseguir con ello para invertir bien el tiempo de tu equipo, que unas veces pueden ser ingresos, otros márgenes, otros conseguir un buen posicionamiento en un mercado, o simplemente para evitar un problema a futuro, o defender una posición. Pero hacer tecnología por hacer tecnología no tiene mucho sentido.
Figura 1: Tres historias de hacer tecnología como
herramienta estratégica de la empresa
De hecho, una de las reglas de un buen emprendedor es "Code Less, Sell More". Si eso lo sigues, será más fácil que levantes startups más rápidamente, que puedan pivotar más rápido, y que consigan el Break-Even mucho antes. Es un hecho, y yo me lo he aplicado desde que con 24 años montamos Informática 64 y había que vivir de eso. Hay que hacer tecnología, pero la que nos ayude de verdad a conseguir los propósitos.
Desde que llegué a Telefónica, me aplico esa regla de oro para todo lo que hago, así que cuando montamos ElevenPaths establecimos unas reglas similares que decían que sólo haremos "Productos que no hagan los demás o que los podamos hacer de manera completamente diferente y mejor". Por eso creamos sólo tecnología que va con patentes y protecciones. Al final, las tecnologías de ElevenPaths iban a ser - como al final fueron -, piezas de innovación para capturar un volumen mucho mayor de servicios de ciberseguridad, que acabaron alcanzando números de ingresos mucho mayores de los tan siquiera nos habíamos planteado al inicio.
Recuerdo que en aquellos momentos el roadmap de un producto era "Ingresos-Driven". Primero Ingresos, segundo Patentes, tercero Relevancia. Y luego todo aquello que fuera "Nice-to-have". Qué momentos más bonitos de debate teníamos en las sesiones de priorización de roadmap. Pero cada decisión de hacer tecnología puede tener una estrategia diferente. Dejadme que os cuente tres ejemplos de cómo se fraguaron tres (o más) tecnologías totalmente distintas en Telefónica, para que veáis cuál era el objetivo de cada una de ellas, como parte de una estrategia de empresa mayor.
Kernel: Codename "La 4ª Plataforma"
El nacimiento de la 4ª Plataforma, que desde hace años la terminamos y lleva el nombre de Kernel, es el corazón de los servicios digitales de Telefónica. Con ella empezamos en el año 2016, y necesitábamos una plataforma que acabara con las arquitecturas application-centric que teníamos hasta el momento, que sacara partido de las arquitecturas Cloud y BigData, para permitir que se crearan nuevos servicios digitales sin estar conectados a los sistemas legados.
Figura 2: Si visitas La Cabina puedes ver funcionando
la 4ª Plataforma en tiempo real en Telefónica de España.
Esta info es similar a la de Alemania, Brasil o UK, por ejemplo.
Además teníamos que hacer una capa que cumpliera el GDPR y la regulación que llegara en 2017, y no podíamos dejar que esa pieza tan clave para el futuro estuviera en manos de un proveedor, así que había que crear tecnología.
Figura 3: App Novum en funcionamiento en la 4ª Plataforma en tiempo real y las
llamadas a APIs y consumo de datasets en el momento, que puedes ver en La Cabina.
18.825 instancias de Novum en este instante.
Creamos la 4ªPlataforma, como IdP único & SSO de todos los servicios digitales, como plataforma de APIs estandarizadas para todo el grupo, Datos normalizados bajo un catálogo de datos global URM, un gestor de consentimientos, y la posibilidad de correr algoritmos de Machine Learning para generar insights.
Figura 4: Apps en paralelo llamando a APIs y procesado Datasets
en la 4ª Plataforma de Telefónica de España.
La pusimos en producción y empezamos a construir los servicios digitales sobre ella. Primero la plataforma móvil (Codename:Novum) que llamamos Mi Movistar, Meu Vivo, Mein O2, Mi O2, Mein Blau, My O2, etc... en cada marca y país, la plataforma de televisión global, que da servicio a Movistar Play, Movistar Plus o Vivo Play en el mundo, la plataforma de gestión de la WiFi de SmartWiFi, Movistar Prosegur Alarmas para la presencia WiFi, Aura, las Living Apps, Movistar Tokens, el Canal Online, el eCommerce, HaaC (Home as a Computer),OpenGateway, etcétera.
Figura 5: Panel en Grafana de peticiones de APIs por segundo en las
últimas 24 horas en la 4ª Plataforma. Se puede ver el Prime-time de la tele.
Hoy en día - y desde hace años -, todos los servicio digitales se construyen sobre la 4ª Plataforma, donde para que os hagáis una idea, tuvimos más de 33 Billones de API Calls en 2024. Y para que puedas verla funcionar, en La Cabina, nuestro Centro de Demostraciones en el Head Quarter de Telefónica, puedes visitarla para ver en tiempo real cómo funciona, como los servicios digitales llaman a las APIs, como se procesan los datos, etcétera.
Figura 6: En La Cabina puedes ver el número de servicios digitales conectados a la 4ª Plataforma en España (126) consumiendo 110 familias de APIs y generando millones de APIs y consumos de datos normalizados. Todo en Cloud, en La 4ª Plataforma.
El objetivo era controlar el core tecnológico de nuestros servicios digitales, y por eso construimos esta plataforma y continuamos haciéndola más grande como arquitectura RAG con modelos de GenAI, y ahora agentes.
Si vas a La Cabina, puedes ver todas estas tecnologías en producción. Incluido Open Gateway, que es nuestro foco principal hoy en día, y se apoya 100% en la 4ª Plataforma (Kernel).
Aura: Codename "YoT"
Este fue un proyecto mucho más complejo, y que tenía un propósito muy diferente. Se trataba de dotar a nuestras tecnologías de capacidades de lenguaje natural Chat/Voz sin darle el control a tercero que nos intermediara en la relación con el cliente. Y por eso comenzamos a construir YoT (You on Telefónica), que luego bautizamos como Aura.
Lo que no queríamos era que los datos de nuestros clientes se quedaran en asistentes generalistas, que buscaban que nos integráramos con ellos. Además, independientemente de que tuviéramos integrados los interfaces de procesamiento de lenguaje natural en Smart Speakers como Alexa o Google Home, eso no nos solucionaría el problema de las webs, los contact centers, las apps móviles, herramientas internas, etc... Debíamos construir las APIs, las intents, y luego buscar en que canal lo integrábamos para llegar al cliente.
Figura 8: Aura, en Vivo Brasil
Así que construimos Aura, y lo integramos en la Televisión, en el Mando Vocal, en las apps, en las llamadas al Contact Center en los países y, puntualmente, en algunos asistentes de terceros con algunas capacidades y funciones limitadas. Queríamos controlar el motor de lenguaje natural e implantarlo en nuestros servicios para clientes. Y ahora, con la llegada de los LLMs y la GenAI, tenemos muchas más posibilidades gracias a eso.
Hoy en día Aura, que está en Brasil, España, Alemania y UK en múltiples canales, con millones de usuarios, y es pieza clave en la estrategia de accesibilidad que viene ahora en Europa. El objetivo era controlar la interacción con el lenguaje natural con nuestros clientes a la par que se desarrollaba esa necesidad - no todos los clientes gustan de chatear o hablar a los servicios digitales -, sin caer en la dependencia de terceros y poder controlar el canal que seguro que iba a ser importante en el futuro.
Movistar Home Connect
Este tercero es uno de los más interesantes proyectos que hemos construido, y de los más difíciles. Y fue un proyecto por el que tuvimos internamente muchos debates y análisis profundos. Y con un objetivo muy concreto que conseguir. Pero dejadme que os lo cuente en detalle que esta historia es de las que me gusta contar a mis compañeros en las cenas.
Estábamos en el año 2016 y el hype de Alexa tenía a todos muy nerviosos. Amazon había hecho una propuesta de un producto muy cool que se disfrutaba en los hogares. Y nosotros teníamos ahí mucho que proteger. Amazon tenía Alexa y Prime Video, FireTV, y Google tenía Android TV, Youtube e iba a sacar Google Home para el hogar en esas fechas. Estaba claro que se abría la batalla por el hogar, y nosotros teníamos mucho que defender allí.
Figura 10: Solución de SmartWifi
En el pasado, cuando nosotros llevamos Internet a los hogares, los ejecutivos de Telefónica, en concreto el mítico Julio Linares, puso en la estrategia proteger la conexión a Internet de Banda Ancha de los hogares mediante una solución WiFi, para que así no éramos intermediados por un dispositivo que estaba apareciendo. Ese fue el nacimiento de SmartWiFi en el grupo Telefónica.
Después, para consolidad nuestro posicionamiento en el hogar apostamos por la Televisión de Digital de Pago, con soluciones IPTV y OTT, incluyendo el descodificador con sistema operativo propio para no ser intermediados y soluciones en forma de apps para las SmartTVs. De hecho, hubo hasta una iniciativa en la que se construyó el descodificador de Telefónica dentro de algunas SmartTvs, aunque no acabó de cuajar. Con esa misma idea de "Home is our Territory", se trabajó en lanzar también Movistar Prosegur Alarmas o Solar360, buscando, como en las buenas partidas de ajedrez, controlar el "centro del tablero".
Figura 11: Presentación Completa del "hogar digital" en Ilustres Ignorantes
Pero estábamos en el año 2016, en medio del boom de Alexa y la corriente con Google Home ( e incluso Cortana ), donde algunas empresas de telecomunicaciones lanzaron su asistente y su smartspeaker para la televisión, como Magenta de DT. Y sí, en Telefónica había un equipo que había diseñado un proyecto de SmartSpeaker, con prototipos, business plan, etc... pero teníamos muchos debates sobre ello. Nunca íbamos a poder competir siendo un asistente para todo. Sin embargo, los tres casos de uso más importantes para estos dispositivos eran la música, la televisión, las llamadas de teléfono. Y nosotros controlábamos dos de ellos.
En Telefónica, no convencidos con el SmartSpekar, el equipo de dispositivos de la unidad de CTO había evolucionado el teléfono fijo a un sistema de teléfono digital en el hogar con pantalla táctil. Yo tengo uno de esos prototipos en mi despacho, que os dejo en foto. La idea era aprovechar el lugar que ocupaban todavía muchos teléfonos fijos en las casas de nuestros hogares, para meter un teléfono digital táctil con más capacidades, como controlar la televisión o tener un Second Screen. Así que, después de muchos debates decidimos que no había que lanzar el SmartSpeaker, y que aprovechando Aura y su integraci´no con la Televisión podríamos lanzar un SmartDisplay para frenar la entrada de Alexa en los hogares.
Figura 12: Prototipo de Movistar Home que guardo en mi oficina
Sabíamos que la mayoría de nuestros clientes seguían usando el mando y no tenían ningún SmartSpeaker en su salón, así que si para los que tenían inquietud por estos dispositivos les dábamos una solución como 2nd Screen para la Televisión y llamadas con Aura, podríamos defender nuestra posición y mitigar el impacto del "hype". Al mismo tiempo había que evolucionar a la máxima calidad los servicios de televisión, y comenzamos con una estrategia de agregar terceros, meter el mando vocal e introducir experiencias como Living Apps, Radio, Podcasts, etc...
Figura 13: Living App de La Liga en Movistar Home
Al final lanzamos Movistar Home, con sólo unas decenas de miles de dispositivos que construimos y vendimos, paramos el hype de Alexa en nuestros clientes sin darles las llamadas ni la televisión. Después llegó la crisis de los chips, y decidimos que todo el software de Movistar Home lo íbamos a migrar a una app, que comenzamos a construir en 2022, para tener la primera versión de Docking Mode de Apps, gratis para nuestros clientes. Y sí, con control de la televisión y las llamadas, para que sigan pudiendo tener la misma experiencia.
Figura 14: De Movistar Home a Movistar Home Connect vía app
presentado en el Innovation Day, como app gratuita de innovación.
En este caso, este proyecto tenía unos objetivos muy concretos, con unos recursos muy limitados, y con una carga de innovación e incertidumbre altísima, pero no sólo nos ayudó a frenar la entrada de los SmartSpeakers como interfaz único con el usuario en casa de nuestros clientes, sino que consiguió que la plataforma de TV creciera en valor, y la estrategia de integrar plataformas en España ha llevado a que Netflix, Prime, Disney+, FlixOlé o Mi Tele están integrados en el descodificador, y otros como HBO Max, Apple TV+, Warner o Sky Showtime integran directamente el contenido.
Figura 15: Con Antonio Guzman presentando Hogar Movistar
con Living Apps y Movistar Home Connect en Innovation Day 2024.
Hacemos tecnología que nos ayude a que "Home is our territory", por eso integramos también Movistar Cloud, Perplexity, hacemos Living Apps de deporte, cuentos, Tv-Commerce y seguimos evolucionando Movistar Home Connect.
Por supuesto, hay muchas tecnologías que no construimos nosotros. Hay también muchas tecnologías de innovación que son experimentales, que tienen un riesgo de morir pronto muy alto, o que simplemente hay un cambio de contexto que obliga a rectificar la estrategia. No tiene sentido hacer todo, ni mucho menos, pero proteger el valor a largo plazo y dejar las fichas de ajedrez en la mejor posición posible es parte de la responsabilidad de los que hacemos tecnología para una empresa.
Espero que estas tres historias de cómo y por qué hemos hecho algunas plataformas os hayan entretenido, que para nosotros han sido muchas, muchas, muchas horas de pensar y ejecutar. Cada una de ellas tiene parte de la vida de todos los que hemos trabajado en ellas. Y por supuesto, hoy hacemos OpenGateway y acuerdos con Perplexity, e inversiones en otras tecnologías, y cada una tiene su historia detrás, pero esas os las contaré dentro de unos años... que ahora estamos en plena ejecución. }:)
Ya hemos visto muchas veces el debate de las cookies publicitarias en las páginas web de navegación en Internet. El poder controlar las cookies que hacen un perfilado de una persona hace que los anuncios sean más ajustados para el visitante de la web, y eso hace que para los anunciantes tenga más sentido anunciarse en las webs que mejor perfilan, y eso hace que los sitios webs ganen más dinero con los anuncios si son capaces de perfilar a los visitantes y tener el anuncio adecuado para cada navegante.
Figura 1: Utiq Consent Hub - Cookies Publicitarias y Muros de Suscripción
Hasta aquí todo fácil de entender. Perfilado implica Dinero. Así de sencilla es la ecuación, pero con la llegada de GDPR, muchas de las cookies dejaron de poder utilizarse para perfilar a los navegantes, porque las webs deben dar la opción de rechazar las cookies de perfilado y el consentimiento para compartir estos datos con terceros, y llegó el "Subscription Wall", es decir, acepta las cookies o suscríbete y paga.
Figura 2: Susbcription Wall
El asunto es que las cookies no se han ganado mucho cariño por los ciudadanos de la red debido a lo difícil que ha sido poder controlarlas, saber qué hacen, y sentirse demasiado "perseguidos" por los anuncios sin poder librarse de ellas fácilmente. Así que muchos fueron los que empujaron por el mundo "Cookieless" que poco a poco está llegando.
Figura 3: Solución de Utiq en Marca.com
Una propuesta alternativa a este mundo es la que hace Utiq, una startup creada entre Orange, Vodafone, Deustche Telekom y Telefónica, donde se utilizan identificadores desde la red móvil con privacidad, que se pueden eliminar de manera sencilla a través de un gestor de consentimientos.
Figura 4: SMS con información de Utiq.
La idea es tan sencilla como que un sitio que utiliza Utiq y quiere dar las dos alternativas - Navegar Gratis o Pagar Suscripción -, puede darle al usuario la opción de ser perfilado por medio de estos identificadores de red. Los usuarios que aceptan utilizar Utiq, recibirán un SMS con información de Utiq, y la URL del Consent Hub de Utiq que es el panel en el que cuando el usuario lo desee, puede ir y eliminar el consentimiento de uso de ese identificador para ese sitio web.
Al Consent Hub de Utiq se accede desde tu conexión móvil, pero yo he accedido desde mi Mac haciendo una sesión de Internet Tethering con mi iPhone, por eso se ve la versión Web de escritorio en la imagen anterior. En la imagen siguiente se puede ver que tienes la opción de "No usar nunca Utiq" o de "Gestionar tus consentimientos" que ahora mismo está vacío. Es decir, no se ha generado ningún identificador de red de tu conexión para ningún sitio web.
Cuando se acepta el uso de Utiq en un sitio, por ejemplo en la web de ejemplo de marca.com, lo que tendremos es este domino en la lista de nuestros consentimientos concedidos, pero con un clic en la papelera, eliminamos este consentimiento desde ese instante en adelante.
De esta forma se intenta conseguir que los sitios de contenido gratuito que viven de la publicidad, puedan también garantizar al usuario que este tiene el control de sus identidades digitales y perfilado con un panel de control para todos.
Si accedes desde el móvil a la URL de https://consenthub.utiq.com/ podrás acceder al panel de control delos consentimientos de Utiq que tienes en tu control.
El modelo de negocio de los llamados Data Brokers es algo muy activo en los Estados Unidos, donde la regulación no es tan estricta como el GDPR que tenemos nosotros en Europa. Yo lo sufro en primera persona porque hay empresas que se dedican a vender números de teléfono y direcciones de correo de todo tipo de perfiles, incluidos los ejecutivos de compañías para hacer campañas de venta. Pero como vamos a ver en este informe, datos mucho más allá de los simples datos de contacto.
No es casual que yo solo utilice MyPublicInbox como forma de contactar conmigo si no nos conocemos, y que no conteste ninguna llamada, ni devuelva ningún mensaje que venga de quién no esté en mi circulo cercano. Es la única forma de proteger mi tiempo para poder sacar a tiempo mis proyectos.
Pero es que la venta de datos va más allá de los datos de contacto en el mundo de los grandes Data Brokers, donde se comercializan toda clase de datos, médicos, socioeconómicos, políticos, de actividad, e insights generados. Y a precios bastante ridículos. Yo hablé de la importancia de todos estos datos en una charla que di en el año 2016 en un evento organizado por mis amigos de Repsol, que decía "You are where you are", donde única y exclusivamente hablaba de la localización, pero ya es más que "crappy".
Comprando datos para comprometer la seguridad nacional
La compra/venta de los datos se ha convertido en una poderosa arma, que utilizada políticamente de forma masiva dio lugar al escándalo de Cambridge Analytica, donde se utilizaron políticamente para ayudar a desequilibrar la balanza hacia un lado un otro en múltiples votaciones. Hechos que abrieron temporalmente los ojos del mundo, pero que parecen ya de otros tiempos, cuando la realidad es que esto sigue siendo el día a día.
En un estudio que se ha publicado este mes, titulado "Data Brokers and the sale of data on U.S Military Personnel" se explica cómo de sencillo es para cualquiera conseguir datos sensibles del personal militar americano aun cómodo precio de 12 céntimos de dólar por registro, lo que puede dejar a un potencial adversario información de inteligencia sobre el personal militar de EEUU a un módico precio. Nada de los grandes maletines con millones y millones de dólares en billetes que veíamos en las películas.
Todo mucho más rápido, sin saltar por montañas, robar microchip, o archivos de inteligencia en bases secretas donde para entrar había que explotar bombas e infiltrar un comando militar encubierto. No, solo con llamar por teléfono a un Data Broker, pedir precios, tipo de información que venden, pagar y listo.
Y como he dicho antes, no se trata sólo de datos de contactos, sino que tienen insights que pueden llegar a ser de lo más sensibles, como podéis ver en el "menú de compra de datos" de uno de los Data Brokers. Es decir, información detallada hasta para saber quién va al casino o le gustan los juegos de azar.
Como os podéis imaginar, esta información es perfecta para hacer APTs preparados contra personal militar que pueda tener un impacto mayor contra alguna organización del ejercito de los EEUU. Desde luego, si eres una organización que tiene adversarios que este tipo de datos se consiga tan fácilmente no es lo que quieres.
Figura 6: Datos conseguidos usando dominios de USA
En la tabla anterior se pueden ver qué tipos de datos de fueron capaces de comprar utilizando dominios de correo electrónico para las comunicaciones ubicados en USA y en la de abajo, los datos que consiguieron usando dominios de ASIA. En ambos casos, datos muy sensibles.
En todos los casos, datos muy sensibles de personal que trabaja en una organización tan importante para la seguridad nacional como el militar, del que llegaron a conseguir datos de alergias médicas, tal vez conseguidas de restaurantes, hoteles y clínicas por los Data Brokers.
Está claro que los datos son un negocio, pero estos ejercicios demuestran que es necesario controlarlos, porque estamos haciendo que sea muy fácil que lleguen a manos de cualquiera. Leer esto, me ha recordado el cuento que cree de "You Leak it!" donde una empresa compra los datos que un ex-empleado puede vender de su empresa nada más ser despedido, pero a lo bestia.
Ayer jueves dediqué un rato de mi día a leerme un paper académico publicado por el equipo de Microsoft Research que trata el problema de la filtración de datos que identifican a personas en los LLM que se generan hoy. Es decir, cómo un atacante haciendo algo de Prompt Injection, es capaz de descubrir PII (Personal Identificable Information) del set de datos privados con que fue entrenado dicho modelo.
Estas técnicas de ataque no son nuevas, y están entre nosotros desde que los LLMs se encuentran también en nuestras vidas, y el artículo en cuestión, titulado "Analyzing Leakage of Personally Identifiable Information in Language Models" los explica e intenta crear una métrica para saber cuando de "leaky" es un LLM.
Al final, el misterio de tener toda la información personal disponible para entrenar el modelo o no, es un equilibrio entre privacidad y usabilidad, ya que cuanto con más datos privados ha sido entrenado un modelo, más puede aprender. Como sucede con los modelos de predicción de texto que se utilizan en los teclados de los smartphones o en la escritura de correos electrónicos en Gmail u Office.
Si se entrenan con nuestros datos sin filtrar, serán más útiles, pero al mismo tiempo si alguien tiene acceso a ellos tendrá la oportunidad de sacar muchos más datos personales jugando con el modelo, haciendo lo que se llama el "Tab Attack" porque es similar a dar al Tab para que autocomplete con el dato correcto el teclado predictivo.
En el caso de los LLM que se entrenan con datos sin filtrar, o con un conjunto de datos filtrados y otros no, nos podremos encontrar que la información PII puede ser filtrada mediante el uso de la API, solo con solicitar actividades vía Prompt Engineering, como contar una historia. Este ejemplo muestra que, al pedir que se cuente una historia, los datos PII son utilizados como parte de la respuesta.
Algo que hace que la narración sea más perfecta, es decir, que el grado de "Perplejidad" sea mejor. Al final, la "Perplejidad" es el grado de confianza que tiene el modelo en que la respuesta que está ofreciendo el modelo es válida. Así que si utiliza PII, la "Perplejidad" será mejor. Esto lo explica muy bien el artículo del año 2021 "Training Data Leakage Analysis in Language Models".
Como ya conocemos este, problema, la curación de datos para generar LLMs tiene un proceso de "Depuración de Datos Personales" o "PII Scrubbing", donde se enmascaran aquellas partes del set de datos que contienen PII, para que modelo entrenado genere las respuestas con datos enmascarados, lo que hará que los resultados tengan menos filtración de información cuando se pide generación de respuestas vía Prompt usando el API.
Sin embargo, ya existen técnicas para encontrar aquellos datos que siguen en el modelo a pesar del PII Scrubbing, utilizando técnicas de Reconstrucción e Inferencia de PII, que se han explicado en diferentes artículos académicos en el último par de años.
Reconstrucción e Inferencia de PII en LLMs
El funcionamiento es bastante curioso, y utiliza una mezcla de Prompt Engineering y análisis de Perplejidad, como se explica en este caso que es muy claro. Veréis, el atacante sabe que alguien ha matado a alguien en un asesinato cerca de una ubicación concreta. Y quiero saber si está información, que aparece en datos de carácter legal, ha sido eliminada de los datos de entrenamiento en el proceso de Data Scrubbing. Así que la frase en cuestión que busca resolver el atacante es
"A murder has been committed by X and Y in a bar close to the Rhine"
Si esa frase no ha sido bien filtrada de PII, entonces el atacante puede utilizar un proceso de Reconstrucción y de Inferencia, haciendo un rellenando parte de la expresión con un modelo de lenguaje que complete con posibles datos PII que se quieren probar. Así, con el modelo de lenguaje externo se generan las alternativas con los "sospechosos" o "candidatos".
"A murder has been committed by John Doe and Teo Peric in a bar close to the Rhine"
"A murder has been committed by John Doe and Ana Jacksic in a bar close to the Rhine"
Y analizar cuál de los dos es el que está en el sin filtrar en el proceso de PII Scrubbing en el LLM, consiste en analizar cuál es el grado de "Perplejidad" que se obtiene con cada uno de los candidatos, ya que el que esté en el Data Set de entrenamiento sin filtrar tendrá un grado de confianza mayor que será descubierto por su "Perplejidad".
Este tipo de análisis lo que permite saber es cuál es el nivel de filtrado de PII en un modelo que haya podido ser entrenado con documentos que puedan tener datos de afiliación de personas, especialmente con datos médicos, legales o ideológicos de personas.
Estas técnicas me recuerdan mucho a las técnicas de inyección de comandos, como Blind SQL Injection, Blind LDAP Injection, Blind XPath Injection, etcétera, donde la extracción de información de la base de datos (SGBD, LDAP o XML) era el objetivo de la inyección.
Ahora, el conocimiento de un modelo de LLM una vez entrenado es la nueva "base de datos", y las técnicas de Prompt Injection o análisis de perplejidad en procesos de inferencia y reconstrucción la forma de hacer el ataque. Un mundo nuevo para estudiar y desarrollar nuevas técnicas de hacking.
Los equipos de Shaadow.io y Tranxfer nos hemos unido para darnos una solución frente a un problema diario. Una pandemia, un mundo globalizado y la constante digitalización de las empresas, son las motivaciones detrás esta alianza. Los canales digitales han abierto la puerta a un nuevo modelo de comunicación, más rápido y eficiente, y se ha multiplicado el intercambio de información, y el envío de documentos entre empleados y entre empresas.
Figura 1: Transferencia de archivos privados con Tranxfer
Cómo consecuencia de esta masificación de envíos, se pierde mucho del control que tienen las empresas cuando estos archivos se comparten en la red y el entorno de trabajo de los empleados, y pasan a enviarse vía plataformas de transferencia de documentos públicos a través de Internet.
Shaadow.io
Fue para resolver dicha problemática, por lo que nació “Shaadow.io”, que identifica el origen de un documento que aparece filtrado en la red. Tienes en este blog publicados algunos artículos sobre Shaadow.io que ayudan a explicar bien cómo se puede utilizar esta tecnología para proteger la información.
Shaadow.io crea marcas invisibles al ojo humano y las inserta en los documentos, generando copias únicas para cada usuario. Estas marcas permiten, en caso de detectar una filtración de información, a quién pertenece este documento.
Por su lado, Tranxfer es una solución B2B para el envío de documentos a través de Internet entre personas, en un entorno privado y seguro. Los administradores de la compañía tienen control sobre qué documento se envía, quién lo envía, a donde lo envía, quién y desde dónde lo ha descargado, cuántas veces y durante cuánto tiempo está disponible.
Una solución que evita que la información de tu compañía esté colgada en URLs públicas en plataformas de transferencia de archivos gratuitas en Internet, que hace que el control de la información que tienes en tu empresa sea nulo.
Tranxfer + Shaadow.io
Volviendo al contexto actual, con el elevado número de ciberataques que ocurren día tras día no para de crecer, y las filtraciones de documentos de empresas están cada día llenando los titulaares de las noticias, hemos decidido acordar la integración de Shaadow.io en la plataforma “Tranxfer”, dónde desde ahora también se pueden marcar los documentos con la marca invisible y localizar las fugas de documentos de tu compañía.
Figura 4: Tranxfer y Shaadow.io se han integrado para el control de la información enviada
Ahora enviar archivos seguros y marcarlos para detectar posibles fugas de información es más fácil e intuitivo. Solo tienes que acceder al panel principal de Tranxfer, e introduce los destinatarios, el asunto y el mensaje del correo electrónico, en la parte izquierda del interfaz.
Una vez hecho esto, solo queda subir el documento al espacio destinado para ello en la parte derecha de la pantalla, y activar la marca invisible de Shaadow.io, tal y como ves en la imagen siguiente, pulsando en el icono de la huella dactilar.
Figura 6: Activación de Shaadow.io en Tranxfer
Hecho esto, ya se puede enviar la transferencia pulsando sobre el botón de “Enviar de forma segura” y le llegará una notificación por correo electrónico a todos los destinatarios. Los usuarios, cómo emisores, podrán acceder a la trazabilidad de la transferencia y ver todos los movimientos que están haciendo los destinatarios.
Figura 4: Resultado de la extracción de la marca Shaadow.io
En caso de que el documento apareciera filtrado, sólo con hacer una foto de éste y hacer la extracción de la marca tanto desde la plataforma Shaadow.io como también desde Tranxfer, podremos extraer la marca oculta y saber quién es el responsable de entre los destinatarios a los que se le envió la transferencia de este documento.
aaa
Puedes ver en este vídeo cómo funciona el proceso completo y paso a paso del marcado de archivos con la tecnología Shaadow.io en Tranxfer. Y si quieres integrar Shaadow.io en tu plataforma, o en tus procesos de control de información, en proyectos DLP, GDPR, o detección de fugas de datos o enemigos internos, no dudes en ponerte en contacto con nosotros. Escríbeme, y yo te ayudo con el proceso completo.
No es la primera vez que hablo del "Leak del Login", pero como sorprendentemente me lo sigo encontrado en muchos sitios, voy a volver a hacer un pequeño artículo hoy sobre él, pero centrándome en su relación con el GDPR y el Esquema Nacional de Seguridad, pues es común encontrarlo en webs que han pasado la auditoría del ENS y tienen sus documentos de GDPR en regla. Voy a volver a hablar un poco de él, solo por hacer hincapié de la necesidad de que se eliminen las webs "verbose" que dan afiliación de personas a sus servicios de manera tan sencilla.
Figura 1: El "Leak del Login", el GDPR y el Esquema Nacional de Seguridad
Por supuesto, no soy experto en leyes y regulación, que para eso cuento con un equipo maravilloso, pero creo que erradicar estos bugs en las webs - sea un incumplimiento o no - es bueno para los clientes o usuarios de un servicio online, sea este el que sea.
He hablado mucho sobre este tema, pero en resumen es tan sencillo como utilizar alguna de las capacidades de un servicio digital que se pueden utilizar sin haberse autenticado aún para saber si un usuario tiene o no cuenta en esa plataforma. Estas capacidades son tan comunes como:
Proceso de iniciar sesión o "Login".
Proceso de darse de alta o "Sign in".
Proceso de recuerpar contraseña o "Forget Password".
Estos tres procesos, que pueden parecer asociados a entornos autenticados, no lo son, pues todos pueden ser invocados sin necesidad de estar autenticado. Es normal que el proceso de "Iniciar Sesión" se lance desde una sesión no autenticada, al igual que es normal que un proceso de "Registro" deba realizarse desde una cuenta aún no regristrada, y lo mismo con el proceso de "Recuperar la contraseña".
Gestión de errores "verbose"
Todos son procesos tienen en común que en un determinado momento deben comprobar la identidad de la persona, ya sea por medio de un DNIe, un número de teléfono, un usuario o un correo electrónico, que es muy común. Y en todos ellos, la gestión de errores, debe ser clave, ya que si alguien puede usar un DNIe, un número de teléfono, un nombre de usuario o un correo electrónico de una persona que no sea ella, podría saber si tiene afiliación con esa plataforma. Es decir, si tiene una cuenta en ese servicio digital, lo que es un problema de privacidad, que puede ser utilizado como una forma de ataque contra la seguridad de la persona.
Figura 2: Se informa al que introduce el e-mail de si la cuenta existe o no en un proceso de Registro
Para que entendáis el proceso, es como si alguien llegara a la recepción de una empresa y comenzara a preguntar si es cliente suyo una persona, y luego otra, y luego una tercera, y así hasta el infinito. Lógicamente, esto es una aberración y seguro que ninguno de vosotros lo permitiría en su empresa. Dar la lista de personas que han usado los servicios es algo que no entra dentro de lo entendible. Si eres una plataforma de masajes, ¿dejarías que alguien preguntara si una persona es cliente o no te tu empresa? No.
Figura 3: Proceso de Recuperación de contraseña con Leak
Pero por desgracia si los mensajes de error en esos tres procesos no están controlados, es como si hicieras eso. Si cuando alguien pide iniciar sesión y el sitio dice "Esta cuenta no existe" cuando la cuenta no existe, y "Contraseña errónea" cuando la cuenta existe, pues ya has dado todas esa información en el Login.
Figura 4: Cuando la cuenta existe, envía el email de recuperación.
Lo mismo para Recuperar la contraseña, si cuando pones un e-mail, un DNIe o un número de teléfono, la web dice "La cuenta no existe" cuando no se ha dado de alta y "Te hemos enviado un mensaje para que continúes con el proceso" si la cuenta existe, pues lo mismo. Y en el proceso de Registro lo mismo, si te dice "esta cuenta ya existe" entonces, más claro el agua.
Cómo no ser "verbose"
Resolver este bug consiste en construir la lógica de manera que no llegue nunca un mensaje que sirva para saber si la cuenta existe o no en ninguna zona no autenticada. Y las soluciones son sencillas y se hacen en comunicaciones privadas. Cada uno de forma diferente, por ejemplo:
Login: Un mensaje de error de "Error en el usuario o la contraseña" en todas las situaciones en las que falle el proceso de login, no da ninguna información.
Registrarse: Se pide un correo electrónico o un número de teléfono, y se le informa por la web que se le va a enviar un mensajes para continuar con el proceso. Si la cuenta existe se informa por mensaje que alguien quiere crearse una cuenta con su identificador, que si es él ya tiene cuenta y puede recuperar la contraseña si no la tiene. Si es una cuenta nueva que aún no existe, se le envía un enlace al dueño del identificado para que continúe con el proceso de registro. De esta forma solo el dueño del e-mail o del número de teléfono pueden tener la información.
Figura 5: Proceso sin leak de información en proceso de Registro
Recuperar la contraseña: Con un mensaje de "Si esta cuenta existe, recibirá un mensaje en us buzón". Y se aplica la misma política que en el caso anterior. Se le envía el mensaje para recuperar la contraseña si existe y el enlace de darse de alta si la cuenta no existe.
En los tres casos, se consigue que no se dé información de afiliación de una identidad a un servicio, y por lo tanto se mejora la privacidad y la seguridad del cliente o usuario de la plataforma.
Riesgos de conocer la afiliacion.
No somos nuevos en esto, y ya hemos visto que conocer la afiliación de una persona es un riesgo para esta persona a varios niveles:
Perfilado social: Por desgracia, los algoritmos de generación de insights con Machine Learning nos etiquetan en todo, desde reputación en Internet hasta Credit Scoring, hasta los anuncios que recibimos en la web. En casos como los de Cambridge Analytica, vimos que este perfilado de forma masiva podría llegar a utilizarse para difundir Fake News adaptadas que cambiaran el curso de votaciones políticas. A muchos se les ha olvidado ya.
Ataques de Spear-Phishing: Si se tienen datos de que una persona tiene cuenta en una plataforma, hacerle un ataque dirigido de phishing para robarle credenciales, tokens OAuth o simplemente infectarle con malware es mucho más efectivo. Si recibes un phishing de un banco donde tienes cuenta es más fácil que piques.
Ataques de Watering Hole: Si se sabe que una persona visita un servicio o una plataforma, se puede encontrar con que la web sea vulnerada para atacarle a él, o simplemente que aparezcan otros usuarios maliciosos dentro de la plataforma que le hagan una encerrona más imaginativa. Como encontrar al amor de tu vida dentro de esa plataforma, y que no sea más que un ataque elaborado.
Así que, filtrar el "Leak del Login", genera muchos problemas para la privacidad y seguridad de las personas que es lo que hay detrás de los usuarios y clientes y de un servicio online. Personas.
GDPR y Esquema Nacional de Seguridad
Dicho esto, el "Leak del Login" es un bug de privacidad. Un fallo. Algo que es muy sencillo de explotar, pero que es un fallo, ya que filtra la afiliación de personas a una web, y por tanto hay que eliminarlo. Sin embargo, he visto muchas webs de grandes empresas - y seguro que es fácil localizarlo en muchas apps, y muchos dominios - que no le prestan la menor atención a esto.
Figura 7: Leak del Login en WordPress.com
Incluso los componentes comunes de login de plataformas de e-Commerce, CMS, Blogs, redes sociales como Instagram o TikTok sufren este bug. La propia WordPress.com tiene este "Leak del Login", pero es fácil encontrarlo en Bancos con DNIs, en redes sociales, empresas de transportes, etcétera.
Y por supuesto, con procesos de GDRP y de Esquema Nacional de Seguridad pasados, lo que me deja un poco perplejo. Creo que esto debería estar entre las pruebas de auditoría básica de cualquier servicio digital, al igual que la búsqueda de metadatos en todos los documentos ofimáticos publicados externamente. Así que, si haces auditorías de GDPR, de ENS o simplemente un Hacking Ético, por favor, reporta todos los "Leak del Login" a ver si somos capaces de mejorar un poco la privacidad de las personas.