Mobile Connect + Fortinet = Un portal cautivo WiFi sin passwords

Otra de las novedades de las que hablamos en el Security Innovation Day 2017 de hace unos días fue del trabajo de colaboración que hemos hecho entre ElevenPaths y Fortinet - que es una de las empresas con la que creamos una alianza - utilizando sus tecnologías de seguridad WiFi y la tecnología de autenticación Mobile Connect basada en el número de teléfono y la SIM para crear un portal cautivo.

Figura 1: Mobile Connect + Fortinet = Un portal cautivo WiFi sin passwords

El sistema ya lo habréis visto en producción si habéis viajado en el AVE, que desde Noviembre de 2016 se puso en producción gracias a la colaboración entre Renfe y Telefónica. Ahora, desde hace unos meses la autenticación funciona con Mobile Connect y Fortinet, tal y como se puede ver en el siguiente vídeo con un número de teléfono de demo.

Figura 2: Demo de portal cautivo con Mobile Connect

Como se puede ver, hemos usado un Windows Phone y un PIN OTP con Link vía SMS para esta demo, para universalizar el número de dispositivos que pueden autenticarse en el sistema, pero dependiendo de las necesidades de seguridad y robustez, se puede elegir el nivel de interacción con la plataforma. Ahora mismo, este sistema se está implantando en muchos hoteles, ya que evita que se tengan que crear usuarios y contraseñas, basta con que el usuario haya dado el número de teléfono en el proceso de registro y listo. 

Saludos Malignos!

Una PoC de Mobile Connect con Biometría de Huellas Dactilares

A la hora de implantar una estrategia de identidad en una organización hay que pensar en el conjunto de soluciones que permitan dotar a cada aplicación o sistema en el que hay que identificarse del máximo posible de opciones para maximizar las cuatro características que deben determinar una buena elección: Universalidad, Usabilidad, Robustez y Cumplimiento.

Figura 1: Una PoC de Mobile Connect con Biometría de Huellas Dactilares

No voy a detenerme en el post de hoy a hablar de estrategias de identidad, porque ya os he hablado tiempo atrás de cuál es nuestra visión. Hoy solo os voy a mostrar otra opción combinada de tecnologías de identidad para autenticarse con dos factores. Ya en una entrevista anterior hice varios ejemplos de uso de Mobile Connect, Latch y Biometría, como podéis ver en este vídeo.

Figura 2: Mobile Connect, Latch y Biometría

Lo más robusto sería utilizar tres factores, con algo que se sepa, algo que se sea y algo que se posea, pero en muchos casos esa Robustez penaliza en exceso al Usabililidad o la Universalidad. Por supuesto, entre utilizar un único factor de identidad o tres, lo más extendido hoy en día es permitir a los usuarios utilizar dos factores de autenticación, como vemos en casi todos los servicios, y en los más avanzados, se permite elegir el mecanismo de segundo factor, para aumentar la Usabilidad y la Universalidad.

Figura 3: Autenticación usando Mobile Connect con la SIM

En este ejemplo, podéis ver una PoC (Prueba de Concepto) hecha por ingenieros de la empresa Certisign de Brasil, en la que han integrado Mobile Connect como primer factor de autenticación más Biometría de Huellas Dactilares como segundo.

Figura 4: Mobile Connect + Fingerprint Biometric

En este caso, si has visto el vídeo, habrás podido comprobar que se está utilizando la cámara del smartphone para escanear las huellas, lo que permite extender la Usabilidad del sistema a todos los smartphone con cámara, y no solo a los que tienen lector de huellas dactilares, como hacía yo en el ejemplo del vídeo de la Figura 2.

Figura 5: El lector de Biometría de Huellas Dactilares es la cámara del smartphone

Al final, el arquitecto de sistemas o aplicaciones es el que debe elegir cuáles son las opciones de identidad que quiere permitir, teniendo en cuenta que utilizar varios sistemas, de varios factores, y permitir al usuario que decida cuál es la que quiere usar es una combinación.

Saludos Malignos!

Prueba un sistema de Adaptive Authentication en nuestro banco @elevenpaths #Latch #MobileConnect

Cada día vamos añadiendo más funcionalidades a nuestro servicio Latch, y las últimas que hemos anunciado tienen que ver con cosas que ya están en producción en algunos de nuestros clientes. Hoy os quiero hablar de una de ellas para que las podáis probar en vuestra app de Latch y, si queréis, después implementar en vuestros propios servicios. Recuerda, que primero debes tener una cuenta de Latch tal y como se explica en este artículo: Cómo comenzar a utilizar Latch en tu vida digital.

Figura 1: Prueba un sistema de Adaptive Authentication en nuestro banco

La característica que hemos añadido a Latch son lo que llamamos "Instancias". Una Instancia en Latch no es nada más que una Operación (OperationID) personalizada para un Usuario Concreto (AccountID) de la Aplicación (ApplicationID). Es decir, en Latch antes podías crear en la web de desarrolladores las operaciones que estarán disponibles para todos los usuarios de esa aplicación, pero ahora, si quieres que cada usuario tenga sus propias operaciones puedes crearlas dinámicamente en forma de Instancias. Vamos a ver cómo funciona esto en un ejemplo de uso.

Autenticación Adaptativa en base a dispositivo con Latch

Por ejemplo, podríamos crear a cada usuario una "Instancia" por cada dispositivo al que se conecta, aplicando así una política de Adaptive Authentication. Vamos a utilizar Nevele Bank como ejemplo, así que primero sácate una cuenta de Nevele Bank tal y como se explica en este artículo: Probar las operaciones de Latch con Nevele Bank. En el vídeo se explica con detalle todo el proceso.

Figura 2: Uso de Latch en Nevele Bank

En el caso de Nevele Bank hacemos eso mismo de forma muy sencilla para esta demostración utilizando el valor del campo User-Agent del dispositivo de conexión a la web. Cada vez que se hace un login exitoso desde un dispositivo, la web de Nevele Bank comprueba el valor User-Agent y si no está en la lista de dispositivos de confianza le pregunta al usuario si es o no un nuevo dispositivo de confianza que quiera registrar para el sistema de Adaptive Authentication.

Figura 3: Nuevo dispositivo detectado

Si lo registra, automáticamente la web de Nevele Bank lo meterá en la lista de dispositivos de confianza que el usuario podrá comprobar desde la misma web y eliminar en cualquier momento. Si no lo registra seguirá siendo un dispositivo "Desconocido".

Figura 4: Lista de dispositivos de confianza en una cuenta de Nevele Bank

Pero además, creará una instancia en la aplicación de Latch para ese usuario en concreto dentro de la operación Login, por lo que a partir de este momento el usuario podrá configurar su política de Adaptive Authentication en función - en este caso - del dispositivo que esté usando. Podría configurar que para el dispositivo de confianza el Login está abierto, pero para los desconocidos el login está cerrado.

Figura 5: Instancias creadas para este usuario en función de sus dispositivos de confianza

Esto abre posibilidades a que también el usuario pueda configurar las opciones de apertura programada con el Schedule de cada Operación, o poner un OTP para unos dispositivos y para otros no, o configurar el Autolock por tiempo o por uso para unos dispositivos sí y otros no. Estas configuraciones permiten configurar un balance de decision entre lo que quiere el usuario y lo que quiere la web del banco.

Autenticación Adaptativa en base a método de identificación

Para nosotros, un sistema de identificación debe cumplir un equilibrio en cuatro escalas que el responsable del sistema de identidad tendrá que evaluar. Deberá elegir para cada aplicación o cada parte de ella, aquellos sistemas que cumplan los requisitos de:

- Universalidad: Que sean utilizables por la mayor cantidad de usuarios en la mayor cantidad de situaciones. 

- Robustez: Que cumpla con los mínimos de seguridad que se ha estimado para ese sistema o aplicación. 

- Usabilidad: Que haga la vida lo más fácil posible al usuario posible dentro de los requisitos de robustez y cumplimiento regulatorio que se exijan. 

- Cumplimiento Regulatorio: Que cubran los requisitos marcados por la legislación, la política de seguridad o las certificaciones que tenga el sistema  o la aplicación.

Dicho esto, podría darse el caso que para una aplicación muchos sistemas de autenticación cumplieran con los valores marcados para él en los 4 ámbitos anteriores o por el contrario solo uno lo permitiera. Todo esto lo tenéis mejor explicado en el WhitePaper que explica nuestra estrategia de identidad.

Figura 6: New Paradigms of Digital Identity: Authentication & Authorization as a Service (AuthaaS)

Por ejemplo para una web de información no importante, a lo mejor con usuario y contraseña valdría, pero si el riesgo reputacional exige mayor robustez o el cumplimiento de una regulación exige un segundo factor de autenticación, tal vez hubiera que moverse a una autenticación con Usuario+Contraseña+OTP o Usuario+Contraseña+Latch o a usar un DNIe con PIN, o una SmartCard+Biometría, etcétera. Este es un ejemplo con SmartID.

Figura 7: Autenticación robusta con DNIe, Biometría, NFC, Latch y SmartCards con SmartID

Al final, lo suyo es que el sistema permita tantos sistemas de autenticación como sea posible que cumplan los requisitos de Robustez y Cumplimiento Regulatorio. Al abrir el abanico de posibilidades al usuario, aumenta por supuesto la Usabilidad (cada uno eligirá el más cómodo para él) y la Universalidad, al abrirse más el número de posibilidades.

Autenticación con Mobile Connect en Nevele Bank

En la web de Nevele Bank, además de con Usuario y Contraseña, de Usuario y Contraseña + Latch, de Usuario + Contraseña + Latch + Verificación de dispositivo, hemos añadido la posibilidad de autenticarte con Mobile Connect, lo que permite a todos los usuarios cuya operadora haya lanzando ya Mobile Connect (como es el caso de Movistar) el poder asociar su número de teléfono a su cuenta de usuario y después seleccionar Mobile Connect como forma de autenticarse.

Figura 8: Pareado de cuenta de Nevele Bank con Mobile Connect

Primero hay que conectarse a la web de Nevele Banck y parear con Mobile Connnect, luego ya basta con poner el número de teléfono en la parte de login y aceptar el proceso.

Figura 9: Login con Mobile Connnect

Figura 10: Autenticación con Mobile Connect en el terminal

En este vídeo tenéis una demostración de cómo funciona con una demo que hice en el programa Likes de #0.

Figura 11: Autenticación Adaptativa con Latch, Mobile Connect y Biometría

Al final, como se ve en el vídeo, con Mobile Connect también se pueden elegir diferentes métodos de autenticación, basados en Click OK, o en PIN o incluso en el uso de biometría de huella dactilar usando FIDO. Es la web la que, en base a los parámetros definidos anteriormente la que debe dar al usuario las posibilidades que son válidas y que el usuario decida cuál le es más cómoda en cada instante.

¿Y tus sistemas? ¿Siguen utilizando solo usuario y contraseña? DO the BASICS!

Saludos Malignos!

Una demo de Mobile Connect, Fido con Mobile Connect & Biometría y Latch con el Apple Watch en Likes de #0

Para hoy domingo os traigo un par de vídeos - por si aún no los has visto - de unos pocos minutos de duración. Son los dos vídeos de las entrevistas que me han hecho en el programa de televisión Likes del Canal #0 de Movistar+. En ellos hablo un poco de algunas tecnologías y hago algunas demos.

Figura 1: Entrevistas de Chema Alonso en Likes #0

Para la primera entrevista no tuve mucho tiempo de preparar las demos, así que expliqué algo sobre los metadatos y hablamos de seguridad informática en general. Eso sí, me llevé mi pedazo de camiseta de Star Wars.

Figura 1: Primera entrevista en Likes #0. Seguridad Informática y Privacidad

En la segunda entrevista preparamos unas demostraciones de identidad que son parte de nuestra visión de cómo debe ser la identidad [Universal, Usable, Robusta y Compliance], así que puedes ver un sistema de autenticación con Mobile Connect + PIN, un sistema de autenticación con Mobile Connect usando FIDO con Biometría dactilar y un sistema de autenticación usando Login/Password + Latch con un Apple Watch. Todo en menos de nueve minutos.

Figura 3: Segunda entrevista en Likes #0. Demos de Identidad

Que paséis un buen domingo, que estamos en fin de semana y hay que recargar pilas para la semana que se nos viene por delante.

Saludos Malignos!

Cuando los mensajes SMS son realmente el First Factor of Authentication

Durante la semana pasada, además de las charlas que me llevaron a que terminara como estoy ahora - completamente devastado - tuvimos la oportunidad de tener una reunión con el equipo de Microsoft en Barcelona, encabezado por el propio Satya Nadella. Como sabéis, en el Mobile World Congress de este año la estrella fue Mobile Connect, que recibió varios premios y mucha atención por parte de todos los medios.

Figura 1: Cuando los mensajes SMS son realmente el First Factor of Authentication

En la reunión, aprovechando que teníamos a Satya delante, le pedí personalmente que se pensara en utilizar Mobile Connect como First Factor of Authentication en Office 365, porque al final, si se confía en un SMS como sistema de recuperación de contraseñas, es exactamente lo mismo que si Mobile Connect fuera el First Factor of Authentication pero más incómodo y menos robusto.

Número de teléfono como recuperación de contraseña

Ya sea vía llamada, o vía mensaje SMS, casi todos los principales servicios en Internet confían en el número de teléfono como forma de recuperar la contraseña. Si has añadido el número a Facebook, Google o Twitter, puedes recuperar la contraseña siempre mediante un envío de un SMS con un OTP que se puede utilizar para poner una nueva contraseña.

Figura 2: Cuenta de Gmail con recuperación de password basada en SMS

Muchos usuarios, realizan este proceso de manera sistemática, ya que se confían en que siempre pueden recuperarla y cada vez que quieren entrar recuperan la contraseña, ponen una nueva, y entran. Esto sucede especialmente en aquellos servicios en los que no se entra de manera continuada, sino de forma esporádica.

Figura 3: Cuenta de Twitter de El Rubius protegida por SMS

Al final si el servicio confía en el SMS como forma de recuperar la contraseña, sería mucho más cómodo para el usuario confiar en el número de teléfono como First Factor of Authentication, vía Mobile Connect. Esto permite que no haya ninguna contraseña que el usuario deba recordar y pueda usar siempre el número de teléfono para autenticarse, pero sin la necesidad de tener que pegarse con las políticas de contraseñas para poner una nueva contraseña en cada caso.

Figura 4: La cuenta de Twitter de Satya está asociada al correo de Microsoft.com.
Los correos de Microsoft.com utilizan el SMS y el Phone Call como 2FA.

Por supuesto, nuestra visión es que hay que darle al usuario todas las posibilidades robustas que se pueda para que él elija en cada caso qué mecanismo quiere utilizar, ya que existen muchas formas robustas de autenticarse y, dependiendo de la casuística, un usuario puede decantarse por una u otra dependiendo de cada caso.

Figura 5: La cuenta Twitter de Pablo Iglesias está asociada la cuenta de Podemos.info.
Podemos.info usa un RoundCube sin 2FA (Solo password). Deberían poner Latch al menos };)

Si confías en el el SMS para recuperar la contraseña, entonces podrías simplificar la vida a tus usuarios simplemente permitiendo que se autentiquen con Mobile Connect, así será mucho más cómodo y aún más robusto, ya que podrías eliminar las contraseñas para muchos usuarios que no deseen utilizar esa forma de autenticarse.

Saludos Malignos!

Ya puedes integrar Mobile Connect en tus servicios

Este lunes comienza el Mobile World Congress y, sin duda, una de las estrellas de esta edición será Mobile Connect, el nuevo estándar para autenticación en servicios basados en el número de teléfono. Detrás del estándar está la GSMA, que es la organización que aglutina a todas las Telcos del mundo, y nosotros en Eleven Paths hemos estado trabajando fuerte para que Telefónica sea una de las primeras en tenerlo listo y funcionando. Y ya está disponible para que empieces a integrarlo donde quieras.

Figura 1: Ya puedes integrar Mobile Connect en tus servicios

El funcionamiento de Mobile Connect es fácil de entender y se basa en autenticar a los usuarios de cualquier sistema mediante un desafió a la tarjeta SIM de su número de teléfono. Es decir, cuando un usuario se quiere autenticar en un servicio, en lugar de introducir un login_id y una password, pide autenticarse con Mobile Connect e introduce su número de teléfono. El servidor en el que se quiere autenticar comprueba que ese número de teléfono es de uno de sus empleados y entonces solicita a la operadora - a la telco - que verifique si el dueño del número de teléfono realmente se quiere conectar a su sistema. 

El servidor se conecta con un servicio de Mobile Connect que ofrece una de las telcos y será la infraestructura de red de las telcos la que busque la SIM del número solicitado para enviar, vía canal de operadora, un mensaje a la SIM del usuario. Ese mensaje hará que se ejecute un programa en la SIM del cliente que le preguntará si quiere autenticarse en ese servicio, y lo hará solicitando diferentes niveles de seguridad, según lo haya requerido el servicio en el que se está autenticando. El siguiente vídeo muestra un ejemplo sencillo de uso.

Figura 2: Ejemplo de login con Mobile Connect

En un nivel de autenticación básica se le solicitará al usuario que dé su aprobación con un clic. En un nivel de aprobación superior se le solicitará el PIN de Mobile Connect. En un nivel de autenticación superior se solicitará el PIN y que luego introduzca un OTP en el servidor web y, en un nivel de autenticación aún superior se le puede exigir que usando FIDO, ponga su huella dactilar para aprobar el acceso con biometría o incluso con el DNIe. Es decisión de lo que quiera el servicio al que se vaya a conectar. 

Figura 3: Mi Movistar España ya permite autenticarse con Mobile Connect

El servicio ya está lanzando en varios países en Telefónica desde hace un tiempo, que lo hemos tenido a prueba, y ya puedes usarlo en Mi Movistar España y en Mi Movistar Perú, donde puedes aprender también a utilizarlo fácilmente.

Figura 4: Mi Movistar Perú permite autenticarse también con Mobile Connect

La ventaja de utilizar Mobile Connect es que el usuario no necesita ni un smartphone ni una conexión de datos, es decir, no necesita que el cliente tenga un plan de Internet en el terminal para poder autenticarse usando Mobile Connect y no se necesita un smartphone porque el cliente de Mobile Connect corre directamente en la SIM del terminal. 

Figura 5: SDKs y Demos para integrar Mobile Connect en tus servicios

Desde ahora ya puedes comenzar a integrar este sistema de autenticación en tus servicios, con lo que podrías tener cualquier servicio en el que si tienes el número de teléfono de tus usuarios podrías autenticarlos con Mobile Connect, lo que además te sirve como forma de verificación de los datos. En la web de Developers de Mobile Connect ya tienes toda la información que necesitas para comenzar a trabajar con él, y en el vídeo siguiente se explica un poco su funcionamiento.

Figura 6: Integración y uso de Mobile Connect

Además, si necesitas ayuda para implementarlo en algún servicio, puedes ponerte en contacto con nuestros ingenieros de Eleven Paths a través de la Comunidad de Eleven Paths, donde hemos abierto una categoría de Mobile Connect para escuchar vuestras ideas, dudas o comentarios. El uso del servicio es gratis para los sistemas de autenticación básica en Internet, así que puedes ponerlo donde quieras en Internet.

Figura 7: Comunidad de Mobile Connect en Eleven Paths

Como ya os he contado en el pasado, nuestra visión de autenticación y autorización se basa en crear soluciones robustas adaptadas a las necesidades de los clientes, para permitir que el usuario decida cuál es la forma más cómoda para autenticarse en un sistema en cada caso. Nuestra idea es poder ofrecerle un abanico lo suficientemente grande de opciones como para que sea una experiencia satisfactoria a la vez que segura. Para ello tenemos soluciones de autenticación y de autorización que se pueden implementar todas juntas en un sistema y adaptarse a las necesidades y situaciones del usuario. 

Figura 8: Demostraciones de Mobile Connect + Latch + SMS + Biometría

Al final, a lo largo de los últimos tres años hemos construido un ecosistema de tecnologías que generan una solución de identidad digital de las que nos sentimos muy satisfechos, ya que recoge la visión que teníamos al inicio de construir algo centrado en el usuario y robusto. En este artículo que os publiqué contamos nuestra visión de autenticación y autorización, pero se resume bien en esta demostración que hicieron nuestros compañeros durante el último Security Innovation Day (vídeo superior) y durante el Security Day 2015 (vídeo siguiente).

Figura 9: Demos de autenticación con SmartID usando DNIe, Biometría, NFC y Latch. Además autenticación vía firma digital manuscrita con SealSign

Las piezas tecnológicas que usamos para que luego se apliquen a gusto del usuario y del servicio para los procesos de autenticación y autorización son:

- Mobile Connect:  SIM, SIM+OTP, SMS+OTP, SIM+FIDO [Web Mobile Connect]
- SmartID: NFC, DNIe, RFID, SmartCard, Biometría dactilar [Web SmartID]
- Latch: Password+Latch,  Password+Latch+OTP [Web Latch]
- SealSign: Biometría de firma manuscrita, Firma Digital [Web SealSign]
- Liliac: RFID ID Card+ Liliac [Web Liliac]

Jugando con todos estas tecnologías, y aplicándolos todos a la vez, un sistema podría requerir uno u otro dependiendo del entorno en el que se encuentre el usuario, o dejar que el usuario elija en cada caso qué es lo que quiere usar para autenticarse. El mundo no debe pararse por las contraseñas y tenemos ya a día de hoy soluciones para hacer la vida más fácil y más segura a los usuarios.

Saludos Malignos!

El Departamento de Homeland Security tiene los mismos problemas de seguridad que muchas grandes empresas

La gestión de la seguridad de una organización grande suele ser algo complejo. El volumen de sistemas de información que se manejan crece día a día a una velocidad superior a la que se introducen los mecanismos de gestión y seguridad. Además, la obsolescencia continuada del parque informático, el cumplimiento normativo y legislativo, unido a los incidentes que surgen, hacen que el día a día de un equipo de seguridad de una organización sea una aventura en la que tienen que lidiar con los temas urgentes, los proyectos importantes y la visión a largo plazo. Una aventura que los CISO y los CSO de las organizaciones deben vivir con la cabeza fría para llevar a la compañía dentro de los límites de un "Riesgo Aceptable".

Figura 1: El DHS es como cualquier otra empresa u organización grande

Pero no penséis que esto es solo su trabajo. No, al igual que hay auditores fiscales y contables que revisan todo lo que tiene que ver con el movimiento de dinero y presupuestos dentro de las empresas, también están los auditores internos de seguridad que revisan si el trabajo de los CISO y los CSO está siendo el adecuado o no y si, está alineado y cumple con la normativa global, central o gubernamental. Estos informes suelen, además, sacar del plan de trabajo a los CSO y CISO ya que acaban en los más altos estamentos de la empresa y les rompe la planificación de su trabajo. 

Figura 2: Informe de auditoría de seguridad a los sistemas IT del DHS

En el gobierno de los Estados Unidos también hacen estos informes de auditoría, y han publicado el referente al mes de Noviembre que se ha realizado a los sistemas de información del DHS (Department of Homeland Security), con unos resultados que he visto en tantas y tantas organizaciones que me he sentido hasta "feliz". No feliz en el sentido de que disfrute con que un sistema de seguridad esté mal, sino feliz porque he estado con muchos - y cuando digo muchos, son muchos - CISO y CSO que sufren por las cosas que ellos saben que tienen mal y luchan contra viento, marea y presupuestos por ir avanzando poco a poco. Muchos de ellos, además, sufren pensando que están peor que otros, y ver que el DHS tiene exactamente los mismos problemas, me ha hecho animarme a publicar este artículo para mis amigos CISO y CSO.

Shadow IT - Mal inventariado de activos

El primer punto importante que dice este informe de auditoría seguro que los conocéis muchos. El informe de auditoría hace referencia a que los informes de activos consolidados de las distintas áreas no muestran los mismos activos que el informe del área de seguridad. En esto falla el DHS.

Figura 3: Mal inventariado de activos en los reportes

Esto también se produce porque no hay un sistemas centralizado de inventario o porque muchas áreas en las empresas empiezan a meter lo que se ha dado en llamar Shadow IT, o lo que es lo mismo, del Bring Your Own Device referido al terminal smartphone, muchos departamentos de las empresas empiezan a hacer cosas como Bring Your Own Cloud, Bring Your Own NAS, Bring Your Own WiFi Hotspot, etcétera, debido a que como muchos empleados tienen conocimientos avanzados de tecnología, comienzan a hacerse "sus cosas" cuando las necesitan, generando un problema de seguridad en la organización sin darse cuenta. Esto, por supuesto, da lugar a las famosas Hidden Networks dentro de las empresas.

Defence in Depth - Do the Basics

Si una empresa no está preparada para asumir su siguiente paso en el nivel de madurez de seguridad, entonces va a estar perdida. Siempre contamos que las empresas más inmaduras en seguridad tienden solo a invertir en Prevenir los incidentes de seguridad, por lo que basan muchas de sus inversiones en software de protección perimetral, con la esperanza de poder frenar todos los atacantes fuera de sus sistemas. Es como los padres que quieren proteger a sus hijos de todos los males sin asumir que no van a ser capaces de hacerlo siempre. 

Figura 4: Sistemas operativos sin soporte

Las empresas que están en un segundo nivel de madurez, asumen que los enemigos están en su red e invierten más en Detectar. Pueden ser atacantes que hayan logrado entrar por una red WiFi en una sucursal, por una impresora mal configurada en Internet, o por un simple Spear Phishing a la persona concreta, o directamente un empleado malicioso pero hay que asumir que el enemigo está dentro. Si no has preparado tus sistemas dentro del perímetro para ser "resilliance", entonces será un paseo militar por tu red. 

Figura 5: Software sin actualizar en los puestos de trabajo. Un regalo para un Metasploit

Mi recomendación es que no dejes de aplicar la política de Defensa en Profundidad en tu organización, y comienza por lo más básico. No dejes sistemas sin actualizar constantemente. No utilices sistemas operativos sin soporte y actualiza absolutamente todo el software que corra sobre los sistemas operativos. Si esto pasa, un atacante dentro de un equipo con un Metasploit va a destrozar tu sistema, tu red, y tu empresa como un cuchillo cortando mantequilla caliente. En esto, también falla el DHS, como muchas empresas. 

Procesos & Incident Response Plan

La gestión es importante en la seguridad. De hecho, supongo que estaréis todos hartos de escuchar que la seguridad no es un producto sino un proceso continuo de gestión que mezcla, Tecnología, Personas y Procesos. Si no tienes los procesos de seguridad bien incrustados en tu compañía, va a ser completamente inmanejable gestionar la seguridad y dentro de esos procesos deben estar los relativos al último nivel de madurez de una compañía: Asumir que el riesgo va a convertirse en realidad y tener un proceso para responder a ese incidente.

Figura 6: Malos procesos de gestión de incidentes de seguridad

¿Qué pasa si me roban los datos del servidor central?¿Qué pasa si un atacante encuentra un 0day en mi sistema expuesto a Internet? ¿Cómo voy a responder ante ese problema? Todos los Planes de Contingencia deben tener su Incident Response Plan, para poder gestionar y resolver correctamente el fallo. Las empresas maduras asumen que eso puede pasar y tienen un plan. Nosotros contamos el caso del bug de Jeep que Charlie Miller y Chris Valasek encontraron. La compañía no tenía previsto que apareciera un bug en el software y no contaba con un sistema de actualización, y le ha costado mucho dinero en tener que actualizar el software coche a coche.

Identity & Access Control

Otro de los puntos en el que el informe de DHS ha hecho hincapié ha sido en la mala gestión de la Identidad y el Control de Acceso. Desde contraseñas inseguras, hasta la falta de uso de Segundos Factores de Autenticación en los sistemas de información internos de la organización, pasando por una falta de control de cuentas privilegiadas.

Figura 7: Control de cuentas privilegiadas

Entre las cosas que cita hay una reflexión más que interesante que debería hacerte replantear los procesos legales de tu organización, y es que las cuentas que están autenticadas con usuarios y contraseñas las cataloga de "accesos anónimos", ya que el usuario y la contraseña puede ser robado de tantas y tantas formas que garantizar que la acción que hace una cuenta en un sistema ha sido realizada por la persona a la que se le entregó inicialmente es complicado.

Figura 8: Falta de Segundos Factores de Autenticación

Para eso, el plan incide en el establecimiento de segundos factores de autenticación y el control de cuentas privilegiadas, no solo en los sistemas internos, sino especialmente en los accesos remotos a los sistemas de información. Hay muchas organizaciones que tienen sistemas de información importantes para la empresa puestos en Internet y sin ningún segundo factor de autenticación y/o autorización todavía. Si te interesa este tema, te recomiendo que veas cómo lo vemos la identidad, la autenticación y la autorización en Eleven Paths con nuestras tecnologías.

Continuos Monitoring & Persistent Pentesting: Long Hanging Fruit

Controlar la seguridad de una organización con auditorías cíclicas cada 6 meses o cada año, es algo que deja una ventana de exposición muy amplia. Estas auditorías son una buena verificación de que se están haciendo bien las cosas, si ya has implantado un sistema de Continuous Monitoring que verifique día a día las vulnerabilidades de todos tus sistemas, o un sistema de Pentesting Persistente como nuestro Faast que va a estar buscando vulnerabilidades día a día con una análisis exhaustivo de todos los activos expuestos a Internet.

Figura 9: Long hanging fruit - Sin actualizar, passwords inseguras y SQL Injection

Que una organización como el DHS tenga Long Hanging Fruit en forma de SQL Injection en las webs de sus sistemas de información dice muy poco de sus sistemas de Continuous Monitoring y de Pentesting Persistente. Si quieres que te hagamos un piloto gratuito para tu organización de nuestro sistema de Pentesting Persistente Faast, ponte en contacto con nosotros y vemos cómo hacértelo.

Figura 10: Aplicación de Continuous Monitoring & Persistent Pentesting

Dicho esto, si eres un CSO o un CISO de una organización espero que este informe te sirva para hacer ver a los jefes lo complejo que es gestionar la seguridad de una empresa. Y si te sirve de algo mi opinión, en los presupuestos del año que viene huye de tecnología super-fashion que acaba de ganarse un espacio en un nuevo cuadrante mágico de algún analista y céntrate en afianzar las cosas fundamentales que yo creo que están bien recogidas en este artículo. 

Saludos Malignos!

Security Innovation Day 2015_ disponible en vídeo

El equipo de comunicación de Eleven Paths no ha tardado en editar todas las charlas del pasado Security Innovation Day 2015 para que las tengáis disponibles y podáis verlas si no pudisteis venir al evento o si no pudiste conectarte por streaming online. Las hemos divido en varias partes, para que sea aún mucho más fácil elegir el momento que quieres ver de toda la sesión. Para que el evento fuera como lo vas a ver online, los equipos trabajaron fuerte y duro. Desde la imagen que se eligió para el evento, el montaje y el diseño de todo el auditorio, las camisetas de Latch que se entregaron a los asistentes que trajeron su app con alguna identidad pareada, los ponentes y sus demos, los equipos de Product Management, IT, Comunicación, UX, Ingeniería y QA para conseguir que las cosas funcionaran como las vas a ver, etcétera.

Figura 1: Security Innovation Day 2015_ disponible en vídeo

Fue un trabajo enorme, y no importa cuántas veces lo haya dicho, me sigo sintiendo orgulloso de poder trabajar con ellos y ver día a día como hacen las cosas. Gracias a todos los que os dejasteis un poquito de vuestra sangre por conseguir que esa demo funcionara, que ese detalle estuviera en el sitio adecuado o que los asistentes estuvieran a gusto. Espero que, si no lo has visto hasta ahora, puedas disfrutar de las presentaciones - que están disponibles para descarga en la web del evento -

Figura 2: SID2015 - Bienvenida

Figura 3: SID 2015 - Amenazas más grandes significan necesidades más grandes

Figura 4: SID2015 - El control de tu identidad digital está en tus manos

Figura 5: SID2015 - Ciberseguridad, Comunidad Técnica y Concursos

Figura 6: SID2015 - Decisiones de seguridad que pueden salvar tu negocio:

Data Protection in the Cloud Era

Figura 7: SID2015 - ¿Me vas a creer a mí o a tus propios ojos? El dilema de la seguridad gestionada

Figura 8: SID2015 - Preventing Data Breaches. Nir Zuk, Founder y CTO de Palo Alto Networks

Figura 9: SID2015 - Conclusiones y despedida

Si has visto las charlas, habrás visto que está todo lo que os he ido contando estos días y algo más. A lo largo de este mes que viene aún os iré desgranando algún detalle más de lo que vamos haciendo, que en Eleven Paths tenemos la suerte de poder jugar con la tecnología día a día y siempre hay algo nuevo en lo que merece la pena pararse a mirar.

Figura 10: Parte del equipo de Global Security en Eleven Paths y Telefónica de España

Adoro este trabajo que tengo y la gente con la que lo comparto. Rocks!

Saludos Malignos!

Estrategia de Identidad en Telefónica y más sobre Latch: (AuthaaS) Authentication & Authorization as a Service

Durante el último Security Innovation Day 2015 tuvimos una sesión de presentación sobre toda la estrategia de soluciones de identidad que estamos impulsando desde Telefónica, haciendo uso de las tecnologías que estamos creando en Eleven Paths. Los que pudisteis venir a las sesiones visteis que en directo mezclábamos todas nuestras soluciones de diversas maneras y en diversas situaciones. Desde autenticar de forma robusta con Mobile Connect o SmartID - para usar smartcards, biometría, NFC, DNIe o RFID, autorizar vía Latch, Mobile Connect con Biometría o tokens OTPs vía SMS para los terminales pre-smartphone, e incluso identificar en el sistema de recuperación de contraseñas a los usuarios vía SealSign (como sistema de autenticación anti Rubber Hose).

Figura 1: Estrategia de identidad en Telefónica y más sobre Latch

Todos ellos funcionando según la estrategia de identidad que una compañía quiera realizar, ya que al final, los productos son nuestros y los podemos adaptar a cada situación. Durante la presentación, lo recogíamos todo en esa diapositiva que habíamos extraído del informe que Gartner ha hecho sobre nuestra propuesta de Authentication & Authorization as a Service.

Figura 2: Estrategia de identidad de Telefónica con tecnologías de Eleven Paths

El informe que ha hecho el equipo de Gartner se ha basado en el trabajo de varios meses analizando nuestra propuesta, y ha quedado plasmado en el siguiente documento que he subido a mi canal SlideShare:

Figura 3: New Paradigms of Digital Identity: Authentication & Authorization as a Service (AuthaaS)

Para conseguir dar esa flexibilidad, tenemos un roadmap muy extenso que va haciendo que día a día, versión a versión, todos ellos tengan nuevas características que permitan hacer más y más cosas. En el caso de Mobile Connect, ya sabéis que lo hemos puesto en producción en España, Argentina, México y Perú, y que en breve estará disponible para integrar en cualquier sitio que quieras. 

Figura 4: Un ejemplo de autenticación con Mobile Connect en una web

En el caso de Latch hemos seguido ampliando el número de sitios donde está integrado - ya hay más de 7.000 aplicaciones integradas con Latch - y hemos continuado metiendo características. Algunas de usabilidad e información para el usuario, como las características de Silenciar y de Log & Stats que os contaba hace poco, y otras vía API, como personalizar los mensajes OTP o permitir crear operaciones de forma dinámica. Esta última opción es la que utilizó Ben Metzel CTO de Vaultive para controlar dinámicamente los dispositivos que podrían acceder al correo electrónico de Office 365 descifrado, tal y como mostró en su demostración en el evento.

Figura 5: Ben Metzel, CTO de Vaultive, controlando el acceso al correo de
Office 365 descifrado por dispositivos desde Latch

Desde el punto de vista más puro de usabilidad, también lanzamos Latch para Apple Watch, que ya puedes descargar y probar, además de una serie de características que están escondidas para los menos curiosos, y que os paso a contar por aquí. Estas características las teníamos en el roadmap desde hace tiempo, pero las vamos metiendo según la cola de prioridad que tienen, y las que hemos sacado son las siguientes que puedes utilizar arrastrando el Latch hacia la derecha.

Figura 6: Acceso a opciones de cada Latch

En la imagen veis unos textos que he añadido yo para hacer más fácil la comprensión, pero luego no van a estar en la app. Son bastante sencillos de entender, ya que son las opciones de Renombrar, Agrupar, Silenciar y acceso a Log & Stats. Esta última, la gestión de Log & Stats, ya la explique en detalle en un artículo, así que me voy a centrar hoy en las otras.

Renombrar y Silenciar

Estas dos opciones son muy sencillas. La primera de ellas es tan fácil que consiste en cambiarle el nombre al pestillo. Esto es útil sobre todo si hay varios Latches protegiendo varias identidades en el mismo sitio. De esta forma se puede poner un nombre que ayude a diferenciarlos. De momento no hemos permitido cambiar el icono del Latch, pero todo se andará.

Figura 7: Cuadro para renombrar un Latch

La segunda opción, la de silenciar, hará que no lleguen alertas para esa identidad. Esto puede ser útil en muchos entornos en los que hay demasiadas comprobaciones, pero puede dejar al usuario sin enterarse de lo que está pasando. Para ello, cuando se activa aparece el icono avisando de esto en el Latch principal.

Figura 8: Un Latch con las alertas silenciadas

Decidimos meter esta opción solo cuando teníamos terminada la parte de logs & stats, ya que a pesar de que no que lleguen las alertas en tiempo real, el usuario podrá revisar siempre todo lo que ha pasado con su identidad.

Mover a una Carpeta

En muchos wallets de Latch el número de identidades empieza a crecer lo suficiente como para que sea útil agruparlos. Hemos decidido meterlos ahora que ya hemos sobrepasado la barrera de los 320.000 usuarios, y su funcionamiento es sencillo. Desde la opción de Mover se pone un nombre de una carpeta la primera vez que se crea y a partir de ese momento aparece una carpeta en la lista de Latches.

Figura 9: Cuadro para mover un Latch a un nuevo Grupo

Es muy similar su funcionamiento a las carpetas de iOS u otros sistemas operativos móviles. Si en algún momento se quiere sacar de la carpeta a una identidad, se vuelve a seleccionar la misma opción y se deselecciona el grupo. Por último, para borrar el grupo, se hace exactamente igual que antes, arrastrando hacia la derecha y con la opción X de borrar. 

Figura 10: Grupo Tienda con Latches dentro

Hemos metido la opción de renombrar el grupo o carpeta de Latches, pero no hemos permitido aún poner iconos personalizados, que tal vez lo hagamos en la siguiente versión.

Figura 11: Izquierda opción de cambiar un Latch de Grupo. Derecha borrar un Grupo.

Como veis, poco a poco intentamos ir metiendo aquellas ideas que se nos ocurren y que nos dais, así que cualquier feedback o necesidad que vayáis teniendo será bien recibida. Recordad que ahora tenemos abierto el Latch Plugin Contest 2015 - puedes debatir sobre él en nuestra comunidad - y que puedes ganar por tus implementaciones de Latch hasta 5.000 $ en BitCoins, así que "Put your code where your mouth is".

Saludos Malignos!