Implementación de "pestillos virtuales" en proyectos basados en Arduino con Latch

miércoles, 30 de diciembre de 2015

Gracias al esfuerzo de Intel por acercar su arquitectura x86 al mundo del IoT, es posible utilizar el SDK en C oficial de Latch desde el entorno de desarrollo de Arduino, y disponer de pestillos virtuales en nuestros proyectos de forma muy sencilla.

Arduino es una popular plataforma de hardware y software abierto ampliamente utilizada en todo tipo de proyectos electrónicos, especialmente en ambientes didácticos, por su sencillez y bajo coste. Actualmente se está librado una batalla en torno a la marca Arduino, que explica claramente Félix Maocho en este artículo.

Incorpora un completo entorno de programación (IDE) que utiliza un lenguaje basado en Wiring; en esencia C++, aunque en muchas ocasiones se usa C, ya que la suite de desarrollo Open Source incluye ambos lenguajes dentro de su colección de compiladores.

Pese a que Intel no supo adaptar x86 a la era post-PC, y desde 2007 la arquitectura ARM domina ampliamente en tablets y smartphones (llegando incluso a dispositivos embebidos que eran nicho tradicional de MIPS), con la llegada del IoT se produce un acercamiento a la comunidad makers de Arduino, hasta ahora fieles a la arquitectura AVR, pero necesitados de facilidades para conectar sus proyectos a Internet.

En 2013 Intel lanza la placa de desarrollo Galileo, basada en la arquitectura x86 (i586) es totalmente compatible, tanto con IDE de Arduino, como con todos módulos complementarios (Shields) al adoptar el mismo pinout que el Arduino UNO R3, convirtiéndose en la primera arquitectura no AVR oficialmente certificada por Arduino. Dotada de un núcleo Linux (Yocto) y conexión Ethernet, su estándar totalmente abierto explota al máximo la fusión entre Linux y Arduino; algo que no sucede con el intento más cercano, el Arduino YÚN, cuyo componente Linux es cerrado y extremadamente limitado al igual que el microcontrolador del lado de Arduino.

Después de una mínima revisión Gen2 en 2014, Intel alcanza en 2015 un hito en los sistemas embebidos al integrar conexiones WiFi y Bluetooth en la minúscula placa x86 (i686) Edison, sembrando la semilla del nuevo Arduino 101 basado en x86 que verá la luz en 2016 para sustituir al veterano UNO R3 y revolucionar el ecosistema actual.

Para utilizar el SDK en C oficial de Latch desde el IDE de Arduino en una placa Intel Edison, es necesario incorporar al IDE las librerías: OpenSSL (libcrypto) para las operaciones criptográficas y cURL (libcurl) para la conexión HTTPS, junto con sus dependencias: nettle, hogweed, gmp, gnutls, z y cap.

Estas librerías y sus archivos de cabecera deben ser copiados desde el sistema Linux Yocto de la placa Intel Edison en la ruta sysroot compiler.toolchain.path del IDE de Arduino; que por ejemplo, en la versión de IDE v1.6.2 será:

  • Linux: /home/test/.arduino15/packages/Intel/tools/core2-32-poky-linux/1.6.2+1.0/i686/sysroots/core2-32-poky-linux/
  • Mac OS X: /Users/test/Library/Arduino15/packages/Intel/tools/core2-32-poky-linux/1.6.2+1.0/i686/core2-32-poky-linux/
  • Win 8.1: C:\Users\test\AppData\Roaming\Arduino15\packages\Intel\tools\core2-32-poky-linux\1.6.2+1.0/core2-32-poky-linux/

Aprovechando la conexión wifi estos archivos se pueden transferir por SSH con una herramienta como WinSCP o similar desde un sistema Windows, y desde Linux o Mac OS X se puede utilizar una combinación de ssh y tar para preservar los enlaces simbólicos; por ejemplo, situarse en el sysroot compiler.toolchain.path y ejecutar:

ssh –C root@ip_edison "tar -c /usr/lib/libcrypto*" | tar –x
ssh -C root@ip_edison "tar -c /usr/lib/libcurl*"   | tar –x
ssh -C root@ip_edison "tar -c /usr/lib/libgnutls*" | tar –x
ssh -C root@ip_edison "tar -c /usr/lib/libnettle*" | tar -x
ssh -C root@ip_edison "tar -c /usr/lib/libhogweed*"| tar –x
ssh -C root@ip_edison "tar -c /usr/lib/libhogmp*"  | tar –x
ssh -C root@ip_edison "tar -c /lib/libz*"     | tar -x
ssh -C root@ip_edison "tar -c /lib/libcap*"   | tar -x
ssh -C root@ip_edison "tar -c /lib/libcrypto*"| tar -x
ssh -C root@ip_edison "tar -c /usr/include/openssl"| tar –x
ssh -C root@ip_edison "tar -c /usr/include/curl"   | tar –x

Para que estas nuevas librerías sean enlazadas dinámicamente por el linker que invoca por el IDE de Arduino en el proceso de construcción del sketch, es necesario modificar el archivo “platform.txt” que detalla las especificaciones de cada arquitectura, añadiendo al final de la línea recipe.c.combine.pattern los modificadores: -lcrypto -lcurl. Este archivo está ubicado en la carpeta correspondiente del IDE de Arduino; por ejemplo, en la versión de IDE v1.6.2 o superior será:

  • Linux: /home/test/.arduino15/packages/Intel/hardware/i686/1.6.2+1.0/
  • Mac OS X: /Users/test/Library/Arduino15/packages/Intel/hardware/i686/1.6.2+1.0/
  • Win 8.1: C:\Users\test\AppData\Roaming\Arduino15\packages\Intel\hardware\i686\1.6.2+1.0/

Todos los archivos de configuración son leídos únicamente al iniciar el IDE de Arduino, por lo que hay que cerrarlo y volver a abrirlo para que los cambios tengan efecto.

Una vez realizados estos cambios en el IDE de Arduino, ya es posible utilizar las librerías del SDK en C de Latch, que podemos descargarnos desde el repositorio oficial, tal y como se muestra a continuación:

Un ejemplo de esta implementación se pudo ver en el pasado Hackathon IoT de Openbank; copatrocinado por ElevenPaths, se impartió un taller demostrativo integrando una hucha física con Latch.

En combinación con un conocido lector de huella dactilar para la autenticación biométrica del usuario, se realiza una delegación múltiple de la autorización de la extracción de monedas en terceros usuarios mediante Latch. Pudiendo combinar los diferentes pestillos de modo que tengan que estar todos abiertos (AND), o solo alguno de ellos (OR), para que tras la autenticación, la hucha expulse una cantidad de monedas definida.

Toda la configuración se almacena en un archivo JSON de fácil manipulación desde Arduino gracias a la librería aJson de Interacive Matter. Y para una mayor sencillez, la conexión física con el lector y la hucha, explota la capacidad de la placa Intel Edison para crear puertos serie virtuales en Arduino a partir de conversores USB, por lo que todo está conectado con un simple HUB USB, sin necesidad de realizar soldaduras ni ninguna otro conexión eléctrica.

El código ejemplo está publicado en el espacio de GitHub https://github.com/latchdevel/latch-moneybox

Tratamiento de metadatos automatizado en Clientes ICAP con Metashield

martes, 29 de diciembre de 2015

ICAP Internet Content Adaptation Protocol es un protocolo que permite encapsular contenidos de solicitudes HTTP con fines de filtrado y conversión en modo Petición (Reqmod mode) o modo Respuesta (Respmod mode), orientado a operar entre otros sobre dispositivos compatibles de control de red tipo firewalls, balanceadores, etc.

Mediante la utilización de este protocolo ICAP, Metashield propone una solución innovadora y escalable en la protección de los datos sensibles que pueden ir incluidos en los metadatos de los documentos que se entregan a los clientes desde servidores web.

Metashield for ICAP unido con un equipo que soporte este protocolo como el Secure Web GW de Blue Coat, interactúan eficientemente en el cumplimiento de este objetivo común:

  1. Todo comienza con una solicitud de descarga de un fichero realizada por parte de un cliente en un portal web.
  2. Esta solicitud llega al Cliente ICAP que como hemos comentado será un dispositivo de la seguridad de red que recogerá la petición y se la hará llegar al servidor que almacena la informacion (archivo).
  3. El servidor localiza y contesta al Cliente ICAP con una copia del archivo.
  4. El Cliente ICAP recoge el archivo y lo redirecciona hacia Metashield for ICAP que ejecuta el proceso de tratamiento.
  5. El Servidor ICAP devuelve el archivo limpio y es el Cliente ICAP el encargado final de suministrárselo al Cliente. Este sencillo proceso evita la fuga de información, que podría afectar económica y reputacionalmente a la organización o a los usuarios que almacenan, editan o distribuyen estos contenidos.

Este modelo, permite una gran flexibilidad ya que es independiente del tipo de servidor Web. Para la instalación de Metashield tan solo es necesario disponer de un equipo con S.O Microsoft® Windows Server 2008 R2 o superior con conexión de red, dotando a la organización de un eficaz sistema de protección contra las fugas de información embebida en los archivos, respetando en todo momento la integridad de los mismos.

Si el ecosistema de Metashield lleva incluida la consola será posible la configuración del tratamiento de los metadatos de un modo más personalizado, pudiendo crear perfiles específicos para su posterior aplicación sobre las extensiones o familias de ficheros seleccionados.

De esta manera se establece un procedimiento de seguridad adicional en entornos heterogéneos, proporcionando un valor añadido a la capa de seguridad establecida en la organización soportando las extensiones más populares de ficheros y archivos multimedia del mercado.


Ilustración 1 – Disposición Response modification para el tratamiento de metadatos con Metashield for ICAP

Una introducción al Trusted Execution Enviroment

lunes, 28 de diciembre de 2015

¿Quién no tiene hoy en día un “smartphone”? La aparición primero del iPhone pero sobre todo la aparición de Android ha propiciado que actualmente casi todo el mundo tenga uno de esos teléfonos inteligentes. En España por ejemplo , según el informe de la Fundación Telefónica, la penetración de los teléfonos inteligentes a finales del año 2014 suponía un 81% sobre el total de teléfonos. Dos años antes era de un 64%, por lo que el crecimiento en tan solo ese tiempo ha sido más que considerable.

Los smartphones actuales son mucho más funcionales y los usamos para una gran variedad de actividades: comunicación, acceso a redes sociales, compras online, transacciones bancarias o navegación en la web, en la mayor parte de los casos a través de aplicaciones que el usuario descarga de las distintas tiendas disponibles. Pero estas funcionalidades también han traído consigo la aparición de nuevos riesgos de seguridad y la creación de malware específico que han obligado a los fabricantes de terminales y proveedores de servicio a buscar nuevas soluciones para proteger a estos dispositivos.

Una de las iniciativas que han surgido para afrontar los problemas de seguridad inherentes a los smartphones, y más en el caso de Android, es el llamado Trusted Execution Environment. (TEE). Global Platform (GP), la organización encargada de estandarizar la gestión de aplicaciones en smartcards y SE (Secure Elements), es también la encargada de estandarizar el TEE.

El TEE es una área segura dentro del procesador principal de un smartphone que garantiza que la información sensible pueda ser almacenada, procesada y protegida en un entorno aislado y seguro. Es el lugar ideal para situar tanto el control de accesos como aquellas aplicaciones especialmente sensibles, que deben ejecutarse aisladas del sistema operativo del terminal.

Los últimos terminales de Samsung (S6, Note5) y Sony (Z5) de alta gama incorporan la tecnología TEE, y esperamos que poco a poco más fabricantes se sumen a esta iniciativa.


Figura 1: Autenticación en un Samsung S6 usando la huella dactilar.

Frente al TEE, la otra iniciativa más conocida para securizar un terminal viene del mundo Apple. Desde la aparición del Touch ID en el iPhone 5S, se viene utilizando una tecnología propia de Apple, pero con unos principios muy similares al TEE denominada “Secure Enclave”. La base de la seguridad en los iPhone está en el uso de un coprocesador dentro del SoC del A7, que utiliza su propio arranque seguro, software y procesamiento separado del procesador de las aplicaciones.

La principal diferencia a nivel funcional entre ambas está en que acceso al “Secure Enclave” se limita a día de hoy en iOS9 a funcionalidad de alto nivel como el TouchID o la generación y uso de pares de claves asimétricas (RSA y ECDSA). El TEE que define GP sin embargo persigue un objetivo más ambicioso, que no es otro que la estandarización de un conjunto de APIs para crear un entorno que permita la ejecución de aplicaciones de confianza de terceros dentro del área segura del terminal de forma interoperable.

EL TEE dentro de la infraestructura de seguridad de un terminal

Antes de continuar, es importante situar al TEE en el contexto de seguridad de un terminal. En este sentido en el terminal podemos distinguir tres entornos de gestión de aplicaciones con distintos niveles de seguridad:

  • Rich OS: Es el OS de alto nivel donde se ejecutan las aplicaciones, como Android, iOS o Windows Phone. Este entorno está abierto a la descarga y ejecución de aplicaciones. Aunque la seguridad es importante en este entorno, a este nivel prima la búsqueda de flexibilidad y versatilidad en el desarrollo de aplicaciones.
  • TEE: La principal función del TEE es la ejecución segura en un entorno de aislado de aplicaciones previamente autorizadas especialmente sensibles, que proporciona seguridad end-to-end, integridad de los datos y control de acceso. El TEE permite ejecutar aplicaciones con una interfaz de usuario atractiva, con una capacidad de procesamiento y acceso a memoria similar a la del sistema operativo de alto nivel del terminal. Además es capaz de acceder a muchos de los periféricos del terminal, incluido el SE, y de resistir a ataques software que normalmente ocurren en los sistemas operativos de alto nivel (OS rooting, malware, jailbreaking, etc.)
  • Secure Element (SE): Actualmente es el entorno más seguro donde pueden ejecutarse aplicaciones dentro del terminal. Aporta seguridad no sólo a nivel software sino a nivel hardware, y permite ejecutar aplicaciones y almacenar datos en un entorno seguro. Otra ventaja de los SE es que pueden ser movidos de un terminal a otro, incluyendo toda la información segura almacenada. Sin embargo, a pesar de su alta seguridad, el SE es un entorno muy poco flexible, con una funcionalidad muy limitada, tanto en términos de experiencia de usuario, capacidad de proceso como de almacenamiento.


Figura 2: Entornos de ejecución en un Smartphone en función de la seguridad ofrecida y la complejidad de implementación.

Lamentablemente, a día de hoy hay una relación inversa entre la seguridad y la flexibilidad en el desarrollo de aplicaciones. La figura anterior representan las características de facilidad de implementacion y seguridad en cada uno de los entornos mencionados. El diagrama refleja la fortaleza de cada uno de los entornos en cada capacidad concreta mediante el largo y ancho de las flechas.

Por último, hacer notar que los tres entornos no son mutuamente excluyentes sino complementarios, en el sentido que es posible implementar una aplicación donde se use el sistema operativo de alto nivel para aquella funcionalidad no sensible, el TEE para aquella funcionalidad que requiera del uso de interfaces de usuario seguras y el SE en las partes que requieran máxima seguridad.

Introducción a la arquitectura del TEE

El TEE es un entorno de ejecución seguro para aplicaciones autorizadas, conocidas como “Trusted Applications”, que implementan una funcionalidad critica desde el punto de vista de seguridad. Esta aplicación puede ser un servicio en sí misma, o puede ser una parte específica de una aplicación que se ejecuta en el OS estándar.

El TEE se encarga de proteger, y mantener la confidencialidad e integridad de la información y controlar el acceso a los datos que pertenecen a cada una de estas aplicaciones “confiables”. Con el fin de garantizar la base de confianza en el TEE, éste es autenticado y despues aislado del sistema operativo de alto nivel durante el proceso de arranque seguro.

En la siguiente figura se recogen los módulos fundamentales de la arquitectura del TEE.


Figura 3: Arquitectura de un TEE.

Dentro del TEE se distinguen dos tipos de software, el código interno propiamente del TEE (llamémosle kernel) y las aplicaciones confiables de terceros (“Trusted Applications”) que ejecutan su funcionalidad sobre ese código.

El kernel del TEE a su vez consta de:

  • Un core, que propociona una funcionalidad similar a la de un OS a las aplicaciones de terceros.
  • Un conjunto de funciones de más alto nivel para facilitar la labor de los desarrolladores de aplicaciones.

Las apliciones seguras de terceros ejecutan sobre este kernel y cada una de ellas es independiente de las otras, en el sentido de que una aplicación no puede realizar un acceso no autorizado a recursos de otra aplicación.

Las aplicaciones que ejecutan en el TEE consiguen acceso controlado a los recursos de seguridad y servicios a través del “TEE Internal API”. Dichos recursos incluyen la gestión de claves, criptografía, almacenamiento seguro, interfaz de usuario segura, etc.

El “TEE Client API” es una interfaz de comunicación a bajo nivel que permite a una aplicación que se ejecuta en el sistema operativo de alto nivel el acceso e intercambio de información con una aplicación segura que se ejecuta dentro del TEE.

Por último, el “TEE Functional API” ofrece un API de alto nivel a las aplicaciones cliente que se ejecutan en el sistema operativo estandar. Este API permite a estas aplicaciones acceder a servicios de criptografia y de almacenamiento seguro mediante un API familiar al usado en estos sistemas operativos.

El TEE y Mobile Connect

En Mobile Connect (MC) uno de los retos que nos planteamos es facilitar la autenticación de los usuarios, mediante métodos de autenticación fuerte sin contraseñas. A día de hoy en MC disponemos de autenticadores fuertes basados en los activos del operador como el SMS y la SIM, que nos permiten llegar a toda nuestra planta de usuarios móviles.

Pero queremos ir más allá e incorporar a MC los autenticadores biométricos, que en el mundo de la autenticación tienen una especial relevancia por la seguridad y experiencia de usuario que aportan, y que hoy en día ofrecen ya muchos terminales de gama alta. Para ello en MC integramos nuestra solución con FIDO, de una forma que garantiza que todos los autenticadores compatibles con el estándar UAF se integran en nuestra solución.

¿Qué aporta el TEE en este ecosistema? En la mayoría de los autenticadores biométricos (huella, reconocimiento de voz, reconocimiento facial), la validación del usuario se lleva a cabo en tres pasos:

  • Extraer la lectura de la huella, muestra de voz o la cara.
  • Almacenar en el dispositivo el patrón para una posterior comparación a partir de las siguientes lecturas.
  • Un motor de comparación, para analizar la comparación entre cada lectura y el patrón, y así validar al usuario.

El TEE se presenta entonces como el lugar ideal dentro del terminal para almacenar el patrón biométrico y todos los procesos necesarios para realizar la comparación entre la lectura y dicho patrón.

El TEE, por tanto, facilita a los proveedores de terminales la creación de autenticadores biométricos seguros. Pero no sólo eso, sino que la estandarización de las interfaces del TEE favorece la innovación de terceros, al permitir crear nuevos autenticadores basados en patrones biométricos alternativos, haciendo accesible el ecosistema a nuevos actores, y no solo a los fabricantes del terminales. La combinación de este hecho con FIDO hace además viable el acceso a cualquiera de estos autenticadores usando un mismo protocolo.

Y dado que MC integra FIDO en su solución de autenticación, cualquier Service Provider que utilice MC en sus procesos de autenticación, y sin realizar integración alguna podrá comenzar a usar de forma inmediata cualquiera de estos nuevos autenticadores biométricos.

Cristina Diaz
cris.diaz@11paths.com

Cybercrime is already a global scourge...Do you really think you are protected?

miércoles, 23 de diciembre de 2015

Nowadays, the exponential development experienced within the ICT field has led to a new scenario where the organizations are capable of exchanging information more effectively, stablishing new business models, and in general, decreasing operational costs while increasing their levels of efficiency and profitability.

Nevertheless, the technology has evolved for everyone, enabling cybercriminals to take advantage of these new and more sophisticated techniques, even perpetrating coordinated and complex attacks against organizations or their supply chain within a few minutes. Subsequently, this fact has driven to a new generation of threats and cybercrime which imply greater risks and a bigger impact for companies.

In fact, the latest figures indicate that the cybercrime cost already represents 0.8% of the global economy, even exceeding the drug and arms trade. The fact is that any organization can be attacked. The cybercriminals do not discriminate on the basis of the company location, size, industry or ethics anymore. Actually, recent studies show that the 97% of the organizations have been hacked or breached to a greater or lesser extent, and the 69% of the detected threats have been discovered by external agents, which means that the internal traditional means are not sufficient anymore.

Another clear example which shows the organizations are not prepared for this new scenario is that, according to the new figures resulting from the latest global reports, these ones take over eight months on average to notice and fully recover from an attack, fact which, in some cases, can result in a critical impact for the organization, and even becoming a threat to their own survival.

Therefore, it is clear that the traditional approach (castle security) is no longer sufficient to face the risks the organizations are exposed nowadays, but a focus beyond the own organization environment becomes necessary, focused on the security risks which impact on their business, included their supply chain. In this sense, the implantation of a new risk management model which adequately coordinates the capacities of prevention, detection, analysis, mitigation, response and recovery becomes essential.

For the purpose of addressing this new scenario, ElevenPaths counts on CyberThreats, whose holistic risk management model focused on cyberintelligence, help prevent, detect and respond continuously which against cyberthreats which might represent a high impact on the organization´s business model. Below the main modules on which CyberThreats is structured, is shown:

Overall, thanks to our expert team specialized in Threat Detection and Incident Response, along with the orchestration of our own proprietary technology and processes combined with the market´s best practices and strategic alliances, the organizations can benefit from a continuous advanced support through the entire threat lifecycle, which facilitates the decision-making process and corporate risk management. The next graph summarizes the CyberThreats' performance model, from the multiple-source scouting to the value delivery to customers:

For further information, please visit the CyberThreats webpage or contact us:

You might also be interested in:


Manuel Muñiz Somoza
manuel.muniz@11paths.com

El Cibercrimen ya es una plaga mundial…¿De verdad crees que estás protegido?

Hoy en día, el exponencial desarrollo e innovación experimentados en el campo de las TICs ha conducido a un nuevo escenario donde las organizaciones son capaces de intercambiar información más eficazmente, estableciendo nuevos modelos de negocio, y en general, disminuyendo sus costes operativos mientras incrementan sus niveles de eficiencia y rentabilidad.

Sin embargo, la tecnología ha evolucionado para todos, con lo que los ciberdelincuentes también hacen uso de estas nuevas tecnologías y de técnicas más sofisticadas, llegando a perpetrar ataques coordinados y complejos en cuestión de minutos contra las organizaciones o contra su red de proveedores. Consecuentemente, esto ha dado lugar a una nueva generación de amenazas y delitos cibernéticos que implican mayores riesgos y un mayor impacto potencial para las empresas.

De hecho, las últimas cifras indican que el coste del cibercrimen ya representa un 0,8% de la economía mundial, superando incluso al tráfico de drogas y armas. La realidad es que cualquier organización puede ser atacada. Los ciberdelincuentes ya no discriminan por la ubicación de las organizaciones, por su tamaño o dimensión, por el sector de actividad o incluso por cuestiones éticas. De hecho, estudios recientes indican que el 97% de las organizaciones han sido hackeadas o vulneradas en menor o mayor medida, y que el 69% de las amenazas detectadas han sido notificadas por agentes externos, con lo que los medios internos tradicionales ya no son suficientes.

Otro claro ejemplo de que las organizaciones no están preparadas para este nuevo escenario es que, según las cifras que arrojan los últimos informes y estudios a nivel global, éstas tardan más de 8 meses de promedio en darse cuenta de que han sido atacadas y llegan a recuperarse totalmente; pudiendo derivar en algunos casos en un impacto crítico para la organización e incluso afectar a su propia supervivencia.

Por lo tanto, es obvio que el enfoque tradicional (seguridad del castillo) ya no es suficiente para abordar los riesgos a los que están expuestos las organizaciones hoy en día, sino que es necesario adoptar un enfoque más allá del entorno de la propia organización, focalizado en los riesgos de seguridad que impactan en su negocio, incluida su cadena de suministro. En este sentido, es esencial la implantación de un nuevo modelo de gestión de riesgos que articule adecuadamente capacidades de prevención, detección, análisis, mitigación, respuesta y recuperación.

Con el propósito de hacer frente a este nuevo escenario, ElevenPaths cuenta con CyberThreats, cuyo modelo holístico de gestión de riesgos centrado en ciberinteligencia ayuda a prevenir, detectar y responder de forma continua a ciberamenazas que pueden suponer un alto impacto en el modelo de negocio de las organizaciones. A continuación se muestran los principales módulos en los que se estructura CyberThreats:

En líneas generales, gracias a nuestro equipo de expertos en Detección de Amenazas y Respuesta a Incidentes y a la orquestación de nuestra propia tecnología y procesos junto con las mejores prácticas del mercado y alianzas estratégicas, las organizaciones pueden contar con un soporte continuo y avanzado durante todo el ciclo de vida de las amenazas que facilita el proceso de toma de decisiones y gestión de riesgos corporativos. El siguiente gráfico sintetiza el modelo de funcionamiento de CyberThreats desde la exploración de múltiples fuentes hasta la entrega de valor al cliente:

Para más información, visita la web de CyberThreats o contacta con nosotros.

También te puede interesar:


Manuel Muñiz Somoza
manuel.muniz@11paths.com

ElevenPaths highlights 2015

martes, 22 de diciembre de 2015


365 días en ElevenPaths dan para mucho. Un año más compartimos con vosotros los hitos que, a vuestro lado, han marcado nuestro 2015:

Creemos en la idea de desafiar, de reinventarse, en la innovación, en la de romper las reglas, en las de ir un paso por delante de los atacantes y amenazas digitales, en el cambio... y cómo no, en liderar la revolución digital ofreciendo una experiencia digital segura. Gracias un año más por confiar en nosotros para impulsar y vivir este cambio juntos. Estamos seguros de que 2016 va a ser un gran año y queremos compartirlo con vosotros.

¡Felices fiestas y feliz 2016!

Vamps: Recupera el control de los activos IT de tu organización

viernes, 18 de diciembre de 2015

¿Sabes si los responsables de sistemas IT de tu empresa conocen todos los activos expuestos a Internet? Aunque lo parezca, no es sencillo. Una empresa con varios equipos, departamentos, necesidades cambiantes, y preocupada por la realización del trabajo diario, a veces no puede detenerse a mirar a su alrededor y pensar, ¿cuántos servidores he montado? ¿cuántos equipos están ahí fuera? ¿se han actualizado todos tras las últimas vulnerabilidades? La estructura informática y de comunicaciones es un medio, no un fin en sí mismo. Para cumplir el objetivo real, se utilizan servidores, conexiones, sistemas y programas, hasta que llega un momento en el que resulta que los administradores no conocen sus propios sistemas, no los controlan realmente.

Por qué ocurre

No resultará complejo entender por qué se llega a este punto. Algunos ejemplos:

  • El desarrollo/adquisición de nuevos servicios o aplicaciones y la mejora de los existentes para responder a las necesidades del negocio de forma rápida y eficiente, prácticas habituales en un entorno tan cambiante, pueden ser causas de cambios en la infraestructura tecnológica.
  • Cambios no autorizados en la infraestructura como la instalación de servidores, sistemas operativos o paquetes de software en puertos específicos que no son comunicados inmediatamente a los grupos responsables de la organización por falta de coordinación o compromiso entre los procesos implicados.
  • Shadow IT, añadiendo elementos a la infraestructura que están fuera del control de TI. Generalmente las áreas de negocio de las organizaciones tienen problemas para lanzar servicios a producción en al dilatarse los plazos proporcionados por TI, tomando la decisión de contratar los servicios en una infraestructura paralela externa a la organización.
  • Activos descuidados que no están siendo gestionados o de los que ha olvidado su existencia que no cubren ninguna necesidad del negocio pero, al estar expuestos en Internet, introducen un nuevo vector de ataque a la organización.

Los atacantes continuamente buscan servidores obsoletos y versiones de software sin actualizar que puedan ser explotados de forma remota y ganar acceso a la organización, por eso es importante conocer qué elementos (servidores, sistemas operativos, paquetes de software) forman parte de la infraestructura del cliente y en qué estado de actualización se encuentran.


Retos IT para una organización distribuida

La solución

Para dar solución a estos retos, presentamos Vamps, nuestra solución para identificar amenazas de seguridad y posibles métodos de ataque contra los sistemas informáticos de una organización permitiendo gestionar rápidamente su corrección. Además, se emplea también Faast, nuestra tecnología de pentesting persisntente, la cual realiza el descubrimiento de activos vulnerables como si fuera un vídeo, de forma continua, sobre todos los activos digitales de tu empresa que son accesibles desde Internet, para reducir el tiempo en detectar cambios en la infraestructura y brechas de seguridad.

Faast, usa las mismas técnicas que realizaría un atacante externo o interno que pretende traspasar la seguridad de la organización, comenzando por un nombre de dominio asociado a la organización se descubre nombres de hosts y de aplicaciones web a través de la búsqueda de URLs en Google o Bing, además de servidores DNS y otros servicios web (archive.org, whois, etc.), sin ninguna limitación previa como un rango de direcciones IP o listados de nombres de servidores, dando como resultado el conjunto de activos y versiones de software de una organización, incluso aquellos activos que se desconocía su existencia.

Ejemplo de descubrimiento partiendo desde dominio democyberdac.com

Dentro del proceso de descubrimiento, la solución empleada por Vamps determina de forma precisa y fiable los cambios de sistema operativo y paquetes de software instalado en los activos. Para llevarlo a cabo analiza y detecta todos los servicios de red ofrecidos por cada una en las direcciones IP del activo, proporcionando información detallada sobre qué servicios de red están siendo ejecutados en cada uno de los sistemas descubiertos y cuáles son las versiones de software que tiene instalados.

Detalle de direcciones IP, puertos y software de servidor descubierto


Software identificado sobre activo descubierto


De esta forma las organizaciones pueden comprobar para cada activo si tiene los programas instalados requeridos con la versión apropiada en función del tipo de sistema y que se encuentre libre de vulnerabilidades conocidas.

Una vez que el sistema ha registrado las versiones de software, Vamps permite la notificación personalizable de las nuevas vulnerabilidades de fabricantes que afectan específicamente al software de sus activos. Por ejemplo, podría estar informado de todas las nuevas vulnerabilidades que afecten al activo www.democyberdac.com, que serían las publicadas referentes a software Apache Http Server, PHP, OpenSSL...Este enfoque nos permite pasar de recibir numerosos correos alertando que "Existe una vulnerabilidad en Apache" a vulnerabilidades potenciales sobre activos de la empresa como "El activo www.democyberdac.com se encuentra afectado por la vulnerabilidad x de Apache".

Se pueden establecer criterios de configuración de las alertas en base a varios parámetros como la severidad según la métrica CVSS, cuándo ser notificado (diariamente, semanal), o estar informado de las vulnerabilidades que afecten a los productos de una familia concreta, entre otros.

Definición de alerta de vulnerabilidad sobre software Apache http server

Para cada activo descubierto se puede crear una serie de etiquetas personalizables y atributos como ubicación, propósito, responsable, nivel de criticidad, etc.

Listado de etiquetas personalizadas por la empresa


Esto le permitirá una gestión más efectiva, a través de listados o informes de vulnerabilidades sobre activos con la clasificación definida por la empresa, facilitando la obtención de métricas que respalden decisiones operativas y estratégicas.

Detalle de filtro utilizando etiquetas definidas por cliente


Creación de informe de seguimiento sobre activos con etiquetas creadas por cliente


Una vez finalizado el descubrimiento de activos, se reinicia este proceso de forma continua y recursiva con la información obtenida, lo que proporciona al cliente una visión actualizada del inventario de sus activos autorizados, desautorizados y aquellos que ha descuidado su existencia accesibles desde el exterior, independientemente de su tamaño.

También te puede interesar:

* Gestión de vulnerabilidades con pentesting persistente, una visión global (I)

Víctor Mundilla
victor.mundilla@11paths.com

Metashield for Exchange soon to be available. How does it work?

miércoles, 16 de diciembre de 2015

Metashield for Exchange stacks up to our currently offered server-side metadata cleaning solutions and broadens the flexibility and customization options that we offer companies to get rid of sensitive information and metadata leaks.

A plugin for Outlook is already offered but depending on the needs and architecture of an organization’s servers it may opt for a centralized Exchange-specific solution. In this case, it will be easier for the end user because the cleaning process is completely transparent and occurs asynchronously on the server.

So where exactly does Metashield For Exchange fit in the Exchange message pipeline? There are several roles that run in Exchange servers such as Mailbox, Client access and Edge Transport server roles. Metashield For Exchange is installed to Mailbox servers as a plugin-like "Routing Agent" and resides more specifically in the "Transport" service.

Once configured, instances of Metashield For Exchange are then spawn according to outgoing messages. These instances bind to the "OnSubmittedMessage" event of the message delivery pipeline and perform the cleaning process of the document asynchronously using the "Metashield Engine" service. As soon as the document is clean it’s sent forth to the pipeline until its destination.

This way we ensure that every single outgoing document is metadata-free when reaching our organization mailserver’s outer boundaries.

Source: https://msdn.microsoft.com/en-us/library/office/dd877035(v=exchg.150).aspx

However there are cases that a certain email attachment should not be cleaned and metadata should be maintained. For this purpose the administrator can define advanced rules to skip those messages and leave them "unclean".

Configuring Metashield whitelist
As for customizable options, a caching layer is available and configurable as memory or file based. Considering the case of forwarded message chains containing attachments, the use of a cache may result in significant performance boost. We reccomend its use.

Using cache in Metashield for Exchange

Of course, the profile and template based cleaning system known from other "Metashield" products is maintained. For the sake of example, let’s see a real world configuration where documents should include information about a company but all other metadata is cleaned:

A step by step example
 
First of all a new template with the desired actions needs to be created. This one will be a simple one for demonstration purposes.


Creating a new template

After that, the newly created template should be assigned to the desired extensions or extension families.

Add the template to a profile
Upon applying the configuration "Metashield" will start cleaning all the newly configured extesions and will include the company information that we’ve configured in the template. That simple. 

Overall we hope that Metashield For Exchange contains everything that a System administrator concerned about security needs to prevent metadata leakage in corporate emails, while maintaining usability and good performance.

A fondo: SealSign (y II)

martes, 15 de diciembre de 2015

En el post anterior sobre SealSign nos centramos en las novedades de los componentes de firma electrónica y biométrica. En este artículo vamos a describir las novedades que proporcionan los otros dos: el almacén centralizado de claves CKC, el módulo más extendido de SealSign, y el repositorio seguro.

Nuevas mejoras
Aparte de estos cambios, la plataforma incluye muchas mejoras que abarcan todos los componentes: optimización del acceso a claves en HW a través de PKCS#11, soporte de Chrome y Firefox en la herramienta de administración, traducción de los textos al inglés, configuración de la apariencia del grafo de la firma, etc. Para una lista completa de los cambios se puede consultar el fichero History.txt incluido en la instalación del producto. Toda la documentación de la plataforma esta ahora disponible online para asegurar la integridad y velocidad de publicación de las últimas versiones. Ya puedes consultarlo en nuestro canal de slideshare.

Claves centralizadas
Uno de los componentes de mayor éxito de la plataforma es el gestor de claves centralizadas y virtualización de certificados en el puesto. Se ha mejorado sustancialmente la gestión de claves en dispositivos HW como HSMs a través de PKCS#11. Hasta la versión 3.0 solo el administrador de la plataforma permitía la creación de reglas de uso de los certificados que permitían controlar y delegar el acceso de los usuarios a la clave privada. A partir de la versión 3.1 se ha incluido esta funcionalidad dentro del portal de autoservicio del usuario, flexibilizando todavía más la gestión de certificados en la organización. Además, se ha optimizado el proceso de inicialización del cliente de forma que la carga de procesos que hacen uso de certificados remotos, como IE, no impacta en la experiencia de usuario.

Workflow de solicitud de uso
Como módulo adicional al uso de claves centralizadas, se ha desarrollado una herramienta de workflow de solicitud de acceso a los certificados. De esta forma, los usuarios que deseen poder utilizar un certificado para una operación en concreto, deberán solicitarla mediante la web de solicitud proporcionada. Esta petición llegará vía e-mail a cada uno de los aprobadores definidos para dicho flujo, con un enlace a una web de aprobación, donde podrán aceptar o rechazar la solicitud. En función del tipo de aprobación y las respuestas de los aprobadores, se le dará o no de alta al usuario solicitante como autorizado de la operación durante el tiempo definido en el período de auto-renovación. Además, el sistema comunicará vía e-mail al usuario solicitante el resultado de su solicitud.

Otras mejoras
El módulo de gestión de claves centralizadas permite realizar un inventario de todos los certificados utilizados en la organización. Proporcionando una fuente de información del uso de certificados y la posibilidad de detectar certificados no autorizados. Además, el cliente tiene la funcionalidad de autoimportar de forma transparente al usuario los certificados del store local del usuario al servidor de SealSign (certificados locales, no centralizados). Se han añadido de forma nativa y de forma experimental el borrado de claves huérfanas: Por defecto en las plataformas Windows de Microsoft, cuando se borra un certificado del Store de certificados, no se borra su clave privada asociada. Esto es así por diseño. Para mitigar este posible agujero de seguridad se puede activar esta política, que en esencia realiza un purgado de las claves privadas huérfanas en el store del usuario.

Repositorio seguro
Aparte del cambio de arquitectura que permite el uso de Oracle como base para el almacenamiento de documentos en el repositorio seguro, se ha añadido un interfaz de búsqueda de documentos mediante los metadatos que simplifica la localización y descarga de documentos del repositorio.

* A fondo: SealSign (I)


Antonio Vila
antonio.vila@11paths.com

Plugin para EmetRules: Ahora, más fácil de usar

lunes, 14 de diciembre de 2015

EmetRules es una herramienta que creamos hace dos años. No es que estuviese destinada a cambiar el mundo, pero resulta una primera incursión en el universo del certificate pinning y facilita una de las funcionalidades de EMET que resulta más compleja de usar: el pinning. Hemos desarrollado ahora un sencillo plugin para internet Explorer que usa EmetRules a su vez, para que el pinning con EMET sea todavía más sencillo. Veamos cómo funciona.


Internet Explorer es el único navegador (de los principales) que no soporta aún HPKP. De hecho, es el navegador con menos opciones a la hora de realizar certificate pinning en general. EMET incluýo hace algunas versiones una funcionalidad para pinear dominios, pero era su uso resultaba engorroso. Por eso creamos EmetRules para pinear varios dominios de una vez.

EmetRules cuenta con algunos fans. Así que hemos creado un plugin sencillo para llamar a EmetRules desde el navegador. Así, es incluso más fácil pinear un dominio, con solo darle a un botón. El dominio acabará en la configuración de EMET y será pineado ahí

EmetRules también ha sido actualizado para soportar la llamada directa desde el navegador, añadiendo una nueva opción. Para explicarlo mejor, aquí van algunos pantallazos de cómo funciona.

  • Se visita el dominio que se quiere pinear con Internet Explorer.

Se visita el dominio que se quiere pinear
  • Se pulsa sobre el icono en la barra de herramientas, o se pulsa con el botón derecho en cualquier punto de la web buscando la opción "Pin with EmetRules"

Se puede usar el icono o la opción del menú con el botón derecho
  • La primera vez que se use, aparecerá una alerta. Todo está bien siempre que el programa esté firmado por nosotros. Esto significa que el sistema operativo está avisando de que un programa externo está siendo llamado desde dentro de una web y que quiere salir del modo protegido (o sea, que será lanzado en nivel de integridad medio en vez de bajo).
Advertencia sobre la ejecución de un fichero desde el navegador
  • Ahora se pasa el control al EmetRules "tradicional". Aparecerá una ventana de comandos que tomará el certificado raíz, construirá el XML para EMET y se lo dará
  • Si eres "administrador pero no administrador" (usas UAC), aparecerá un diálogo de UAC, puesto que insertar dominios de EMET necesita elevar privilegios.
  • Si todo va bien, el dominio aparecerá pineado en EMET.
El dominio se pinea finalmente con EMET

Si se quiere cambiar al gusto la funcionalidad, se puede hacer modificando directamente el html en el directorio de instalación.

Esperamos que os sea útil. La herramienta está disponible desde aquí.


Plugin for EmetRules: Now, easier to use

EmetRules is a simple tool we created two years ago. Not meant to change the world, it was a first incursion in certificate pinning universe, and intended to ease one of the harder-to-use-features of EMET: pinning. We have developed now an easy plugin for Internet Explorer that uses EmetRules, so pinning with EMET is easier than ever. Let’s see how it works.

Internet Explorer is one the only (main) browser not supporting HPKP yet. In fact, is the browser with fewer options to pin certificates in general. EMET included a few versions ago a feature for pinning, but it was indeed complicated and tricky to use. So we created a simple tool called EmetRules to pin lots of domains at once.

EmetRules counts with some fans. So we have created a very simple plugin for calling EmetRules from the browser itself, so it is even easier to pin a domain. Just visit it, and click a button. The domain will go to EMET configuration and will be pinned there

EmetRules itself has been updated to support being called directly from Internet Explorer, just adding a new option. To better explain it, a few screenshots of how it works:
  • Visit the domain you want to pin with Internet Explorer.

Visit the domain you want to pin
  • Click on the icon in the bar, or right click somewhere on the webpage and "Pin with EmetRules"
Use the icon or the entry in the right click menu
  • The first time you use it, a warning signal will appear. It is ok as long as the program is signed by us. This means the operative system is telling you an external program is being called from somewhere inside a web and wants to go out from the protected mode (is going to be launched in medium integrity level instead of low).
Warning about executing a file from the browser
Now it on depends on the "traditional" EmetRules. A command window will be launched, it will fetch the certificate for you, build an XML file and feed EMET.
  • If you are an "admin and not an admin" (you are using UAC), an UAC dialog will prompt, since inserting domains in EMET needs administrator privileges.
  • If everything is ok, the domain will appear in EMET pinning panel.
The domain is finally pinned in EMET

If you want to modify default settings, just modify the html file (JavaScript) in the installation directory.

 Hope you enjoy it. The new version may be downloaded from here.


Sinfonier y Telegram

viernes, 11 de diciembre de 2015

La cuenta de Twitter de Emergencias Madrid utiliza como uno de los canales de comunicación las alertas que Twitter permite gestionar para la notificación masiva, en este caso, para información crítica en situaciones de emergencia. Esto ejemplifica cómo los canales de comunicación están cambiando y cóomo surgen nuevas oportunidades todos los días delante de nosotros. Conscientes de esta realidad, vemos que es el momento de comenzar a trabajar en estas alternativas. Por suerte para nosotros ya está disponible en Sinfonier los módulos necesarios para interactuar con Telegram: TelegramUpdates y TelegramMessage Drain.

Primero, veamos cómo utilizar TelegramMessage. Se trata de un sencillo Drain que nos permite enviar mensajes usando Telegram BotAPI. El Bot API es un interfaz basado en HTTP creado para la creación de bots para Telegram.

En Telegram los bots son cuentas especiales diseñadas para manejar mensajes de forma automática. Los usuarios pueden interactuar con ellos enviando comandos de forma privada (solamente al bot) o en grupos.

Este Drain necesita tres parámetros para funcionar correctamente:
  • Token: clave para autenticar a nuestro bot.
  • Chat_id_field: nuestro identificador para el chat.
  • Textfield: el campo de texto para los mensajes que serán enviados.

¿De dónde sacamos estos parámetros? Veamos cómo conseguirlos:
  1. Crear una nueva cuenta tipo Bot y obtener el Token
  2. Lo primero es crear un nuevo bot en Telegram . Para crear la cuenta tenemos que hablar con el BotFather. Una vez arranca el bot podemos ver un menú de ayuda con todos los comandos disponibles. Estos comandos se utilizan para manejar las cuentas tipo bot: podemos crear una cuenta, configurar el nombre, la descripción, privacidad e incluso eliminar el bot, entre otras cosas.

    El comando/newbot crea un nuevo bot. Tendremos que darle un nombre y un “username” y el BotFather nos dará el Token. ¡Perfecto! Ya tenemos nuestro Token y por tanto nuestro primer parámetro. Vamos a por el siguiente.

  3. Configuración del modo privado y obtener el “chat_id of a conversation”
  4. Los Bots no pueden comenzar conversaciones con los usuarios. Debe ser el usuario el que comience la conversación para obtener el “chat_id”. Pero antes de comenzar a charlar con un bot tenemos que cambiar la privacidad del mismo a “disabled”. Si dejamos la privacidad activa nuestro bot solamente reconocerá mensajes que comiencen con una barra “/”, es decir, comandos. Ya podemos comenzar a charlar con nuestro bot como si fuese otro usuario.

    Ahora podemos obtener el chat_id consultando el método getUpdates del API HTTP. Para hacer esto, solamente necesitamos el token que hemos obtenido en el paso anterior y no tener miedo a leer un fichero tipo JSON.

    El id que buscamos está en: message -> chat -> id.

  5. Probando TelegramMessage Drain
  6. Ahora que tenemos los dos parámetros que nos sirven para interactuar con Telegram solamente nos falta decir a nuestro Drain qué campo queremos enviar al usuario. Para probar que funciona correctamente utilizaremos un Spout que genera información de forma continua y que nos sirve para comprobar que sabemos configurar nuestro módulo y hemos creado el bot correctamente.

TelegramUpdates Spout
Ahora que tenemos nuestro Drain necesitamos poder leer los mensajes que los usuarios nos envíen. Para ellos vamos a utilizar el método que vimos antes para obtener el chat_id, getUpdates.Para ello, recuperaremos los mensajes bajo una frecuencia configurable. Cada mensaje nuevo lo emitiremos a la topología para procesarlo.

En la siguiente topología vemos lo sencillo que es recuperar los mensajes y acto seguido reenviarlos sin procesamiento alguno. Solamente utilizamos un bolt que nos ayuda a simplificar el JSON que recibimos de Telegram para acceder a los datos que nos interesan de forma más sencilla.

¿Qué significa el parámetro offset? Simplemente nos sirve para indicar al Spout desde qué update_id debe comenzar a procesar los mensajes.

Bot de Telegram interactuando con Latch y VirusTotal
En este caso vamos a ver cómo interactuar con nuestra tecnología Latch y VirusTotal mediante un bot que nos permite indicar a usuarios que estén en un grupo concreto que hemos comenzado a realizar una acción concreta (en este caso, conducir) y además el bot comprobará cada URL enviada al chat contra VirusTotal. Cómo crear esta topología:



Sinfonier integrado con Intel Edison y Latch
Este segundo ejemplo muestra cómo nuestra tecnología Sinfonier interactúa con una Placa Intel Edison gestionando el acceso a la placa mediante de nuevo con Latch. Cómo crear esta integración:




Fran Gómez
franciscojesus.gomez@11paths.com
@ffranz