innovación disruptiva en tecnologías de seguridad

Libro BBVA maqueta-ESP 1.indd 1Libro BBVA maqueta-ESP 1.indd 1 22/05/2015 14:07:1322/05/2015 14:07:13

d innoTSec14

Innovación disruptiva en tecnologías de seguridad

Cursos de Verano 2014Universidad Rey Juan Carlos

Campus de Vicálvaro

Madrid, del 30 junio al 2 de julio de 2014


EDICIÓN

PRODUCCIÓN

DISEÑO Y MAQUETACIÓN

Miguel Salgueiro / MSGráfica

IMPRESIÓN Y ENCUADERNACIÓN

Gráficas Monterreina

Depósito Legal: M-18110-2015


Curso de Verano 2014 d innoTSec14 – Innovación disruptiva en tecnologías de seguridad

Centro de Investigación para la Gestión Tecnológica del Riesgo CIGTR 3

ÍNDICE

PRÓLOGO ...................................................................................................................................................................................................... 5Santiago Moral

CUMPLIENDO CON EL CONTROL DE ACCESO BASADO EN LA LOCALIZACIÓN Y EL TIEMPO DE DATOS ALMACENADOS EN LA NUBE ........................................................................................................................................................... 7Claudio Soriente

INTELIGENCIA ARTIFICIAL Y MACHINE LEARNING EN LA INVESTIGACIÓN DE CAMPAÑAS APT ......... 23Vicente Díaz

CYBERPROBE: TOWARDS INTERNET-SCALE ACTIVE DETECTION OF MALICIOUS SERVER ................... 37Juan Caballero

PANDORA FMS: CÓMO COMPETIR CON LOS GRANDES FABRICANTES DE SOFTWARE SIN MORIR EN EL INTENTO ............................................................................................................................................................... 53Sancho Lerena

ESPECIALIZACIÓN E INNOVACIÓN PARA COMPETIR EN SEGURIDAD .................................................................... 65Andrés Tarascó Acuña

PROTEGIENDO LA INFORMACIÓN EN LA NUBE. TECNOLOGÍAS DE CIFRADO .................................................. 73Isaac Agudo


Centro de Investigación para la Gestión Tecnológica del Riesgo CIGTR4

d innoTSec14 – Innovación disruptiva en tecnologías de seguridad Curso de Verano 2014

INNOVACIÓN DISRUPTIVA EN TÉCNICAS DE CIBERCRIMEN ........................................................................................ 91Etay Maor

INNOVACIÓN EN IDENTIDAD ............................................................................................................................................................ 103Luis Saiz

ENIGMEDIA. INNOVACIÓN EN COMUNICACIONES CIFRADAS .................................................................................... 121Gerard Vidal

MESA REDONDA: INFORMACIÓN PERSONAL (PII), DERECHOS DE LOS CIUDADANOS Y REGULACIÓN INTERNACIONAL .................................................................................................................................................. 129Intervinientes: Luis Saiz, Isaac Agudo, Juan López-Rubio Fernández, Esther González Hernández y Pablo García Mexía Moderador: Miguel Ángel Cano Gómez

DETECCIÓN DE ANOMALÍAS CON APACHE SPARK ............................................................................................................ 151Sean Owen

PERCEPCIÓN DEL CRIMEN A TRAVÉS DE LAS REDES SOCIALES ............................................................................... 163Luke Sloan

UN MODELO DE COLABORACIÓN UNIVERSIDAD-EMPRESA: LA RELACIÓN ENTRE EL GRUPO BBVA Y LA URJC .............................................................................................................. 177Regino Criado / Santiago Moral Rubio

ÁLBUM FOTOGRÁFICO ........................................................................................................................................................................ 193

Los contenidos de las ponencias están disponibles en la página oficial de CIGTR www.cigtr.info. Se pueden consultar las transparencias y los vídeos en los canales oficiales de CIGTR en YouTube y SlideShare.




Por cuarto año consecutivo ponemos a tu alcance esta publicación que recoge las ponencias presentadas durante el Curso de Verano que impulsa el CIGTR

de la mano de la Universidad Rey Juan Carlos. En este curso de 2014 hemos tratado cómo las nuevas tecnologías, a la par de proporcionar oportunidades de conectar cada vez más nuestras vidas, también nos obligan a adoptar nuevas medidas para mantenerlas seguras. Estar preparado tanto para esas oportunidades como las amenazas que les acompañan requiere aproximaciones y formas de pensar diferentes. Al mismo tiempo, en las organizaciones crece rápidamente la preocupación respecto a la dirección a seguir dentro de sus planes estratégicos, en vista que esta evolución

tecnológica está sucediendo a una velocidad mayor de la que se sienten cómodas para gestionar.

El ecosistema en el que estamos inmersos, más allá de invitarnos a innovar, nos reta a ser disruptivos en nuestras ideas y soluciones. La innovación disruptiva se produce cuando incorporamos al mercado un producto, servicio, sistema, proceso o método organizacional que supone una ruptura con lo ya establecido, no siendo una evolución natural de lo ya existente. De esta forma, nacen tecnologías revolucionarias que representan puntos de inflexión en las prácticas establecidas, produciéndose cambios de alcance global. Este tipo de innovación, por lo general, es menos eficiente durante su incursión en los mercados que ya son maduros en la

PRÓLOGO

Santiago Moral RubioDirector de IT Risk, Fraud & Security. Grupo BBVA




práctica anterior, pero es muy competitiva en aquellos que están abiertos a una nueva oferta de menor costo, aunque presenten algunas deficiencias iniciales.

En este sentido las startups juegan un papel fundamental. Son éstas las que consiguen mostrar una mayor agilidad para adaptarse a las necesidades del mercado en comparación con las grandes corporaciones. Además, tienen mejores motivaciones para abordar nichos que en principio son pequeños y con poco margen de ganancia. Si esto a su vez se conjuga con una

colaboración estrecha y estable con universidades

u otros entes de investigación científica, es

posible obtener ventajas competitivas reales y

diferenciadoras, a la par que se promueve un

avance en el conocimiento.

Esta es la apuesta que hacemos desde el Grupo

BBVA para encontrar esas soluciones que van

a permitirnos afrontar los retos que se nos

presentan en el ámbito de la ciberseguridad y,

en esa línea, el contenido seleccionado para este

curso acompaña a esta estrategia.




El trabajo que os voy a presentar trata sobre el control de acceso que también tiene en cuenta el tiempo y el lugar. Quizá estéis familiarizados con los Servicios

Basados en Localización. Si miráis hacia las tecnologías disruptivas, los Servicios Basados en Localización son una de ellas. Esta charla trata sobre cómo asegurar este tipo de sistemas.

Voy a comenzar con una transparencia acerca del control de accesos (AC). Aquí está Alice, que es la propietaria de algunos recursos, como unos ficheros, y quiere aplicar unas políticas de control de acceso para esos ficheros. Ella no está siempre conectada, por lo que recurre al cloud,

llamaremos a este servidor como el punto de aplicación de políticas (PEP, Policy Enforcement Point). Lo que hace Alice es especificar un archivo y una política de acceso basada en la identidad de los usuarios, quienes se supone que van a acceder a dicho fichero. Por ejemplo, esa política de acceso debe permitir acceder a Bob o Charlie. Como hemos dicho, ya que Alice no siempre está conectada, transfiere el archivo y dicha política de seguridad al punto de aplicación de políticas, que es exactamente lo que el nombre sugiere, para hacer cumplir la política de seguridad en nombre de Alice. Para hacerlo, el PEP debe ser la puerta al archivo y debe de identificar a los usuarios. Esto significa que cuando Bob quiera acceder al

Claudio SorienteInvestigador senior en el Grupo de Seguridad de Sistemas (D-INFK) en el Instituto Federal Suizo de Tecnología (ETH) de Zúrich

El contenido de esta ponencia (diapositivas y contenidos audiovisuales) está disponible en la página oficial de CIGTR www.cigtr.info

CUMPLIENDO CON EL CONTROL DE ACCESO BASADO EN LA LOCALIZACIÓN Y EL TIEMPO

DE DATOS ALMACENADOS EN LA NUBE




archivo, su identidad se compara con la política de seguridad establecida y debido a que concuerda con ella, se le da una copia del archivo. De igual manera, si David quiere acceder al archivo, ya que su identidad no concuerda con la establecida en la política de seguridad, le será denegado el acceso a dicho archivo. Esto es lo que sería un control de acceso estándar basado en la identidad del usuario o, también, lo que sería basado en roles según una jerarquía organizacional.

Y, ¿por qué añadir localización al control de acceso? Hay algunas compañías que ya lo hacen a través de unos servicios llamados Recompensas Basadas en la Localización (Location-Based Rewards). La idea es que los clientes puedan conseguir cupones o descuentos por visitar unas localizaciones clasificadas como premium. Por ejemplo, Starbucks podría enviar una política que diga que si visitas uno de sus locales puedes llevarte un café gratis. Otra de las razones por la que se añade la localización al control de accesos es el llamado Geo-fencing. Un geo-fence es el perímetro virtual de un área geográfica donde puedes activar eventos cuando el usuario se mueve dentro o fuera de esa área. Por ejemplo, hay compañías que mandan datos sensibles a sus clientes a los que solo pueden acceder dentro de las instalaciones de la empresa. Por ejemplo, un banco puede establecer que solo se pueda acceder a ciertos datos dentro de las instalaciones del banco. Esto estaría dentro de lo que es el cumplimiento de la regulación, pero también conlleva implicaciones respecto a su seguridad. Symantec empezó un proyecto llamado ‘Smartphone Honey Stick Project’ cuya idea era dejar dispositivos en diferentes sitios de

las ciudades de Nueva York y Chicago, como si estuvieran perdidos. Estos dispositivos contenían archivos que claramente se habían marcado como confidenciales y lo que hizo Symantec fue monitorizar la forma en la que la gente que se encontraba estos dispositivos miraban esos archivos. El resultado del experimento fue que, incluso la gente que estaba dispuesta a devolver el dispositivo a su propietario, vio lo que contenían esos archivos. En este caso, si hubiera habido un geo-fence implementado en esos archivos, seguramente no hubieran podido acceder a aquellos datos sensibles a no ser que el dispositivo fuera devuelto a la zona establecida como geo-fence.

Además, cuando estableces una localización en tus políticas de control de acceso también tienes que mirar al tiempo. Para las Recompensas Basadas en Localización, el tiempo es importante porque quieres que los clientes se lleven dicha recompensa en localizaciones específicas en un momento en concreto, como la hora de apertura de ese local. Para el geo-fence tú quieres que los datos solo sean accedidos dentro de las instalaciones de tu compañía pero solo en las horas de trabajo. Desde esto sistemas puedes especificar ese tipo de políticas de seguridad que pueden llevarte a poner que tanto Bob como Charlie, pueden acceder al fichero si están en este lugar a esa hora. Además, puedes establecer dicha política de seguridad tan compleja como quieras por lo que quizá, estas dos personas, para acceder al fichero, deberían de estar en esta localización a esta hora, o en esta otra localización a esta otra hora. Todo eso lo transfieres al PEP, que debe almacenar los archivos, identificar a los usuarios y




debe tener capacidades de localización, es decir, debe localizar a los usuarios. Y, teniendo todo esto, puede resultar el principal problema aquí. Si echas un vistazo a los diseños de las soluciones que existen por un lado tenemos trabajos de investigación sobre políticas de seguridad, por otro lado tenemos soluciones de criptografía y en tercer lugar tenemos los sistemas desplegados, es decir, los sistemas que tenemos funcionando a día de hoy.

Vamos a empezar con las políticas de seguridad que suelen ser una extensión de los marcos de control de acceso basados en roles. Existe un estándar que define las políticas de control de acceso y que extiende su marco para expresar también los accesos basados en tiempo y localización. Por un lado, son claramente expresivos, puedes definir arbitrariamente una combinación de roles, localizaciones e intervalos de tiempo. Pero el problema es que ellos lo dejan en manos de una identidad que haga todo. Una identidad que almacena los ficheros, que cumple con las políticas de seguridad y que localiza a los usuarios. El problema es que esa identidad, el PEP, la consideramos de plena confianza. Confiamos en ella para acceder a los datos con textos claros y confiamos en ella para que aplique las políticas de seguridad correctamente. No hay forma para que Alice diga si esta persona de aquí está llevando a cado la política de seguridad de Alice de la manera correcta o no.

Echemos ahora un vistazo a los sistemas desplegados. Los sistemas desplegados están basados en el check-in, es decir, en estar en las localizaciones premium. La idea aquí es que el

usuario instala una aplicación en su smartphone con la que puede visitar dichas localizaciones premium, hacer check-in en esas localizaciones. Esos check-in se convierten en puntos y esos puntos dan derecho a premios, es decir, si tú consigues suficientes puntos podrías ganar un café gratis. Esto es lo que Bob va a hacer. Va a visitar un local de Starbucks, va a hacer check-in, el GPS de su teléfono está coordinado con el servidor de cupones basado en cloud, luego visita otro local, hace chek-in también, el localizador de GPS se pone en contacto con el servidor y, una vez que ha visitado un número determinado de localizaciones, el servidor de cupones le envía un cupón que a lo mejor permite a Bob conseguir un café gratis.

Una de las principales ventajas es que estos sistemas no necesitan una infraestructura de localización. No necesitan el PEP para localizar usuarios porque todo está basado en las coordenadas del GPS del teléfono del usuario. El hacer check-in es una acción voluntaria del usuario que dice al servidor que está en una localización en particular. Pero la localización del GPS puede ser falsa, el usuario puede ser malicioso y, en este caso, podría abusar del sistema. Es decir, podría enviar al servidor de cupones que él está en un local de Starbucks, mientras que realmente está sentado en su sofá. Además, tenemos el mismo problema que teníamos antes, que es que el PEP es de plena confianza para acceder a los datos y para cumplir con las políticas de seguridad correctamente por lo que no tenemos manera de decir si esta política de seguridad ha sido correctamente aplicada o no.




Para resolver el problema ante la aparición de usuarios maliciosos que proveen falsas coordenadas de GPS al servidor, hay algunas soluciones criptográficas. Una de ellas fue presentada en 2009 y está basada en pruebas de localización. La idea básica es que el PEP es ahora una identidad diferente de la infraestructura de localización. De hecho, aquí, la infraestructura de localización es ad-hoc en el sentido en el que está formada por puntos de acceso. Es decir, si una tienda quiere participar en este tipo de sistemas puede comprar uno de estos puntos de acceso y situarlo en la tienda. Estos puntos de acceso son pruebas de localización. Una prueba de localización es un estamento digital (a digital statement) que dice que un usuario estuvo allí en un momento determinado. Aquí, la idea es que Bob visita una localización y obtiene esta prueba de localización que tiene la identidad de Bob, el lugar y la hora, y esta línea de aquí que lo rodea significa que está inscrito en este punto de acceso. Bob también puede ir y conectarse a diferentes puntos de acceso para recoger varias pruebas de localización. La idea es que cuando ha recogido suficientes pruebas de localización, puede volver al PEP y el PEP puede comparar las pruebas de localización recogidas por Bob con la política de seguridad establecida para decidir si puede conceder o denegar el acceso al archivo a Bob. Esto significa que, aparte de hacer check-in de las pruebas de localización con la política de seguridad, el PEP también debe comprobar la validez de la política de seguridad. Las pruebas de localización son un sistema muy pragmático porque no necesitas el PEP para localizar usuarios, está separado. Y el usuario no puede falsificar

la prueba porque la única manera que tiene de recolectar una prueba de localización es ir y conectarse con la infraestructura de localización, es decir, ir y ‘hablar’ con uno de esos puntos de acceso que pueden emitir esas pruebas de localización. No está basado en las coordenadas del GPS del teléfono del usuario. Por otro lado, el PEP debe confiar en la infraestructura de localización por lo que antes de que el sistema pueda operar debe haber una relación de confianza entre estas dos identidades. Por eso, uno debe verificar la firma que es emitida por el otro. Además, volvemos otra vez al hecho de que confiamos plenamente en el PEP. Se confía en que puede acceder al archivo, que puede aplicar la política de seguridad definida por el propietario de un modo correcto.

Si miramos al espacio de diseño, si quieres desplegar un sistema así debería tener al menos tres componentes: la aplicación de políticas (alguien que verifique las credenciales de los usuarios que quieran acceder a los archivos), el almacenamiento para almacenar esos archivos y la localización (la manera de localizar usuarios). Hay una solución que es solo el PEP, es decir, un estamento que hace todo lo anterior.

Este es un ejemplo de sistemas desplegados donde no se aplica la localización en el PEP y confía en las coordenadas del GPS del usuario. Así es como, a día de hoy, funcionan los sistemas.

También, hay soluciones que separan el PEP de la infraestructura de localización. El PEP almacena los archivos y cumple con las políticas de seguridad mientras que la infraestructura de




localización, como su nombre indica, localiza los usuarios. Pero estas dos identidades tienen que confiar una en la otra, es decir, es necesario conseguir una relación de confianza para que los sistemas puedan funcionar.

Además, existen casos en los que todos los sistemas confían en el PEP para acceder a los datos y para cumplir con las políticas de seguridad. De nuevo, si estas personas son maliciosas el sistema se rompe.

Este es el punto de inicio del sistema que hemos construido, el LoTAC (Location and Time-based Access Control). Lo primero que debemos tener en cuenta es que no queríamos ningún PEP de confianza, es decir, no queríamos confiar en nadie para aplicar las políticas de seguridad instaladas por los usuarios. La idea era que nadie, aparte de los usuarios autorizados que están en una localización determinada a una hora específica, debería de ser capaz de acceder a los archivos. Lo que queríamos era aplicar las políticas de seguridad a través del cifrado. La propietaria de los datos, Alice, que es quien establece la política de seguridad, cifra el archivo con lo que nos aseguramos que solamente los usuarios autorizados, en el lugar correcto y a la hora adecuada, serán capaces de acceder al archivo cifrado.

Ahora, si dejamos a un lado la aplicación de las políticas de seguridad, nos queda el almacenamiento y la localización. Para el primero recurrimos a los servicios de almacenamiento en la nube como Dropbox. Lo único que necesitamos es un almacenamiento de los datos y acceso

ubicuos. Como sabéis, este tipo de sistemas no tiene capacidades de localización por lo que no saben dónde están los usuarios. Ellos pueden aplicar el control de acceso basado en la identidad del usuario por lo que puedes decir “quiero que mi amigo pueda acceder a este archivo”. Pero también queríamos dejar de lado esta opción. Una vez que tienes el almacenamiento, necesitas localización. La única infraestructura de localización que puede localizar usuarios a gran escala a día de hoy es el Cellular Network Operator (el operador de red móvil). No hay otra cosa que puedas utilizar si quieres desplegar un sistema que cubra un área geográfica determinada. Ellos no ofrecen servicios de almacenamiento, pero tenemos Dropbox para eso. Ellos sí pueden identificar y localizar usuarios, en este caso, en todo el territorio nacional. Una vez que tenemos esos dos componentes del sistema, no queremos que confíen uno del otro. Si esperamos a que un servidor cloud como Dropbox hable con un operador de red como Movistar, puede que esto no ocurra nunca. Por lo que queremos un sistema que integre perfectamente estos dos. Además, Movistar está bien para España pero si Dropbox quiere hacer negocio en otro país entonces tenemos que hablar con otro operador de red móvil y, quizá, en ese otro país haya más de un operador de red. Por lo que está relación de confianza entre ambos.no es fácil. Tú quieres un sistema que funcione a día de hoy y que integre perfectamente estas dos entidades.

Veamos algunos de los diseños que hemos escogido. Tenemos el operador de red móvil que puede identificar y localizar usuarios. Esto




es lo que pasa hoy cuando Movistar sabe dónde está y quién es su usuario o, al menos, cuál es la identidad asociada a su número de teléfono. El área está dividida en celdas dentro de la red 3G. Las llamamos localizaciones y para referirnos a ellas las presentamos con una letra “e”. Cada celda de localización está cubierta por un servidor de localización (a estos podéis verlos como una estación base de antenas que están repartidas por el territorio nacional). Un solo servidor de localización es el único responsable de localizar a los usuarios que están en su localización, que son los que están dentro de la celda 3G. Los servidores de localización tienen key pairs; hay una clave pública asignada a esa localización y hay una clave secreta. Por lo que para el resto de la charla quedaros con que localización es igual a servidores de localización que es igual a la clave pública (e1 = LS1 = pke1) de estas localizaciones. Es decir, tú puedes decir: esta es la celda número uno, la localización 1 (hay un servidor de localización que corresponde a la localización 1), tiene una clave pública que está expuesta y se mantiene secreta la correspondiente clave secreta. Así, puedes pensar en el área geográfica donde el sistema ha sido dividido en estas localizaciones como la unidad granular de nuestro sistema.

Acerca del servidor de almacenamiento (Dropbox puede valer pero podéis coger otro), provee un almacenamiento y acceso a los datos ubicuos, y no hace cumplir el control de acceso, por lo que Alice cifrará los datos, los subirá a Dropbox y Dropbox permitirá a cualquiera descargarse esos datos. Pero como están cifrados no nos importan las capacidades de control de acceso de Dropbox.

Y, finalmente, tenemos a los usuarios. Los usuarios acceden a los datos en movilidad, tienen dispositivos móviles. Ellos exponen una clave pública (Bob es pkb) y la clave secreta está almacenada de forma segura en sus teléfonos (esto sk). Tú puedes pensar fácilmente que estos pk, estas identidades digitales, están ligados a la tarjeta SIM de Bob. Hasta hoy Movistar ya tiene un delimitador entre la identidad del usuario y algunas claves que están embebidas en la tarjeta SIM, por lo que es fácil ampliar esto para incluir también estas identidades digitales.

Ahora, ¿cómo te gustaría que funcionase el sistema? La idea es que aquí tenemos a la propietaria del archivo, Alice, que empezó con él. Ellos encuentran que hay una política de seguridad que está basada en la identidad de los usuarios que deberían de acceder a ese archivo. También está basada en la localización y en las ventanas de tiempo donde esos usuarios deberían estar antes de intentar acceder al archivo. Por un momento, dentro de esta charla vamos a llamar a este grupo de usuarios el set de acceso, estará el conjunto de localizaciones y el tiempo, que enmarcan la política de seguridad contextual. Ahora, todo el set de acceso y la política de seguridad contextual están dadas como un input en la rutina de cifrado de todo el archivo y esto asegura los bits del archivo, por lo que aquí nuestros archivos están cifrados y son enviados al servidor de almacenamiento. Ahora, nadie puede descargarse ese archivo. Eventualmente, uno de los usuarios del set de acceso descargará el archivo y lo moverá cerca de estos servidores de localización que están definidos aquí, en la política de seguridad contextual. Lo que el servidor de




localización hará será aceptar el archivo cifrado de Bob y lo reproducirá de vuelta con el proceso de cifrado de texto. Este proceso está únicamente basado en la identidad del usuario quien ha iniciado el protocolo, la localización cubierta por este servidor de localización en el tiempo actual. En este punto, el servidor de localización no es consciente de que el fichero ha sido aceptado o cómo de compleja es la política de seguridad. Es un sistema que solo acepta inputs y que procesa esos inputs basados en estos atributos: la localización actual, la hora actual y la identidad de la persona que inició el protocolo. Una vez que Bob ha establecido una conversación con un número de servidores de localización suficiente, que cubren todas las localizaciones de la política de acceso, puede utilizar la clave secreta de su teléfono para descifrar el texto y acceder al archivo original. Así es como queremos que trabaje el sistema.

Para que esto funcione utilizamos algunas herramientas con las que algunos a lo mejor estáis familiarizados y otros no. Nuestra contribución al esquema de cifrado en dispositivos integra todas estas herramientas juntas que os voy a enseñar, que no son primitivas, pero no hay un esquema de cifrado que abarque a todas ellas, por lo que lo dividiremos para ello. La primera herramienta de la que voy a hablar es el cifrado basado en tags. Este es un diagrama del esquema de cifrado público, donde empezamos con un fichero. Lo cifras bajo una clave pública, éste es tu texto seguro (el círculo amarillo de la transparencia indica que es un texto seguro), el contenido está a salvo. Luego lo descifras utilizando la correspondiente clave secreta y vuelves a

fichero. El esquema de cifrado basado en tags es especial en el sentido en el que el cifrado utiliza una información pública denominada tag. Esta etiqueta se trata de una cadena arbitraria: cuando tú cifras un fichero en la parte pública tú puedes especificar un tag que puede ser cualquier cadena que puedas imaginar, incluso una cadena vacía, si quieres. Lo que pasa es que para descifrarlo no solo necesitas la clave secreta correspondiente a esta clave pública, también necesitas el tag original, de manera que si utilizas ambos puedes volver al fichero original. La seguridad en el cifrado basado en tags es este nombre que está aquí en la transparencia pero para descifrar el fichero original solo necesitas: uno, la clave secreta correspondiente a la clave pública, y dos, exactamente el mismo tag. Incluso si tienes la clave secreta correcta pero modificas un solo bit del tag (con lo cual este tag ya es diferente al anterior), lo que obtienes es algo diferente. Incluso, si eres el legítimo poseedor de la clave secreta correspondiente a esta clave de cifrado: tags diferentes pueden arruinar tu proceso de cifrado. Ésta es la primera herramienta que utilizaríamos.

Otra herramienta que utilizaríamos es Onion Encryption (cifrado por capas). Estaréis familiarizados con el cifrado Onion si conocéis Tor, la infraestructura de buscador caracterizada por el anonimato. La idea con el cifrado Onion es añadir capas consecutivas en el cifrado como una cebolla, lo que serían rutinas de cifrado en cascada. Si tenemos varias claves públicas; empiezas con tu archivo de texto, lo cifras bajo una clave pública y lo que obtienes es una capa de cifrado. Entonces, usas otra clave pública en ese texto ya cifrado, lo




cifras y obtienes dos capas de cifrado y así puedes seguir tanto como quieras. Aquí ya paramos a las tres capas. Para descifrar lo que necesitamos es eliminar estas capas, una a una. Si tienes la clave secreta correspondiente a estas claves de cifrado, empiezas con tu texto a salvo bajo esas tres capas, eliminas una con una clave secreta, obtienes la segunda capa de texto cifrado, eliminas otra con otra clave secreta y nos queda una capa de texto cifrado, y por último, eliminas la capa interna para obtener el fichero original.

Estas son las dos primeras herramientas que usamos en LoTAC. Y, ¿cómo las utilizamos? Bueno, lo primero que vamos a utilizar es la Onion Encryption. De nuevo, tú quieres que el usuario defina un set de acceso dentro de una política de seguridad contextual, hacer un input de esto en un contexto de cifrado con un archivo y, por arte de magia, tienes el texto a salvo fuera. Así que, para los usuarios del set de acceso, añades una capa de cifrado con la herramienta Onion Encryption, con la clave pública dentro del set de acceso. Así, si Bob está en el set de acceso, añade una capa de cifrado a este archivo con la clave pública ‘Bob’, de forma que solo él será capaz de descifrarlo. Para acomodarlo a la política de seguridad contextual necesitas hacer algo similar. Una capa más externa de cifrado será añadida a la clave pública del servidor de localización especificado en la política de seguridad contextual. Por lo que si quieres que Bob esté en la localización 1, tienes que añadir una capa de cifrado con la clave pública en la localización 1. Esto significa que solo el servidor de localización 1 puede ser descifrado con la clave secreta. Y puedes hacer tantas capas como quieras.

Si nos preocupamos de las identidades y la localización, también tenemos que preocuparnos por el tiempo. Para ello, utilizamos cifrados basados en tags donde estas etiquetas, estas cadenas arbitrarias que son utilizadas durante el cifrado, codifican el tiempo. Y un tag puede ser algo como esto [señala la transparencia], y puede ser tan complejo como quieras, por lo que eres libre de especificar intervalos de tiempo. La idea es que ahora, aparte de tener la clave secreta correcta aquí, cuando lo descifras también necesitarás el tag original. Este tag de aquí definido por Alice en la política de seguridad contextual no puede ser modificado, no puedes alterar esa etiqueta.

[Transparencia] Éste es un ejemplo donde tenemos a Alice con su archivo y ésta es la política de seguridad contextual. Alice quiere dar acceso a Bob. Aquí está en la localización 1, en alguno de estos días, y aquí está en la localización 2, en este día concreto, con unos intervalos de tiempo. Ahora, por un lado, tenemos los servidores de localización que exponen sus claves públicas, y en el otro lado, tenemos a los usuarios que exponen también sus claves públicas. Y, de nuevo, este es el set de acceso de usuarios autorizados y ésta es la política de seguridad contextual. Empezamos el cifrado en el set de acceso comenzando por el fichero cifrándolo con El-Gamal bajo la clave pública ‘Bob’: ya tenemos una capa de cifrado. Ahora tienes que acomodarlo en la política de seguridad contextual. Como la política de seguridad contextual dice que el primero tiene que estar en la localización 1 en este intervalo de tiempo, cogemos la clave pública del servidor




de localización 1 y añadimos una capa de cifrado utilizando el tag El-Gamal y aquí tenemos que especificar un tag. El tag es exactamente este tiempo. Como tenemos otra pista en la política contextual, hacemos el mismo proceso: coger la clave pública del servidor de localización 2 y utilizar esta cadena como tag. El tag basado en El-Gamal, la clave pública del servidor y esta cadena como segundo tag. Una vez que has terminado con el cifrado solo falta subir todo al servidor de almacenamiento, es decir, este blob [acrónimo de Binary Large Object] cifrado lo subimos a Dropbox. Una vez que esto está hecho también, cualquiera puede descargarse este blob cifrado pero solo los usuarios autorizados serán capaces de dar sentido al archivo que está escondido detrás del texto cifrado. Y, ¿cómo funciona una vez que Bob se ha descargado el texto cifrado? Bueno, el descifrado de este blob requiere la clave secreta del servidor de localización 2 con el tag que especificamos en su momento y eliminar la capa de cifrado. Una vez que esto está hecho, Bob tiene que ‘hablar’ con el servidor de localización que cubre la localización 1, por lo que necesitas la clave secreta de este servidor de localización además del tag original con el que se hizo el cifrado y, una vez que Bob ‘ha hablado’ con todos los servidores de localización de la política de seguridad contextual, puede eliminar la capa interior del cifrado usando su clave secreta. Y, ¿cómo funciona la interacción entre Bob y cada uno de los dos servidores de localización? La idea es que en algún momento, Bob se moverá dentro del área que cubre uno de los servidores de localización. Lo que los

servidores de localización harán es, en primer lugar, identificar a Bob donde él tiene que asegurarse de que es el usuario legítimo de esa clave pública. Una vez que esto está hecho, Bob manda al servidor de localización el blob cifrado y el tag usado cuando hemos realizado la capa de cifrado con la clave pública de este servidor de localización. La única cosa que queremos que el servidor de localización haga es comprobar el tag con el momento actual. Si el tiempo actual coincide con el tag (y recordar que para la seguridad del cifrado basada en tags Bob no puede cambiar esa etiqueta), puede borrar una capa de cifrado del blob utilizando la clave secreta. Ahora, Bob ha pasado de un blob de tres capas de cifrado a dos capas. Claramente, aún necesita conectarse con el servidor que permite eliminar la siguiente capa de cifrado y algo similar a lo anterior pasa ahora. Bob va y ‘habla’ con el servidor de localización 1, que está localizado dentro del servidor de localización base. Entonces el servidor de localización coge el texto cifrado emitido por Bob, el tag provisto por Bob, comprueba el momento actual con este tag y si los dos coinciden es posible eliminar una capa de cifrado utilizando la clave secreta. Una vez que Bob ha eliminado todas las capas de cifrado relacionadas con la política de seguridad contextual, será capaz de usar la clave secreta de su teléfono para acceder al archivo original.

Esto no es todo porque aún tenemos que tener cuidado con los usuarios maliciosos cuando colaboran para llegar al derecho de acceso. Este es un ejemplo de ataque si utilizáis el sistema que os he mostrado hasta ahora. Fue un problema complejo de resolver. La idea es que




Bob, para acceder a este fichero, tiene que estar en esta localización a una hora determinada pero Bob es perezoso por lo que solo está en la localización 1, es decir, solo está al lado del servidor 1, y no puede ‘hablar’ directamente con el servidor 2, así que lo que hace es pedir ayuda a un amigo. La idea era que, David, que está dentro del área del servidor de localización 2 provee el texto cifrado y el tag correcto. El servidor comprueba que el tag coincide con el momento, admite el texto cifrado de David y elimina una capa de cifrado. Lo que David puede hacer es pasarle el texto cifrado a Bob, por lo que Bob puede ‘hablar’ con el servidor de localización 1 en el momento adecuado, provee el tag correcto y elimina otra capa de cifrado, y Bob puede acceder al fichero escalado en el derecho de acceso. Nosotros queríamos que Bob fuera a las dos localizaciones, en dos ventanas de tiempo concretas, pero no fue así porque Bob consiguió la clave gracias a David.

¿Cómo resolvemos esto? Aquí tenemos otra herramienta llamada Re-randomization. De nuevo, os presento un estándar de lo que sería el diagrama de un proceso de cifrado donde tenemos un texto con una clave pública, su paso a texto cifrado y cómo, con una clave secreta, vuelve al texto original. Lo que podemos hacer es ‘re-aleatorizar’ el texto cifrado debajo de otra clave. Es decir, que si tú coges la clave pública que has utilizado para el primer cifrado tú puedes ‘re-aleatorizar’ el texto cifrado. Coges el texto cifrado, aplicas la clave pública original y lo que obtienes es su ‘re-aleatorización’. Mirad, esto es un círculo y esto es un hexágono, y esto te dice que estos dos textos cifrados no están vinculados. Si miras

a estos dos textos cifrados no puedes decir que éste es la versión ‘re-aleatorizada’ de este otro. La consecuencia de que tengan esta propiedad de no vinculación es que la ‘re-aleatorización’ ha sido utilizada hasta ahora para proveer de privacidad en redes mixtas o en otro tipo de tecnologías privadas. Lo usamos por seguridad. Veamos, una vez que has ‘re-aleatorizado’ estos dos textos cifrados se verán distintos pero utilizando la clave correcta serás capaz de descifrarlos. Es justo la manera de desvincular este texto cifrado de este otro, pero la confidencialidad mantiene las mismas propiedades, por lo que necesitas las mismas claves secretas. La idea es que si tú ‘re-aleatorizas’ el texto cifrado por el pk1 con otra clave pública obtienes este tipo de blob. Este de aquí que vemos que es la mitad amarilla y la otra mitad roja, y que muestra que dos claves públicas han sido utilizadas. Lo que pasa es que una vez que has ‘re-aleatorizado’ con una clave pública que no es la original que utilizaste para el cifrado, este texto cifrado no puede ser descifrado con la clave secreta correspondiente a la clave utilizada para la ‘re-aleatorización’, ni puede ser descifrada con la clave secreta correspondiente a la clave pública utilizada para hacer el cifrado original. Esto solo pasa en algunos grupos de texto cifrados por lo que tienes que tener en cuenta aquí las operaciones matemáticas para hacer que funcione. Para asegurarnos que este sistema tiene estas propiedades, una vez que has realizado el cifrado bajo una clave si tú lo ‘re-aleatorizas’ bajo la misma clave todo está correcto, pero si lo ‘re-aleatorizas’ bajo una clave diferente nadie va a ser capaz de descifrar el texto. Estas son las características que queremos.




¿Cómo utilizamos esto dentro de LoTAC? La interacción entre el usuario y el servidor de localización es exactamente la misma pero recordad que el primer paso es que el servidor de aplicaciones identifica a Bob lo que significa que comprueba que Bob es efectivamente el propietario de la clave pública. Una vez que esto se ha hecho, este texto cifrado que es devuelto desde el servidor de localización es ‘re-aleatorizado’ bajo de la clave pública de Bob. Veamos cómo funciona esto en caso de un ataque de colusión. Éste sería el gráfico que representaría a un ataque de colusión: David envía el texto cifrado y a continuación se devuelve el texto cifrado con una capa menos, pasa ese texto cifrado a Bob, Bob ‘habla’ con el otro servidor para eliminar la otra capa de cifrado y finalmente puede eliminar la capa interna con la clave secreta. Ahora, lo que pasa es que si este texto cifrado es ‘re-aleatorizado’ con una clave pública de David porque, de nuevo, aquí tenemos otro protocolo de identificación que se asegura que quien está hablando con el servidor de localización es David, y si este texto cifrado es ‘re-aleatorizado’ con la clave pública de Bob, observas que obtienes el mismo texto cifrado porque, eventualmente, la capa más interna es el mismo texto cifrado que re ‘re-aleatorizado’ con dos claves públicas diferentes. Con ello, Bob no será capaz de acceder al texto cifrado. Este truco garantiza que Bob debe ser el único que vaya a cada una de las dos localizaciones en las que están los servidores de localización en la política de seguridad contextual antes de ser capaz de acceder al archivo. Bob no puede solicitar ayuda de otros usuarios para no vulnerar sus derechos de acceso.

Este es el último truco que os voy a mostrar. También miramos a las macro-localizaciones. La idea es que tenemos servidores de localización que cubren las celdas 3G de las redes y tú puedes especificar políticas que definan una o más de estas localizaciones. Por lo que quiero que este usuario esté aquí, aquí y aquí antes de ser capaz de acceder al archivo. Pero, ¿qué pasa si quiero definir una macro-localización? Quiero algo como esto [en la transparencia]. Éste es nuestro campus, el cual, quizá está cubierto por varias localizaciones por lo que habría seis servidores cubriéndolo. ¿Qué pasa si Alice, quien ha definido la política de seguridad, quiere dar acceso a Bob que está en Vicálvaro en esta fecha? Esto significa que, a menos que Bob esté en alguna de esas localizaciones debería de ser capaz de acceder al archivo porque está dentro de la política de seguridad. Ahora, ¿cómo nos encargamos de esto? Aquí tenemos otra herramienta que se llama Re-cifrado (re-encryption), la cual, funciona de la siguiente manera. De nuevo, empezaremos con un gráfico que va desde el mensaje al texto cifrado con la clave pública al texto original con su correspondiente clave secreta. Ahora, quiero algo que coja este texto cifrado, que es amarillo (por lo que puede ser descifrado con la clave secreta amarilla), y sea rojo, con lo cual, puede ser descifrado con la clave secreta roja. Lo que quiero es cambiar la clave pública, bajo la cual está el texto cifrado, sin tener que descifrar y re-cifrar, y para ello tenemos un algoritmo que hace eso por sí mismo. La idea es calcular la clave de re-cifrado, para lo que tenemos un algoritmo de abstracción clave que coge la clave secreta que corresponde a esta clave publica que fue utilizada originalmente




para calcular el texto cifrado, y la clave pública bajo la cual quiero cambiar mi texto cifrado y obtengo mi clave de re-cifrado, por lo que esto es mitad rojo y mitad amarillo otra vez. Y esta clave de re-cifrado va desde 1 a 2, lo que significa que puedo transformar un texto cifrado que fue cifrado bajo la clave pública 1 a un texto cifrado bajo la clave pública 2. Una vez que cojo estas dos claves de re-cifrado hay un input al algoritmo de re–cifrado y transforma ese texto cifrado amarillo (por lo que puede ser descifrado utilizando la clave secreta amarilla), al mismo texto cifrado que puede ser descifrado con esta clave secreta roja.

¿Cómo utilizamos esto en el LoTAC? La idea es tener una jerarquía de ubicaciones dentro de la infraestructura de localización. Pensemos que tenemos algo como esto: Madrid que está formado por barrios y tenemos Vicálvaro (no sé si Vicálvaro es un barrio pero en este ejemplo asumámoslo así). Ahora, Serrano está cubierto por dos servidores de localización, Chamberí está cubierto por tres servidores de localización y Vicálvaro tiene tres servidores de localización también. Si creas una política de seguridad que diga que los usuarios deben estar en Vicálvaro, estos usuarios deberían de ser capaces de hablar con cada uno de estos servidores de localización [señala pantalla]. Los servidores de localización están debajo de nuestra jerarquía. La idea es que empecemos con el nivel más alto de nuestra jerarquía. He empezado con Vicálvaro, pero puedes empezar con España si quieres. La infraestructura de localización, Movistar, publica una clave pública para Vicálvaro y la clave de cifrado que permite a cualquiera cambiar un texto que estaba cifrado bajo la clave pública de

Vicálvaro a un texto cifrado bajo la clave pública de alguno de estos servidores. Por lo que la clave pública que está cifrada bajo esta persona puede ser transformada en una clave pública que podría ser descifrada por esta otra persona.

Y algo similar ocurre aquí. Empezamos en Madrid, cogemos la clave pública de Serrano o Chamberí y publicas la clave de re-cifrado. Todas estas claves son públicas para aquellos usuarios que se especifican en la política de seguridad. Una vez que tienes la clave pública de Serrano y Chamberí la utilizas para publicar la clave de cifrado para los servidores que cubren cada uno de estos dos barrios.

Una vez que todos son públicos, veamos cómo pueden ser utilizados. Asumiendo que ésta es la política de acceso, Alice quiere dar acceso a Bob si él está en Vicálvaro en esta fecha en concreto. Esto significa que el texto cifrado tendrá una apariencia como ésta porque la clave pública de Vicálvaro es azul, tú tendrás la capa más interna que es roja, para la clave pública de Bob, y la otra capa que es azul porque hemos utilizado la clave pública de Vicálvaro para crear una nueva capa de cifrado. Bob, a menos que hable con algunos de esos servidores, debería de estar bien, debería de ser aceptado por las políticas de seguridad porque cada uno de estos servidores es un servidor de Vicálvaro. ¿Cómo funciona? Asumiendo que Bob está en realidad hablando con el servidor de localización 8, por lo que está en esta ubicación, él coge este texto cifrado, coge la clave de re-cifrado publicada que cambia el texto cifrado de Vicálvaro a la localización 8, re-cifra el texto cifrado que cambia esta capa exterior de azul a morado y




ahora, debido a que esta capa es morada, puede ser procesada por este servidor de localización. Así que el protocolo funciona como siempre: Bob es identificado, envía el texto cifrado y el tag, esta persona verifica que el tag concuerda con el momento actual y elimina una capa de cifrado. Una vez que esto está hecho, Bob puede eliminar una capa más interna de cifrado y recuperar el texto original.

Todos estos son los trucos que utilizamos en este tipo de sistemas y de nuevo, nuestra contribución descansa en un esquema de cifrado que puede aunar todos estos trucos juntos. Ahora queremos evaluar cómo funcionan estos sistemas en la práctica. Hemos creado una implementación prototipo donde tenemos un servidor, clientes y la red cliente GMS. Estos [en la pantalla] son algunos de los resultados acerca de cuánto se tarda en cifrar el archivo, es decir, cuánto tiempo tarda Alice en crear un texto cifrado empezando por un archivo y una política de seguridad. Aquí vemos que está establecido en orden de segundos. También vemos que las habilidades del sistema son mejores en número de localizaciones que en número de usuarios, pero puedes emplear algunos trucos como la jerarquía de las localizaciones para hacer lo mismo con la identidad de los usuarios, por lo que ese aspecto puede ser mejorado sin problema. No obstante, en una versión no mejorada, la cifrado bajo 20 localizaciones y 75 usuarios no tarda más de un segundo por lo que el sistema es bastante rápido. Ahora, lo que realmente tenemos que saber es cuánto tarda el proceso de los textos cifrados para los usuarios de smartphones, es decir, cuánto tarda el hecho de que el smartphone establezca

una conversación con el servidor de localización para procesar el texto cifrado. Este es el tiempo que tarda cuando el smartphone del usuario está envuelto en este proceso donde, como podéis ver, todo lo que está dominado por la comunicación tarda unos tres segundos en descargarse el archivo cifrado, esto incluye un archivo simple de 20k. La comunicación entre el usuario y el servidor de localización tarda unos dos segundos y este cálculo se hizo en el servidor de localización y es el del descifrado final del usuario por lo que es bastante rápido también. Esto nos da la seguridad de que el sistema puede ser utilizado en los smartphones que nos encontramos a día de hoy.

Con esto he concluido. Para terminar me gustaría decir que la localización y el tiempo son definitivamente la forma de abrir tu modelo de negocio al desarrollo de nuevas aplicaciones a medida que se confía en el control de acceso. Aunque, a menos que encaucemos los problemas de seguridad, las aplicaciones de seguridad crítica no podrán aprovechar esta nueva tecnología. Y, como hemos desarrollado un sistema como este, a menos que nos preocupemos de especificar cuál es la infraestructura de localización correcta, en este caso, es el operador de red móvil porque es la única infraestructura construida que tenemos a día de hoy. Tienes otros sistemas que no son seguros, como aquellos que confían en las coordenadas de los GPS de los usuarios. Cuando se habla de localización muchos usuarios tienen miedo de dejar al descubierto su privacidad por lo que la localización privada es también un campo de estudio muy activo.




Aquí os dejo algunas de las investigaciones a las que he recurrido para hacer esta presentación y este es nuestro estudio que presentaremos en tres días aquí, en Madrid.

Turno de preguntas

Tengo dos preguntas. Una es: en este sistema de tags que has establecido y montado sobre un control de acceso basado en roles, ¿cuáles son las diferencias, si es que las hay, frente a las tecnologías publicadas que usan cifrado basado en atributos fundamentado en el emparejamiento bilineal? Y la segunda cuestión trata sobre el concepto de capas que has introducido y la posibilidad de la conmutatividad entre las capas, el hecho de que el orden sea importante o no, que es una cosa que puede resolver un cifrado basado en atributos y que no veo en el esquema que has contado. Gracias.

Son dos preguntas excelentes. De hecho, tengo dos transparencias que explican por qué el cifrado basado en atributos no funciona pero las quité por problema de tiempo. El principal problema con el cifrado basado en atributos es que es muy difícil definir intervalos. Así que, ¿cuál es la granularidad del atributo? ¿Es un segundo, un minuto, una hora, un día…? En el cifrado basado en atributos lo que tienes es, dependiendo del número de atributos que tienes, tu árbol de la política de seguridad que se basará en un logaritmo así de alto. Si el tiempo establecido de tu política es un día pero tienes un minuto de granularidad, necesitas muchos atributos debajo de ese árbol que has construido

para definir el acceso. Éste es un problema con el cifrado basado en atributos. No es muy expresivo cuando queremos establecer intervalos. Podría resultar para ajustar localizaciones pero los intervalos de tiempo no van a ser tan expresivos.

En segundo lugar, el cifrado basado en atributos es mucho más caro que el cifrado basado en El-Gamal, por lo que necesitará más batería en tu smartphone. Y, tercero, no queríamos confiar en ninguna de las partes del sistema y en el cifrado basado en atributos tienes este problema inherente. Debe haber una autoridad que tenga la clave secreta que está relacionada con esos atributos y esta autoridad es en realidad una persona que puede acceder a todos los archivos que se han subido. Por lo que hay un problema de seguridad inherente ahí. Por estas tres razones no hemos querido apostar por el cifrado basado en atributos. Pero cuando estaba preparando esta charla era una cuestión que apareció. Lo consideramos, pero no funcionó.

La otra cuestión relacionada con la conmutatividad de las capas. Déjame que vuelva atrás. En nuestro ejemplo, os mostraba que el servidor de localización 2 eliminaba la capa más externa y el servidor de localización 1 eliminaba la capa interna. Tú puedes hacerlo fuera de servicio y cómo te aseguras… Incluso, si lo haces fuera de servicio la política se cumple. La idea es usar las tags. Así que, incluso si Bob habla con el servidor de localización 1 en primer lugar, está bien siempre y cuando Bob lo haga en este periodo de tiempo. Puede que el 14 de julio hable con el servidor de localizaciones 1 porque está en la ventana de tiempo correcta, por lo que el servidor de localización eliminará




esta capa. El 16 de julio él hablará con el servidor de aplicaciones 2, el cual, eliminará esta capa. Él puede hacerlo en cualquier orden y son las tags las que hacen que las políticas de seguridad se respeten. Espero que esto tenga sentido… Esta es la versión hashed de El-Gamal en el que el grupo del texto cifrado es el grupo de residuos cuadráticos positivos que te da tus opciones de tags, la posibilidad de eliminar capas de cifrado en el orden que quieras, debido a que el grupo en el que estamos te da la ‘re-aleatorización’ que probablemente te permita prevenir que un texto cifrado sea descifrado si está ‘re-aletorizado’ con dos claves públicas, diferentes claves públicas, y esto te permite tener esta jerarquía de localizaciones que está permitida por esas claves de localización. Todo esto está en este esquema de cifrado.

Aparte de la infraestructura de la red de móviles, de confiar en esa parte de la infraestructura, implícitamente también estás confiando en la autenticación entre el móvil y esa infraestructura, ¿no? ¿No serviría un tipo de infraestructura que hiciese de proxy de esa infraestructura de comunicaciones? O sea, que tuviese una sincronización con la red de móviles pero que tú te conectases vía wi-fi o vía bluetooth. Eso no se podría hacer porque necesitas que esté autenticando el móvil, ¿no?

La idea es que sea la tarjeta SIM la que esté autenticada...

¿Pero tienes que utilizar ese canal explícito? ¿No sirve que te comuniques con un servidor web que tenga la red de móviles?

No. Por esta razón utilizamos el operador de red móvil porque es la única infraestructura de localización ubicua hasta ahora y te da la propiedad de añadir la identificación de usuarios en un lugar. No pagamos un coste por dicha identificación. Si el operador de red móvil, con su estación base habla con los teléfonos, están ya autenticados….

Pero no solo eso, sino que, ¿no te puede hacer alguien un relay? Porque esa autenticación que estás haciendo del móvil… para que alguien no te ponga un móvil que haga de relay y que te autentique el posicionamiento en cualquier momento y te hagan un ataque…

Sí. Eso sería posible. Nosotros somos tan seguros como segura es la localización y la identificación de la infraestructura de red móvil. No proponemos nuevos esquemas de localización por lo que estamos tan seguros como eso y no hay otra opción si quieres desarrollar un sistema como este a día de hoy. Si la infraestructura de red móvil es segura frente a los posibles relays, nuestro sistema también lo será.

Encuentro muy interesante la manera en la que tienes que lidiar con la colusión de usuarios, pero la pregunta es, ¿cómo evitas que Bob envíe su clave privada a David?

Si esta clave pública está embebida en la tarjeta SIM del usuario, y a día de hoy tienes tarjetas SIM que tienen claves públicas dentro. Podríamos utilizar la criptografía asimétrica que está desarrollada dentro para asegurarnos de que eso no pasa. Si se tiene en cuenta una tarjeta SIM como asistente dispositivo antisabotaje, la clave




de seguridad se almacena de forma segura dentro de la tarjeta SIM de Bob.

Uno de los problemas que tenemos en otras latitudes es lo referente a la suplantación de identidades en las operadoras. ¿Cómo podríamos restringir o controlar esa posibilidad de que me suplantes en la operadora y de que obtengan mi tarjeta SIM sin ser yo?

Es una gran pregunta, pero ahora mismo no tengo la respuesta en mi cabeza. Esto es más dentro de un nivel más físico ¿no? Con alguien que quiere

robar tu identidad debe proveer alguna forma de identificación. Creo que esto es lo que pasa ahora y no sé una manera mejor de sobrellevarlo pero en nuestro sistema damos por sentado muchas cosas como la identificación y la localización y esto es porque utilizamos una infraestructura de red móvil. ¿Cómo hacer frente al robo de identidades? Es un problema complicado. ¿Cómo hacer frente al robo de identidades cuando la autoridad de autenticación, en este caso, infraestructura de red móvil, se vuelve maliciosa? Es muy complicado, no tengo la respuesta en mi cabeza.




La idea de esta charla es ver qué técnicas de Inteligencia Artificial se pueden utilizar en la investigación de campañas APT. De hecho, en mi compañía nos dedicamos a

diario a investigar este tipo de nuevas amenazas, campañas de ciberespionaje, etc. Un tema que, a día de hoy, es bastante candente.

El objetivo de esta charla es explicar cómo se hacen este tipo de investigaciones y qué técnicas podemos utilizar: qué tipo de técnicas especialmente relacionadas con la Inteligencia Artificial tienen sentido de aplicar en este tipo de campañas. La idea es hacer un enfoque más práctico que teórico. Para ello, he intentado

realizar una aproximación con aplicaciones reales, con herramientas que podemos utilizar todos.

Lo primero sería definir qué es una campaña APT, ya que es una de las principales cuestiones que vamos a tratar en esta charla. APT son las siglas en inglés de Advanced Persistent Threat, que significa que es una amenaza persistente y avanzada. Se trata de un término que se acuñó entre el 2010 y 2011, durante el caso ‘Aurora’, que fue un ataque, en este caso contra Google, haciendo públicos algunos de sus detalles. A través de un zero-day, los atacantes tuvieron acceso a sus servidores y habían conseguido filtrar datos que aparentemente tenían destino

Vicente DíazAnalista Senior de Malware. Kaspersky Lab. Global Research & Analist Team (GREAT)


INTELIGENCIA ARTIFICIAL Y MACHINE LEARNING EN

LA INVESTIGACIÓN DE CAMPAÑAS APT




en servidores chinos. En aquel momento, cuando se hicieron públicos los detalles, otro tipo de empresas del mismo sector habían tenido ataques similares. Tras su relación, se confirmó que todos habían sido víctima de los mismos ataques. Por este motivo, se les calificó como Advanced Persistent Threat: Advanced porque se realizaban a través de un zero-day; Persistent, porque estaba infectados durante varias semanas o meses; y Threat, porque se trataba de una amenaza.

A partir de entonces, ese término se empezó a utilizar masivamente aplicándose casi a cualquier tipo de amenaza y, hoy en día, todo el mundo habla de campañas APT cuando en la mayoría de casos el término ‘Avanzado’ es muy relativo. Y es que, muchas veces, a lo mejor pasa que una entidad bancaria muy importante está infectada y resulta que realmente está infectada porque les han enviado un enlace que dice “haz doble clic aquí” para instalarte un archivo y ya está. Recuerdo que hubo un caso en el que se enviaron unos correos con un ejecutable, alguien ejecutó ese archivo, se infectó y trató de solucionarlo borrando el correo electrónico, creyendo que ya se habían librado del ataque. Por eso, muchas veces se hace uso del término Advanced cuando realmente no lo es. Lo que sí es cierto es que son persistentes, ya que, en la mayoría de los casos, cuando hacemos investigaciones de este tipo de campañas, las víctimas llevan años siendo objeto de robo datos y no lo saben.

Una de las campañas que a nivel nacional ha tenido más eco ha sido la de ‘Careto’. La verdad es que el nombre es muy particular. Es curioso porque, cuando me preguntan cómo nombramos

las campañas, la verdad es que nos basamos en algo que vemos dentro de la campaña y la identificamos así. Luego, a lo mejor, no va a ningún sitio, pero cuando llega a los medios, se hace una gran difusión de la misma y tienes que explicar el origen. La mayoría de las veces no tienen mucha gracia. En el caso de Careto, cuando nuestros compañeros nos preguntaban el por qué del nombre, no sabía cómo explicárselo. Careto es cuando te levantas por la mañana y te miras en el espejo, puede que ésta sea la mejor definición. Pero el caso es que dentro de la campaña de ciberespionaje que estuvimos investigando y que tiene su origen en 2007, lo que detectamos fue que algunos binarios tenían esta cadena de caracteres, ‘careto’, lo cuál era bastante particular. Pero, además, había una segunda cadena de caracteres que era una contraseña que se utilizaba para cifrar el tráfico que era ‘me cago en la mar’. Al final, no decidimos bautizar a la campaña con este segundo nombre, pero me costó mucho más explicar qué quería decir eso. En cualquier caso, se trataba de una campaña de ciberespionaje cuyo código utilizado para espiar a las víctimas era muy avanzado porque se ocultaba muy bien en el sistema, tenía muchas técnicas, tenía muchos módulos… Realmente, era un código malicioso muy destacable por su complejidad.

Todo empezó porque explotaba una vulnerabilidad en Kaspersky para intentar hacerse invisible en el sistema. Una vulnerabilidad antigua que ya estaba solucionada pero que, curiosamente, la explotaba. En cualquier caso, nosotros tenemos firmas para este tipo de cosas y, a partir de ahí, empezamos la investigación en




la que nos sorprendió la complejidad y lo grande que era esta campaña.

Uno de los aspectos más interesantes era que también tenía módulos para sistemas operativos, como puedan ser Linux. Vimos trazas en algunas víctimas que podían indicar que también tenían algún módulo para iPad y para OSX, aunque no encontramos nunca el código malicioso. De lo que sí nos dimos cuenta fue de la existencia de trazas muy características de Android.

Haciendo una radiografía de la campaña, el periodo en el que se concentró la mayor parte de su actividad fue entre los años 2012 y 2013, por lo que era bastante reciente en el momento en el que la estuvimos investigando. Encontramos más de 380 víctimas con más de 1.000 IPs de distintos países. Entre las víctimas se encontraban instituciones gubernamentales, embajadas, empresas de energía, empresas de investigación, etc. Marruecos fue el país con mayor número de IPs. El problema es que la mayor parte de las víctimas que había en Marruecos, por lo que creemos, eran parte del módulo para Android; y un teléfono con sistema operativo Android cambia con mucha más frecuencia que un dispositivo que esté fijo.

Simplemente quería utilizar este ejemplo para explicar qué entendemos nosotros por APTs, campañas de ciber-espionaje en donde, hoy en día, existen más actores para hacer este tipo de ataques.

La segunda definición que entra en la materia de la que vamos a hablar es la Inteligencia Artificial. En general, el problema de la Inteligencia Artificial,

como me dijo una vez un profesor, son las expectativas. Y es que Inteligencia es una palabra muy pretenciosa con la que nos imaginamos a una entidad que es totalmente independiente y que es capaz de pensar por sí misma. Quizá sí que es este el destino final de la Inteligencia Artificial, pero lo que quiero decir es que, hoy en día, lo que aplicamos aquí no es sino una serie de técnicas, una serie de algoritmos, una serie de herramientas que nos permiten hacer cosas muy interesantes. Y, este es el enfoque de esta conferencia: ver qué tipo de técnicas de Inteligencia Artificial nos ayudan a la detección de este tipo de campañas.

Una de las cosas que hice para llegar a una definición es mirar lo que incluye el curso de Inteligencia Artificial de Berkeley, entre los que tenemos temas de solución de problemas, temas de machine learning, clustering y análisis semántico, que es un área totalmente distinta. Una gran cantidad de temas, pero solo algunos de ellos son los que nos interesan para investigar las campañas APT. Pero antes, quisiera comentar que la Inteligencia Artificial es un área muy amplia, que toca muchos palos y que algunos de ellos nos pueden ayudar a investigar todo este tipo de campañas y otros no.

También, quisiera mencionar uno de los motivos por los que estoy aquí, que es quizá la conferencia que pronuncié el año pasado, en la cual hablaba sobre cómo detectar perfiles maliciosos en Twitter utilizando técnicas de machine learning. No quiero repetir esto, pero si alguien tiene interés podemos ver alguna cosa porque está ahí publicada y es que, es otra aplicación de esas técnicas, en




este caso, a un contexto distinto, como es el de detectar perfiles maliciosos en redes sociales.

¿Qué vamos a utilizar de la Inteligencia Artificial en el tema de las campañas APTs? Desde mi punto de vista, los aspectos más interesantes son los relacionados con data mining, clustering, temas de machine learning y, quizá, también, lo que toca a los sistemas expertos. Todo esto es muy complejo de por sí, pero creo que todos disponen de técnicas que nos pueden servir para ayudarnos en la investigación de este tipo de campañas. De forma colateral, os enseñaré algunas herramientas que ya utilizan todo este tipo de herramientas y que nosotros mismos no tenemos por qué implementarlas. En mi opinión, los mejores analistas son los que saben lo que hay detrás de las cosas, aunque no necesariamente tienen que ser expertos y ser capaces de desarrollarlas desde cero. Es decir, tenemos que saber cuáles son las herramientas con las que trabajamos, cómo nos ayudan, las limitaciones que tienen y qué es lo que hay por detrás, ya que, a veces, las utilizamos a ciegas, solo sabemos que no nos da ningún positivo y ya está. Pero si no sabemos lo que hay detrás, no sabemos por qué nos puede estar fallando y puede ser que no nos esté dando toda la información. Hoy en día, la investigación de APTs es una mezcla de este conocimiento, quizá muy técnico, y de un conocimiento más mundano sobre cómo hacer este tipo de investigaciones.

Vamos a ver cómo se investiga una campaña APT y, en cada punto, haré una referencia sobre qué tipo de herramientas y qué tipo de técnicas de Inteligencia Artificial podemos utilizar.

Lo primero que hay que saber es cómo empieza una campaña. Imaginaos las películas de detectives, cuando hay un asesinato y todo empieza con un cuerpo y un grito en medio de la noche. En este caso, el cuerpo puede ser un binario que ha estado filtrando datos y el grito en medio de la noche puede ser una alerta del sistema de detección de intrusos… no lo sabemos. Pero tenemos alguna pista inicial que nos hace pensar que hay algo interesante para empezar una investigación de este tipo. Por ejemplo, como he comentado antes sobre Careto, la primera pista fue encontrar que había unos binarios que estaban explotando una vulnerabilidad de un producto de Kaspersky. Aquí de lo que se trata es de intentar encontrar la mayor cantidad de pistas posibles, de recolectar la mayor cantidad de artefactos que luego nos permitan desarrollar nuestra investigación. Entonces aquí empieza el primer problema, que es encontrar qué hay relacionado con esta campaña. Los binarios, en este caso, todos los artefactos que podamos encontrar, que estén utilizados en una campaña, para explotarla, para infectar el sistema, para filtrar datos, para cualquier cosa, son nuestra fuente de información primaria. Es lo más interesante en este punto. Entonces, la primera reflexión es saber qué es un binario y qué podemos hacer con él.

Lo primero que nos gustaría, una vez detectado un binario que parece que es de una campaña que parece muy interesante y del que queremos más información, es cómo encontrar otros binarios que puedan estar relacionados con esta misma campaña, con este grupo que hay detrás y que nos puedan aportar más información porque, al




final, lo que queremos tener es una imagen, una visión global lo más amplia posible en la cual podamos incorporar cuantos más elementos, mejor.

Para encontrar binarios relacionados, una de las cosas que nos podía venir a la mente es utilizar funciones de distancia. Una función de distancia está relacionada con el clustering, se trata de encontrar qué atributos tiene un binario con los cuales poder construir una representación numérica, que nos de una cifra, un scoring, y que lo podamos comparar con otro binario. Así podemos establecer la distancia que hay entre estos dos binarios. Una vez que tenemos esta función definida, podemos hacer un clustering que, simplemente, consista en agrupar los binarios que sean similares.

Una vez que tenemos esto, todo es más fácil. El aprendizaje automático, el machine learning, lo podemos utilizar también para hacer este tipo de aprendizaje, es decir, para aprender qué binarios están relacionados unos con otros. De hecho, el clustering tiene una desventaja y es que no sabemos si funciona o no. Imaginaos que tenemos ahora mismo una función de distancia que creemos que es buena, la tiramos contra un terabyte de binarios, ya que disponemos de unos cuantos cientos de miles o millones, y nos da una serie de grupos, ¿cómo sabemos que, realmente, este clustering es bueno, que estos binarios realmente se parecen o no? No es sencillo. En cambio, cuando utilizamos el machine learning la aproximación es algo distinta. El algoritmo de machine learning lo que necesita es aprendizaje supervisado, lo que significa que le vamos a dar

una serie de binarios y vamos a decir “éstos son de este grupo, éstos son de este otro y éstos son de un tercer grupo”. A partir de aquí, el algoritmo aprenderá cuáles de las características de los binarios son interesantes haciendo que este grupo se distinga del segundo. De este modo, cuando demos con un grupo que no conocemos, nos lo clasificará automáticamente.

Entonces, como se aprecia, aquí no hace falta tanto la función de distancia sino la selección de los atributos adecuados. Es decir, ¿el tamaño de un binario es relevante para hacer una agrupación? Seguramente, no. ¿El nombre del binario? Quizá. ¿La tabla de importación? Seguramente, sí. Y es que hay una serie de características que nos permitirán saber si estos binarios realmente se parecen o no. Una vez establecida la distinción entre machine learning y clustering, dependiendo de lo que queramos hacer podremos utilizar una aproximación u otra.

Antes de hablar de funciones de distancia, cabe preguntarse si realmente son necesarias. Quizá podamos hacerlo todo un poco más sencillo. No siempre va a ser necesario que utilicemos una función de distancia y, muchas veces, podemos buscar un patrón dentro del código que haga que este binario tenga algo relevante, algo único que nos lo identifique del resto. Antes comentaba que, dentro de los binarios de Careto, encontramos esta cadena de caracteres. Es bastante único. Si buscáramos esta cadena de caracteres que nos daba Careto entre todos los binarios que tenemos y nos diera otros positivos, valdría la pena echarle un ojo. Entonces, podemos buscar secuencias de bytes que sean únicas dentro de




toda nuestra colección de binarios. Por ejemplo, esto es lo que utiliza el ‘Comando File’ de Linux, que lo que hace es decirnos de un fichero qué tipo de fichero es. El ‘Comando File’, por ejemplo, utiliza lo que hay en File Magic, donde lo que tiene es una base de datos que incluye la secuencia de bytes que identifican cada tipo de archivo. Lo que está haciendo el ‘Comando File’ -un comando que funciona muy bienes simplemente tirar de una base de datos donde le está diciendo que estas secuencias de bytes hacen que este fichero sea único y nos permite identificarlo de forma unívoca. Podemos utilizar esta misma aproximación nosotros cuando hagamos búsquedas. De hecho, no sé si conocéis ‘Yara’, un metalenguaje que permite crear reglas para la búsqueda de secuencias de bytes dentro de binarios. Yara, aparte, nos permite definir cierta lógica para decirnos si este binario es interesante o no. Es una herramienta que se utiliza muchísimo para el análisis de binarios y para campañas maliciosas.

Otra cosa que podemos utilizar también son los metadatos de los binarios. Los metadatos nos proporcionan información muy interesante y que no tiene que ver necesariamente con la estructura del binario en sí, sino que son datos relacionados con este binario. Por ejemplo, hay una utilidad que se llama ‘P Frame’ que si la utilizamos con el archivo ‘Hot Brasilian XXX’ que hemos encontrado, podemos ver la fecha de compilación, el packer que tiene, si tiene URLs, los archivos de la API y otras cosas interesantes como el nombre interno que, en este caso, lo han llamado Power para que si lo pones encima del icono de Windows te diga que es un archivo de Power. Y el nombre

original es ‘ThisReclamo.exe’. Lo que quiere decir es que quien ha creado este binario, internamente está haciendo un reclamo si se llama ‘Hot Brasilian XXX’, haciéndose pasar por un fichero Power Point. Os podéis imaginar que, efectivamente, es un reclamo para una campaña maliciosa.

Entonces, gracias a estos metadatos vemos el nombre interno y podríamos utilizar estos metadatos para buscar más reclamos .exe porque esta es la ruta interna que ha utilizado la persona que lo ha creado y, si encontramos una ruta similar, seguramente tendrá un origen común con esta campaña. Los metadatos son una fuente injustamente olvidada, en mi opinión.

Un ejemplo de Yara que os quería mostrar es esta secuencia de bytes que es la firma que hice para buscar un ransomware que se hace pasar por la policía y que afecta al sistema de Android. Aquí, simplemente lo que hice es que la condición era que se cumpliera la firma. Así de sencillo. No tiene más, pero podemos poner varias condiciones y que se cumpla una u otra, que si no se cumplen dos, una tercera dé positivo, etc. Es un ejemplo de lo más sencillo sobre Yara. En este caso, esta firma es una secuencia de bytes, por lo que simplemente buscamos esta secuencia de bytes entre todos los APKs maliciosos, permitiéndonos detectar si hay algún otro dentro de esta campaña. Nos permite detectar patrones, en este caso simplemente buscando una secuencia de bytes, por lo que tenemos una forma sencilla de identificar si hay otros binarios relacionados.

De hecho, entre hacer una función de distancia versus buscar un patrón, por ejemplo, en este




caso la página web Virus Total, tiene una función de similitud, de distancia a través de la función ‘similar to’ y en este caso, no hay ningún resultado buscando binarios similares al APK que os he comentado antes. Sin embargo, si lo que hago es utilizar la regla de Yara que he comentado, me da un montón. Simplemente a través de la búsqueda de un patrón, que en mi caso era la firma pública de este APK, entre todos los APK que tienes en Virus Total. Por eso a veces no hace falta complicarse la vida, no hace falta hacer algo muy complicado con una función de distancia, porque simplemente el uso de una búsqueda de patrones nos va a dar un resultado igual o mejor.

Vuelvo a la comparación de binarios. El binario más sencillo que podemos imaginar, en este caso sería un ‘Hello World’, el cual, simplemente es una línea de código y un ’include’; si lo compilamos con un flag diferente vemos que el hash resultante es totalmente distinto. Los hashes no sirven para hacer comparaciones. Lo que quiero decir aquí es que el compilador tiene mucho peso a la hora de determinar la forma final de un binario. Un mismo código fuente compilado con distintas propiedades hace que el resultado final sea totalmente distinto. El compilador siempre tiene un peso muy importante; sin embargo, hay algunas aproximaciones que nos pueden servir. Si seguimos pensando que un binario es simplemente, una secuencia de bytes, hay algunas aproximaciones interesantes, como pueda ser lo que se conoce como ‘n-grams’, que es utilizar ‘n’ secuencias de ‘n’ bytes, es decir, en lugar de utilizar el binario como una secuencia de bytes enorme, cogemos secuencias de bytes de cinco en cinco, de siete en siete, etc, dependiendo

de la granularidad, lo que nos permite hacer comparaciones parciales que nos pueden dar información. Al final las secuencias de bytes son las operaciones a un alto nivel, por lo que tiene más sentido utilizarlas. De hecho, hay una secuencia de operaciones como usar histogramas de los distintos tipos de bytes. Es decir, podemos utilizar un histograma de todos los bytes que tenemos dentro de un binario y, según esta distribución, podemos llegar a averiguar el tipo de fichero. Lo bueno que tiene esta aproximación es que funciona también con una muestra parcial. Es decir, si lo estamos haciendo, por ejemplo, en la red y estamos cogiendo un número de bytes de un binario que nos está llegando, esto no puede llevar a identificar el tipo de binario que es.

En esta presentación he puesto varias referencias a papers de este tipo de estudios porque, como veis, explicar esto es un poco farragoso y no quiero entrar en detalles muy técnicos ya que, de hecho, son muy complicados y tendría que aprendérmelos antes todos. Pero os explico esto para que tengáis la visión de que las cosas se pueden hacer y que tengáis la referencia y las herramientas que se pueden utilizar.

Una herramienta muy interesante es SSdeep que, básicamente, lo que hace es coger secuencia de bytes idénticos dentro de un binario y hacer un hash. Esto lo que nos permite es tener un valor de un binario y compararlo con otro binario con hashes parciales de secuencias de bytes que tenemos dentro. Esto nos ayuda a saber si dos binarios coinciden o no. Por ejemplo, tengo dos binarios, los dos son el ‘Hello World’ que he comentado antes, y SSdeep lo que hace es




generar un archivo .txt que tiene la firma de estos hashes parciales internos del binario y nos hace una comparación. En este caso la herramienta dice que tienen algo en común. Viéndolo desde fuera parece que son lo mismo, pero esta utilidad te dice si realmente coinciden o no. Recordad que los MD5 de ambos son totalmente distintos. Entonces, aunque no nos sirven los hashes como comparación directa, sí que hay aproximaciones como estos hashes parciales de secuencias de bytes dentro de los binarios que sí nos permiten hacer estas comparaciones. En cualquier caso, como decía antes, no hace falta conocer toda la teoría, pero es importante saber que existe esta aproximación y cómo funciona. Yo recomiendo, por ejemplo, utilizar SSdeep porque es una herramienta muy buena para este tipo de búsquedas. Recordad que todavía estamos buscando los binarios que puedan estar relacionados con una campaña y estamos viendo desde el más bajo nivel qué hay de interesante en un binario que podemos utilizar para esta búsqueda.

A un nivel superior de abstracción, si ya nos olvidamos de los bytes que, como decíamos, representan el código en el ensamblador de las instrucciones que está ejecutando un binario. Este código es un nivel más alto de abstracción y nos interesa mucho más a la hora de comparar dos binarios. El tema es que los métodos de ‘parseo’ para encontrar código en alto nivel no son triviales. Todos utilizamos herramientas como ‘Aida Pro’, pero hay que saber que pueden fallar. Es decir, la representación que hace del código en un alto nivel puede tener errores. De hecho, este tipo de compiladores utilizan premisas muy

fuertes a la hora de interpretar un código pero tienen muchos errores si esas premisas no se cumplen, por ejemplo, con un compilador extraño y cosas así. Entonces, puede ser que el código que obtengamos con Aida no tenga nada que ver con la realidad. Para la comparación de estos binarios hay aproximaciones mixtas, como por ejemplo, hacer comparación de grafos para ver si coinciden o no. Esta aproximación, la comparación de grafos o la búsqueda de un subgrafo dentro de un grafo, son problemas que se conocen como NP Completos, que significa que el tiempo de computación no se puede hacer de forma polinómica, pues entonces tarda mucho. BinDiff es una herramienta que utiliza este tipo de comparación de una forma muy visual con el control flow de lo que sería el binario y, en este caso, encuentras diferencias en los bloques de código, comparando lo que sería la matriz de adyacencia de un grafo (que es una forma muy rápida de hacer esta comparación). También tiene sus limitaciones. Pero saber cómo funcionan a nivel interno este tipo de herramientas y que lo que tengáis con Aida Pro, por ejemplo, no significa que tengáis la representación real de este código binario, ni significa que la comparación entre control flows sea perfecta, siempre hay que tener esto en cuenta.

Una información interesante de estos binarios con una representación a más alto nivel son, sobre todo, las importaciones. En este caso vemos todos los archivos que están importando funciones que utiliza este binario. Pensad que muchas de estas funciones las puede utilizar el propio packer. Es decir, un archivo está empaquetado, este empaquetador utiliza ciertas funciones de la API de Windows para luego desempaquetarse




y ejecutarse; entonces, tampoco confiéis ciegamente en esta IAT, en esta tabla de importación, porque a veces puede ser que el propio packer esté utilizando funciones que luego el binario no usa para nada. Aparte de ver las DLLs que utiliza, también, en este caso, a través de Aida, podemos ver las distintas funciones dentro de cada DLL que está empleando. Esto nos puede dar pistas muy buenas sobre qué tipo de actividad va a hacer el binario en el sistema.

Otra herramienta interesante respecto a esta tabla de importaciones es ImpHash, un paper que hizo público Mandiant aunque, realmente, es una técnica que parece ser que se utilizaba antes. En este caso, y como decía, las importaciones que hace un binario nos dan muchas pistas sobre qué está haciendo nuestro sistema: si está utilizando una DLL para comunicarse por Internet, en algún caso podemos sospechar si lo hace, si abre un fichero, etc. En este sentido, ImpHash lo que hace es hacernos un hash de la tabla de importaciones que hace este binario para compararla con el resto. La clave de esta aproximación se concreta en dos puntos: primero, que es muy rápido, porque al hacernos un hash nos proporciona una firma única de las importaciones y lo podemos comparar de forma muy rápida con unos cuantos millones de binarios. Y segundo, algo muy interesante: que la tabla de importaciones que crea el compilador depende del orden en el cual se encuentren las llamadas funciones en el código fuente del binario. Esto significa que si todos nosotros nos ponemos a crear un código binario y utilizamos, por ejemplo, dos DLLs, puede que tengamos firmas distintas para todos nosotros en función de cuándo las llamemos dentro del

código. Es decir, no solo que llamemos a esas funciones sino también, cuándo las llamemos. Al hacer que esto cambie el compilador, buscar el hash de esta tabla de importaciones hace que sea distinta en función de este orden, por lo cual es muy interesante a la hora de buscar códigos que sean muy similares. Como os digo, no es una aproximación perfecta para hacer la similitud entre dos binarios pero sí interesante. ImpHash cada vez se utiliza más y es otra de las herramientas que podéis aplicar todos.

Pero bueno, lo que más nos interesa quizá de los binarios es cuándo podemos hacer un análisis dinámico. Un análisis dinámico significa que cogemos un binario lo ejecutamos en una sandbox y observamos qué es lo que hace. Aquí encontramos todas las características, todo el comportamiento del binario. Es la aproximación más sencilla. ¿El problema? Esto no siempre es posible, por ejemplo, por técnicas de anti-emulación, porque solo se ejecuta cuando el usuario ha hecho una serie de cosas en el sistema, etc. Pero si llegamos a obtener esta información es la más valiosa, ya que seguramente nos va a dar más pistas de qué es lo que está haciendo el binario y si realmente es el mismo que otro que estamos analizando. Aquí no estamos comparando ya las características estructurales del binario, sino que estamos comparando temas relacionados con los datos que tiene. Por ejemplo, si se conecta contra una URL, contra un dominio, si accede a un archivo, etc.; esto puede cambiar para dos binarios exactos, en función de los datos que tenga, evidentemente. Pero, realmente, tales datos seguro que son los más importantes. Si los podemos obtener son los más efectivos. El




problema es que son los más difíciles de computar porque son muchos. Muchos de ellos no son atómicos (por lo que para hacer una función los datos cualitativos seguramente no son muy buenos), y también, son caros, en el sentido en el que necesitamos muchas máquinas para poder ejecutar todos estos binarios y recoger toda la actividad que están haciendo.

En definitiva, si queremos hacer una buena función de distancia tenemos que tener en cuenta, lo primero, que necesitamos un conocimiento experto ya que todas estas características de las que hemos estado hablando están muy bien, pero hay que saber cuáles son las buenas. Un ejemplo es lo que hemos comentado antes de ImpHash, de cómo el orden a las llamadas a las funciones altera la reacción de la IAT de los binarios. Si no sabemos esto, nunca se nos ocurriría hacer, por ejemplo, una feature del ImpHash. El tema de la maldición de la dimensionalidad significa que el tener muchas características en los binarios va a hacer que el tratamiento de las funciones de distancia sea casi imposible, por lo que tenemos que seleccionar solo cuáles son las buenas. Y luego, el over citing significa que si utilizamos unos cuantos binarios que no son genéricos va a hacer que nuestras funciones de reconocimiento posteriormente sean demasiado específicas para este grupo de binarios, es decir, que el grupo de entrenamiento que utilizamos tiene que ser bueno, esto es, que tenemos que utilizar algo que realmente luego nos funcione.

Tengo aquí una entrada de un blog en el que un hombre dice que le gustaría hacer un clustering de distintos malware relacionados con distintas

APTs que, básicamente, es de lo que estamos hablando en esta charla. Si nos fijamos en las características que tenemos para cada binario, el nombre del fichero, la extensión, el tamaño, el tipo, el compilador, el packer, la detección, dinámicos, etc., al final el hombre no consiguió solucionarlo, pero en lo que me quiero centrar es en la gran cantidad de datos que tenemos y la dificultad de seleccionar los que realmente son relevantes. Ninguna técnica de Inteligencia Artificial nos va a servir aquí si no tenemos un conocimiento experto detrás.

No obstante, es importante no dejar que los árboles nos impidan ver el bosque. En esta primera parte, hemos hablado solo de binarios y en una campaña APT hay muchísimas más cosas. En esta segunda parte de la presentación vamos a hablar de qué otras cosas tenemos. Para empezar, de las limitaciones en el mundo real. Los binarios pueden ser todos distintos, pueden ser todos iguales o puede que no tengan ninguna relevancia. ¿Por qué? Porque hoy en día lo que se utiliza es malware genérico para que no haya forma de relacionar este código malicioso con un grupo en concreto. Es decir, utilizamos herramientas que podemos obtener en el mercado. Utilizamos herramientas de acceso remoto para poder obtener información de nuestras víctimas pero que no se puedan relacionar con un grupo. Hoy en día, lo que se utiliza más es lo que se conoce como TTPs (techniques, tactiques and procedures) que son las técnicas, las tácticas y los procedimientos de los grupos que hay detrás de los ataques. Es decir, analizo una máquina que ha afectado a la Universidad Rey Juan Carlos y encuentro




un malware genérico; en principio, a lo mejor pensamos que se ha infectado porque estaban navegando por cualquier sitio y bueno, es una infección normal. Pero resulta que este malware, si se ha infectado a través de esta página, esta página la utiliza tal grupo y suele utilizar este malware para infectar como primer paso a la primera víctima para poner un pie dentro de la empresa y luego utiliza una herramienta de movimiento lateral para hacer otra infección del dominio, etc. Estas tácticas, estos procedimientos, conforman el comportamiento que nos permite identificar al adversario, lo que hoy en día se conoce como attribution, la ‘atribución’, y es por lo que pagan las empresas. Es la razón por la que todas las empresas lo ponen dentro de su portafolio.

¿Qué elementos se pueden tener en cuenta para identificar el grupo que hay detrás. ¿No sé si conocéis el reportaje de APT1 de Mandiant? Mandiant es una empresa que se dedica al análisis forense de investigación de este tipo de campañas. Se maneja codo con codo con el gobierno americano y el año pasado realizó este reportaje en el cual se comentaban distintos APTs que tenían origen en China contra los Estados Unidos. En este reportaje hay una parte interesante que es cuando habla de atribución, hablando sobre cómo lo utilizan. Ellos lo describen así: considerando la analogía con el mundo físico, imaginad un ladrón que deja trazos de su delito en distintas escenas del crimen. En cada robo individual podemos ver cómo el ladrón entró en el sistema, las herramientas que utilizó para abrir la caja fuerte, si eligió un ítem particular para robar o lo cogió todo para posteriormente ver qué era

lo interesante. Se trata de una analogía que está bien para ver cómo, hoy en día, se investigan este tipo de cosas en función de cómo actúa este grupo, lo que nos ayuda a identificar quién puede estar detrás. Por supuesto, un grupo perfecto es el que no actúa dos veces de la misma forma. Además, hoy en día, en muy común dejar pistas falsas. Ese es el problema de la atribución en el mundo digital, que es muy difícil de conocer. Y este tipo de iniciativas, este tipo de información, es lo que intentamos que nos sirva para identificar a esos grupos. Pero fijaos que esta información es muy difícil de analizar de forma automática, por lo que la primera parte de la charla sí que tratábamos de herramientas de machine learning que sí que podíamos utilizar para desarrollar una primera fase, pero para una segunda fase de la investigación estamos hablando de analistas que sean capaces de dar sentido a esa información.

¿Qué más tenemos? Pues el terreno de comunicación, sobre todo. Los servidores a los que se están enviando datos, los dominios que utiliza, la información de estos dominios… es decir, todo lo que utiliza de infraestructura de red cualquier campaña es muy interesante y, seguramente, es una información después de los binarios de lo más valioso que podemos obtener. Se utilizan sobre todo métodos no-estándar para la comunicación, se utiliza un tipo de cifrado muy característico y esto es interesante porque nos permitirá identificar más elementos, pero sobre todo los dominios. Por ejemplo, lo que os comentada antes de la campaña de malware para Android. Cuando lo estuvimos investigando resulta que se distribuía a través de varios sitios porno. Unos sitios que después de analizarlos con




profundidad, creemos que tenían semejanzas, aunque eran a nivel estructural, es decir, parecía que todos apuntaban a los mismos sitios web para los recursos. Lo que hicimos con un pequeño script es que cogiera todos estos sitios, los descargara, se viera a dónde apuntaban y luego que hiciera un pequeño mapa en el cual se vieran las relaciones. Podemos pensar cuál es la probabilidad si cogemos cien sitios porno, que todos tengan una estructura similar. Esa probabilidad realmente es baja. Entonces, este tipo de análisis nos permite ver que realmente hay una infraestructura inherente y nos va a permitir encontrar más sitios que se estén utilizando para esta campaña. Por eso, los dominios que se utilizan para una de estas campañas, su estructura interna, son un valor también muy interesante que nos permite no solo hacer la relación, sino descubrir más elementos relacionados.

La información de Whois, ya sabéis lo que es: si vas a un dominio y haces un Whois nos da datos de quién es el propietario, los cuales, hoy en día, muchas veces son anónimos y la mayor parte de las veces falsos. ¿Esto significa que la información de Whois no es importante o valiosa? En absoluto, es información muy interesante por varios motivos. Recordad lo que hablábamos de los TTPs donde los grupos tienen preferencias: hay grupos que, a lo mejor, siempre utilizan los mismos servidores de correos para poner el registro del ‘whois’, a lo mejor utilizan una misma dirección para registrar 40 dominios también, porque hay limitaciones y, por ser prácticos, utilizas algunas que son tus favoritas; puedes usar los mismos proveedores para registrar el dominio; puedes hacer los registros en las mismas fechas…; como

veis aquí, en esta campaña, viendo los datos de registro, nos percatamos de que claramente, en noviembre, es donde se alcanza el máximo punto de actividad para registrar esos dominios que se utilizaron posteriormente.

Todos estos pequeños vicios, las compañías donde está el hosting, los dominios que están utilizados en estas campañas, cómo van rotando entre distintos proveedores de hosting, en distintos países y siempre son los mismos, siempre ves la misma rotación. Toda esta información es muy interesante porque son vicios que tienen los grupos, son pequeños errores que luego nos permiten a nosotros encontrar relaciones, encontrar pistas que nos permitan analizar la campaña. Por lo que toda esta información de Whois es muy valiosa aunque sea falsa porque a lo mejor siempre utilizan la misma dirección, el mismo dominio, el mismo proveedor o se registran a la misma hora.

Entonces, dos herramientas muy buenas son las DomainsTools, por supuesto, y Whoisology porque nos permiten encontrar a partir de una dirección de correo los dominios que hay registrados, es decir, lo que se conoce como un ‘reverse whois’. Y también puedes descargar, creo que se pueden comprar, las bases de datos de Whois; son varios terabytes pero lo podéis tener en vuestra organización e intentar hacer relaciones, que también es interesante.

¿Qué más tenemos? Tenemos datos de sinkhole. Sinkhole es una campaña maliciosa: todos los datos robados van a un servidor, ese servidor tiene un dominio, entonces vas a la policía y le




dices que tienes pruebas de que este dominio está realizando actividad maliciosa y está registrando los datos robados de esta campaña. Con lo que puedes conseguir que este dominio, en lugar de redirigir al servidor malicioso, redirija a tu servidor, por lo cual, todos los usuarios infectados reportarán los datos a nuestro servidor. ¿Qué es lo que veremos? Generalmente, nada en cuanto a datos porque los robados siempre están cifrados; pero lo que sí que vamos a ver son las IPs de los usuarios infectados. Gracias a ello muchas veces somos capaces de avisar a las víctimas que están infectadas sin que ellos lo sepan. Si tú hablas con una víctima y dices “oye, tengo que hablar con el de seguridad porque creemos que estáis infectados”, lo primero que responden ellos es “¿y cómo lo sabes?, ¿me estás intentado vender antivirus?”. Pero nosotros lo vemos porque estamos observando la IP que es de esta víctima y que está enviando datos robados de su organización sin que ellos lo sepan. Entonces, gracias a un sinkhole podemos ver este tipo de datos que son muy valiosos porque podemos ver la tipología de las víctimas, las fechas de infección, por cómo reportan los datos, etc., podemos tener mucha información para una campaña.

Respecto al Big Data, simplemente voy a comentar dos cosas porque parece que, hoy en día, es una solución mágica para todo, igual que lo de Inteligencia Artificial, y no es así. Primero, para Big Data hace falta infraestructura: instalar un Hadoop en vuestro servidor de casa no es Big Data.

Normalizar datos contra no-normalizar datos. Hoy en día también está de moda no-normalizar nada. Tú pones todos los datos en un servidor,

que tenemos 100 terabytes y tenemos un elastic search por lo que tenemos búsquedas que nos darán datos. Esto está muy bien para algunas cosas, pero para otras está muy mal. Por ejemplo, si queréis tener los datos de un sinkhole, si tenéis que ‘grepear’ los ‘teras’ de datos que tenéis cada vez que queráis buscar una IP va a ser totalmente ‘inusable’. Hay datos que se pueden normalizar, estos datos los cogéis, los metéis en una base de datos, aunque sea MySQL, incluis la IP como un entero y hacéis un árbol de búsquedas. En menos de un segundo, vais a tener las IPs que están relacionadas con una campaña y a poder hacer búsquedas por rangos de forma más sencilla, con máscaras. Pero si tenéis que hacer esta búsqueda dentro de todos los access.log que tengáis, vais a tardar horas. Por lo que no es una solución mágica y está bien que los datos los tengáis normalizados. Como me enfado mucho con esto quería comentarlo aunque no tenga mucho que ver...

Para terminar, mencionaré el asunto del cruce de datos. Todo esto que hemos hablado está muy bien, tenemos un montón de datos, no todos se representan fácilmente y no es nada sencillo cruzarlos. De hecho, no solo eso, sino que tenemos datos que queremos obtener de otras organizaciones. ¿Cómo representar estos datos para que sean útiles para nosotros, para otras organizaciones, etc.? Hay varias herramientas. Por ejemplo, una de las más famosas es Maltego, que nos permite integrar toda esta información en unos servidores que tiene la propia Maltego y lo que hace es intercambiar estos datos con otros servidores que tienen ellos para que obtengamos más inteligencia. Podemos comprar nuestros propios servidores y nos da relaciones. Al final nos




interesa tener un framework de este tipo en el que podamos ver todas estas relaciones en integrar toda esta inteligencia, pero no es nada sencillo.

Maltego es una herramienta comercial, pero hay frameworks públicos, gratis y open source, como es CIF (Collective Inteligence Framework), el cual también nos permite integrar inteligencia desde muchas fuentes en un mismo sitio que luego nosotros podemos explotar. Ojo, no se explota sola, las relaciones las tendremos que hacer nosotros.

Al final, el tipo de información que tenemos es algo de este estilo de la pantalla. Esto no es una herramienta automática, sino que está hecha a mano; nos permite obtener este tipo de representación, y creo que es una visión bastante adecuada de lo que tiene que ver el analista. Te muestra una información muy extensa, y esta es la que se puede clasificar fácilmente, la que se puede atomizar, pero a veces esto no es posible. Entonces, desde mi punto de vista y, en la actualidad, sí que hay muchas herramientas que nos ayudan. Hay muchos frameworks para integrar toda esta inteligencia, pero todavía hay una labor de analista muy importante, que sepa utilizar esas herramientas y lo que significan para, posteriormente, saber interpretar los datos. Lo que decíamos de los TTPs, muchas veces no se puede hacer automáticamente.

Si os queréis lanzar, hoy en día, dentro de la Inteligencia Artificial lo que está más en boga

son los modelos gráficos y las ‘redes bayesianas’. Imaginaos un modelo en el cual, este grafo que hemos visto tiene una probabilidad para que en función de lo que pase sepamos si estamos en un estado u otro y lo identifiquemos como malicioso o no, si pertenece a un grupo, a una campaña, etc. Esta es la aproximación en la que se está trabajando. Hoy en día, yo creo que no hay ningún modelo actual que lo tenga bien integrado, ni comercial, ni no-comercial. Igual estoy totalmente equivocado pero, no sé hasta qué punto es posible realizar todo esto de forma semiautomática y hacer un framework donde se integren todas estas posibilidades. ¿Por qué? Porque hay demasiadas características y hacerlo desde un punto de vista formal y genérico lo veo muy complicado. Pero creo que ciertas partes, como hemos visto, se benefician de esas herramientas y se pueden utilizar dentro de este framework para ayudarnos a tomar decisiones y hacer el análisis. Aunque actualmente soy escéptico al respecto de lo que se pueda hacer desde un punto de vista genérico.

Concluyo: la idea de esta conferencia era ver algunas cuestiones que se tienen que tener en cuenta en una investigación de campañas APTs, exponer cómo se pueden utilizar ciertas herramientas y ayudar a que todos entendamos mejor cómo funcionan las herramientas que se utilizan en distintos niveles y en las distintas etapas.




Muchas gracias. Efectivamente, les voy a hablar de CyberProbe: Towards Internet-Scale Active Detection of Malicious Server. Esto es un trabajo

con mis estudiantes Antonio Nappa y Zubair Rafique en el Instituto de IMDEA Software, que está aquí en Madrid, en el campus de Montegancedo, en la Facultad de Informática de la Universidad de Politécnica de Madrid, y con nuestros compañeros Zhaoyan Xu y Guofei Gu, de la Universidad Texas A&M de Estados Unidos.

En un slide os resumo el tipo de cosas que hago. Trabajo en seguridad de sistemas, seguridad de software y seguridad de redes en temas

como Software, Vulnerabilidades y Exploits, Malware, Detección de Intrusiones y Técnicas de Análisis Forense. Y una cosa que une todas estas áreas de investigación es esto que pongo en el centro, el Análisis de Programas Binarios que es cuando utilizas el código sin tener acceso al código fuente, simplemente teniendo acceso a los ejecutables que lo implementan. Pues, he tenido a Vicente justo antes y ha hecho ya una introducción a muchos de los temas que voy a tratar. Cada día tenemos más ciberataques, ¿no? Hay tres tipos de atacantes básicamente ahí fuera. Tenemos a los cibercriminales que tienen una motivación muy clara: lo que quieren es hacer dinero. Tenemos un segundo grupo de atacantes

CYBERPROBE: TOWARDS INTERNET-SCALE ACTIVE DETECTION OF MALICIOUS SERVER

Juan CaballeroProfesor Investigador Ayudante, Instituto IMDEA Software





que normalmente llamamos los hacktivist, cosas como Wikileaks, Anonymous, etc., cuya motivación la podemos clasificar ampliamente como una motivación política. Y, luego, tenemos un grupo más reciente de atacantes que podemos definir como Gobiernos o Agencias patrocinadas por Gobiernos, y pongo ahí algunas que han estado linkeadas, algunos de los casos más notorios últimamente y podemos clasificarlos por la motivación de estos atacantes... es un poco más difuso pero lo vamos a llamar defensa nacional o seguridad nacional.

En estos tipos de atacantes tenemos básicamente los cibercriminales y luego existen los ataques APT, que Vicente ha mencionado antes. Lo que voy a exponer aquí es que hay dos componentes fundamentales en este tipo de operaciones maliciosas. Uno es el malware. El malware es fundamental porque básicamente una vez han infectado ordenadores de los cuales quieren la información que contienen o quieren monitorizarlos de alguna forma, por ejemplo, enviando spam o lanzando ataques de denegación de servicio, establecen una presencia permanente en esos ordenadores. Pero luego existe un segundo componente, los servidores. Básicamente, esos son los servidores que están en Internet y que se utilizan para controlar toda la operación, controlan el malware, envían órdenes y también sirven para distribuir este malware. Me centraré en esta segunda parte.

¿Qué son estos servidores maliciosos? Pues los hay de muchos tipos. Tenemos servidores de explotación, que están involucrados en cosas como drive-by-download. Básicamente,

visitas tu sitio web favorito que te redirige a otro, otra redirección y, después de una cadena de redirecciones, acabas en un servidor que habla con tu browser e intenta explotar una vulnerabilidad, bien en tu browser o bien en algunos de los plug-ins que tienes instalados en ese browser. Si logran explotarte, te instalan malware. Bueno, ese en un tipo de servidor. Otros servidores son los command and control, los de comando y control. Básicamente son los que les envían las órdenes al malware y a veces también son los que reciben la información que el malware les filtra de los ordenadores infectados. Pero existen otro tipo de servidores. Por ejemplo, puede haber servidores de pago, como los ransomware o los fake antivirus que van a intentar convencerte de que hagas un pago, bien para recuperar tu información cifrada por ellos, o bien porque te quieren vender la licencia de un programa de seguridad que realmente no te va arreglar nada. Esos servidores recibirían básicamente tu información de la tarjeta de crédito. Hay servidores como proxys redirectors que los atacantes utilizan para ganar anonimidad en el acceso. Bueno, existe otro tipo de infraestructuras distintas que no se basan en servidores: las redes de pares. En esta conferencia vamos a pensar que una red de par o un nodo en esa red es como un servidor. ¿Por qué? Bueno, realmente contienen la funcionalidad tanto de servidor como de cliente, van a recibir mensajes y van iniciar también comunicaciones. Luego tienen las dos versiones. Entonces, los consideramos también como un servidor. Básicamente, vamos a hablar de operaciones y de tipos de servidores, ¿no? ¿Qué es una operación? Una operación




tiene un objetivo y se lleva a cabo por parte de un grupo específico de atacantes. Por ejemplo, podemos tener un grupo específico de atacantes que maneje un ramsonware y que tenga una serie de servidores distribuidos por Internet. Existen otros atacantes que van a tener otros servidores también distribuidos y algunos de estos, por ejemplo, pueden tener además dos tipos de servidores: unos serán esos servidores de command and control y otros serán exploits servers, por ejemplo, para la distribución de malware. Las preguntas que nos hacemos en este trabajo son: ¿podemos encontrar esos servidores que pertenecen a una operación determinada? ¿Cuántos servidores utiliza esa operación? (Y esa es una propiedad que puede variar de operación en operación). ¿Dónde están esos servidores almacenados?

Voy a empezar la tercera pregunta, que hemos analizado en algunos trabajos anteriores a CyberProbe. Básicamente, estamos viendo que los servidores maliciosos se están moviendo a la nube. ¿Por qué? Pues porque los servidores no viven para siempre. Es decir, un servidor malicioso tiene una vida limitada porque existen defensores, gente que trabaja en compañías de seguridad, voluntarios que si encuentran un servidor malicioso lo reportan y básicamente ese servidor se quita de la red. En un trabajo anterior medimos que la media de la vida que se dedica a hacer drive-by downloads, es decir, a explotar, a instalar malware, es solo de 16 horas. Es un tiempo muy pequeño porque ni siquiera viven ni un día. ¿Qué es lo que pasa? Que si quieres mantener una operación que distribuye malware a lo largo del tiempo necesitas muchos

servidores. Entonces, ¿dónde vas a encontrar esos servidores? Pues vas a los proveedores de hosting en Internet. Todo el mundo habla de la nube, la nube es preciosa, la nube te permite encontrar servidores, te permite pagar solo por los recursos que utilizas, te da una instalación muy fácil y todas estas ventajas también las ven los atacantes. Dicen, “efectivamente, también estas ventajas están muy bien desde mi punto de vista”. Entonces, una de las cosas que medimos es que el 60% de los servidores de explotación que encontrábamos estaban alojados en estos proveedores de servicios de alojamiento en la nube. ¿Cuál es el tipo de servicio del que se abusa predominantemente? Es lo que se denomina VPS, Virtual Private Servers. ¿Por qué? Porque esto básicamente es una máquina virtual en algún sitio en Internet en la que te dan acceso root, lo que es perfecto desde el punto de vista de un atacante. Es decir, él tiene una shell con acceso root, él puede instalar lo que quiera y, básicamente, nadie se mete en lo que está instalando. Mucho más beneficioso que otro tipo de servicios de alojamiento en el que le tienes que pedir al proveedor que te instale en código, lo cual es problemático si el código que quieres instalar es command and control u otro servidor de explotación. Entonces, ¿qué es lo que pasa? Pues básicamente lo que necesitan es contratar muchos servidores o comprarlos, alquilarlos e ir reemplazando los servidores que van muriendo con nuevos servidores de este pool de servidores.

¿Cómo funciona esto? Bueno, pues tenemos al atacante que tiene varios servidores en Internet y tenemos los defensores que, de vez en cuando, reportan esos servidores y dicen “este servidor lo




he visto yo involucrado en actividades maliciosas, por favor, desconéctenlo”. Bien, pues uno de los servidores se desconecta y ¿qué es lo que pasa? Pues que el atacante coge el dinero y se compra otro. Y entonces volvemos a reportar otro y el atacante dice “bueno, pues ahora voy a comprar cinco”. Esta es la carrera en la que nos encontramos actualmente.

Nuestro objetivo es identificar estos servidores maliciosos que están en Internet. Hay diversas técnicas para hacer esto. Existen técnicas pasivas, cosas como los honeypots, los spamtraps, los IDS, los servidores de detección de intrusiones. Por ejemplo, si tienes un servidor de detección de intrusiones, analiza el tráfico de red en tu empresa, si te conectas a un servidor malicioso igual tiene una firma y te lo dice y entonces de esa forma identificamos un servidor remoto. ¿Cuál es el problema de este tipo de approaches pasivos? Es que tiene una visibilidad muy limitada; es decir que tú solo ves los ataques que afectan a lo que estás monitorizando, normalmente tu empresa. ¿Qué quiere decir? Que si tu empresa tiene una fracción muy pequeña de todo el tráfico de Internet la fracción de ataques que ves también va a ser muy pequeña y no va a corresponderse con lo que está pasando a nivel global. También son lentas, es decir, hasta que no sucede un ataque de estos tú no sabes nada de este tipo de ataques.

Existen otro tipo de técnicas que son activas. La más clásica es recopilar un montón de malware, ejecutarlo y mirar a ver a qué servidores se conecta ese malware y básicamente extraer una lista de las direcciones IP de los dominios a los que se conecta. Esto, por ejemplo, es una

de las cosas que hace VirusTotal. Existen lo que son granjas de honeyclients. ¿Qué es un honeyclient? Es una máquina virtual que le da una URL, visita esa URL e interacciona con el servicio. Por ejemplo, si el servicio es un exploit server va a intentar explotarlo y puede detectarlo el honeyclient y, por lo tanto, identificas que eso es un servidor de explotación. Esta es la técnica que se utiliza en defensas como Google Safebrowsing y Microsoft Forefront, que muchos de nosotros utilizamos. ¿Qué es lo que pasa? Que también tienen limitaciones, su visibilidad limitada, aunque mucho más amplia que las técnicas pasivas. ¿Por qué? Porque por ejemplo, Google puede coger todos los resultados de su crawling de Internet, darle todas esas URLs a los honeyclients y, básicamente, tener una visibilidad grande de todo lo que está pasando en Internet. Sin embargo, ese tipo de approaches es muy caro porque hay muchas direcciones URL; eso quiere decir que hacen falta muchas máquinas virtuales para visitarlo y por eso es por lo que solo empresas muy grandes, como Google y Microsoft, normalmente utilizan este tipo de approaches. Otra limitación: que son específicas a un tipo de servidor determinado. Es decir, en el caso de los honeyclients normalmente es para los servidores de explotación: visitas la URL y vas a ver si intenta explotarte y si te intenta instalar malware. Pero esa técnica no te vale para, por ejemplo, detectar un command and control server.

Os voy a presentar otro tipo de técnicas distintas. Las llamamos Active Probing en inglés. Quizá su traducción sea Técnicas de Escaneado. ¿Cómo funciona? Bueno, tenemos dos operaciones de ejemplo aquí: la primera es con dos tipos de




servidores y segunda la con uno. Y, básicamente, lo que vamos a hacer es instalar una serie de máquinas a las que vamos a llamar scanners, y las podemos poner donde queramos. Son pocas. Literalmente, son tres o cuatro. Y lo que les vamos a dar son unas firmas. Y os voy a contar cómo se generan estas firmas. Tenemos firmas para cada una de las familias: operación y tipo de servidor dentro de la familia. Entonces, lo que hacemos es: le enviamos tráfico a un servidor, recibimos las respuestas de ese servidor y le pasamos las respuestas a un clasificador que va a ser capaz de determinar si ese servidor con el que estamos hablando es malicioso o no. Repetimos eso con otro servidor distinto, recibimos las respuestas y lo clasificamos. A veces enviaremos tráfico a un servidor que es inocente, recibiremos las respuestas y deberemos de ser capaces de decir que ese servidor no está involucrado en ninguna actividad maliciosa. ¿Cuáles son los beneficios de este tipo de técnicas? En general se puede utilizar para cualquier servidor, para cualquier máquina que está escuchando, esperando tráfico que le va a ser enviado. Por eso, aparte de los servidores también afecta o también se puede utilizar para redes de pares, puesto que también están escuchando para recibir tráfico remoto. Es escalable. De hecho, es tan escalable que se puede aplicar a todo Internet. Y es rápido: puedes escanear todo Internet en cuestión de horas. Literalmente con tres o cuatro máquinas en cuestión de cuatro o cinco horas. Es fácil de instalar. ¿Por qué? Porque solo necesitas unas pocas máquinas centralizadas. No necesitas instalar un sensor en cada una de las redes en Internet que quieres defender. Y es relativamente barato.

¿Cuáles son las contribuciones de nuestro trabajo que, por cierto, presentamos en el Network and Distributed Systems Security Symposium en San Diego en febrero de 2014? La primera contribución es una técnica de escaneado para detectar servidores maliciosos. Para lograr que esto funcione lo que desarrollamos fue una técnica de creación de estas firmas que necesitamos para identificar el servidor. Lo hemos implementado en una herramienta que se llama CyberProbe. Y hemos utilizado esta herramienta para encontrar realmente servidores maliciosos ahí fuera, en Internet. Pues encontramos 151 servidores a través de una serie de escaneados. El 75% de esos servidores que encontramos no eran conocidos antes de que nosotros los encontráramos. Por ejemplo, no eran conocidos en bases de datos como VirusTotal o como URLquery, etc. Y también encontramos más de 7.000 nodos de una red peer-to-peer de malware. E identificamos una propiedad interesante, que llamamos provider locality, que se traduciría en algo así como ‘localidad en los proveedores de hosting’. Luego explicaré en qué consiste.

Os cuento cómo funciona la técnica. En resumen hay dos pasos. Uno es la generación de las firmas; básicamente tomamos como input lo que es tráfico malicioso y también tráfico benigno. Y el output de esta generación van a ser estas huellas que nosotros necesitamos para la clasificación y también lo que llamamos servidores semilla. Es decir, vamos a empezar con algún servidor malicioso que ya conocemos, muy pocos. Normalmente, uno; de hecho, de una familia en concreto. Y una vez que tenemos esto, la segunda etapa es el escaneado. Cogemos esa huella, los




rangos de direcciones que queremos escanear y el puerto en el que queremos hacer el escaneado, enviamos el tráfico, recolectamos las respuestas, clasificamos y hacemos un output de cuáles de las direcciones IP corresponden a servidores maliciosos. ¿Cuál es el truco aquí? Es que lo que queremos encontrar son, si empezamos con algunos servidores semilla que ya conocemos –normalmente uno–, más servidores que pertenecen a esa familia. Luego el número de servidores maliciosos debe ser mayor que el encontrado de servidores semilla.

¿Qué es una huella? Bueno, una huella identifica una familia de servidores; es decir, una operación y un tipo de servidor concreto dentro de esa operación. Si hay varios tipos de servidores en la misma operación, cada uno tendría una huella distinta y podemos, también, desarrollar múltiples huellas para el mismo tipo de servidor.

¿Qué es esta huella? Pues, en esencia dos cosas. Es una función de construcción de las solicitudes de red. Es decir, es una función a la que tú le das la dirección IP que quieres escanear y te devuelve cuál es el paquete que le tienes que enviar o la secuencia de paquetes que le tienes que enviar. La segunda parte es una función de clasificación: es la función con la que recibes las respuestas del servidor y, básicamente, es un clasificador boolenano que va a decir “Sí, pertenece a esta familia” o “No, no pertenece a esta familia”. ¿Cómo implementamos esas funciones de clasificación? Es tan sencillo como una regla para Snort. Snort es uno de los IDS más populares ahí fuera. Este es un ejemplo muy sencillo: tenemos una huella para una familia, que la vamos a llamar ‘clicpayz’

y, en esencia, lo que tenemos es la solicitud que le vamos a enviar. No he puesto el contenido completo pero es una solicitud HTTP GET para una URL muy particular con unos parámetros muy particulares. Y lo que vamos a hacer es si yo le envío esta solicitud a un servidor y recibo una respuesta que matchea con esta firma, que básicamente está diciendo “vas a recibir una redirección”, este es el código 302 y el contenido va a decir loading. Vamos a considerar que ese es el servidor malicioso. Este es básicamente el resumen de una huella.

¿Cómo generamos estas huellas de una forma automática? Bueno, uno de los conceptos más importantes es esta palabra de aquí arriba que pone adversarial. Adversarial quiere decir que necesitamos generar estas firmas en el contexto de un atacante. Básicamente, que existe un atacante. ¿Por qué? Porque tenemos unos servidores semillas con los cuales vamos a tener que interaccionar, vamos a tener que enviar tráfico y recolectar sus respuestas. Si ese servidor está controlado por el atacante, si sabe que el tráfico que estamos enviando es nuestro podría bloquearnos, ignorarnos… lo que quiera. Entonces, el problema al que se reduce es a que queremos que nuestra generación de firma sea lo más inconspicua posible. Y esto se traduce en algo muy sencillo. Tenemos que minimizar el tráfico que enviamos a esos servidores, cuanto menos tráfico mejor, y tenemos que hacer que nuestro tráfico parezca lo más benigno posible, es decir, que se parezca lo más posible al tráfico que ya reciben esos servidores maliciosos. Entonces, la intuición un poco de cómo haces esto es buena, por qué no simplemente hacemos un replay de




un tráfico que ya hemos visto anteriormente y que esos servidores reciben. Ese tráfico ya va a ser muy parecido al tipo que espera el servidor recibir. Y, puesto que es un tráfico válido, nos minimiza el número de intentos que tenemos que hacer enviar paquetes a esos servidores remotos.

¿Cuál es la arquitectura de esta generación de Adversarial Fingerprint Generation? Bueno, cogemos el tráfico malicioso, extraemos los pares de solicitudes y respuestas, las pasamos a un modo que lo que va a hacer el replay de ese tráfico a servidores reales, que son los servidores semilla. Ese módulo también va a filtrar todas las respuestas que no son válidas. Luego lo pasamos a modo de clustering que dice que todas las solicitudes que son parecidas van a pertenecer a la misma familia y van a ser utilizadas para construir la misma huella. Y, después de que hemos agrupado los requests, miramos todas las respuestas e identificamos las partes de las respuestas que la hacen distintiva, que la hacen única, que nos van a permitir distinguir entre la respuesta de un servidor benigno y uno malicioso. Para utilizar eso tenemos que tener de input tráfico benigno para, básicamente, poder diferenciar entre ambos. Y el output son las huellas digitales que vamos a utilizar en la fase de escaneado. ¿De dónde sale este tráfico malicioso que necesitamos como inputs? De dos tipos distintos de approach. Podemos coger malware, lo ejecutamos en una máquina virtual, en un entorno contenido con ciertas políticas y, básicamente, lo que hace es un output del tráfico de red que genera el malware mientras se está ejecutando. La otra opción es para servidores de explotación; ahí, el tráfico que queremos nosotros

es el tráfico de la explotación de un cliente cuando visita un servidor de estos. Entonces utilizamos honeyclients, a los que les damos una URL. Si una de esas URLs genera la instalación de un malware al final, pues hacemos un output de la traza y esas son las trazas que vamos a utilizar como input. De esas trazas extraemos los pares de solicitudes y respuestas.

Vamos a la parte de replay. Sabemos que hay una serie de servidores maliciosos ahí, sabemos el tráfico que se les ha enviado, conocemos lo que han respondido y, entonces, lo repetimos tomando ciertas precauciones, es decir, no queremos que sepan que ese tráfico nos viene a nosotros. Por ejemplo, podemos utilizar un virtual private network que nos proporciona cierta anonimidad y también una diversidad en direcciones IP. Es decir, que cada vez que envío un paquete puedo cambiar el nodo de salida de la VPN y, básicamente, me asigna otra dirección IP. Entonces, el que está recibiendo el tráfico no sabe que los tráficos realmente están siendo enviados por la misma persona. Y uno de los challenges aquí es que tenemos que ser capaces de eliminar todas las respuestas benignas. Algunas son fáciles, puede haber errores, puede haber servidores que no hayan respondido y, entonces, los eliminamos rápidamente. Pero existen otras más complicadas; un servidor te puede responder, por ejemplo, dándote en http un 200 OK y luego mandarte un error dentro del contenido del mensaje. Ahora bien, cada servidor elige el error que quiera o cada webmaster. Entonces, ¿cómo identificamos esto de una manera genérica? El truco está en una comprobación contra la respuesta a una URL aleatoria. ¿Qué es lo que




pasa aquí? Bueno, tenemos nuestro replayer, un servidor que solía ser malicioso con esta dirección IP. ¿Qué sucede? Que entre el tiempo en el que nosotros recopilamos esa traza y cuando vamos a hacer el replay, ese servidor puede haber dejado de ser malicioso. Y, ahora, esa dirección IP ha sido asignada a otro servidor distinto que es benigno. Entonces, lo que nosotros hacemos es: le enviamos la solicitud que habíamos observado en la traza y obtenemos la respuesta. Pero luego le enviamos otra vez otra solicitud aleatoria y obtenemos la respuesta. Y la intuición es que si ambas respuestas son parecidas quiere decir que ese servidor no ha entendido lo que le hemos enviado porque no me debería de estar respondiendo a una solicitud aleatoria. Y este es uno de los trucos que utilizamos para eliminar contenido o respuestas benignas.

Una vez tenemos los pares de solicitudes y respuestas que hemos logrado de hacer el replay, se los pasamos al clustering que va a agrupar juntas las solicitudes que se parecen. Para esto son cosas relacionadas con las que decía Vicente antes: establecemos una distancia entre las solicitudes… y hacemos un clustering utilizando esa distancia. No entro en detalles, os envío al artículo si queréis para ver…; pero básicamente, diferentes features dependiendo de si el tráfico es http, que es la mayoría, o de si no lo es. Luego construimos la función de la generación de las solicitudes, que es tan sencilla como una de las que hemos visto antes pero reemplazando el tráfico que vemos que cambia. Si, por ejemplo, tenemos varias solicitudes con varias respuestas, puede haber algún campo que vaya cambiando, bien porque corresponde a la dirección IP o bien porque sea una timestamp,

entonces intentamos identificar esos y actualizarlos. Una vez tenemos los clústeres, lo que hemos de hacer es generar unas firmas en las respuestas, que es lo que va a necesitar nuestro clasificador. Cogemos los clústeres, el tráfico benigno y hacemos un output de las huellas. ¿Qué es lo importante aquí? Que necesitamos identificar las partes de las respuestas que son únicas, que son características de ese tráfico malicioso. Y por esto utilizamos una infraestructura para generar huellas, lo que se llaman network signatures (es lo que normalmente utilizan Snort y Suricata) para luego identificar tráfico malicioso en la red. Tenemos un algoritmo para eso, pero no lo voy a explicar ahora, lo podéis ver en el artículo si queréis. Básicamente, la idea general es si conocemos el protocolo, lo vamos a parsear y vamos a generar las huellas a nivel de los campos del protocolo y, por ejemplo, por cada campo… un campo puede ser el GET, la URL, el http1/1… En la dirección http vamos a ver qué valores aparecen en esos campos que no aparecen en el tráfico benigno y, por tanto, son distintivos para poder identificarlo. Es una simplificación muy rápida de lo que hacemos. Y podemos generar varias huellas para el mismo clúster.

Ya hemos generado las huellas. Ahora, lo que tenemos es que utilizarlas para encontrar servidores maliciosos en Internet. Hablo de Internet pero, realmente, podemos utilizar varios rangos distintos para hacer el escaneado. Entonces, el escaneado más básico es lo que llamamos un escaneado localizado. Es decir, que no queremos escanear todo el Internet sino que, pensamos; esta es una hipótesis que luego vamos a ver cómo se verifica que existen rangos en Internet que son más propensos a tener




servidores maliciosos que otros; especialmente para una familia determinada. ¿Cómo hacemos esto? Tenemos un primer tipo de rangos que llamamos localized-reduced; entonces, empezamos con un servidor semilla que tenemos…, bueno, ahora he puesto un servidor benigno en vez de un servidor malicioso… Google.com y una dirección IP, ¿no? Entonces, lo que queremos es un rango más amplio. No queremos escanear una única dirección. Lo que hacemos es establecemos cuál es la ruta BGP que contiene esta dirección IP y ya nos da un rango mucho más amplio. En este caso, de 2 16 direcciones IP. Lo segundo que podemos hacer es conseguir unos rangos todavía más amplios, que es lo que llamamos localized-extended. Lo que decimos es, “bueno, si esa ruta yo sé que pertenece a Google por qué no lo pregunta a la información ‘whois’, cuáles son todas las rutas que pertenecen a Google”. Y ahora tengo un rango mucho más grande de direcciones IP que todavía es muy pequeño con respecto a todas las direcciones IPv4, por ejemplo en Internet, pero me permite identificar servidores. Y,el último, por supuesto, sería el rango, todo Internet; cuando decimos todo Internet no quiere decir que queramos escanear 232 direcciones IPv4. ¿Por qué? Porque de esas 232 direcciones existen muchas que están reservadas; entonces simplemente eliminando esas quitamos un 14% de las direcciones... Hace tiempo solía pasar que todas las direcciones no estaban distribuidas a usuarios. Hoy en día ya todas lo están, no queda ninguna dirección IPv4 libre; ahí no hay reducción. Pero luego tenemos que, de las direcciones IP que tienen dueño, no todas se anuncian en un momento determinado de tiempo,

es decir, no todas están dispuestas a aceptar tráfico. Por lo tanto, al filtrar por las rutas BGP activas tenemos otra reducción y, esencialmente, reducimos un 40% el tamaño de lo que tenemos que escanear.

¿Qué tipo de escáneres utilizamos? Tres. El primero es un Horizontal Scanner, esto es una herramienta como Nmap, por ejemplo, y recientemente, ha habido otra herramienta que ha recibido bastante publicidad que se llama SIMAP. Básicamente, envía un SYN scan y si recibe una respuesta, un sign and knowlegde, sabe que el puerto está abierto y si no, pues el puerto no está abierto, la simplifica. Entonces, una vez que sabemos esto, para las firmas que son TCP establecemos una conexión, por ejemplo, http, enviamos la solicitud, recibimos la respuesta. Para UDP realmente no hace falta hacer el escaneado horizontal. Directamente podemos enviarle la solicitud UDP, no hay un concepto de conexión; entonces, enviamos directamente la solicitud UDP, recibimos la respuesta si la hay y evaluamos en esa respuesta. La forma más sencilla de implementar esto es recoger todas las solicitudes en una traza y luego correr el Snort o correr Snort en vivo en todas las respuestas que nos están llegando de servidores remotos.

Algunas propiedades del escaneado. Lo primero es la tasa de escaneado. Básicamente, la gente que no trabaja en estos temas considera que escanear tan rápido como puedas es relativamente fácil. De hecho con una máquina, un PC cualquiera, uno puede saturar fácilmente un link de 1 Gbps si le pones a generar tráfico lo más rápido posible. Incluso hay artículos de




investigación que proponen frameworks muy especializados de software a nivel de kernel por ejemplo, con optimizaciones que permiten saturar con un PC lo que es un link de 10 Gbps. Lo cual quiere decir es que si te lo propones y empiezas a enviar tráfico como loco, lo que vas a conseguir es saturar el link en el que estás enviando y bloquear a todo el mundo que está intentado salir por ese mismo link. Luego es importante limitar el escaneado. En este caso, lo limitamos a 60.000 paquetes por segundo o 400 conexiones TCP por segundo. Otra cosa importante es el orden en el que escaneas. No quieres hacer un escaneado secuencial, quieres hacer un escaneado aleatorio… Estas son cosas que se han estudiado en otros artículos anteriormente. Nosotros para esto utilizamos un linear congruential generator que garantiza que visitamos todas las direcciones IP pero en orden aleatorio. Y para las TCP, que es el output de lo que dice el Horizontal Scanner, cogemos todas las direcciones IP que dice que están vivas y hacemos un shuff le, que quiere decir que randomizamos el orden. Utilizamos también, un Whitelisting. Como son las direcciones IPv4 y 232 es el máximo número que puede haber, podemos utilizar un array en el que en cada bit represente una dirección IP y si el array dice 1 quiere decir “sí, podemos escanear esta dirección IP”, y si dice 0 “No”. Entonces, por ejemplo, todas aquellas que no aparecen en los rangos BGP les damos un 0 y así no se escanean. Y el output es bueno, pues recibimos un Pcap tanto para el escáner TCP/UDP y una lista de direcciones IP para el Horizontal.

Consideraciones éticas. Básicamente, cuando estás haciendo este tipo de escaneado, tú estás

enviando tráfico a unas máquinas que no te han pedido recibir ese tráfico. Y eso quiere decir que puede haber alguien que no le guste recibir ese tipo de tráfico o que no quisiera recibirlo. Entonces, hace falta seguir una serie de normas estrictas sobre cómo hacerlo. Aquí tenemos un resumen de las reglas que nosotros hacemos. Limitamos la tasa que enviamos, cuanto más rápido envías más ruido generas. Solo escaneamos una huella al mismo tiempo: cuantas más huellas intentas escanear al mismo tiempo, más ruido generas. Anunciamos lo que hacemos: ponemos servidores, direcciones DNS reversas que apunten a los escáneres para que sepan que son escáneres. Ponemos una página web en los escáneres que explican que es un experimento y por qué y para qué se usa. Y lo más importante es si alguien dice “por favor, no me escanees”, añadimos sus direcciones IP para no volver a escanearles; por eso tenemos esa Whitelist que es necesario poseer. Y también otra cosa importante: hay que hacer una verificación manual de las huellas. Es decir, no quieres enviar tráfico que tú has cogido aleatoriamente, que el malware corre sin haber mirado un poco lo que hace porque podía ser un ataque de inyección SQL.

Con esto entro en la parte de resultados. Resumo. Generación de huellas: básicamente utilizamos dos tipos de inputs, lo que es malware y lo que son los honeyclients. Para detectar tanto servidores de command and control o de pago que el malware se conecte o para detectar servidores de explotación en drive by downloads. O corremos malware o visitamos URL y obtenemos un número de servidores semilla y un número de huellas. Podéis ver aquí que el número de huellas es relativamente




pequeño comparado con el número total, por ejemplo, de malware que corremos. Obtenemos 23 huellas para 13 familias distintas, la mayor parte de ellas son http pero también tenemos una UDP. Tres familias de exploit kits, 10 familias de malware. ¿Por qué ese número es pequeño? Por varias razones. La primera es que a veces cogemos las trazas y hacemos el replay mucho más tarde y muchos de los servidores que existían en esas trazas han dejado ya de estar vivos, con lo cual hay trazas que no nos valen para identificar estos seeds. Luego tenemos familias en las que lo que te puede pasar es que tengas 100 malware que sean todos de la misma familia, puesto que generas el mismo tipo de tráfico, la huella que generas es la misma. Y también puede haber cosas en las que el replay por lo que sea no funcione. Una vez que tenemos las huellas lo que hacemos es escanear. Y aquí me salto la parte de escaneado horizontal que no es nada novedosa y voy directamente a la parte de los escaneados http. Hacemos 11 escaneados localizados y vemos que nueve de ellos ya encuentran servidores que previamente no conocíamos. Es decir, servidores que no están en nuestra lista de servidores semilla. Hacemos otros 11 escaneados a nivel de Internet y vemos que en 14 horas con cuatro escáneres a esa velocidad limitada a 60.000 paquetes por segundo podemos escanear Internet. En 24 horas con tres escáneres se encuentran 151 servidores maliciosos. Así pues, empezamos con 15 servidores semilla y acabamos con 151 servidores maliciosos, luego estamos logrando un factor de amplificación de 10 veces.

¿Cómo comprar esto con técnicas que ya existen? No existe ninguna técnica que conozcamos de escaneado de este estilo públicamente

disponible pero sí bases de datos que contienen mucha información maliciosa, incluyendo IPs y dominios. Entonces, nos centramos en las que tienes información de IPs, por eso no utilizamos algo como el Google Safe Browsing, porque solo tiene información de dominios, pero VirusTotal tiene mucho. Ellos corren malware, observan el tráfico e identifican las direcciones IP de los servidores que se conectan. Básicamente, de los 151 que conocemos de VirusTotal, que son los que mejor funcionan claramente con respecto al resto de servicios, solo conoce 40, es decir un 26% de esos servidores, lo cual, quiere decir que nuestra técnica está logrando una visibilidad mucho más amplia que las técnicas ya existentes. Podemos ver una clara diferencia entre VirusTotal, URLquery y servicios como VxVault y Malware DomainList; la diferencia ahí es que estos dos son voluntarios que manualmente añaden las direcciones IP y las verifican, y VirusTotal y URLquery utilizan métodos automatizados que logran una cobertura mucho mayor.

Bueno, algún resumen en operaciones. Aquí, he clasificado las operaciones, les doy un nombre que intento que encaje con análisis anteriores que pueden haber hecho, por ejemplo, empresas de seguridad. Y podemos ver el número de servidores que estamos encontrando… bueno, perdón, primero el número de huellas: vemos que en algunas familias generamos más de una huella, bien porque tengan dos tipos de servidores, bien porque podamos generar dos firmas distintas para el mismo tipo de servidor. Y en el número de servidores que encontramos podemos ver ya muchas diferencias. Podemos ver operaciones que solo tienen dos servidores




en Internet corriendo a la vez. Este es un número muy pequeño y eso nos está indicando que este tipo de operaciones están utilizando bulletproof hosting, es decir, servidores en que si tú envías una queja y dices “este servidor está involucrado en operaciones maliciosas”, no van a hacer ni caso a la queja, ¿vale? Con lo cual el servidor sigue corriendo sin límite. Pero podemos ver que hay operaciones que utilizan un número grande de servidores, por ejemplo, 51 a la vez en Internet. Lo que hacemos es: utilizamos las direcciones IP para clasificar, identificar cuál es el proveedor de alojamiento poseedor de esa dirección IP. Y entonces, lo que hacemos es: el ratio y lo que vemos es que, normalmente, cuando existe un servidor malicioso instalado en un proveedor en la nube, existe más de un servidor de la misma familia. De hecho, de media, existen 3,2 servidores. Y esa es la propiedad que nosotros llamamos provider located, que te dice que ‘una vez que una operación maliciosa ha establecido un contacto con un proveedor de alojamiento en la nube eso quiere decir que les ha tenido que enviar a veces, datos de identificación, una cuenta de PayPal, ha tenido que aprender cómo hacer un upload de las imágenes de sus máquinas virtuales, etc. Lo que quieren es reutilizar esa relación que tiene con ese proveedor lo más posible, es decir, no van a instalar solo un servidor, lo van a reutilizar lo máximo posible, hasta que eventualmente ese proveedor se dé cuenta de que ahí hay servidores maliciosos, los irá quitando y se moverán a otro proveedor distinto. Esta es la propiedad que había mencionado yo.

Bueno, aquí tengo un ejemplo, simplemente, de una de las operaciones. Esta se llama BestAV.

BestAV es… bueno, es el nombre que le damos, no sabemos el nombre que ellos tienen… es una operación que maneja tres familias populares de malware… por lo menos dos de ellas son populares, la tercera no sabemos lo que es. Winwebsec es una familia de fake antivirus que te hacen pop-up en el ordenador y te dicen “estás infectado, cómprame la licencia que yo te lo limpio”. Urausy es un ransomware que cifra los datos y luego te pide que hagas un pago para recuperar la llave para descifrarlos. Y encontramos 29 servidores distintos de esta familia: 11 de ellos son de command and control, es decir, son los que ellos utilizan para controlar el malware, enviarle los comandos y recibir la información; 16 son servidores de pago, precisamente porque cuando te dicen que te han cifrado los datos, te piden que hagas un pago y esos son otros tipos distintos de servidores; y, luego también encontramos dos servidores para los aff iliates. No he explicado aquí el concepto de aff iliates pero, básicamente, esta gente paga a otra gente para distribuir su malware, y esos son lo que se denominan los afiliados. Ellos tienen servidores web en los que el afiliado hace un log in con su cuenta y dice “a ver, cuántas instalaciones he hecho, cuánto dinero me debe esta gente”. Lo que podemos ver aquí es que aunque tienen 29 servidores solo utilizan cuatro proveedores de alojamiento en la nube. Tenemos dos de ellos que tienen una cantidad grande, seis de pago, cinco de command and control, 9 de pago y command and control. Y luego tenemos dos que solo tienen un número muy pequeño de servidores. Ahí tenemos dos hipótesis distintas: una sería que los proveedores C y D son los que utilizaban antes, les




han ido quitando los servidores y han empezado a trabajar con los proveedores A y B; y otra opción sería que C y D, por ejemplo, fueran el back-end de la infraestructura, lo que necesita menos servidores y los otros podrían estar haciendo un proxy a estos servidores.

Bueno, más servidores… éstas son operaciones de explotación y aquí lo único que quiero mostrar son tres tipos diferentes de servidores cuando lo hicimos, que era cuando Blackhole todavía existía, y Doubleighty. Y podemos ver, como hemos dicho, las diferencias. Hay desde los que usan solo dos o tres servidores (os había comentado antes que un servidor de explotación tiene de vida media 16 horas), sin embargo, esta gente logra que estos servidores vivan durante semanas y meses, precisamente, porque los corren en estos proveedores de alojamiento que ignoran todas las request. Sin embargo, otros necesitan tener un número más grande. Y lo que vemos aquí es que, por ejemplo, aunque VirusTotal tiene menor cobertura a veces sí hay servidores que nosotros descubrimos en un momento. Por ejemplo, cuatro días más tarde, ellos encuentran dos de los servidores que nosotros ya habíamos descubierto. Es decir, que no es que siempre encontremos servidores que ellos nunca van a encontrar, es que los encontramos más rápido.

Y aquí otro ejemplo en Doubleighty; básicamente, en un escaneado encontramos nueve servidores de explotación. Entonces lo que hacemos es: cogemos nuestra infraestructura y decimos, “vamos a visitarlo con un honeyclient para ver si realmente nos explota y nos instala malware”. Siete de ellos nos instalan malware según los

visitamos; sin embargo, dos de ellos no. Entonces, la pregunta es “¿no nos están instalando malware porque realmente no son servidores de explotación o porque no están activos ahora mismo y los tienen en stand by para ver cuándo les hace falta para utilizarlos? Lo que hacemos es que dejamos a nuestros honeyclients que periódicamente los visiten y sean explotados. Y, al cabo de un mes, uno de ellos empieza a explotarnos. ¿Qué es lo que quiere decir? Que esta gente lo tenía preparado, instalado el servidor pero no lo estaba utilizando. Entonces, un mes más tarde (porque igual el resto de servidores habían dejado de funcionar, habían contratado otros), lo activan. Lo cual quiere decir que nuestra técnica es capaz de encontrar muchas veces servidores que están instalados pero que todavía no están siendo utilizados.

Una slide para acabar: los resultados en el escaneado de redes de pares; aquí es la firma que generamos de UDP que era para la familia zeroaccess que hace unos meses fue decapitada en una operación que involucró a varias instituciones. Entonces, hacemos dos scans aquí de tipo reducido, es decir, localizando en el que solo escaneamos 40.000 direcciones IP. Tenemos la dirección IP que ya tiene un nodo de esta red, obtenemos los rangos que pertenecen al mismo proveedor, lo escaneamos y encontramos 55. Y luego repetimos lo mismo pero ahora escaneamos todo Internet. Entonces, encontramos casi 8.000 nodos peer to peer. Estos son los nodos, los supernodos que son públicamente accesibles. La botnet, básicamente, puede ser mucho más grande porque puede haber bots detrás de cosas como firewalls que




no reciben el tráfico cuando se lo envías. Pero podemos ver aquí una diferencia importante. Como el escaneado localizado obtiene un ratio de cuántos seeds tiene respecto a todas las direcciones IP que has explorado mucho más alto que cuando escaneas todo Internet, lo cual verifica también esta hipótesis de que existen rangos ahí fuera de direcciones que tienen más probabilidad de tener estos servidores maliciosos. En el caso de servidores, son los proveedores de hosting. En el caso de redes peer to peer, normalmente son proveedores de acceso a usuarios, lo que sería un ONO, un Telefónica, etc. Hay mucho trabajo relacionado, no voy a describirlo en detalle. Existen trabajos anteriores de escaneado. Leonard proporciona recomendaciones (que nosotros seguimos) de cómo escanear lo más educadamente posible. Zmap es una herramienta relativamente reciente solo de escaneado horizontal pero lo hace muy rápido, tan rápido que puede escanear todo Internet horizontalmente en 45 minutos. Ha habido técnicas anteriores de fingerprinting; la diferencia ahí es que las hacen en un contexto en el que no hay un adversario, por lo tanto no hay que minimizar el tráfico que se genera y, básicamente, la contribución ahí es el concepto de cómo generamos las firmas. También existen muchos algoritmos anteriores de generación de firmas. Nosotros proponemos uno que refina el propuesto en Hamsa, que es un trabajo anterior.

Y con esto concluyo. He presentado una técnica de escaneado para detectar servidores maliciosos en Internet. Hemos desarrollado una técnica de generación de las huellas que son necesarias para realizar este escaneado.

Hemos implementado nuestras técnicas en una herramienta que se llama CyberProbe. Hemos utilizado CyberProbe para escanear y encontrar servidores maliciosos. Y demostramos que podemos encontrar más servidores que las bases de datos existentes actualmente. También identificamos esta técnica importante de localidad en los proveedores de alojamiento en la nube que los proveedores deben de tener en cuenta porque cuando reciben una notificación de que una de sus direcciones IP está corriendo un servidor malicioso, las probabilidades son de tres contra uno de que van a tener más servidores de la misma familia instalados en sus instalaciones y deberían encontrarlos también; si no, volverán a tener una queja más tarde, más adelante en el tiempo. Y con esto he concluido. Os dejo con la página web de nuestro proyecto Malicia, que tiene alguna de nuestras publicaciones en esta área. Muchas gracias a toda la gente con la que hemos trabajado en este proyecto y gracias a ustedes.

Turno de preguntas

Muy interesante. Quería hacerte dos preguntas. La primera es: ¿cómo solventáis el problema de la localización de la IP de origen? Porque ciertos servidores no responden si la IP es de cierto rango, si la visitas dos veces, etc. Y la segunda: ¿tenéis datos de vuestra tasa de falsos positivos?

Para la primera, cambiamos la dirección IP cada vez que enviamos una prueba a los servidores, o sea, realmente es difícil que nos detecten. En el




caso por ejemplo de algo como Blackhole, que podía bloquear dos conexiones distintas, si la segunda era desde la misma IP, básicamente la iba a ignorar. En muchos de los casos lo que pasa es que somos la primera conexión desde esa IP que va a esos servidores. Si no lo fuéramos no lo encontraríamos, eso sería un false negative. Es decir, nosotros en los resultados queremos intentar encontrar todos los servidores de la familia pero realmente sabemos que, por diversas razones, una de ellas sería ésta. Lo que realmente encontramos es un lower bound, un mínimo de los servidores. Podría haber más servidores para la familia pero, por lo menos, hay ese número ahí fuera.

La segunda pregunta era la de los falsos positivos. Es complicado evaluar los falsos positivos, lo hacemos manualmente. En nuestra evaluación solo encontramos un caso de un falso positivo. Era un servidor de explotación que, después de intentar explotarte, te redirigía en el caso de que no lo lograse, a una página web que parecía de Adobe y que te decía que por favor, te descargaras el Flash Player que realmente era el malware que, como no habían logrado explotarte e instalártelo automáticamente, te lo daban para que te lo instalaras manualmente. En suma, encontramos un servidor que nos daba una página muy parecida que realmente era un servidor que tenía llaves crackeadas de todos los productos de Adobe. Eso era un tipo de falso positivo que encontramos. O sea, que hay una posibilidad de falsos positivos, pero nuestra experiencia manualmente es que son pocos.

También es difícil tener un ground truth porque no sabes los servidores que existen ahí fuera.

Planteabas al principio tres grandes tipos de ciberataques: los cibercriminales, el hacktivismo y los gobiernos o agencias estatales; supongo que la pregunta es difícil de responder pero, ¿cuál de los tres agentes está más involucrado de forma más permanente en la contaminación de servidores para los fines que ellos decidan utilizar?

Difícil de responder. Si yo tuviera que decir uno me tiraría por los cibercriminales. Primero porque los hacktivist necesitan normalmente menos infraestructura de servidores. A veces, algunos de los ataques que hacen son del estilo que no necesita una infraestructura; simplemente hacen el ataque o una inyección SQL, roban una serie de datos... O sea, a veces no necesitan tantos servidores como las otras. Los gobiernos al hacer ataques muy target tienen unas ciertas empresas o máquinas que les interesan, y el tamaño de las infraestructuras puede ser más pequeño también. Sin embargo, el objetivo básico de los cibercriminales es capturar cuantas más máquinas mejor. Y luego, ya se figuran qué tipo de monetización van a hacer, si van a enviar spam con ellas…; cada familia, normalmente, tiene uno o varios tipos de monetización distintos pero esto quiere decir que necesitan infraestructuras un poco más grandes. Y también porque son más grandes hacen más ruido, distribuyen más su malware y es más fácil que sus servidores se detecten y que necesiten uno nuevo.




Mi nombre es Sancho Lerena, tengo 38 años, soy de Madrid y mi formación es la de ingeniero informático en mis orígenes aunque, viendo mis

carencias, decidí estudiar un MBA ya cuando había puesto en funcionamiento mi empresa. Fundamos Ártica a finales de 2005, es decir, que dentro de poco haremos 10 años, lo cual, para una startup, probablemente, ya sea un poco viejilla, pero no es tan fácil en este país crecer a la velocidad que se crece en otros países como EE.UU. Ahora mismo somos 14 empleados. Es cierto que tuvimos que escindir la empresa en dos hace cosa de unos cuatro años y fundé una empresa con mis socios, una empresa puramente de servicios que no tiene

mucha cabida en esta charla, con lo cual, solo voy a centrarme en hablar de Ártica.

Para mí lo más significativo de nuestra empresa es que el 45% de nuestra facturación está hecha fuera de España, es decir, vendemos a diferentes países del mundo, y que somos una empresa de producto. Hemos desarrollado nuestras propias soluciones y no somos una empresa de desarrollo que hace servicios y da valor a otras, sino que tenemos un producto como toda la vida se ha considerado de software. De momento, el único producto que ha tenido un gran éxito, lo que para nosotros significa sobrevivir y crecer, es Pandora FMS, que es del que voy a hablar hoy.

PANDORA FMS: CÓMO COMPETIR CON LOS GRANDES FABRICANTES DE SOFTWARE

SIN MORIR EN EL INTENTO

Sancho LerenaCEO y cofundador, Ártica Soluciones Tecnológicas





Pandora es una herramienta que surgió en una entidad bancaria cuyo nombre no quiero decir... algunos ya sabéis de qué hablo. Pandora surgió como proyecto de software libre allá por el año 2003. Surgió como una iniciativa personal, luego fui aglutinando a gente que me ayudó y, bueno, ese fue el germen de la empresa como tal.

Ya he dicho quién soy, cómo me llamo, qué he estudiado pero lo que más nos define como empresa y de lo que más orgulloso estoy es de los clientes que tengo. Aquí podéis ver algunos de los más representativos. Del que más orgulloso estoy es de Rakuten, el Amazon asiático. Nuestra implantación en Rakuten ha sido en Tokio. Obviamente nosotros no hemos ido, ha sido un partner el que la ha hecho. Es nuestro proyecto más grande, de momento, con 9.000 servidores, y representa para nosotros el orgullo de vender tecnología a Japón. Fuimos allí a visitarle y parte del equipo actual de desarrollo de la solución está compuesta por un equipo japonés de cuatro personas. Otros proyectos representativos para nosotros... (quizás los nombres no os suenen porque muchas de estas empresas están fuera del ámbito TI). Por ejemplo Gestamp, que es el grupo de automoción más grande de España y uno de los más grandes de Europa con fábricas en 64 países, que monitorizamos con nuestra solución. En banca solo tenemos CajaSol, que ya no existe. Me gustaría mucho tener ahí a BBVA, Santander, etc., pero sí es cierto que trabajamos en todos los sectores. Por ejemplo, Ingeteam es una empresa española que se dedica a energías renovables. Otra multinacional es G4S, una empresa griega que, curiosamente, se dedica a temas de seguridad. Luego tenemos empresas

de transporte como la EMT, en la cual tenemos unos cuantos proyectos muy interesantes (ahora mismo hay un agente de Pandora en cada autobús, ¡tened cuidado!). También tenemos unos proyectos curiosos porque son en ámbitos gubernamentales, en este caso, en Brasil, en el Gobierno Regional de Acre, en el cual monitorizamos toda la infraestructura que están desplegando de redes wi-fi para sus poblaciones sin recursos; la verdad es que es un proyecto muy complejo. Y, bueno, cierto es que el gran proyecto para nosotros es Telefónica. Todo el mundo la conoce y tiene gracia porque parece que todo el mundo tiene a Telefónica como cliente, pero es complicado hacer un proyecto serio, grande y salir vivo con Telefónica. Hay otros cuantos clientes que no me dejan poner el logo y de esto voy a hablaré más tarde.

En esta charla quería contaros una historia acerca de la innovación porque todo el mundo habla de innovación, de I+D+i. El gobierno español está empeñado en que haya I+D+i. Todo el mundo habla de ello, pero es confuso, el concepto de la I+D+i, de la innovación… A mí todavía no me acaba de entrar, por eso, cuando estaba preparando esta charla, busqué una historia que pudiera representar bien lo que supone la innovación a la hora de fundar una empresa, a la hora de montar un proyecto. Así que vamos a remontarnos al siglo XII; ya sé que no había ordenadores, pero había otras tecnologías. Es parte de una leyenda, de una historia que dice que el Rey Ricardo Corazón de León, en plenas Cruzadas, se encontró con Saladino El Grande, que en esa época era el Gran General de los musulmanes. Y Ricardo era una de las figuras más importantes dentro del mundo




occidental cristiano. Así que un buen día se encontraron sus grandes ejércitos, y se pusieron a hablar de batallas, de espadas y de otras historias. El caso es que decidieron poner en común sus mejores tecnologías militares. Hablaron de sus batallas y de sus formaciones a ver quién impresionaba más al otro. En un momento dado Ricardo sacó su mandoble y con él partió de un solo tajo una barra de acero. Entonces, Saladino cogió su alfanje con un acero fascinante pero que parecía que se iba a romper, que era de juguete, tiró un trozo de seda al aire y con un esfuerzo mínimo lo partió en dos. (No sé si sabéis mucho de espadas, pero hacer eso con una espada es muy complicado). Y todo el mundo decía, “menudo truco, pero esto no tiene nada que ver con la guerra”. Y, con la misma espada, Saladino cogió y rompió el mismo trozo de acero que acababa de romper Ricardo, demostrando que su espada no solo era la más fuerte, la más rápida y la más ligera sino que, además, era igual de fuerte y cortaba mucho más que la del Rey Ricardo. Desde ese momento, todos los occidentales, durante nueve siglos hasta hace apenas unos 15 años que se descubrió por fin cómo se elaborada el acero de Damasco (curiosamente fue la Universidad Complutense de Madrid, junto con otras universidades americanas, las cuales, tienen una patente pendiente…) estuvieron intentado copiar el secreto del acero de Damasco, porque tal acero era en aquella época una ventaja competitiva, como dirían hoy en día los profesores de los MBA. Este acero permitía partir de una forma muy fácil el acero normal, permitía perforar las armaduras, cortar todo con una facilidad increíble y, además, no se desgastaba.

No se sabe ubicar dónde se descubrió, lo que sí que es cierto es que el acero de Damasco no venía de Siria, venía de la India. Y no lo inventaron los árabes, lo inventaron los indios. Lo que pasa es que los indios no lo sabían comercializar muy bien, así que en el siglo VII debía de haber un tío con barba, muy pequeñito y con una mochila, que llegó a la India, vio aquello y dijo “yo tengo un primo herrero que con un par de martillazos hace unas armas alucinantes”. Así que se lo llevó a su tierra, montó un chiringuito (vamos a llamarlo así), y fijaros si le ha ido bien porque es algo legendario: han tardado nueve siglos en copiarle y durante muchos años las batallas se libraban no solo para ganar a los árabes sino también para robarles las armas. De hecho, dicen que la espada del Cid, el metal que tiene no es toledano… No digo más.

Esto para mi es innovar. El hecho de que alguien vio una idea y le supo dar la vuelta. La idea no era suya, no había inventado el acero, no era él el que forjaba las espadas, pero vio el concepto y supo sacarle provecho. Yo imagino que al herrero que tenía estas armas en Damasco, el que las vendía a los príncipes y demás, no le iría mal. Así que, hablamos del germen de una pequeña empresa. La innovación, por tanto, desde mi humilde parecer, no siempre es un gran descubrimiento de la nada, sino que muchas veces es un redescubrimiento, una aplicación nueva a algo que ya existía. Muchas veces tenemos la sensación de que innovar tiene que ser algo absolutamente revolucionario y lo que ocurre, y en la historia está más o menos demostrado, es que cuando hay algo excesivamente revolucionario no acaba de cuajar.




Veremos que la innovación no parte de algo completamente nuevo, sino que adapta algo que ya existe. Y, por supuesto, la innovación no es solo técnica. El hombre que trajo el acero a Damasco probablemente no era herrero, sino mercader, y lo que supo es darle una vuelta de tuerca a todo este asunto. Y, algo muy importante, podemos traer innovación pero sin un mercado no sirve para nada. Es decir, si este buen hombre, después de hacerse el viaje hasta la India y volver, se hubiera dedicado a hacer espadas para gente pobre o espadas para artistas, muy probablemente no hubiera llegado a su nicho de mercado, que eran los príncipes guerreros, que tenían mucho dinero para generar un ejército de élite con esas armas.

Ya acercándonos un poco más a la tecnología, no sé si conocéis la historia de Edison y Tesla… ¿sí, verdad?... Y, probablemente, todos estéis a favor de Tesla porque era un genio. Bien, pues hay una historia menos conocida también con Edison, que es el malo de la película; pero Edison fue quien inventó la bombilla. Mentira, la inventó Göbel. Göbel fue el que realmente inventó la bombilla, pero no pudo hacerla funcionar durante más de unas horas. Edison sí. Ahora todo el mundo piensa que las bombillas las inventó Edison. Así que, en este momento, no sabemos a quién otorgarle la innovación si a Göbel o a Edison. Para mí, se la daría a Edison porque fue el que consiguió llevar la innovación a cabo, consiguió mercado y hacer que la gente pudiera leer por la noche.

Llegados a este punto podéis estar un poco desconcertados porque estamos en una charla de seguridad y yo os estoy hablando de espadas y de bombillas. Pensad que también estamos

hablando de empresa, de innovación y de pymes. Así que voy a centrarme ya más en las pequeñas empresas. Sabéis que una startup es una pyme, ¿no? Porque ‘pyme’ significa pequeña y mediana empresa. Las pequeñas empresas son, más o menos, de dos a nueve personas, las mediadas suelen ser de 10 a 30, 50 o 100 personas… Pues que sepáis que el 80% de las pymes mueren al llegar al año de vida. En algunos países en el 75%, en otros en el 90%, pero más o menos en todo el mundo estamos hablando de esas cifras. No son unas cifras exclusivamente españolas. Es cierto que en España la situación está muy mal, pero montar una empresa es complicado.

Partiendo de esto, de que empezamos con un planteamiento complicado, os voy a contar cómo lo he hecho yo, como he visto que lo han hecho otros emprendedores y qué fallos han cometido a este respecto.

Lo primero a la hora de montar una empresa, aparte de tener una gran idea, aparte de tener algo de dinero para ir tirando, si queremos tener una empresa que perdure lo que debemos tener es un plan a medio y largo plazo, y un plan a corto plazo. El plan a corto plazo es conseguir clientes lo antes posible. Es decir, montar una empresa de tecnología que quiera invertir durante cinco años y luego buscar clientes es, desde mi punto de vista, un suicidio. El plan a medio plazo es conseguir un producto, conseguir algo que tenga valor por sí mismo. Algo que se conseguirá con mucho trabajo, mucha dedicación, muchos viajes y muchas alianzas. Pero bueno, no me quiero adelantar. Estamos hablando de problemas, os he dicho que tener dos planes, a corto plazo y a




medio plazo, es casi imprescindible, pero también es imprescindible tener una formación fuera de lo técnico. Viendo esta sala, me da que aquí hay más gente del mundo de la gerencia, que del mundo puramente técnico. Yo pensaba que iba a ser al revés, con lo cual, la pregunta que voy a hacer ahora va a caer en saco roto. Pero la gran mayoría de las empresas fallan por no tener una gestión correcta, fallan porque tienen un equipo técnico muy bueno, tienen muchas ideas, pero no tienen a un gestor de empresa, a alguien en la parte financiera, alguien en la parte de gestión de proyectos, alguien en la parte comercial y en la parte de marketing que les apoye. Por eso fracasan más del 50% de las empresas.

Como resumen de cómo sobrevivir al comienzo, imaginaos que estáis en medio de una batalla y vosotros tenéis una pistolita de las pequeñas con una sola bala y el enemigo está completamente blindado con rifles de asalto, cargadores, granadas… y tú estás por ahí diciendo “Madre mía, como me vean me matan”. Pues eso es exactamente lo que se siente cuando eres una pyme y compites contra grandes empresas. Así que la única solución es tener muy claro que solo tienes una bala y tener muy claro que a ciertos enemigos no les puedes disparar porque no les vas a matar.

A veces escucho a emprendedores con un montón de ideas, con un montón de cosas en la cabeza que les gustaría hacer y que además se empeñan en llevar a cabo. De hecho, uno de mis principales fracasos al principio fue ese, que nosotros íbamos con cuatro productos al mercado, con una línea de servicios y cada vez

que nos preguntaba alguien sobre una cosa abríamos una línea de servicios nueva. Así que, claro, si intentas abarcar tanto siendo muy pequeño es muy complicado hacer algo bien. Ese es el gran consejo que yo os podría dar al principio de cómo sobrevivir.

Ahora vamos a la segunda parte. Una vez que hemos sobrevivido, ¿cómo competimos? El gran secreto de todo es conocer bien a la competencia, ser capaz de aprender de forma continua, copiar, copiar, copiar, mejorarlo y volver a empezar, porque la competencia no para. Esto es una parte de ello, así que esa gente que reniega de conocer al contrario y que piensa que sus ideas son mejores tiene un gran problema porque siempre hay alguien mejor que tú. Lo único es que puedes usar sus ideas para tu propio proyecto. Así que, escucha, aprende de ellos y, por supuesto, aprende de tus clientes. Yo digo muchas veces a mis clientes que, a veces, les debería de pagar yo a ellos por las ideas que me dan, porque gracias a sus ideas yo mejoro mi producto. Hoy en día, Pandora no sería el producto que es sin las grandes ideas de mis clientes. Calculo que entre el 60% y 70% de mi producto ha venido de sus ideas. Ojo, ideas con criterio, hay que saber también decir que no.

Hablando de pymes y sobre cómo sobrevivir hay dos puntos importantes más. La innovación es lo que te va a distinguir de la competencia: si te limitas solamente a copiar y a mejorar vas a ser como los chinos que, hasta ahora, se han limitado a copiar, mejorando los costes e invadiendo. Pero eso no basta si realmente te quieres distinguir




y sobrevivir. La innovación te va a permitir distinguirte de una forma efectiva, mantener una distancia con la competencia y una diferencia. Esta innovación también se tiene que aplicar al marketing. Quienes tengáis un presupuesto de 2.000 euros al año que sepáis que se pueden hacer muchas cosas, obviamente no de las formas tradicionales. Así que la innovación abarca no solo la parte de TI sino también, la parte comercial. Hay un concepto llamado marketing de guerrilla (hay muchos libros que hablan específicamente de esto). Y por último y lo más importante, es el equipo humano. Lo que distingue una pequeña empresa de una gran empresa es que en una gran empresa siempre va a haber mucha gente, no que sobre, pero sí que realmente podría hacer más de lo que hace en ese momento. No voy a hablar de experiencias personales, pero siempre he creído que las empresas pequeñas, cuando tienes un equipo que encaja, son capaces de dar el 110% de lo que tiene dentro y eso los distingue generalmente de una gran multinacional. Cuando competimos con IBM, porque nosotros hemos competido con IBM, con HP, etc., el propio cliente nos decía: “¿Cómo es posible que hagáis en tres semanas lo que hace IBM en un año?”. Por todo esto, por agilidad, porque nuestro personal no es que sea mejor, es que es más ágil, vamos más rápido porque no le tenemos que dar el montón de explicaciones que tienen que dar las grandes empresas. No tenemos ese proceso tan pesado. Y eso es otra de las cosas que hace diferente una pequeña empresa respecto a una grande: la flexibilidad del equipo humano.

Cometer un error en cualquiera de estos puntos, por ejemplo, no innovar, no aprender de tus

clientes, no conocer la competencia o tener un equipo humano inadecuado, puede ser motivo de fracaso de una startup casi en el primer año.

Ahora voy a hablar de mi libro. Durante mucho tiempo la gente me ha preguntado por qué hice otra herramienta de monitorización. En el momento en el que escogí hacer una ya había dentro de las cuatro grandes (HP OpenView, IBM Tivoli, Patrum y Spectrum, que entran dentro), y otras siete u ocho open source y otras siete u ocho mitad comerciales con un modelo open source. Es decir, había más de 20 productos similares. La verdad es que si hay que innovar es mejor hacerlo en un sector que no esté tan copado como la monitorización, pero realmente, cuando decidí meterme en este mundo fue porque veía que no había una solución con una arquitectura flexible como para monitorizar ciertas cosas. Esta idea surgió cuando estaba trabajando dentro del grupo de seguridad lógica de una entidad bancaria cuyo nombre no quiero decir, donde había una serie de requisitos para monitorizar ciertas cosas y con las herramientas que teníamos no se podía, así que como yo soy ingeniero me puse a inventar y de ahí surgió la idea. Nuestra innovación principal respecto a la competencia es el modelo de arquitectura que tiene tan distribuido y tan flexible que no es tan habitual o no existe ninguna herramienta que lo tenga tal cual. Pero luego, como os decía antes, fuimos recogiendo ideas de clientes y fusionamos conceptos de diferentes tecnologías.

Hace mucho tiempo fui instructor de Check Point, de sus firewalls, y tenían un modelo que se llamaba metaconsola y tenían un concepto




de arquitectura federada que permitía hacer un escalado de los sistemas bastante interesante. Bueno, pues yo lo copié tal cual y me quedé tan ancho. De hecho, a mí me lo ha copiado ya mi competencia, aunque no con ese nombre. Entonces tú haces una cosa y viene uno y lo copia, luego lo mejora y luego lo tienes que coger tú y seguir mejorándolo. Es lo que os decía de innovación continua. Desde luego si os limitáis a copiar a los demás siempre vais a estar a la cola, da igual que seáis grandes o pequeños. Los grandes lo que hacen es comprar a los pequeños y se ponen automáticamente arriba.

Volviendo al tema, ¿qué tiene de especial Pandora? (Esta es la parte donde yo vendo mi solución y digo que es fantástica y todos me tenéis que decir que sí). La gran ventaja de Pandora es que nosotros competimos contra los grandes. La gran mayoría de las soluciones no pretenden competir contra los grandes, pretenden comerle un trocito. Yo los quiero quitar de encima completamente. De hecho, en Telefónica, los hemos reemplazado, vamos a decirlo así. Hemos reemplazado a Tivoli y hemos reemplazado a OpenView gran parte de su operación. En otras empresas hemos hecho lo mismo como, por ejemplo, Rakuten, donde estamos hablando de 9.000 servidores, no estamos hablando de una pyme. Nuestra gran innovación y creo que en esto somos únicos, es que integramos paradigmas que antes eran estancos: hay herramientas de monitorización de red, herramientas de monitorización de eventos, herramientas de monitorización de alarmas de red, de intrusiones en red, de intrusiones en sistemas, de rendimiento, de eventos… y son

especializadas, cada una lo hace muy bien en su contexto, pero no había una herramienta que pudiera hacerlo todo. Esos somos nosotros. Quizá en algunas cosas no seamos tan fuertes como herramientas especializadas, pero la gente echaba de menos una herramienta que cohesionara todo ese mundo y ahí es donde estamos. Os puede parecer que no es una gran innovación, no hemos descubierto cómo monitorizar por arte de magia, pero la gente muchas veces tampoco necesita eso. La gente tiene una serie de necesidades y es cuando hay que escuchar al cliente y llevarlo a cabo.

Tres cosas que nosotros creamos que no tenía nadie: bulkrequest es hacer un montón de peticiones a ‘bulto’, a un montón de IPs, a un montón de destinos, del protocolo SMLP, que es un protocolo que se usa para monitorizar… pues no había nadie que supiera hacer esto, lo hacían de una forma secuencial y aquello tenía una escalabilidad limitada, es decir, podías hacer cierto número de chequeos por segundo. Pero claro, para ciertas necesidades no daba. Yo estuve rompiéndome la cabeza durante mucho tiempo para ver cómo hacerlo, pero no soy programador, soy ingeniero y la cabeza no me daba para tanto. Así que lo que hice fue probar diferentes soluciones de código que había por ahí y vi un código medio roto de un polaco que prometía hacer esto y, de hecho, lo hacía con muchos problemas, tuvimos que parchearlo y gracias a esto nosotros fuimos capaces de hacer más peticiones de SMLP que nadie de nuestra competencia. Desde luego, mandamos las correcciones al autor original del código y lo incorporamos a nuestra solución.




Otra gran evolución es a nivel de arquitectura; ya no es tan técnico sino, más bien, conceptual. La gestión de la monitorización completamente descentralizada, completamente conexionless, es algo que permite monitorizar un millón de cosas con la misma arquitectura. Esto tampoco lo tiene la competencia. Y lo que os decía de Check Point.

Ahora os voy a contar otra historia porque creo que os gusta más que os cuente historias que que os cuente cosas de mi libro. Esta es una historia que habla más que de innovación, de cómo gestionar esa innovación. Me la contó mi director comercial, que es una persona con muchísima experiencia comercial, no como yo, que me sirvió para entender la relación que hay entre las grandes empresas y las pequeñas empresas.

Había una vez un sastre que tenía una tienda pequeñita en Chamberí, que hacía unas camisas que eran el boca a boca en el barrio porque tenían un tejido increíblemente bueno, con una calidad y un detalle final que nadie tenía. Era complicado encontrar una camisa similar si no ibas a esa tienda y, además, no eran especialmente caras. Así que un buen día se le acercó un señor con traje, corbata y un poquito grande. Era el responsable de distribución de una gran cadena de tiendas de ropa. (No voy a decir cuál, solo que tiene tiendas en toda España. Esta es una historia real, ¿eh? No me la estoy inventando). Así que el hombre le estuvo haciendo una serie de preguntas sobre cuánto le costaban las camisas, cuánto le costaba el género, cuántos empleados tenía, qué inversiones financieras tenía, qué deudas… Bueno, estuvieron hablando durante varios días

y el hombre de la gran empresa le dijo, “Vamos a llegar a un acuerdo, si tú me entregas 500 camisas al mes, yo te hago un pedido de un año y te lo pago ahora”. El sastre empezó a hacer números, se le pusieron las pupilas con el signo del dólar y pensó “Esta es mi oportunidad de crecer”. Hizo los cálculos y tenía que contratar a más personas, tenía que hacer un gran pedido de tela, tenía que comprar una máquina que no tenía y dijo “voy a pedir una hipoteca, voy a pedir dinero a mis abuelos y además, dejaré de llevar a mi hijo a un colegio privado”. Se metió en la inversión, hizo la primera entrega del material y llega el hombre y dice “Bueno, está muy bien el género pero es que la gente de Compras me ha dicho que tenemos este año –el próximo año ya veremos– que aplicar un 15% de descuento en todo el pedido”. En ese momento, el sastre volvió a hacer cuentas y, seguía ganando dinero, pero ahora estaba muy apretado. Podía pagar todas las facturas, la hipoteca, pero ya no tenía capacidad para hacer nada más. Él tenía pensado, con el dinero que sacara de ahí, hacer otra línea de inversión en moda, pero vio que tenía un gran cliente que le iba a pagar pero no podía hacer otra cosa. El otro hombre le prometía que iba a renegociar, que iban a hacer un pedido que, en vez de 500 camisas, iba a ser de 1000, pero el caso es que, a partir de entonces, las ideas del sastre, su innovación… ya no las podías llevar a cabo porque tenía que hacer las camisas que el gran empresario quería. Y el gran empresario no tenía ni idea de hacer unas camisas para gente especial, con gusto, que apreciara el detalle. El gran empresario lo que quería eran camisas




baratas y buenas: bueno, bonito y barato. Y así le dijo “Vamos a hacer las camisas un poco más baratas, déjate de tantas filigranas que yo quiero vender muchas de éstas”. Así que nuestro sastre, nuestro innovador, tuvo que dejar de innovar y tuvo que hacer lo que le decían. Es decir, llegados a este punto, perdió la libertad, perdió el poder de negociación. Ya no le podía decir al empresario que no, porque tenía que pagar facturas y tenía una deuda tan grande que su capacidad de decidir, su destino, ya estaba en manos de otro. Sin libertad, puedes crecer, puedes vender muchas camisas malas, puedes deslocalizar tu fabricación a la India, puedes hacer muchas cosas pero, probablemente, ya no vayas hacia donde tú querías ir. Tu visión como emprendedor, tu visión como innovador se diluye. No sabes a dónde vas. Sabes que estás ganando dinero pero pierdes el concepto. Y si no innovas, no hay futuro. Al final, te comerá alguien más grande y se acabó.

Una cosa que hunde a los emprendedores es el primer cliente. De hecho, esto tiene un nombre, pero ahora no sé cómo se llama. Hay un nombre para el problema que genera el primer empleado, hay un nombre para el primer gran cliente y hay un nombre para el primer gran todo. Recuerdo, cuando hice la factura a nuestro primer gran cliente, que nos costó tiempo despegarnos de ese cliente. Si hubiéramos seguido pegados a él, seguramente no habríamos crecido y ahora estaríamos dependiendo de él completamente, como en el caso anterior.

La gran ventaja que tiene el primer cliente es que te permite generar una gran referencia pública,

que te conozcan por el trabajo que hiciste allí, porque la gente no te va a conocer si haces un trabajo para Alcantarillas Paco, no. Puede ser una empresa fantástica, puedes haber ganado mucho dinero pero Alcantarillas Paco no te va a dar nombre. Sin embargo, si haces un trabajo para la NASA, no sé qué tipo de trabajo será pero, desde luego, te van a conocer. Así que hay que luchar por conseguir meterte en la NASA. Pero, una vez que has conseguido meterte en la NASA tienes que salir corriendo de allí cuando puedas. Por eso, tienes que conseguir más clientes, a ser posible con nombre, para que te permitan acceder a más clientes. Es lo que se llama obtener referencias y hacer casos de éxito, incluso, perdiendo dinero. Yo, con uno de los primeros clientes que tuve entré perdiendo dinero o no ganándolo: trabajaba prácticamente a coste. Si no hubiese soltado esos clientes probablemente hoy estaría muerto. Para resumir todo esto tengo un dicho que es: “De los clientes con nombre obtendrás reputación, de los clientes sin nombre obtendrás beneficio”. Lo ideal es encontrar un buen cliente con nombre del que puedas obtener reputación, beneficio, que te ayude, etc., pero yo todavía no lo he encontrado. Una empresa si no innova, si no va creando un activo, al final se va quedando pequeña y cuanto más pequeña eres, más fácil es que te devoren.

Cuando hablo de crecimiento no hablo de ganar dinero. La gente con el dinero tiene un problema. Se lo digo a mis empleados, por qué siempre estáis hablando de dinero. También se lo digo a mis clientes. La forma de crecer, realmente, es engordar tu activo. Engordar, en este caso, tu producto. Tu producto es lo que hace que tengas una presencia en el mercado, que tengas algo que




le interese a la gente, lo que hace que la gente te llame, que vayas poco a poco creciendo, porque lo que nos interesa es crecer, y poco a poco ir haciendo más.

Para terminar, voy a hablar de financiación. Hay muchas formas de financiación. En mi caso, la que he usado es la financiación vía I+D+i. Para ello, generalmente te hace falta tener un negocio ya establecido. No vale montar una empresa y decirle al Estado “Papá, dame dinero”. No funciona así. Generalmente, hay dos formas de financiación. Por un lado, mediante la cual tú pones una parte y yo pongo la otra, que es la subvención parcial. Generalmente es un 20%, 40%, 60% y, obviamente tú tienes que poner la otra parte, por lo que si no tienes dinero, no te pueden dar dinero. Y, por otro lado, hablamos de préstamo, es decir, tiene un 4% anual de interés o lo que sea, lo que significa que lo tienes que devolver. Y no es lo mismo deberle dinero al banco, que al Estado. Y hablamos siempre de cantidades bastante grandes, de uno o dos millones de euros de préstamo o de subvención. Por lo que no es sencillo obtener dinero a través de las subvenciones de I+D. Por supuesto, la forma más fácil de que no te lo den es tener una propuesta basada en servicios; por eso, hablaba de la importancia de tener un activo, de tener un producto. He participado en varios programas europeos y os puedo decir que si no vais con alguien que conozca un poco el asunto es muy complicado entrar.

Otra de las formas es a través del capital riesgo. En este país, aún no he conocido a nadie que entienda el significado de “capital riesgo” como lo entienden los americanos. Por eso, he

puesto venture capital, porque me parece más correcto. Generalmente, interviene cuando la empresa ya ha echado flores, no ha echado unas grandes flores pero ya empiezan a echar flores, ellos huelen y dicen: “Aquí hay posibilidad de crecimiento”. Un inversor de Nueva York me contó que invirtieron en una empresa de mi competencia cuando estaban ganando 30 millones de dólares anuales de facturación. Ellos entraron en esa fase. Después de salirse, ocho años después, esta empresa facturaba 3.000 millones. El negocio de monitorización de HP está en torno a 7.000 millones. Es decir, se come la mitad del negocio de monitorización de HP. Y esto es lo que hace una empresa de capital riesgo, te proyecta. No mete dinero y se olvida. Mete dinero, conocimiento y te ayuda a echar para adelante las ideas que tienes.

Después de todo esto que os he contado, he juntado un grupo de nombres como Wozniak, Jobs, Tesla, Edison… además a todos al lado, en el mismo cuadro… a gente de nuestro entorno, como Carmack, que no sé si os sonará, etc. Y he puesto dos cajas, dos opciones: “Quiero hacer dinero, no historia” y “Quiero hacer historia, no dinero”. Os puedo asegurar que la gran mayoría de emprendedores y empresarios de éxito que he conocido cuando empezaron a hacer lo que querían hacer no pensaban en el dinero (hombre, el dinero está ahí, el dinero hay que usarlo, el dinero es una herramienta), pero el motor que les movía a ellos no era el dinero. Sin embargo, hay nombres, seguro que conocéis las historias tristes de Tesla, de Wozniak… tristes para mí por el decrecimiento que tuvieron que, en contraposición con sus enemigos en esa época




acabaron bastante mal y eran personas con una capacidad muy buena, eran genios. Sin embargo, ellos querían cambiar la historia pero, al final, no consiguieron cambiar la historia como ellos querían y tampoco consiguieron dinero. Este, para

mí, es el resumen de mi charla: no solo basta con innovar, no basta con ser un genio, lo importante es ponerlo en el mercado y hacer que tu idea original llegue a germinar y llegue a cambiar el mundo y, obviamente, a darte algún dinero.




Os pongo en antecedentes. Tarlogic es una empresa de seguridad informática que surge a finales de 2011. Es una empresa que fundamos Miguel y yo,

y ahora mismo somos un equipo de 13 personas más otro freelance en Estados Unidos. Tenemos principalmente dos áreas de negocio: una es la de Servicios de Consultoría de Seguridad Informática y la otra es el área de Producto, que es la de I+D, donde desarrollamos una serie de soluciones que os comentaré más adelante.

¿Qué hacemos? Nuestro objetivo, nuestro día a día, al final es ayudar a las empresas a proteger sus sistemas informáticos para evitar fugas

ESPECIALIZACIÓN E INNOVACIÓN PARA COMPETIR EN SEGURIDAD

Andrés Tarascó AcuñaCofundador y auditor de seguridad, Tarlogic


de información, analizar o rastrear cualquier amenaza a sus sistemas informáticos o que pueda afectar a su continuidad de negocio. (Por enseñaros un resumen rápido, os voy a poner un pequeño vídeo. Estoy orgulloso, porque somos una empresa pequeña con poco presupuesto para marketing y ya que tenemos un vídeo promocional y que resume lo que hacemos, os lo voy a enseñar…).

No os lo he mencionado, yo lidero el área de Seguridad Informática. Miguel, mi hermano, lidera el área de I+D. Son dos líneas que están muy ligadas entre sí. Y su nexo de unión es la seguridad informática. Tanto Miguel, como yo, arrastramos




la pasión por la seguridad. De hecho, cuando de pequeños otra gente se iba a jugar al fútbol, nuestro juego era ver quién era capaz de entrar en más sistemas informáticos en menos tiempo. Cuando empezamos en 2011 éramos 2 personas y ahora mismo somos 14, esperando a ser 18 de aquí a final de año. Y tenemos intención de llegar a 30 el año que viene.

Realmente, lo que quiero contaros es qué supone esto del emprendimiento para una persona, cómo es de difícil, cómo es la situación actual de una persona para emprender y cuáles son las penurias que tenemos que pasar para poder crecer y competir en este sector. Cuando la gente dice que el emprendimiento se lleva en la sangre, para nosotros fue una suma de factores. El primero fue la necesidad. En mi caso, me encontré en la situación de buscar una nueva salida profesional y tenía que buscar dónde lo hacía. La opción más rápida en 2011 y con la situación económica que atravesábamos, era salir del país, daba igual si por tierra, mar o aire, pero todo apuntaba a que fuera de España todo era mucho más sencillo. En el caso de mi hermano, trabajaba como investigador en la Universidad de Santiago de Compostela en una serie de productos muy interesantes pero vinieron los recortes y su puesto de trabajo se suprimió. Entonces, nos encontrábamos dudando si intentábamos trabajar en Galicia con casi una ausencia de tejido empresarial de empresas tecnológicas o irnos fuera. Teníamos a nuestras familias, teníamos a nuestros amigos, teníamos ganas de montar algo en Galicia y nos lanzamos a la aventura.

Por otro lado, fue una inquietud. Teníamos ganas de innovar, de hacer cosas distintas en seguridad

informática, un poquito distintas a cómo se hacen en otras empresas del sector, lo cual no quiere decir que no funcionen, sino que teníamos una visión distinta y, sobre todo, queríamos apostar por la investigación y el I+D: en las empresas que no son cien por cien de seguridad, sino que la seguridad es un departamento más, una línea de negocio más, no siempre se lleva a cabo.

También teníamos la intención de desarrollar cosas distintas. Teníamos varias ideas pero no sabíamos hasta qué punto podían ser viables.

Por otro lado, la seguridad es nuestro hobby, nuestra pasión y a lo que nos queríamos dedicar profesionalmente.

¿Cómo afrontamos esta situación en 2011? Lo primero era la idea. Teníamos claro que queríamos montar una empresa y lo primero que hicimos fue pensar en “qué es lo que vamos a hacer”, “tenemos que sobrevivir”. “Pues vamos apostar por algo que a corto plazo que nos de suficiente liquidez para salir adelante”. Entonces, contactamos con antiguos clientes, empresas con las que habíamos trabajado, gente con la que teníamos contacto en el sector e intentamos cerrar los primeros trabajos para asegurarnos una continuidad para, al menos, los primeros meses de vida de la empresa. A continuación, definimos una serie de servicios básicos que podíamos empezar a ofrecer, decidimos que el hacking ético iba a ser el núcleo de la empresa. Todo tenía que estar relacionado con hacking ético, no queríamos perder en ningún momento el norte. Constituimos la sociedad de forma telemática, a través de CIRCE, y en 24 horas empezamos a




trabajar. Obviamente, lo que teníamos claro es que necesitábamos asesoramiento no técnico. Tanto mi hermano como yo somos técnicos, no somos informáticos, al igual que el cien por cien de nuestro equipo, que es puramente técnico. Y había otra serie de habilidades que necesitábamos adquirir para asegurar el éxito.

¿Cómo se gestiona una empresa? La verdad es que no teníamos ni idea. Necesitábamos de terceros que nos ayudasen a evitar ese alto porcentaje de fracaso que existe en las empresas o las startups durante el primer año. Lo que hicimos, el día 1 después de la constitución de la empresa fue empezar a trabajar en nuestros clientes, en unas jornadas semanales de 70 u 80 horas. Algo que duró aproximadamente dos años. Es decir, trabajar 12 horas diarias durante dos años, sin un solo día libre, sin vacaciones y sin posibilidad de ponerte enfermo. Además, de los trabajos que realizábamos para nuestros clientes, íbamos adquiriendo otra serie de habilidades, como formación en recursos humanos, formación financiera, formación en marketing desarrollando contenidos, desarrollando propuestas tipo, desarrollando nuestra página web, etc. Y, obviamente, cada vez que tenías que viajar para hacer una visita comercial a un cliente se te caía el mundo porque no te llegaban las horas del día. Fue una época bastante dura.

No hemos tenido financiación. La empresa nació con el capital mínimo necesario para constituir una S.L., que son 3.000 euros, y quizá una de las cosas de lo que estamos más orgullosos es que nunca le hemos debido un euro a nadie. Nadie nos lo ha dado, ningún banco, ninguna línea de

financiación... Yo creo que no existen. Hay gente que dice que sí, pero creo que es un poco leyenda urbana. Y nuestra estrategia, como dijo Sancho, era economía de guerra: no gastes absolutamente nada que no tengas, y todo el dinero que entra en la empresa es para reinvertir, para poder crecer.

Entre las cosas que hemos visto durante el primer año están los impuestos, que es algo que puede matar tu startup. Al principio no eres consciente de la cantidad de impuestos que tienes que pagar y ves que ese dinero que tienes en el banco desaparece y se divide por arte de magia. Es importantísimo decidir quiénes quieres que sean tus clientes. En nuestro caso nos marcamos una serie de metas y nos dijimos “No queremos trabajar para la administración pública”, aunque a lo mejor no sea políticamente correcto decir esto, pero lo que necesitábamos era que nos pagasen. Y, por temas éticos, hubo también una serie de empresas o áreas con las que dijimos que no queríamos trabajar. La única ventaja que teníamos era que, por nuestro sector, seguridad informática, hacking ético, entramos en la seguridad de los sistemas de nuestros clientes hasta la cocina, y pocos se atreven a no pagarte. Te pueden retrasar los pagos y te pueden poner en un aprieto pero tenemos la suerte de estar en un sector en el que se paga y se suele pagar a tiempo. Aunque, durante el primer año estuvimos a punto de cerrar por temas de retrasos. Tienes que dejar de trabajar con esos determinados clientes malpagadores, porque te suponen un problema.

Una de las cosas que aprendimos es que cuesta el mismo esfuerzo vender un servicio o un producto a una empresa pequeña que a una empresa




grande, con la diferencia de que las grandes lo habitual es que sepan lo que quieren, (aunque no siempre). Eso hizo que nos centrásemos sobre todo en empresas grandes. También, por nuestra trayectoria profesional estábamos más acostumbramos a trabajar con empresas de un volumen importante, como firmas que cotizan en bolsa, banca, telecomunicaciones, biotecnología… Y ese fue nuestro target. Decidimos orientarnos a trabajar con empresas grandes.

Otra de las cosas que tuvimos que aprender bastante rápido fue saber por qué somos diferentes. Esas cosas las aprendimos al principio, pues no podíamos competir por precio. Todo el mundo compite en precio pero es mejor mantenerte firme y que seas la empresa que no se puedan permitir, que meterte en esa lucha. Y, sobre todo, aprender cuál es tu valor diferenciador, qué estás ofreciendo frente a la competencia. En nuestro caso, buscábamos la excelencia, una dedicación más allá de lo habitual, un equipo especializado para hacer este tipo de trabajos de análisis de seguridad. Y, sobre todo, aprender a decir que no. Te puede suponer muchísimos problemas decir que sí a determinados trabajos y, en nuestro caso, todos los trabajos que nos han propuesto, aunque fueran muy lucrativos económicamente, si se alejaban de lo que era nuestra visión del tipo de servicio que queríamos desarrollar, los hemos desechado.

¿Qué hemos desarrollado? Os he comentado que tenemos dos grandes líneas: Servicios y Producto. Teníamos nuestra idea del producto que íbamos a desarrollar. De hecho, cuando

montamos la empresa teníamos clarísimo que nos íbamos a orientar a un servicio cloud de análisis de varias cosas que no vienen a cuento y la realidad es que en el día a día, el cliente te va marcando hacia dónde tienes que ir. Uno de nuestros primeros trabajos fue analizar una infraestructura de telecomunicaciones wi-fi de un cliente con más de 500 puntos de acceso y nos encontramos con que, aunque era un campo en el que nos sentíamos bastante cómodos, no teníamos herramientas para poder hacer este tipo de estudios. El día 1 de la empresa, con el primer trabajo, nació Acrylic WiFi, que es un sistema de monitorización y análisis de comunicaciones inalámbricas. Ahora tenemos tres productos en el mercado: la versión gratuita, la versión profesional y la versión que se dedica a hacer análisis de cobertura de infraestructuras. Somos, quizá, el único producto del mercado que es capaz de utilizar la tecnología wi-fi en Windows para capturar tráfico e integrarse con Wireshark y otra serie de herramientas que no existen en ninguna otra solución en el mercado. Y, sobre todo, queríamos huir de la pantalla en negro para hacer análisis de todo esto. Queríamos hacer algo muy visual, muy intuitivo, de forma que cualquier persona pueda utilizar este tipo de productos. Desde que hemos lanzado Acrylic WiFi tenemos más de 50.000 usuarios de nuestra versión gratuita del software. La versión profesional y la versión HeatMaps están empezando a funcionar bastante bien. Es lento, como pequeña empresa tenemos nuestras limitaciones en cuanto a presupuesto de marketing, pero también hacemos marketing de guerrilla que no viene a cuento.

Nuestra apuesta para 2014-2015 es irnos a la parte




de seguridad, tanto análisis de seguridad pasivo como análisis de seguridad activo y otra gama de productos que están también en desarrollo, orientados a agencias gubernamentales, todo lo que tiene que ver con triangulación de dispositivos.

Os enseño unas imágenes de Acrylic WiFi: como veis vamos a hacer mapeo o cobertura de redes, análisis de solapamiento de canales, análisis de comportamiento que es algo también bastante novedoso que no hace ningún otro producto de software de análisis de comunicaciones inalámbricas, toda la parte de captura de información o representación de datos.

Con la gama de Acrylic WiFi realmente lo que queríamos hacer era cerrar el círculo. Empezamos desarrollando una metodología de seguridad abierta que se llama Open Wireless Security Segment Methodology. La metodología definía una serie de riesgos; con el software medíamos los riesgos. Después desarrollamos una APT, que veremos por aquí, la cual utiliza tecnología wi-fi para infiltrarse en sistema en organizaciones y, por otro lado, también desarrollamos la herramienta que es capaz de detectarlo y protegerte.

En los servicios de Tarlogic, os decía que el hacking ético es nuestro núcleo de negocio, sobre todo, con trabajos de test de intrusión, análisis de páginas web, análisis de aplicaciones móviles… Trabajamos mucho con empresas que venden a través de Internet, con sectores bancarios, donde tenemos experiencia de banca electrónica, eCommerce, etc. Realizamos definición de

arquitecturas de red seguras, respuesta ante incidentes, fortificación, ingeniería social… A día de hoy las empresas invierten muchísimo dinero en protegerse en multitud de tecnologías y la ingeniería social es el principal punto de filtración dentro de las empresas.

Esta es quizá una de las partes más divertidas dentro de Tarlogic: intentamos dedicar gran parte de nuestro tiempo, siempre que sea posible, a I+D+i y uno de nuestros hobbies ha sido desarrollar Acarus. Acarus es un APT, un malware utilizado en tests de intrusión, y lo utilizamos en las empresas para demostrarles que somos capaces de infiltrarnos en su organización y que por muchas barreras de seguridad, muchos controles que tengan, somos capaces de encontrar la forma de sacar los datos desde dentro de la organización hacia fuera. Para ello, utiliza cosas tan curiosas como infiltración de datos por DNS, PHTP, etc. Algo que también hemos presentado es exfiltración a través de wi-fi. Es decir, tenemos un equipo, un Windows, un iOS, un Android y, aunque el dispositivo no tenga ninguna red IP y no esté conectado a una red wi-fi, somos capaces de conectarnos al sistema y robar datos a través del tráfico de señalización.

Otra parte divertida que hacemos en Tarlogic dentro de la línea de Servicios es la de investigaciones. Es decir, investigar qué ha pasado, quién ha sido el responsable de determinadas acciones o si existe algo que está provocando pérdidas dentro de mi compañía, robo de información, suplantación de identidad, phishing, etc. En este sentido, desarrollamos herramientas de monitorización a medida para dar soluciones a




medida a estos clientes. Dentro de nuestra línea de especialización, dentro de seguridad, la ingeniería inversa es algo que también nos ocupa mucho tiempo. Por ejemplo, trabajamos con operadores de telecomunicaciones haciendo ingeniería inversa y análisis de seguridad de dispositivos de comunicaciones, de routers domésticos, de routers de empresas, etc., con el objetivo de identificar puertas traseras que haya podido incluir el propio fabricante y conseguir al final proteger a los usuarios de las empresas. Aquí, el trabajo es con pantalla negra y muchas horas mirando líneas de código.

La verdad es que haber llegado hasta aquí no ha sido fácil, especialmente, sin financiación, sin demasiada ayuda ni apoyos, pero creo que hemos llegado a un momento de madurez dentro de Tarlogic y nuestros objetivos a corto plazo son terminar de afianzarnos en el mercado español y conseguir la presencia internacional que creo que la línea de producto Acrylic WiFi nos está dando. Os he contado muy por encima cuáles son nuestros distintos productos... Realmente es un proyecto muy a largo plazo en el que queremos competir con las grandes, veremos si no nos comen por el camino, y esa es una de nuestras principales vías de expansión. En relación a la parte de I+D, estamos en proceso de identificar partners, empresas a nivel internacional que nos ayuden a distribuir nuestros productos y también estamos en el paso de buscar esa financiación de la que hemos huido al principio porque no queríamos que nadie externo a la organización corrompiese nuestra visión, que nos dijese que no podíamos ir en una determinada línea.

¿Qué nos hace diferentes? Os lo decía antes. A pesar de que somos una empresa de consultoría, nuestro foco, nuestro core es la seguridad informática. No hacemos nada más que seguridad informática y lo que buscamos es la especialización de nuestro equipo. Y, junto con la especialización de nuestro equipo, lo que buscamos es una ética profesional que no siempre se ve en todas las empresas de transparencia completa para el cliente. Es decir, nunca venderemos un servicio a una empresa que lo demande si ese servicio no se puede llevar a cabo, sobre todo, porque al final nosotros somos el equipo técnico que lo va a ejecutar. Y, desde luego, intentamos siempre ir con las empresas de la mano, no desligarnos en el momento en el que cerramos un proyecto: queremos estar dentro de esa evolución de la seguridad dentro de las organizaciones. Y esto es todo. Nos ha ido bastante bien. La especialización es algo que cada vez se ve más en el mercado y creemos que tanto esa línea de servicios, que a corto plazo nos ha permitido mantenernos en el mercado, como esa línea de productos que nos permitirá crecer y hacer cada vez más ruido en el mercado, se enmarcan en un buen modelo de especialización.

Turno de preguntas

La presentación ha sido muy buena y me quedo con una frase que es “copia, copia y mejora”. En este caso, en su startup, que tiene un producto innovador que no está en ninguna otra compañía, ¿qué planean hacer cuando otra




empresa se de cuenta de que pueden copiar y mejorarlo?

Nosotros también hemos copiado. Nuestra gama de HeatMaps existe en el mercado. Hay un montón de empresas muy bien posicionadas y cuando sacamos nuestro producto, nuestra primera versión de la que no estábamos orgullosos (dicen que si la sacas y estás orgulloso es que la sacas demasiado tarde), empezamos a ver que realmente nuestro software no era competitivo porque faltaban una serie de funcionalidades muy interesantes que tenían otras empresas del sector. Obviamente, hemos investigado, hemos analizado a la competencia y hemos intentado aglutinar todas aquellas funcionalidades del resto de las herramientas del mercado e incluirlas en nuestro software. ¿Qué hemos estado viendo desde el momento en el que hemos sacado Acrylic Wifi? Que ciertas funcionalidades que teníamos nosotros y que no tenían el resto de la competencia sí que las han ido copiando. Pero tenemos muy claro hacia donde queremos ir y creemos que

el salto, la innovación que van a suponer cada una de nuestras versiones de software, es muy importante: llevamos dos años y medio de trabajo y creemos que vamos a ser capaces de llegar al mercado antes que ellos.

Está claro que se trata de llegar al mercado antes, innovar y llegar al mercado antes que los demás, ¿no?

Claro. Quizá, el negocio dentro de la seguridad inalámbrica del resto de las empresas es muy específico: o quieren medir algo o quieren representar cierta información. Nosotros queremos hacer el círculo completo, es decir, tenemos la metodología de análisis, tenemos la identificación de dispositivos, la triangulación de dispositivos, el análisis de la cobertura, un framework de análisis de seguridad con el que queremos meternos dentro de la tecnología, ser capaces de certificar productos de software o de hardware que hacen uso de comunicaciones inalámbricas. Y creo que esa visión que tenemos se aleja de la que tienen el resto de la competencia.




PROTEGIENDO LA INFORMACIÓN EN LA NUBE. TECNOLOGÍAS DE CIFRADO

Isaac AgudoProfesor contratado. Doctor por la Universidad de Málaga. Network, Information and Computer Security Lab, UMA


La idea de la charla es no solamente contar nuestra propuesta en particular, sino también abrir la visión sobre por qué hace falta una seguridad adicional en entornos

cloud. Vamos a ver una introducción del cloud computing muy ligera. Entiendo que ya todo el mundo tiene una idea muy clara de lo que entiende por entorno de cloud computing. Luego veremos los retos de seguridad en entornos cloud. También veremos ventajas que tenemos en ese tipo de entornos para protegernos de ese conjunto de amenazas. Más adelante, nos centraremos en ver un panorama amplio sobre temas criptográficos que pueden permitir nuevas vías de uso en entornos cloud o facilitar

la adopción de ese tipo de recursos por las empresas, sobre todo cuando se trata con datos críticos, datos sensibles. Y, por último, hablaremos de una solución particular al problema o al escenario de gestión de identidad en la nube.

Supongo que todos estaréis familiarizados con lo que es el cloud computing. Hay múltiples definiciones sobre lo que es el cloud, cada una tiene un sesgo más relacionado con el escenario de uso pero sí que es verdad que si tenemos que elegir una definición estándar que está aceptada a nivel global, la candidata sería la que hace el NIST, el Instituto de Estándares de Estados Unidos, que establece un conjunto




de características básicas mínimas que debe tener un entorno cloud. Entre ellas estaría el conjunto compartido de recursos, es decir, ya en el cloud no tenemos una máquina dedicada para tu aplicación o para tus servicios, sino que tenemos una máquina física que comparte diferentes recursos y diferentes servicios. Tenemos una elasticidad, una escalabilidad, una gestión bajo demanda de recursos. Y, aparte de esas características esenciales, también define lo que son tres modelos de servicios que se delimitarían por el nivel en que se abstraen los recursos de tus aplicaciones; un nivel básico sería la infraestructura como servicio, que esencialmente significa que el cloud te ofrece una infraestructura para poder almacenar y ejecutar tus máquinas virtuales. Aquí lo que se abstrae es la infraestructura, es decir, tú el hardware no lo llegas a ver pero tienes un control hasta el sistema operativo, puedes instalar lo que quieras dentro de esas máquinas. En el entorno con más control, cuanto más control tienes en el cloud, más responsabilidad. Si trabajas en un entorno IAS, tú instalas tu máquina, eres responsable del sistema operativo, de tus licencias, de tus actualizaciones, de tus parches, etc. Cualquier tipo de problema, en cualquier sistema de tu sistema operativo, en cualquier librería, es tu responsabilidad.

Tenemos un nivel intermedio que sería la plataforma como servicio donde ya el cloud no es un PC virtual donde pones tu máquina virtual, sino que es tu entorno de desarrollo donde pones tu código. Así, por ejemplo, en entornos Java tienes un motor, un servidor de aplicaciones Tomcat y tú pones tus aplicaciones Java. Entonces, solo te preocupas de tu código Java y todo lo que hay

debajo es responsabilidad del proveedor de cloud: los parches del sistema operativo los gestiona el proveedor, así como los parches de la máquina virtual de Java… Es su responsabilidad, no la tuya. Te quitas un problema de encima pero también tienes menos control porque no ves lo que hay debajo.

Y luego estaría un nivel más alto de abstracción que sería el software como servicio. Aquí, realmente, el proveedor de cloud te da un servicio directamente como un correo electrónico, edición de documentos… No ves nada de lo que hay debajo, solo el servicio que tiene también estas características: un servicio que está ejecutado sobre un entorno compartido, que también es elástico y bajo demanda.

Aparte de los modelos de servicio, también define el NIST cuatro modelos de despliegue según el uso que se le da a esa infraestructura de cloud, según quién es el usuario. Tendríamos lo que sería un cloud público, es decir, al que todo el mundo tiene acceso a contratar los servicios de cloud. Cuando hablamos de público no quiere decir que sea gratuito, sino que es accesible para todo el mundo. Sería, por ejemplo, Amazon, Azure o cualquier producto como. Luego están los cloud privados, que son una extensión de los CPDs tradicionales. Es decir, es como si yo cojo mi centro de datos y lo convierto en un pequeño cloud. ¿Qué pasa en los cloud privados? Pues solamente la empresa que los crea tiene acceso a ese cloud. No se hace una venta de recursos hacia fuera, son entornos privativos. También están los cloud híbridos donde lo que hacen es combinar cloud públicos con cloud privados. Y




luego, además, están lo que denominan como clouds comunitarios que es un cloud privado pero que lo comparten diferentes organizaciones con un mismo interés. Por ejemplo, un cloud estatal donde todas las administraciones públicas tienen acceso pero un cliente particular no podría acceder.

Una distinción importante que tendríamos que hacer dentro de los entornos cloud sería: qué es un cliente de cloud y qué es un usuario en entorno cloud. En los entornos de cloud computing tenemos diferenciados claramente lo que es el proveedor de cloud, que es aquel que tiene la infraestructura donde se ejecutan esos entornos bajo demanda, elásticos y que se proporcionan a través de Internet y, luego, estaría el cliente, que tiene un contrato directo con ese proveedor de cloud, que contrata los servicios, que almacena sus aplicaciones, sus datos, dentro del proveedor de cloud. Pero, aparte, surgen otro tipo de usuarios que son los usuarios finales que consumen esas aplicaciones. Un ejemplo simple: si pensamos en Dropbox (supongo que todo el mundo conoce cómo funciona Dropbox), es un cliente de Amazon porque Dropbox contrata el almacenamiento en el cloud de Amazon pero los usuarios de Dropbox no son clientes de Amazon, son clientes de un cliente. Esto que parece que no tiene sentido es muy importante en el tema de la responsabilidad legal. Digamos que el que contrata los servicios en el cloud, el que expone su información en el cloud es el cliente del cloud, no es el usuario. No es responsabilidad del usuario que los datos estén en el cloud o estén en un servidor centralizado; para el usuario es transparente. Entonces el usuario le da

información a esta persona y él decide ponerlo en el cloud por lo que la responsabilidad total es de esta persona. El que decide realmente es el cliente. Él es el que tiene que decidir si su información o la de sus clientes la puede o no subir al cloud.

Vamos a hacer un repaso de unos cuantos retos importantes de la seguridad en el cloud. Yo creo que todos tenemos claro que en entornos virtualizados, en entornos de cloud, uno de los mayores retos sería la seguridad. Hay otros temas que pueden hacer que una empresa se replantee llevar o no su información al cloud pero digamos que el impedimento o el riesgo que más se considera sería la seguridad. Esto es así desde que surgió este tipo de paradigma.

Algunos de los estudios más conocidos y más interesantes sobre los riesgos de la seguridad en el cloud o cómo las empresas se plantean mover o no mover su información, su infraestructura al cloud, son los que ha realizado CSA. No sé si vosotros conocéis la CSA, Cloud Security Alliance. Es una organización sin ánimo de lucro que se encarga de promover buenas prácticas para el uso del cloud. Lo que hicieron, en un estudio inicial en 2010, fue encuestar a miles de empresas a nivel mundial para ver qué era lo que más les impedía a la hora de mover su información a entornos virtualizados, a entornos cloud. Ese estudio que hicieron en 2010, lo revisaron en 2013 y lo que hicieron fue preguntar sobre esas amenazas que ya existían, si seguían siendo relevantes o no, y, también, identificar nuevas amenazas. Este estudio se hizo mayormente con empresas de Estados Unidos pero también




cubrió a otras del resto del mundo. Además, tenía en cuenta tanto a proveedores de cloud, como a clientes y usuarios.

Esto sería, según la CSA, las ‘Notorious Nine’, las nueve amenazas que existen o que las empresas consideran como retos más importantes a la hora de moverse hacia el cloud. Están ordenadas por un criterio de relevancia que hace CSA en ese informe y lo que vemos aquí en las filas, en la pantalla, sería el porcentaje de respuestas en la encuesta que consideran que sigue siendo relevante. Vamos a ver tres de ellas, las más importantes a mi entender. La primera serían las fugas de información. Digamos que el primer riesgo que te puedes encontrar sería ese: yo tengo la información almacenada en mi centro de datos, en un entorno controlado, donde tengo un control de acceso físico y sé quién entra y quién no entra al centro de datos. Lo tengo todo muy controlado pero cuando mi información se va a la nube, ¿qué ocurre? Puede que otras empresas puedan acceder a esa información, está más expuesta. Entonces, el riesgo principal sería ese: mi información se va al cloud por lo que se expone a que cualquier persona pueda acceder a ella, por ejemplo, competidores. Subo una patente al cloud, un proceso que es secreto si lo subo a la nube, ¿quién me dice que no lo va a poder copiar alguien? ¿O que puede, incluso, cooperar con el proveedor de cloud para conseguir esa información? El problema es que, claro, cuando nos movemos a un entorno de cloud esas políticas de control de acceso, esos sistemas de gestión de datos ya no son locales sino que el que se encarga de hacerlos efectivos es el cloud. Tú al cloud le dices cuáles son las políticas y es

el cloud el que se encarga de gestionarlas. Es como cuando gestionamos la seguridad en un entorno físico: tú puedes tener tus guardas de seguridad, que son tus empleados, o subcontratar a un tercero y de ese tercero que subcontrates tendrás que ver su reputación, su historia… para enjuiciar precisamente si puedes fiarte o no de esa persona, porque es la que realmente va a hacer efectivo ese control de acceso a tus edificios. Aquí es lo mismo, tu información ya está en el cloud y te fías del cloud no solamente para que almacene tu información y no la pierda, que sería el siguiente reto, sino para que no se la dé a nadie al que no le has dado permiso. Dentro del asunto de la pérdida de datos, una de las ventajas del proveedor de cloud es que la información que está en el cloud, está replicada, está más accesible y es más difícil que se pierda, ¿no? Tienen una infraestructura mucho mayor y mucho mejor que la mía. Cuanto más se replica la información, más se expone también. Aquí lo que tenemos es una contraposición entre los dos top threats que define CSA: uno sería el de fuga de información y el otro sería el de pérdida de información, que es el segundo más importante. Si yo quiero protegerme ante una posible pérdida de información, replico mucho mis datos, y cuanto más los replique, estarán en más sitios y más expuestos. Entonces, si yo quiero protegerme de una pérdida de datos me estoy debilitando ante la fuga de información y viceversa.

Otro problema inherente de los entornos virtualizados con respecto a las fugas de información es que estamos en un entorno de recursos compartidos. Ya no tenemos un equipo, un PC dedicado, encerrado en una jaula con mi




llave al que solo puedo acceder yo, sino que lo que tenemos es una máquina virtual en un PC físico que no sé dónde está, dónde hay otras máquinas virtuales de otras personas que no sé quiénes son. Se pueden dar circunstancias como ésta que aparece aquí. Es un ejemplo pero hay muchos como éste. Es decir, tengo dos máquinas virtuales coexistiendo en un disco duro: tengo la máquina virtual de la izquierda que empieza a borrar datos y cuando empieza a borrarlos, el gestor de máquinas virtual dice “tú realmente, de la información que te tengo reservada de ese disco duro, de esos 20 Gb, solo necesitas 15, pues te quito 5 y se los doy a otra persona”. Entonces, los datos que estaban dentro de tu disco duro ya no están bajo tu control sino que vuelven otra vez al gestor de máquinas virtuales. ¿Qué ocurre?, que llega una máquina virtual, otro competidor, una empresa que requiere más almacenamiento y empieza a copiar cosas. Entonces, este trozo de información física del dominio de la máquina de la izquierda pasa al dominio de la máquina de la derecha. Tus bits, tu información está ahí y hemos movido información de una máquina virtual a otra de forma inconsciente. No éramos conscientes de que esto pasaba; pero pasa. ¿Por qué? Porque tenemos un pool de recursos compartido: ese disco ya no es de una persona, es de muchas. Entonces, si esos datos no están cifrados, si esos datos cuando los borramos no los sobre-escribimos con ceros, siguen ahí en el disco duro, por lo que cualquiera que recupere ese trozo de información física puede hacer luego un escáner y sacar fotos o documentos que había dentro de ese trozo de disco duro. Este tipo de amenazas en lo que se llama entornos multitenant, es decir un

recurso físico compartido con varias máquinas virtuales, es solo un ejemplo simple pero hay muchos tipos de ejemplos que explotan ese tipo de vulnerabilidades, el que dos máquinas coexistan en el mismo equipo físico. El hardware ahora mismo existente no está preparado para que ese aislamiento sea tan fino.

Otro de los retos que no es específico de entornos cloud, que es algo genérico, es el robo de contraseñas, el robo de cuentas. ¿Qué ocurre?, pues que si te roban tu cuenta de correo, podrán enviar correos en tu nombre; si te roban tu cuenta de iTunes, podrán comprar aplicaciones en tu nombre; si te roban tu cuenta de Amazon, pueden crear máquinas virtuales, pueden montar un ataque distribuido de denegación de servicio en tu nombre… Aquí el problema no es un nuevo tipo de amenaza, la amenaza es la misma solo que el efecto es más devastador. Aquí si alguien te roba tus claves de acceso a entornos virtualizados como Amazon, tiene acceso a crear nuevas máquinas en tu nombre, a borrar tus máquinas, etc., tiene acceso completo. Es como si perdieses la llave de tu CPD. Muchas veces es algo que no entra en la cabeza, al estar acostumbrados a algo físico y controlado; cuando viene el cloud todo se reduce a una contraseña. Si alguien coge mi contraseña entra a toda mi infraestructura de red. Ya no basta con contraseña y usuario, hay que ir a autenticaciones más avanzadas.

Otra amenaza también relevante y que está relacionada con el desconocimiento y la falta de transparencia en los entornos virtualizados son los llamados malicious insiders, o trabajadores maliciosos. Es decir, que cuando voy a un




entorno cloud, confío en Google, en Amazon, etc., confío en la empresa por su nombre, pero que tú confíes en la empresa por sus políticas o por sus normativas no quiere decir que haya alguien dentro, trabajando en esa empresa, que se comporte de forma no honrada. Y esa persona, su comportamiento, no tiene un efecto en la empresa que lo contrata sino en todos los clientes que tienen sus servicios ahí y en los usuarios de esos clientes. ¿Cuál es el problema que tenemos? Que en un entorno cloud hay poca transparencia, es decir, el cliente del cloud conoce ciertas políticas de uso, conoce los SLAs, pero no conoce, por ejemplo, qué tipo de personal hay cuando contratan ese tipo de entornos, no conocen ni siquiera dónde está la información, si está en Estados Unidos, si está en Europa... Se pierde perspectiva.

Otro tipo de amenazas sería el del uso o del abuso de la infraestructura cloud para fines malignos. Es decir, si tengo un entorno cloud, ¿para qué voy a montar una botnet? Compro mis servicios en el cloud y monto ahí mis servidores de explotación. Es decir, no tengo que infectar a nadie, compro lo que me haga falta y lo utilizo. También el cloud se ha convertido en una fuente de amenazas, porque hay gente que hace un uso malicioso de esta infraestructura.

Aquí aparecen una serie de ataques que ha habido en la historia para entornos de infraestructura como servicio que, digamos, es un entorno un poco más extendido y también un poco más susceptible. Puedo comentar, como ejemplos inherentes, los de las imágenes maliciosas; aunque también ha habido ataques como Side

Channel Attacks, que lo que intentaban era explotar esa coexistencia de máquinas virtuales dentro de un mismo equipo físico. Es decir, en teoría, cuando estás en un entorno virtualizado no sabes dónde está tu máquina, no sabes quién está contigo en tu mismo equipo, ¿no? Pues lo que hacían era explotar latencias y algún tipo de ataque sobre patrones de comunicación en red para saber si dos máquinas virtuales estaban o no en el mismo equipo físico. Una vez que lo estaban, explotaban otro tipo de ataques para conseguir información por un canal paralelo.

Otros problemas que hay en entornos virtualizados es que cuando utilizamos criptografía en este tipo de entornos no tenemos acceso a una fuente de entropía pura, es decir, aquí no tenemos acceso directo al hardware, todo va a través del hipervisor. Si tenemos un hardware dedicado para generar números aleatorios, tu máquina virtual no accede al hardware, accede a una capa software que consulta ese hardware, con lo cual ya esa entropía se pierde o se degenera.

El ejemplo de las máquinas virtuales comprometidas, ¿cuál sería? Bueno, pues está basado en dos trabajos realizados en 2009 y 2011, pero es para que tengáis una perspectiva de cómo han evolucionado este tipo de soluciones. Es decir, el modelo de negocio de Amazon te proporciona una infraestructura para ejecutar máquinas virtuales y también te facilita que, en vez de instalar tu máquina virtual desde cero, es decir te bajas tu CD de instalación, lo instalas y lo configuras, te proporcionan ya máquinas listas para que con un clic te funcione la aplicación, para que tengas tu máquina funcionando, una




máquina con Apache, con Tomcat, etc., todo preparado y mucho más rápido. ¿Qué pasa? Que esa facilidad de uso, de decir me cojo la máquina que esté más arriba en la lista (esto es como un market) como el market de Android, me cojo la que está con más estrellitas y esa será la que sea mejor de todas, la más segura y no tengo que preocuparme de tirarme una hora configurando, sino que solamente a través de un clic tengo mi máquina funcionando, mis servicios funcionando. ¿El problema? Pues ellos vieron que entre esas máquinas virtuales que estaban en ese market había máquinas que tenían cosas raras: claves SSH instaladas para que pudieras hacer una sesión remota directamente a esa máquina, había rootkits, caballos de Troya... había cosas que podían hacer que tu negocio se fuera al garete. Y lo peor es que lo que vieron ellos y lo que demostraron en 2009, fue que esas máquinas no eran las que estaban al final del todo. Son capaces de coger una máquina que tenga ese tipo de cosas y ponerla en el top 10, con lo cual, cualquier persona inexperta que entra en Amazon va empezar por elegir una máquina del top 10, que son las mejores y le va a funcionar. Entonces, en ese trabajo lo que hicieron fue colocar en el top 10 máquinas infectadas o comprometidas.

Luego ya, en 2011, tanto ellos como otro grupo europeo de la Universidad de Amsterdan, lo que hicieron fue decir “bueno, ya que sabemos que esas máquinas están ahí, vamos a darles unas herramientas a los usuarios para que, antes de subir y utilizar esa máquina virtual, la puedan analizar en busca de ese tipo de problemas, de posibles amenazas”. Lo que hacían era coger un script que analizaba la presencia de cadenas de

SSH, de certificados, conexiones activas y demás. Y de esos análisis que hicieron en ese momento, en 2011, publicaron también unas estadísticas. Por ejemplo, de todas las máquinas que comprobaron ellos, casi un cuarto tenían ya una clave SSH. Y, además, de todo lo que encontraron era lo que más predominaba.

Luego, este otro equipo hizo algo parecido y también analizó 550 máquinas en el dominio Este Amazon y 550 máquinas en el dominio Oeste. De las máquinas que vieron en cada dominio, observaron que en el Este casi el 50% tenía un SSH y en el Oeste, solamente un 15%. Todo esto lo que viene a evidenciar es que cuando te vas a un entorno cloud, primero están los problemas del cloud y luego están los problemas inherentes del usuario, de la comodidad; y si voy a un entorno nuevo con laxitud, ya empezamos con mal pie, y todo va a ir mal. Cuando empieces piensa que estás en un entorno nuevo, en un entorno desconocido, donde tienes que tener mucha más precaución de la que tenías antes. No vale ir a la ligera.

Los entornos cloud no son solo los más peligrosos, también tienen nuevas funcionalidades y ventajas que permiten hacer un análisis de seguridad más avanzado o pormenorizado. Esto es lo que sería la imagen tradicional de un entorno virtualizado, es decir, tenemos arriba las máquinas virtuales, tenemos el hipervisor que sería la capa de abstracción para que las máquinas virtuales no se preocupen del hardware, que no sepan lo que hay debajo, y el hardware que está justo debajo. Bueno, pues ¿qué es lo que tenemos como nueva herramienta? Tenemos lo que se




llama la introspección. La introspección permite extender esas capacidades del hipervisor, que en principio solo traduce llamadas al disco duro (graba en el disco duro, lee el disco duro... lo traduce a una llamada física al disco en particular), y lo podemos extender para monitorizar los accesos de las máquinas virtuales, fuera de lo que es el sistema operativo. Y además, estándar para cualquier tipo de sistema operativo, como Windows, Linux, OS X... Da igual, ya que lo hace fuera del entorno del sistema operativo. Entonces, podemos monitorizar, por ejemplo, el acceso a memoria, el control de ejecución del programa, el acceso a datos dentro de los dispositivos de almacenamiento, el control de tráfico, etc., todo fuera de lo que es la máquina virtual, sin tener que instalar nada específico dentro de cada máquina virtual. No tenemos que depender de que el usuario lo haga bien, sino que nuestro hipervisor puede hacer un análisis a nivel global, holístico, de todo lo que es la infraestructura de cloud. Este hipervisor es un programa que está por encima de la máquina virtual, con lo cual, ve todo lo que están haciendo y puede detectarlo todo. Puede detectar los rootkits, porque no se va a engañar por el sistema operativo, no lo conoce, él ve una caja negra en cada máquina virtual. Entonces cada vez que vea llamadas sospechosas, las puede detectar y reportar algún tipo de amenaza o ataque. Pero tampoco es el Santo Grial. El asunto del hipervisor lo puedo complicar todo lo que yo quiera; pero cuanto más complico mi hipervisor, mi calidad de servicio va a disminuir, con lo que mi rendimiento va a bajar. Y no solo eso, sino que si el hipervisor es muy grande, muy complejo, es más propenso a errores: cuanto más grande

es la dimensión de tu software, más fácil es que tengas algún tipo de amenaza o de problema de seguridad. De hecho, la evolución en entornos de cloud ha sido buscar los micro kernels, cuanto más eficientes y más pequeño mejor, porque lo que buscas es minimizar el footprint del hipervisor. Si quieres ir a por la seguridad tienes que hacer justo lo contrario. Hay que buscar un balance entre los dos extremos.

¿Qué es lo que nos puede permitir el hipervisor? Bueno, pues lo que he comentado antes, puede hacer un control de malware, un control de detección de intrusiones a un nivel mucho más fino sin que, además, tenga que instalar nada específico en las máquinas virtuales, lo ve todo desde fuera. También, puede evitar el acceso a información privilegiada dentro de su disco duro físico, puedes bloquear ciertas porciones del disco duro para que no se pueda acceder a ellas nunca. También puede hacer un cortafuegos entre máquinas virtuales, tanto a nivel de red como a nivel de memoria. Puede permitir un aislamiento mucho más fino entre las máquinas virtuales. Y luego, en lo que toca al análisis forense, si hay algún tipo de amenaza y tienes un registro exhaustivo de todas las acciones a nivel de hipervisor, es mucho más fácil tirar para atrás y ver cuál fue la fuente de la amenaza.

Otro beneficio de la introspección sería, por ejemplo, en este caso: pensad cómo funciona un antivirus. Tú tienes un antivirus, lo programas y a tal hora hace un escaneo. Pensad que tenemos una máquina física con diez máquinas virtuales y todas con el mismo antivirus programado a la misma hora. Cuando llegue esa hora, la




máquina explota porque tiene diez maquinas virtuales explorando el disco duro al completo y a la vez. ¿Qué es lo que también permite el hipervisor? Bueno, pues en vez de hacer un escaneo por huellas de virus desde cada máquina virtual, lo hago desde el hipervisor: busco una máquina que tenga un acceso holístico a todo el almacenamiento físico que hay debajo de cada máquina virtual y desde una sola máquina escaneo todo el disco duro completo, con lo que también mejoro la eficiencia de los procesos tradicionales de seguridad en una infraestructura.

Todo esto no es suficiente; está claro: el cloud tiene sus riesgos, tiene sus ventajas y nosotros creemos que una de las soluciones que puede crear más ventajas en el cloud sería la criptografía; no la criptografía tradicional que tenemos ahora mismo en el cloud, sino una criptografía más especializada. Éste sería el esquema tradicional de cifrado en la nube. Cuando uno contrata un servicio y te dice que su información está cifrada en la nube esto es lo que ocurre: yo tengo mis datos, yo subo los datos (me da una API de acceso remoto para subir mis datos) y mi proveedor de cloud genera una clave maestra con la que cifra los datos. Pero él antes ya ha visto mis datos en claro. Yo los he enviado a través de la red y él los ha visto. Cifra los datos, los guarda cifrados dentro de su base de datos de información cifrada y también guarda su clave de cifrado en una zona más protegida de la infraestructura. Esto le da la seguridad al usuario de que si alguien ataca, este almacenamiento estará replicado (esto, a lo mejor, está replicado en todas sus zonas geográficas), por lo que si hay un ataque a este almacenamiento, no accede a tu información

porque le hace falta la clave de cifrado. Pero la clave de cifrado también está en entornos virtualizados, es decir, si alguien realmente hace un ataque más potente al final sacan tus claves, porque están también en la nube. Aparte, en algún momento, el proveedor de cloud recibió la información en claro por lo que en alguna caché se almacenó esa información, está ahí y si alguien compromete esta infraestructura y monta algún tipo de malware, ese malware va a ver tus datos. Por lo que no es una seguridad garantizada cien por cien. El usuario tiene que asumir también ciertos riesgos. Por ejemplo, este es el modelo que utiliza Dropbox. Cuando subimos a Dropbox nuestros datos, Dropbox contrata con Amazon, o con otro proveedor, el que sea, un cifrado; pero realmente las claves no las gestiona Dropbox, las gestiona el proveedor de cloud, que tiene control sobre los datos y sobre las claves.

¿Solución a este primer problema? Permitir que el cliente pueda cifrar sus datos antes de subirlos a la nube. Aquí tendríamos soluciones, por ejemplo, como TrueCrypt... Bueno, ha habido cierta controversia con TrueCrypt, que ahora parece que lo van a abandonar y demás, ¿no? Pero hay servicios comerciales análogos a Dropbox que permiten que cifres los datos en local en el PC y luego los subas a la nube. ¿Qué ocurre cuando subimos a la nube esa información cifrada? Que a cualquier cliente que quiera acceder a esa información le falta la clave. En Dropbox ahora mismo eso es muy fácil, tú subes tus datos, te los llevas a cualquier parte del mundo y accedes a tus datos. Si has cifrado los datos en tú máquina, o recuerdas la contraseña o no puedes acceder a esa información, por lo que tiene sus ventajas y




sus inconvenientes. Hay también soluciones de compromiso que lo que hacen es utilizar múltiples clouds. Es decir, tengo un cloud más seguro en el que almaceno las claves de cifrado solamente, un cloud muy seguro, muy resistente, muy caro. Y luego, un cloud más barato, menos seguro o menos confiable donde almaceno la información cifrada. Entonces, desde cualquier ubicación tengo acceso a mis claves que están en el cloud también y tengo acceso a mis datos con un ancho de banda muy grande.

Esto sería una solución a un problema tradicional: cifrar la información cuando está descansando en el cloud; pero hay otras funcionalidades que también se pueden conseguir en entornos virtualizados con ayuda de este tipo de esquemas criptográficos, que serían: Searchable Encryption, Homomorphic Encryption y Proxy Re-encription. No sé si a algunos de vosotros os suena Searchable Encryption... ¿a alguno? ¿no? ¿Y cifrado homomórfico? A alguno por ahí, también. ¿Y recifrado proxy? Bueno, pues veremos un poco por encima en qué consiste cada cosa pero en esencia, Searchable Encryption permite que tu información la guarde cifrada en la nube, tu base de datos esté cifrada en la nube y puedas hacer consultas sobre tu base de datos sin que el proveedor de cloud descifre los datos. Es decir, tú le mandas una query, él la ejecuta sin descifrar los datos y te devuelve el conjunto de respuestas sin saber lo que te está devolviendo. Solo el cliente, cuando le llega el conjunto de respuestas cifrado, descifra y ve los datos. El cifrado homomórfico lo que hace es “no solamente voy a hacer búsquedas, quiero realizar un procesamiento arbitrario sobre datos en la

nube”, como operaciones de cifrado, de sumas, multiplicaciones... ejecutar fórmulas en la nube sin que el proveedor de cloud tenga acceso a la fórmula, ni a los datos de entrada, ni a los datos de ejecución. Y luego estaría el recifrado proxy, que lo que hace es que tengo un cifrado con una clave y lo cambio a otra clave. Vamos a ver todo esto con más de detalle.

Éste sería el sistema genérico del cifrado con búsquedas, Searchable Encryption, que lo que hace es basarse en el uso de unos tokens que genera el dueño de los datos para que las personas que hagan las consultas, junto con ese token, mande su consulta. Hay sistemas simétricos o asimétricos y según la respuesta a ese tipo de preguntas se hará un esquema más adecuado u otro para tu solución. Digamos que serán estos cinco parámetros los que determinan qué solución utilizar o no. Por ejemplo, quién es el dueño de los datos, quién puede actualizar los datos en esa base de datos, quién puede incluir datos nuevos, quién puede hacer la consulta... pues por ejemplo, si el que incluye los datos y el que hace la consulta son personas diferentes, un esquema simétrico es más complicado porque la clave es la misma en las dos direcciones. Entonces, un esquema asimétrico te ayudaría a que alguien suba los datos y otra persona acceda a la información, a las consultas. También, según quién genera el índice y cómo se actualiza, según si puedo permitir revocación de esos token, es decir, si yo te doy acceso a una consulta, te mando tu token para hacer una consulta, pero si mañana no quiero que hagas la consulta, ¿cómo lo resuelvo? También, según el tipo de consultas: puedo hacer consultas muy simples




del tipo “búscame esta palabra”, “búscame estas palabras”, “búscame todas estas palabras” o “búscame algo que esté en este rango”... cuanto más compleja es la consulta, más complejo es el esquema y menos eficiente es, pero hay soluciones para todas estas cosas. Y también algo un poco más específico, es decir, ¿cómo se ha demostrado la seguridad de ese modelo? Pues aquí hay diferentes suposiciones de seguridad. Según el tipo de modelo que utilicemos para demostrar la seguridad, será un modelo más o menos robusto. Una cosa importante cuando inicialmente se definieron este tipo de esquemas, no se centraron tanto en una consulta en una base de datos que recupere la información, sino simplemente en saber: ¿en esa base de datos hay alguna entrada para este keyword? O sea, el primer problema que se resolvió fue saber cuántos kits había, es decir, cuántos documentos hay con este keyword. Pero conseguir los datos fue una cosa posterior. Esto ha ido evolucionando y sigue en evolución y cada vez habrá esquemas más eficientes y con más funcionalidad. El problema es que todavía no hay nada, ningún servicio en el cloud que utilice este tipo de cosas. Tenemos todavía una brecha entre lo que es el producto comercial y lo que es el desarrollo académico. Veis además que son esquemas antiguos, del 2007, es decir, no es una cosa que se haya inventado ayer.

Luego estaría el cifrado homomórfico, un área cuyo desarrollo va también lento, porque los esquemas de cifrado homomórfico no son eficientes, no son viables a gran escala. Hay alternativas, como por ejemplo lo que se define como el cifrado ‘casi-homomórfico’, que son más viables. También hay

alternativas que resuelven un problema similar pero en entornos más específicos. Lo que hace es un procesamiento parcial, un procesamiento muy específico de la información en la nube. Por ejemplo, dos cosas que podrían ser relevantes son, en primer lugar, el Private Set Intersection, que lo que hace es lo siguiente: “tengo dos personas, dos usuarios que quieren colaborar y quieren conseguir encontrar los puntos en común”, es decir, tienen dos conjuntos de datos y quieren saber los datos en común. Un ejemplo en las redes sociales, por ejemplo, una web de citas: tengo mis hobbies y quiero que alguien ponga sus hobbies pero yo solo quiero que vea mis hobbies quien tenga algo en común conmigo, es decir, yo solamente quiero desvelarle a la otra persona lo que tenemos en común, lo demás no lo va a ver. Pues hay esquemas para eso. Entonces, de forma privada hay un protocolo en el que esas personas consiguen saber que tienen algo en común pero sin que lo que no sea en común lo puedan ver, ni el uno ni el otro.

En segundo lugar, estaría el Secure Multiparty Computation, es decir, en vez de utilizar un esquema criptográfico muy pesado, que no es eficiente, para hacer un procesamiento arbitrario de la información lo que hago es que reparto procesamiento entre varios elementos de forma que, si entre ellos no colaboran, no tienes acceso ni a los parámetros de entrada, ni a las fórmulas. Se hace un proceso distribuido por etapas. Y aquí sí que hay soluciones comerciales.

Ya por último, estaría el recifrado proxy que es la base de nuestras dos propuestas que veremos en las siguientes transparencias, y lo que hace es eso que he comentado antes, es decir, tengo dos




usuarios, Alice y Bob, tengo una entidad especial que es el proxy, que representa la tercera parte, y tengo tres elementos que serían un mensaje cifrado con la clave de ‘A’, un token de recifrado, que permite convertir un mensaje cifrado con la clave de ‘A’ a un mensaje cifrado con la clave de ‘B’. Este tipo de soluciones tiene varias variantes que serían, pues, si quiero que ese token funcione en las dos direcciones, es decir, si Alice consigue cambiar su cifrado con su clave, con la clave de ‘B’, ¿Bob puede hacer lo mismo con el mismo token o requiere uno nuevo diferente? Hay esquemas que son unidireccionales, es decir, que solo funcionan en una dirección, y esquemas que son bidireccionales donde este token pues si tengo el token de ‘A’ hacia ‘B’, el token inverso da la vuelta, vuelve hacia atrás. Y muchas veces es importante que sean únicamente esquemas unidireccionales. Otro problema sería cuántas veces puedo hacer esta operación de recifrado, es decir, ¿es solamente un salto? Una vez que yo re-cifro de Alice a Bob, ¿esto lo puedo volver a re-cifrar o no? Pues también hay esquemas que son de un único salto o de múltiples saltos, según el tipo de expansión que le queramos dar a la información. Luego también los hay que son más o menos seguros. Por ejemplo, si Alice y este proxy se ponen de acuerdo pueden sacar la clave privada de Bob, o esquemas en los que si Bob y el proxy se ponen de acuerdo, pueden sacar la clave privada de ‘A’, de Alice. Por lo que hay que buscar esquemas que se hagan resistentes a la cooperación entre las partes.

Un esquema de recifrado proxy, entre sus usos tradicionales, puede servir por ejemplo para delegación segura de correo electrónico. Pensemos que tenemos una empresa y tenemos

una persona responsable de un área de negocio. Los correos le llegan cifrados a esa persona y esa persona está de vacaciones y quiere redirigir su correo a otra persona, a un tercero, pero no quiere dar su clave de cifrado entonces ¿qué es lo que hace? Pues crea un token de recifrado por lo que cuando un correo llega a esa persona se re-cifra para la otra persona y en ningún momento se ha descifrado el correo, ni se ha desvelado la clave cifrada del usuario. Con lo cual, yo puedo delegar mi correo en otra persona, delegar mis tareas en otra persona, el correo nunca se descifra, en ningún momento está en claro, y consigo una seguridad extremo a extremo. También se puede utilizar, no para un entorno de delegación voluntaria, sino para delegación que tenga que ver con inspección de correo por entidades estatales, en donde, si quieren inspeccionar el correo, en lugar de pedirte que me des tu clave de descifrado, te pido un token de recifrado y tú me recifras ciertos datos, por lo que no estás dándome la clave de cifrado. Otro uso sería el acceso delegado de la información, es decir, si yo tengo mis datos de acceso cifrados en el cloud, yo pongo mis datos en el cloud, los cifro en el cloud con mi clave pública (los cifro para mí), y quiero dar acceso a un tercero y, ¿qué es lo que hago? Pues lo re-cifro con su clave: le doy el token de recifrado a la nube y la nube se encarga de re-cifrarlo para el tercero, pero en ningún momento la nube sabe mi clave privada. Y tiene muchos más usos. Aquí os señalo un ejemplo típico dentro del tema del DRM (Digital Rights Mamagement)... lo que cuento es un problema que tuvo la plataforma iTunes de Apple, donde ellos tienen toda la música cifrada en la nube y cuando tu compras una canción, se descarga en tu equipo, va con una clave




cifrada, se descifra y se cifra para tu dispositivo. Entonces, en algún momento, en tu PC, se descifra la información, está en claro durante unos segundos y se vuelve a cifrar para tu dispositivo. Pues con un esquema de proxy eso no sucedería. Y lo que ha pasado es que ha habido ataques a esa plataforma que lo que han hecho es quitar el DRM. ¿Y cómo lo hacen? En ese proceso de descifrado y recifrado capturan la información de la memoria o del almacenamiento temporal del disco duro y sacan la información sin DRM. Y si utilizáramos proxy eso no ocurriría.

Aquí, simplemente, hay unos esquemas de referencia para que veáis que no es algo nuevo. Empezó en 1998 y en 2007 ya había esquemas bastante avanzados.

Paso ahora a nuestra propuesta para la gestión de identidad en la nube. Aquí, realmente, los datos que querríamos proteger son los atributos de nuestros usuarios en nuestro sistema.

El término de Identidad como Servicio lo acuñó CSA (ya hablamos de CSA antes con el tema de los retos en seguridad), como una gestión en la nube de tu identidad. Es como si montáramos nuestro active directory en la nube. ¿Qué riesgos tiene? Pues que tus credenciales, tus políticas, todo está en la nube. Lo controla un tercero que además controla la identidad de otras muchas empresas. O sea, sus intereses van a ser contrapuestos, por lo que hay que proteger la información antes de que salga. Aquí de lo que habla es de que cuando utilizamos un proveedor de identidad en la nube, que todavía es un servicio que está empezando, tienes que confiar plenamente en

ese servidor porque ese proveedor de cloud puede hacer cualquier cosa dentro de tu sistema: puede cambiar las credenciales, puede cambiar los atributos de tus usuarios, en general, puede degradar la calidad de servicio de tu sistema.

Éste sería el esquema que nosotros vemos de descomposición de roles de un entorno de proveedor de identidad en el cloud, donde tenemos tres roles diferenciados. Uno sería el almacenamiento en sí de los atributos del usuario, es decir, las cuentas de usuario, pues almacenar sus atributos, sus nombres, sus políticas... Es solamente un almacenamiento y para el problema del almacenamiento ya hay soluciones, por lo que es algo que ya no tendríamos que tener en cuenta. También, estaría el protocolo en sí de gestión de identidades, es decir, cómo me comunico con los usuarios y con los proveedores de servicios para intercambiar la información de atributos de mis usuarios. En este sentido, hay múltiples protocolos de gestión de identidad y son independientes de los datos. Y luego estaría la parte de protección de estos datos que sería cómo esa información que se almacena se protege, se cifra y se procesa antes de comunicarla al resto de elementos de la infraestructura.

Estos roles también se replican en los otros elementos de la infraestructura. Uno sería el proveedor de servicio que tiene también un rol de protocolo de gestión de identidades, es decir, tiene que saber pedir atributos, saber comunicarse con el proveedor de identidad y ser capaz de acceder a la información que se intercambie de forma segura.




Y este sería el esquema que queremos seguir. Es decir, tenemos un usuario, una organización, que tiene unos atributos de sus usuarios y cuando sube la información hacia el proveedor de identidad en la nube lo que hace es que antes de subir los datos de los usuarios los cifra, los protege, de forma que cuando llegue al cloud están cifrados. El proveedor de cloud no ve los datos. ¿Qué ocurre? Cuando el proveedor de identidad le pregunta por los atributos de un usuario tiene que, en algún momento, descifrar esos datos. Entonces, ¿qué hacemos? En vez de descifrarlos en el cloud, los desciframos en el proveedor de servicios de forma que, dentro del cloud, tanto en la entrada como en la salida de datos, en ningún momento en el proveedor de cloud que es la zona menos confiable tendría acceso a los datos de tus usuarios. Esto no obliga a implementar esta capa de protección de datos en tres niveles. Tanto a nivel de usuario, administración, que sube la información cifrada que tiene que poder cifrarla antes de subirla al proveedor de cloud. Aquí hay un proceso de recifrado que ya os lo adelanto pero que veremos más tarde. Y luego, el proveedor de servicios tendría que ser capaz de descifrar esa información que recibe, esos atributos, para poder usarlos y dar un servicio al usuario.

Tenemos dos aproximaciones, una utilizando OpenID, que sería donde realmente es el usuario el que se encarga de gestionar su propia información. El usuario habla con el proveedor de identidad, cifra sus datos y los sube al proveedor de cloud, de identidad. Este [en la pantalla] sería el esquema genérico: lo que se busca aquí es que tengo el usuario, tengo una clave pública y una

privada del usuario, tengo una clave pública y una privada de los proveedores de servicio y el proveedor de identidad no tiene clave pública, ni privada, sino que va a hacer un proceso de recifrado. ¿Cómo funciona el esquema? Cuando el usuario quiere registrarse en el proveedor de cloud sube sus atributos cifrados con su clave pública y como los ha cifrado con su clave pública, solo él es capaz de descifrarlos. Ahí el proveedor de cloud no tiene acceso a esos datos del usuario. Una vez que los sube al proveedor de cloud se almacenan cifrados y cuando el usuario quiera acceder a un recurso, acceder a un proveedor de servicios, le pasa al proveedor de identidad un token de recifrado. Es decir, le permite al proveedor de identidad que, mediante el proceso de recifrado, cambie el cifrado con la clave pública del usuario al cifrado con la clave pública del proveedor de servicios. En este momento, cuando el proveedor de cloud ha recifrado los datos sigue sin ver nada pero le puede pasar al proveedor de servicios los datos cifrados con la clave pública. El proveedor de servicios, con su clave privada, lo descifra antes de consumirlo en la aplicación y ya en su aplicación aparecen los datos descifrados. Entonces, la ventaja que hemos conseguido es que un atributo fluya entre el usuario y el proveedor de servicios sin que el proveedor de identidad, que es el intermediario, acceda a la información. Además, como le hemos dado este token de recifrado que lo puede almacenar localmente este proveedor de cloud, yo no tengo que estar activo en este intercambio de atributos, es decir, una vez que he pasado este token de recifrado, si el proveedor de servicios requiere más atributos nuevos, más datos míos, se los pide




al proveedor de cloud y él los re-cifra sin que yo tenga que estar implicado directamente.

Este sería el protocolo original de OpenID en el que el acceso al proveedor de servicios se redirecciona hacia el IDP, el usuario se autentica en el IDP y cuando ya lo ha hecho, vuelve otra vez a redireccionar hacia el proveedor de servicios junto con los atributos del usuario. Lo que hemos hecho ha sido implementar estos cambios, adaptar ese flujo, para que en este paso el proveedor de identidad re-cifra los datos que ha recibido del usuario. Y en este paso, el proveedor de servicios, antes de acceder a los datos los re-cifra también. Además, también analizamos la sobrecarga y vimos que realmente no es significativo, es decir, no es una cosa que haga que el proveedor de cloud se sobrecargue.

Una de las principales limitaciones o críticas a este esquema es que, como es el usuario el que se encarga de subir esos datos, cuando esos datos los recibe el proveedor de servicios, se los podían dar directamente también en la comunicación, es decir, digamos que aquí, como esto realmente lo dice el usuario, no está certificado por nadie, o no está verificado por nadie, pues es igual que se lo pase a través de un tercero, que directamente se lo comunique. En principio, esta podría ser una de las críticas. Lo que hicimos también fue meter esta misma idea en un proceso en el que ya no es el usuario el que sube esos datos al cloud sino que es una organización, es la empresa, la que los sube. Y mejor que utilizar un esquema de transporte como OpenID, que es más user centric, usamos un esquema más orientado a entornos corporativos que sería con SAML. Aquí la idea es la

misma, es decir, tenemos una empresa que tiene todos sus empleados, tiene una clave pública y una clave privada. Tenemos a los proveedores de servicios también con su clave pública y su clave privada. Y lo que hace la empresa es que, antes de subir su directorio al cloud, lo cifra todo con su clave pública, de forma que cuando el directorio se sube aquí está cifrado con la clave pública de la organización. Luego se re-cifra y llega al proveedor de servicios.

Este sería el esquema tradicional de federación de identidad donde tendríamos una relación directa entre el proveedor de servicios y la organización que gestiona las identidades, que es tanto la organización del usuario como el proveedor de identidad (tiene un doble rol). Y aquí [en esta transparencia] sería donde ya separamos lo que es el proveedor de servicios y tenemos dos partes, el rol del proveedor de identidad que estaría en el cloud y la empresa que estaría separada. Aquí se complican un poco las relaciones de confianza entre los elementos pero lo que conseguimos es, igual que antes, que el flujo de información que va desde el host organization hasta el service provider lo gestione el proveedor de identidad sin que acceda nunca a la información sobre mis usuarios, ya que los usuarios son de la empresa, no son del cloud.

Este sería el esquema de SAML tradicional de autenticación pero metiendo las modificaciones del recifrado. Sería un punto más complejo, tenemos una identidad más que sería el host organization pero en definitiva es lo mismo, es decir, hay una comunicación en la que el proveedor de servicios redirecciona a los usuarios




hacia el proveedor de identidad. El proveedor de identidad redirecciona hacia el host organization, es decir, mi usuario se autentica en mi empresa, no se autentica en el cloud y, una vez que se ha autenticado, se devuelve el token de recifrado hacia el proveedor de identidad en el cloud. Con ese token de recifrado, él ya puede enviarle la información cifrada al proveedor de servicios con una clave que reconoce. Aquí, en este punto, el proveedor de servicios recibe la clave, los datos cifrados con su clave pública, los descifra y le da un servicio al usuario. Hicimos aquí también un estudio sobre el rendimiento de la solución y vimos que monetizando el coste de la sobrecarga del proxy para una empresa que tenía en torno a un millón peticiones de gestión de identidad, un millón de recifrados diarios, en un año, supondría un coste de unos 2.000 euros. Por lo que realmente, esa sobrecarga de ese procesamiento extra en el cloud, en tiempo de cálculo, en energía (basado en unas estimaciones de otros autores), suponía para una empresa que tuviera un millón al día de peticiones de recifrado, 2.000 euros al año. Tampoco es un coste extra significativo y lo que permite es que, por un lado, el proveedor de identidad en el cloud no puede ver los datos pero no solo eso, también es una ventaja para él porque si no ve los datos, si alguien entra en su infraestructura y roba sus datos no es responsable de esa información. Es decir, aquí también ganamos en una parte legal: el proveedor de identidad. Su negocio está mucho más separado y solo se encarga de hacer de intermediario entre dos partes. Si alguien roba esos datos, no va a acceder a la información del host organization con lo cual no va a ser responsable legal de ese tipo de información.

Turno de preguntas.

¿Cómo ves esto último relacionado con unas siglas que te pueden ser muy familiares UMA, User Management Access, para mayor dominio de datos?

En teoría el primer uso inicial del proxy era justo eso. Era conseguir que la persona que se encarga de almacenar la información no tenga que saber qué datos son los que está almacenando, ni quién es el receptor de la información. Entonces, lo que se busca en este esquema es que tú puedes elegir hacia quién remites ese token de recifrado, a quién le puedes dar visibilidad a la información. Pero tiene muchas limitaciones. Por ejemplo, esos token de recifrado que tú emites, cómo se revocan, es decir, este dato dáselo a esta persona o todos mis datos con mi clave se los das a esta persona. Y ahora digo, pues ya no quiero que se los des, cómo borro ese token que ya está ahí y lo tiene ya el proveedor. Entonces, realmente se mejora un poco la gestión del almacenamiento de la información y cómo se distribuye, pero tiene sus limitaciones y una de ellas es la revocación, que es un problema en este tipo de esquemas.

¿Estáis trabajando con Kantara Initiative?

En principio la idea ha sido tocar solo dos líneas, es decir, integrarlo en OpenID, integrarlo en SAML, pero la idea no es buscar una solución que funcione para todos los esquemas de gestión de identidad, ni que sea tan extensible, porque vemos que todavía tiene limitaciones. Tiene problemas por resolver. Es una prueba de concepto para ver que esto es posible, que se puede ir en esa




dirección, pero quizá, los esquemas incluso de recifrado que hay actualmente no son los adecuados todavía para ese tipo de soluciones. Aún hay muchas limitaciones.

Tengo la sensación de que un token de recifrado en el fondo es como una clave privada en todos los sentidos porque el que tiene un token de recifrado que corresponde a su clave pública puede descifrar, ¿es correcto, no?

Sí, sí, efectivamente.

Entonces, la idea es que un proveedor de servicio teóricamente es una persona menos fiable en los esquemas básicos que el gestor de la identidad (ese es el concepto de gestión de la identidad). Sin embargo, tú como usuario o como organización, lo mismo da, en cualquiera de los dos esquemas, tienes que proporcionar un equivalente a una clave privada correspondiente a la clave pública de un proveedor de servicio y, ¿cómo sabes que ese proveedor de servicio es fiable? ¿Cómo sabes, por ejemplo, que no ha sido creado específicamente por el cloud identity provider?

Esos problemas están ahí. Como hemos comentado, si alguien tiene el token de recifrado y la clave privada correspondiente, esa clave pública, si tiene las dos cosas es como si tuviera la clave privada del usuario final. El esquema o diseño sería que hubiera una separación, que es lo que se busca entre el proveedor de identidad y el de servicio. Es decir, el que tiene la clave privada y el que tiene el token. Si trabajan juntos, efectivamente, tienen todos los datos. Es que eso

no entra dentro de nuestra solución. Hay que suponer que en algún momento este proveedor de identidad va a ser confiable también en el sentido en el que no va a buscar ese tipo de ataques. Estamos pensando en la amenaza en el sentido en el que él quiere acceder a los datos, pero muchas veces, el proveedor de identidad... nuestra solución no solo permite que no acceda a los datos, sino también, que no sea responsable legalmente de esa información. Incluso a lo mejor puede que le interese “mira, es que yo no quiero verlo”, y va a hacer lo posible para que él no vea los datos, para que si pasa algo en su infraestructura, él, con un desembolso menor en seguridad, dice “me da igual estar expuesto, si alguien me roba algo aquí no va a sacar nada” (en teoría, ¿no?). También es una ventaja de cara al proveedor de identidad para que su negocio sea un poquito más fácil, más simple. Pero es verdad que tiene sus limitaciones. Como comentabas, si se ponen de acuerdo el proveedor de servicio y el proveedor de identidad, entre ellos pueden sacar todos los datos del usuario, efectivamente. Claro, el usuario tiene que generar en algún momento ese token de recifrado para empresas confiables. La organización que confía en el cloud provider tiene que decir en qué proveedor de servicios confía y para cuál generar un token de recifrado, porque el token lo genera la organización. Entonces, claro, si tú te inventas un proveedor de servicio falso, como comentabas, para sacar toda la información... pues también hay que hacer un poco de investigación, hay que saber en quién confías tanto a nivel de proveedor de identidad, como en quién confías a nivel de proveedor de servicios. Es decir, tú también tienes la decisión.




Esto de por sí no es vulnerable. Si eliges bien en quién generar los token de recifrado, en teoría, debería de ir todo bien.

Mi pregunta está enfocada a la capacidad que tendrían los atacantes de usar tu infraestructura en la nube para realizar ataques. En base a tu experiencia, ¿cómo de común ha sido esto, cuáles han sido las implicaciones legales y cómo se han solucionado estos temas?

Cada vez está más extendido el uso de la infraestructura en el cloud para hacer ataques

maliciosos. Yo creo que está creciendo porque es fácilmente accesible. Sí que es verdad que los proveedores, digamos los grandes proveedores, los que tienen la reputación en el mercado, tipo Amazon, Google... cada vez están haciendo más complicado que alguien lance una máquina por ejemplo, con credenciales robadas, que roben las tarjetas de crédito, que roben las credenciales, eso está mejorando, pero es una tendencia. Cada vez hay más proveedores de cloud, cada vez la oferta es mayor y hay proveedores incluso que aunque les mandes una queja no van a echar abajo las máquinas virtuales. Es difícil hacer algo contra eso.




INNOVACIÓN DISRUPTIVA EN TÉCNICAS DE CIBERCRIMEN

Etay MaorSenior Fraud Prevention Strategist. Trusteer (an IBM company)


Buenos días a todos. Llevo un año y medio trabajando en Trusteer, que es ahora una compañía de IBM. Me uní después de trabajar durante 6 años en RSA, donde

mi último rol fue el de Jefe del Laboratorio de Investigación de Ciberamenazas, por lo que dirigí grupos de ingeniería inversa, pruebas de penetración (penetration testers) e investigaciones sobre seguridad. Mi principal estudio de investigación es el malware; cómo opera y la gente que está detrás de este tipo de ataques. También formo parte del Institute For Counter-Terrorism, se trata del Instituto de Estudios de Seguridad Nacional de Israel del que hablaré un poco más tarde.

El título de la presentación que voy a hacer hoy es ‘Innovación disruptiva en técnicas de cibercrimen’. Esto es lo que dice allí, pero le he añadido ‘y más…’ porque hablaremos de más cosas al final. He elegido este tema porque, en términos de cómo los criminales operan y cómo roban información, se han sucedido una gran cantidad de cambios en los últimos cinco años. El malware sigue operando de la misma manera, sigue utilizando keyloggers, screen scrapers (raspado de pantalla), form grabbers y otras cuantas técnicas que roban los datos con las que los criminales pueden adquirir cuentas bancarias. Pero lo que ha cambiado significativamente en este último año y medio es cómo los criminales protegen su propio




malware, sus propias técnicas. Ellos saben que hay investigadores de seguridad como nosotros, como los diferentes grupos que existen dentro de BBVA, los analizan y los estudian, y ellos quieren proteger sus investigaciones. Así que en esta parte de la charla lo que voy a intentar es demostraros lo fácil que es ser un cibercriminal a día de hoy, lo fácil que es realizar un ataque, robar información y proteger tu inversión. Y al final de la sesión seguramente saldréis de la sala diciendo “estoy en el lado equivocado, debería haber sido un cibercriminal”. Esto último que acabo de decir no es oficial por lo que lo podéis olvidar, pero es básicamente la idea.

Hay un montón de buenas soluciones de seguridad ahí afuera. Voy a empezar diciendo eso, que hay un montón de buenas soluciones, mucha innovación, muchas técnicas interesantes pero cuando pienso en ellas, esta es la clase de imagen que me viene a la mente [pone una imagen en la pantalla]. La razón es que los criminales no se quedan ahí. Ellos realizan una gran cantidad de operaciones de inteligencia. Saben lo que hay detrás y buscan esos pequeños agujeros en las soluciones de seguridad, en las técnicas, en los procedimientos que tenéis en los bancos, y encuentran la manera de llegar hasta ellos. Por lo que, aunque tengan una buena plataforma bancaria de seguridad online ésta no establece comunicación con la información, los acontecimientos y factores de riesgo con tu solución móvil, ni con tu solución de análisis de fraude, ni con tu solución de anti-blanqueo de dinero (anti-money laundering solution), ni con tu call-center… y estos son, exactamente, aquellos agujeros que los criminales buscan, tratan de

manipular y se aprovechan de ellos. Así que esta es la clase de imagen que quiero que tengáis en vuestra cabeza cuando pase a la siguiente parte sobre cómo funcionan los sistemas y, específicamente, cómo los criminales llegan hasta ellos.

En primer lugar, tenemos que sumergirnos en la manera de pensar de los criminales y cuando estos piensan, quieren llegar hasta el dinero, hasta una cuenta bancaria, que es lo que realmente están buscando al final del día. Hay tres capas de seguridad que ellos han que superar para hacerse con el dinero. Aquí tenemos esas tres capas y algunos ejemplos de soluciones de seguridad para cada capa. La primera capa es la externa. Esta capa sería lo que manejan las víctimas en sus ordenadores o, en este caso, en los ordenadores de los investigadores (porque como tenemos que hacer frente a los criminales, tenemos que hacer frente a los investigadores también). En los ordenadores de los usuarios finales lo principal con lo que nos encontramos son los antivirus, en los ordenadores de los investigadores me encontraría con máquinas virtuales (VMs). Y, ¿por qué máquinas virtuales? Porque para mí, como investigador de Trusteer, si encuentro malware financiero nuevo, lo primero que hago es cogerlo e infectar las máquinas virtuales. Y empiezo a estudiar qué es lo que está haciendo con la comunicación, qué es lo que está haciendo con el hardware, qué es lo que está haciendo con el registro… Los criminales saben esto, ¿vale? Esto no es 2008 y no son noticias nuevas para ellos. Ellos saben que esto es lo que hacemos. Así que lo que dicen es “vale, cada vez que mi malware infecte un dispositivo que en realidad sea una máquina




virtual, no quiero que la infecte”. ¿Por qué? Porque el 99% de los usuarios de casa y probablemente el 99% de la gente que hay en esta sala no utiliza máquinas virtuales para acceder a su banco online. Sin embargo, el 99% de los investigadores utilizan máquinas virtuales para analizar este malware. Por lo que si ves un dispositivo que resulta que es una máquina virtual, no la infectes. Y os enseñaré cómo lo hacen. Ellos hacen otros tipos de análisis. No buscan máquinas virtuales, buscan otros elementos que podrían indicar que este no es un ordenador de la víctima, elementos que analizan que este ordenador tiene instalado Microsoft Off ice. Yo, como investigador, no instalo Microsoft Off ice en mi máquina virtual porque ocupa espacio y tarda más tiempo en cargarse, pero los criminales saben que los usuarios finales utilizan Microsoft Word y si no existe Microsoft Word, Outlook, etc., probablemente, esta no es la clase de ordenador que quieres infectar.

Pero digamos que fue capaz de infectar el ordenador y que fue capaz de robar los nombres de usuario y las contraseñas, ahora tendría que enfrentarme al proceso de inicio de sesión (login). En el proceso de inicio de sesión, si intento acceder a la cuenta bancaria me voy a encontrar con múltiples capas de seguridad que me pondrán a prueba a mí, que soy el criminal. ¿Cuáles son esas capas? Bueno, en primer lugar, todo el mundo utiliza el identificador (ID) de dispositivo. Estoy seguro de que BBVA utiliza alguna clase de ID de dispositivo, al menos, todas las instituciones que conozco utilizan un ID de dispositivo porque, como sabemos, no podemos confiar solamente en el número de usuario y en la contraseña, ya que podrían ser robados. Así

que, ahora voy a analizar el dispositivo… He visto a alguien logarse en el banco online de BBVA (era Etay Maor, era yo), y utilizó el nombre de usuario y la contraseña pero no era su ordenador. Etay normalmente se registra desde un ordenador desde Israel con Windows 7 instalado y, por otro lado, vemos que Etay se esta registrando desde otro ordenador en Rusia, con Windows Vista, por lo que deben de ser el nombre de usuario y la contraseña de Etay pero no es el dispositivo de Etay, por lo que no confío en esta conexión así que, mantenlo fuera. Este tipo de solución está por todos los lados pero hay otras soluciones en las que tengo que asegurarme de que sé cómo manejar como atacante, como la autenticación por contraseña de un solo uso basado en SMS (One Time Password SMS, OPT SMS). No sé si es popular en España. Creo que es muy popular. He visto varios ejemplos de ataques contra esto. Si intento logarme el banco me manda un SMS a mi dispositivo móvil (los criminales no tienen mi dispositivo móvil por lo que no pueden cogerla), y entro gracias a la autenticación por contraseña de un solo uso basado en SMS. Y, como criminal, ¿cómo llego a eso? Lo veremos un poco más tarde. Ahora, digamos que lo he conseguido y he robado las credenciales, he sido capaz de pasar la barrera de estas soluciones de aquí [señala la pantalla] y ahora me encuentro dentro de la cuenta bancaria e intento pasar dinero. Pues aquí también hay soluciones que intentarán pillarme, como por ejemplo la detección por comportamiento anómalo. Por lo que puede que sea el nombre de usuario y la contraseña de Etay, puede que sea el ordenador de Etay, pero esta no es la manera en la que se comporta




Etay. Normalmente, se registra, mira su tarjeta de crédito, mira su hipoteca y entonces hace una transacción. Pero en esta ocasión, cuando Etay entra, lo primero que hace es mover 20.000 dólares fuera de la cuenta. Por lo que, aunque era el nombre de usuario y la contraseña de Etay y su ordenador, no confío en este comportamiento y no voy a dejar que la transacción se lleve a cabo. Así que, los criminales tienen que hacer frente a esto también. Y, ¿cómo lo hacen? Lo veremos en un par de minutos.

Volvamos a la primera capa. ¿Capa número uno? Externa. Es la primera que nos encontramos y la primera de las soluciones de seguridad a las que tenemos que hacer frente es el antivirus. No me malinterpretéis. No es malo instalar un antivirus. Nunca me oiréis decir “no instales una solución de seguridad”, solo estate seguro de cuáles son las limitaciones, o cuáles son las debilidades de estas soluciones. Y no tenéis que cogerlo de mí. Me refiero, he recopilado unos titulares como podéis ver [pasan titulares en la pantalla] y creo que el más importante es este [Symantec llama a los antivirus ‘condenados a fallar’ mientras que los gigantes de la seguridad luchan por sobrevivir]. Así que, si ellos lo dicen, ¿quién soy yo para rebatirlo? Los antivirus son buenos para prevenir ataques y virus simples, pero no valen contra el malware financiero avanzado. ¿Por qué? ¿Cómo puede hacer eso el malware? ¿Cómo puede hacer que el antivirus sea tan inefectivo? Bien, hay diferentes soluciones que los criminales utilizan. Una de las más populares son los crypters. Este es un ejemplo de un crypter utilizado por Zeus. Este es el crypter de Zeus. Es una herramienta hecha por criminales para criminales. Podéis

pensar en ello como un anti-antivirus. Y, como podéis ver, este es el interface. Podéis comprarlo en diferentes foros underground. Podéis ver que tiene la pestaña ‘anti’ y tiene ‘anti-OllyDbg’ (OllyDbg es una herramienta de ingeniera inversa que, de hecho, yo uso), ‘anti-SandBoxie’, ‘anti-Virtual Machines’, ‘anti-AVG’, ‘anti-WireShark’ (que es un analizador de comunicaciones), ‘anti-ThreatExpert’, ‘anti-VirtualPC’, etc. Es decir, protege el malware de estas diferentes soluciones de seguridad malas. Como podéis ver, son todas soluciones perimetrales: antivirus, máquinas virtuales y sandboxes. ¿Cómo funciona? Bueno, si os preocupa cómo funciona esto os voy a enseñar ahora una herramienta secreta que utilizo en mi laboratorio para que entendáis cómo funciona. Se llama Youtube y puedes conectarte ahora mismo y ver vídeos que te enseñan cómo usar Zeus Crypter. Lo único que he hecho ha sido coger una captura de pantalla de YouTube y lo que hacen es, en realidad, una prueba de concepto donde te enseñan aquí tienes la suscripción donde necesitas hacer clic aquí, hacer clic allá, rellenar esto, hacer clic aquí y ellos hacen una prueba de concepto: cogen todas las versiones de Zeus (Zeus es un malware financiero. Estoy seguro que estáis familiarizados con su nombre), y lo ejecutan contra un antivirus y puedes ver cómo todos los antivirus pueden detectarlo, lo detectan como un Zeus, como un Zbot, como malware... no importa, todos ellos pueden ser detectados. Entonces, cogen el malware, ejecutan Zeus Crypter sobre él, aparece con una capa protectora alrededor de él y, como podéis ver, lo ejecutan otra vez y todos los antivirus (esto es solo una lista parcial) muestran que no han




detectado ninguna amenaza; todo sale limpio. Es invisible para estas soluciones de seguridad. Este es el tipo de cosas que utilizan. Ahora, como os decía, vamos a pensar como criminales, espero que esto mole como criminal pero seguramente que sois como yo, que sois un poquito perezosos, y no quiero trabajar mucho, por lo que puedes externalizar esta parte. Y aquí está esta página web (no entréis en ella, no os recomiendo que visitéis esta página web), donde podéis ver... creo que la imagen muestra lo que hacen: ellos cogen el malware malo y lo convierten en un ángel, algo indetectable. Esto es algo parecido a lo que hemos visto antes, servicios gestionados: ellos tienen una suscripción, tú les envías el malware y te devuelven un malware protegido. Solo tienes que pagar una pequeña cantidad de dinero. Puedes encontrar esto como una red normal, esto está en Internet y pueden encontrarlo en la red oscura (Darknet), hablamos de la red oscura un poco más tarde; TOR, si estáis familiarizados con The Onion Route, ahí es donde hago la mayoría de mis investigaciones.

Este [en la pantalla] es un servicio profesional de cifrado; es ruso. Como podéis ver, tienes que ser miembro para acceder y tienes que pagar a través de bitcoins, las cuales, permanecen anónimas.

Respecto a la identificación de dispositivos (hemos pasado la primera capa, y ahora nos encontramos la segunda, donde está el ID de dispositivo). ¿Cómo puedo sobrepasar el ID de dispositivo? He robado el nombre de usuario y la contraseña pero cómo puedo convencer al banco de que éste es también el ordenador de mi víctima a través del que he hecho el login. Por

suerte, tenemos amigos en los undergrounds de Rusia que nos ayudan a desarrollar soluciones contra el ID de dispositivo. Aquí va un ejemplo: este es el software de Device Forging. Está en ruso pero se explica bastante por sí solo. Lo que haces es que, después de robar el nombre de usuario y la contraseña, ejecutas esto en tu propio ordenador, en tu ordenador criminal, antes de logarte en BBVA en este caso, y puedes cambiar la apariencia de tu ID de dispositivo: puedes cambiar las ventanas del identificador, cambiar el reproductor multimedia, incluso cambiar tu hardware. Puedes cambiar todo. Después de todo, el ID de dispositivo mira en diferentes parámetros para determinar si realmente es el ID del usuario, por lo que puedes cambiar tus propios parámetros como si fueran los del dispositivo del usuario. Básicamente, enmascaras tu dispositivo para que sea el de tu víctima. Esta es una forma de superar las soluciones de identificación de dispositivos. Hay otras maneras, una de las más populares… Estas fueron muy populares en 2008 y en 2009 y después desaparecieron (os diré en un minuto por qué). Ahora han vuelto. Son VNC y RDP malware: VNC significa Virtual Network Connection y RDP equivale a Remote Desktop Protocol. Se trata de un malware que es capaz de hacerse con el control de un dispositivo. Estos protocolos son utilizados por motivos legítimos, por cierto. Cuando tienes un problema técnico en tu ordenador y llamas al soporte técnico para decir “mi ordenador no funciona”, y te dicen “no toques el ratón, ni el teclado”, y entonces puedes ver cómo el ratón se empieza a mover para hacer lo que tengan que hacer. Pues es exactamente lo mismo. ¿Cómo funcionan este tipo de ataques?




Bien, tú infectas a un usuario con un malware que tiene capacidades RDP o VNC. Este es el criminal, este soy yo, por el momento. Y este es el banco. Ahora te sientas y esperas. Un día, la víctima entra en el banco. Va a la página web de BBVA. Esa persona quiere teclear su nombre de usuario y su contraseña. Lo escribe, entra y en ese momento recibo un mensaje. Mi malware me envía un mensaje, normalmente utilizando el sistema de mensajería instantánea de Jabber. “Etay, la víctima está conectada ahora mismo”. Y ahora, lo que quiero es que la víctima no toque la pantalla. Quiero hacerme con el control de su ordenador. ¿Cómo lo hago? Con una simple manipulación. Hago un HTML injection (inyección HTML), le pongo una pantalla dentro mientras está accediendo. Algo como esto [aparece imagen en la transparencia]. Esta es una captura de pantalla sacada de un ataque real: ‘Por favor, espera, te atenderemos en breves momentos’. Y el contador empieza a contar: dos minutos, un minuto, medio minuto... Esto es muy feo, normalmente, hay cosas más chulas que esto como por ejemplo ‘Lo sentimos, debido a razones de seguridad queremos volver a autenticarte, por favor, espera. De otra manera, nos veremos obligados a suspender la sesión’. Algo que hace que el usuario no toque el ordenador. Perfecto, ahora el usuario está a la espera. Ahora, hago un RDP en su dispositivo... bueno, el ataque no sería exactamente así porque existe otra computadora en medio, pero no importa, para simplificarlo, hago un RDP a su dispositivo y realizo una transacción. Pensad en ello. En primer lugar, esto es fantástico para un criminal. Ni siquiera necesito saber su nombre de usuario, ni su contraseña.

Esa persona ya ha entrado, yo solo tengo que hacerme con el control de su sesión después de la autenticación. Así que, ni siquiera tengo que conocer su nombre de usuario, ni su contraseña. Lo único que tengo que hacer es hacerme con el control de su dispositivo y realizar una transacción. Ahora, pensadlo desde la perspectiva de la identificación de dispositivo: el banco ve este ordenador, no este otro ordenador. Por lo que, en términos de ID de dispositivo, está limpio. Este es el dispositivo que tú esperarías. Así es como hacen las cosas. Estos tipos de malware podríais pensar que son raros. Me refiero a que cuando The Carberp apareció en 2009 querían 50.000 dólares para este módulo. A día de hoy, todo gran malware financiero posee estas capacidades. Aquí podéis ver un servidor de comando y control de un spyware y podéis ver que tiene su RDP (por cierto, aviso, el test virtual de nuestro amigo está también aquí ‘como servicio’, por lo que tú puedes hacer clic sobre él y generar nuevas versiones protegidas de espías). Bueno, tiene RDP. Aquí hay alguien que está vendiendo Zeus con VNC en un foro underground. Aquí está VNC Fox de Citadel, que es otro tipo de descendencia de Zeus. Así que, todo el gran malware financiero tiene esta capacidad de conectar dispositivos controlados. De hecho, os puedo contar que hace dos semanas y media, estaba en Bélgica hablando con el CISO de un gran banco de allí y me contó que implementaron una solución de seguridad (este banco hace negocios business to business por lo que realiza grandes transacciones), dieron a todos sus clientes un dispositivo para conectarte con tu ordenador en la que tienes que meter tu tarjeta bancaria personal para poder




realizar una transacción. Por lo que si tú intentas hacer una transacción y no hay dispositivo y si aunque tengas el dispositivo no introduces la tarjeta, no puedes hacer la transacción. No sé si tenéis este tipo de dispositivo aquí, dispositivos inteligentes... Así que, ¿cómo se enfrentan a esto los criminales? Porque los criminales nunca van a tener este dispositivo. Bueno, a lo mejor pueden robar el dispositivo, pero no tienen la tarjeta bancaria personal. No podían. Lo que hicieron fue infectar a gente con este tipo de malware [señala la pantalla] y esperaron. Después de un mes de esta solución de seguridad, la gente que estaba usándola no la volvió a usar correctamente. Estaban muy molestos por el hecho de tener que poner la tarjeta en el dispositivo y quitarla, etc. Al final, ellos la ponían al principio del día y no la sacaban hasta el final de día y, entonces, lo que hicieron los criminales, que sabían lo que estaba pasando, fue esperar a que los usuarios hicieran un descanso para hacerse con el control del dispositivo con el RDP, y realizar así la transacción. Y es que la tarjeta bancaria estaba metida en el dispositivo porque los usuarios nunca la sacaban. Así que estad siempre atentos con las soluciones de seguridad que conllevan la proactividad del usuario final porque los usuarios... seguro que no sabéis, yo hago esto un montón de veces... cuando hay algo que me molesta, incluso aunque tenga que ver con seguridad, paso de hacerlo de alguna manera para que sea más fácil. Por lo que sed conscientes de ello.

Esto [señala la pantalla] fue muy popular hasta hace poco. Así que lo que los criminales hicieron fue coger malware... lo que los criminales hicieron fue desarrollar algo llamado ATS, Sistemas de

Transferencias Automáticas (Automatic Transfers Systems), lo que es un gran nombre para un script. Lo que hacía este script, una vez que eras infectado con malware con ATS, era esperar hasta que entrabas en tu cuenta bancaria. Una vez que entrabas, el script se hacía con el control por una fracción de segundo, hacía una transacción fuera de la cuenta a otra cuenta, a mi cuenta o a una cuenta para dejar el dinero, y liberaba de nuevo la sesión al usuario. El usuario no lo veía. Tarda menos de un segundo y se ha realizado desde el verdadero ID del dispositivo. Esto fue un gran problema porque consiguieron hacer mucho dinero de esta manera. Así que, ¿qué hicimos la gente de seguridad? Desarrollamos una solución. Dijimos “vale, cada vez que veamos una página web con una transacción rellena en menos de un segundo, no es un humano por lo que, paradla. No vamos a dejar que esa transacción se complete”. Entonces, lo que los criminales hicieron fue esto: añadieron esto a su malware, se llama ‘slow fill’ y añade un intervalo de 200 milisegundos entre cada carácter cuando el malware rellena la transacción. Es decir, rellena la página web de la transacción más despacio para que se parezca a algo humano. ¿Vale? Así que en cada carácter espera 200 milisegundos antes de que el siguiente carácter aparece. Pero no somos tontos como investigadores en seguridad. ¿Sabéis lo que hicimos? Dijimos “perfecto, cada vez que vea 200 milisegundos o, en este caso, cualquier cálculo exacto de intervalo de tiempo entre diferentes caracteres no es un humano porque lo humanos no pueden teclear con la misma exactitud entre caracteres. Así que, cada vez que veas algo como esto, destrúyelo porque son criminales. Y,




¿sabéis lo que hicieron ahora? [Responde una persona del público] ¿Una espera aleatoria? [Responde el ponente] ¡Aleatorios! Bien, ahora estáis pensando como criminales, me gusta. Bien, lo que hicieron fue añadir una función aleatoria aquí de tal manera que está comprendido entre 200 milisegundos y tres segundos, por lo que cada carácter hace una espera diferente. Se trata normalmente del juego del ratón y el gato entre los criminales y los que trabajamos en seguridad. No estoy seguro de quién es el ratón y quién es el gato pero ha sido así durante mucho tiempo. No todos los hackers en sus ataques hacen uso de la tecnología. Algunos de ellos confían puramente en la inteligencia y en entender cómo es una solución de seguridad y la manera de acceder a ella. Nosotros, y cuando digo ‘nosotros’ me refiero al equipo de seguridad y el equipo de innovación de Trusteer, recogemos una gran cantidad de información... Simplemente, he entrado en la sala y he robado el crédito, he recogido una gran cantidad de información de uno de nuestros bancos, uno de los más grandes de Europa. No puedo decirlo, pero es uno de los bancos más grandes de Reino Unido. Recogimos tres semanas de datos de información. Durante esas tres semanas, hubo 1,5 millones de cuentas que accedieron al banco, así que, es un banco bastante grande, donde hubo 10 millones de intentos de iniciar sesión (durante tres semanas). Entonces, empezamos a analizar los datos y encontramos algo interesante. El banco tenía fraude. Los criminales sabían que había un sistema de identificación de dispositivo en sistemas de conducta de perfiles. ¿Cómo sabía que lo sabían? Bueno, ellos realizaron una serie de

comportamientos interesantes. Lo que hicieron fue borrar los nombres de usuario y contraseñas de sus víctimas y utilizaron malware y phishing. Y se registraron en la cuenta desde los dispositivos de los criminales: iniciaron sesión y se salieron de la sesión. Y pasó un día. Entonces, iniciaron sesión y se salieron. Y pasó otro día. Y volvieron a iniciar sesión y salirse. La mente criminal que está aquí sabe lo que está pasando. Después de dos semanas, iniciaron sesión y completaron una transacción. ¿Por qué? Porque después de dos semanas se convirtió ya en un dispositivo de confianza. Si no haces nada supersospechoso en el primer, el segundo, el cuarto, el décimo inicio de sesión eres probablemente otro dispositivo que el usuario utiliza. El sistema lo añade a la lista de dispositivos de confianza y la transacción se hace. De nuevo, no hay tecnología, no existe realmente innovación, pero sigue siendo bastante inteligente por su parte. Normalmente, utilizo esto para bromear con el equipo de innovación. Otra cosa que encontramos en este hackeo del banco fue que los criminales estaban llevando a cabo ataques desde dispositivos móviles, lo que es interesante porque el 30% de los usuarios estaban utilizando dispositivos móviles... Por cierto, ¿cómo es el uso de la movilidad aquí? ¿Grande? ¿Pequeño? Me refiero en términos de banca móvil… ¿Bastante alto? Vale. Bueno, es lo mismo en realidad en todo el mundo, está creciendo en todos los lados aunque hay aún algunos sitios que tienen un 5 o 10%, otros bancos me han dicho que están en el 40% y que van a llegar al 50% en algunas áreas, depende. Así que lo que estaba pasando era que el 30% de los usuarios procedían de dispositivos móviles




pero los criminales también estaban realizando ataques desde dispositivos móviles. Lo que estaban haciendo, una vez más, era manipular la identidad del dispositivo. ¿Cómo lo hacían? Bueno, no sé si lo sabréis, pero en mayo del pasado año Apple anunciaba que si creabas una aplicación, una aplicación basada en IOS que intentase entrar en el iPhone UDID (Unique Device Identifiers), el cual es el ID real del dispositivo, te echarían de la App Store. ¿Por qué? Privacidad. Ellos no quieren que la gente sea capaz de identificar un dispositivo y luego mandar mensajes de marketing, anuncios, etc. Ellos quieren proteger la privacidad de los usuarios. Pero la privacidad para los usuarios es privacidad para los criminales. Así que lo que los criminales hicieron fue, y esta es la parte más difícil, robar los nombres y usuarios y las contraseñas con malware, phishing. Cogieron sus móviles pero lanzaron la aplicación, se metieron en Safari y abrieron el canal online del banco. Y, entonces, metieron el nombre de usuario y la contraseña. En términos de ID de dispositivo, los sistemas no pueden saber si este es el identificador del dispositivo del criminal, o el iPhone del criminal, o el iPhone del usuario. Por lo que, de forma efectiva, burlaron la identificación del dispositivo accediendo al canal online del banco a través de Safari de Apple. Cuando mostré esto a varios bancos de Estados Unidos ellos me dijeron, “bueno, no solo bancos, sino compañías de seguros también”, donde me dijeron que habían visto este tipo de manipulación. Veremos cómo puede ser resuelto en el futuro.

Desde que he empezado a hablar de móviles, he tenido la necesidad de hablar de amenazas móviles. Esto no es exactamente innovación

disruptiva pero creo que es importante para vosotros que os familiaricéis con esto. No voy a empezar con estadísticas sobre cómo es de grande el uso de los móviles, estoy seguro de que estáis familiarizados con esta parte. Esta es una imagen de cuando el Papa fue nombrado, tanto en 2005, como en 2015, podéis ver las diferencias. No hay duda de que el uso del móvil es muy grande pero, por cierto, quiero mostraros un ejemplo de mi propia vida. Dejadme que os enseñe un ejemplo de lo grande que es el uso del móvil desde mi experiencia personal. Alrededor de cinco o tres meses atrás, me encontraba en Holanda. Fui a ver un partido de la Liga de Campeones. Era el Ajax de Amsterdam contra el Barcelona (estoy en Madrid así que hablaré con cuidado de esto), pero seguro que os alegraréis, ¿sabéis quién ganó este partido? Barcelona... ¡No! Ajax, el Ajax 2-1. Messi no jugó, pero bueno... Como podéis ver, fui al partido. Estaba muy animado. Estaba con los fans del Barcelona, no me matéis por esto, mi jefe me obligó... Estábamos protegidos y todo eso, y el partido empezó, todo estaba yendo genial. Antes de que el partido empezara, trajeron al equipo de chavales del Barcelona y se sentaron justo delante de mí, por lo que había tres filas de futuros Ronaldos, o de lo que sea, sentados justo frente a mí, todos niños. El juego empezó y todo el mundo estaba animado. Y, vi esto durante el partido. [En la pantalla] Estos son los jóvenes jugadores durante el partido. Jugaba el Barcelona. Era la Liga de Campeones... Este chico, que creo que era defensa del joven equipo, cogió su dispositivo móvil, abrió la aplicación de FIFA donde estaba jugando el Barcelona contra el Ajax aquí, cuando el partido real estaba justo aquí [señala con el




puntero]. Para mi fue increíble. Empecé a hacer fotos. Era increíble. Estaba viendo el partido de fútbol en el móvil en vez de verlo en directo.

Bueno, vamos a hablar sobre los ataques a los dispositivos móviles. No voy a abarcar todos los tipos de ataques a dispositivos móviles pero quiero que conozcáis un tipo de ataque en concreto que encontramos hace alrededor de ocho meses, en Rusia, durante las etapas de preparación y que ahora está en todo el mundo. Este malware se llama SVPENG. Habréis oído hablar de él. Es un poco grande y la gente habla sobre él. Se trata de un ataque de superposición (overlay attack) sobre dispositivos móviles. Los ataques por superposición son un tipo de malware muy popular en Brasil. Lo que hace es que el malware está en el dispositivo y espera a que el usuario inicie sesión en la página web del banco. Tan pronto como el usuario accede, pone una pantalla encima del buscador. Tiene la misma apariencia que la página web del banco pero, en realidad, es malware. Por lo que, sin saberlo, el usuario está interactuando con el malware y no con la verdadera página web del banco. Se trata de un ataque de superposición. Se produce en PC. Lo hemos visto en Brasil y también trasladarse a Reino Unido. Lo hemos visto en otras regiones y ahora se está produciendo en dispositivos móviles. Por lo que, SVPENG es un malware que se disfraza como una actualización de Adobe Flash Player y, una vez que lo instalas, tiene privilegios administrativos. ¿Sabéis como consigue esos privilegios administrativos? Porque cuando la gente instala cosas... os diré como instalo yo aplicaciones: la abro y hago clic en ‘Siguiente’, ‘Siguiente’, ‘Siguiente’, ‘Siguiente’, ‘Siguiente’,

‘Siguiente’... nunca leo. Nadie lee las licencias de usuario. El acuerdo te dice que va a acceder y que va a tener privilegios administrativos, pero a nadie le importa. Así que, obtiene privilegios administrativos y el problema es que, una vez que está dentro del dispositivo no lo puedes eliminar. Si intentas eliminarlo, no puedes. Así que ahora está ahí, ejecuta tres procesos en la memoria, cada uno de los cuales están creados por un crack llamado DDD que lo que hace es fijarse constantemente en qué es lo que está mirando el usuario. En el momento en el que el usuario abre una aplicación bancaria ejecuta el ataque de superposición. Dejadme que os enseñe un ejemplo. Este es el ataque de superposición a un servidor de un banco de Rusia. ¿Podéis verlo? No, porque esta es la idea, que no veas nada. Esta es la superposición. La aplicación real está debajo pero el usuario nunca la ha visto. En el momento en el que el usuario hace clic en la aplicación, se pone una pantalla encima de ella. Así es como funciona. Podéis verlo un poco mejor aquí, en Google Play. Puedes ver que tan pronto como al acceder a Google Play Market, te pregunta por tus credenciales, por las credenciales de tu tarjeta bancaria. Esto empezó en Rusia, se expandió a Alemania y ahora, está básicamente en Reino Unido y en Estados Unidos, expandiéndose por todo el mundo. Y, además, añadieron otra dificultad a ello. ¿Qué pasa cuando infectas a alguien que no accede a la banca online? ¿O accede a un banco, el cual no es tu objetivo? Bueno, hay una solución para ello como criminal en los PC. Se llama ransomware. ¿Estáis familiarizados con el ransomware o con el cryptolocker? Ya sabéis,




todo este malware molesto que bloquea tu dispositivo y por el que tienes que pagar dinero. Ellos hacen esto en los dispositivos móviles también. Este es el ransomware de los usuarios de SVPENG. Dice que es del FBI y que has accedido a contenidos pornográficos de menores por lo que tu dispositivo está bloqueado y tienes que pagar 500 dólares a través de un servicio de pago anónimo (porque ellos son el FBI). Este es el tipo de ataques ransomware que se están haciendo cada vez más populares alrededor del mundo. Si abres Google y tecleas SVPENG podréis ver mucha información sobre esto. ¿Por qué lo hacen? Porque funciona. Porque la gente cae en ello. Porque ellos saben que funciona en los PC, por lo que funcionará en los móviles también.

Para terminar, antes de que apaguen la cámara, una cosa más: estas personas son muy profesionales. Las soluciones que os he enseñado son muy profesionales. Un amigo mío recibe una notificación en forma de mensaje en su dispositivo móvil donde el criminal intenta pescarle. Trata de atraerlo a un site con phishing pero se olvidó de conectar al tipo de ataque la base de datos que tiene con los nombres de usuarios y esto es lo que apareció: ‘Hola víctima’, en vez de ‘Hola Etay’, por ejemplo. Verás estas impresionantes fotos de desnudos, ¿bien? Y, entonces, paso a esta página web. Así que, esto es lo que pasa cuando fallas y cuando no lo haces bien. Sé que muchos de vosotros sois gente especializada en seguridad y puedo deciros que he hecho muchas entrevistas en

medios, estoy seguro de que vosotros también habréis hecho entrevistas en medios en vuestras oficinas, por favor, tened en cuenta que a día de hoy, las televisiones son HDTV y que puedes pausarlas. Además, aseguraos de que cuando habléis de seguridad, también practiquéis seguridad. Os voy a enseñar un par de ejemplos porque esto es un hobby que tengo, encontrar estos pequeños errores técnicos que tiene la gente. Este es un ejemplo: el primero es de un show de Estados Unidos donde mostraban un nueva tableta, la persona técnica quería enseñar la nueva tableta y lo potente que era y olvidó borrar su historial antes de hacer el directo. No sé si podéis verlo pero no fue la página web que quería enseñar en televisión. Otros ejemplos de este tipo de fallos son las entrevistas con deportistas. Aquí, el comentarista estaba haciendo la entrevista y no sé si veis el problema de seguridad en esta entrevista... No importa qué clase de soluciones de seguridad tengas... está es una forma de resolver tus problemas. Este es otro ejemplo... podéis ver esto... era dentro de la parte de Deportes y había una entrevista en el centro de mandos de la Super Bowl, lo que sucedió hace un par de semanas... esto es lo que emitieron.. ¡Impresionante! Pero hablemos de cosas más recientes. De hecho, hicieron una entrevista muy similar a esta en el centro de mandos de la Copa del Mundo. No sé si lográis ver esto pero aquí aparece el nombre de la red y aquí está la contraseña que era ‘Brasil2014’. Alguna combinación de letras y números, pero no es la mejor contraseña del mundo.




INNOVACIÓN EN IDENTIDAD

Luis SaizResponsable de Innovación en Seguridad, Tecnologías y Omnicanalidad, Grupo BBVA


Buenos días. Vengo a hablaros de Innovación en Identidad. Estábamos comentado antes que tampoco creo que vaya a ser esto muy innovador.

Vamos a hacer cositas, que a lo mejor sí pueden ser desconocidas para algunos de vosotros y también hacer un repaso a algunos de los últimos protocolos, de las últimas innovaciones en seguridad en el tema de Identidad. Quería repasar primero un poco por localizar, dado que trabajo en un banco, pues, darle un contexto a la Identidad en Banca. Luego hablaré de cómo la Identidad y la Gestión del Riesgo pueden ser realmente un driver del negocio. Cómo la Identidad se está volviendo a conferir como la última frontera y

luego entraremos, ya un poco más en detalle, en temas de identidad, autenticación, autorizaciones y los últimos avances que podamos contaros. El primero es: ¿Qué es esto de un banco? Un banco son básicamente tres cosas. Una es llevar la contabilidad. Ser buenos contables y llevar la famosa ‘doble entrada’. Esto se inventó por el siglo XV o XIV. Y, ¿cómo la llevamos ahora? Pues ahora la llevamos igual, pero en vez de ser en un libro mayor pues tenemos unos ordenadores mayores. ¿Qué es lo que hay que hacer? Pues conservar bien los libros. En este caso conservar bien los datos y gestionarlos bien. ¿Qué otra cosa tenemos que hacer bien en Banca y que si la hacemos mal se nos puede ir todo al garete? La Gestión de




Riesgos. Diferentes tipos de riesgos. De crédito aquí hay un radar del posicionamiento en riesgos de los diferentes países (Grecia, Irlanda, Portugal, España…). Puede que os suene de los últimos años. Gestionar el riesgo de nuestras carteras, gestionar el riesgo de liquidez, gestionar el riesgo operacional. Aquí, en esta parte de gestión del riesgo operacional, es donde entramos en la parte de la tecnología, dado en que todo esta basado en esos libros que veíamos antes que ahora son ordenadores. Y la tercera cosa que tenemos que asegurarnos de hacer bien –y aquí ligo con el tema de la charla–, es gestionar bien la Identidad. Darle el dinero al que nos lo dejó, o pedírselo al que se lo dejamos porque si no podemos tener bastantes problemas. Claro, esto a veces es complicado, no siempre es fácil determinar la Identidad porque no sabes muy bien si el que te viene a autenticarse es o no es. En otros casos puede ser más sencillo, podemos tenerlo un punto más fácil y descubrir esa impersonación.

Estos tres factores de éxito son claves para la Banca, pues los tres están regulados. Tenemos regulación contable, unas auditorías contables muy fuertes, empresas auditoras, el regulador que supervisa a su vez a las empresas auditoras. Tenemos una supervisión de riesgos muy fuerte, efectivamente, en cómo gestionamos todos esos riesgos de los que hablábamos antes, de crédito, de solvencia, de liquidez operacional. Y tenemos también una regulación específica y que no tienen otros sectores, que es en la propia gestión de identidades. En gestión de identidades se nos pide un plus frente al resto de negocios. Y es que tenemos que garantizar la autenticidad de nuestros clientes: la autenticidad de la identidad.

Esto parece un poco juego de palabras, pero básicamente consiste en que tanto por la parte de depósitos como por la de créditos, necesitamos en un caso porque nos lo exigen los gobiernos para, en el caso de que haya que perseguir a alguien por delitos de blanqueo, delitos fiscales, etc., saber muy bien contra quién tenemos que ir por la vía criminal. Y si tenemos que recuperar un préstamo que no se nos devuelve, tenemos que saber quién nos lo pidió para poder ir por la vía civil. Esa parte de autenticidad nos distingue de otras empresas que no necesitan en el proceso de enrollment u onboarding de los nuevos clientes saber si efectivamente la identidad con la que viene es auténtica. Como mucho necesitan saber si estás pagando el último recibo, o cuál es el riesgo que está asumiendo contigo la empresa. Una ‘telco’, por ejemplo, tiene ese riesgo pero la mayor parte de las veces es un riesgo no directamente económico, sino de lucro cesante. Puede ser económico en los temas de roaming; pero no es lo mismo un lucro cesante, que una pérdida económica directa.

¿Cómo vemos o cómo veo la Gestión de la Seguridad y la Gestión del Riesgo puede darnos ventaja competitiva en el negocio? Pues, tradicionalmente, veíamos que teníamos un gap de riesgo, entre lo que quería Negocio y lo que desde Seguridad estábamos dispuestos a aceptar. Entonces –alguno que haya leído el artículo que publiqué hace poco en la revista SIC– éramos conocidos como los chicos del “no”. “No, eso no se puede hacer, no. No, eso no se puede hacer”, mientras que el Negocio quería hacer cosas nuevas. Claro cuando llegaron los grandes consultores pues dijeron “no, no, no, no,




esto tiene que estar... tenéis que alinearos con el negocio”. Entonces, el alineamiento del negocio era que todas las cosas que el negocio quería, teníamos que buscar la manera de hacerlas. Este era el mundo ideal del perfecto alineamiento de los astros entre Negocio y Seguridad. Bueno, pues los mundos ideales no existen. Y entonces, realmente, lo que tenemos es que sigue habiendo una zona del ‘no’. Hay determinadas cosas que no se pueden hacer por razones regulatorias, por ejemplo, y eso es un metaimpuesto por entidades externas, y también hay cosas que no se pueden hacer porque una vez que haces el análisis de los riesgos no te va a salir económico, te van a dar por todos los lados nada más salir. Hay una zona evidentemente de alineamiento y tenemos que intentar que sea lo más grande posible.

Pero la oportunidad es que con la evolución de las tecnologías, la evolución de las Tecnologías de Seguridad y como punto de ejemplo la evolución de las Tecnologías de Gestión de Identidades tenemos una nueva área en la que se pueden hacer nuevos negocios, nuevas propuestas de valor para nuestras empresas y que el Negocio no lo sabe. Hemos de descubrirlas, tenemos que mostrarles que se pueden hacer nuevas cosas. Y tenemos que estar preparados, que ir moviendo y preparando nuestros sistemas y nuestras arquitecturas para que eso pueda ser posible. Y ejemplos tenemos muchos. Aquí os pongo algunos cuantos. Como noticia de ayer, ese que veis ahí en el medio es el centro de HCE. HCE son las siglas de Host Card Emulation. Esto consiste en que somos capaces de tener una tarjeta que se comporta ante terminales contact less como si fuese una tarjeta AMV, cuando lo que

tengo realmente es una aplicación y no tengo nada más. Me lo puedo descargar, autentico correctamente al cliente y le descargo en tiempo real los datos de la tarjeta, las claves que necesita e inmediatamente puede ser utilizada. Ese es uno de los ejemplos en los que prácticamente hablamos de un proyecto más de seguridad que de medios de pago, porque la parte de medios de pago, realmente, es igual a lo que ya teníamos. La única diferencia es cómo manejamos las claves. Y ese “cómo manejamos las claves” nos hace que pongamos en manos del cliente una tarjeta en tiempo real y sin pasar por la operadora, que nos estaba creando muchísimos problemas, a nosotros, a Google y a Visa. Por eso han sacado el estándar para poder hacerlo.

¿Qué otras cosas podemos hacer? Pues podemos habilitar a nuestros merchands la facilidad de hacer una one click purchase, de tener las mismas armas que tienen Amazon o Apple. Podemos aprovechar los conocimientos que tenemos en Gestión de Fraude para tener una autenticación que incorpore, no solamente un blanco o un negro, sino matices de gris. Podemos federarnos con autenticadores externos y, a la vez, podemos ser nosotros autenticadores. Tendremos que escoger dependiendo de qué tipo de negocio queremos hacer, qué tipo de empresa somos, si queremos aprovecharnos nosotros de terceros o queremos ser nosotros los que ofrezcamos esos servicios a terceros. Aquí hay un montón de campo abierto en el que se puede aportar muchísimo. Otro ejemplo es el remote onboarding.

Y quería, también, comentar el tema de cómo la identidad se esta convirtiendo en la última




frontera de la seguridad. Esto que parece un poco de western, es un tema del que podéis leer por ahí, ‘El perímetro ha muerto, viva la gestión de identidad’. Realmente, intentar protegernos con capas y capas cuando lo que realmente estamos es ofreciendo al exterior nuestros data centers o en la nube, ofrecer servicios y, por lo tanto, exponiendo en la capa de aplicación funcionalidad de negocio, pues del perímetro tendremos que preocuparnos, pero lo básico. Básico es cómo gestionamos la identidad de nuestros clientes o de todos aquellos que vienen a consultar o a operar con nosotros. Y esto no es nada nuevo, por eso decía que es un poco volver a los orígenes. Volvemos a los orígenes en los Sistemas/370, que es cuando aparece el Rack F.

¿Qué es lo que teníamos en los años 70, 80 y 90? Teníamos un mainframe y una gestión de identidades, una autenticación y una autorización. Y es lo que había, no había más. Y ni teníamos antivirus porque las pantallas eran tontas, y estamos volviendo a ello, y estamos volviendo a tener PC tontos virtualizados o a no tener prácticamente nada en el puesto. Y teníamos unos servicios que nos ofrecían en este caso un mainframe y que ahora nos ofrecerán servicios que, como os digo, los tendremos en nuestras instalaciones o en la nube. Pero básicamente lo que había era una gestión de identidades para ver si podías o no podías hacer lo que querías. Esto es lo que teníamos antes y lo seguimos manteniendo, los sistemas finales, los sistemas de backend, siguen siendo sistemas mainframe; luego veremos algunos de los problemas que nos crea tener ese legacy, pero hemos decidido y cada vez vemos que no estamos solos en este viaje,

que los nuevos competidores vienen con otro tipo de tecnologías, que no nos podemos quedar ahí y tenemos que ir hacia otros paradigmas. Aquí se muestran algunas de las frases de nuestro Presidente en un libro publicado hace poco de Open Mind de cómo Internet está cambiando nuestras vidas. Y, efectivamente, lo que cuenta es que vienen nuevos players que no tienen legacy, que tenemos que dar lo que quieren nuestros clientes. Y nuestros clientes están acostumbrados a manejar la tecnología que tienen en sus manos, no la que nosotros le ofrecíamos antes, sino la que tiene ahora de estos nuevos jugadores. Tenemos que ser rápidos. Tenemos que hacer un real time brutal. Y tenemos que hacerlo a un coste mínimo. Y todo eso, además, ajustado a cada uno de nuestros clientes, en las condiciones en las que quiera acceder. Y esto es intentar ser el primer banco, que seamos capaces de ser Web Scale. Están viniendo más, no dejan de aparecer noticias de otros bancos, de CEOs de otros bancos, o de CIOs de otros bancos en los que todavía no ha llegado tan arriba esta idea, pues está cuajando. Y como veíamos antes, en ese alineamiento con el Negocio desde la parte de Tecnología, lo que se nos está pidiendo es que seamos elásticos, que podamos crecer, que podamos dar servicios, sin necesidad de esperar a tener un plazo para que nos lleguen las máquinas, las instalemos, las despleguemos, las configuremos, sino que lo que quiera el cliente en el momento en que lo quiera, lo tenemos que tener disponible. Tenemos que diseñar para picos y hemos de tener en cada momento lo que el cliente nos esté pidiendo. Para poder obtener esa elasticidad resulta que tenemos que ir a sistemas distribuidos. Para tener




sistemas distribuidos, tenemos que dar que no tengan estado y, como veremos más tarde, poder tener sistemas que no mantienen el estado, sino que yo voy haciendo peticiones una a una porque la primera petición la hago a un CPD y la segunda la hago a otro y, por medio, me comunico con un tercero. Y además, necesitamos gestionar el acceso a esos datos o a esas transacciones basado en los atributos. Y ahora veremos por qué nos tenemos que ir a un modelo basado en atributos. Resulta que esto es bastante complejo en cuanto a la arquitectura que necesitamos. En temas de rendimiento o disponibilidad de los datos replicados a la vez, en todos los sitios donde los necesitemos.

Entonces, hablando ya de identidad, vamos a intentar ir por partes. Y efectivamente, no es lo mismo aunque hay veces que mezclamos los conceptos, tenemos que tener muy claro de qué hablamos cuando hablamos de identificación, el grado de autenticidad que tenemos en esa identificación, en ese proceso de registro en el que el cliente viene por primera vez. El cómo luego autenticamos. El cómo verificamos con algún tipo de credencial, que efectivamente esa petición que nos llega por parte de un cliente, con una identidad que es real o no lo es. Y luego la última: ¿cómo hago el control de acceso?, ¿cómo hago el control de operación en función de quién eres, qué quieres hacer y sobre qué? Empezando por la primera, la distinción de un usuario que, realmente, sabemos quién es y un usuario que nos da lo mismo saber quién es en la vida real, podemos tener diferentes niveles de confianza en la identidad real del usuario y podemos tener diferentes niveles de confianza en la autenticación de ese usuario.

En algunos casos nos sirve, como os decía antes, saber que es el mismo que se registró. En la mayor parte de los servicios que utilizamos, los masivos, tienen unos procesos de registros tan simples que el negocio nos pide “yo me abro una cuenta de correo y me la abro en el momento”. “si quiero usar Whatsapp, lo hago en el momento”. Dice: “claro, si lo único que necesitas saber es escoger una identidad que todavía no esté en uso y asignarte a ti mismo unas credenciales para acceder y lo único que verifica el servicio es que tú eres el mismo que se registró, pues ya hemos acabado. Ya no tienes nada más que hacer, ya te doy el alta, y lo único que tengo que mirar es que vienes con un usuario que no existe todavía, clave única, ‘punto pelota’, se acabó”. Mientras que si necesito saber con un grado de certeza más o menos aproximado, dependiendo del tipo de servicio que dé, o dependiendo de la regulación a la que esté sujeto, pues tengo que empezar a asegurarme de que, efectivamente, esa identidad es real. Y ahí, según esos niveles de aseguramiento de la identidad real, vamos a tener, por ejemplo, diferentes tipos de productos, que podemos ofrecer a nuestros clientes. Y, legalmente, en banca podemos ofrecer dinero electrónico con una verificación de identidad real, ligera. Dinero electrónico que tiene unos límites anuales de movimiento de dinero. Eso no es una apertura de una cuenta corriente en la que, en principio, no tienes esos límites, pues necesitabas hasta hace muy poco cumplir uno de los mecanismos que la ley te otorgaba. La ley te decía: “para identificar totalmente a un cliente en banca tienes estos tres mecanismos”, “no es que se me ha ocurrido...” “No, estos tres”. “Es que ha




salido un nuevo sistema con el que yo puedo...” “Estos tres”. Bueno esto era hasta que hace un mes se cambió la ley porque afortunadamente alguien se ha dado cuenta de que no pueden estar puestos los mecanismos en una ley que tarda años en poder cambiarse y se ha delegado en el Servicio de Prevención de Blanqueo de Capitales del Banco de España la posibilidad de que permita otro tipo de mecanismos de aseguramiento de la identidad de los clientes para cumplir con los temas de Prevención de Blanqueo de Capitales. Vamos a poder intentar convencer al Servicio de Prevención de Blanqueo de Capitales, qué mecanismos tecnológicos que podamos implantar y que no sean los tres que estaban en la ley, nos lo convaliden como mecanismo de identificación de los clientes. Este esquema que veis aquí es cómo el NIST, el Organismo de Estandarización de Estados Unidos para la Administración, cómo tiene estructurado el modelo de autenticación electrónico. Lo digo porque el otro día estuve en una charla de Juanjo que lo puso y dije “pues yo también lo voy a poner”. Yo también lo voy a poner porque quería discutir con él amablemente sobre este tipo de arquitectura. Y, si veis, en la arquitectura hay dos cuadros perfectamente diferenciados que se refieren a lo que venía hablando, la parte de aquí, de cómo es el registro. Ahí, es donde puedo asegurarme de cuál es la identidad real del cliente o del usuario. Mientras que la parte de la derecha es la parte en la que ya está el usuario registrado en los sistemas y empieza a utilizarlos y a autenticarse. Tenemos diferentes niveles de aseguramiento de identidad real en la izquierda y diferentes niveles de autenticación en la derecha.

Y podéis ver que podemos ir desde un tema sin Verificación en la Identidad del Proceso de Registro, hasta un tema de un nivel alto donde se nos va a pedir que esa identidad esté verificada y corroborada por diferentes partes autorizadas. Por otro lado, tenemos el grado de aseguramiento que nos pueden dar las credenciales que vamos a utilizar en los sistemas. Y, de ahí, tenemos diferentes niveles en cuanto a qué información o a qué tipo de transacciones vamos a acceder.

El modelo del NIST, cuando habla de niveles de aseguramiento..., el modelo de Inglaterra..., vienen auspiciados por la parte administrativa, de la parte del Gobierno. La parte del Gobierno al final resulta que une mucho esos dos tipos de aseguramiento porque al final sí que están ligados entre sí, porque la Administración, como los Bancos, no lo delega tampoco. La Administración en muchos de esos procesos necesita saber la identidad real del usuario que está detrás, pero si no lo necesitamos lo podemos tener perfectamente separado. Para poder luego utilizar estos diferentes niveles de aseguramiento en la identidad del cliente y en su autenticación, tenemos que preparar nuestros sistemas, el cómo hacemos nuestra arquitectura de datos, nuestra arquitectura de sistemas, para que luego podamos hacer un mapeo real de esas distintas combinaciones, con qué tipo de información accedemos o qué tipo de transacciones, con qué tipo de riesgo vamos a dejar hacer...

Nosotros hemos ido un poquitín más allá en BBVA y, en vez de hablar de niveles, hablamos de estados, que es un enfoque más genérico. Por simplificar, si nos movemos en niveles es más




fácil de asimilar, pero no tendría por qué estar, no tendría por qué ir un salto de uno en uno, sino que un doble factor o determinado doble factor podría hacernos un salto más importante o podríamos introducir un ámbito temporal de cuánto tiempo hace que autenticaste o cuánto tiempo hace que me diste el doble factor. Y la otra arquitectura típica de cómo deconstruimos todo el tema de identidad, de Gestión de Identidades, es intentar ver qué sistemas son los que necesitamos para tenerlos perfectamente identificados, segregados y unidos vía servicios. No monolíticamente, como los solíamos tener, como los solíamos diseñar, sino tenerlos perfectamente diferenciados para poder segregarlos, distribuirlos entre diferentes localizaciones de Centros de Procesos de Datos o cómo integrarnos con otras partes de nuestros Sistemas TI. Básicamente lo que veíamos antes, lo que tenemos es alguien que quiere hacer o acceder a algo y para eso, de manera genérica, lo que tenemos es un punto donde se va hacer el enforcement, donde se va a permitir o no ese acceso. Ese punto es factible poder distribuirlo allá donde tengamos el objeto. El objeto no tiene por qué estar en un punto concreto, sino que lo podemos tener distribuido en varias nubes o en varios sistemas dentro de nuestros CPDs. Luego, tenemos ese punto, hasta cierto punto es un poco tonto. Tiene que ser rápido y tonto, y lo que tiene es por debajo un servicio, un policy decision point donde le va a preguntar si ese usuario, ese subject...

Tenemos también que ir perdiendo el tema de usuario con el tema de las cosas. Ya no son usuarios son subjects que acceden a cosas. Pues ahí vamos a tener las reglas que van a determinar

si voy a dejar acceder o no, o qué tipo de acción le voy a decir al sujeto que quiere interactuar tiene que hacer en la siguiente interacción. Para eso va a tener que consultar el Repositorio de Políticas de Acceso que lo administraremos a través de policy administration point. Y para decidir eso, lo que sí vemos cada vez más es que tenemos que ser capaces de poder consultar en tiempo real información. No vamos a tener las reglas grabadas a fuego y con los parámetros ya puestos, sino que, en muchos casos, lo que vamos a tener es que consultar a servicios externos, servicios que puedan consultar atributos y servicios que puedan ver otro tipo de condiciones de contorno.

Este tipo de arquitectura que se ha plasmado, sobre todo, para el acceso basado en atributos, no solamente funciona para atributos. El sistema clásico basado en roles también podría estar siguiendo este esquema. Lo que consultaríamos ahí serían los permisos. Si, además de los permisos, consultamos los atributos, pues tenemos capacidad de hacer reglas bastante más complejas. Y, por poner algunos ejemplos de cómo de complejo puede ser esto, podemos tener un subject, que es en este caso una persona, un verbo, una acción, un objeto, la información de los clientes. Esto sería un ACL, una regla de acceso. Cuando llegó el tema de introducción de roles, lo que se añadió ahí, porque era muy difícil manejar usuario-usuario, en vez de que sea Sally, pues vamos a decir que todos los managers de ventas pueden actualizar la información de los clientes, y ya luego, por otra parte, llevo la lista de quiénes son los managers, ¿vale? Asocio a Sally a ese grupo de managers. Esto lo puedo ir complicando y entonces puedo ir añadiendo reglas mucho




más complejas, es decir, reglas desde dónde viene Sally, qué tipo de dispositivo está utilizando, qué día del año es... Puedo ir complicando... O, qué tipo de cliente es... Empiezo a perfilar no solamente quién accede, si no a qué accede. El problema viene con ésta. ¿Veis que la otra era muy complicada? Esta es mucho más sencilla, pues sin embargo esta es la realmente complicada pensando que Sally no es una empleada nuestra si no que es una cliente nuestra. Esto, que parece tan sencillo, que es que yo solo interactúo, solo puedo acceder o solo puedo operar con información o con cuentas que son mías, es lo que veíamos antes: que cuando lo quiero poder distribuir, lo quiero tener en un sistema que no guarde el estado, es cuando se nos complica y es realmente complejo el llevarlo a cabo.

El otro día en el intermedio que tuvimos en el curso de un evento organizado por SIC sobre Gestión de Identidades, hablaba con compañeros de otros bancos para ver si efectivamente todos teníamos las ruedas igual de redondas y parece que sí, que tenemos todos las ruedas igual de redondas. Cuando pasamos de ser una empresa en la que a los sistemas solo accedían los empleados, a ser una empresa a la que los propios clientes acceden a sus datos, todo el mundo, históricamente hace diez o quince años, lo que hicimos fue crearnos una autorización implícita en la que creábamos en el primer acceso, recuperábamos de nuestro amado mainframe toda la información referente a las cuentas de ese cliente y generábamos ahí un estado de esa sesión, un contexto de sesión con esa información. Hacia el cliente, por temas de seguridad, no mandábamos esos datos porque,

claro, si empezamos a mandar los datos de cuáles son las cuentas, cuáles son las tarjetas hacia la parte de cliente... Eso ya sabemos todos que eso no, eso es peligroso. No es que no se pueda hacer pero es peligroso. Entonces, nos sentíamos bastante confortables con esa... ¿eh? Mandábamos hacia la parte del cliente una referencia del valor y guardábamos el mapeo entre la referencia y el valor real en ese contexto de sesión. Cada vez que el cliente interactuaba con los servidores frontales, se producía por parte de la aplicación ese cambio, y en vez de decir: “quiero operar desde la cuenta número dos a transferir dinero a la cuenta número uno”, decía: “la cuenta número dos es bla bla bla no sé qué...”, “la cuenta número uno es bla bla bla no sé qué...” y eso era lo que se mandaba al mainframe. Todo esto, derivado de que necesitábamos poder hacerlo sin sesión (y ya expliqué antes por qué necesitamos manejar temas de sin sesión), para poder ser, para poder escalar. Esto es lo que empieza a ser complicado porque en este esquema vamos a tener que recoger información de quién accede y de qué cuentas son las que tiene ese cliente para hacer esa autorización en tiempo real. Y eso hacerlo de manera distribuida y eficientemente es lo complejo. Aquí, el tipo de condiciones, de contorno que podemos tener... Pueden ser muchísimas, la propia condición de cómo te autenticaste, quién el que te autenticó... En esa deconstrucción ahora ya no somos nosotros siempre los que autenticamos, puede ser un tercero el que autentica por nosotros o podemos ser nosotros lo que estemos proporcionando esa autenticación a un tercero. El saber quién fue el que autenticó y cómo lo hizo




es parte de la información que va a entrar como atributo, puede entrar como atributo en esas reglas. Puede entrar otro tipo de información que tengamos de ese cliente, de esa sesión. Pueden entrar muchos otros temas. Esto lo podemos complicar muchísimo.

La otra cosa que cambia es que estamos pasando de manejar identidades que son digitales a identidades que son analógicas. Y esto, ¿en qué consiste? Pues esto consiste en que... (también, te he copiado otra vez, ¿eh? Juanjo)... ¿Qué es lo que teníamos antes? Pues antes teníamos que o estábamos autenticados o no. Y si no estábamos autenticados accedíamos a la información que era pública, y si lo estábamos, podíamos acceder a información privada. Y ya está. Por eso digo lo de digital porque o estábamos en el cero o estábamos en el uno, y no había mas, y no nos planteábamos más. Pero tenemos muchas más cosas. Podemos saber, como os decía antes, cómo te has autenticado, quién te ha autenticado, qué otras variables de contexto tenemos en la autenticación o en cada una de las siguientes interacciones. Esto en banca lo sabemos hacer bien por la parte de fraude, porque en la parte de fraude una autorización de una tarjeta de crédito es autorización... En la autorización de tarjeta de crédito, ¿cómo te autenticas? Pues por un lado, autenticando a la tarjeta. Y, por otro lado, estás autenticando al usuario con un pin, pero al final no deja de ser una autenticación. ¿Y qué es lo que hace cuando llega la transacción de autorización? De la transacción de autorización llegan una serie de datos, se comprueban fotográficamente y si dice que sí, es que sí, y si dice que no, es que no. Entonces, lo de la monitorización de fraude nos

la quitamos, ¿no? Porque si no hay nada más que hacer... Sí, sí hay más que hacer. ¿Por qué? Porque no solamente vienen esos dos datos criptográficos, viene mucho más. Viene información de cuál es el importe, dónde se está efectuando el pago, en qué tipo de comercio se está efectuando... Ese tipo de información adicional, que no interviene en la autenticación, nos puede servir para ver si esa autenticación, que en teoría es un cero o un uno, tiene pinta de que es buena o es mala. Podemos ver el histórico del cliente, o podemos ver una primera operación que nos resulta rara y estar pendientes de la siguiente que nos hace. Por lo tanto, nosotros en banca sabemos manejar estas autenticaciones fuera de los ceros y los unos.

Siguiendo con el modelo del NIST, y también para ir yendo de lo digital a lo analógico, lo primero que hacemos es que en vez de ser digital puro pues tenemos diferentes saltos. Y tenemos una parte pública que viene alguien sin identificar. Tenemos una parte que a lo mejor no parece que sea útil en un primer momento pero, realmente desde el punto de vista de negocio, sí que lo es. Y es: yo puedo tener una especie de estado personalizado en el que puedo intentar personalizar la información que le dirijo a un cliente e incluso en el caso de que el cliente todavía no se haya autenticado. ¿Por qué? Porque una vez se autenticó. Una vez. Y le dejé una cookie, y le dejé ahí una señal, que se la puede robar, que puede no ser él cuando venga la próxima vez. Bueno, pero si en el 99% de los casos yo, cuando entro al banco, entro desde mi PC, la siguiente vez que vaya al PC, el banco antes de que yo me haya autenticado puede saber con más o menos certeza quién soy. Y no me va a enseñar cuál es mi posición, pero si




por el tipo de cliente que soy, me tiene que ofrecer un préstamo o me tiene que ofrecer un depósito, el banner de publicidad que me coloca es uno o es otro. ¿Sucede algo si en vez de que entre yo entra Mac? Pues no pasa nada, lo más que puedes hacer es que le intentes colocar un depósito y lo que quiere es un crédito porque anda pelao pero, bueno, eso es lo único que puede pasar. Luego tenemos un factor de identificación, por lo cual estaríamos autenticados. O dos factores de autenticación, con lo cual podríamos acceder a información sensible o a realizar operaciones de riesgo. Ahí es la parte importante. Si recordáis uno de los gráficos anteriores, el cómo planteamos y cómo gestionamos los sistemas para que esa machine sea fácil y no tengamos que estar haciendo un ‘arco de iglesia’ cada vez que hacemos algo. Si tenemos claro cuál es la clasificación de información, clasificación de cada una de las transacciones de las operaciones por niveles de riesgo, luego es más sencillo poder dejar acceder con sistemas más sencillos para la parte del cliente. Si la tenemos toda mezclada, vamos a tener que ir aquí todo el tiempo. Si la tenemos segregada, la iremos mostrando o dejaremos ir haciendo las transacciones en función de la interacción que tenga el cliente. Y el último nivel que aparece en el NIST, que habla de todas sus criptografías, yo lo estoy asociando a un tema de que en algunos casos podemos tener requisitos legales en los que no sirva ni siquiera tener un doble factor porque ya no son temas más de riesgo nuestro, sino temas legales en los que queramos tener una firma reconocida. Si alguno tenéis curiosidad por cómo establece el NIST los niveles veréis que hay uno que habla de

sus criptografías. Y, una vez que tenemos esos escalones, ya podemos empezar a hacer esa continuidad entre escalones.

La continuidad entre escalones nos la van a dar temas complementarios. Nos la va a dar desde dónde estás accediendo: ¿estás accediendo desde la red interna del banco? Pues entonces a lo mejor es que eres un empleado. Tienes más probabilidades de ser un empleado si accedes desde la red del banco que si accedes desde Ucrania. Desde Ucrania puede que seas un empleado del banco pero, a lo mejor, no. Podemos tener sistemas de reconocimiento biométrico, sistemas de reconocimiento de (cómo nos contaba antes el compañero de IBM) cómo interaccionas... Cómo interaccionas con el banco, con los sistemas... Pues podemos empezar a tener aquí niveles de gris. No estoy ni en un 1, ni en un 2, estoy en un uno y medio. Te has autenticado con usuario y contraseña en la banca telefónica y, además, por como suenas, con un error de un 2%, pues parece que eres tú. ¿Te voy a dejar que recargues un teléfono móvil que ya lo has recargado otras veces, sin necesidad de pedirte el doble factor? Pues a lo mejor sí, ¿no? y no tengo que... Te facilito la vida. Eso es continuidad entre los escalones. Y esta continuidad dependiendo de quién sea el que autentique, pues resulta que nos puede subir o nos puede bajar. En el caso de que, por ejemplo, no seamos nosotros mismos lo que realicemos la autenticación sino que, vía federación, estemos utilizando una autenticación de un tercero pues como el tercero no sabemos si lo hace igual de bien que nosotros, podemos decidir que “mira que no, que cuando vienes de un tercero no te dejo hacer lo mismo que cuando




vienes autenticado por mí”. O cuando vienes de un tercero con un doble factor, pues lo mismo te dejo hacer más, no tanto como si fuese yo, pero te dejo hacer más. Y podemos ir por la parte de arriba. Como os decía antes, este sería el punto, por ejemplo, de un factor más una biometría. Llegaríamos a tener un nivel de autorización más elevado.

¿De dónde están viniendo las revoluciones en la parte de autenticación? Pues por un lado, de la parte de móviles, algo de la parte de las cosas (ya veremos qué tipo de cosas) y de la parte de redes sociales. La parte de móviles, sobre todo temas de biometría, de secure elements, de geo-fencing. Parecido a lo que contaban ayer pero en otro sentido mucho más mundano. ¿Qué cosas podemos usar ya? Pues micrófonos tienen todos los móviles, así que biometría de voz ya la podemos usar, ¿no? Cámara también. Todos los smartphones ya tienen cámara, pues ya podemos utilizar reconocimiento de cara, ¿vale? Incluso hay alguna empresa española, algunas startups, que están utilizando reconocimiento de iris, con algunos problemas porque las cámaras para poder hacerlo bien... El tema de la cámara tienes que hacerlo con la cámara frontal para ver si están dando o no están dando en el ojo y resulta que las cámaras frontales no tienen autofocus y, como no tienen autofocus y lo tienes que tener cerca, pues no hay manera de hacerlo. Y por la parte de detrás, como no te pongas frente a un espejo es un poco complicado. Entonces ahí están viendo algunos problemas. Tenemos también temas de comportamiento, de cómo reaccionas ante pequeños cambios que se realizan en la pantalla.

Pero la gran revolución que tenemos sobre la mesa son dos tipos de tecnologías: una de Apple y otra de Android, liderada por Samsung, que son la parte de biometría de huella. Con el escáner de huella lo que podemos hacer es conseguir desbloquear el teléfono, tener una manera segura de desbloqueo que, en algunos de los casos, nos va a servir como doble factor o como desbloqueo de otro doble factor que tengamos almacenado en el propio móvil de manera segura. ¿Integraciones? Pues con Amazon, por ejemplo, para poder comprar con one click, ahora sería... no sé... one touch. Sería one touch, ¿no? Directamente podrías dar una orden de compra o en PayPal, también se están integrando con el reconocimiento de huella que tiene Samsung. Y, además de este tipo de integraciones, se está estandarizando la manera en la que integrarlas dentro de los aplicativos, de tal manera que no tengamos que estar pendientes de cada nueva cosa que sale, sino que se ha creado un estándar por la Alliance que nos permite hacer esa integración de nuevas características de biometría directamente. O sea, por ejemplo, cuando Apple ha abierto su identificación por huella (su Touch ID), ha abierto el API. Lo ha abierto a todos los desarrolladores y en dos días estaba hecha la integración porque no hace falta desarrollar algo específico. Y, aprovechando que toco el tema de la apertura del Touch ID..., yo creo que es uno de los casos que vemos cómo una empresa que pudiendo controlar por ella misma una tecnología, tener la llave para que todo el mundo que quiera utilizarla tenga que pasar por ella, lo que ha hecho es abrirlo. Prefiere abrirlo y que se desarrolle, a tenerlo cerrado y que tengamos problemas para meternos aunque ella pierda el control.




Esto lo que ha hecho también Tesla hace poco en Estados Unidos. Ha abierto toda su propiedad intelectual sobre baterías, motores eléctricos, etc., porque prefieren ser los mejores fabricantes de coches eléctricos, que los únicos fabricantes de coches eléctricos. Yo creo que esta lección no la han aprendido los operadores telefónicos. Llevan diez años intentando ver cómo nos alquilan un cachito de la SIM, como sistema de almacenamiento seguro y lo que han decidido directamente es matar a la gallina de los huevos de oro antes de que dé un solo huevo. Esta era otra de las cosas que quería hablar. Utilizar la SIM como elemento seguro dentro de los móviles, veis que los móviles se están convirtiendo en la pieza central de las aplicaciones y de la seguridad. Se acabaron los token, se acabaron los temas de otros dispositivos. No. Lo que llevamos encima es el móvil. Y sobre el móvil va a orquestarse todo: las aplicaciones y la seguridad. Decía que en vez de aprovechar esa ventaja competitiva de que ya tenían un elemento seguro y poder abrirlo a que lo utilicemos terceros, pues han decidido poner todas las pegas del mundo (económicas) y lo que están consiguiendo es que nos vayamos hacia otro lado y que sean los fabricantes de los móviles los que nos terminen proporcionando elementos seguros. A esto yo creo que le queda nada. Una o dos evoluciones de hardware de móviles y va en la línea que os comentaba antes de que Apple abre el Touch ID, en vez de cerrarlo. Estoy convencido de que vamos a tener elementos seguros en los iPhones y en los Samsung, y que los vamos a tener a nuestra disposición para hacer cosas sobre ellos.

La otra cosa que, respecto a los temas de móviles, quería contaros y que también es novedad de

la semana pasada es la configuración de cómo se puede hacer el desbloqueo de la pantalla. El desbloqueo de la pantalla es muy importante, muy interesante, para poder conseguir ese doble factor que necesitamos en algunos casos en los móviles. Necesitamos poder asegurarnos de que realmente está el cliente detrás y, normalmente, lo hacemos pidiéndole algo, una password, un pin. Se lo podemos pedir nosotros desde nuestra aplicación o nuestra aplicación puede verificar si el teléfono ya lo ha pedido. En la nueva versión de Android puedes configurarlo, de tal manera que no te pida nada en la pantalla de acceso si estás cerca de tu smartwatch, de tu wi-fi, de otro bluetooth, o de algo. Si estás en su sitio es porque estás al lado de ti mismo o porque estás en tu casa o en un sitio confiable.

La otra gran revolución que tenemos encima es la parte de identidad relacionada con las redes sociales. Para cualquiera que no necesite los requisitos de verificación de identidad que contábamos antes que tenemos en algunos sectores, el manejar por sí mismo una gestión de identidad, a breve plazo, no va a tener ningún sentido. No va a tener ningún sentido que en 100.000 sitios nos estén pidiendo que nos registremos y que escojamos un usuario y una clave. Lo más sencillo va a ser si tú tienes una identidad social, úsala. Tengo toda la información necesaria para poder hacer ese enrollment, esa primera recogida de datos básicos del cliente y luego utilizarlo sencillamente. Necesitaremos algún tipo de integración para los clientes que ya teníamos antes, para ver qué es lo que hacemos para terminar de rellenar información que no tenemos en ese primer momento. Pero




básicamente, utilizar la identidad de redes sociales para la mayor parte de las empresas va a ser más que suficiente. Es más, hay algunas que nos obligan a registrarnos, a tener password cuando los que se quieren proteger son ellos en vez de nosotros. No sé los sitios en donde estáis registrados, que dices, “qué password que pongo aquí si lo único que quieres es saber que soy yo”. Y, “que a mí no me preocupa porque voy a leer el periódico”, por ejemplo. Si el periódico es lo mismo para mí que para mi vecino. El que está interesado en saber que soy yo, eres tú, yo no. La password para leer el periódico no tengo ningún problema en dársela a otro.

Por último, en todos los temas de autorización vamos hacia tres tipos de nuevos estándares. Unos basados sobre todo en delegación y combinación con autenticación que sería OAUTH y OpenID Connect. Y, por otro, el de Mayordomía. Éste, desde el punto de vista empresarial, tiene un poco menos de sentido todavía. Tiene sentido en algunos ámbitos en los que el cliente, el usuario, quiere tener control de la información, de cómo se trasfiere la información de unas empresas a otras. Aquí, sobre todo, se está avanzando mucho en temas del sector salud. ¿Cómo? Entre aseguradoras y entre hospitales que pertenecen o que están asociados a una aseguradora, se gestiona la información (ese expediente único de paciente) entre los diferentes actores. Entonces, aparece una figura que es Mayordomía de datos y cómo puede el usuario directamente gestionar la autorización al acceso a sus datos. Siendo únicamente una empresa tiene menos de sentido porque somos nosotros los que terminamos decidiendo cómo hacerlo. Y hay toda

una interacción de cómo utilizar esta gestión de autorizaciones con el OpenID Connect y con OAUTH. Esta es la combinación de tres nuevos estándares que tienen todos menos de un año o año y poco.

Retos que tenemos pendientes: ¿cómo pasar aseguramiento en los procesos de autenticación? Ahora mismo somos incapaces de que Google o Facebook nos manden información adicional de sus usuarios, nuestros clientes, que a pesar de que los tenemos matcheados, no sabemos cómo se han identificado ante ellos. No sabemos cuándo nuestro cliente usuario de Google se ha autenticado, o ha utilizado el doble factor de Google. Si Google en ese momento tiene reconocido el dispositivo en el que esta entrando, o su propio scoring interno que Google y Facebook tienen, ¿nos lo podrían pasar de alguna forma? Nos vendría muy bien, les daríamos muchos más servicios a nuestros clientes. El otro reto que tenemos pendiente es el de las autorizaciones distribuidas y el rendimiento de autorizaciones, que van un poco ligados. No hay tampoco un estándar de cómo puedo preautorizar determinados accesos a datos. Se está haciendo por parte de los distintos proveedores utilizando tecnología propietaria. Por ejemplo, Amazon en su S3 tiene una manera de permitir que, en base a una clave que solamente tienes tú, te construyas una URL para acceso a datos, pero no hay estándar. Lo que sí estamos viendo es que todos los que quieren estar como primeros espadas en el mundo de Internet están mimando y se quieren quedar el tema de la autenticación y de la gestión de identidad. Yahoo hace muy poquito ha cambiado, nos ha cambiado la posibilidad de entrar con las credenciales de Google y ha obligado a todo el




que tenía cuenta en Flickr, mi caso, a abrirse una cuenta en Yahoo. La autenticación, la gestión de la identidad por parte de Google, por parte de Facebook, es una parte fundamental de su modelo de negocio. Y, por ejemplo, la integración que Google hizo hace un tiempo de todos sus diferentes servicios con una única identidad es lo que forma al final su propio ecosistema. El pegamento que une todas las piezas es cómo gestionas la identidad. Y por último, quería rendir un homenaje a muchos de los que estáis aquí. Decían, “dame un punto de apoyo y moveré el mundo”. Bueno, para poder hacer este tipo de cosas, una de las cosas que hay que hacer es tener bien sentadas las bases. Partir como punto de apoyo de tener bien hechos los deberes. Y los deberes aquí se han hecho manejando y teniendo bien implantada una identidad corporativa, que llevó su tiempo, teniendo un directorio corporativo, teniendo procesos automáticos de perfilado en base a roles y teniendo sincronizadas las contraseñas. Eso no ha permitido que, desde los sistemas internos del banco, estemos preparados desde el punto de vista de gestión de identidad para poder abordar el resto de cosas donde podemos dar un valor añadido al negocio. Si esto lo tuviésemos mal, tendríamos que estar tapando agujeros y no diciéndonos a ver cómo podíamos dar mas funcionalidades al negocio. Y, también, aparte del punto de apoyo fuerza, el ver cómo estamos organizados y la experiencia que tenemos en riesgo, en fraude, en desarrollo. Y como resumen final para la presentación y para esto, evidentemente, la ejecución lo es todo. Aquí no sé si estamos deconstruyendo el plato. Sea como fuere, hay que deconstruir pero con sentido,

que lo que nos quede luego no sea una mayonesa cortada. Muchas gracias.

Turno de preguntas.

Pensando a futuro, ya que hablaste de los móviles y cómo van a reemplazar muchas tecnologías, ¿cómo ves los temas de autenticación futuros? ¿Qué nos viene con los móviles NFC...?

Básicamente veo, como os decía antes, muy fuerte el tema de biometría integrada para facilitar el acceso a desbloquear, lo que es el uso del móvil, el uso de aplicaciones o poder hacer un desbloqueo rápido por parte de las aplicaciones de una verificación de que, efectivamente, estás tú ahí delante. El tema de NFC yo creo que va a seguir, no lo veo tanto como autenticación, sino para utilizarlo como elemento sustitutivo de la tarjeta, que sea directamente el móvil el que lo haga. El gran problema es Estados Unidos, que lleva bastante retraso en todo esto porque todo lo que se esta haciendo está basado en EMV y ellos todavía no están. Pero viendo algunas de las cosas que se preparan, pues yo creo que... a ver si lo encuentro por aquí, que creo que lo tenia... No, no lo tengo... Cuando estaba preparando la presentación estuve viendo algunas de las patentes que Apple está presentando para todo el tema de gestión de pagos. Y en esa gestión de pagos evidentemente está wi-fi y está bluetooth porque están apostando por ello. Pero está NFC en la comunicación con el TPV. Con lo cual por esa parte veo que es la vía por la que vamos a




terminar yendo. Y por otra parte, los operadores se han quedado fuera... la disrupción ésta... la innovación disruptiva, en vez de hacerlas ellas se la están haciendo otros. Se quedaron sin el mercado de los SMS por Whatsapp a pesar de que tenían los protocolos y los sistemas preparados para hacerlo ellas mismas, decidieron no hacerlo. Y, ahora mismo, yo creo que se están quedando otra vez fuera con el tema de las SIM. Los elementos seguros van a venir en los móviles y los vamos a poder utilizar, bien porque nos los dejen utilizar directamente o bien porque el modelo de acuerdo que tengamos sea mucho más factible de tener con dos, tres, a lo sumo cuatro grandes fabricantes de móviles, que con 20, 30, 40 operadoras que podemos estar gestionando en un grupo como el nuestro. Podemos tener tres grandes operadoras pero luego tienes cinco o seis, diez pequeñitas en cada país. Y, aunque haya muchas que coincidan al final, resulta que operadoras para llegar a acuerdos tienes decenas y fabricantes de móviles tal como esta el patio pues quedan cuatro, y el cuarto renqueante.

Sigo con los móviles y con las técnicas de biometría que se están empezando a implantar en ellos. La reflexión que yo quería hacer contigo es que realmente ahora mismo todas esas técnicas están basadas en lo que es experiencia de usuario. Hace poco Gartner decía que uno de los problemas que hay al utilizar la biometría en móvil, dentro de un punto de vista de seguridad, es que los algoritmos que están implementados a día de hoy para evitar una alta tasa de falsos negativos, están haciendo los algoritmos más laxos con lo cual está subiendo mucho la tasa de falsos positivos. ¿Qué opinas de la utilización

de estas técnicas a día de hoy como parte de seguridad, cuando digamos el umbral de credibilidad es tan laxo?

Pues que no lo vamos a utilizar como mecanismo único. Si quieres utilizar biometría como mecanismo único te tienes que ir a iris, a un reconocimiento de huella con unos lectores más ajustados, pero que no puedes distribuir de manera masiva, o te tienes que ir a reconocimiento de venas. Hay sistemas que te servirían como mecanismo único, como un factor. Yo lo veo más como ese medio factor, ¿vale? Para hacer esto, ¿qué necesitas? Factor y medio. Y ese factor y medio en muchos casos es más que suficiente para el tipo de ataques que quieres controlar: si por una parte estás identificado en el dispositivo por algún otro tipo de elemento que tengas dentro, algún tipo de clave que hayas introducido dentro del móvil, necesitas algo adicional para que, cuando te lo dejas encima de la mesa o cuando te lo roban, no lo puedan utilizar directamente. Y ahí nos sirve casi cualquier cosa. Sí, cualquier cosa. Nos sirve un PIN, el desbloqueo que tengas puesto en el teléfono, si lo hacemos por nosotros mismos las claves de acceso que tengamos, y nos sirve una biometría con un margen de error de un uno por ciento o menos de un uno por ciento, sin necesitad de que sea un uno por diez mil…, porque la probabilidad de que alguien tenga acceso a tu móvil y que le cuadre, sea justo esa persona la que te lo ha robado o la que te lo está distrayendo, llegue a tener eso, pues es muy, muy baja. Es parecido a las tarjetas por un pin de cuatro dígitos. ¿Por qué un pin de cuatro dígitos es suficiente en una tarjeta? Porque si tienes que tener la tarjeta pues con eso tenemos suficiente.




Tenía dudas de hacer esta pregunta porque no recordaba si la conversación que había tenido contigo por Twitter era en privado –con lo cual no se debe de decir– o en público... Era en público. Hace unas semanas hablando de contraseñas me decías, “Será porque en el fondo saben que da igual”. Y la semana pasada, además, una persona cuyo nombre no voy a decir, que pasa por ser el hacker más conocido de España, tenía un post, precisamente, a propósito de ese mismo tema. La pregunta es: ¿da lo mismo (y creo que tiene mucho que ver con el core del negocio), porque si te la quieres saltar te la saltas, o da lo mismo porque sí hay otros mecanismos, como los que estamos viendo en los que se acentúa la investigación y que van adelante, y las contraseñas son el pasado?

Las contraseñas no van a ser el pasado, vamos a seguir utilizándolas, porque son muy útiles, muy sencillas de utilizar. Lo que no vamos a tener es contraseñas para 50 sitios. Vas a tener tu contraseña de tu red social de referencia, que estará asociada con tu correo de referencia, y la de tu trabajo y dos más. Porque el resto es que no tiene sentido. El sentido que tiene es que es fácil de hacer, o era fácil. Ahora es fácil de hacerlo de otra forma. Y como es sencillo hacerlo de otra forma, lo vamos hacer. En lo que toca a la seguridad de la propia contraseña, el principal problema que se tiene es que solo se tiende a ver uno de los posibles métodos de ataque, que es el de “te he robado tu base de datos de contraseñas y me dedico a hacer fuerza bruta”. Y todos los sitios donde veáis que dicen cuán segura es una contraseña, se refieren a cuán segura es una

contraseña frente al ataque de robo de base de datos de contraseñas. El problema es que esa no es la manera en que se roban las contraseñas, las contraseñas te las roban con los caballos de Troya. La manera de proteger las otras no tiene que ver con la complejidad, hay maneras de hacerlo, lo que pasa es que los fabricantes no las quieren hacer, no se muy bien por qué. Y bueno, algunos que se están pasando al tema de empresa, ya se están dando cuenta de que una cosa es predicar y otra dar trigo, efectivamente.

Has empezado la conferencia comentado cómo la innovación en seguridad, más específicamente el caso de identidad, puede utilizarse como un habilitador de negocio y luego, pues es evidente que hemos pasado de un mundo hace años en que todo era igual, utilizaba alguna password y alguna cosa comercial más, al momento en el cual tú te puedes diferenciar con todas estas cosas que cuentas; y de hecho vosotros estáis dando algunos pasos adelante. Mi pregunta es: ¿hasta qué punto ves que esta capacidad de diferenciación que en principio te obliga a tener tecnología propia o soluciones propias, también es un posible factor de riesgo de imagen? Por ejemplo, muy recientemente salía que PayPal, su sistema de doble factor, habría ‘bypasseado’, cuando hacía poco pues se habían llevado sus contraseñas por lo cual, este tema de jugar con nuevos sistemas de autenticación propios, también conlleva un riesgo de imagen que corres, digamos por proponer a Negocio nuevas posibilidades basadas en nuevas tecnologías de las que tú eres pionero. ¿Cómo ves este riesgo? ¿Merece la pena correrlo?




Creo que sí merece la pena. Evidentemente, ¿qué nos pueden sacar cantares porque hagamos las cosas mal? Sí. Nos las sacan haciéndolas bien... No creo que estés libre de problemas porque seas o no seas tú el que lo ha fabricado. El lío que se montó con el Open SSL, pues nadie se había puesto a fabricar porque, además, desde Seguridad decimos no fabricar nuestra propia criptografía. El lío que se ha montado, cada uno qué tenía y qué estaba afectado, luego que se pudiese utilizar o no. A cada empresa que tenía un Open SSL vulnerable, la que le montó fue espectacular. Cuando no tenía la mayor parte de las veces ni pies ni cabeza el revuelo que se montó. No estás libre. No estás libre ni haciéndolo tú, ni teniendo una pieza de mercado. No estás libre. Entonces, en cualquiera de los dos casos tienes que ver, que asegurarte, hasta todo lo posible, de esa pieza de mercado, de estar pendiente de ella y si te lo fabricas tú, de zumbarle bien. No creo que estés mejor posicionado en un caso que en otro.

Al principio comentaste que uno de los paradigmas que ha ido cambiando es pasar de ‘clientes más inteligentes’ a ‘clientes más tontos’, ¿no? Yo no sé si eso, dentro del mundo móvil, está pasando. Yo creo que no, porque hoy cada día se mete más inteligencia dentro de los dispositivos. ¿Cómo ves esa evolución dentro de los propios móviles, alineado con la tendencia del Bring Your Own Device para ver cómo controlamos a nuestros propios empleados de traer sus dispositivos? Segunda cuestión: sabemos que estamos en un mundo muy conectado, que la evolución es bastante ágil, vemos nuevos productos, nuevas

tecnologías; pero sin embargo todos conocemos las cuentas exprés de nuestros compañeros de BBVA Bancomer, de que se utilizan teléfonos un poco menos tecnológicos. Precisamente BBVA Colombia ha sacado también su banca móvil con tecnología un poco más, atrasada. ¿No estamos dejando a mucha gente fuera del panorama cuando estamos invirtiendo demasiado en tecnología?

Empezando por la última. ¿Cuánto tiempo tarda una empresa como nosotros sin implantar un sistema? ¿Cuál es la tasa de reposición de tecnología con la última tecnología? Pues es que ya te he contestado. La velocidad a la que vamos es que, o salimos corriendo hoy o no llegamos. Pero corriendo es corriendo. Dice “no, es que la penetración que tiene el móvil es de...” Mira, la penetración que tenga hoy el móvil será del uno, o del diez. La que va a tener dentro de un año y la que va a tener dentro de dos años es exponencial. Entonces, tenemos que estar preparados para ello y apostar por lo que vamos a ser capaces de implantar dentro de un año porque, dentro de un año, la escena que vamos a tener es totalmente diferente. Y respecto al tema de virtualización, como gestionar la parte de Bring Your Own Device, precisamente con virtualización; cuanta más virtualización tengamos, más fácil será para que tú puedas traerte el dispositivo que quieras. Trae lo que quieras que yo te virtualizo y no te dejo que los datos residan en tu dispositivo, sino que te los presento yo. Cuanta más foto te presente y menos dato, mejor. Por eso digo que volvíamos a los orígenes de las pantallas tontas, y no refiriéndome a que no tengan capacidad de proceso, por supuesto que en el móvil puedes




tener mucha capacidad de proceso, pero si la aplicación la tengo en una sandbox y la aplicación la he construido yo, y los mecanismos que tienes de que salga el dato de ahí los controlo yo, pues será muy listo pero al final es muy tonto, porque no puedes hacer más que lo que yo te deje.

Una pregunta adicional. Colgándome de la pregunta anterior relacionada con el uso de las contraseñas a futuro y viendo que no se dejarán de usar y sabiendo los riesgos en los cuales nos pueden capturar esa contraseña, ¿cómo ves la posibilidad que las empresas tipo Google, Facebook, que ya tienen nuestros datos de móviles, utilicen autenticación fuerte a través de Whatsapp, por ejemplo?

A través de Whatsapp exactamente no, porque el Whatsapp no lo tienes ligado a la aplicación, lo tienes ligado al teléfono, al número de teléfono, no a ninguna aplicación; pero, en todo caso, yo creo va a estar todo más ligado a las aplicaciones que al envío de SMS. Los SMS son algo de lo que vamos a prescindir a medio-corto plazo. Vamos a apalancarnos muchísimo más en sistemas de notificación push y en aplicaciones nuestras o de terceros para analizar ese doble factor. ¿Que lo van a poder hacer ellos? Por supuesto, la ventaja que tienen y por la que en algunos casos

hay autenticación de terceros, en este caso, Facebook o Google, es que los usuarios están acostumbrados a tenerlo permanente abierto. Y, como está permanentemente abierto, pues ya tienes las credenciales. ¿Por qué vamos y fabricamos un BBVA Link con autenticación de Facebook en Chile y lo estamos promoviendo en otros países? Total, si le estamos pidiendo una password, o sea en vez de pedírsela nosotros, se la pide Facebook. Facebook el cliente lo mantiene abierto, y como es lo que mantiene abierto, pues... Y ahí vamos a ir, al tema de sesiones consultivas, poder tener permanentemente abierto... Aquí lo que pasa es que tenemos algunos una edad, ¿no? Entre mantener abierto en el teléfono o en el ordenador, entre tener abierto Facebook y vuestra cuenta del banco, ¿cuál creéis que la gente estaría más dispuesta a proteger? Digo la cuenta en cuanto a tema de consulta. Yo creo que la gente tiene más miedo a que te pillen, a que te vean el Facebook, a que te vean la cuenta. Y la están dejando abierta, con lo cual vamos a ir indefectiblemente a que los nuevos usuarios, lo de que para mirar sus cuentas les pidamos una password, no lo entiendan. Su correo lo tienen abierto y su Facebook lo tienen abierto y tienen cosas mucho mas sensibles en su correo y en un Facebook que en su cuenta corriente.




ENIGMEDIA. INNOVACIÓN EN COMUNICACIONES CIFRADAS

Gerard VidalFundador, Enigmedia


Gracias por la oportunidad de presentar aquí nuestra startup. Voy a explicaros primero una pequeña introducción sobre la Teoría del Caos. No os

preocupéis, no hay formulas, para que tengáis un poco la idea de cual es la innovación de nuestra tecnología, etc. Después, básicamente es un orden cronológico de cómo hemos montado la empresa porque así también os echáis unas risas. Es de cómo sale la idea, la innovación, cómo montamos un demostrador tecnológico y dónde estamos ahora y a qué queremos ir. Entonces, dejadme que os introduzca un poco la Teoría del Caos. Es una parte de la matemática que trabaja la forma no lineal. En resumidas cuentas, la matemática lineal.

Esto os sonará del cole, tres más dos es igual a dos más tres, tres más dos más uno es igual a tres más dos y luego le sumo el uno, etc. Bien, pues lo más curioso de todo el mundo que esto no es normal, lo más normal es que tú tengas sistemas no lineales, ¿no? Como por ejemplo, quizá os guste la sopa y seguramente os gustará el chocolate pero la sopa con chocolate no os va a gustar. En teoría las matemáticas te dicen que tendrían que gustarte el doble. Bien, pues entonces ya tenemos un ejemplo de sistema no lineal. También tenemos un claro ejemplo en que tú inhalas oxígeno y expiras CO2 pero sin embargo sabemos que la propiedad contraria no se cumple. Entonces ahí falla, claramente, la propiedad conmutativa. Hay




un montón de ejemplos. Quizá, el más chulo del caos está relacionado con el Efecto Mariposa, quizás os suena, es la propagación de error en los sistemas. Vosotros tenéis… Esto es un cuerpo en caída libre, ¿no? No sé si habéis hecho alguna vez un ejercicio de estos de ingeniería, de calcular con una ‘g’ de nueve con ocho, eso esta mal, y una ‘g’ de diez. Entonces, la solución tiene pinta de ser la misma pero hay un error, hay un error pequeño. Sin embargo, la pinta es la misma. Pasa lo mismo con los planetas. Tú te coges las leyes de Kepler y las soluciones son elipses, ¿no? Esto, quizás, es un error de millones de kilómetros pero la solución tiene la misma pinta. Entonces, con el caos pasa una cosa muy curiosa y es que tú has cometido aquí un error muy pequeño (esto creo que es una simulación con una millonésima de diferencia), fíjate que al principio parece lo mismo pero cambia. Esto ya no es lo mismo que esto, ya no lo puedes representar. La solución cambia. Hay una propagación brutal del error. Un pequeño error hace que todo se estropee y esto tiene unas consecuencias brutales con determinismo, con la predictibilidad de las cosas. Porque cuando estaban Galileo o Laplace la gente pensaba que si tienes un estado del sistema, coges las leyes de la naturaleza o el modelo matemático que tú creas, puedes sacar el estado dos. Si tienes el estado dos y lo pones al principio, sacas el estado tres. Es decir que si tuvieses una capacidad infinita de cómputo, podrías predecir el futuro y sabrías lo que va a pasar. El problema del caos es que se demuestra matemáticamente que eso es falso, y que tú no tienes capacidad de predicción. Y eso es muy curioso porque no piensen que es una teoría matemática, es decir, Enigmedia empieza con un

experimento, estaba yo calentando aceite y veía cómo se formaba un patrón convectivo. No sé si vosotros alguna vez habréis calentado aceite para hacer una tortilla de patadas: el aceite se curva, la superficie del aceite se curva un poquito, esto es lo mismo, lo que pasa es que esto es con aceite de silicona, etc. Pero tú ves ese patrón y cuando vas conectándolo forma una oscilación que es impredecible. Si alguna vez cuando calentáis el aceite de la tortilla de patatas, os sale el mismo patrón en dos sartenes, preocupaos algo pasa. Es un fenómeno físico sorprendente. Tiene que ser impredecible.

¿Cómo surge Enigmedia? Surge de que tenemos un método matemático para generar secuencias seudo-aleatorias: son secuencias que yo sé que son impredecibles. Entonces, ¿para qué lo planteamos? Muy bien, pues para cifrar. Normalmente, este es el esquema típico de un keystream, donde tú sabes que si tienes el mensaje aquí, aquí esta la puerta XOR y aquí tienes una secuencia seudo-aleatoria con unas propiedades matemáticas especiales, el cifrado que esta aquí es indescifrable, el ciphertext es indescifrable, tiene entropía máxima. Lo mas curioso es que, en nuestro caso, gracias a estas matemáticas nos funciona. Entonces, hemos obtenido un esquema de cifrado con un rendimiento que ahorra un 95% de CPU respecto a los estándares actuales. Además, es altamente portable porque es un código matemático y lo puedes poner en cualquier lado, no depende de hardware. La seguridad de nuestro sistema es de 252 bits aunque podemos aumentarla hasta 630, depende de en qué tipo de procesador estemos trabajando. Lo hemos implementado y probado




en un sistema de videoconferencia en tiempo real. Os voy a contar ahora por qué cogimos este sistema porque tiene su gracia. Dejadme que os explique un poco cómo funciona y cuál es el truco de todo esto. Nosotros partimos de unas ecuaciones deterministas y aplicamos unas reglas de muestreo de manera que digo: “vale, este sistema tiene que ser simétrico, tiene que tener la misma pinta a través de un eje, por arriba y por abajo”. ¿Por qué? Porque yo quiero que haya igual número de ceros que de unos. Si no tiene igual número de ceros que de unos, eso no es aleatorio, seguro que puedo predecirlo. Y, por otro lado, quiero que haya una de-correlación entre los tiempos y es por eso que es importante el caos. Porque el caos lo que te asegura es que, entre esta muestra de aquí, y esta muestra de aquí, ha pasado tiempo suficiente como para que sepas qué viene, un cero o un uno. Me explico de una forma más clara. Esto es Madrid pero nosotros estamos en Donostia y en Donostia hay un dicho de que si no te gusta el tiempo tú esperas cinco minutos y ha cambiado. Pasa lo mismo. El fenómeno del caos es el fenómeno atmosférico, es decir, ahora mismo hace solazo, ¿no? Abres la ventana, ¿y que tienes? Solazo. Dentro de diez segundos, ¿que tendrás? Pues sol. Y, ¿dentro de veinte segundos? Sol. Vale, ¿y dentro de tres días? Ya no lo sabes. ¿Y dentro de una semana? ¿Y dentro de cuatro meses? Hay un momento en que has perdido la correlación. Hay un momento en que ya no puedes predecir lo que te va a pasar. Pues nosotros lo que tenemos es una fórmula con unos indicadores matemáticos que nos dicen cuándo podemos decir eso de una forma exacta, de manera que podemos saber cuándo perdemos

esa relación. Otra de las ventajas que tenemos es otro tipo de operación que se llama la Herradura de Esneil, básicamente lo que hacemos es una operación de stretching and folding. Stretching and folding es esto de aquí [señala la pantalla]. Tú coges una bola de plastilina y la empiezas a amasar. Es lo mismo, ¿vale? Imagínate, yo tengo una operación matemática que modela el hacer una bola de plastilina. ¿Qué ventajas matemáticas tiene esto? Muy sencillo. ¿Vosotros aquí podéis distinguir los colores? Vale. Veis que aquí es una masa uniforme, ¿verdad? A ninguno de vosotros se le ocurre, si tiene esta bola de plastilina, empezar a mezclarla de manera que le salgan los colores. ¿Hay alguien que piense eso? Vale. Esto es una prueba de que vamos bien. Entonces ¿esto para qué nos sirve? Nos sirve para esto: con estas dos herramientas matemáticas lo que hemos conseguido es lo siguiente, lo que hacemos es esta gráfica. ¿Qué quiere decir esta gráfica? Esta gráfica es, fíjate, esto es rand(). ¿Os suena el rand() de Linux para generar números aleatorios, etc.? Vale, nosotros tenemos nuestro sistema Enigmedia y esto es la información mutua entre bits. Y esto es la separación de esos bits en tiempo. Fijaos, la banda azul está con la banda roja, ¿qué quiere decir eso? Quiere decir que nosotros hemos hecho un sistema y decimos “si nuestro sistema funciona, la información mutua entre los bits debería ser cero y debe tender a cero”, y casualmente funciona. Tiende a cero con la misma pinta que funciona la función rand() que está hecha para que dé esto. Entonces, de alguna manera nosotros hemos acertado. Hemos cogido una teoría, hemos dicho “a ver, si hago esto y me funciona, tengo que tener una




máquina que genere número aleatorios”. ¡Toma! Y funciona. Entonces, hemos cogido esta maquina que genera números aleatorios y los hemos puesto en un sistema clásico de cifrado. Y, ¿ahora que hacemos? Pues cifrar. Ciframos mucho más rápido que los demás. Esto es un resumen de tests de análisis (tenemos muchos más, me podéis preguntar después si queréis), pero para que veáis que pasamos los test del NIST sin ningún problema. Normalmente cogemos el test del NIST, se ha hecho sobre 800 secuencias y un millón de bits cada secuencia. La diferencia, lo que nos caracteriza a nosotros, es que hemos cogido una sola semilla para hacer estas 800 secuencias y diréis “esto está mal”. Y digo “no, es que lo hemos hecho aposta” porque hemos dicho “si funciona el sistema tiene que ser ergódico, es decir, que me da igual coger una sola semilla que ochocientas semillas distintas”. Es obvio que con ochocientas semillas distintas iba a salir bien. Lo que tiene mérito es que yo coja una sola semilla y el resto de secuencias me siguen dando. Entonces, son más propiedades matemáticas que añadimos.

Bueno, esto es para que veáis el benchmark con la velocidad: esto es AES 128CBC, aquí está RC4 (RC4 es el del wi-fi, para que quede claro). Entonces, os voy contando la slide del benchmark: lo que hemos hecho ha sido “hemos cogido nuestro código y lo hemos compilado para 16 bits con OpenSSL… perdonad, nosotros hemos compilado con GCC, sin ningún tipo de truco, en diversos procesadores y lo hemos comparado con OpenSSL, que es el estándar, con todo el hardware activado, etc. Nosotros no usamos ningún tipo de instrucción extra, de aceleración por hardware, de instrucción especial, etc. Solamente, compilar el

código tal cual. Incluso compilando el código tal cual, veis que tenemos un orden de magnitud más que en el resto de los casos. Por ejemplo, en el caso del Intel es especialmente llamativo, porque nuestro resultado, este algoritmo esta diseñado para 16 bits, el procesador tiene 64 y además es doble core, con lo cual, quiere decir que haciendo una operación muy sencilla de compilación podía mejorar estos resultados por diez, bueno por ocho para ser exactos. Entonces, es llamativo porque lo que hemos hecho es un sistema que matemáticamente es mucho más rápido que el resto, no tiene más.

Bien y aquí viene lo divertido. Hemos descubierto una cosa que tiene una seguridad de 256 bits, ahorra el 95% de CPU respecto al resto de cosas y sirve cualquier tipo de comunicación. Y esto está bien. Entonces dijimos: “bien, aquí vienen los problemas”. Bueno, son otros resultados para enseñaros: comparamos los anchos de banda (esto de la plataforma de comunicaciones seguras), ahorramos un 50% porque aplicamos también compresión, esto sería el overhead de HTTPS y otros servidores de streaming y esto es el número de conexiones que te aguanta un servidor. En nuestro caso puede aguantar más conexiones porque tenemos menos carga de CPU. En este caso, triplicamos al resto. Bien y ahora viene el choque de realidad que te ocurre cuando vas a montar una empresa. Y es lo siguiente. Tú te juntas con tres colegas y dices “buah, tengo una teoría matemática súper chula que sirve para cualquier cosa, va mucho mejor, es más rápido, esto se tiene que vender en algún lado, esto lo quiere alguien”. Vale, ¿quién lo compra? Luego, segunda pregunta: ¿cómo se vende? Porque, claro,




tú no has visto una tienda de cifrado en tu vida. Dices: “¿dónde voy?, ¿dónde lo vendo?, ¿a quién se lo cuento?”. Y luego la siguiente, una vez que ya nos pusimos a buscar gente, claro tú imagínate estás echando unas cañas con tus colegas, haces un brainstorming, te haces una lista de la gente que puede acceder ahí y dices “vale, voy a ir a ver a este tío, que tiene una consultora TI, muy grande, seguro que hay alguien ahí que me entiende”. Tú, el primer día que vas a vender eso en lugar de tener un Power Point como todo el mundo, coges una pizarra y empiezas a llenarla de fórmulas y llega el primer choque: “¿cómo es que acabo de demostrar matemáticamente a alguien que lo mío funciona y no lo ha entendido?” Y claro, tienes que darle vueltas y tienes que mejorar tu mensaje y te das cuenta de que tienes un problema y que no te sirve. O sea, que tienes que forzarte a montar una empresa, ¿no? Y esto te cuesta un montón. Entonces, las primeras decisiones fueron primero montar la empresa. Es decir, “vale, hemos superado esto, sabemos que tenemos que montar una empresa, vamos a hacerlo”. Esto ya es un Cristo porque, no sé si sabéis en España lo que pasa. Imagínate el primer día, somos tres ingenieros, vas a montar una empresa y te dice el tío de Hacienda “oye, necesito una cuenta de banco”. Muy bien. Te vas al banco y te dice “no, necesito el alta en el IAE” y dices “vale”. Te vuelves al banco, bueno te vas a Hacienda y dices “oye, necesito el alta en el IAE” y te dice “no, no tienes una cuenta bancaria y te vas al IAE”. Y aquí dices: “estaré haciendo yo mal algo? No puede ser que el sistema esté mal”. No, el sistema está mal. Tienes que aprender este tipo de cosas, es decir, tienes que suponer que hay cosas

que están mal intrínsecamente, ¿no? Cosa que, imaginaos, haciendo ingenierías eso ya te rompe por completo, pero bueno. Entonces, primero montamos la empresa, ¡lo que nos costó! Cogimos un mapa de España y empezamos a ver dónde había dinero. ¿Aquí nos van a dar subvenciones? No. ¿Aquí nos van a dar subvenciones? No. Bueno, al final terminamos en Donostia, dijimos “se come bien”, y nos lanzamos, nos dieron una subvención, la verdad es que nos esta yendo muy bien y dijimos “bueno, hemos tenido una experiencia y es que nadie nos entiende”.

Entonces, tenemos que hacer dos cosas. La primera, hacer una lista de gente que nos entiende ahora. Tal cual estamos, tengo un paper científico, ¿quién nos va a entender en el mundo?, ¿cuánta gente hay? No habrá mucha. Tampoco es cuestión de ofrecerse mucho porque no la vas a encontrar. Lo que te salga primero y si están lejos pues coges un avión y te vas. Y la segunda es decir “vale, tenemos cubierta la parte de la gente que nos entiende, ¿qué hacemos con la gente que no nos entiende, que es el 95% del mundo?”. Vamos a hacer un prototipo para la gente que no lo entienda lo vea. Vale, si haces un cacharro la gente entiende las cosas, entiende un cacharro, entiende un producto. O sea mi abuela si yo le digo “abuela tengo una teoría científica” me dice “te quiero”, pero nada más. No me va a comprar eso. Claro, tengo que hacer algo que la gente lo entienda, lo vea y lo haya usado. Entonces, en nuestro caso hicimos un prototipo. Este prototipo es un sistema, una plataforma de comunicaciones seguras. Esta plataforma de comunicaciones seguras es, imaginaos, un Skype; está cifrado y permite hablar entre smartphones, tablets,




móviles y ordenadores, todo con todo. Entonces, ¿qué ventajas tiene? Como tenemos una obra de CPU, consumimos menos energía y podemos usar el CPU que nos queda para comprimir, con lo cual conseguimos unos ahorros de ancho de banda del 50% y hacemos que la batería en el móvil te dure más del doble. Son números, son métricas que ya molan. No es el core, no es lo que queremos transmitir porque nuestro core es mucho mejor (es la tecnología de cifrado), pero bueno, esto se entiende. Esto alguien que quiera una plataforma segura de comunicaciones “bla, bla, bla”, le puede servir. Entonces, empezamos a vender esto. No lo queríamos vender pero nos lo empezaron a pedir, que es lo mas curioso.

Hicimos la app que, como veis, no tiene nada, te la bajas del market, esta es la pinta que tiene para la tablet y para el ordenador y esta para el smartphone, no tiene más. Puedes hablar con gente y esta es la situación para la televisión. Lo que hicimos para la tele fue coger un dispositivo muy barato de estos que venden en Alibaba y le metimos nuestra aplicación. ¿Para qué? Para demostrar que incluso en un cacharro muy barato de Alibaba, con poca potencia, podemos hacer una videoconferencia en HD y así dejarlo claro: “oye tengo una solución técnica que nadie más tiene”. Pero no queríamos venderla porque no sabíamos cómo vender cosas. Es un problema que teníamos, aunque finalmente lo hicimos. Y, ahora el equivalente sería el de una polycom pero mucho más barato. Para que os podáis hacer una idea, una polycom puede costar unos 1.000 euros y esto lo vendemos nosotros por 590 euros. Entonces, ¿qué va ocurriendo? Va ocurriendo que vas viendo la realidad y la

gente te va pidiendo cosas y poniendo pegas. Dicen, “los sistemas de cifrado están súper bien, pero yo tengo un problema”. Claro, al final, para hablar de forma segura con otra persona, las dos personas tienen que tener una licencia, ¿no? Y dices: “claro, esto no puede ser. Vamos a hacer el modo invitado”. ¿Qué quiere decir? Que yo tengo mi licencia de Enigmedia App y puedo invitar a cualquier persona que tenga mi teléfono solamente haciendo un clic. Cojo mi agenda de contactos, le invito, le mando un SMS, el tío le da aceptar y ya está. Y ya puede hablar de forma segura con esa persona. Claro que esto tiene un montón de implicaciones como, por ejemplo, cómo certificas que ese móvil es seguro etc., etc. Pero de eso ya hablo después. Luego también hicimos, es súper curioso, el gestor de ancho de banda, porque nos dimos cuenta de que hablar en 3G de forma segura por voz IP pues todo el mundo habla. Pero, ¿qué pasa cuando tienes poca cobertura? Entonces, justo tuvimos un cliente que estaba interesado en esta región, en la región de CDMA-GSM, cuando tienes poca cobertura, etc., porque son países con poca infraestructura. Lo que hicimos fue coger dos, hacer un bandwidth manager con diferentes codecs, de manera que la adaptación de la comunicación sea adaptativa al ancho de banda. Entonces, tú puedes seguir hablando aunque el ancho de banda sea poco. Y aquí viene el tema, esto fue lo más divertido.

Esto fue lo del Modo Invitado, la autoridad central. La autoridad central, básicamente es una PKI, de manera que nosotros generamos nuestros propios certificados. ¿Para qué? Para que cuando invito alguien, se genere un certificado en su móvil, de manera que lo tengo identificado todo el rato




y sé que mi persona esta hablando con la otra persona. Pero aquí tuvimos un problema y es que tú esto se lo estas contando a un tío y te dice: “ya, entonces, ¿tú tienes tu autoridad certificadora?”. “Sí”. “Entonces, ¿me tengo que fiar de ti?” “Sí”. Y dice: “hombre, ¿tú te fiarías de cuatro chavales que dicen que hacen cifrado y tienen una autoridad certificadora?”. Pues dicho así suena un poco fuerte, pero tengo que decir que sí, ¿no? Dice, “no, no, esto mejor si lo cambias y tal…” Dije, “bueno, pues no pasa, lo que hacemos es que esta PKI te la damos”. Entonces definimos una cosa muy chula. Tú tienes una autoridad central que es tuya. Puedes tener monitorizados y traceados todos los tíos que están usando el sistema de comunicaciones y además tienes el control de los accesos de cuándo llaman, tienes unos metadatos, etc. Esto es muy interesante. Y encima tuvimos un problema y es que, “hombre, yo no puedo absorber todo el mensaje porque eso me colapsa el sistema”. Lo que tenemos al final, lo que hemos hecho es una autoridad central altamente escalable. El mensaje siempre pasa cifrado de punto a punto. Pero es en la autoridad central donde se hace gestión de claves, donde se generan las certificaciones y donde, únicamente, tenemos que establecer las conexiones y verificar quién es quién. Pero el resto de la información pasa. Esto tiene muchas implicaciones, por ejemplo, en la interceptación legal de llamadas, que eso no nos dimos cuenta hasta que lo hicimos. Y es que yo tengo el modo “software as a service”, que es donde Enigmedia tiene la autoridad central y si me viene el ejército o quien sea, me pide la autorización yo la tengo. “Oye, ¿quieres saber qué pasa? Yo te lo digo”. Pero, ¿que ocurre cuando la autoridad central

ya no es mía? Que no tengo acceso, ni físico, ni siquiera ahí. Entonces es muy interesante porque la interceptación legal de llamadas hace que nuestro cliente sea la persona que tiene que responder ante la Ley. Que no sé exactamente que implica eso pero hemos llegado a esa conclusión. Otra ventaja de la autoridad central es la gestión de llamadas. Como tienes todos los datos, tienes todas las autoridades, puedes invitar a gente, decidir quién tiene que llamar a quién, hacer despliegues muy rápidos, podemos hacer que haya aplicaciones personalizadas para cada tipo de cliente y, luego, que sea él quien haga un rápido despliegue. Como puedes tener esto, como puedes tener un gestor de un user manager, claro, tú puedes hacer directamente una solución arrastrando los contactos de Google ¡zas! y ya los puedes llamar a todos. También puedes sacar estadísticas, etc.

Os quiero contar también otro proyecto que tenemos, que es el de telemedicina. ¿Cómo te financias? Al principio dijimos “tenemos que hacer un producto que sirva para hacer videoconferencias, que sea seguro, etc.”, pero obviamente no te van a financiar un sistema que sea para comunicar ejércitos o abogados o bancos, ¿no? Sin embargo, un sistema de telemedicina, sí. Entonces, esto nos servía como demostrador tecnológico de nuestras capacidades. ¿Qué hemos seguido haciendo? Hemos hecho un sistema de telemedicina que, además, cumple con todos los requisitos anteriores: autoridad central, invitados… Date cuenta de que es ideal para un despliegue. ¿Por qué? Porque hemos cogido un sistema de bajo coste. Como es un sistema de bajo coste, ¿qué quiere decir? Pues que puedes hacer un




despliegue a gran escala, asumiendo los costes en lugar de tener una Xbox que es lo que hace Microsoft, pues te puedes poner un sistema que lo compras en Alibaba. Luego, claro, como tiene una plataforma Android, le puedes conectar lo que te dé la gana. Todos los sensores pueden transmitirse de forma segura de aquí al otro lado y, además, tú puedes identificar cuál es, incluso, cada dispositivo, con lo cual puedes saber quién es tu paciente. Además, tiene una serie de componentes muy interesantes.

Y este es nuestro roadmap. Ya para acabar diré que en 2012 nos juntamos tres amigos, teníamos mi paper y decidimos montar la empresa. En dos años hemos levantando 300.000 euros

de capital riesgo del País Vasco de inversión y hemos conseguido hasta dos millones de euros, en función de subvenciones de I+D, etc. También hemos conseguido un producto que es el que estamos vendiendo, Enigmedia App. Tenemos más líneas de investigación y queremos abrir en los próximos meses el sistema para transferencia tecnológica. Somos ya un equipo de 23 personas. Ya hemos ido generando empleo para aumentar la empresa de manera que estamos en buena dimensión. Para el año que viene, para enero, esperamos cerrar la ronda de inversión en torno a unos cinco millones y ya con inversores de primer nivel que adquieren startups para dominar el mundo en los próximos tiempos. Y este es nuestro roadmap. Muchas gracias por vuestro tiempo.




MESA REDONDA: INFORMACIÓN PERSONAL (PII),

DERECHOS DE LOS CIUDADANOS Y REGULACIÓN INTERNACIONAL

En la mesa redonda participaron Luis Saiz, Isaac Agudo, Juan López-Rubio Fernández, Esther González Hernández y Pablo García Mexía. La moderación estuvo a cargo de Miguel Ángel Cano Gómez.

Miguel Ángel Cano GómezInvestigador de IT Risk, Fraud and Security,

Grupo BBVA

En este debate tenemos a dos personas de Letras y dos de Ciencias, a saber: dos personas de Derecho y dos personas de Tecnología. Vamos a hablar de identidad digital. Os voy a poner unas slides de introducción. Y Esther me ha comentado que tiene una pequeña presentación que quiere realizar. Yo voy a hacer una serie de preguntas casi de ciencia ficción, al respecto de qué entendemos por derechos de las personas, por Internet y por computadoras... Vamos a hacer una pequeña referencia a una controvertida sentencia

que ha habido actualmente y plantearemos una serie de cuestiones. Lo que voy a plantear son las dudas que tengo como informático, un informático algo raro, porque tengo algo de Letras y de Ciencias. El planteamiento que vamos hacer es muy sencillo. Hablamos de Derecho Natural, el Derecho que tenemos todos los seres humanos por ser seres humanos. Sin embargo, ¿qué podemos decir en realidad? Podemos decir que una persona pasa a tener Derecho cuando tiene una identidad, cuando está dentro de un Estado regulado. ¿Qué es un Estado regulado? Un estado que tiene una ley que se aplica y cumple. Es decir, que actualmente en España, yo, por tener un DNI, por tener un reglamento




jurídico vigente tengo una serie de Derechos que están circunscritos a mi país. Del mismo modo, tengo unos Derechos en Europa porque mi país y su ordenamiento jurídico son compatibles con Europa. Independientemente, yo puedo tener todos los Derechos que quiera; pero no es real. Tenemos casos todos los días, si miramos hacia la ciudad de Ceuta, hacia Melilla, hacia Italia, hacia todas las migraciones de seres humanos que estamos viviendo. Eso nos plantea una primera duda: ¿es necesaria una identidad para ser alguien dentro de algo, que tenga unas normas que cumplimos? Eso nos lleva a ir hacia el futuro. El futuro es el mundo digital.

A mí me encanta la Informática. La Informática en realidad tiene su origen en las calculadoras, unas calculadoras como unas máquinas de estado maravillosas como el maravilloso Turing. Un día, para reventar unos ciertos códigos empezaron a meter códigos: salió un proyecto, Colossus, maravilloso, y se hicieron los primeros autómatas programables, y metieron unos datos, hacían unos cálculos con ellos muy interesantes y daban como resultado otros datos. Y tenían equipos de señores que lo miraban y decían de repente ¡Ops! estos datos son información. Con lo cual ya empezábamos a trabajar con un concepto curioso, matemáticos que trabajaban con datos ciertas de propiedades, que hemos estado viendo. Os ha venido muy bien que hablasen del caos porque algunas de las propiedades están citadas ahí. Y nos da de resultado otros datos que cuando un ser humano se ponía delante decía ¡Ops!, es información. Curioso. Los ingleses con una gran visión comercial, el proyecto Colossus con Flowers y toda esta gente, lo destruyeron y no

les dejaron hablar a ninguno de los que estaban metidos. Entonces, pasa el tiempo, se siguen construyendo diferentes tipos de computadoras, cada una hija de su padre y de su madre. Algo muy habitual en el ser humano, como hemos podido ver cada vez que hablamos de protocolos y sistemas operativos. Y a algún buen militar se le ocurre que sería una buena idea que todas esas máquinas que tienen datos pudiesen hablarse: redes heterogéneas a través de unas redes de comunicación de datos. Y se empezaron a mandar datos. Eso fue una gran idea, que en realidad hemos ido evolucionando, creciendo, creciendo y la tenemos aquí. Unas redes de datos maravillosos que nos proporcionan información. Lo estoy diciendo todo a muy, muy grosso modo para tardar poco y pasaros la palabra. En ese mundo donde todo tiene mucha información, de repente, empezamos a decir “hay que ahorrar costes”. Y tomamos esos datos y nos pusimos en cada país con una regulación diferente porque, claro, hay una parte que no he dicho, y es que cada país regula sobre dos conceptos diferentes, muy interesantes: datos e información. Es curioso y son mis primeras preguntas: ¿qué es un dato? ¿Qué es información? Tenía dos definiciones muy buenas en mi presentación que decían que la información es aquel conjunto de datos que agrupados para un ser humano, tiene un sentido independiente de la semántica de lo que el dato signifique. Y, datos son unidades elementales para ordenadores a fin de poder ejecutar determinados cálculos. Entonces yo puedo tener datos por todo el planeta Tierra, que cuando se van uniendo van formando células de información, y estas células de información pueden tener una identidad en




un determinado lugar físico del planeta. Es decir, un DNI, que es una fórmula calculada de una serie de números que me da una letra, con un nombre cualquiera y un apellido cualquiera; si esas tres cosas tienen relación en España hay una implicación legal. En Francia, ninguna. Bueno, en Francia sí, porque tenemos acuerdos. Pero en Estados Unidos, ninguna (aunque dependiendo de qué tipo de cosa hagas, también puede tenerla). Entonces, a lo que nosotros vamos es a estudiar cómo la información cambia en base a que existan acuerdos o no.

¿A dónde nos lleva este jaleo? Volvamos otra vez al tema de la información, los datos distribuidos por cien mil sitios. Sale una sentencia actualmente que dice que un autómata que recoge datos y replica algoritmos para obtener búsquedas rápidas de un compañero nuestro en esto de tener todos las mismas normas (aunque luego sabemos que no es verdad), que está utilizando, no la puede utilizar, es decir que esos datos indexados que están aleatorios por todo el planeta, que pueden estar en cualquier parte, no los puede coger, no los puede presentar; esto es curioso, porque dice que es debido a que la identidad de una persona se ve comprometida, entonces se plantea una duda. Y es mi duda. La identidad de esa persona en ese lugar etéreo que es ese conjunto de redes, de intercambio de datos, que no tienen una ubicación física total en ningún país, ¿qué es? ¿Qué es la identidad de la persona? Porque en ese mundo mi identidad, en Google, es mas útil que en mi DNI. Entonces, digo: ¿qué quieren legislar? ¿Por qué legislan contra una entidad favoreciendo, por ejemplo, a otro país que tenga otro gran buscador que no respete

ni siquiera el control cambiario entre países? Es curioso. Y luego me planteo otra, porque además lo visten con que quieren garantizar el derecho al anonimato. ¿El anonimato del ciudadano? Venga, seamos honrados. ¿Cuántos de los que estáis aquí no creéis que hay identidades mucho más potentes que nosotros y ciudadanos con mucho más poder que nosotros que quieran el anonimato antes que nosotros? Entonces, ¿qué hay detrás de todo esto? Para cerrar esta introducción, formulo unas últimas cuestiones: desde el punto de vista legal del Derecho Constitucional, del Derecho Internacional, ¿qué es la identidad digital? Y, ¿por qué tengo que estar circunscrito a los criterios de un país cuando mis datos forman parte de cien mil países? Y solamente son, realmente, información de valor cuando y donde a mí me dé la gana reunirla. Cojo mi móvil, lo abro en México y tengo unos derechos diferentes sobre la información que en España.

Y ahora paso la palabra a Esther González, a quien os presento: Esther es profesora titular de Derecho Constitucional de la Universidad Rey Juan Carlos y, hasta hace poco Subdirectora de la Fundación de la misma. También se hizo cargo durante dos años de la coordinación de las Unidades de Investigación adscritas al Vicerrectorado de la Investigación y vicepresidente del Comité Ética de Investigación de esta Universidad. Galardonada con el Premio ‘Nicolás Pérez Serrano’ del Centro de Estudios Políticos y Constitucionales a las mejores tesis doctorales y con el premio de la misma entidad a la mejor memoria de investigación en la Diplomatura de Especialización en Derecho Constitucional y Ciencia Política que también




cursó. Profesora de varios másteres, tanto nacionales como internacionales, entre los que destaca el Máster sobre Multilevel Governance de la Universitá di Cagliari, el Máster en Derecho del Estado Autonómico de la Universidad Rey Juan Carlos y el Máster en Participación Ciudadana de la Universidad Francisco de Vitoria en colaboración con el Colegio de Abogados. Miembro del equipo de Investigación Financiero sobre Análisis de Riesgo, Democracia Electrónica y también sobre el Derecho Autonómico del Constitucional. Cuenta con 18 años de experiencia docente investigadora en varios ámbitos de especialización científica. Todos ellos relacionados con el Derecho Constitucional y de las Ciencias Sociales.

Esther González HernándezProfesora Titular de Derecho Constitucional, Universidad Rey Juan Carlos (URJC)

Agradezco a Miguel Ángel Cano y a todas las personas que conozco del Grupo BBVA que me hayan invitado a participar. Esta Universidad es mi “casa” y en cierto modo he vuelto a ella para participar en este curso de verano. El año pasado yo estaba en la gestión de los Cursos de Verano y este año me toca estar aquí como ponente. Ahora que me encuentro aquí, me veo un poco chiquitita, más pequeñita de lo que soy, porque resulta que la mayoría, salvo Pablo, sois científicos, matemáticos. Y ahora vengo yo y os empiezo hablar de Derecho Constitucional, de nuevos derechos, de que no todo vale. Así que, bueno, voy a intentar salvar lo mejor posible, en tiempo y

forma, este difícil papel que me ha tocado.

Cuando venía hacia aquí en el coche, iba oyendo en la radio que hay huelga de taxistas en Madrid y en Barcelona porque los taxistas están enfadadísimos por una nueva aplicación informática que te puedes descargar en el móvil desde Internet… Hablan de competencia desleal, de que estas personas no pagan impuestos… Y venía pensando en la primera diapositiva con la que empezaba yo esta pequeña exposición. Efectivamente, hay un conflicto entre dos actores protagonistas de renombre: entre las Tecnologías de la Información y del Conocimiento y los Derechos fundamentales. Y, desde luego, tal cual se esta poniendo la cuestión, estamos ante un problema jurídico de primer orden. Ya no lo podemos negar. Ya no podemos decir, “bueno, esto ya se resolverá”. No. La tecnología esta aquí. Ha venido para quedarse y hay que intentar adecuar Tecnología y Derechos fundamentales. Y yo, como profesora de Derecho Constitucional, cuando hablo de Derechos fundamentales, necesariamente me viene a la cabeza lo que nosotros los constitucionalistas llamamos generaciones de derechos. El concepto de Derecho Fundamental es un concepto que se ha ido elaborando en el tiempo, es un concepto histórico y cuando hablamos de los listados de los derechos fundamentales, tenemos que evidenciar que se han ido generando en el tiempo. Podemos entonces concretar que a día de hoy existirían tres generaciones de derechos fundamentes. Una primera generación, que es la imagen de derecho fundamental que tenemos todos en la cabeza: derecho al honor, a la intimidad personal, a la libertad... Esas generaciones propias, esos




derechos propios del constitucionalismo liberal, que tienen su ejemplo paradigmático en la Declaración de los Derechos del Hombre y del Ciudadano, que son los derechos de libertad, de seguridad personal, etc. Pero, a medida que va transcurriendo el tiempo, pasamos la Primera Guerra Mundial y entramos en la época del constitucionalismo social, aparece una segunda generación los denominados derechos socioeconómicos. Le sigue una tercera generación que son los que llamamos derechos de solidaridad, derechos colectivos, derecho al medio ambiente, a un entorno sano, al patrimonio cultural. Bien, todo esto viene como consecuencia de lo que yo me planteo cuando empecé a preparar esta breve exposición, a saber: ¿podemos hablar a día de hoy de una cuarta generación de derechos? O, por lo menos, ¿podemos hablar a día de hoy de una nueva generación de drechos públicos subjetivos? Es decir, dado que las tecnologías están aquí, se van a quedar y evolucionar, y que tenemos esta nueva realidad, es posible en el panorama constitucional poder hablar de una nueva realidad de derechos que se relacionan con dichas tecnologías que van mucho más allá del derecho a la intimidad. Es decir, cuando los constitucionalistas hablamos de derechos fundamentales y tecnología solemos circunscribir el problema al derecho a la intimidad, al honor personal, al entorno personal familiar y a la propia imagen. Pero yo creo que esto va mucho más allá. No se pueden poner puertas al campo. Ya ha llegado el momento en que tenemos que empezar a aceptar que en nuestro panorama jurídico existe una nueva realidad. Porque además pongo aquí unos ejemplos, yo sé muy poco de

TIC, he tenido la osadía de intentar entender la anterior ponencia y estoy todavía en ello... Pero vivo en este mundo, y aunque sepa poco de tecnología, aunque no sepa de matemáticas, entiendes que hay perfiles de una persona, que son unos datos que están, aunque no sean identificables, que hay anonimización, que hay direcciones IP, que hay cookies a través de las cuales las empresas pueden enviarte una serie de publicidad aunque tu perfil no sea identificado con un nombre y un apellido. En este sentido, creo que tenemos que hablar de que existen unos nuevos derechos y la jurisprudencia también ha reconocido esta nueva realidad. Es decir, tenemos esta sentencia del Tribunal Constitucional que desde el año 2000 empieza hablar de la existencia de un nuevo Derecho público subjetivo que, como tal, no aparece así llamado en la Constitución Española, que será el derecho a la protección de datos de carácter personal. No aparece referenciado como tal, aunque efectivamente sí se puede derivar de otros preceptos. Pero, claro, éste desde la perspectiva de un jurista se ve como un derecho diferente. Porque el derecho a la intimidad lo que trata de garantizar es un espacio reservado a la ingeniería de poderes públicos y aquí, sin embargo, como dice Antoni Roig, estamos hablando de un derecho que trata de garantizar un conjunto de facultades de actuación por parte de las personas, por parte del ciudadano, en contra de la actuación de otro particular. Ya no estamos hablando única y exclusivamente de poderes públicos.

Todo esto viene como consecuencia de lo que os decía antes. El artículo 18 de la Constitución Española, que es el artículo del que todos los




constitucionalistas solemos hablar cuando nos enfrentamos al estudio de estas cuestiones, solamente incluye una referencia muy escasa a la Informática; en su apartado 4 dice: “La ley limitará el uso de la informática”. No busquen más. No hay nada más que hable de informática en la Constitución. Entonces, ¿qué ocurre? Que, efectivamente, el mundo ha cambiado, el uso de Internet está en unos niveles elevadísimos. Si hacemos caso, por ejemplo, de los datos que da el Observatorio Nacional de Telecomunicaciones, el creciente aumento del uso de las TIC es imparable. Como decía yo antes, no se pueden poner puertas al campo. El 70% de internautas, en los últimos tres meses del año pasado, accedieron a Internet fuera de su domicilio, en un lugar de trabajo, utilizando algún dispositivo móvil… Si a todos esos datos añadimos, por ejemplo, que Facebook, según dicen –por lo que yo he encontrado en páginas más o menos fiables en la Red– supera los 1.000 millones de usuarios, pues resulta que la comunidad Facebook estaría ya por el tercer estado del mundo por número de de población. Es decir, tenemos China, India y después está ese no sé si nuevo estado al que me refería; pero, desde luego, desde el punto de vista poblacional, es una realidad que afecta a un número elevadísimo de personas, todas ellas con derechos. Y parece que estas personas, muchos de nosotros, no tenemos absolutamente ningún reparo en hacer dejación de nuestros derechos a la intimidad porque colgamos datos constantemente en Internet. No tenemos absolutamente ningún problema, con lo cual, efectivamente, estamos ante una nueva realidad que nos ha superado. Esto es mucho más que hablar de derecho a la intimidad y es

mucho más que la categoría de la que hablamos los juristas, que bueno, claro, el conflicto verdaderamente esté entre el derecho a la intimidad y el derecho a la libertad de expresión, información. Efectivamente el conflicto sigue estando ahí, como decía antes Miguel Ángel.

Pero esto va muchísimo más allá, porque a veces nos enfrentamos a que los datos que hay en la Red tampoco son tan importantes. No estamos hablando de datos que vayan a conformar la identidad de una persona. Pero, ¿y la acumulación de datos? Eso sí que tiene un valor, puede tener una importancia. ¿Qué hacemos con eso? ¿Cómo se gestiona esa información? Y yo cuando planteaba esto me preguntaba… como veis son muchas preguntas. ¿Todo lo que está en la Red, todos los datos por ejemplo, que se piden para configurar el perfil de una red social, son información relevante? ¿Es información que ayuda a conformar lo que los constitucionalistas entendemos por una opinión pública libre? ¿No? Que es lo que estaría protegido por el derecho a la información y por la libertad de expresión. La mayoría de los datos son mero entretenimiento y algunos, que esto es importante también, son muy relevantes para intereses comerciales, que en muchos aspectos es lo que verdaderamente está en juego. Está claro, la realidad nos ha superado y yo apuesto porque, efectivamente, podemos hablar de una nueva categoría de derechos o nuevos derechos públicos subjetivos. Cuando empiezas a leer sobre este tipo de cuestiones, empiezas a ver en los textos jurídicos expresiones como que hay que garantizar el derecho a la tranquilidad y al descanso, o el derecho a estar solo, o el derecho al olvido, o a la autodeterminación de la información personal, o a




la identidad digital. A ver, creo que los dos primeros en el mundo en el que vivimos, son una entelequia, son absolutamente irrealizables. Pero también creo que estos tres últimos –de los que voy a hablar en un par de minutos– han venido para quedarse. De hecho, ya tenemos una sentencia, la famosa Sentencia Google, donde se habla del derecho al olvido. Y cuando los juristas hablamos de derecho fundamental, siempre utilizamos una categoría jurídica que es la del ‘contenido esencial’. Un derecho es diferente de otro si tiene un contenido esencial diferente; no voy a entrar en honduras de lo que es un contenido esencial; básicamente viene a ser aquello que lo hace reconducible a la ciudadanía. Cuál es el núcleo duro y disponible que la ciudadanía reconoce que es un derecho y no es otro. Yo creo que, cuando estamos hablando del derecho al olvido, sí que tenemos un contenido esencial bien diferente, del derecho a la intimidad. Porque estamos hablando de la facultad de los internautas de exigir que los buscadores eliminen la indexación de datos personales que obtienen de determinadas páginas o la facultad de solicitar de los buscadores la eliminación de determinadas informaciones indexadas, evitando que los buscadores localicen la información publicada o incluida en la Red por terceros, la indexen automáticamente, la almacenen y la pongan a disposición de aquel que la quiera consultar. Yo sé que Miguel Ángel no está de acuerdo con lo que voy a decir ahora, y probablemente vosotros tampoco lo estéis, pero opino que la Sentencia Google sí que tiene virtudes. Lo que básicamente viene a decir es que el sitio web sería como un almacén de información, como la biblioteca, y el buscador Google lo que

hace es que la encuentra y la difunde, como un ventilador, y todo el mundo tiene acceso a ella. Esto que a nosotros, si no estamos afectados, nos puede parecer que no tiene interés, que lo soporte determinada persona puede ser delicado; a lo mejor sí que deberíamos empezar a hablar de la superación de conceptos que se deslindan en esta Sentencia Google, como es la superación de un plazo razonable, o para la publicidad, o atender a si ha habido un cambio en la utilidad para la finalidad... que se está utilizando esa información para una finalidad diferente para la que se prestó el consentimiento por parte del interesado. Todo esto podría constituir una actividad ilícita. Porque lo que hace la Sentencia Google, en esencia, es hablar de un criterio de proporcionalidad. Está diciendo, bueno, la perpetuación de determinadas informaciones sobre personas en la Red puede ser excesiva y lo he sacado literalmente de lo que dice la sentencia. Vamos a establecer un criterio proporcional. Y, además, dice que puede afectar significativamente a los Derechos fundamentales de las personas si dicho tratamiento permite que cualquier internauta pueda obtener, mediante la lista de resultados, una visión estructurada de la información relativa a esta persona que pueda hallarse en Internet, que sin dicho buscador no habría accedido a toda esta cantidad de información. Eso es lo que dice la sentencia. Luego, a esto hay que unirle cuestiones de las que ya he tenido oportunidad de hablar en alguna ocasión con Miguel Ángel, como las orientaciones tecnológicas de web semántica, que no solamente van a buscar palabras claves, sino que se van a permitir extraer significados, ontologías y mapas de significados de las relaciones en la Red. Esto




puede cambiar y dar un nuevo concepto de dato personal, que va a ser mucho más complejo y que, además, va a ser deducible. Con lo cual, entramos en un mundo inimaginable, con unas posibilidades tremendas y los juristas y el ordenamiento jurídico en algún momento tendrán que decir algo. Luego tenemos el segundo de los derechos que yo he identificado, que sí que podríamos hablar de un nuevo derecho. Sería este derecho a la autodeterminación informática. Y vuelvo a decir lo mismo: no es un derecho a la intimidad que dice bueno, venga este es mi espacio y aquí, en mi espacio de injerencia, los poderes públicos no pueden injerir. No, aquí estamos hablando de que se otorga al ciudadano facultades. Es decir, la facultad de decidir básicamente por sí solo sobre la difusión y la utilización de sus datos personales y sus fines. Evidentemente, y en eso sí que le doy la razón a Miguel Ángel, hay que tener cuidado con estas cosas porque, claro, hay información que va a ser la que conforma esa opinión pública libre. La que hace que podamos ser una masa crítica de control del Gobierno, de control de determinadas políticas empresariales. Pero bueno, hay que tener cuidado también con personas que a lo mejor no están en esa tesitura, que no se conviertan en lo que Barriuso Ruiz habla de un hombre de cristal, absolutamente transparente. Este derecho a la autodeterminación se deslinda también en alguna decisión jurisprudencial, la básica es la 92/2000, que habla de este haz de facultades que se da a los ciudadanos, que se oponen frente a terceros y que permiten garantizar a la persona un poder de control sobre sus datos personales.

Y luego habría un tercer derecho del que también encontramos algún ejemplo en la legislación

española. En el artículo 6 de la Ley 11/2007 de Acceso Electrónico de los Ciudadanos, es el derecho a la identidad electrónica. Es decir, esta norma ya permite a los ciudadanos el derecho a obtener los medios de identificación electrónica necesarios en sus relaciones con las administraciones públicas. Y estamos, por tanto, hablando de un elemento de capacitación de las personas en el ámbito electrónico, lo que ha abierto un nuevo debate sobre la conveniencia o no de tener una identidad electrónica única. Es decir, la unificación de los proveedores de identidades digitales. Y, algunos ya han puesto la atención sobre esto, que están diciendo que a lo mejor eso podría tener muchísimos peligros.

Creo que, efectivamente, estamos hablando de otro tipo nuevo de derechos, no sé si para confrontar una nueva categoría pero que, jurisprudencialmente, y en ámbito internacional, ya se están reconociendo, que incluyen estas facultades jurídicas activas y proactivas para conformar una libre decisión de cómo, cuándo y hasta dónde se quieren diseñar o mostrar determinados perfiles o identidades en la Red, que tendrían apoyatura jurídica en el artículo 10.1 de la Constitución, que es el que regula el Derecho a la dignidad de las personas cuando habla del libre desarrollo de la personalidad. Por tanto, su encaje constitucional estaría garantizado, algo que creo que es importante cuando hablamos de tecnología y cuando hablamos de Derechos fundamentales para no perder una referencia en el horizonte.

Todo esto está para ser útil a las personas; es decir, que en la sociedad de la información y la comunicación, el centro y el referente de todas




las nuevas tecnologías tiene que ser la persona y no el dato por el dato. Y ahí es donde los juristas podemos participar y, a pesar del diferente lenguaje que mantenemos científicos y juristas, ayudar a conformar una visión integradora de todos los intereses en conflicto. Muchísimas gracias.

Miguel Ángel Cano. Pues creo que, sin más, nos falta por conocer a otras personas. Os hago su introducción y arrancamos el debate.

Pablo García Mexía es Profesor visitante de Derecho y Gobierno de Internet College of William & Mary. Letrado de las Cortes Of Counsel en Ashurst LLP. Doctor en Derecho y co-fundador de Syntagma, centro de estudios estratégicos. Lleva casi quince años enseñando, divulgando y asesorando sobre los aspectos sociales y legales de Internet. Es autor de los libros “Internet, TICs y Derechos humanos” (2014), “Historias de Internet. Casos y cosas de la red de redes” (2012), “Derecho Europeo de Internet” (ediciones española e inglesa, 2009) y “Principios de Derecho de Internet” (en coautoría, 2002 y 2005); así como de múltiples artículos sobre estos temas en revistas especializadas y medios de amplia difusión. Colabora habitualmente en el diario ABC.es, donde escribe la columna semanal “La ley en la Red”.

Me queda por presentar a Luis Saiz y a Juan López Rubio. Pablo adelante.

Pablo García Mexía. Iba a sugerir a Miguel Ángel que como Esther y yo somos juristas para no saturar al auditorio, primero tomen la palabra los

tecnólogos, o sea Luis y Juan, y luego hable yo. Pero el moderador manda.

Miguel Ángel Cano. Mejor presento a Luis y a Juan, y si os parece nos lanzamos al fuego.

Juan López Rubio es Ingeniero en Informática por la Universidad de Granada, con más de diez años de experiencia en el sector, posee las certificaciones CISA y CISSP. Actualmente, dirige el área iLabs en I4S, cuyas principales funciones son el diseño de aplicaciones, arquitecturas y servicios que permiten afrontar los nuevos retos tecnológicos en los ámbitos de Seguridad TI, Prevención del Fraude y Gestión del Riesgo en TI. Asimismo, colabora con el equipo de Innovación de Seguridad del Departamento de Tecnologías Digitales y Omnicanalidad de BBVA en la prospección de nuevas tecnologías de seguridad.

Y aunque esté en contra de lo que diga Luis, Luis no le va a pegar. Una vez dicho esto, solo un comentario sobre la jurisprudencia: resulta que también hay jurisprudencia que dice que los enlaces de eMule no son un delito... y dicho esto...

Luis Saiz. Yo estoy en eso. No me hacen caso pero yo estoy en eso.

Miguel Ángel Cano. Os dejo que os peguéis, no sin presentarte.

Luis SaizResponsable de Innovación en Seguridad, Tecnologías Digitales y Omnicanalidad en BBVA

No, si ellos lo único que van a hacer es reflejar lo que dicen los tribunales... No creo que...




Podemos discutir, ¿no? Evidentemente, desde mi punto de vista lo que pasa es que muchas de estas sentencias y muchas de las leyes nos llevan al siglo pasado o hace dos siglos. Y yo, sinceramente, la sentencia del derecho al olvido, no sé si yo no entiendo la Ley o la Ley no entiende la tecnología. Si es un dato que es público, ¿por qué no lo puedo indexar? Cuando... ve contra el origen y cuando el origen esté borrado o esté suprimido o esté marcado como no indexable, que se puede hacer perfectamente, márcalo como no indexable. Recientemente, tenemos otro pequeño lio con la indexabilidad, no indexabilidad, con un asunto que es más monetario, y que afecta a otro tipo de derechos. Los medios de comunicación pretenden que, obligatoriamente, aquel que ponga enlaces a sus noticias les tenga que pagar dinero, cuando tienen el medio técnico para que si no quieren estar indexados, no se indexen. Entonces nos meten a las tecnologías, a la parte tecnológica, en líos porque no saben por donde salir. Luego hablaremos de algún otro tema de data location y cosas de estas.

Pablo García MexíaProfesor visitante de Derecho de Internet, The College of William & Mary, Of Counsel en Ashurst, LLP

Casi mejor. Tenía una intervención estructurada, aunque luego me han surgido ideas al hilo de las sugerencias de Luis Saiz y de la exposición de mi compañera Esther, que me ha parecido muy estimulante y muy interesante. Yo no sé si probablemente es útil que os cuente lo que tenía más estructurado y posteriormente, a lo mejor, suelte más en el debate.

La verdad es que me he tenido que morder la lengua varias veces escuchando a los dos porque evidentemente están tocando la medula de asuntos enormemente interesantes. Bueno, lo estructurado. Yo quería ir por la misma senda que ha trazado Esther, concretando quizás más algunos aspectos. En general, como contexto y es probablemente la idea de partida. Van a ser tres partes fundamentales las que comparta con vosotros.

Una idea de partida, la idea de contexto. Me gusta referirme a ese contexto como un entorno de Internet total o Internet por defecto. Esto a los tecnólogos probablemente les va a resultar muy familiar, ¿no? Hay tres vectores principales para este entorno de Internet total o Internet por defecto. Uno sería el cloud, y no hace falta que dé pormenores. Otro sería el mobile, es decir, toda la irrupción de Internet móvil, los dispositivos manejables en cualquier momento y lugar más que nunca. Y, en tercer lugar, la Internet de las Cosas. Ya también daría para muchísimo, porque la propia Internet de las Cosas es evidente que tiene repercusiones legales de enorme calado y, sobre todo, en la privacidad, en el ámbito de la intimidad personal. Por cierto, aunque pensaba hacerlo después, ya me lanzo con la idea que fundamentalmente me sugería la excelente intervención de Esther, yo incluso le pediría que pudiera ir un poco más allá en ella, porque creo que a la vez es el paraguas de toda su exposición. ¿Hasta qué punto estamos ante un derecho o un haz de derechos cualitativamente distinto? Porque, efectivamente, como ella muy bien ha indicado, se ha venido hablando de generaciones de derechos. Lo habitual en este contexto ha sido




referirse a derechos de la cuarta generación y, por tanto, meter los derechos relacionados con Internet y las TIC dentro del cajón de los derechos de cuarta generación. Pero claro, ese cajón de derechos de cuarta generación se ha venido compartiendo con otros derechos que no tienen que ver estrictamente con la informática, con la electrónica o con Internet y las TIC, que son las biotecnologías y los derechos biotecnológicos. Yo casi le pregunto a ella, porque a lo mejor sería bueno que después nos comentara si lo ha reflexionado, si realmente ella cree que incluso se debería hablar de una categoría específica de derechos en la medida en que suponen todas estas cosas diferentes que ella muy bien ha subrayado. Me parece muy sugerente esa idea y estoy francamente interesado en lo que pueda comentar. Bien, esto en cuanto al contexto.

En cuanto a amenazas, en las que se plasma ese contexto. Bueno, amenazas, retos... Podemos ser más suaves. ¿Qué es lo que supone sobre todo este contexto de Internet al que me he referido, como entorno tecnológico total? Una serie de desafíos que podrían ser los siguientes. Uno de ellos... ¡eh!, y son tres, básicamente. Los franceses se han referido a ello jugando con esta noción ‘orwelliana’ del Big Brother al Big Other. Es decir, al hecho de que cualquiera de nosotros, léase teléfono móvil, manifestación, puede por ejemplo tomar imágenes nuestras, subirlas a Internet... Ya no es que sea solo el estado, un poder publico, una empresa, una gran corporación, la que puede hacerse con nuestros datos y difundirlos, somos cualquiera. Otros hablan de un panóptico. A mí, me gustaría referirme al efecto Google Glass, ¿no? Cualquiera se pone esas gafas y te saca

quién sabe dónde y quién sabe cuándo. Otra idea: se suele hablar de information overlaw. Se ha referido antes Miguel Ángel a ese paso del dato a la información, luego vendría el conocimiento etc. Se suele hablar por lo tanto de information overlaw, pero a lo mejor lo que está pasando es que estamos comenzando a sufrir una intelligence overlaw, es decir una sobrecarga de inteligencia. ¿Por qué? Pues precisamente por esta mayor y mejor capacidad de procesamiento. No es tanto que el Big Data que es este contexto de Internet total en otras expresiones o en otra manera de referirlo, cada vez implique más información. Es que también este Big Data cada vez implica más entrelazamiento de la información y, probablemente, este sea su principal peligro. Esta capacidad, precisamente, es mucho más sofisticada, mucho más afilada, y puede generar dosis de inteligencia muy preocupantes. Léase en el plano público, político, internacional, vigilancia, ciberespionaje, etc. Es un gran asunto sobre el que a lo mejor podemos volver después.

Otro, la business intelligence de las empresas que hace que, por ejemplo, no se queden sin desodorante de tal marca en verano que es justamente cuando hay más demanda. O, incluso, en el ámbito del delito, ¿por qué no? Esta mayor capacidad de procesamiento hace que los delincuentes cada vez sean más inteligentes y podría incluso hablarse de una criminal intelligence o de una inteligencia delictiva. Y, en tercer lugar, también lo mencionaba antes Esther. En el fondo, la intimidad o la privacidad en sentido más... Me gusta más hablar de privacidad, en línea con esa idea tuya Esther de tratar de explorar




nuevos terrenos legales en connivencia con las TIC. Estos terrenos de la privacidad habitualmente han sido considerados, los clásicos lo decían así, el derecho a ser dejado en paz. Probablemente estemos en un contexto en el que ser dejado en paz, creo que lo dabas a entender antes, empieza a ser más difícil. Incluso comentaba antes Esther que a lo mejor tenemos que “renunciar”. Primer factor de leve discrepancia. Yo creo que es bueno que tratemos de conseguir el derecho efectivo a ser dejado en paz, ¿no?

Bien, entro en la tercera parte y, por lo tanto, empiezo a acabar. Solo empiezo, no se hagan demasiadas ilusiones, que ya me lo decía un maestro “cuando veas cansado al auditorio, sobre todo a estas horas, di que empiezas a acabar aunque sea mentira”; en este caso les aseguro que es verdad. Bien, por lo tanto, remedios posibles y solo a lo mejor casi más ideas, más miras, más cargas de profundidad que otra cosa. Pues, hombre, la Comisión empieza hablar –y vuelvo a entroncar con la misma idea que lanzaba Esther– de un Derecho al silencio de los chips. Y lo menciona ella. Por ciento, he tratado de ver qué fuente utilizan y no lo he averiguado. Derecho al silencio de los chips; probablemente sea algo por lo que merezca la pena combatir. En segundo lugar, pues, si cualquiera puede acabar siendo un responsable de datos, en el sentido de nuestra legislación de protección de datos, a lo mejor es bueno que también cualquiera deba ser cada vez más consciente de esas obligaciones que puedan acabar asumiendo. Incluso, en ocasiones, de un modo más o menos inopinable y hasta imprudente respecto de esos datos que haya podido recabar. Si antes hablábamos

del efecto Google Glass, a lo mejor habría que empezar a hablar de efecto Gafas Google, de unas disposiciones sobre datos relativas a las gafas Google, Google Glass provisions, en otras palabras.

Tercero. Mencionaba Esther el hecho de que cada vez estábamos más presentes en línea, la necesidad de empoderar –perdón por el término– al ciudadano en línea. Habría que, a la vez, complementar esa idea, y lo acaba de hacer el Consejo de Europa en un documento que les recomiendo, que es de hace unas semanas, de abril de 2014. Es una guía de Derechos de los usuarios en Internet. Y en esa guía, entre otras muchas cosas, desgrana la necesidad de que el usuario sea diligente. Es algo que se nos viene reiterando sobre todo, por ejemplo, cuando hablamos de Internet y menores, el hecho de que, bueno, seamos cuidadosos. Yo lo llamaría una especie de diligencia de vida digital. Es decir, no nos basta con decir, y entiendo que no nos debe bastar con decir, “hombre, Google protéjame”, “hombre, Estado protéjame”. Yo también me tengo que autoproteger cuando estoy en línea del mismo modo que cuando, a lo mejor, me autoprotejo al evitar ciertas zonas delicadas o peligrosas en una ciudad a ciertas horas, o ambas cosas.

Cuarta idea. Esto puede ser muy polémico. Y fíjate que también lo bordeabas cuando hablabas de que el dato tiene valor. Es que el dato tiene valor, no solamente hablando de identidad digital –tiro aquí de las ideas de Miguel Ángel y también de las de Esther–, tiene un valor económico. Hemos estado acostumbrados a una protección constitucional, internacional, comunitaria




europea, directivas de datos, convenciones del Consejo de Europa, fundamental, interesantísima, pero a lo mejor habría que empezar a pensar, dado que este dato es el nuevo oro negro, como se viene diciendo por ahí en este entorno digital, en otorgar valor a la protección, adicionalmente, y ¡ojo! subrayo adicionalmente. Nunca “en cambio de” o “a reemplazo de” de la protección constitucional que es sagrada, y que debe irse a más en la medida de lo posible, pero a lo mejor suplementariamente pensar en una dimensión estrictamente (es casi pecaminoso, lo que voy a decir), estrictamente patrimonial del dato. Es decir, hacer al ciudadano... hombre, vamos a ver, no las dimensiones estrictamente o exclusivamente personales, ¿no? No el nombre, no el apellido, no el número del DNI. Pero hay cosas en nuestros datos que otros están utilizando, desde un punto de vista estrictamente mercantil y económico, que a lo mejor y aunque solo fuera a efectos de claridad conceptual convendría restablecer respecto de ellas que, el que es propietario, ya no les digo cual es la idea que me lo despertó, fue escuchar hace apenas unos meses a una persona cualificadísima del entorno digital (tanto que no puedo decir quién es, porque dirían muchos de ustedes “ah ya, era tal persona”). Bien, pues esta persona decía, “Claro, porque es que como...” Y era tecnólogo, eso sí. Y eso fue lo que me acentuó más la necesidad de seguir trabajando, y voy a seguir trabajando esta idea, de la posible propiedad patrimonial sobre el dato. Decía “No, claro, es que como el ciudadano es el propietario de los datos”. ¿Cómo que es el propietario? Pues si yo soy el propietario de los datos, entonces realmente la propiedad que estoy disfrutando es

muy sui generis o yo no me he enterado de cómo funciona o, realmente, los que en verdad poseen, y digo “poseen”, es decir los tienen, los usan, a mí muchas cosas que hacen no me las cuentan. Y es evidente que con su casa nadie hace cosas de las que ustedes no se enteren. Con su coche nadie hace cosas de las que ustedes no se enteren. En cambio está sucediendo con los datos.

Y en último lugar, ya que estamos en un contexto de Internet por defecto, es evidente que debe existir –y aquí apelo a los tecnólogos– la privacidad por defecto. Es decir, el hecho de que la privacidad pase a los mecanismos, pase a los dispositivos y pase a los procesos. Estas son ideas que, como saben bien, vienen de Canadá, de hace unos veinte años y son enormemente interesantes, pues tiene cada vez mas predicamento. El nuevo reglamento de datos, por cierto, que entrará en vigor en apenas unos meses, ya la recoge, la privacidad por diseño, la privacidad por defecto, de un modo especialmente resaltado. Esto es lo que quería comentar, aunque luego hablemos de ‘olvido’. Y, por cierto, anticipo: no estoy demasiado de acuerdo con Esther, lo cual puede hacer más divertido el debate. Y odio no estarlo porque claro, además, de ser la única dama, encima que somos juristas y en minoría, ahora se queda Esther en minoría, pues me sabe especialmente mal. Pero bueno, luego ya lo hablamos. Muchas gracias.

Juan López-Rubio FernándezResponsable de iLabs de Innovation 4 Security (I4S)

Buenas tardes. Pues si me permitís, estamos de acuerdo en que estamos en desacuerdo, con




ambos. Yo voy a plantear la postura del tecnólogo. Habéis planteado un montón de ideas interesantes. De hecho, hay varios puntos que me ha gustado oír en boca de un jurista, como es el poner las puertas al campo que decía Esther, o la dejación de derechos hacia el ciudadano, porque al final no podemos legislar contra la estupidez del ciudadano y eso es inherente a la propia persona. Pero ahí yo creo que hay un problema de base en lo que es la legislación en Internet y es que, obviamente, los derechos fundamentales están ahí y hay que respetarlos y son la base jurídica de los países. Y disculpadme, que no soy jurista, pero son la base con la que los países montan su legislación, montan su jurisprudencia, para defender esos derechos. El problema es que Internet no tiene fronteras, o sea, la legislación de un país acaba en sus fronteras y empieza la del país siguiente. Pero Internet no tiene esas fronteras. Entonces, ¿qué legislación me aplican? ¿La de mi país de origen? ¿La del país en la que reside el dato? ¿La del país contra el que estoy accediendo? O sea, si yo desde Francia, como ciudadano español, utilizo unos datos que están alojados en Rusia, ¿cuál es la legislación que me va a afectar? Porque por mucho que nos esforcemos a nivel nacional en hacer unas legislaciones cerradas que permitan proteger al ciudadano en Internet, que busquen su privacidad de datos, siempre va a haber paraísos fiscales, siempre va a haber paraísos digitales en este caso. Y, hablaba ayer el profesor Cabello de los ‘hosting muling probe’, los países en los que, precisamente, no se están respetando los derechos fundamentales, a los que yo como usuario de Internet tengo acceso en un clic. O sea, antes si yo me quería ir a las Islas Caimán tenía complicación para llegar allí; pero

ahora si quiero contratar un servicio de hacking, o un servicio que pueda utilizar como base para una botnet para atacar a ciudadanos de otros países, con un clic desde cualquier sitio llego. Y eso que no hay ningún, como decías tú, Big Brother, no hay ningún gobierno, no hay ningún organismo que regule eso y que vele por esos Derechos de los ciudadanos en el Internet general. Hay organismos de estandarización, o sea, de cuestiones técnicas. Nadie, el propio país sí, pero nadie a escala global defiende al ciudadano dentro de Internet. Esta era la idea que quería lanzar.

Esther González Hernández. Es que tenemos Pablo y yo un papel malísimo, la verdad. Efectivamente, y contestando a los dos compañeros: muchas de las cuestiones que me decía Pablo que he rozado, claro, es que llega un momento ee que quieres hablar de tantas cosas que tienes que elegir. La vida es así, hay que elegir y con el tema que comentaba Pablo del derecho a ser dejado en paz, yo efectivamente coincido. Creo que hay una idea que se impone. La realidad es que es difícil pero yo coincido con Pablo en que hay que seguir intentándolo. Quiero decir que, efectivamente, la tecnología –y vuelvo a la última idea que era para mí la fundamental– está hecha para las personas y para que las personas la disfrutemos. Y lo que las personas podemos hacer, en el uso de nuestra libertad, es decidir que no queremos hacer uso de determinadas cuestiones o que no queremos que se nos moleste con determinadas cuestiones.

También me preguntaba Pablo si deberíamos hablar de una nueva categoría de derechos. Yo, sobre esto, he pensado muchísimo estos días; no




sé, todavía no tengo una respuesta exacta. Desde luego, lo que yo sí que creo es que, y coincido con Pablo lo que dice ahí, hay que encajarlo en la última categoría de derechos, la que poníamos en el slide. Estos derechos de tercera generación no sirven. Los derechos de tercera generación no son auténticos derechos públicos subjetivos que permiten al ciudadano ejercer determinadas facultades o exigir determinadas facultades. No te permiten ir a un tribunal y decirle “Oiga, a tal buscador, dígale que quite esta información”. Yo creo que, como mínimo, habría que hablar de una tercera generación de derechos públicos subjetivos. No sé si dentro, como una subcategoría, de lo que es la consideración de derechos públicos subjetivos, porque lo que me planteaba también estos días es si este elemento externo que en la Tecnología tiene suficiente fuerza externa como para crear una nueva categoría jurídica. Sobre todo, porque luego son tantas las situaciones de conflicto, tan variopintas, tan variadas, que no lo sé. Lo que sí pienso es que deberíamos empezar a reconsiderar y a replantear que efectivamente estamos ante una nueva realidad, que las Nuevas Tecnologías están, que el mundo es completamente diferente por mucho que digamos que no lo es. Las personas que no son muy hábiles en tecnología, como yo, al final terminan sucumbiendo y aprendiendo y terminan haciendo uso. Y respecto a lo que comentabas, efectivamente o también me he planteado el criterio de la territorialidad y cuando hablaba por ejemplo de la comunidad Facebook, efectivamente es que ahí está el problema. Ahí está la madre del cordero. Aunque sea una expresión muy coloquial. ¿Qué legislación se

aplica? De esto concretamente sabe muchísimo más Pablo que yo.

Luis Saiz. Yo añadiría una cosa a lo que decía Juan: ¿existe derecho si no puede ser aplicado? ¿Existe algún tipo de derecho si luego no lo puedes aplicar?

Esther González Hernández. Sí, existe; de hecho hay muchos ejemplos. El ordenamiento jurídico está lleno de ejemplos de derechos que no se aplican, sobre todo si hablamos de Derecho Constitucional.

Miguel Ángel Cano. Por eso en el planteamiento inicial yo ponía el enfoque de que un ciudadano tiene derechos cuando tiene un ordenamiento jurídico en el que esta circunscrito por tener una identidad dentro de un Estado. En Internet no tengo Estado. Llamamos identidad a lo que hay en Facebook, yo tengo quince cuentas en Facebook y soy de todas las edades de todos los sexos y de todas las religiones... Entonces, si estamos en un mundo tan ambiguo, totalmente de acuerdo en que haya una nueva rama de Derecho. Y aquí esta la complicación. ¿Hablar de Derecho Digital nos parece que es como hablar del Derecho Natural? Que está muy bien. Pero que se lo digan al de ahí abajo que va a cruzar Ceuta o Melilla, o a Italia. ¿Qué es inherente al ser humano? Lo es, pero es que no hay un ser humano, ¿eh? Aquí hablamos de procesos.

Pablo García Mexía. Esther, a mí esto me recuerda a un tercer grado. Tenían que haberme avisado mi amiga Elena y los organizadores y haberme dicho: “Mira, este es en un foro de tecnólogos, y estarás




en un debate de tecnólogos que te apuntarán y te dispararán”. Es broma. Yo venía preparado.

Quiero centrarme en dos bloques de asuntos. Uno. el que comentaba Esther al final, Luis también y Miguel Ángel en el arranque, que es el de la jurisdicción en el fondo. Hasta qué punto el hecho de que esto sea una red global, además tiene que ser global porque es descentralizada, que os voy a contar, el extremo a extremo justamente está en la base y condiciona precisamente nuestro trabajo como juristas, después. Son accesibles desde cualquier lugar y en cualquier momento. Bueno, posibilidades que tendríamos para resolver el problema. Pues básicamente dos. Una que es la ideal. Vamos a ver, probablemente muchos de ustedes habrán pensando en ello, muy probablemente Esther igual: pues hombre si esto es global, como es Internacional, pues Derecho Internacional. Es decir, hacemos un Tratado, nos sentamos todos los señores del mundo con los gobiernos correspondientes y llegamos al acuerdo de que se trate. Por ejemplo, expresión en la Red, olvido, privacidad..., lo que fuere..., delitos, comercio electrónico, propiedad intelectual, enlaces; luego si queréis vamos a eso, pero vamos, es otra cosa, es sobre todo propiedad intelectual. Bien, ¿solución? Ya está, facilísimo. Vale, vamos a ponerlo en práctica: lo bajamos a la tierra, que diríais también vosotros los tecnólogos, y lo ponemos a trabajar y sentamos en una mesa a China con Rusia, con España, con Portugal, con Francia, con Sudáfrica, con Corea del Norte, con Cuba, con Arabia Saudita, con Irán… Y, rápidamente, llegamos a un acuerdo para regular sin problema alguno la libre expresión en la Red. Por lo tanto, opción A perfectamente

ideal, pero perfectamente quimérica. “Hombre”, diréis “hay tratados”. Los hay, pero en realidad son la excepción que confirma la regla. Se pueden contar con los dedos de una mano y media. Hay uno muy importante sobre ciberdelito que tiene alcance europeo, que es el Convenio del Consejo de Europa. Hay un par de cosas sobre propiedad intelectual que elaboró la Organización de Propiedad Intelectual en el año noventa y tantos, al hilo de la irrupción de la Red, que era imparable. Hay otro documento que es mas código modelo que otra cosa; más que Derecho es una aproximación, una orientación que procede de la Organización Mundial del Comercio. Y no hay mucho más. Dirán “no, pero la Unión Europea”. La Unión Europea no es internacional. La Unión Europea es nuestra casa. Igual que esta es la casa de Esther y un poco también nuestra. La Unión Europea es nuestro entorno. De hecho, España no tiene margen de maniobra alguno en estos temas. Recuerdo a Miguel Roca i Junyent, al político catalán, comentado hace unos años “No, es que ni Cataluña...” Cataluña evidentemente no y Murcia tampoco, pero es que ni España. España no esta trazando políticas autónomas en materia de Internet, ni normas, ni esta redactando normas en materia de Internet y TICs desde hace muchísimos años porque es que no tiene margen de maniobra. Todas las importantes se encastran en el ámbito de la Unión Europea; por tanto, eso es Derecho Interno, con matices, pero Derecho Interno. Así pues, vía uno, la ideal pero realmente muy difícil de poner en práctica, aunque haya que seguir avanzado.

¿Y la otra vía? Pues esto lo aprendí de un profesor de Pensilvania al que la verdad es un honor citar




porque escribió, además, un libro memorable en el año 2009. Este profesor decía, “Hombre, a mi esto me recuerda al juego del ratón y el gato”. Y qué razón tenía porque, claro, yo puedo decir “bien si tengo a la persona...”, un delincuente en línea, un phisher de estos, lo pillo aquí. Asunto resuelto. “Vale, no le pillo a él pero pillo sus bienes”. Asunto resuelto, también. Vale ni bien, ni persona, pero tengo un tratado de extradición. Bien y, qué pasa si no hay tratado de extradición porque con las Islas Tonga puede no haberlo, qué pasa si no pillo al señor y qué pasa si no pillo los bienes o no trabo los bienes. Pues que se ha perpetrado la injusticia. Por lo tanto, la solución que podría ser en principio más realista es en cambio la más injusta en muchas ocasiones. Y aquí es donde llega la frustración. Y les tengo que confesar, incluso, que aquí la siento yo también. Esta misma mañana, en la Universidad, hablando a los alumnos de estos temas, pues lo he dicho: “Chicos, para esto las soluciones son muy complejas”. Luego ya sí se ha hablado del establecimiento de los datos, se ha hablado de criterios, pues lo que quieran y de hecho, ¿qué es lo que se suele hacer? Pues, al final, aplicar los criterios de la Normativa General, que en ocasiones en Derecho Internacional privado nos da soluciones, por ejemplo, la Normativa de datos, y me quedo ahí. Dice: si alguien que maneja datos de un tercero, por ejemplo Google y la famosa sentencia del olvido, tiene un establecimiento en España pues ya está en territorio de la Unión Europea. Arreglado. Y, de hecho, la sentencia va ahí, y en eso sí que estoy de acuerdo con la sentencia. La sentencia, dice Google, es verdad que no toca el indexador y, por lo tanto, no toca el motor de búsqueda, no toca molla tecnológica en España.

Pero sí toca molla comercial porque, justamente, su oficina en España se ocupa de gestionar los adwords, lo que supone el noventa y tantos por ciento de los ingresos de Google. Por lo tanto, tiene un establecimiento en España. Aunque solo sea a efectos comerciales, que no tecnológicos. Por lo tanto, perfectamente se le puede aplicar y se le debe aplicar la legislación. A veces, se aplica, por ejemplo, un criterio que a mí me gusta mucho más que este, que es mucho más justo y que tiene mucho más en cuenta la naturaleza de Internet y es que se esté dirigiendo alguien a un determinado público objetivo. Lo dabas a entender antes. Hombre, si yo quiero vender flores y estoy basado en Nueva York pero resulta que me quiero dirigir al público inglés y empiezo a venderles por Internet flores, –a diferencia de lo que algún Tribunal, por ejemplo inglés, es un caso real, ha fallado– pues parece que es razonable pensar que la legislación del Reino Unido se le debe aplicar porque usted está dirigiéndose justamente como público objetivo al público británico. Bien, esto en cuanto a otros criterios que se podrían añadir a los que, como digo, legalmente se deben también aplicar y que en el fondo llevan a que sea la legislación nacional la que prime, dado que los tratados están muy reducidos en su ámbito. Y luego ya vendría todo el tema del olvido, que también ha quedado antes trazado.

Sobre el olvido tengo que mencionar dos aspectos. Yo coincido con Esther en que la sentencia es buena. Uno el que he mencionado: el hecho de que Google trata datos en España, y por lo tanto se le debe aplicar la legislación de datos europea y española que la desarrolla. En segundo lugar, el hecho de que trate datos. Un




indexador trata datos, maneja información. La legislación europea es tan amplia –cuando digo europea digo española porque la ley española no concreta nada más–. En realidad, lo único que hace es desarrollar de un modo prácticamente mimético lo que dice la directiva del año ‘95, ¿no? Fíjense que, incluso, la legislación de datos, a partir de ahora, en Europa, va a ser regulada a través de un reglamento. Con lo cual, el margen de maniobra que tenían los Estados a través de una directiva de ir concretando, ni siquiera lo van a tener ahora. Ya es un reglamento y a la letra se le debe aplicar dentro de unos meses en toda Europa. Por lo tanto, el margen de maniobra que ahí tenía el Tribunal era muy escaso. Google trata datos respecto de un territorio determinado y, además, trata datos. Y esto creo que es poco discutible porque, como digo, las definiciones de las legislaciones de la Unión Europea son muy amplias. Por lo que parece prácticamente imposible que el Tribunal hubiera fallado de un modo diferente.

En cambio, donde sí discrepo es en la molla de la sentencia, en el núcleo, Y además, me duele la sentencia porque se aparta de un modo radical de lo que fueron las conclusiones del abogado general. Estoy incluso pensando traerlo a España (no sé, en algún foro a lo mejor lanzo la idea), si queréis al año que viene, porque me parece casi un héroe este señor, el finlandés Leskinen, que hacía un análisis francamente bueno, porque descendía a lo que es Internet. Yo sé que esto probablemente gusta oírlo a los de tecnologías, y es que es así. Es decir, entiende perfectamente el abogado general lo que es la Red, cómo funciona desde el punto de vista tecnológico y, sobre

todo, el hecho de que, en ocasiones, al tratar el buscador determinada información es frecuente que pueda entrar en conflicto esa información con una libertad que es capital, que es la libertad de información y que es el derecho a la libre expresión. Fíjense que el abogado general en las conclusiones que elabora llega incluso a hablar de censura. Y lo hace dos veces. Y, claramente, viene a decir “si Google se mete por medio y Google empieza como tercero en discordia recibiendo quejas de personas que puedan estar damnificadas y, anticipo, el mayor de los respetos, o la mayor de la sensibilidad es hacia las personas que en ocasiones están expuestas; yo lo puedo estar mañana. Cualquiera de ustedes me podría demandar mañana. Oiga, ¿no era usted el que era tan proclive a la libre expresión, en contra del derecho al olvido? Pues ahora lo está sufriendo y casi lo merece”. Probablemente, lo merezca. Es verdad que es muy difícil en ocasiones trazar ese equilibrio entre expresión, libre información y derecho a la intimidad o a la privacidad, que pueda derivarse del daño que, en ocasiones, es enorme, lo repito, que pueda estar sufriendo alguien; pensemos incluso en un menor, que a lo mejor de por vida va a ver como ese buscador... Por cierto, lanzo de soslayo una pregunta a los tecnólogos: Realmente sacar esto es siquiera tecnológicamente viable. O no me he enterado de nada si a lo largo de estos años que se ha estado amasando este problema he estado escuchando de vosotros que realmente los robots lo van a volver a encontrar. O estoy yo errado.

Luis Saiz. ¿Si no lo han borrado en origen? Ni lo borran en origen, ni indican que no se indexe, que también lo puedes poner. Técnicamente es




posible poner “esto no se indexa”. Ninguna de las dos cosas. Ese es el tema que desde la parte tecnológica nos chirría. Si tienes capacidad... Porque creo que era un medio de comunicación español... Si al medio de comunicación español, con jurisdicción española, no se le puede obligar a que retire, ni si quiera a que ponga que no se indexe. Y, en cambio, el que realiza la indexación sí, eso es lo que nos descuadra totalmente.

Pablo García Mexía. De hecho, esa es otra idea clave de la sentencia o, más que idea clave, es una consecuencia que no sé si está deliberadamente asumida por la sentencia o no. Y es que han trasformado a Google de la noche a la mañana, sabemos que hay varios turnos para acceder a la judicatura, uno es la oposición; luego está el llamado cuarto turno, que consiste en que cuando tienes una trayectoria dilatada, pues por ejemplo una persona de reconocido prestigio... Esther es un caso. Esther mañana podría ser juez. Y ahora está el quinto turno. Es decir, que han trasformado a Google en un juez que va a tener que dilucidar si una información pesa o no más que un determinado dato que, por cierto, no es que sea erróneo, ni que sea incierto, es que es el problema de todo esto. Es que son datos que es verdad que han podido perder actualidad; pero claro, por otro lado este es otro problema, ¿quién es Google para decir si un dato ha perdido o no actualidad cuando resulta que la fuente originaria fue la que lo subió a la Red? Ejemplo de Costeja: “No, es que era una multa a la seguridad social; entonces, claro, esto ya está pagado”. Perfecto. Pero es La Vanguardia la que sabe realmente si esto ha perdido actualidad o no. ¿Quién es Google para decir que esto ha

perdido actualidad? Pues igual sí o igual no. Y paradoja final, que evidentemente supongo que el Tribunal ni se planteó: es que puede acabar ocurriendo incluso que Google termine siendo demandada por un tercero que considere que ha sido censurado por el propio Google. Porque, claro, cuando llega Google y hace de juez, como no son jueces, porque ellos mismos lo tienen en su lema: “yo es que hago búsquedas”. Ahora tendrán a lo mejor que decir “yo hago búsquedas y no me queda mas remedio que también ser juez”. Pero es que puede llegar un tercero, al que le han quitado la información, y demandar a Google porque les está censurando. Este, que es un supuesto de laboratorio hoy, mañana puede ser real.

Esther González. Coincido con los últimos temas que ha planteado Pablo y, simplemente, quiero matizar. Yo me he limitado a exponer lo que dice la sentencia y sí que creo, si no lo he hecho antes lo explico ahora, que efectivamente ahí está uno de los problemas: que la información es pública. Cuando hablaba del concepto de información pública libre desde el punto de vista del Constitucional, hay que tener muchísimo cuidado con estas cosas porque, desde luego, los derechos a la información y a la libertad de expresión también existen. Y hay que tener en cuenta lo que los juristas llamamos criterio de ponderación. Es decir, hay que balancear cuándo efectivamente estamos hablando de privacidad y cuándo estamos hablando de un derecho a la información que se situaría por encima de ese derecho a la privacidad, en la conformación de esa opinión pública libre, de esa masa crítica libre. De crítica... bueno, pues desde actuaciones del




Gobierno, de cualquier otro tipo de información que de facto sea relevante, que es lo que yo planteaba. ¿Cuándo la información es relevante y cuándo no lo es? Porque podemos tener el riesgo, que es lo que decía Pablo, o lo que también apuntaba Miguel Ángel, de que al final empiecen a plantear demandas de quite usted esto, quite usted aquello, que luego puede tener cierto interés a la hora de… Todos lo sabemos, investigas y encuentras determinados supuestos en que están implicados, desde casos de corrupción, de cibercrimen, etc. Lo que sí me gustaría matizar es que, efectivamente, el derecho al olvido tiene que ser proporcionado y tiene que estar bien circunscrito, que creo que ese es el campo que tenemos que hacer los juristas: circunscribir y llegar a ese contenido mínimo irrenunciable pero que permita la vigencia de los Derechos de la información y a la libertad de expresión.

Juan López-Rubio. De hecho en ese sentido Pablo, en su primera intervención, apuntaba algo importante, que es el concepto del usuario diligente. No solo desde el punto de vista del que siempre hablamos de concienciación del usuario, de enseñar al usuario en Internet, pensamos en un usuario consumidor de datos. Pero Internet no es solo consumo de datos, sino la generación de los datos y los ejemplos que estás dando tú son claros. Esos sitios web de terceros, que ponen una serie de datos públicos, por ejemplo: una universidad que cuelga las actas de una asignatura pública (que eso me ha pasado; no la busquéis, por favor); antes de que estuviese consagrada la de privacidad era muy normal poner un acta de notas pública. Ese usuario que está poniendo esas actas no es un usuario

concienciado. Está poniendo información de un tercero. Entonces, que Google le indexe y la presente al final no es culpa de Google, es de ese usuario. Por lo que al final volvemos a qué va antes, si el huevo o la gallina: ¿la generación de la información, el ser consciente y responsable a la hora de poner, de crear, de generar, esa información (cosa que obviamente no se puede controlar a lo largo de la red), o el castigo, el derecho al olvido, la búsqueda de ese abuso de información? Al final podemos estar dándole vueltas al mismo concepto todo el tiempo, pero se basa siempre en lo mismo, en un uso y consumo responsable de esa información.

Miguel Ángel Cano. Ha sido muy interesante, pero tenemos que dar por finalizado el debate.

Santiago Moral Rubio, (Director de IT Risk, Fraud & Security de BBVA). Muchas gracias. Ha habido varias ideas que no han terminado de surgir, que teníamos cierta esperanza de que llegaran, las dejo simplemente apuntadas. La primera es: posiblemente el ciudadano ha decidido no vivir bajo vuestra jurisprudencia. Mi hija ya ha decidido hace mucho tiempo que no va a visitar ningún sitio tan protegido, no quiere estar en ningún sitio donde la protejan tanto. Tiene 14 años y, como el resto de todos nosotros, raramente navega por ningún sitio que tenga jurisprudencia de protección. Estamos siempre en sitios estadounidenses que carecen de ese tipo de jurisprudencia. Por lo cual, el ciudadano ya ha decidido. Y el ciudadano está decidiendo qué tipo de protección quiere, y quiere la que quiere. Y cuando el Estado decide lo contrario, pues es otro tipo de Estado. Por ello hay que




tener cuidado, hay un sesgo ahí muy interesante en los debates, porque el ciudadano ya está tomando su decisión.

Hay una segunda visión con respecto a la protección europea del ciudadano, y es que el Estado le protege a través de las empresas, regulando la actividad con el ciudadano. Eso sucede cuando está geolocalizado; pero cuando no está geolocalizado el ciudadano está hoy trabajando al 99,999999%... solo con empresas estadounidenses. No hay que irse a Tombuctú. Es Estados Unidos y no quiere esa regulación europea...

Y enlazo con la tercera idea: ¿es casual que el que triunfa no tenga ese tipo de regulación? ¿Es una casualidad? Porque ha habido un detalle muy interesante en todas las intervenciones, y es que estáis hablando de la tercera generación de Derecho que tiene que ver con la administración. Internet es privada. No es un espacio público. No hay nada público en Internet. Es una cosa financiada por empresas privadas, pagado por empresas privadas, y usado de forma privada. No es un espacio público. Hay que tener cuidado. Los sajones tienen claro que se basa de relaciones entre particulares o entre empresas fuera del Derecho y enmarcado en los usos de la Common Law. No es la calle, Internet no es la calle. Está financiado por unas empresas. Es un sitio privado. Entonces todas esas formas legislativas estadounidenses les permiten una orientación, y en Europa llevamos otra. Empiezan a alzarse voces que manifiestan que Europa se

haya quedado completamente fuera de Internet, porque no provee ningún servicio, tiene cierta relación con un regusto... eh, un poco fino de estar pendiente de unos derechos públicos en un entorno que no es público. Y eso nos tiene algo despistados y está echando hacia fuera inversiones.

El caso de Google en España es un ejemplo que se ve a nivel internacional en lo que se refiere a cuáles son los costes y los peligros de venir a hacer negocios en Internet en Europa. Y es malo porque yo desde cualquier parte del mundo puedo publicar... desde Estados Unidos, no me tengo que ir a China, y puedo hacer negocios con legislación estadounidense; pero vengo a Europa y tengo una complicación inmensa. Eso está sesgando el debate y ya hay quienes opinan que no es tan transparente el estilo continental y que el estilo legislativo europeo en Internet tiene alguna relación con la falta de capacidad de triunfo de nuestras empresas en Internet.

Quiero agradecer a todos vuestra participación, y especialmente a los juristas por haberos batido con bravura ante esta manada de lobos tecnológicos. Como director de este curso os lo agradezco de veras. Vuestra aportación ha sido, aparte de brillante, interesantísima. Os instamos a que participéis en la siguiente edición con más tiempo. Tomo el guante para que le dediquemos una mañana completa y un espacio de debate más preparado y con más juristas, porque sus ideas nos interesan mucho.




Buenos días. Mi nombre es Sean. Dejadme que os muestre mi presentación aquí [en la pantalla]. Bien, me gustaría hablar sobre la

detección de anomalías en Apache Spark. Mucha gente de la sala trabaja en seguridad por lo que, probablemente, no tengo mucho que enseñaros sobre detección de anomalías, ya que habéis estado haciendo esto un tiempo. Pero quería que fuera una excusa para introducir Apache Spark. Es un nuevo, y creo que emocionante, marco de trabajo en la parte superior del ecosistema de Apache Hadoop. Para la gente interesada en machine learning creo que ofrece un modelo de programación

sencillo y ofrece, quizás, más rendimiento para algoritmos iterativos. Y algunos algoritmos de entrenamiento para la detección de anomalías son iterativos. Por último, pero no por ello menos importante, Spark incluye algunas implementaciones de estos algoritmos clave. Así que, en esta presentación, en alrededor de 45 minutos quiero profundizar y mostraros algo de código, por lo que será algo técnica. Pero quiero enseñaros cómo se utiliza Spark, cómo es el código y cómo son sus principios. Además, a lo largo de la ponencia os presentaré algunas ideas básicas dentro de la detección de anomalías, al menos, para aquellos que no trabajan en este campo.

DETECCIÓN DE ANOMALÍAS CON APACHE SPARK

Sean OwenDirector de Data Science Cloudera, Londres





Para mí, la detección de anomalías trata sobre decidir qué es inusual, y es complicado saberlo. Por ejemplo, puede que tenga un grupo de transacciones bancarias en la tarjeta de crédito y me gustaría saber si son fraudulentas o no. Simplemente no se asemejan a otras transacciones realizadas. Por lo que es un problema encontrar aquello que no se conoce, las cosas que no sé que son malas, solo que son diferentes al resto. Algunas veces tengo etiquetas, otras no. Por ejemplo, en algunos casos sobre fraudes a tarjetas de crédito tengo ejemplos donde sabía que la actividad había sido fraudulenta, pero en otros casos no los tengo. Y para los nuevos ataques y los nuevos tipos de fraude no sé necesariamente cómo son antes de tiempo. Una aproximación básica a la detección de anomalías a través de machine learning es utilizar alguna clase de estimación de la identidad o, más concretamente, un algoritmo de clustering que agrupa la actividad en el pasado. Y no nos importan mucho los clústeres en sí, nos importa dónde no están los clústeres. Así que los puntos que van juntos, no sabemos si indican fraude o no pero, al menos, sabemos que representan actividades normales. Pero si los puntos se ubican dispersos alrededor de un espacio, representan otro clúster que está cerca de otra actividad y éstos son lo que pueden ser inusuales, son los valores atípicos. Vamos a utilizar esta aproximación para definir qué puntos podrían ser potencialmente anómalos. Por ejemplo, en este caso, los puntos rojos que se esparcen alrededor deberían de ser aquellos que queremos investigar, manualmente, para ver si son fraudulentos.

En este ejemplo voy a hablar de un algoritmo

básico de clústeres llamado ‘k-means++ clutering’. Es sencillo, muy popular, de asignación iterativa de puntos a un clúster, de actualización en el clustering, y que van y vienen. Así que, es iterativo. Creo que muchos de vosotros en la sala estáis familiarizados con esto, y lo que va a intentar hacer es tratar de poner los centros de los clústeres cerca de los grupos de puntos, por lo que volveremos a esto más tarde.

Bien, el data set de hoy no es un conjunto de datos mío, es el data set del reto KDD Cup Challenge de 1999. La KDD Cup es una competición anual de machine learning cuyo tema, en 1999, fue la ‘Detección de Intrusiones en la Red’. Se les dio a los participantes un conjunto de datos de conexiones TCP, había unas 4,9 millones de estadísticas de conexión TCP, y se les pidió construir un modelo base sobre este conjunto de datos con el objetivo de decidir cuándo algunas de las actividades en las sesiones parecían ataques o podrían serlo. Así es como ese data set se presentó y, por cierto, esto no sirve para construir un modelo de detección de intrusión real. Todo esto está desactualizado pero es interesante como ejemplo. Así es como el conjunto de datos se mostró. [Imagen en la pantalla] Los campos no son en realidad muy importantes, no os preocupéis por eso. Se les dio una sesión con el protocolo, la aplicación, creo que el estado del TCP final de bytes enviados y recibidos, y un montón de estadísticas acerca de la sesión... creo que los ratios de recibidos... algo así, los detalles no importan. Y en esta ocasión, se dieron etiquetas (labels). Esta sesión en particular está etiquetada como ‘Normal’, se ha conocido por no tener un ataque. No siempre tendremos




algo como esto y, en realidad, empezaríamos sin usar etiquetas pero, en este caso, se les dieron etiquetas a los participantes. Perdón, en realidad quería presentar esta transparencia.

Así que, ¿qué es Spark? ¿Podría preguntar quién en la sala utiliza Apache Hadoop? ¿Alguien? Bueno, puede que uno o dos usuarios... Entonces, puede que Spark no os sea muy familiar. Bien, Hadoop es una infraestructura de código abierto para almacenar y procesar gran cantidad de datos. Y, Spark es... podéis pensar en ello como una aplicación por encima que ofrece una manera de expresar la computación sobre el clúster de Hadoop e, incluso, provee algunas implementaciones de machine learning encima de este mismo framework. No necesitáis un Spark, no necesitáis un Hadoop, pero os enseñaré un poco de Spark para que os llevéis una buena impresión. Spark en sí proviene de UC Berkeley. Es un proyecto académico, ahora es un proyecto de Apache. Está basado en Scala, por lo que si alguien en esta sala es programador Java, Scala os resultara algo familiar desde que es un lenguaje basado en JVM, pero está escrito en Scala, no en Java o Python. Se muestra en colecciones distribuidas, API, sobre tus datos, por lo que si pones en Spark un archivo de texto grande, de unos cuantos terabytes, piensa que es un conjunto de cadenas de líneas y puedes poner operaciones y transformaciones sobre este conjunto de datos y Spark se hará cargo de su cálculo. Veremos algunos ejemplos del CPI en un momento. Algunas de las razones por las que me gusta Spark es que incluye REPL interactivo, Read Evaluate Print Loop. No es solo una librería sobre la que puedes construir aplicaciones, es algo que puedes ejecutarlo en shell y teclearlo de forma

interactiva. Y, normalmente, en una demostración como ésta teclearía en el shell en directo para que veáis qué es lo que pasa pero no quiero hacerlo hoy por problemas de tiempo. Y por supuesto, es distribuido, es compatible con Hadoop, por lo que si tienes tus datos en Hadoop, si ya tienes un clúster de Hadoop, instala Spark y ejecútalo encima: no necesitas invertir en un clúster o en un gestor de clústeres.

¿Qué pasa si intentamos clusterizar estos datos directamente? ¿Qué pasa? Bueno, aquí tenéis vuestra primera cata del Spark. [Aparece una transparencia con una imagen]. Esto es algo que he tecleado en el REPL, el shell. Es un texto que he probado, un archivo de texto, en HDFS, en mi directorio que contiene todos estos datos. Bueno, realmente no pasa nada cuando introduces esto porque, antes de hacer nada, solo he preguntado por una referencia al fichero. Es solo cuando invoco una acción como “cuenta en esta colección de cadenas” cuando muestra una acción contando líneas de forma distribuida, por lo que veréis más outputs. Al final, volverá a alrededor de 4,9 millones. Así, aquí ha contado las líneas del fichero. Eso es todo lo que hice.

Ahora, para empezar voy a ignorar un par de cosas en el data set (o conjunto de datos): voy a ignorar las etiquetas y las características no numéricas. Por lo que nos vamos a basar en las características numéricas del clúster. Parte de esto es el k-means, este algoritmo que vamos a utilizar por naturaleza solo coge valores de entradas numéricas, vectores de características. Así que, volveremos a ello más tarde.




Bien, aquí tenemos un poco de Scala y código de Spark. Los detalles no importan, sólo quiero enseñaros qué apariencia tiene. Éste es un ejemplo de captura de datos en bruto, una colección de cadenas y mapeo que realmente cambia cada línea en una estructura de datos diferentes. Lo que he hecho ha sido introducirlo, dividirlo por comas y quitar algunos otros campos y lo que devuelve es un tuple, un par de características numéricas, un conjunto de valores de dobles puntos flotantes y la etiqueta. No voy a utilizar la etiqueta aún, pero esto es lo que nos devuelve. Lo que he obtenido es otra colección distribuida, un tuple, no cadenas (string). Así es cómo Spark y casi toda la colección de APIs de Scala trabaja. Así que, cogemos los datos, solo la primera parte de cada tuple y lo cachea en la memoria. Ésta es la razón por la que Spark va tan rápido. Por naturaleza, Spark va a utilizar la memoria y el disco para almacenar tu colección distribuida pero puedes sugerirle o forzarle para que mantenga todo el conjunto de datos en memoria. Esto es algo que te ayudará porque puede leerlo una y otra vez. Dejadme que siga con un par de puntos aquí. Aquí tenemos a Spark en acción. De hecho, esto es todo lo que necesitarás para ejecutar el clúster en Spark. He importado las implementaciones de k-means de MLlib dentro de Spark y le he dicho que construya un modelo sobre los datos. Por lo que, ahora tú manejas la colección distribuida de dobles valores y él hace el resto. Aquí, coge todos los centros del clúster del modelo y los imprime. Esto es básicamente que está trayendo los centroids. Podría, incluso, si quisiera, sacar cada punto de datos y proyectar su clúster para diseñar un clúster, pero eso es

con una etiqueta. Finalmente, solo ha cogido esta colección de clústeres y etiquetas y calcula. Cuenta el número de veces que cada clúster contiene una etiqueta. Puede que esto nos ayude a entender qué pasa aquí. Por lo que voy a saltar a la última línea: clúster, etiqueta, contar. Esto es lo que pasa. [Pasa a la siguiente transparencia]. Bueno, esto no funcionó del todo. Dejadme que os ayude a entender por qué. He comentado que en cada clúster había solo dos clústeres asignados, y uno de ellos solo tenía un punto de datos asignado. Así que, me temo que esto no funcionó del todo. Todo fue asignado al clúster 0. Bien, esto no funcionó, es terrible.

Uno de los problemas es que no dimos un valor ‘k’, no dijimos cuántos clústeres queríamos instalar. Este es verdaderamente un conjunto de datos muy complicado. Probablemente no se va a descomponer en clústeres, por lo que necesitábamos establecer el valor ‘k’ de forma diferente y esto es para que el número de clústeres sea asignado. El problema es que realmente no sabíamos que ‘k’ se suponía que tenía que ser, 10, 100, 1000... Bien, puede que podamos utilizar un clúster para que lo averigüe por nosotros, probando un montón de valores. El que he cogido parece ser el mejor. Así que aquí estamos otra vez, he definido una función de distancia en arrays de dobles ‘Array[Double]’. Esto es justo lo que se llama la distancia euclidiana. Incluso si no conocéis Scala, creo que podéis analizar qué pasa aquí. He cogido dos arrays de dobles, los he puesto juntos, he cogido las diferencias de los pares, los he cuadrado, los he sumado, y he cogido el cuadrado del grupo. Esto es la distancia euclidiana. Buena y precisa. Scala puede ser algo más complicado de




procesar al principio. Y lo que he hecho es definir un resultado que decida qué bueno es un clúster. Así que, he dicho que un clustering es bueno si todos los puntos están bastante cerca del clúster más cercano. La idea es que todos terminen cerca del centro del clustering y no lejos de él. Así que, aquí he definido un método que coge la ‘k’, establece un valor a ‘k’ y ejecuta el modelo. Entonces, por cada punto de datos encuentra los centroids más cercanos y la distancia entre ellos, y lo añade. Este va a ser mi resultado para ese valor ‘k’. Un valor bajo es mejor. Esto significaría que mis puntos están más cerca de sus clústeres. Así que lo que voy a hacer es coger los valores 5, 10, 15, 20... y paralelamente, ejecutar este modelo, y obtendré ‘k’ más el resultado. Eso me dará un sentido de cuál es el valor de ‘k’ que debería ser, que me debería de funcionar bien. Si haces esto... bueno, debería decir que tarda un poco de tiempo, puede que tarde unos minutos. Durante ese tiempo, puedes ir a este máster de Spark y mirar la aplicación. Esta es la parte que realmente me gusta. Puedes ver la acción que se ejecuta. Muestra las partes de la computación que son necesarias, las tareas en el UI. Puedes ver cada acción de la computación completa. Incluso, puedes verlo por número de línea. Sigue siendo complicado este tipo de programas distribuidos pero, al menos, cuáles por número de línea están invocando las operaciones distribuidas, cuáles tardan más, cuantos datos están saliendo tanto si están en memoria, como si no. Así que, es más que teclear código en el shell. Tienes panel UI de administración razonablemente bueno en Spark. Bueno, esto es lo que obtengo si imprimo el resultado, es decir, el último test. Así que aquí tenemos ‘k’ y el resultado que es la suma de

distancias de puntos a los clústeres más cercanos. A medida que ‘k’ crece, el número va bajando. Esto es bueno pero no es sorprendente en sí. Si he establecido ‘k’ al número de puntos de datos en todo el conjunto de datos el valor debería de ser 0. Cada punto debería estar en su propio clúster. Por lo que no se trata tanto de encontrar el valor más bajo sino de dónde parece que el valor está parando de descender. Estamos buscando esos puntos en esta gráfica. Allí donde ‘k’ se incrementa no deja caer la puntuación mucho más. Para mí, aquí no está claro cuál es el punto más bajo. Sigue bajando muy rápido cuando paso 40 por lo que, probablemente, el número ‘k’ correcto es más alto que 40. Y hay otro problema aquí: ni siquiera tiene un decrecimiento estricto. Por ejemplo, y de hecho, va hacia arriba al pasar de 25 a 30. Y eso no debería pasar. No debería ser posible en algún sentido. El problema aquí comienza en un punto aleatorio, en una solución aleatoria. Alterando esa aleatoriedad puedes crear una solución mejor o peor cada vez que la ejecutas. Así que, necesitamos arreglar eso, podemos tener esta aleatoriedad. No podemos quitar esa aleatoriedad pero, al menos, podríamos ejecutarla muchas veces. También podemos pedir al algoritmo que tarde más en ejecutar para poder converger estos puntos, estos clústeres, un poco mejor. Así que voy a ejecutar el mismo experimento otra vez, pero voy a establecer el numero de ejecuciones a 10. Es decir, ahora, por cada valor de ‘k’ ejecutará el clustering de k-means 10 veces en paralelo, no solo una vez, y me dirá cuál es el mejor resultado. He establecido este valor llamado Epsilon, que es una tolerancia de convergencia, por lo que se sigue haciendo más grande hasta que el centroid para de moverse.




Lo hice y obtuve diferentes respuestas. Aquí, de hecho, he movido el rango para ver el ‘k’ más grande. Ahora, está decreciendo de forma estricta. Eso está bien. Y, no sé, parece que los valores más altos son mejores aquí. A lo mejor ha empezado desde abajo hacia 100 pero no lo sé, a lo mejor 100 es correcto o a lo mejor un número más grande es correcto también. Así que, sigamos explorando.

Una breve digresión: esto es ar-code donde puedo coger los resultados y visulizarlos, es bueno para ver lo que está pasando. Desde el primer ejemplo, esto es lo que tiene si lo visualizas en ar-code y es... no es de mucha ayuda... todo lo que puedo ver en este gráfico tridimensional, el cual puedo rotar, pero solo puedo ver los puntos en el mapa en forma de ‘L’ en el espacio, no importa cómo lo rotes y lo proyectes. Así que, mi interpretación de esto es que hay dos dimensiones en el data set que son totalmente dominantes, dónde están en el espacio, y esto va a ser una pista sobre por qué no funcionó bien y cómo podemos arreglarlo. De hecho, si os acordáis de las transparencias iniciales, había dos valores que eran mucho más grandes que los otros. Las dos primeras columnas eran byte enviado, byte recibido, y fueron medidos en miles, en decenas de miles, y todo lo demás fue cero o uno. Por lo que, creo que lo que vemos aquí, los puntos y el espacio, predominan estas dos dimensiones y esto entorpece el analizador de distancia. Así que, me gusta la visualización para ver y pensar qué está pasando y así mejorar el clustering. Por lo que vamos a solucionar este problema. Vamos a solucionar el problema de las dos dimensiones dominantes, vamos a normalizar los valores. Así que, vamos a realizar una normalización simplificada aquí.

En cada columna vamos a extraer el ‘mean’ de la columna y dividirlo entre la desviación estándar. Se llama ‘z score’ o ‘standard score’. Creo que esto es válido aquí. Es la división entre la desviación estándar, por el rango. Tiende a traer todos los valores dentro de un mismo rango comparable. Creo que esto es válido porque todos estos valores tienen una distribución normal... podemos debatir sobre las estadísticas pero para nuestro propósito está bien. En realidad, extraer ‘mean’ no es estrictamente necesario aquí. Es porque ‘mean’ solo mueve todos los puntos en el espacio y no afecta al clustering. Bueno, vamos a extraer ‘mean’ porque esta era la idea del resultado normal para que se entienda bien. Confiad en mí, este es el código de Spark que lo hará, coger el dato y calcular el ‘mean’, calcular la desviación estándar y transformar los datos y elegir su curso. Necesitáis hacer esto, es denso pero os recuerdo que en realidad, este es todo el código que necesitáis para implementar esto a través de un data set enorme. Y aquí voy a ejecutar el mismo test otra vez utilizando mis datos normalizados en esta ocasión, no los datos en bruto. Vamos a ver qué pasa. Bueno, los valores son mucho más pequeños en la derecha, lo que es algo que tiene sentido. Así que, esas columnas tan grandes se han reducido a algo alrededor de 0 ó 1. Bien, así que mis distancias son más pequeñas ahora. Para mí, esto parece como si abajo estuviera la respuesta, en 110, porque el cambio de 110 a 120 es muy pequeño comparado con 100 y 110. Así que, podríamos empezar a utilizar 110 o así, es un buen valor, ¿ok? No está claro, pero estamos llegando ahora a alguna parte. ¿Qué pasa si visualizo estos datos? Mismo proceso: lo ejecuto sobre mi




sistema de tres dimensiones y lo visualizo. Aquí tenemos una extraña estructura de tenedor. Pero esto tiene algo más de sentido. Como podéis ver... están coloreados por clúster, por cierto, por lo que hay una línea de puntos rojos que parecen estar juntos, eso es un clúster. Hay un clúster de puntos verde que parece que está esparcido en todo el espacio porque hemos reducido 30 dimensiones en una y en el espacio alto dimensional forma su propia forma de clúster. Así que, no sé si hay mucho que interpretar aquí pero al menos, podemos ver algo de lo que está pasando. Puede que tenga más sentido si lo comparamos con la última vez. Podemos ver que hay puntos que están, claramente, fuera de la estructura principal. Hay interesantes valores atípicos en los datos.

Bien, me gustaría volver e incluir las variables categóricas. Recordad que nos hemos dejado los campos TCP y HTTP en el original. Queremos utilizar esa información. Es, probablemente, valioso saber si es una conexión TCP o UDP en una sesión HTTP o en una sesión FTP. Así que lo que vamos hacer dentro del clustering de ‘k-means’ es volverlo a traer. Bien, vamos a ‘mapear’ el protocolo de una dimensión en muchas dimensiones. Por lo que si hay, por ejemplo, dos valores de protocolo que son TCP y UDP voy a convertir esa única dimensión en dos dimensiones donde los valores son 0 ó 1, dependiendo si el valor es TCP o UDP. Así que, cuando introduzca un grupo de dimensiones, exactamente, una de ellas se activará a 1 y utilizaré ese parámetro en una única dimensión categórica. Una vez más, esto es todo lo que tenéis que hacer. Bueno, si miráis luego se desgrana lo que está pasando aquí pero bueno,

solo estoy ‘mapeando’ una dimensión en muchas dimensiones aquí. Hay un 0 y un 1 numéricos por lo que puedo con el ‘k-means’. Creedme, esto es lo que pasa aquí. Podéis descargaros el correlador. Y este... este es el resultado. Hemos añadido más información y ahora... bueno, creo que hemos obtenido un resultado similar. Los números son un poco diferentes al añadir más dimensiones por lo que las distancias cambian. Pero, otra vez, parece que podemos empezar en alrededor de 110 aunque parece que cae más otra vez en 140. Por lo que se puede decir que, quizás 110 o 140 encajan especialmente bien para estos datos. Hay un números de clústeres que nos deja ‘mapear’, trazar los datos y representarlos de una manera efectiva. Pero para mí esto confirma el último resultado. Quizás podríamos quedarnos con 110. Quizás, es un valor razonable para elegir para ‘k’ aquí. Bueno, he cogido esto y lo he construido de nuevo para ver qué pasa. Tenemos básicamente la misma estructura. El color ha cambiado. No sé, hay mucha información de la que podemos aprender aquí. Hay una estructura principal de los datos cuando lo proyectamos en tres dimensiones. Y hay claramente algunos valores atípicos también. Es más interesante que antes. De nuevo podéis ejecutarlo, podéis coger estos datos y llevarlos al HDFS y ejecutarlo ahí, si queréis.

Bueno, para terminar, quiero volver y pasar más tiempo usando las etiquetas. Normalmente, si soy un supervisor de problemas de ejecución, no necesitamos tener etiquetas y podríamos parar aquí y, probablemente utilizar otro algoritmo, pero no podríamos dar un paso adelante y utilizar los datos cuando nos han sido dados sobre qué sesión es mala y qué sesión es buena. Pero




tenemos estos datos aquí. Si no, podría parar aquí y decir que tengo un modelo que me dice cuándo un dato se ha normalizado cuando no, pero podemos ir más lejos si podemos añadir datos porque aquí sabemos que algunas sesiones son fraudulentas y que otras no lo son. Sabemos que en dos puntos de datos parecen tener el mismo tipo de comportamiento, por lo que dando dos sesiones puedo decir que hay dos ejemplos del mismo tipo de ataque o que estos son dos ejemplos de un comportamiento normal. Y creo que, idealmente, un buen clustering pondría comportamientos similares en el mismo clúster o, como alternativa, no pondría muchos tipos de comportamientos diferentes en un solo clúster. Así que, quizás, las etiquetas nos ayuden a decidir cuándo un clustering es bastante bueno.

Así que esto es lo que voy a analizar en las últimas cinco o diez transparencias: cómo utilizar etiquetas y la entropía ideal para evaluar cómo de bueno es el clustering. Cómo habéis podido ver, sin datos adicionales como éstos, quizás solo podemos mirar a los puntos más bajos y los espacios de las distancias entre clústeres. Hay algunas técnicas avanzadas pero es cómo podemos utilizar las etiquetas. Esta es la etiqueta de la que estoy hablando. En el conjunto de datos original se nos dijo si la sesión era normal o si tenía algún ataque, etc. Para describir en qué se va a basar esta métrica, como una breve introducción a la idea de entropía. Creo que algunos en la sala estáis familiarizados si os dedicáis a la recuperación de información. Entropía es una medida de la mezcla (mixed-ness) de un grupo de elementos. Es decir, si tengo un grupo de elementos que son lo mismo, tiene una

entropía baja, no es muy variado. Si tengo un grupo de elementos que son todos diferentes, tiene una entropía alta, está muy mezclado. Aquí vamos a aplicarlos a los clústeres para decidir cómo de mezclados están los clústeres. Así, un clúster malo tiene una entropía alta. Esto significaría que estarían mezclados en un mismo clúster cosas como actividades normales y ataques. El clúster ideal tendría un solo tipo de actividad. Si es así sería bueno. Así que, queremos una entropía baja. Queremos medir la entropía en todos los clústeres añadidos y encontrar que la entropía es baja. Y el valor de ‘k’, para el valor de ‘k’ una entropía baja es un buen valor. Aquí tenemos más código Scala. Esto es una operación matemática de la entropía sobre un grupo de counts. Lo que hemos hecho ha sido añadirlos y calcular proporcionalmente cada uno, lo que cada count representa, coger el ‘log’, ‘-p’ y sumarlo. Un cálculo muy estándar. Y luego, vamos a redefinir los resultados del método de clustering anterior. Antes, había una suma de las distancias entre los clústeres y ahora va a haber una suma de la entropía de los clústeres. De nuevo, probablemente tendré que ir atrás y recordar exactamente qué es lo que hace Spark aquí. Pero esto es todo lo que tenéis que hacer: coger cada clúster, counts, etiquetas por clúster, calcular la entropía de esos counts, añadir el mapeo y devolver eso como resultado. Un poco denso pero esta es una operación distribuida completa. Bueno, qué pasa si cojo esto y ejecuto el proceso otra vez, pruebo un grupo de diferentes valores, en paralelo, y pido los resultados. Aquí he probado otra vez desde 30 hasta 120, es un rango bastante bueno. Y aquí, la entropía no decrece




necesariamente con ‘k’. De hecho, creo que éstas son buenas noticias. Podemos solo buscar un mínimo. No se trata de que tenga que decrecer cada vez. De nuevo, veo que hay un salto entre 95 y 100. Así que, puede que 100 sea un buen valor. Antes, hemos empezado por 110... es lo mismo... quizás, 100. Si nos detenemos podemos profundizar y, probablemente, encontrar un valor más grande para ‘k’ que nos guste. Pero esta es la manera en la que podemos añadir información adicional en la evaluación para coger un valor mejor de ‘k’. Así que, para mí, creo que podemos coger el valor de 100 y, presintiendo que tenemos un buen modelo de clustering, bastante bien definido, como los datos reales van juntos por lo que podemos decir cuándo los datos están normalizados.

Finalmente, ¿qué debo hacer si finalmente detecto una anomalía? Una vez que he construido el modelo de clustering, lo que tenemos es un grupo de puntos, los centros del clúster y el espacio. Y, ¿qué hacemos para decidir si existen puntos de datos normalizados en el nuevo conjunto de datos? Lo que vamos a hacer es coger un nuevo grupo de datos, el cual no sabemos si es normal o no, y averiguar qué cerca está de los clústeres. Entonces, cogemos aquellos que están lejos de cualquier clúster, aquellos que pueden ser los más interesantes, aquellos que podrían ser anómalos. Aquí vamos, una vez más, construyendo el modelo de clustering de ‘k-means’, definiendo la función de distancia, cogiendo los centroids (los centros de los clústeres) y mapeando cada nuevo punto de datos al que está... perdón, aquí estamos mapeando cada punto de datos sobre su distancia al clúster más cercano. El modelo te

da el clúster más cercano, coge el centroid, coge la distancia entre estos y los datos y devuelve estos datos como un tuple. Entonces, cogemos los primeros cinco por distancia, los puntos que tienen las distancias más largas del clúster más cercano, y decidimos que quizá esos son los más interesantes a los que prestar atención. Si haces esto, tendrás unos puntos que serán de ayuda para ver, pero en el mundo real probablemente querrás volver y encontrar la sesión original, mirarla y decidir si es anómalo o no. Así que, esto te ayudará a definir los puntos de datos más interesantes para analizar de forma manual en un data set de millones. Así es como lo harías.

Para terminar, ¿cuál es la diferencia entre este ejemplo y el mundo real, una implementación del mundo real? Que esto es un juguete, es solo un ejemplo. Lo que además necesitas hacer si quieres, realmente, implementar un sistema de detección de anomalías en Hadoop, en Spark, es: número uno, necesitarás un conjunto real de datos, de nuevo esto de aquí es solo un juguete, un data set de la KDD Cup, de hecho, no hace una representación muy realista del tráfico de red real. Así que, no lo utilicéis para construir un modelo real de detección de intrusiones. Debería decir que, agradecidamente, el data set de KDD fue ya convertido en sesión, es decir, cogieron previamente el conjunto de datos en bruto e hicieron unos puntos de datos en una sesión para nosotros. Esto lo tendréis que hacer vosotros en la vida real y eso es mucho trabajo.

Aquí solo hemos mirado a un algoritmo, que es el clustering de ‘k-means’, el cual, es un algoritmo de clustering muy simplista. Y no creo que sea,




necesariamente, el único correcto, solo que es simple y está ya implementado en Spark. Por ejemplo, no hemos probado con otras métricas de distancia. No sabéis cómo utilizar la distancia euclidiana cuando estás en el clustering y podríais haber dicho, incluso, que no sería una buena métrica aquí. Podéis probar diferentes tipos de inicialización de k-means para tener una mejor agrupación inicial. Y, finalmente, podríais no haber utilizado, incluso, el k-means... No hicimos nada de esto aquí, así que puede que queráis probar todas esas cosas en un sistema de producción general de la vida real. Aquí, en el pipeline tampoco hemos intentado identificar únicamente los puntos de datos así que, al final, podría deciros este punto de datos y este punto de datos parecen anómalos, pero no hemos tenido manera de trazarlos con el conjunto de datos original. En la vida real, debería añadir alguna clase de identificador a este pipeline, como, al final, coger el resultado y mapearlo con mis datos originales más fácilmente. Y, por supuesto, incluso sabiendo que al final en el ejemplo en el que cogíamos los cinco primeros que más lejos se encontraban, los puntos de datos más anómalos, esto no te ayuda en un sistema a tiempo real. En la vida real, querrás construir un sistema que, automáticamente, señale eventos y sesiones como anómalas. Así que, quizás, querrás desarrollar este sistema en alguna clase de tecnología streaming que mirará los datos entrantes y señalará aquello que está muy lejos del clúster como algo que podría ser anómalo. Y, agradecidamente, tenemos tecnologías en Spark y en la plataforma Hadoop que te ayudan a hacer esto. Tenemos Spark Streaming y tenemos Storm, por ejemplo. Ambos, cogen un flujo de datos y

te permiten ejecutar código como lo que hemos visto aquí y hacer algo como activar una alerta, por lo que es muy, francamente, muy fácil de hacer también.

Además, creo que necesitaríais construir un pipeline continuo alrededor de esto. Nosotros construimos una vez un modelo, a mano, pero presumiblemente tú quieres construir un modelo continuamente cada vez y responder nuevos datos después de haber etiquetado nuevos datos. Y hay tecnologías como éstas dentro de Hadoop: puedes establecer un workflow, puedes utilizar cosas como Spark Streaming... hablad conmigo si estáis interesados en estas cosas, pero podéis construir estas cosas en Hadoop.

Finalmente, solo hemos tocado un poco de visualización aquí. Me lo salté. Me hubiera gustado utilizar la visualización más para entender qué es los que están haciendo mis clústeres y, tal vez, depurarlos y pensar si mis procesos y mis características tienen sentido. Así que, si lo volviera hacer añadiría mejor visualización también. Pero, quizás, ha sido una buena introducción a las ideas más básicas de la detección de anomalías, cómo aplicar un aprendizaje supervisado y, más específicamente, y una prueba sobre cómo se puede utilizar Apache Spark para implementar todas estas cosas: cómo se muestran, cómo se ejecutan... Así que, si estáis interesados en estas cosas, si estáis interesados en la implementación de avisos a gran escala tendréis un ejemplo por el que empezar, si estáis experimentando con Hadoop. Si estáis experimentando con Hadoop en temas de seguridad, podéis usarlo para casos de estudio




de detección de anomalías. Probablemente, este es un buen calentamiento de introducción a la plataforma.

Esto ha sido todo por mi parte. Muchas gracias por escuchar un puñado de código.

Turno de preguntas

Gracias por la presentación. ¿Estáis usando de alguna manera este tipo de aproximaciones en Cloudera, en vuestro entorno de producción?

¿La pregunta es si utilizamos cosas como Spark? Bueno, por un lado, nosotros proveemos las herramientas, proveemos la plataforma, nosotros no hacemos detección de anomalías. Nuestros clientes lo hacen y les ayudamos a hacerlo. ¿Si nuestros clientes utilizan tecnologías como estas? Seguro. Las cosas que he visto es que la gente utiliza Spark más para cosas como sistemas de recomendaciones en realidad. Esta en una buena manera de probar un modelo de recomendación. Yo trabajo con Spark para hacer machine learning para clientes. De hecho, son sistemas recomendados. Así que, ellos prueban el modelo de esta manera, no con este algoritmo pero algo parecido y, entonces, ofrece recomendaciones de eso. He visto a gente utilizar esto para detección de anomalías, incluso, para algunos casos de usuarios clasificados. Cualquier cosa que hagas dentro de machine learning, probablemente, podrás construirlo en una plataforma como esta.

Perdona si vuelvo a tu ejemplo, pero he echado en falta la parte en la que... porque solo has hablado sobre el proceso pero para mí, hay un punto razonable donde tú deberías considerar todas estas dimensiones o características que son, en realidad, representativas para la clasificación que estáis intentando hacer. La pregunta es, ¿por qué te has saltado eso? ¿Hay alguna razón?

Seguro. Aquí tenemos un conjunto de datos en bruto y lo que he hecho es utilizar todas las características a ciegas... Tienes razón. Esto no es, generalmente, una buena idea. Algunas de estas características podrían ser irrelevantes. Estoy intentado pensar en un buen ejemplo... si tuviera una característica como la temperatura del ordenador cuando agrupo el paquete, no parece que sea relevante en la detección de anomalías y no la querría incluir en el modelo. Podría incluirlo pero sería solo ruido. Aquí no lo he hecho por simplicidad y porque sé que el conjunto de datos de la KDD Cup son datos en los que han seleccionado ya unas características y son todas ellas relevantes. No he explicado cuáles son estas características pero son todas relevantes para este caso de éxito. Pero sí, en la vida real, lo tendrás que hacer. De tu fuente de datos en bruto tendrás que decidir qué es útil, qué es irrelevante, probar el modelo, mirarlo y decir, “estabas equivocado, estas características no me sirven para nada”. Y volver a probar con unas nuevas. Así que, aquí por simplificarlo he utilizado un conjunto de datos como estaba. Pero tienes razón.




PERCEPCIÓN DEL CRIMEN A TRAVÉS DE LAS REDES SOCIALES

Luke SloanColaborador en Collaborative Online Social Media Observatory (COSMOS). Universidad de Cardiff


Buenos días a todos. Mi nombre es Luke Sloan. Estoy encantado de haber sido invitado. COSMOS, Collaborative Online Social Media Observatory, es una

plataforma creada por diferentes instituciones en Reino Unido, y es una colaboración entre científicos sociales y científicos computacionales. Principalmente, porque estoy seguro de que vosotros sois técnicamente competentes, pero antes de empezar con la charla no tenía ni idea de cómo utilizar los datos generados por los medios sociales para entender los fenómenos sociales. Así que la colaboración ha creado esta fantástica plataforma de la que voy a hablar. Me centraré especialmente en un trabajo en el que estamos

inmersos en este momento, que trata sobre la percepción del crimen utilizando redes sociales. Y, luego, probablemente, utilizaré la mayor parte de la presentación para hablar de los problemas que nos hemos encontrado trabajando con los datos y de las soluciones que creemos que hemos encontrado.

Bueno, básicamente, soy científico social y entiendo el comportamiento de los usuarios en Twitter, por lo que una y otra vez utilizaré la palabra ‘predecir’, pero solo para referirme en un sentido de modelado de sistemas como en el uso adicional extra de predecir. ¿Por qué? Bueno, en realidad, para referirme a una asociación entre




gente que tuitea sobre crímenes y desórdenes y que son registrados directamente por la policía.

Bien, el proyecto es un caso de estudio entre dos capitales, Londres y Cardiff . Voy a hablar más de Londres porque son los principales datos que tenemos. Esencialmente, tenemos resultados de cuatro proyectos. Lo que queremos es evaluar si Twitter podría ser una asociación para la actividad criminal. Queremos desarrollar una máquina automática para identificar, de alguna manera, desórdenes criminales, es decir, una detección automática del lenguaje. A través de ello, nos hemos dado cuenta de una variación especial del crimen y, ¿cómo? Porque la relación entre todos los tuits de Londres sobre crimen relacionados con el número de crímenes cometidos es directa y las leyes tienen variantes geográficas, os mostraré algunos ejemplos más tarde. Vamos a comparar modelos de predicción convencionales. Típicamente, dentro de los sites de las redes sociales, nos fijamos en depravación o desempleo como elementos predictivos del crimen. Pero las redes sociales son diferentes, no es algo que se mida cada 10 años en los censos nacionales. Los medios sociales son una locomotora que pasa cada segundo. Así que, ¿cómo puedo utilizarlo para entender niveles de criminalidad y como una capacidad operativa útil para la información en tiempo real que pasa en el mundo? El origen de este proyecto es simplemente que todos estos datos que están pasando, los cuales –ya sabéis de lo que estoy hablando– hay que convertirlos pero en las ciencias sociales no tenemos manera de acceder a estas operaciones con datos digitales para entender fenómenos sociales.

Ahora, voy a hablar de Twitter porque la plataforma que hemos desarrollado está optimizada para Twitter, pero incluiré fuentes adicionales. No obstante, tenemos esta idea: los medios sociales se han convertido en una fuente para la policía. Las opiniones son una reacción instantánea a los medios de comunicación, a lo que pasa en las noticias también, es donde se privan de los derechos civiles representados. Cuando la gente normalmente responde a encuestas sociales es instantáneo y barato comparado con hacer un estudio. Estoy hablando de estudios mucho, pero dentro de las ciencias sociales nos dan datos comprensibles y esto es una revolución desde nuestra manera de pensar. Es algo que las ciencias de la información han estado haciendo durante años pero para nosotros es bastante nuevo. Para hacernos una idea, este es el volumen de datos producido por Twitter: ‘Spritzer’ llega al 1% (podéis tener gratis esta API de Twitter con la que podréis trabajar bien) 3,5 millones de tuits al día. Bueno, estas cifras fueron recogidas hace un tiempo por lo que seguramente han aumentado. ‘Garden Hose’ al 10%, el cual tiene un acceso gratis negociado desde Twitter; si preguntas por algunos de sus canales, alcanza 35 millones de tuits al día. Y ‘Fire Hose’ al cien por cien, contabilizó 350 millones de tuits al día.

Bueno, son muchos datos, seguro que sois conscientes tras la última presentación, que hay también mucho ruido. Por lo que tenemos muchos datos medidos y mucho ruido para encontrar lo que nos va a resultar útil, así que de lo que más voy a hablar es de cómo extraer el núcleo útil, el kernel de la verdad, de este abrumador flujo de datos masivo.




Aquí tenemos una muestra de la plataforma que hemos desarrollado y que nos llevó un par de años de trabajo y de la que voy a hablar de dos ejemplos. Bueno, aquí tenemos una captura de pantalla de la plataforma y vamos a echarle un vistazo a las características clave. En la izquierda, aquí puedes filtrar, son datos que aparecen en tiempo real por lo que puedes elegir un filtro por género, por idioma, por lugar... cerca del 0,5% de los tuits tienen activada la etiqueta de localización (el geotagging), así que tenemos las coordenadas de latitud, por lo que podemos señalar de forma precisa dónde se hace el tuit. Para otros, para su localización, tenemos que confiar en el propio código del país o a veces, podríamos suponer que el lenguaje es el proxy. También, rellenarlo con palabras clave, los hashtag y las cuentas de Twitter. Lo que podéis ver en el medio, esto es más bien animado (no es una captura), donde los tuits aparecen y corren de entre a 70 y 120 tuits por segundo. Ellos aparecen en la base de datos de COSMOS y, automáticamente, los datos son añadidos de forma metódica tales como el género en la izquierda, se censan utilizando el censo directamente, donde los clasificamos por positivos o negativos, no creamos métricas para los dos, miramos a ambos. Tenemos textos actuales aquí. El rojo indica dónde hay un texto difamatorio u obsceno, solo está en lengua inglesa por el momento. En la derecha podéis ver estadísticas de hombres, mujeres, idioma y hashtag y, puede que al final sea el momento en el que podéis preguntar cómo manejamos estas métricas y estaré encantado de volver a ello.

Moviéndonos un paso más, tenemos la tensión a través del tiempo. Este es el gráfico que se

mueve cuando los tuits entran. Trazamos la tensión dividida en masculino y femenino y, como podéis ver, hay algunas claves. Hay una medida del ‘sentimiento’. Para determinar el sentimiento utiliza SentiStrength que es un producto estándar del lenguaje creado por Mike Thelwall en el Reino Unido. La ‘tensión’ es nuestra propia métrica, la cual, es medida con herramientas que hemos desarrollado para los llamamientos racistas en el fútbol, por lo que tiende a prestar atención... Podéis ver a veces algunos picos de atención antes del ‘sentimiento’ y, de nuevo, podemos volver a esto después.

Bueno, no hay nada más, es una brillante visión sinóptica. Si tú coges todos los tuits de cada uno de los países esto no serviría. Pero si te focalizas en eventos, si filtras por hashtag, palabras clave, esto te dirá cuándo las cosas empiezan a pasar, así que básicamente es muy útil. En la derecha, podéis ver diferentes hashtag, las estadísticas del idioma y otros filtros y métricas de la página anterior. Finalmente, hay una prueba de concepto que es el mapeo. Este es el mapa de Londres dividido por concejos y este está trazado con los datos del censo provistos por la Oficina Nacional de Estadística. En la parte de arriba podéis ver la composición étnica, podéis ver la población y cuando lo activamos, también se pueden ver puntos de Twitter que cuando aparecen en el mapa pueden hacer clic en estos puntos para ver qué está diciendo la gente y dónde están. También podéis ir a la API de la policía y acceder a los datos de los crímenes del último mes en el área en el que has pinchado. Por tanto, ¿qué es lo que hace esta plataforma? Provee un mecanismo a través del cual todas estas diferentes fuentes de datos




pueden ser interrelacionadas, generalmente, a través de la geografía. La geografía aquí es la clave. Esto esta creado para la gente que no tiene una formación técnica pero, probablemente, con habilidades en las ciencias sociales pueden hacer las preguntas correctas para analizar estos datos y decir que hay algún enlace útil, el cual, además, puede ser exportado en varios formatos.

Bueno, estos fueron los primeros artículos, ahora vamos a ver una segunda versión del estudio de Cosmos en otro caso. Este es el maratón de Bostón -en el que explotó la bomba- donde estuvimos recolectando datos en ese momento. Automáticamente, estuvimos recogiendo un 1% de los datos a nivel mundial. Lo que podéis ver aquí es un mapa de Bostón que lo resume y los puntos en amarillo representan los puntos que... eh, los tuits que se hicieron en este periodo de tiempo, ¿ok? Así que esto está entre las 16:00 y las 17:00 del 15 de abril. En la parte de abajo a la izquierda podéis ver una simple nube de palabras por tamaño. Las palabras más grandes son las que más frecuentemente aparecieron: ‘buena suerte’, ‘running’... nada que no esperarías de una maratón. Ahora, nos hemos movido de las 17:00 a las 18:00 y, como podéis ver, 21:00... hay un pico que es justo cuando estallo la bomba y lo que podéis ver si seguimos es ‘buena suerte’, ‘running’, ‘buena suerte’, ‘running’, ‘buena suerte’, ‘running’... Y ¡pam! ‘explosiones’, hay un incremento masivo en el uso de la palabra ‘explosiones’ y, también, podéis ver cómo los tuits se expanden, no solo está agrupado en la ruta del maratón, todo el mundo está hablando sobre ello. Así que, si fuera un profesional de la seguridad viendo esto contra todo lo que está pasando y, probablemente,

trabajaría en el epicentro del evento. Puedo ampliar esto más allá, en minutos, y podéis ver aquí, esto es cuando la explosión acaba de pasar y, entonces, se extiende contagiando a todos los Estados Unidos. Por lo que la plataforma en muy potente en ese aspecto. Este es el software que estamos utilizando para comprender la percepción criminal y creo que esto provee una buena evidencia de que los humanos percibimos los eventos reales en el mundo.

¿Cómo pueden utilizarse los datos de Twitter para comprender el crimen? Bueno, esto no es el departamento de pre-crímen, no estoy aquí de pie predicando Minority Report. No estoy diciendo que podemos proteger del crimen a través de las redes sociales, estoy diciendo que, a lo mejor, una asociación nos puede... No predecimos los crímenes. Sin embargo, sí encontramos que hay ciertos términos en Twitter que se asocian con altos niveles de criminalidad en París, si encontramos que estas palabras aparecen en áreas donde el crimen no está registrado deberíamos informar que hay un crimen en marcha y que no está registrado. Ahora, esto es particularmente pertinente cuando estamos teniendo en cuenta el estatus social-económico del área. Hemos encontrado que hay un menor índice de crímenes registrados en áreas muy degeneradas, por lo que puede que haya crímenes que no estén registrados. Twitter es una tecnología emancipadora y no tenemos ninguna razón para creer que la gente de las áreas más deprimidas no tuitean. De hecho, ellos tuitean cosas como ‘acabo de hacer un grafiti en mi pared’ o ‘mi propiedad está siendo atacada por unos vándalos’ y podrían no corresponderse con




un crimen. En cualquier caso, Twitter puede ser una fuente alternativa teniendo en cuenta otro tipo de fuente de donde extraemos información. Así que, tenemos buenas razones para creer que Twitter es útil para entender los fenómenos sociales. Sabemos que Twitter ha sido utilizado en las elecciones generales de Alemania, ha sido usado para trabajar sobre los ingresos de las películas. Este artículo en particular de Asur y Huberman concluyó que los datos de Twitter o, básicamente, las menciones de las películas en Twitter constituyen un sistema de predicción mejor de los ingresos en taquilla que el Hollywood Stock Market, el cual, es un estándar.

Por mi background en política, alguno puede estar al tanto de que hay una votación sobre la independencia escocesa, estoy muy interesado en ver si los sentimientos en Twitter afectan a la votación escocesa. Es una forma de predicción mejor que las encuestas tradicionales porque son caras y consumen dinero. Twitter es barato y permite atajar. Habiendo dicho eso, sabemos que puede ser utilizado para estimar los centros de los terremotos. Con base en Japón, se hizo un estudio en el que esencialmente encontraron que usando Twitter puedes tener un aviso de 10 segundos. Creo que fue con el terremoto y salvó la vida de alguien. También, podéis mirar a la extensión de los datos, tenéis que tener cuidado con las diferentes comunidades geográficas. Cuando los datos de Boston aparecían tú podías intentar trabajar en el epicentro para saber qué estaba pasando y puedes hacerlo ampliándolo de horas a minutos.

Bien. Twitter también se utiliza para estimar los cambios en la densidad de población. Estoy

haciendo ahora un trabajo para la Oficina Nacional de Estadística para tratar de entender cómo Twitter puede usarse para medir la percepción de la migración y, a lo largo de las trazas de los datos geográficos que hemos obtenido se esperaría un grupo de tuits dentro de poblaciones densas. Por lo que si tuvierais que mapear los tuits en estos puntos de datos en el mapa de Reino Unido, seguiría la densidad de población que esperaríais encontrar.

Finalmente, hay un estudio de Gerber el cual hace una investigación entre los crímenes registrados y los temas de Twitter que prevalecieron, lo que sería un data mining atendiendo a ciertas palabras y su correlación dentro de áreas. Aquí aparece Chicago en bloques de un kilómetro cuadrado, solo es una estimación de la densidad del kernel. Aquí operamos de forma diferente, no utilizamos bloques estándar, utilizamos geografías tal como lo entiende la Oficina Nacional de Estadística. Así, el problema de utilizar un bloque de un kilómetro cuadrado es que no tienes los datos socio-económicos en él, si utilizas lo que llamamos un board o área estadística geográfica, sabes cuánta gente está desempleada, sabes la proporción de la mezcla de etnias hay en un área esto quiere decir que puedes obtener una imagen más esquemática de lo que pasa.

¿Puede el contenido relacionado con el crimen y el desorden en Twitter mejorar nuestra compresión y nuestra habilidad para predecir patrones de comportamientos criminales? Si es así, ¿es el contenido de Twitter una mejor manera de predicción de ciertos tipos de crímenes que otros? Lo que nosotros esperaríamos son diferencias para ser un mejor sistema de predicción o de más




altas asociaciones con crímenes que se establecen en un lugar, tu entras en un área y comentas sobre un acto vandálico, comentas un grafiti o, un interesante ejemplo (os hablaré de él después), sobre la presencia de agujas que se usan para drogarse de forma intravenosa. Bien, ¿puede este tipo de datos ser utilizado como una medida alternativa de sentimientos de inseguridad? Estamos hablando en realidad de hipótesis de ventanas rotas pero no esperamos que alguien vaya a Twitter y diga “he robado una televisión” o “he atacado la casa de esta persona”. Lo que se podría tuitear es “esta área ha sido afectada” o si hay muchas ventanas rotas ‘no me siento seguro andando por este área’. Por lo que es el uso de un nivel bajo de desorden el que se emplea para comprender los crímenes actuales, cómo se siente la gente y asociarlos con unas características socio-económicas como el desempleo.

Estamos haciendo un estudio comparativo de Londres. Estamos en proceso de realización en este momento, por lo que no tengo los resultados finales para enseñároslos pero lo que sí que puedo enseñaros son los datos de crímenes y algunos de los problemas en los que estamos intentando integrar Twitter y los datos de crímenes de la investigación oficial. Hemos registrado el crimen entre agosto de 2013 y agosto de 2014, y tenemos latitud y longitud, seguimos teniendo la localización precisa de los puntos de los datos de los crímenes cuando pasan. También tenemos el tipo de crimen, es decir, la categoría. Recolectamos automáticamente el 100% de los tuit marcados con geotagging en el Reino Unido, con lo que cada día hay aproximadamente 500.000 tuits hechos desde Reino Unido que son geoetiquetados. Bueno,

solo explicar el geotagging, una cosa que no sé pero puede que conozcáis. Un usuario puede elegir activar el geotagging y los tuits graban el lugar preciso donde están en el mismo momento en el que hacen el tuit. Y, si la gente activa el geotagging, hay evidencias, hay mucho trabajo que se muestra en el cual tú puedes seguir el viaje de alguien a lo largo de la ciudad y hay algunas plataformas como Foursquare que se basan en el geotagging. Es muy interesante. Pero en Twitter el usuario tiene que activarlo. Así que hemos contabilizado entre un 0,5 y un 1% lo tienen. Como podéis ver, no obstante, siguen dando muchos datos entre los usuarios de Twitter: 500.000 usuarios hoy. También, tenemos datos censales basados en la composición étnica, educación, logros... todo tipo de variables que pueden ser interesantes y que nos pueden ayudar a entender. Así que, en la lista de abajo están los métodos tradicionales para comprender el crimen en un área enlazándolo a las características de un área. Tenemos esta capa adicional en la que está constantemente fluyendo un sentimiento. Muchos datos pero potencialmente útiles si puedes apoyarlos.

Lo primero que tenemos que hacer es limpiar los datos tuiteados, 500.000 tuis al día es demasiado para hacerlo manualmente por lo que hemos establecido un algoritmo de machine learning para encontrar los datos que queremos. Y esto, probablemente, no es una sorpresa para vosotros que sois profesionales de la seguridad pero esto es algo que he estado aprendiendo. Tenemos todos los tuits geocodificados (geocoded) de Reino Unido entre agosto de 2013 y agosto de 2014. Así que lo primero que hacemos con esta muestra es usarla para identificar los que se enviaron desde




Londres y Cardiff , lo que reduce sustancialmente la cantidad de datos que tenemos. Asumimos que algunos en el Reino Unido están establecidos en las dos grandes ciudades pero que tuitean desde algunas otras pero para localizarlos en una ciudad necesitamos los que han sido geotagged en esa ciudad o que ellos que digan que la ciudad es Londres. Ahora, el problema es, soy de Cardiff , mi perfil de Twitter es de Cardiff pero estoy en Madrid y también tengo el geotagging activado por lo que puedes asumir cuando tuiteo desde aquí que estoy en Londres, por lo que este desorden es en lo que tenemos que trabajar, especialmente, en el contenido de los tuits que pone la gente. Este es un trabajo en el que estamos. Pero, asumiendo que hacemos esto, hemos cogido una submuestra aleatoria (cade nth tuit) enviada por multitud de fuentes de codificación en línea, por lo que hemos creado fuentes y hemos preguntado a la gente, ¿cuáles de estos tuits contienen y no contienen información sobre crimen y desorden? Así, contengan o no, mantén el trabajo lo más pequeño y lo más barato posible. El 50% del grupo de datos anotados para clasificarlos en un espacio automático. Y la clasificación es binaria simplemente diciendo: ¿estos tuits contienen o no contienen información sobre crimen y desorden? Empieza por palabras. Así que, deberías apuntar, no vamos a empezar con un grupo de palabras, no vamos a identificar palabras o algo así, vamos a confiar completamente en la sabiduría de la gente en este sentido. Y aquí quizás tengamos problemas (que pueden ser teóricos) pero eso ya ha sido mostrado antes así que vamos a pasarlo. Y, entonces, vamos a dar por supuesto, ¿han tenido estos tuits en Londres y Cardiff señales de

crímenes y desorden? Un simple tuit puede ser medida para el crimen y el desorden. Estamos esperando que este proceso de filtrado se realice. Habrá algunos pequeños datos que se dejen atrás, los cuales, por eso precisamente hemos cogido en un periodo de un año y por eso, precisamente, lo que hemos cogido desde menciones especiales de criminales y términos acerca de desordenes como ‘grafiti’, ‘ventanas rotas’ y cosas que no son necesariamente una actividad criminal en sí, que debemos asociar pero que no son crímenes per se.

Ahora, asumiendo que estamos en este estado podemos trazarlo en un mapa y utilizar la estimación actual para encontrar las correlaciones entre tuits pero, desgraciadamente, no es tan simple. El problema es que los datos de Twitter entran a cada segundo y tenemos un segundo de etiqueta para los datos. Tenemos datos criminales que también se cuentan por segundos pero la gente no reporta crímenes en el minuto en el que pasa, muchos de ellos podrían tuitearlo pero alternativamente, alguien puede tuitear he visto a alguien que ha sido marcado hoy pero sin referencias en el tiempo. Así que, lo que quiero enseñaros ahora son algunas dificultades que tenemos con los datos criminales, cosas similares a artefactos en la manera en el que el dato es registrado. Es solo una reflexión en la manera en la que los seres humanos recuerdan los eventos que les han pasado. Bien, este es un simple histograma: a lo largo de la parte inferior tenemos el tiempo en el que los crímenes fueron cometidos. Esto corresponde a todo junio y la frecuencia de crímenes en el que se incluyen todos los crímenes. Bien, como podéis esperar los crímenes apuntan sobre las 5 o las 6 de la




mañana y se van sucediendo durante el día pero es muy obvio y nada normal aquí. Nos hemos dado cuenta de que hay muchos crímenes que pasan a mediodía. Esto es un artefacto de que la gente registra. Ellos creen que la hora que más se ajusta o saben que pasan alguna vez en la hora de la comida, es decir, a las 12 en punto. Por lo que aquí está el primer problema: si alguien observa un crimen que está pasando y dice ‘alguien está cometiendo actos vandálicos en este lugar’ en un tuit tenemos dos minutos en los que el crimen ocurre. Sin embargo, cuando alguien lo registra y lo reporta a la policía los datos oficiales dicen que ha pasado a las 12 en punto y podríamos tener un desajuste. Así que, tenemos que pensar que hay que comprender el grado de tolerancia entre los datos en lo que se ha registrado, que puede que sea impreciso, comparado con los tuits que debemos de asumir como razonablemente precisos. Si tenemos en cuenta las palabras que califican, si ha pasado entonces, si ha pasado ahora, si pasó ayer, con la gente diciendo “esta tarde he visto...”, etc.

Vamos a pasar a la contabilidad de diferentes tipos de crímenes ocurridos en diferentes momentos del día. Y, realmente necesitáis... Sé que el texto es bastante pequeño... En realidad, solo necesitáis leer la principal clase de delitos. Lo importante son las proporciones de colores que cambian. Los tuits pueden ser muy buenos para identificar crímenes particulares como grafitis o alteraciones del entorno, los crímenes geográficos cuando la gente pasa por algún lado. Si observo un asalto y digo ‘esto en un transporte público’ en el momento en el que tuiteo ese asalto probablemente estoy dos calles más allá

de donde ha pasado por lo que es muy difícil relacionar los puntos geográficos. Pero la cuestión es que si Twitter es mejor para identificar unos crímenes que otros, necesitamos tener en cuenta que algunos crímenes ocurren en momentos diferentes a otros. Por lo que Twitter puede ser bueno para proteger de ciertos crímenes en ciertos momentos de día y, lo que voy a enseñaros después, es que también hay que tenerlo en cuenta para ciertos tipos de áreas. Por lo que esto no es la gallina de los huevos de oro, esto no va a resolver todas las cosas, pero sospechamos, teorizamos que podría tener algunos atributos específicos en lo que puede ser útil con algunas asociaciones que pueden ocurrir. Y, el principal problema para nosotros en saber dónde es útil y lo que es solo ruido.

Bueno, aquí está el histograma de los datos de junio de 2013 de nuevo, que muestra las clases de los principales crímenes. Ahora, hay algo muy interesante aquí que es el robo y la manipulación. Aparentemente, los crímenes de robo y manipulación solo ocurren en la hora, hay un punto cada hora, a esto es a lo que me refiero con el artefacto de la gente reportando un crimen, ellos creen que pasa a las 13:27, creen que pasa incluso alrededor de las 13:30 y las 13:00 y esto hace difícil averiguarlo. Por lo que, ¿cuál es la tolerancia de lo que pasa entre tuit y tuit? ¿Abrimos una ventana de una hora de los tuits que se han hecho? Bien, no vamos a ver qué ha pasado antes. No estarías tuiteando lo que ha pasado antes de tiempo a no ser que tú vayas a cometerlo. Así que, ¿una o dos horas después? ¿Qué tolerancia podemos admitir dentro de los márgenes para hacer asociaciones del crimen?




Así que, el tiempo es importante. Tenemos más tuits durante el día porque lo que quizás podemos comprender mejor es qué datos son en los que más podemos confiar pero también tenemos más ruido. Dejadme que os dé un ejemplo. Hemos creado una colección para el término ‘agujas’, por lo que pensamos que la gente tuitea acerca de las agujas nos da una pista del consumo de drogas... ‘agujas’ en el parque y entonces se geoetiqueta y sabemos que se están consumiendo drogas. Y el consumo de drogas es muy difícil de captar porque se mueve por todos los lados. Hay una aplicación muy útil, lo que hemos encontrado es que hay una increíble comunidad de tejedores muy activa en Twitter. Por lo que cerca del 80 o del 90% de los tuits se trataba sobre tejer. Y eso lo podemos filtrar utilizando términos como ‘lana’... Es un ejemplo gracioso, pero la cuestión es cuánto podemos equivocarnos pensando que ‘agujas’ era algo obvio. Pasamos mucho tiempo hasta que dimos con ello. Incluso, cuando tienes un grupo de términos necesitas filtrarlos de esta manera de término presentado y, entonces, ignorarlo. Y puedes sentarte en la oficina y llegar a esto teóricamente en tu cabeza basado en algo que sabes pero hasta que no tienes los datos y no lo intentas, no lo sabes. Bueno, este es un ejemplo de cómo cuando vas con buenas intenciones también te equivocas.

Así que, ¿cómo puedes hacer frente a este retraso (‘lag’)? Por ejemplo, ‘la casa del camino sufrió un robo anoche’. Aquí podemos utilizar procesamiento de lenguaje natural y otras técnicas para identificar ‘la pasada noche’ para comprender el tiempo pero esto es difícil por la manera en la que la gente hace la frase y usa el

tiempo pasado, también hay una imprecisión en la manera en la que la gente dice cosas. Es problemático, por lo que ‘robo la noche pasada’ es muy útil porque sabemos que el tuit se envió el martes por lo que sabemos que el robo ocurrió el lunes por la noche o el martes por la mañana. Si alguien dice, ‘alguien fue robado la semana pasada’ es menos útil porque tienes una semana y se puede volver al año pasado, etc. Así que, ¿en qué punto cortas y dices ‘no voy a utilizar esto porque no es preciso’? Cada vez que realizas una decisión a medida que avanzas a la precisión, pierdes datos. Y, por lo tanto, se convierte en algo más duro de ser seguro y tal. Es una tensión interesante. Es una forma interesante de curvar la cuadratura.

Específicamente, para un área que como Londres o como Madrid, es una gran área, hay muchas variantes, económicas de la población que vive allí, de los tipos de crímenes que se producen y de la cantidad de crímenes, particularmente. Así que, la pregunta es, ¿a qué nivel geográfico debemos mirar los datos? Estos son los datos de crímenes desde junio hasta julio de 2013, en Londres. Si no estáis familiarizados con Londres... Bueno, esto es el mapa de los centros de población de Londres. Lo interesante es este justo en el centro de la ciudad donde existe una manera diferente de registrar el crimen por las fuerzas policiales. Podemos ignorar esos datos. Pero a este nivel, podéis ver las líneas rojas que marcan los bordes de los concejos, los distritos, las autoridades locales o como los llamemos. A este nivel lo que pasa no tiene sentido. Podéis ver que el crimen se concentra en áreas de población densa. Otro problema de Londres es




que es una ciudad donde hay muchos traslados. La gente se mueve dentro y fuera. Hay mucho movimiento. También es una ciudad turística, particularmente en el centro, donde los turistas se mueven todo el tiempo. Por lo que la población ‘estática’, normalmente, no es la gente que vive en el área desde la que está tuiteando. La gente se va moviendo de áreas. Esta es una imagen donde se ha hecho una ampliación del mapa de Londres. Lo que podéis ver ahora... bueno, las líneas negras gruesas son los mismos límites de antes de los concejos, de las autoridades locales. Las pequeñas parcelas de dentro son lo que llamamos tablas de estadísticas censales agregadas por lo que son tablas que sabemos que representan pequeñas áreas geográficas las cuales conocemos por sus características socio-económicas. Podríamos llegar a un nivel más bajo pero el mapa se llenaría más. Bien, los colores, el rojo y el verde, se refieren al desempleo. Es decir, el rojo representa altos niveles de desempleo y el verde son los bajos niveles. Por lo que hemos juntado la información geográfica, los datos de los crímenes, los datos sociales y económicos y, una vez que hemos llegado al nivel de los tuits también los hemos trazado encima. Bueno, lo que podemos ver aquí es una concentración mayor de los tuits en la zona de Soho y de Covent Garden, y menor en Knightsbridge y Hyde Park. El Soho y Covent Garden están en el centro de Londres, el centro turístico, donde están los teatros y los bares a los que mucha gente acude. Knightsbridge y Hyde Park son unas áreas privilegiadas, como podéis ver, tienen mucho verde lo que significa que tienen un bajo nivel de desempleo y mucho dinero y es muy rico. Bueno,

esto no significa necesariamente que los crímenes estén ocurriendo allí, solo hace referencia a los diferentes tipos de crímenes que suceden, o puede que ocurran, o no, teniendo en cuenta las características del turismo y socio-económicas. Bien, es un tema de debate averiguar qué área es la mejor para encontrar una asociación, ¿podemos encontrar una mejor asociación donde hay más gente y más datos o es porque los turistas van allí? Porque hay turistas de diferentes lugares, con diferentes idiomas y nuestros motores están especialmente preparados para el inglés por lo que vamos a tener problemas para encontrar algo allí, ya que puede haber mucho ruido. O, incluso, puede que sea mejor algo más tranquilo, con menos ruido.

De nuevo, otro ejemplo que podéis ver. Esto se está refiriendo a bajos niveles de desempleo y aquí altos niveles de desempleo. Podemos ver que hay muchos crímenes en esta zona. Pero hay numerosos tuits donde hay muchos crímenes por lo que no estamos seguros de lo que la gente tuitea acerca del crimen en esa área. He dicho que Twitter es una tecnología emancipadora, aunque he dicho que cualquiera puede tuitear y reportar un crimen. La realidad es que, en áreas con un alto nivel de pobreza, existe un menor acceso a la tecnología. Puede que sea porque, simplemente, la gente no tenga móviles de contrato con paquetes de datos por lo que no tuitean o usan wi-fi, o tuitean desde una casa con wi-fi, lo que significa que no tuitean cuando se mueven... Todo esto es lo que tenemos que ver y tener en cuenta... No hemos sido muy buenos encontrando una buena asociación entre los tuits y el crimen en esta área y, quizás, podemos ser mejor en esa otra área.




Bueno, probablemente, las personas de esta sala tienen algunas ideas. No voy a meter presión pero, la pregunta es ¿cómo modelamos estos datos? ¿Cómo investigamos la asociación entre ellos? Necesitamos coger, por ejemplo, digamos que lo más obvio es coger las tablas dónde el nivel geográfico te muestra donde están los datos de empleo y tratarlos cruzándolos entre secciones. Es decir, cogemos un mes y miramos la relación entre el crimen y los tuits ,la estimación actual de la densidad o cualquier cosa geográfica y, entonces, ves la asociación. El problema es que los datos son muy poderosos porque lo que realmente tenemos son datos de panel. Tenemos medidas repetidas para las diferentes áreas geográficas en el tiempo. Es como un estudio de cohorte donde figuran áreas geográficas a las que volvemos cada vez haciéndonos la misma pregunta, ¿cuáles son los ratios de criminalidad? Así que, no solo tenemos en cuenta hechos espaciales, también los factores temporales, cómo las cosas cambian en el tiempo. Por lo que tenemos que tener en cuenta datos estáticos, datos aleatorios y si es un modelo multinivel porque tenemos áreas geográficas, pequeñas áreas geográficas anidadas dentro de las administraciones locales, por lo que puede haber distintos niveles locales a tener en cuenta. Y básicamente, ¿cómo todos estos datos tuiteados pueden mejorar nuestra comprensión por encima de todos los factores existentes? En los modelos que normalmente utilizamos con los datos fijos el mayor problema que hemos tenido utilizándolos, en realidad, es cómo manejarlos, cómo manejar su tamaño, cómo limpiarlos... Lo que la inferencia estadística significa en este caso es un montón de trabajo, de ciencia de cálculo, minería de datos y

todo aquello que es usado en modelos de toma de decisiones pero en ciencias sociales la inferencia estadística (cómo de seguros podemos estar de que los datos que tenemos) representan a una población muy amplia. ¿Qué seguros podemos estar de que lo que hemos encontrado en Twitter puede ser representativo para alguien más? Este es el problema real porque no sabemos, en realidad, quién esta tuiteando en un momento dado. Tenemos algunas ideas (iré con esto muy rápido) y las cuentas, podemos establecer algunos rasgos rápidos al final, como el género. Pero el caso es que hay nociones tradicionales de inferencia estadística que solo funcionan cuando los datos que tienes son muestras aleatorias. Es decir, si tenemos una muestra aleatoria de datos de Twitter, que es lo que hacemos para una población amplia, podemos inferir en la seguridad de las variables, por lo que, ¿cómo de seguros podemos estar de que lo que hemos encontrado en nuestra muestra representa a nuestra población? Pero la gente que tuitea no son representaciones aleatorias de la población de Reino Unido. Y este es un problema que tenemos que intentar solventar en cualquier población. Y en ello estamos ahora.

Ahora de lo que vamos a hablar es de información demográfica. Tenemos que saber quién es la gente que tuitea y podemos hablar un poco de geografía. Os he dicho que podemos hacer esto basado en la vida, en el país, en las noticias de las que habla la gente, también lo podemos hacer con el género y con el idioma.

Demográficamente hay tres fuentes de datos de localización. Existe una información del perfil de usuario; como he dicho, el problema es que,




aparentemente vivo en Cardiff pero estoy en Madrid ahora y esto no ayuda si estoy tuiteanto acerca de este evento y alguien se preguntará por qué está tuiteando desde Madrid si vive en Cardiff . Así que, esta es una medida muy caótica pero es algo que tenemos que usar. Las otras premisas son las diferencias entre dónde ha nacido la gente, o dónde piensa que está realmente su casa, dónde trabajan y dónde están en el momento en el que está tuiteando. En Londres, donde normalmente la mayor parte de la gente se mueve para trabajar y luego se va a casa, tenemos que distinguir entre la casa y el trabajo. Así, en algunos estudios de Reino Unido se fijan dónde la gente tuitea dependiendo del momento del día. Ahora, podemos mirar al contenido de los tuits y puede que no sea muy útil, pero puedo escribir que estoy en Madrid. Y en el caso de Londres, decir que estoy yendo en el metro de Covent Garden... Es útil pero necesitas mucha potencia de cálculo para recoger esos datos. Podéis utilizar algo como Yahoo PlaceFinders, es muy bueno para eso. Pero cuando alguien dice: “estoy en el pub al final de la carretera” o “estoy en el puerto tomando una copa”, esto no es útil, porque hay cientos de pubs y esto no es lo que busca el programa. Esto significa que es un programa al que tenemos que prestar atención porque, automáticamente, destaca los tuits geoetiquetados. En vez de poner la confianza en lo que dice alguien, o en que mantenga el perfil actualizado, solo se fija dónde están cuando están tuiteando y, muy importante, te permite trabajar en el contexto en el que se está tuiteando. Sabes sí está en un sitio muy concurrido, si está en un nivel de desempleo, el idioma, la composición étnica del área, si está

empobrecido o es rico y todas las cosas. Por lo que sabes si alguien tuitea “he visto muchas ventanas rotas, qué raro” y está andando en un área rica entonces, sí, es extraño, es inusual. He visto muchas ventanas rotas cuando he pasado por un sitio ruinoso no es sorprendente. Así que, estos son los datos más importantes. Hay más de 50.000 tuits al día, lo que sigue siendo mucho.

Y esto es solo para convenceros de que realmente funciona. Esto es un mapa del mundo con la propiedad de geotagging activada. Y tengo que decir que la primera vez que vi esto me preocupé mucho porque hay muchos puntos en el mar pero estos son, en realidad, hasta lo que nosotros sabemos, rutas de barcos. Por lo que hay gente en barcos que tuitea, y ello significa que funciona. Y podéis ver a este nivel, si se amplia, que los niveles de densidad de población coinciden con lo que se espera que sean.

Bien, el lenguaje es particularmente interesante porque podemos correlacionar el idioma que la gente utiliza en un área con lo que creemos que es ese área. Así, en Reino Unido hacemos el censo cada 10 años y se pregunta cuál es la primera lengua y tú sabes la lengua que debería ser. Aquí hay una cuestión interesante, ¿coincide el idioma registrado por el censo con el idioma utilizado en Twitter? Si no, si algunos grupos no aparecen o no están representados, puede que no tengan acceso a tecnología, puede que no puedan permitírselo, puede que esta gente utilice Twitter. En cualquier caso, ¿es realmente importante saberlo? ¿Es importante saber quién no utiliza Twitter? Y si lo es, qué dice del otro.




Sabemos que a lo largo de Reino Unido, el 40% del contenido está en inglés. Hemos utilizado la librería de detección de lenguaje Java para hacerlo. Esto no significa que la persona que esté tuiteando sea inglesa, pueden haber escogido tuitear en inglés. Puedes mirar el nombre principal del usuario y el idioma de la interfaz de Twitter en los metadatos que Twitter te da en la API. Hay muchas maneras de corresponder a esto pero el idioma que se usa en los tuits es uno. Por lo que, ¿corresponden los patrones espaciales del lenguaje de Twitter utilizados para su registro con Twitter maps? Y, los “hard to reach groups” (las comunidades marginadas o aisladas) pueden usar Twitter.

Estadísticas de lugar e idioma definen cuando es un género. El género tiene una importancia crítica desde una perspectiva de las ciencias sociales y desde muchas perspectivas del marketing también. Pero los datos de Twitter parecen más metadatos. Si entras en Facebook sabes cómo es la gente, conoces las caras de quienes se han registrado, tienes información demográfica. No tenemos eso en Twitter. Tenemos trazas, que es como intentar adivinar qué tipo de coche es oliendo el humo que expulsa y, encima, el coche ya se ha ido y tú intentas trabajar con eso. Así que lo usamos en una base de datos con 40.000 nombres y utilizamos varias técnicas para limpiar los nombres que la gente da en Twitter y ver así si es un nombre de hombre, de mujer o unisex. La mayoría de la gente son desconocidos. Podemos decir también que la gente miente en sus nombres y en el género que ponen en Twitter, aunque estoy seguro de que poca gente lo hace. Pero, en realidad, creemos, basados en trabajos anteriores, que poca gente lo hace y que hay más datos que puedes dejar que

vengan como falsos positivos. Bien, lo interesante es que cuando hemos aplicado los datos de Reino Unido, dejando de lado los nombres unisex y los nombres que no hemos podido identificar, el 48,8% corresponden a nombres masculinos y el 51,2% a femeninos, utilizando datos de años atrás y usuarios únicos. Esto coincide con el censo de Reino Unido de 2011, con algún decimal, que directamente corresponde con eso, tanto como si nos hemos equivocado y ha dado la coincidencia de que es el mismo lugar o es en realidad una aproximación precisa del género. Y creo que es un proxy preciso. Dejadme que os dé un ejemplo. Perdón, mis ejemplos están hechos en Gran Bretaña, pero este es uno de las Olimpiadas. Y lo que podéis ver aquí son sentimientos positivos y negativos haciendo uso del ranking del censo. Está dividido por género, por lo que esto de arriba es el sentimiento positivo registrado, los picos representan picos de positividad, los rosas corresponden al género femenino y los azules al masculino. En la parte de abajo está lo negativo, hablando de sentimiento, también. Como podemos ver, está basado en el tiempo. Esto corresponde a un periodo en particular entre las 8:00 y las 11:00 horas. En realidad, fue en un súper sábado, fue cuando el equipo de Gran Bretaña (Team GB) consiguió tres medallas de oro seguidas. Y, de forma interesante, lo que podéis ver, en particular, es que hay picos en los sentimientos, puntos clave en el evento... Estos son unos datos de social media muy poderosos porque podemos cogerlos de minutos a segundos donde puedes ver qué está pasando al mismo tiempo que el evento real está ocurriendo y, en particular, si nos fijamos en la medalla de Ennis, todos los picos de sentimiento




son rosas, las líneas rosas siempre estaban más altas. Lo que significa que si el algoritmo de detección de género era correcto, los tuits de las mujeres tienden a ser más positivos cuando utilizan su propio idioma que los tuits de los hombres. Es consistente, en particular, aquí, cuando Ennis consigue ganar la medalla.

Algo de lo que quería hablar es del trabajo que está en proceso en el que se está identificando la edad y ocupación y en este sentido esencialmente creemos que hay formas de investigar las edades y de investigar la ocupación utilizando los metadatos que utilizamos de Twitter. No tienes que usar los tuits necesariamente, ya que tienes información en el campo de la descripción que la gente utiliza para describirse a sí mismos y el momento en el día en el que tuitean si se trabaja en patrones de turnos. Usan cosas como ‘me gusta hacer’, tienen en su red a amigos por lo que puedes tener un diagrama de la red y ver quién está tuiteando, podemos ver si son productores de información o consumidores. Y, cogiendo todas estas cosas juntas podemos empezar a pintar una imagen, empezar a pintar colores en el mapa sobre qué clase de personas son las que tuitean gracias a las características demográficas que están a su alrededor. Muchas gracias.

Turno de preguntas

Mi felicitación por la ponencia. No solamente estoy de acuerdo con las conexiones que existen. Tengo la suerte de dedicarme al social media y a la integración con datos procedentes del Big Data y de los análisis científicos. Lo que no sé, desde el punto de vista académico, es

cómo es exportable esto que hemos visto a un modelo de negocios, a la explotación desde las grandes compañías, en el sentido de que, entre otras cosas, las grandes compañías no siempre entienden el fenómeno que está relacionado con el social media y, específicamente, con Twitter. Términos como conversación abierta, como hacktivismo entendido no como ataque. No sé cómo se puede exportar este tipo de estudios o cómo se puede defender desde el punto de vista académico la exportación de estos estudios a la explotación en un mundo de negocios.

COSMOS está diseñada como una plataforma emancipadora, está diseñada para permitir acceso. Está fundada por Research Councils UK y, una vez que está desarrollada, que está escalada para la mayoría de los usuarios, se encuentra disponible gratuitamente dentro de Reino Unido y ellos pueden usarla. En este sentido, está diseñada para permitir el acceso a otros, precisamente, para eliminar el monopolio que las compañías privadas tienen de los datos en este momento. Nuestra mayor preocupación es que en todas las tecnologías que las compañías utilizan para identificar diferentes ocupaciones o, incluso, sentimientos, son cajas negras, no sabemos cómo se han producido. Y, como no sabemos cómo se han producido, no sabemos si se han hecho bien. Todo lo que hacemos nosotros está publicado. Puedes verlo, puedes criticarlo y eventualmente puedes escribir en los márgenes para mejorarlo, este es el caso. Por lo que nuestra tecnología es un reto precisamente para los grandes negocios. No me refiero a comercializarla, sino para utilizarla.




Santiago Moral

Buenos días, comenzamos la conferencia de clausura de esta cuarta edición que hacemos del curso de verano desde el grupo Centro de Investigación para la Gestión Tecnológica del Riesgo. El objetivo que teníamos Regino y yo era trasladaros qué han sido estos cuatro años, cuáles son las líneas de investigación, hacia dónde estamos yendo, qué es lo que se está planteando y el porqué, el fondo de toda esta iniciativa. Vamos a intentar poner de contexto dónde se enmarca esta iniciativa a nivel internacional y cuál es el momento histórico que estamos viviendo. Yo daré una visión general y luego Regino explicará los trabajos que

UN MODELO DE COLABORACIÓN UNIVERSIDAD-EMPRESA: LA RELACIÓN

ENTRE EL GRUPO BBVA Y LA URJC

Regino CriadoCatedrático de Matemática Aplicada, Universidad Rey Juan Carlos (URJC)

Santiago Moral RubioDirector de IT Risk, Fraud & Security, Grupo BBVA


estamos haciendo fundamentalmente alrededor de una Cátedra de Riesgo Tecnológico que hemos creado recientemente con la Universidad. Finalmente daré un track de cuál ha sido la historia del Centro de Investigación que fundamos con la Universidad en el año 2010.

A ver, ¿cuál es el momento histórico que estamos viviendo en materia de Seguridad de la Información? Es muy interesante, como habéis podido observar estos dos días y medio que llevamos, hay una relación muy interesante entre la nueva Matemática y su aplicación en la industria tecnológica. Es decir, yo creo que algo que sucedió en el origen de esta disciplina y tenemos a Shannon o a Turing, que




antes comentaba ayer Miguel Ángel ha vuelto a suceder. Y es que, de repente, para conseguir el siguiente gran avance, en materia de tecnología, la disciplina científica vuelve a ser necesaria. De hecho, todo lo que habéis estado viendo estos días son fórmulas matemáticas y mas fórmulas matemáticas y más formulación matemática y más estadística y más análisis numérico, ¿vale? Sin toda esa capacidad y sin toda esa nueva matemática y algunos avances que esta liderando Regino con su equipo, es imposible dar el siguiente paso. El siguiente paso lo están liderando una conjunción de científicos y tecnólogos. ¿Cuál es la posición relativa que tenemos en estos momentos en la historia? Pues, hay un contexto económico-cultural que es muy importante resaltar y que se está viendo, donde se esta poniendo de manera muy patente encima de la mesa es en varias reuniones que está habiendo en California, en distintos sitios, en San Francisco, Silicon Valley apadrinado por el ICEX, por el Instituto de Comercio Exterior, y en una relación muy estrecha que está teniendo con la Cámara de Comercio Hispano-californiana, en la cual está empezando haber una ligazón y una relación que es tremendamente interesante. Lo que pasa es que desde aquí, desde España, y con los problemas domésticos le perdemos un poco la perspectiva. Pero nos encontramos en una situación en la cual en la Costa Oeste, el liderazgo del mundo hispano, en la parte en las disciplinas de las Tecnologías de la Información, está creciendo de manera espectacular. Eso significa que nos encontramos, por ejemplo, que el CIO de HP es hispano, el CIO de Facebook es hispano, el CIO de ATT es hispano, y así podemos ir sumando una colección de primeros responsables en Informática

en grandes corporaciones estadounidenses que son de origen hispano. Y es una realidad cada vez más latente. De hecho, estamos liderando de alguna forma la participación, o estamos intentando liderar junto con otras entidades como el Santander y Telefónica, la participación del mundo hispano en esta corriente creciente participando en una asociación estadounidense que es el HITEC, el Hispanic IT Executive Council. Es la asociación que reúne a los máximos responsables en materia de TI de origen hispano. Esta asociación va cobrando cada vez más fuerza y está en una relación muy estrecha con el ICEX, y es quien esta ayudando en la confección del Spanish Tech Week, que es una reunión semanal de conocimiento, emprendimento, inversores y ciencia, de origen español. La más importante que hemos tenido en su origen ha sido en California y la apadrinó personalmente su alteza el entonces Príncipe de Asturias, ahora rey de España. Este movimiento, que está acompañando el posicionamiento de empresas, está haciendo que cada vez tengamos una relación más estrecha entre conocimiento generado en España y utilización de este conocimiento y de esta ingeniería en Estados Unidos. Hay dos bazas muy importantes que es clave tener en contexto. La primera de ellas es un movimiento donde quien está haciendo de protagonista no es España sino Latinoamérica. Es decir, todo este colectivo que está impulsando y haciendo crecer el mundo hispano en Estados Unidos tiene, hoy por hoy, poca presencia española, y es fundamentalmente presencia latinoamericana. Es uno de los ejes.

El segundo eje es que en materia de Seguridad hablando específicamente, España es uno de los principales prescriptores internacionales. ¿Por




qué es así? Después de Estados Unidos y de Israel, somos el principal fabricante de tecnología de seguridad por número y por expansión en el mundo. En el cuarto lugar están los Países Nórdicos, que están trabajando fundamentalmente dentro de Seguridad en los ámbitos de gestión de identidad. ¿Qué es lo que sucede? Y aquí nos encontramos en España con un Safelayer, con un Bitácora o con un Prot-On. Nos encontramos bastante tecnología; es por una razón muy simple: que las corporaciones españolas trabajamos de manera mayoritaria con Latinoamérica y eso significa que la prescripción de tecnologías que hacemos aquí, una vez hecha y realizada, se implanta en todo un continente y entonces eso da capacidad de que se desarrollen empresas de manera conjunta. Cuando ponemos estos tres ejes juntos, es decir, cuando ponemos un eje de interés dado el momento de crisis que tenemos en España de salir hacia el exterior, nos encontramos de una manera receptiva sobre todo los ámbitos de California, y en segundo lugar los ámbitos de Boston y de Miami en Estados Unidos, pero de manera muy importante los californianos. Nos encontramos con una comunidad hispana muy fuerte, que está abanderando un crecimiento hispano, sobre todo en la Costa Oeste en materia de TI, y ponemos a jugar esos tres ejes, lo que nos encontramos –y esto se comenta con los estratos más altos del gobierno y con el ámbito político– es en una situación en la cual podemos terminar generando un polo tecnológico en materia de Seguridad en España a poquito que nos esforcemos. ¿Por qué? Porque tenemos la capacidad de prescripción, porque tenemos multinacionales, pocas pero bien implantadas

en Latinoamérica de origen español. Ahora está habiendo un movimiento de Latinoamérica también hacia España para entrar en Europa, con lo cual la prescripción ya la podemos ir haciendo conjunta. Ingeniería de origen hispano, se implanta primero en toda Latinoamérica y, con esa base de clientes, es capaz de dar el salto hacia California, hacia Silicon Valley, porque ya se encuentran con productos que no están en primera ronda de financiación, sino que ya tienen un núcleo de clientes importantes a nivel mundial. Están probados, contrastados y, a partir de ahí, pueden entrar en rondas de financiación mucho mas interesantes para colocarlo como producto en Estados Unidos.

Es ahí donde hay que enmarcar esta iniciativa. Es decir, la iniciativa que arrancamos hace cuatro años de creación conjunta entre el grupo BBVA y la Universidad Rey Juan Carlos, del Centro de Investigación para la Gestión Tecnológica del Riesgo, es tener un sitio físico, concreto, donde empezar a depositar los rudimentos que permitan que empresa y universidad estemos colaborando, poniendo la empresa fundamentalmente dos ámbitos que tenemos que cubrir y es, tenemos los datos para trabajar y tenemos la necesidad. Es decir, si nosotros queremos hacer analítica de prevención de fraude, nosotros tenemos los datos de fraude en tarjetas y la necesidad, sabemos lo que conseguir. Y lo que necesitamos es la parte científica que nos vaya incorporando todo ese movimiento científico de datos, de creación de nuevos algoritmos, utilización de matemáticas de redes complejas, que ahora comentará Regino. Vayan incorporándola pero tengan los datos en los que probar porque los avances científicos




solamente se pueden consolidar cuando detrás de una idea se puede contrastar y se puede probar y, de manera empírica, se puede depurar. Esa es la relación interesante y ese es uno de los objetivos fundamentales que nos dimos cuando se creó el Centro de Investigación. Si habéis estado en la presentación anterior que hablaba de tuits, de Twitter, de social media… Estaba comentando con Regino en el intermedio “oye, no sería descabellado, y está perfectamente dentro de los objetivos de este Centro de Investigación para la Gestión Tecnológica del Riesgo, que pudiéramos crear una base de datos con los tuits de dos grandes ciudades de España, los dejáramos completamente anonimizados para no tener ningún problema de protección de datos, y eso quedara como base estable de trabajo sobre el que poder hacer análisis semántico de comportamiento, de querencias, de tendencias, de evolución. Y eso es parte del objetivo porque el objetivo que tenemos, como grupo empresarial, es ser partícipe de todos esos avances, ser de los primeros y de los avanzados en obtener rentabilidad, en obtener rendimiento de alguna forma de todos esos avances, y por tanto, tenemos interés en ponerlos a disposición del mundo científico para que haya un enriquecimiento común. Eso es un poco la perspectiva principal. Tenéis en esta primera trasparencia algunas ideas más. Hay una que es muy importante, que a Regino le gusta destacar mucho, que es el cambio cultural. ¿Qué significa el cambio cultural? Pues significa que podamos hablar en la empresa, de que estamos trabajando con la universidad y no se nos vea como bichos raros y que en la universidad puedan trabajar con la empresa de manera

estable, estableciendo unos ciclos. Ya llevamos cuatro años, este es el cuarto año de colaboración y que tampoco se vea eso extraño, es decir, que no sea porque al final esto no ha degenerado en que le tengo subcontratado a la universidad el mantenimiento de un producto, sino que estamos en un ciclo permanente de mejora de conceptos y de ideas. Ese tipo de relación es el cambio cultural que tenemos que conseguir que se produzca tanto en la empresa como en la universidad. Cedo la palabra a Regino para que nos cuente cuál es la visión, desde el punto de vista de la cátedra que estamos creando con la empresa del Grupo BBVA, Innovation 4 Security, y la Cátedra de Matemáticas.

Regino Criado

Bueno, muchísimas gracias por la presentación de ‘Mac’, pero en cualquier caso, uno de los resultados que han conformado y que pueden formar parte del mérito que se nos pueda atribuir, es haber conseguido aglutinar en torno a las herramientas de análisis de riesgo y tecnologías de detección de fraude a un grupo tanto de tecnólogos de los que forman parte profesionales pertenecientes a Innovation 4 Security y a distintas partes del grupo BBVA, como a jóvenes talentos investigadores con distintos ‘expertizajes’ que van desde la mecánica hasta la estadística, pasando por la teoría de redes, criptografía y un largo etcétera, y que están aglutinadas en torno al Departamento de Matemática Aplicada de la Universidad Rey Juan Carlos y en torno, en este caso, a la Cátedra. El título de la Cátedra es largo pero cuando menos ilustrativo: es la Cátedra




de Innovación en Seguridad de la Información, Prevención del Fraude y Gestión del Riesgo Tecnológico. Todos esos elementos configuran una declaración de intenciones acerca de cuál va a ser el contenido de esa colaboración entre el grupo BBVA, en este caso particularizado o concretado en la empresa Innovation 4 Security, y el grupo de matemáticos y físicos de la Universidad Rey Juan Carlos del que me honra formar parte. Como misión, aquí aparece el desarrollo de técnicas científicas que formalicen nuevas aproximaciones a la gestión de riesgos tecnológicos, que aporten nuevas técnicas de prevención del fraude tecnológico y que promuevan su conocimiento tanto en el sector científico, como en el sector de la seguridad de las Tecnologías de la Información. Aquí cabe decir que señalaría el apartado científico: los científicos somos observadores del mundo que nos rodea y, en algunas ocasiones, nuestro objetivo es replicar o reproducir fenómenos o sistemas que son observables, y en otro caso, fundamentalmente, hemos tenido esta mañana dos charlas relacionadas con esta segunda parte, hacer predicciones de lo que puede suceder en un sistema del que se conocen algunos elementos. Entonces, dentro de esto que estamos comentando aquí, aparecen, como digo, tres vertientes: una de formación en todos estos temas, otra de investigación y otra de divulgación. Iremos concretando, desarrollando algunos, pormenorizando los elementos que componen cada uno de ellos. Como primer hito en el ámbito de las actividades de formación que se van a desarrollar desde esta nueva Cátedra universidad-empresa, que me atrevería a tildar de un modelo

de verdad de colaboración entre una empresa y una universidad. Ese modelo que tantas veces en este país se ha dicho que es muy difícil, la trasmisión del conocimiento efectivo entre esas dos grandes patas que constituyen una base sobre la que fomentar el desarrollo a todos los niveles, tecnológico y científico, de una sociedad. En este caso, cabe señalar que un solido avance en ese desarrollo se produce cuando se conjugan en un mismo entorno el conocimiento de las últimas tecnologías y relaciones con elementos y herramientas del mundo de la empresa, con la creatividad y la sensibilidad hacia la creación de modelos que, realmente, permitan mejorar algunas de esas herramientas existentes que, en este caso, sería la parte que correspondería a la universidad.

Vamos a desarrollar y esto sucederá en este curso que arranca este año, posiblemente, en el mes de enero, un curso de formación continua en la Universidad Rey Juan Carlos, abierto, en el que vamos a tratar de incorporar un temario absolutamente novedoso. Es decir, un curso dedicado a la investigación de la prevención del fraude en el que aparezcan asignaturas como redes complejas para el riesgo, el fraude y la seguridad. Además de otros elementos que configuran, bueno pues todo un conglomerado de materias que permitan garantizar una sólida formación en estos temas. Esta formación en partes: ingeniería de la decisión, teoría de juegos, patrones, machine learning, etc., constituye un primer avance de lo que, más adelante y previa aprobación por el Organismo Oficial que opera en España que es ANECA del Máster en Investigación, con un contenido ampliado y relacionado con este




primer avance que se desarrolla en este curso, pues formarán parte de las actividades, digamos ‘estrella’, a nivel de formación, planificadas para este próximo curso 2014/2015. Además, está previsto el desarrollo de sesiones monográficas, sesiones de formación. Hasta ahora se han desarrollado dos en el ámbito de la Cátedra: una conferencia dictada por Francisco García Marín sobre criptografía en mainframe de IBM y otra por Dario Fiore acerca de “Verifiable Delegation os Computation of Outsourced Data”. Ambas fueron impartidas en la Universidad Rey Juan Carlos con asistencia de alumnos de los últimos cursos de Informática. Además, dentro de este ámbito, está prevista la participación y la colaboración en el desarrollo del curso interno de la Universidad Rey Juan Carlos, hay cuatro en concreto para la obtención del Certificado de Director de Seguridad que otorga el Ministerio del Interior.

Investigación. En Investigación aparecen los temas que estamos tratando en este momento con mayor o menor avance. A lo largo de estos cuatro años de colaboración y, en este caso, estoy hablando de lo que tiene que circunscribirse al ámbito de la colaboración dentro de la cátedra de Innovation 4 Security y la Universidad Rey Juan Carlos, tenemos al menos estos cuatro primeros temas de investigación. El primero de ellos, sobre el que seguramente hablaremos con un poquito más de detenimiento en lo sucesivo a lo largo de la charla, se refiere a la Certificación de Algoritmos de Cifrado, en concreto, el FPE. En la ‘tokenización’ se supone un cifrado que respeta el formato ¿de acuerdo?, de manera que uno tiene ‘tokenizado’ un string de las mismas características que el string antes de ‘tokenizar’.

Prevención del Fraude con Redes Parenclíticas. Como bien ha dicho Santiago, la Teoría de Redes ahora mismo es una de las materias científicas que se está revelando fundamental, no solo por ser una de las de mayor actualidad, sino también por ser una de las que mayor aplicación tienen. Surgen de la mano de la Teoría de Redes disciplinas como la Econofísica o Econophysics, donde se utilizan, se desarrollan utilizando como base las redes complejas en modelos de predicción de la evolución de los mercados o del posible crecimiento o, incluso, de otros elementos que están en torno a la economía. Cabría pensar si seríamos capaces de crear algo parecido, lo que hablaríamos de risk physics o Teoría de Redes Complejas aplicadas a la gestión, detección y elaboración de herramientas relacionadas con la prevención del riesgo tecnológico. A lo mejor habría que incluir alguna de psicología básica. Me comentaba un compañero cuando estábamos entrando: “eso que llevas ahí del primer congreso hispano-marroquí de Matemática Estadística, como está escrito en árabe a lo mejor todo el mundo piensa que llevas ahí un tic-tac” y es que parece que, psicológicamente, todos tendemos a identificar ciertos hábitos con cuestiones relacionadas con el riesgo que no vienen al caso. Bueno, además de esto, hablaremos también de este proyecto que de alguna forma será continuación del de la certificación, que sería la extensión a la nube de estos métodos de ‘tokenización’. Y, finalmente, una teoría que sí que estaría relacionada con lo que acabo de mencionar antes, que consistiría en el análisis de las bases matemáticas y físicas que se usarán como soporte en el desarrollo de la Teoría de la




Seguridad de la Información. Nos reíamos antes, cuando estábamos viendo ahí la formula de la entropía, pensando en ella entre otras cosas como entre uno de los elementos que seguramente debemos de afinar y definir en el contexto adecuado para trabajar sobre ello.

Dentro del apartado de Divulgación está este curso de verano, que espero se esté desarrollando a plena satisfacción de todos los participantes y ponentes. Las jornadas que se desarrollarán a partir de mañana avanzaremos bastante. En mi caso concreto, llevaré una conferencia donde trataremos de forma específica la aplicación de las redes parenclíticas a la detención del fraude en tarjetas, con todas las herramientas, con todos los elementos y los problemas que hay. Y, finalmente, a las revistas tanto de divulgación, como lo que se refiere a la difusión de actividades de la Cátedra y de, incluso, de su formación en las revistas SIC y Red Seguridad, como a las revistas puramente científicas. En concreto, se publicará por Springer lo que podría llamar, más que un artículo, un paper, un minibook, donde se recogen todas las conclusiones y todos los elementos que configuran el tratamiento de Gestión del Riesgo Intencional en su división de riesgo estático y riesgo dinámico que se desarrolló en años anteriores y que, finalmente, se ha visto culminado este año, y una derivación de este artículo que saldrá, de hecho, ya está prevista la publicación del algoritmo relacionado con la distribución del valor desde las bóvedas a la hora de modelar una red. Concretamente: “Complex Network of Intentionality: an algorithm to distribute the value of the information”. Este artículo será publicado por la revista Networks and Heterogeneous Media del American Institute of Mathematics Science. Esta es

una revista importante dentro del ámbito científico, puesto que forma parte del elenco de revistas, de journals, que están impactando y que se consideran de máxima audiencia y repercusión en el avance tecnológico y de la ciencia.

Por último, hay que recoger también, dentro del ámbito de la colaboración con Innovation 4 Security, nuestra participación en el programa europeo ‘Horizon 2020’, que tiene como objetivo desarrollar parte de la metodología Casandra y, en lo que se refiere al apartado específico de nuestra participación, lo que tiene que ver con la formalización matemática y el desarrollo del soporte científico de todo lo que tiene que ver con el riesgo intencional y es a través de la visión y de la modelización dada por la Teoría de Juegos y por la Teoría de Redes Complejas. El objetivo, por supuesto, consiste en estandarizar la metodología de Análisis de Riesgo Intencional de manera que sea reconocida por los órganos reguladores, además del desarrollo y del lado teórico correspondiente con un soporte con un fuerte basamento científico. La creación de una comunidad interesada de manera que se pueden desarrollar herramientas open source y, finalmente, la validación de la herramienta donde aparecen otras series de instituciones que permitirán validar la misma.

Santiago Moral

Regino nos ha dado una pincelada de lo que son las líneas de investigación y las líneas de avance que estamos llevando, muy enfocado a la parte docente,




a la parte de publicación y de algunos proyectos concretos. Nos retrotraemos al inicio de 2010. Se firma la creación del Centro de Investigación por la Gestión Tecnológica del Riesgo entre el grupo BBVA y la Fundación Universidad Rey Juan Carlos. Los objetivos son los que hemos comentado anteriormente, es decir, tener un espacio común donde grupos científicos internacionales puedan venir a trabajar sobre datos anonimizados del banco, donde nosotros pongamos los objetivos de cuál es el tipo de resultado que queremos tener y esto se puede hacer de una manera natural, sin estar trabajando por excepciones. Y parte de los resultados son los que ya ha ido comentando Regino.

¿Dónde nos focalizamos? ¿Cómo elegimos en qué cosas trabajar y en qué cosas investigar? Hace dos años hicimos para una presentación como departamento en San Francisco en un foro tecnológico especializado que mezcla tres ámbitos: Big Data, Mobility y Security. El Amphion Forum es un foro que cada seis meses se realiza en distintas ciudades principales de Estados Unidos, que aglutina a las empresas tanto fabricantes como proveedores, que tiene como nexo de unión esos tres ámbitos: Big Data, Movilidad y Seguridad. Para esa conferencia, hicimos un análisis de sensibilidad de cuáles son los puntos, las áreas en las que estamos interesados en crear investigación y, posteriormente, fue presentada en la RSA Conference, hace año y medio. Allí, con distintos consultores, fue validado el modelo. Básicamente la idea es la siguiente, esta gráfica, bueno como toda gráfica de consultor da igual lo que pongas, lo bueno: arriba a la derecha, ¿no? Si estás bien arriba a la derecha. Básicamente,

aquí lo que hemos intentado identificar es cuál es la aportación de valor que tiene para el sector financiero, y dentro del sector financiero, por un banco de un decidido carácter tecnológico como es el grupo BBVA, y cuál es el tipo de participación que se debería tener en la génesis y en la gestión de ese tipo de tecnologías desde el grupo. Entonces, la aportación de valor va de menos a más y la participación en la génesis y en la gestión de esas tecnologías va de menos a más. Lo dividimos en dos grandes grupos y es: si nos interesaría como grupo estar en un grupo de followers o estar en un grupo de leaders. Y, dentro de followers pues simplemente participando, conociendo un poquito los proveedores, pudiendo influir en los fabricantes, sería esto de aquí abajo. Y, luego, que nos permitieran participar en el roadmap podría indicar al fabricante si nos interesa más que se vaya, o se incorpore algún tipo de tema o, directamente, teniendo algún tipo de participación en la propiedad, quiere decir que no sea nuestro pero que pudiéramos estar en el board donde se decida hacia dónde tiene que ir esa tecnología. ¿Cómo medimos la aportación de valor? Bueno, lo que hay por detrás es un tipo de escala donde la aportación de valor la medimos en cuánto una pequeña diferencia genera beneficio económico. Entonces, si nos vamos a este extremo, a mí pequeñas diferencias en sistemas de provisión de identidad no van a hacer que venda más libretones. Es imposible. No tiene correlación. No voy a captar más clientes por Internet, no voy a fidelizar más a ningún cliente. Sin embargo, tenemos arriba a la derecha, muy pegado ya allí, un buen algoritmo de predicción de comportamiento sí que puede hacer que yo diseñe muy buenas campañas on line, muy




acertadas, que me permitan mejorar mi capacidad de fidelización o, incluso, que me permitan anticiparme a problemas financieros que puedan tener mis clientes y que me permitan reaccionar de manera proactiva al cliente. Son sistemas de alta aportación de valor donde pequeñas diferencias entre dos competidores maximiza o es donde se maximizan el valor, en el sentido económico directo, es decir, donde una pequeña diferencia te puede generar más beneficio económico. Eso es lo de aportación de valor. Aportación de valor es que pequeñas diferencias te hagan ganar más dinero que la competencia de manera real y aquí es donde están ordenadas, de manera natural, todas, es decir, cualquier tecnología que quede en el cuadrante de arriba a la izquierda o en el cuadrante abajo a la derecha estaría mal ubicada. No nos interesa en ningún sitio no tener ningún tipo de participación en cosas que sean de alta participación de valor o tener muchísima participación en cosas que no nos aporten ningún tipo de valor, ningún tipo de hecho diferencial frente a la competencia. ¿Dónde queremos investigar? Pues, fundamentalmente, en aquellas que están en aquel cuadrante, ¿vale? Y, con especial relevancia, tenéis un poquito ordenadas aquellas que más esfuerzo y más dedicación nosotros le estamos poniendo. Esos numeritos son la ordenación, por lo cual para nosotros uno de los elementos más interesantes es la ‘tokenización’, y queremos estar en ello, fabricar algoritmos, ser parte del futuro de esa ‘tokenización’ porque entendemos que nos permitirá ir de manera muy decidida hacia un objetivo nuestro, que es el banco digital. Porque nos permitirá de manera más natural poder securizar información de los clientes fuera de las fronteras de nuestra organización y

nos va a permitir poder dar ese salto cualitativo, anonimizar la información de manera natural dentro de nuestra organización, pero que el usuario propietario de esa información la pueda utilizar cuando está fuera. Eso es el Principio de Tokenización.

Estamos muy interesados en todo lo que son algoritmos predictivos y en lo que el Big Data aporta a la seguridad; no tanto a la seguridad del Big Data, que eso lo tenemos que hacer de una manera natural, sino el Big Data como uno de los elementos de base para todo el aprendizaje, el machine learning y la detección, como lo que hemos estado viendo hoy, por ejemplo, pues prácticamente se ha estado dedicando a este tipo de avances. Esta es la forma de decidir en qué trabajamos y en qué no. Por ejemplo, estamos muy interesados también en todo lo que es ciberbiometría, más que la utilización clásica de la biometría es la utilización de la biometría no presencial, no forzada, no voluntaria. Es decir, la utilización de la biometría en la nube. En esa sí estamos mucho más interesados que en la biometría clásica. Este es el eje que nosotros utilizamos para decidir hacia dónde nos interesa trabajar. De tal forma que cuando trabajamos con las universidades y con los grupos de investigación, cuando vemos avances importantes que un grupo de investigación, un grupo científico puede producirnos, es cuando comienza esa relación de la que hablaba antes Regino, a partir de ahí les dedicamos algo del presupuesto, algo de tiempo, tomamos nuestros datos, los ponemos a disposición para la investigación, y empezamos a trabajar de manera conjunta para ver si las hipótesis que se están dando en el mundo científico




realmente son empleables y utilizables para nosotros.

¿Algunos resultados? Pues Regino puede contar mucho mejor que yo los resultados. Tuvimos ya a finales de 2010 una primera versión del algoritmo de cifrado con preservación de formato, que fue muy interesante. Hicimos con la ayuda de la Universidad la primera implementación de un algoritmo de ‘tokenización’ dentro del entorno host de IBM. Ahora estamos validándolo, por ejemplo, en el proceso en el que estamos hemos aprendido muy bien a ‘tokenizar’ los datos uno a uno, pero para cuando nos vamos a llevar un Big Data fuera, o nos vamos a llevar un lago de datos hacia el exterior o, no que esté hacia el exterior pero que esté accesible desde otro sitio aunque lo sigamos manteniendo dentro y queremos ‘tokenizar’ de manera masiva, pues sabemos ‘tokenizar’. Sabemos comernos las aceitunas de una en una, pero un saco de golpe no sabemos. Eso es lo que estamos haciendo, ver si ponemos todas las aceitunas en ristra y las espachurramos todas a la vez o cómo se hacen los procesos de ‘tokenización’ masivos, que es una de las cosas que estamos aprendiendo con ellos. Hemos tenido, por ejemplo, toda la parte de formalización académica de los resultados. Y lo último que hemos obtenido, aunque hemos perdido un poquito el enlace, es un interés de la ONU por estos algoritmos. En uno de estos foros entramos en relación con la oficina de Big Data de Naciones Unidas. Naciones Unidas ha creado recientemente, hace un año y medio, una oficina de Big Data donde se ha entrado en el concepto de donación de datos. Naciones Unidas tiene el objetivo de poder analizar y utilizar las tecnologías de Big Data como alerta temprana

de movimientos de masas de personas y, para eso, lo que necesita es que el sector financiero y el sector ‘telco’ entremos en un concepto de donación de datos. Es decir, si pueden analizar con Big Data datos de movimientos de llamadas de móviles y datos de movimientos de tarjetas, en tiempo casi real, en sitios de alto riesgo, pueden identificar movimientos migratorios masivos que esté habiendo de huidas de masas de cientos de miles de personas. Uno de los grandes problemas que tiene Naciones Unidas para conseguir esto es primero que, por ejemplo, en Europa estaría prohibido per se. Yo no puedo hacer donación, yo no puedo coger una información y sacarla fuera porque no soy el propietario de ella, soy el que la trata, el propietario al final es el ciudadano. Y, hay otros países, otras entidades que, sin tener esta regulación, pues no se fían de tomar toda esa información de negocio y ponerla a disposición de un tercero. Entonces, uno de los aspectos interesantes que se estuvo tratando con esta oficina, fue entrar en el concepto de donación de algoritmos. ¿Cuál es el concepto de donación de algoritmos? Algoritmos de ‘tokenización’ que sean libres de patentes, como en este que estamos trabajando, que pudiera ser utilizado por Naciones Unidas para entregarlo a aquellas empresas que sí estén dispuestas a hacer donación de datos para que lo puedan utilizar como bahía de la anonimización segura y certificada. Entonces, una de las líneas y de los sitios donde empezar a tratar y a aprobar este tipo de algoritmos y de avances es, directamente, con esta oficina. Hemos tenido… si lo quieres tú comentar unos temas de grafos, de redes complejas bastante interesantes como resultados...




Regino Criado

Bueno, este es uno de los proyectos que se ha desarrollado y que finalmente hemos podido cuantificar, incluso, llegar a la primera fase de implementación de una herramienta para cuantificar el riesgo de una red, ¿de acuerdo? Entonces, los elementos que forman parte del análisis de riesgo intencional, en cada uno de los elementos, en cada uno de los nodos, que son distintas unidades, módulos, terminales, etc., del grafo, de la red y las conexiones entre ellas pues aparecen como parámetros interesantes con vistas al análisis del riesgo, la accesibilidad, el valor y la anonimidad. Dentro de esos tres parámetros que permiten de alguna manera estudiar el riesgo potencial de la red, además de su cuantificación tanto local como a nivel global de la red, se ha tenido que diferenciar entre lo que llamamos riesgo estático y riesgo dinámico. El riesgo estático forma parte del riesgo relacionado, de alguna forma, con aquellos hackers o intrusos que utilizan los canales usuales para penetrar en la red, ¿de acuerdo? Por ejemplo, entraría dentro de la clasificación relacionada con el riesgo estático, pues el phishing o la suplantación de identidad. El riesgo dinámico tiene que ver con la utilización de aquellos caminos no detectados por ignorancia, por no previstos, no detectados porque se pueden producir vulnerabilidades que permiten al intruso ir dando saltos de una parte de la red a otra y donde todo lo que tenga que ver, en este caso fundamentalmente, con el parámetro de accesibilidad de los datos serían los que permitirían diseñar dispositivos de gestión y prevención del riesgo.

Santiago Moral

Es uno de los trabajos más interesantes que hemos tenido y que estamos teniendo, sobre todo, porque nos está abriendo la puerta y el conocimiento hacia los siguientes. Cuando estamos haciendo este trabajo y estamos empezando a diferenciar el tipo de incidentes y el tipo de riesgo que podemos tener entre estáticos y dinámicos, atendiendo a cómo se configura el grafo, estamos profundizando en ver dos modelos de control radicalmente distintos que, históricamente, los hemos tenido separados pero que no éramos conscientes de las disciplinas de seguridad. Y es que tenemos mecanismos de autenticación, luego mecanismos de defensa de los perímetros. Ambos tienen un comportamiento radicalmente distinto, que cuando se modela del punto de vista de grafos queda muy evidente y muy patente y eso nos está permitiendo empezar a trabajar y entender cuáles son los volúmenes de caminos no conocidos y medir ahí la entropía, lo que estaba comentando al principio Regino, cuáles son los volúmenes de caminos no conocidos y usables que tenemos dentro de grandes sistemas de información.

El trabajo sobre nuevas metodologías para el análisis de riesgos está en una fase muy interesante de poder conseguir formalización matemática a una serie de metodologías que veníamos usando de manera recurrente dentro de distintos grupos de seguridad y, aquí, la parte más importante es que, aparte de que ya se han creado los primeros rudimentos, una base de datos de incidentes y se han ido refinando las metodologías, vamos a poder tener la base matemática por detrás que le dé la capacidad de que esto sea publicable. Al




ser publicable, es contrastable con el resto de la industria y, al ser contrastable, que sea un tipo de metodología que pueda terminar siendo parte de los estándares de gestión.

Hemos estado trabajando en aspectos de autenticación biométrica, fundamentalmente, de ciberbiometría, toma de imagenes desde cámaras para poder utilizar reconocimiento facial desde dispositivos móviles. Ahí hemos tenido avances bastante interesantes. Bueno, pues aquí está, casi cerrando la conferencia, el grupo de colaboradores estables del Centro de Investigación de Innovation 4 Security. En la parte de Matemática Aplicada, dirigidos por Regino, están Miguel Román, María Isabel González y Ángel Luis Pérez y, luego, tenemos una colaboración espectacular de Massimiliano Zanin. En la parte de Lenguajes y Sistemas de Información, más en la parte de desarrollo metodológico, estamos trabajando con el equipo de Esperanza Marcos, con Juan Manuel Vara, Marcos López, Javier Garzás y Jennifer Verde. En la parte de Arquitectura y Tecnología de Computación y Ciencias de Computación, que es la parte de biometría para todo lo que es face recognition y artificial vision, estamos trabajando con el equipo de Enrique Cabello Pardos con Isaac Martín, Cristina Conde y Oscar Siordia. En la parte de Economía de Empresa, menos ingenieril y más ligado a Matemática Aplicada a la economía, con Jesús Palomo, que es el Doctor que nos está ayudando en todo lo que es la aplicación de Teoría de Juegos, él es uno de los expertos que tenemos en este país. Ahí tenemos una colaboración de Ángel Hernando de la Universidad Carlos III. Éste sería el grupo estable de colaboradores del CIGTR dentro de la Universidad Rey Juan Carlos. Como

veis, cada vez trabajamos con más departamentos porque en las disciplinas que estamos utilizando cada vez hace falta más participación de distintos textos de distintas áreas del conocimiento científico.

Uno de los resultados es esta conferencia y son estos cursos. Uno de los objetivos dentro de la difusión que nos marcamos era conseguir tener en España un foro dedicado a la seguridad al riesgo tecnológico, al fraude, más alejado del mundo de los proveedores porque algún foro hay donde nos vemos usuarios de seguridad y vendedores de seguridad, implantadores e integradores, sino que fuera un foro científico donde pudiéramos traer, anualmente, a distintos expertos internacionales del ámbito científico o del ámbito empresarial pero más enfocado al plano didáctico.

Y cerrando ya, enlazo un poco con la clausura de esta edición del curso. Visto lo visto este año, por cuarto año, debo de agradecerle personalmente a Miguel Ángel Cano su trabajo y su dedicación para traer este grupo de conferenciantes tan interesante y a las personas que han estado colaborando contigo porque yo creo que, este año, hemos vuelto a mantener el nivel. Por lo que he ido hablando con vosotros entre cafés, realmente, el nivel que veníamos teniendo de distintos conferenciantes se ha conseguido mantener, y un año mas, pues hemos podido contar con cuatro o cinco expertos internacionales venidos, en este caso, desde Gran Bretaña, Suiza y de distintos puntos de Europa, ayer venía una persona desde Israel. Es decir, que hemos conseguido volver a juntar en dos días y medio media docena de expertos internacionales que han venido a




hablarnos de por dónde van los últimos avances, en este caso, este año tocaba de tecnologías. Como esto va de tecnologías de seguridad, prevención de fraude y gestión de riesgos, vamos alternando y dedicando cada uno de estos cuatro años con un foco puesto en distintos sitios. Este año tocaban más tecnologías. Era el año más techie, así que el año que viene tenemos que volver a enfocarnos más en las metodologías o en el fraude. Ya veremos, cuando cerremos hoy, hacia dónde nos enfocamos el año que viene y quién va a estar al frente. Ya tendremos que ir eligiendo quién va a estar otro año divirtiéndose con este foro. Hemos participado como CIGTR en distintos foros internacionales: hemos estado en el congreso Net-Works 1013, organizado por la Rey Juan Carlos; hemos estado en el ITGSM, organizado por el capítulo español de esta institución; en Securmática, en distintas charlas; una charla muy interesante que se dió en San Francisco, en Amphion Forum, hablando sobre las estrategias de evolución tecnológica que os he comentado antes y, bueno, reconociendo que tuvimos en el sector hace dos años con Esperanza Marcos, Doctora que está más en la parte de desarrollo metodológico. Esto era un poco lo que veníamos a contaros hoy, junto con Regino, las líneas de avance y las líneas de investigación que se están llevando a cabo. Dentro del grupo BBVA vamos a tener el viernes por la mañana una charla muy en profundidad para explicarles a los implicados en los desarrollos de los proyectos internos, toda la base matemática que esta detrás de las redes parenclíticas. Para nosotros, estamos viendo en las redes parenclíticas un recurso científico de un valor incalculable para la búsqueda de anomalías. Al final, nuestro oficio de

IT Risk, Fraud and Security, básicamente tiene tres vertientes: la primera, identificar bien a la gente; la segunda, garantizar que la gente haga lo que tiene que hacer; y, la tercera, demostrar que está siendo así. No tiene más. Es así de simple y así de complejo. En todo esto, la forma de monitorizar es fundamentalmente detectar anomalías, porque cuando alguien se pasa por otra persona, tengo que detectarlo como una anomalía, puesto que está utilizando sus credenciales, y cuando alguien está accediendo a donde no debe por canales que no sabemos que existen, lo que tenemos que hacer es estar buscando también esas anomalías. En el campo de la Detección de Anomalías en Redes Parenclíticas, están configurando como un recurso de un valor incalculable, porque están especializadas. Es un recurso matemático especializado en encontrar anomalías en volúmenes ingentes de datos, donde de cada dato tengo un número de atributos muy pequeño, muy limitado. Y eso es justo lo que tenemos. Cuando estamos haciendo prevención de fraude de cada operación tengo cuatro o cinco datos: la tarjeta, de dónde viene, a dónde va, el importe y el usuario. Pero poco más. Ahí, estas matemáticas están siendo especialmente interesantes y hay, en este momento, dos grandes campos que es donde está triunfando esta matemática por ahora: en la búsqueda de anomalías enfocadas más al sector financiero, en todo este tipo de capacidades, y enfocada a la biomedicina. Hay un artículo muy interesante, no si sé puede comentar, pero si lo puedes comentar yo creo que sería un buen cierre para ver cómo estos avances que generamos no valen solamente para nosotros, si no que tienen aplicaciones en la solución de problemas que no




tienen por qué ser tecnológicos pero que tienen una raíz científica común, por lo cual si lo puedes explicar damos por cerradas con esto las jornadas.

Regino Criado

Bueno, brevemente, para dar una idea en qué consiste este tipo de metodología, evidentemente el análisis de redes complejas está en la base de, bueno, pues muchos campos. En este momento, la ciencia puntera en el ámbito de la detección precoz, por ejemplo, de enfermedades neurológicas del estilo del Alzheimer o del Parkinson, pues tiene que ver realmente con el análisis de cómo están, de alguna manera, sincronizadas las respuestas que da el cerebro frente a ciertos momentos y ver qué partes se ven afectadas de alguna forma. Para entender un poco en qué consiste la Teoría de Redes y, en este caso, de redes parenclíticas, el mejor ejemplo que a mi se me ocurre en este momento, sería el equivalente al análisis por parte de un experto del resultado de un análisis de sangre. A todos nosotros, si no somos médicos, nos dan un análisis de sangre y nos dan un rango de valores que nos permiten decir que si el colesterol HDL esté por determinado sitio o si el número de hematíes está… Variable por variable somos capaces de decidir si hay algo que no se ajusta a lo que se entiende como normal. El médico es el que establece la relación que hay cuando dos o más de esos parámetros coinciden en el desarrollo de una enfermedad. No es lo mismo decir este parámetro, el número de hematíes, tiene que estar dentro de este rango, cuando ¡uy! colesterol alto, el malo, el número de leucocitos está por este lado. Relación

entre esos parámetros, ¿de acuerdo? En nuestro caso tiene que ver con que esa metodología que permite establecer relaciones entre los parámetros, correlaciones realmente, entre ellos, y llevarlos a la práctica con una metodología de detección de que algo es irregular, está en la base de las redes parenticlícas, cuyo nombre viene de ‘parénclesis’, es decir, desviación. Desviación en torno a lo que se supone que es normal, lo que se supone que es bueno. Esa sería un poco la idea. Claro, aquí hay un proceso muy importante porque la base, por decirlo de alguna forma, de las redes complejas es importante en la medida en lo que somos capaces de trabajar con grandes bases de datos con Big Data, limpiar esos datos (que es una cuestión bastante compleja). Además de limpiar esos datos, detectar cuáles son las variables importantes y cuáles no hay que considerar y, finalmente, cuando te quedan cinco o seis variables, decir “bueno y ahora qué podemos hacer con esto a la hora de detectar qué es normal y qué no es normal”. Sobre eso hablaremos el viernes.

Santiago Moral

Muchas gracias Regino. Quería volver a agradecer igual que en la apertura a su excelentísimo y magnífico rector señor Don Fernando Suárez por su amabilidad por dejarnos participar y por permitirnos que seamos partícipes de esta nueva edición de los cursos de verano de la Universidad Rey Juan Carlos, y a todos vosotros por vuestra presencia. Espero que en estos dos días y medio que habéis estado por aquí, os haya venido bien, os haya permitido aprovechar el tiempo, os haya




permitido conocer algunos nuevos avances importantes en el objeto del curso, que es al final la aplicación de la tecnología, sobre todo, de los avances científicos al avance tecnológico. A toda la organización que ha participado en el curso junto con Miguel Ángel. Daros a todos las gracias por el esfuerzo que lleva siempre el elaborar este curso y permitir que lleguemos hasta este punto. Muchas gracias por la participación, por el esfuerzo y por

la dedicación. Nada más. Un aplauso para todo el

equipo organizador.

Miguel Ángel Cano

Muchas gracias a todos por vuestra asistencia y

vuestras interesantes aportaciones.




ÁLBUM FOTOGRÁFICO


Centro de Investigación para la Gestión Tecnológica del Riesgo CI-GTR

Curso de Verano 2014d innoTSec14 – Innovación disruptiva en tecnologías de seguridad

I



Claudio Soriente, Investigador Senior en el Grupo de Seguridad de Sistemas (D-INFK) en el Instituto Federal Suizo de Tecnología (ETH) de Zurich, consideró en su conferencia que el control de accesos que tiene en cuenta la localización y el tiempo es la mejor forma de abrir un modelo de negocio al desarrollo de nuevas aplicaciones.

Aplicar técnicas de Inteligencia Artificial a la investigación de campañas APT fue el leit motiv utilizado por Vicente

Díaz, Analista Senior de Malware de Kaspersky Lab en el Global Research & Analist Team (GREAT), durante

su ponencia, la cual destacó por la practicidad de sus planteamientos.

II



Juan Caballero, Profesor Investigador Ayudante en el Instituto IMDEA Software, expuso con profundidad una técnica de escaneado cuya finalidad pasa por detectar servidores maliciosos en Internet y que se implanta en la herramienta denominada CyberProbe.

Como CEO y Cofundador de Ártica Soluciones Tecnológicas, Sancho Lerena hizo un exhaustivo

recorrido por la creación y consolidación de su compañía, cimentadas en el producto Pandora FMS, en un mercado

donde los grandes fabricantes de software tienden a copar el negocio.

III



IV

Andrés Tarascó, Cofundador y Auditor de Seguridad de Tarlogic, se basó en su experiencia personal para mostrar cómo la especialización y la innovación son dos elementos claves a la hora de emprender en seguridad informática.

Uno de los puntos fundamentales en la ponencia de Isaac Agudo, Profesor y Doctor por la Universidad de Málaga, así

como miembro del Network, Information and Computer Security Lab (UMA), fueron los temas criptográficos capaces de permitir nuevas vías de uso en entornos

en la nube.



Para Etay Maor, Senior Fraud Prevention Strategist de Trusteer, an IBM company, los criminales realizan una gran cantidad de operaciones de inteligencia, protegen su propio malware frente a los investigadores de seguridad y tienen múltiples facilidades para atacar y robar información.

Luis Sáiz, Responsable de Innovación en Seguridad, Tecnologías y Omnicanalidad del Grupo BBVA, ofreció

a los asistentes interesantes argumentos sobre las posibilidades de mejora que la Identidad y la Gestión del

Riesgo proporcionan al negocio, tomando como ejemplo para ello al propio BBVA.

V



VI

Después de una pequeña introducción sobre la Teoría del Caos, Gerard Vidal, Fundador de Enigmedia, presentó esta startup nacida a partir de un método matemático capaz de generar secuencias seudo-aleatorias.

Los asistentes a la ponencia de Sean Owen, Director de Data Science Cloudera, comprobaron de primera mano

cómo detectar anomalías en Apache Spark, el nuevo marco de trabajo en la parte superior del ecosistema de

Apache Hadoop.



La mesa redonda moderada por Miguel Ángel Cano, Investigador de IT Risk, Fraud and Security del Grupo BBVA, versó sobre los derechos ciudadanos y la regulación internacional cuando se trata con información personal. Los participantes (de izquierda a derecha en la imagen) fueron Isaac Agudo, Profesor, Doctor por la Universidad de Málaga y miembro del Network, Information and Computer Security Lab (UMA); Pablo García Mexía, Profesor visitante de Derecho de Internet en The Collage of William & Mary Of Counsel en Ashurst (LLP); Esther González, Profesora Titular de Derecho Constitucional en la Universidad Rey Juan Carlos, Luis Sáiz, Responsable de Innovación en Seguridad, Tecnologías y Omnicanalidad del Grupo BBVA, y Juan López-Rubio, Responsable de iLabs de Innovation 4 Security (I4S).

VII



VIII

Luke Sloan, Colaborador en Collaborative Online Social Media Observatory (COSMOS) en la Universidad de Cardiff, demostró su nutrida experiencia como científico social impartiendo una ponencia sobre la percepción del crimen utilizando redes sociales.

En la conferencia de clausura del curso de verano, Regino Criado, Catedrático de Matemática Aplicada de la

Universidad Rey Juan Carlos, y Santiago Moral, Director de IT Risk, Fraud & Security del Grupo BBVA, sentaron las pautas del modelo de colaboración entre el sector

universitario y el empresarial.



IX

El nuevo recinto elegido para los Cursos de Verano 2014 en el Campus de Vicálvaro de la Universidad Rey Juan Carlos propició que la asistencia fuera aún más nutrida que en anteriores ediciones.

Durante las diferentes ponencias, los asistentes tuvieron la oportunidad de compartir sus dudas y opiniones sobre los temas tratados.



X

innovación disruptiva en tecnologías de seguridad

Technology