See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/313400021

Metodología de análisis de riesgos para la mejora de la seguridad del Internet

de las Cosas. Caso Smartwatch

Working Paper · February 2017

DOI: 10.13140/RG.2.2.16026.24005

CITATIONS READS

0 2,393

1 author:

Alberto Tejero
Universidad Politécnica de Madrid
8 PUBLICATIONS   8 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Technology Intelligence Services for SMEs through IBM Watson View project

All content following this page was uploaded by Alberto Tejero on 07 February 2017.

The user has requested enhancement of the downloaded file.

 Working Paper:

Metodología de análisis de riesgos para la mejora

de la seguridad del Internet de las Cosas.
Caso Smartwatch
Alberto Tejero1
Febrero 2017

Abstract

El Internet de las Cosas avanza a pasos agigantados, aunque no así su seguridad, algo que
supone un foco importante de riesgos, vulnerabilidades y amenazas, pero que también abre la
puerta al desarrollo de nuevas soluciones y oportunidades. El objetivo de esta investigación se
centra en la creación de una metodología capaz de mejorar la seguridad de los Smartwatch o
relojes inteligentes, uno de los productos de mayor crecimiento dentro del Internet de las
Cosas, mediante un proceso sistematizado de análisis de la seguridad, donde además del
propio dispositivo se analizan el resto de los elementos normalmente implicados: teléfono
móvil, comunicaciones y Cloud. Mediante la evaluación de la metodología en dos de los relojes
inteligentes más conocidos, Apple Watch y LG G Watch R W110, se verifica la idoneidad,
viabilidad y funcionalidad, a la hora de analizar la seguridad de estos dispositivos y recomendar
acciones para la mejora de su seguridad.

Keywords

Internet de las Cosas, IoT, Smartwatch, metodología, análisis de riesgos, evaluación, seguridad
informática.

1
Master’s Degree in Computer Science and Master’s Degree in Business and Administration. Centro de
Apoyo a la Innovación Tecnológica. Universidad Politécnica de Madrid (Spain). Email:
alberto.tejero@upm.es
Contenidos
Abstract ......................................................................................................................................... 1
Keywords ...................................................................................................................................... 1
1. Introducción .......................................................................................................................... 3
2. Metodología para el análisis de la seguridad de Smartwatch ............................................ 4
2.1. Definición de la metodología de análisis de riesgos a aplicar ............................................ 4
2.2. Identificación de los riesgos potenciales............................................................................ 9
2.3. Identificación de los objetivos de control ........................................................................ 12
2.3. Identificación de los controles ......................................................................................... 13
2.4. Definición de las pruebas ................................................................................................. 15
2.5. Diseño del cuestionario .................................................................................................... 17
3. Aplicación de la metodología ............................................................................................. 19
3.1. Revisión de la seguridad ................................................................................................... 20
3.2. Fiabilidad del sistema y recomendaciones de seguridad ................................................. 21
3.2.1. Obtención del riesgo real .............................................................................................. 21
3.2.2. Recomendaciones para mejorar la seguridad............................................................... 24
3.2.3. Resumen de pasos a realizar ......................................................................................... 25
4. Evaluación de la metodología ............................................................................................ 26
4.1. Primer caso de evaluación ............................................................................................... 26
4.2. Segundo caso de evaluación ............................................................................................ 29
4.3. Comparativa de resultados .............................................................................................. 31
5. Conclusiones ....................................................................................................................... 33
6. Trabajo futuro ..................................................................................................................... 34
Referencias ................................................................................................................................. 36
1. Introducción

El Internet de las Cosas (IoT) sigue una línea de crecimiento imparable que sorprende a
extraños y expertos. Así, en 2020 se prevé que existan más de 50 billones de dispositivos IoT
conectados, es decir, que por cada persona se disponga de entre 6 y 7 dispositivos IoT. Para los
consumidores, supone una herramienta que les ayuda a alcanzar sus objetivos mediante una
ampliación en la recopilación de datos de su propia actividad. A nivel empresarial, el IoT ayuda
a las empresas a lograr una mayor optimización y eficiencia de los procesos a través de los
datos recibidos en tiempo real.

Existen una serie de factores que han hecho posible este crecimiento del IoT, como es que el
tamaño y costes de las radiofrecuencias inalámbricas se haya reducido considerablemente,
que el IPV6 permita asignar direcciones para la comunicación a miles de millones de
dispositivo, que las compañías de electrónica estén construyendo Wi-Fi y conectividad celular
inalámbrica en una amplia gama de dispositivos, la ampliación de cobertura de datos móviles,
y que la tecnología de las baterías haya mejorado considerablemente. Así, la hoja de ruta
tecnológica de IoT pasa por la nube (Cloud), algo con lo que se pretende obtener una
arquitectura flexible y abierta, centrada en el usuario, que habilite que diferentes elementos
puedan interactuar dentro del marco de operación de IoT.

La mayoría de los dispositivos wearables, como es el caso de los Smartwach, interaccionan y

dependen de los teléfonos móviles, que los utilizan como fuente de conexión a la red y como
base de transferencia y almacenamiento de información, también en plataformas Cloud. A
nivel software, los relojes inteligentes se componen de un sistema operativo y de aplicaciones
o apps que utilizan para realizar sus funciones, en conjunción con las apps instaladas y
gestionadas desde el teléfono móvil, así como de la información normalmente almacenada en
Cloud. Todos estos elementos son fuentes de ataques y susceptibles de ser vulnerados, por lo
que todo este conjunto conforma la superficie total de exposición en cuanto a seguridad se
refiere.

En referencia precisamente a la seguridad y privacidad, el principal problema radica en que en

IoT cada objeto inteligente puede estar conectado a Internet y puede comunicarse con otros
objetos, por lo que se abren multitud de posibles escenarios y problemas de seguridad y
privacidad, en todas las dimensiones conocidas, que afectan de forma muy directa a la
confidencialidad, autenticidad e integridad, pero también a nuevas que aparecen con estos
nuevos escenarios:

 El actual diseño a nivel hardware de las tecnologías IoT impone grandes dificultades para
la aplicación de la seguridad tradicional en estos dispositivos, lo que hace necesario
establecer nuevos métodos para su protección.

 Con la evolución del IoT será necesario disponer de una infraestructura mayor de software
y, por tanto, se incrementará su complejidad, típico foco de problemas de seguridad, al
aumentar significativamente la superficie de exposición a vulnerabilidades y amenazas.
 Las comunicaciones inalámbricas, vitales para la comunicación actual de los distintos
dispositivos del IoT, además de no ser las más adecuadas a nivel funcional, presentan
grandes deficiencias en cuanto a su seguridad, como en el caso del Bluetooth o el Wi-Fi.
 El incremento de información recopilada por estos objetos también complica cada vez más
temas de tanta transcendencia como la privacidad, requiriéndose la aplicación de
controles para evitar accesos ilícitos o incluso robos de información.

 El cumplimiento normativo y de legislación, dependiendo del lugar donde estén ubicados

los objetos IoT, supone también otro gran reto a solucionar.

 La Comisión Europea hace especial hincapié en la falta de calidad en cuanto al

consentimiento del usuario, referido a la información recopilada por estos dispositivos,
entre la que suele encontrarse muchos de sus datos personales, algo que claramente
podría chocar con la legislación comunitaria.

 La evolución futura y actual que experimenta el IoT hace muy difícil identificar los
controles más apropiadas para la seguridad de estos sistemas, por lo que se apunta a la
necesidad de tener que definir nuevos controles adaptados a cada sistema o arquitectura,
hasta el día que, si es posible, se llegue a una homogeneización de las arquitecturas sobre
la que se basan estos objetos.

Por todo ello, se apunta a la necesidad de que el Internet de las Cosas deba ser construido de
forma tal que se garantice un control fácil y seguro por parte del usuario. Los consumidores
necesitan de esa confianza para entrar en el IoT y disfrutar plenamente de los beneficios que
puede brindarles, pero evitando los riesgos contra su seguridad y privacidad, siempre que sea
posible y dispongan de herramientas para ello.

2. Metodología para el análisis de la seguridad de Smartwatch

2.1. Definición de la metodología de análisis de riesgos a aplicar

Según la International Standard Organization (ISO), la definición de activo sería: “Algo que
tiene valor para la organización”. ISO/IEC 13335-1:2004. Cambiando de enfoque, si en lugar de
una organización se tiene en cuenta al usuario, la definición de activo en nuestra metodología
sería: “Algo que tiene valor para el usuario”.

Contextualizando un poco más, la metodología que se pretende debe estar enfocada a analizar
la seguridad de dispositivos Smartwatch. Pero atendiendo a lo mencionado anteriormente,
este tipo de dispositivos no trabaja de forma independiente, sino que requiere de la
interacción de otros elementos para poder realizar las funciones y servicios para lo que ha sido
diseñado. Bajo esta premisa, el Smartwatch, en conjunción con esos elementos necesarios
para su funcionamiento, se podría decir que conforma un “Sistema de Smartwatch”.

Así, partimos de un “Sistema de Smartwatch” cuya composición atiende habitualmente al

esquema mostrado en la siguiente ilustración:

Smartwatch + Comunicaciones + Smartphone + Cloud

Ilustración 1. Sistema base para análisis de la seguridad de Smartwatch (Elaboración propia)

En base a este esquema, la metodología se focaliza en analizar la seguridad de este

denominado “Sistema de Smartwatch”. Además, según la definición de activo señalada antes
como “algo que tiene valor para el usuario”, dentro de este sistema se puede identificar como
principal activo a la información. La información generada a partir de la actividad del usuario,
pero también la información aportada directamente por éste, ya sea a través de sus datos
personales, bancarios o de cualquier otra índole.

Recapitulando, disponemos de un “Sistema de Smartwatch” que pertenece a un usuario y cuyo

principal activo es la información. Por tanto, si entendemos este sistema como un sistema de
información, en términos de activos del sistema de información es posible distinguir
(Fernández and Delgado, 2014):

- Al usuario.
- La información.
- El software (sistema operativo y aplicaciones).
- Hardware.
- Comunicaciones.
Además, hay que tener en cuenta que todo sistema de información debe:

- Salvaguardar la propiedad de la información.

- Mantener la integridad de la información.
- Asegurar la confidencialidad de la información.
- Garantizar la disponibilidad de la información.
- Llevar a cabo los fines del usuario, es decir, ser eficiente en el sentido de que debe
cumplir los objetivos del usuario.

Y, precisamente, la gestión de la seguridad de la información se centra en preservar las tres

dimensiones de seguridad principales asociadas a la información, que según AENOR2 son:

- Disponibilidad. Asegurar que los usuarios autorizados tienen acceso cuando lo

requieran a la información y sus activos asociados.
- Confidencialidad. Asegurar que la información es accesible solo para aquellos
autorizados a tener acceso.
- Integridad. Garantizar la exactitud y completitud de la información y los métodos de su
proceso.

Aquí es importante señalar que la información se encuentra expuesta a riesgos, entendiendo

riesgo como la probabilidad de amenazas a los activos que utilicen las vulnerabilidades
(debilidades) y se produzcan impactos negativos. El análisis del riesgo y la implantación de
controles son la herramienta primordial para mitigar el riesgo. Y aunque el riesgo siempre
existe, éste se puede mitigar, siendo su mitigación el objetivo de aplicar controles de
seguridad.

Teniendo en cuenta todo lo anterior, el presente trabajo tiene por objetivo el diseño de una
metodología de análisis de la seguridad, o auditoría, cuya fase de conocimiento está basada en
la evaluación de riesgos y enfocada al que hemos denominado “Sistema de Smartwatch”. Un
proceso de auditoría basado en la evaluación de los riesgos permite cuantificar el riesgo de los
sistemas de información, es decir, la medida en que es posible asegurar la integridad,
confidencialidad y disponibilidad de la información que manejan estos sistemas. Así una
metodología de análisis de riesgos se compone habitualmente de los siguientes elementos:

- Análisis de los riesgos. Se trata de un proceso sistemático para identificar y estimar la

magnitud del riesgo. Es posible distinguir entre:
o Análisis de riesgos cualitativo. En el que se usa una escala de puntuaciones
para situar la gravedad del impacto.

2
AENOR es la Asociación Española de Normalización y Certificación, entidad dedicada al desarrollo de la
normalización y la certificación en todos los sectores industriales y de servicios.
 o Análisis de riesgos cuantitativo. En el que en función de las pérdidas
financieras y económicas se causaría el impacto.
- Gestión de los riesgos. Donde se selecciona e implanta salvaguardas o controles para
conocer, prevenir, impedir, reducir, controlar o transferir los riesgos identificados. En
este tipo de metodologías siempre se utilizan los conceptos: activos, amenazas,
vulnerabilidades, riesgos y controles o salvaguardas.

En cuanto a los riesgos, es importante destacar la existencia de tres tipos de riesgos asociados
a sistemas de información:

- Riesgo potencial. Se trata del riesgo asociado a un sistema de manera inherente. Es

decir, exista o no un control de mitigación del mismo (como una salvaguarda o
contramedida).
- Riesgo real. Es el riesgo existente a pesar de la existencia de un control para mitigarlo
o por la inexistencia del mismo. Este es el riesgo que se mide en el análisis o auditoría
del sistema.
- Riesgo residual. Se trata del riesgo que queda tras el ajuste de los controles asociados
al sistema, para la mitigación del riesgo real a un umbral de riesgo aceptado por el
usuario. Se denomina residual porque es asumible por el usuario, es decir, no requiere
de un mayor nivel de control asociado.

En la siguiente ilustración se presenta un resumen de todos estos conceptos tratados, así como
la forma en la que están relacionados, para su mejor entendimiento.

Ilustración 2. Conceptos genéricos implicados en el análisis de riesgos (López, 2012)

De entre las diferentes opciones de metodologías de evaluación de riesgos disponibles, se
utilizará la metodología basada en EDR o ROA (Risk Oriented Assessment), recomendada por
ISACA y creada por Arthur Andersen, por ser la más difundida y permitir su aplicabilidad al
“Sistema de Smartwatch” que hemos definido. Dentro de los tres tipos de EDR existentes,
genérico, simplificado y ampliado o avanzado, se utilizará el EDR genérico como base para
desarrollar la metodología.

En pocas palabras, el proceso de auditoría se basa en una metodología de evaluación de

riesgos que parte de la evaluación inicial del riesgo potencial existente en el sistema de objeto
de análisis. Se analiza el riesgo existente, determinando a través de pruebas y herramientas de
auditoría la existencia de controles y la eficacia y eficiencia de los mismos, identificando los
riesgos existentes por defecto del control o por la implementación parcial del mismo. Es decir,
como consecuencia de la ausencia de controles o por ser un sistema deficiente, los riesgos
sobre el sistema deben ser cuantificados y valorados, de tal forma que permita determinar el
nivel de fiabilidad que brinda el sistema sobre la exactitud, integridad y procesamiento de la
información.

Por tanto, la auditoría basada en la evaluación de riesgos permite cuantificar el riesgo de los
sistemas de información (la medida en que son capaces de asegurar la integridad,
confidencialidad y disponibilidad de la información manejada), midiendo la completitud,
eficacia y eficiencia de los controles puestos en marcha. En términos generales, se analizan los
riesgos del sistema y se cuantifican, y se evalúa y analiza la completitud y el grado de eficacia
para la gestión del riesgo potencial identificado, sirviéndose de un conjunto de pruebas.

Los principales elementos de la metodología basada en EDR se resumen mediante el siguiente

esquema:

Ilustración 3. Principales elementos de una metodología basada en EDR (Fernández and Delgado, 2014)
Por tanto, como primer paso, a continuación se llevará a cabo la identificación de los riesgos
potenciales, en base a las vulnerabilidades y amenazas para dispositivos Smartwatch
identificadas en anteriores apartados.

2.2. Identificación de los riesgos potenciales

Esta fase coincide con la detección de los posibles riesgos en ausencia o deficiencia de
controles relacionados, donde se cuantificará el riesgo potencial o inherente al sistema. El
riesgo potencial es el riesgo asociado a los sistemas de información, con independencia de la
existencia o no de controles.

Para simplificar el presente trabajo, se tendrán inicialmente en cuenta las vulnerabilidades

detectadas en el proyecto OWASP. En base a las vulnerabilidades identificadas por el proyecto
OWASP IoT Top 10, se obtienen a continuación una relación de los riesgos potenciales:

Categoría Impacto Explotabilidad4 Nivel de

3
OWASP IoT Riesgo
Riesgo potencial
Top 10

I1: Interfaz NO APLICA A LOS SMARTWATCH - - -

Web insegura

I2: Posibilidad de acceso indebido al

Autorización/a sistema, tanto de usuarios internos como
ALTO MEDIA ALTO
utenticación externos (puede dar como resultado la
insuficiente pérdida o corrupción de los datos, falta
de control, o denegación de acceso, o
incluso llevar a comprometer el
dispositivo y/o las cuentas de los
usuarios).

I3: Servicios de Posibilidad de acceso indebido al

red inseguros dispositivo a través de la conexión de
MEDIO MEDIA MEDIO
red, tanto de usuarios internos como
externos (puede dar como resultado la
pérdida o corrupción de los datos,

3
Se entiende por Impacto la medición de la/s consecuencias de la materialización de una amenaza.
4
Se entiende por Explotabilidad el grado de dificultad para explotar o utilizar una vulnerabilidad.
 denegación de servicio o facilitar el
ataque a otros dispositivos).

I4: Falta de Posibilidad de acceso a la red del

encriptación a dispositivo al que está conectado, tanto
ALTO MEDIA ALTO
nivel transporte de usuarios externos como internos
(puede resultar en la pérdida de datos y
dependiendo de los datos expuestos,
podría llevar a comprometer
completamente el dispositivo o las
cuentas de usuarios).

I5: Posibilidad de acceso al dispositivo, a la

Preocupacione red del dispositivo al que está conectado,
ALTO MEDIA ALTO
s sobre la a la aplicación móvil o la conexión Cloud,
privacidad incluyendo usuarios externos e internos
(la recopilación de datos personales,
junto con la falta de protección de los
datos, puede llevar al compromiso de los
datos personales del usuario).

I6: Interfaz Posibilidad de acceso a Internet/Cloud

Cloud inseguro (puede llevar a comprometer los datos
ALTO MEDIA ALTO
de usuario y el control sobre el
dispositivo).

I7: Interfaz Posibilidad de acceso a la aplicación

móvil insegura móvil (puede llevar a comprometer los
ALTO MEDIA ALTO
(Smartphone) datos de usuario y el control sobre el
dispositivo).

I8: Posibilidad de acceso al dispositivo

Configurabilida (puede llevar a comprometer el
MEDIO MEDIA MEDIO
d de la dispositivo, de forma intencionada o
seguridad accidental, y/o la pérdida de datos).
insuficiente

I9: Posibilidad de acceso al dispositivo y/o a

Software/Firm la red donde el dispositivo reside;
ALTO BAJA MEDIO
ware inseguro también la posibilidad de tener acceso al
servidor de actualizaciones (puede llevar
a comprometer los datos de usuario,
obtener control del dispositivo y ser
 utilizado para ataques contra otros
dispositivos).

I10: Seguridad Posibilidad de tener acceso físico al

física pobre dispositivo (puede llevar al compromiso
ALTO MEDIA ALTO
del dispositivo mismo y algunos datos
almacenados en éste).

Tabla 1. Riesgos potenciales según categorías OWASP IoT Top 10

Como se puede apreciar en la tabla 1, de las diez categorías de vulnerabilidades identificadas

por el proyecto OWASP seis suponen un riesgo potencial alto, tres un riesgo potencial medio, y
una no es aplicable a los dispositivos de Smartwatch5. Para obtener los valores anteriores de la
columna correspondiente a riesgo potencial se ha tenido en cuenta la siguiente configuración:

IMPACTO EXPLOTABILIDAD RIESGO

Alto Alta Alto

Medio Alta Alto

Bajo Alta Medio

Alto Media Alto

Medio Media Medio

Bajo Media Medio

Alto Baja Bajo

Medio Baja Bajo

Bajo Baja Bajo

Tabla 2. Configuración de riesgo potencial según impacto y explotabilidad de una vulnerabilidad

Como se puede observar en la tabla 2, la explotabilidad tiene un peso importante en la

“ecuación” del riesgo, ya que marca en gran medida el tipo de riesgo subyacente del sistema.
La probabilidad de que un riesgo se materialice está por tanto directamente relacionada con la
dificultad de explotabilidad de la vulnerabilidad: cuanto más sencillo sea explotar una
vulnerabilidad, mayor probabilidad habrá de que se materialice, y al contrario.

5
Los Smartwach no disponen de servidor Web, es decir, no ofrecen una interfaz web para la conexión
externa al dispositivo, como sí es posible observar en otros dispositivos del IoT.
2.3. Identificación de los objetivos de control

El riesgo se puede reducir de dos maneras:

- Reduciendo su posibilidad de ocurrencia, es decir, si se reduce la posibilidad de que se

materialice el riesgo, se está reduciendo el riesgo: un riesgo de alto impacto pero de
probabilidad prácticamente nula es un riesgo bajo.
- Reduciendo el impacto, es decir, reduciendo el impacto que tiene la materialización
del riesgo. La reducción del impacto se consigue con la mitigación, o lo que es lo
mismo, disponer de controles para mitigar el impacto del riesgo.

Cada riesgo asociado al sistema tendrá uno o varios objetivos de control asociados para
mitigar ese riesgo. Por tanto, el objetivo de todo control es la reducción del riesgo, bien
reduciendo su probabilidad de ocurrencia o bien mitigando su impacto. La cuantificación de los
riesgos potenciales, conocidos o no, es la base para establecer detalladamente los objetivos de
control. Así, con los riesgos cuantificados en el apartado anterior, se puede obtener la tabla 3
de muestra de objetivos de control, con los que se pretende reducir su probabilidad de
ocurrencia.

OBJETIVO DE
RIESGO POTENCIAL
CONTROL

I2: Autorización / Posibilidad de acceso indebido al sistema, Prevenir los accesos

autenticación tanto de usuarios internos como externos electrónicos no
insuficiente (puede dar como resultado la pérdida o autorizados a la
corrupción de los datos, falta de control, o información, así como la
denegación de acceso, o incluso llevar a modificación o deterioro de
comprometer el dispositivo y/o las cuentas la misma por partes no
de los usuarios). autorizadas.

Tabla 3. Muestra de la definición de objetivos de control en base a riesgos potenciales

Así, los objetivos de control se pueden resumir en tres grandes tipos:

- Los enfocados a prevenir los accesos físicos no autorizados a la información, así como
la modificación o deterioro de la misma por partes no autorizadas.
- Los enfocados a prevenir los accesos electrónicos no autorizados a la información, así
como la modificación o deterioro de la misma por partes no autorizadas.
 - Los enfocados a prevenir los accesos físicos y electrónicos no autorizados a la
información, así como la modificación o deterioro de la misma por partes no
autorizadas.

Para hacer más sencilla la equiparación de controles con objetivos, según cada uno de los
riesgos identificados, se tratará cada objetivo de control de forma individual.

2.3. Identificación de los controles

Un objetivo de control está cubierto por uno o varios controles. Un control protege frente a
posibles pérdidas y corrige las desviaciones que se presentan en el desarrollo normal de las
actividades. Los controles pueden actuar de forma:

- Preventiva, reduciendo la vulnerabilidad de un activo (lo que lo hace inseguro), o bien

reduciendo la amenaza del activo (el elemento de riesgo).
- Correctiva, mitigando el impacto del riesgo una vez materializado.

En esta metodología los controles utilizados serán del tipo preventivo, ya que partimos de una
relación de vulnerabilidades provenientes del proyecto OWASP IoT Top 10. En los controles de
hardware y software de sistemas destacan los controles de seguridad lógica y de seguridad
física, que se encargan de asegurar las propiedades de la información: confidencialidad,
integridad y disponibilidad. La seguridad lógica está referida a la protección de la información,
procesos y programas, así como la del acceso ordenado y autorizado de los usuarios a dicha
información (Ej. Control de acceso restringido a un dispositivo mediante la asignación de un
identificador de usuario y contraseña personal e intransferible). La seguridad física se centra
en la protección del hardware y los soportes de datos, así como la seguridad de los lugares que
los albergan, ya sean edificios, instalaciones, CPD, etc. (Ej. Controles físicos para asegurar que
el acceso físico a un dispositivo queda restringido a las personas autorizadas).

Precisamente, teniendo en cuenta que los objetivos de control obtenidos anteriormente se

centraban en prevenir accesos físicos y/o electrónicos, este tipo de controles de seguridad
física y lógica serán los generados a continuación en la tabla de muestra 4, en base a los
riesgos potenciales y objetivos de control definido.
 OBJETIVO DE
RIESGO POTENCIAL
CONTROL CONTROL

I2: Autorización Posibilidad de acceso Asegurar que se

/ autenticación indebido al sistema, requieren contraseñas
insuficiente tanto de usuarios fuertes.
internos como
Asegurar un control de
externos (puede dar
acceso granular cuando
como resultado la
sea necesario.
pérdida o corrupción
de los datos, falta de Asegurar que las
control, o denegación credenciales están
de acceso, o incluso protegidas
llevar a comprometer apropiadamente.
el dispositivo y/o las Prevenir los accesos
Implementar
cuentas de los electrónicos no
autenticación de dos
usuarios). autorizados a la
factores cuando sea
información, así
posible.
como la modificación
o deterioro de la Asegurar que los
misma por partes no mecanismos de
autorizadas. recuperación de
contraseñas son seguros.

Asegurar que la re-

autenticación es
requerida para
propiedades sensibles.

Asegurar que existen

opciones disponibles
para configurar los
controles de las
contraseñas.

Tabla 4. Muestra de controles generados a partir de los objetivos de control

También existen controles por motivos legales, donde se suelen tener en cuenta las Leyes de
Propiedad Intelectual (LPI), de Protección de Datos (LOPD), etc. Estos controles deben existir
para poder garantizar el cumplimiento de las leyes y normativa aplicable. Este enfoque podría
ser tratado como línea de trabajo para ampliar la base de conocimiento creada en la presente
metodología, donde se prestara atención a controles de tipo normativo y legal, que como se
mostró en el apartado referido al estado del arte, se constituyen como uno de los retos a
enfrentar en el ámbito del IoT.

2.4. Definición de las pruebas

Una vez identificado el riesgo potencial y definidos los objetivos de control encaminados a la
mitigación del riesgo, es necesario valorar la eficacia y completitud de los controles puestos en
marcha. Para este fin se diseñan las pruebas. Las pruebas permiten obtener evidencias y
verificar la consistencia de los controles existentes, así como medir el riesgo por deficiencia de
éstos (no funcionan como deben) o por ausencia. De esta forma se cuantifica el riesgo real del
sistema.

El riesgo real es el riesgo actual del sistema, aún con la existencia de controles. Este riesgo se
debe normalmente a:

- La ausencia de controles para cubrir alguno de los objetivos de control asociados a un

riesgo potencial.
- La existencia del control pero la ineficacia o implementación parcial del mismo.

En general, se pueden distinguir dos tipos de pruebas: las de cumplimento y las sustantivas.
Las pruebas de cumplimiento son empleadas para probar y verificar el cumplimiento de una
técnica de control o controles. Una prueba de este tipo reúne evidencias para indicar:

- Si un control existe.
- Si funciona de forma efectiva.
- Si logra sus objetivos de forma eficiente.

El otro tipo de pruebas, las pruebas sustantivas, son empleadas cuando las pruebas de
cumplimiento no han satisfecho los objetivos. Se podría decir que las pruebas de cumplimiento
son pruebas de alto nivel mientras que las sustantivas entran en el detalle para verificar de
forma más específica el funcionamiento o no de los controles establecidos, y por tanto, de su
seguridad. Por tanto, las pruebas sustantivas permiten profundizar para comprobar la
fiabilidad y consistencia de los controles existentes e identificar la magnitud y el impacto de los
errores e incidencias, consiguiendo cuantificar con ello el riesgo real y el grado de eficacia de
los controles.

Teniendo en cuenta el enfoque práctico de esta metodología y de cara a una mayor eficacia y
simplicidad para el usuario, se tenderá mayoritariamente a realizar pruebas sustantivas,
siempre que sea posible, que permiten profundizar y comprobar de forma directa la fiabilidad
del sistema. A continuación en la tabla 5, teniendo en cuenta las recomendaciones y análisis
desarrollado dentro del proyecto OWASP IoT Top 10, se presenta una muestra del detalle de
las pruebas sustantivas a realizar para cada uno de los riesgos previamente obtenidos en cada
una de las categorías, que permitirá verificar la existencia o deficiencia de controles.

RIESGO POTENCIAL
PRUEBA

I2: Autorización / Posibilidad de Revisar el tráfico de red para determinar si las

autenticación acceso indebido al credenciales están siendo transmitidas como texto
insuficiente sistema, tanto de en claro.
usuarios internos
como externos
Revisar los requerimientos acerca de controles
(puede dar como
sobre la contraseña, como complejidad de la
resultado la pérdida
contraseña, chequeo del historial de contraseñas,
o corrupción de los
expiración de contraseñas y reseteo de
datos, falta de
contraseñas forzado para nuevos usuarios.
control, o
denegación de Revisar si la re-autenticación es requerida para
acceso, o incluso características sensibles.
llevar a comprometer
el dispositivo y/o las
cuentas de los
usuarios).

Tabla 5. Muestra de pruebas generadas a través de los riesgos y para comprobar los controles

Hasta el momento, se han utilizado las categorías ofrecidas por el proyecto OWASP IoT Top 10
para mayor comodidad a la hora de identificar tanto los objetivos de control, como los
controles y finalmente las pruebas. Llegados a este punto, para utilizar las distintas pruebas
obtenidas y aplicarlas a un “Sistema de Smartwatch”, se agruparán las nueve categorías de
OWASP aplicables a estos dispositivos en las cuatro distintas secciones o categorías que
representan un típico “Sistema de Smartwatch”. El resultado se presenta en la tabla 6.

CATEGORÍAS SISTEMA CATEGORÍAS CLASIFICACIÓN

SMARTWATCH OWASP IoT Top 10

Smartwatch Ámbito Lógico I2: Autorización / autenticación insuficiente

I4: Falta de encriptación a nivel transporte

I5: Preocupaciones sobre la privacidad

I8: Configurabilidad de la seguridad

insuficiente

I9: Software / Firmware inseguro

Ámbito Físico I10: Seguridad física pobre

Comunicaciones I3: Servicios de red inseguros

Teléfono móvil I7: Interfaz móvil insegura (Smartphone)

Cloud I6: Interfaz Cloud inseguro

Tabla 6. Agrupación de categorías OWASP en categorías de un “Sistema de Smartwatch”

Tal como se puede apreciar en la tabla anterior, la categoría de “Smartwatch” se ha

subdividido a su vez en dos categorías: “Ámbito Lógico” y “Ámbito Físico”. Esta separación
tiene como objetivo que la presente metodología pueda así representar de manera más clara y
concisa la seguridad de las distintas partes en la que están divididos estos dispositivos.

2.5. Diseño del cuestionario

En este apartado, y en base a la numeración de las pruebas mostradas en el apartado previo,

se presentan las preguntas del cuestionario a realizar a un usuario a la hora de analizar la
seguridad de su sistema de Smartwatch. Se han mantenido los nombres de las categorías del
proyecto OWASP, dentro de las de sistema de Smartwatch, para que sea más sencillo
identificar posteriormente las preguntas, respuestas y recomendaciones. A continuación, en la
tabla 7, se presenta una muestra del cuestionario.
 Nº Preguntas
Prueba
PRUEBAS I2: Autorización / autenticación insuficiente

1 ¿Son transmitidas las credenciales como texto en claro?

(Para esta prueba debe utilizar una herramienta de escaneo o sniffer de

tráfico, por lo que el usuario deberá tener ser avanzado)

2a ¿Las contraseñas solicitadas por el dispositivo son seguras (complejas,

seguridad fuerte)?

2b ¿El sistema permite chequear el historial de contraseñas?

2c ¿El sistema permite establecer la expiración de contraseñas?

2d ¿El sistema obliga al resteo de contraseñas para un nuevo usuario?

3 ¿Se utiliza reautenticación en el sistema?

Tabla 7. Muestra de preguntas del cuestionario

Por tanto, la tabla 8, que resume las preguntas por cada prueba, se presenta a continuación.

PRUEBA PREGUNTAS PRUEBA PREGUNTAS PRUEBA PREGUNTAS

1 1 11 11 21 21

2 2a+2b+2c+2d 12 12 22 22

3 3 13 13 23 23

4 4 14 14 24 24

5 5 15 15 25 25

6 6 16 16 26 26

7 7a+7b 17 17 27 27

8 8 18 18a+18b 28 28

9 9 19 19a+19b 29 29

10 10 20 20

Tabla 8. Preguntas por prueba a realizar

Como se puede apreciar en la tabla 8, las preguntas número 2, 7, 18 y 19, están compuestas a
su vez de varias preguntas. Este hecho se tendrá en cuenta a la hora de realizar el cálculo del
riesgo real del sistema.

3. Aplicación de la metodología

La aplicación de la metodología conlleva la realización de una serie de pasos, tal como se

describe de forma esquemática en la ilustración 4.

Ilustración 4. Pasos de aplicación de la metodología (Elaboración propia)

En los siguientes apartados se describe este proceso de forma más detallada. Cabe destacar
que esta fase de aplicación sería mucho más sencilla de utilizar, y ese es uno de los objetivos a
corto-medio plazo como futuro trabajo, si tanto las respuestas obtenidas del usuario, como el
cálculo del riesgo, representación y recomendaciones fueran facilitados a través de una
aplicación software. Es decir, en este trabajo se presentan las distintas fases y recursos a
utilizar para la aplicación de la metodología, que puede ser utilizada de forma totalmente
“manual” por un usuario para evaluar su sistema, aunque como se menciona sería mucho más
aceptable por los usuarios si se facilitara a través de una aplicación que realizara las preguntas
al usuario y mediante sus respuestas llevara a cabo internamente los cálculos y ofreciera el
riesgo real del sistema por las categorías definidas, así como las recomendaciones en base a
los riesgos encontrados. Hasta ese momento, se presentan los pasos de la metodología para su
aplicación manual en un sistema de Smartwatch, con la posible complejidad que pudiera
conllevar esta aplicación.

3.1. Revisión de la seguridad

Tal como se apuntaba, para la aplicación de la metodología es necesario seguir una serie de
pasos. El primer paso consiste en responder a las preguntas del cuestionario de seguridad y
rellenar una plantilla de respuestas. Las respuestas a las preguntas del cuestionario deben ser
apuntadas en la plantilla generada para tal fin. De esta manera, el usuario, contestando al
cuestionario, revisará la seguridad de su "Sistema de Smartwatch".

El objetivo de la metodología es que cualquier usuario utilizando el cuestionario sea capaz de

evaluar la seguridad de su “Sistema de Smartwatch”. Sin embargo, en esta primera versión de
la metodología pueden existir preguntas que a un usuario inexperto pueda resultarle difícil
responder. En siguientes versiones se debería ir mejorando y refinando el cuestionario,
adjuntando ayuda y explicaciones para la facilidad de su uso.

A continuación, en la tabla 9, se presenta el modelo de plantilla a utilizar para esta primera

versión de la metodología.

PREGUNTA Sí / NO PREGUNTA Sí / NO PREGUNTA Sí / NO

1 9 19b

2a 10 20

2b 11 21

2c 12 22

2d 13 23

3 14 24

4 15 25

5 16 26
 6 17 27

7a 18a 28

7b 18b 29

8 19a

Tabla 9. Plantilla de respuestas al cuestionario

3.2. Fiabilidad del sistema y recomendaciones de seguridad

3.2.1. Obtención del riesgo real

Una vez completada la plantilla con las respuestas obtenidas sobre el cuestionario, el segundo
paso consiste en la obtención del riesgo real del sistema evaluado. El objetivo de la
metodología es calcular el nivel de riesgo del sistema, por lo que se parte de un nivel ideal de
riesgo 0 (estado inicial). Cada pregunta respondida ser obtendrá un valor de 0 si lo respondido
se corresponde con seguro y 1 si es inseguro. Responder a una pregunta “Sí” no será
equiparado a un “1” o a un “0” siempre, sino que dependiendo de las preguntas y las
respuestas ofrecidas, se entenderá que el sistema es seguro “0” o por el contrario es inseguro
“1”.

Por otro lado, en función del riesgo obtenido en el apartado “2.2. Identificación de los riesgos
potenciales”, se pueden obtener los valores numéricos de riesgo siguientes:

CATEGORIAS OWASP Nivel de Riesgo Valor numérico

(Alto =3,
Medio=2,

Bajo =1)

I2 ALTO 3

I3 MEDIO 2

I4 ALTO 3

I5 ALTO 3

I6 ALTO 3

I7 ALTO 3
 I8 MEDIO 2

I9 MEDIO 2

I10 ALTO 3

Tabla 10. Asignación de valores numéricos al riesgo identificado por sección

Si hacemos el cálculo del riesgo para las nuevas categorías, se obtendría la tabla 11.

CATEGORÍAS SISTEMA CATEGORÍAS VALOR RIESGO

SMARTWATCH CLASIFICACIÓN OWASP
CATEGORÍA
IoT Top 10

Smartwatch Ámbito I2: Autorización / autenticación 3+ (Total)

Lógico insuficiente
3+
I4: Falta de encriptación a nivel
transporte 3+

I5: Preocupaciones sobre la 2+ 3

privacidad 2=
I8: Configurabilidad de la 13 / 5 =
seguridad insuficiente
2,6  3
I9: Software / Firmware inseguro

Ámbito I10: Seguridad física pobre

Físico

Comunicaciones I3: Servicios de red inseguros 2

Teléfono móvil I7: Interfaz móvil insegura 3

(Smartphone)

Cloud I6: Interfaz Cloud inseguro 3

Tabla 11. Tabla de relación de riesgos de las categorías evaluadas por la metodología

Teniendo en cuenta la anterior asignación de valores, a continuación se presenta en la tabla 12

una muestra de la formulación utilizada, en base a las respuestas ofrecidas al cuestionario de
preguntas anteriormente definido, para el cálculo del riesgo en cada una de las categorías.
CATEGORÍA RESPUESTAS RIESGO

SMAR-LOG Xi = Valor de riesgo según respuesta (Riesgo potencial

subcategoría = 3)
(I2) (0 = no hay riesgo,

1 = se detecta riesgo)

(I2: Autorización / autenticación Suma de Riesgos

insuficiente)

1 2a 2b 2c 2d 3 X=X1+X2+X3+X4+X5+X6

Posibles
valores Sí/No Sí/No Sí/No Sí/No Sí/No Sí/No Riesgo TOTAL

X1 X2 X3 X4 X5 X6 (Si X > 0  3

Si X = 0  0)

0/1 0/1 0/1 0/1 0/1 0/1 X= 0/ 3

Tabla 12. Tabla de muestra del cálculo del riesgo en la categoría SMARTWATCH-LOGICA (I2)

Tal como se comentaba anteriormente, la complejidad de calcular el riesgo se podría diluir

introduciendo estos cálculos en una aplicación informática, en base a las respuestas, que
ofrecería de forma más sencilla y rápida para el usuario el riesgo real del sistema.

Una vez obtenidos los riesgos de cada sección, el tercer paso de la metodología consistiría en
representar el riesgo real mediante un diagrama de radar, tal como el mostrado en la
ilustración 5.
 Representación del RIESGO del Sistema Smartwatch
Riesgo BAJO Riesgo MEDIO Riesgo ALTO Sin Riesgo

SMARTWATCH-LOGICO
3

1
CLOUD SMARTWATCH-FISICO
0

-1

TELEFONO MÓVIL COMUNICACIONES

Ilustración 5. Representación gráfica del Riesgo de un Sistema

3.2.2. Recomendaciones para mejorar la seguridad

En base a los resultados obtenidos, es posible obtener una serie de recomendaciones para
mejorar la seguridad, utilizando para ello los controles identificados en el apartado “2.3.
Identificación de los controles”. Este será el cuarto paso y final de la metodología.

CATEGORÍAS CATEGORÍAS Recomendaciones

OWASP IoT Top
SISTEMA (Basadas en los Controles)
10
SMARTWATCH

SMARTWATCH – I2: Autorización /  Asegurar que se requieren contraseñas

LOGICO autenticación fuertes.
insuficiente  Asegurar un control de acceso granular
cuando sea necesario.
 Asegurar que las credenciales están
protegidas apropiadamente.
 Implementar autenticación de dos factores
 cuando sea posible.
 Asegurar que los mecanismos de
recuperación de contraseñas son seguros.
 Asegurar que la re-autenticación es
requerida para propiedades sensibles.
 Asegurar que existen opciones disponibles
para configurar los controles de las
contraseñas.
Tabla 13. Muestra de recomendaciones de seguridad basadas en controles

La tabla 13 presenta una muestra de las recomendaciones posibles en base a controles. Cabe
destacar que dentro de la categoría “Smartwatch – Lógico” se pueden extraer
recomendaciones para cada una de las subcategorías de las que está compuesta esta categoría
general de la metodología.

3.2.3. Resumen de pasos a realizar

Por tanto, la aplicación de la metodología consiste en la ejecución de cuatro pasos bien

diferenciados, utilizándose en cada uno de ellos las herramientas mostradas en apartados
anteriores. La tabla 14 resume los pasos y recursos necesarios para su aplicación.

PASO Explicación de uso y finalidad Recursos para su aplicación

(Descripción de su utilidad)

1 Responder a las respuestas del  Cuestionario: obtención de

cuestionario de seguridad del preguntas a responder.
sistema, utilizando para ello la  Plantilla de respuestas: para
plantilla de respuestas. anotar las respuestas del
cuestionario.
2 Obtención del riesgo real del  Tablas de cálculo: para la
sistema, utilizando para ello la obtención del riesgo del sistema, en
formulación ofrecida por la cada una de sus diferentes
metodología. categorías.

3 Representar el riesgo real del  Diagrama de radar: para la

 sistema, para mejor representación del riesgo real en
entendimiento de las partes cada una de las cuatro categorías
seguras e inseguras del sistema evaluadas: Smartwatch (ámbitos
evaluado. lógico y físico), Comunicaciones,
Teléfono Móvil y Cloud).
4 Obtención de  Tabla de recomendaciones:
recomendaciones, en base a los utilizando para ello los controles
controles identificados en la definidos en la metodología, por
metodología, para mejorar la cada categoría y subcategoría.
seguridad de las partes con
déficit de seguridad.

Tabla 14. Resumen de pasos para aplicación de la metodología

El cuadro anterior sirve como guía de aplicación para la evaluación de la metodología que es
aplicada en dos casos reales.

4. Evaluación de la metodología

En este apartado se evalúa el funcionamiento de la metodología mediante el análisis de

seguridad de dos “sistemas de Smartwatch” distintos.

- Un primer sistema que se corresponde con un Smartwatch LG G Watch R W110, con

sistema operativo Android Wear.
- El segundo sistema que se corresponde con un Smartwatch Apple Watch, con sistema
operativo iOS.

En cada caso de evaluación se detallan tanto las especificaciones del sistema a evaluar, en el
momento de su evaluación, como los pasos llevados a cabo y resultados.

4.1. Primer caso de evaluación

El primer sistema evaluado es el LG G Watch R W110. Este Smartwatch dispone de las

siguientes especificaciones y configuración en el momento de su evaluación6:

- Sistema Operativo: Android Wear 1.0 (compatible con Android 4.3+)

- Comunicaciones: Bluetooth versión 4.0.

6
Especificaciones técnicas obtenidas de LG.
 - Puertos y conectores: USB (Pogo Pin, adaptador de carga Micro USB.
- Sensores: 9 ejes (Acelerómetro/Giroscopio/Brújula), barómetro y Pulsómetro PPG.

El Smartwatch prestado para su evaluación dispone de los siguientes elementos funcionales de

un “sistema de Smartwatch”:

- Smartwatch LG G Watch R W110.

- Comunicaciones (Bluetooth).
- Teléfono móvil (Samsung con sistema operativo Android).

Como se puede apreciar, este Smartwatch en el momento de su evaluación no estaba

configurado para utilizar un sistema de almacenamiento Cloud. Por tanto, esta categoría de la
metodología no será evaluada, apareciendo un valor de 0. A continuación lo que se muestra es
simplemente los resultados de la aplicación de la metodología, es decir, la representación
gráfica del riesgo y la tabla de recomendaciones:

- Representación gráfica del riesgo real (Diagrama radar).

Representación RIESGO Sistema LG G Watch R W110

Riesgo del Sistema Evaluado

SMARTWATCH-LOGICO
3
3
2

1
CLOUD 3
SMARTWATCH-FISICO
0
0
-1

TELEFONO MÓVIL
2 COMUNICACIONES
3

Ilustración 6. Representación del riesgo real del LG G Watch R W110

 Representación RIESGO Sistema LG G Watch R W110
(Subsistemas SMARTWATCH-LOGICO)
Riesgo del Sistema Evaluado

Autorización /
autenticación insuficiente
3
3
2

1
Software / Firmware Falta de encriptación a
inseguro 2 0 nivel transporte
0
-1

Configurabilidad de la 2 Preocupaciones sobre la

seguridad insuficiente privacidad
3

Ilustración 7. Representación del riesgo real del ÁMBITO LÓGICO del LG G Watch R W110

- Recomendaciones ofrecidas en función del riesgo real obtenido.

CATEGORÍA ¿Recomendaciones?

SMARTWATCH-LOGICO I2: Autorización / SI (ver Anexo C)

autenticación insuficiente

I4: Falta de encriptación a NO

nivel transporte

I5: Preocupaciones sobre la SI (ver Anexo C)

privacidad

I8: Configurabilidad de la SI (ver Anexo C)

seguridad insuficiente

I9: Software / Firmware SI (ver Anexo C)

inseguro

SMARTWATCH-FISICO SI (ver Anexo C)

COMUNICACIONES SI (ver Anexo C)

TELEFONO MOVIL SI (ver Anexo C)

CLOUD NO

Tabla 15. Recomendaciones a revisar según riesgo real del LG G Watch R W110

4.2. Segundo caso de evaluación

El segundo sistema evaluado es el Apple Watch, modelo Sport. Este Smartwatch dispone de
las siguientes especificaciones y configuración en el momento de su evaluación:

- Sistema Operativo: Watch OS.

- Comunicaciones: Bluetooth versión 4.0. y WIFI 802.11 b/g/n 2.4 GHz.
- Puertos y conectores: conector Lightning (para carga y transmisión de datos).
- Sensores: Sensor de luz ambiental, de frecuencia cardiaca, acelerómetro y giroscopio.

El Smartwatch prestado para su evaluación dispone de los siguientes elementos funcionales de

un “sistema de Smartwatch”:

- Smartwatch (Apple Watch)

- Comunicaciones (Wi-fi y Bluetooth)
- Teléfono móvil (iPhone 6).
- Cloud (iCloud)

A continuación se muestran los resultados de la aplicación de la metodología, es decir, la

representación gráfica del riesgo y la tabla de recomendaciones a revisar:

- Representación gráfica del riesgo real.

 Representación RIESGO Sistema Apple Watch
Riesgo del Sistema Evaluado

SMARTWATCH-LOGICO
3
3
2

1
3
CLOUD SMARTWATCH-FISICO
0
0
-1

TELEFONO MÓVIL
2 COMUNICACIONES
3

Ilustración 8. Representación del riesgo real del Apple Watch

Representación RIESGO Sistema Apple Watch

(Subsistemas SMARTWATCH-LOGICO)
Riesgo del Sistema Evaluado

Autorización /
autenticación insuficiente
3
3
2

1
Software / Firmware Falta de encriptación a
inseguro 0 nivel transporte
0 0
-1

Configurabilidad de la 2 Preocupaciones sobre la

seguridad insuficiente privacidad

Ilustración 9. Representación del riesgo real del ÁMBITO LÓGICO del Apple Watch
 - Cuarto paso: Consiste en las recomendaciones en base al riesgo real obtenido por el
sistema. El usuario debería revisar las recomendaciones apuntadas en la siguiente
tabla 16:

CATEGORÍA ¿Recomendaciones?

SMARTWATCH-LOGICO I2: Autorización / SI (ver tabla 13)

autenticación insuficiente

I4: Falta de encriptación a NO

nivel transporte

I5: Preocupaciones sobre la NO

privacidad

I8: Configurabilidad de la SI
seguridad insuficiente

I9: Software / Firmware NO

inseguro

SMARTWATCH-FISICO NO

COMUNICACIONES SI

TELEFONO MOVIL SI

CLOUD SI

Tabla 16. Recomendaciones a revisar según riesgo real del Apple Watch

4.3. Comparativa de resultados

CATEGORÍA APPLE WATCH LG G WATCH R W110

SMARTWATCH-LOGICO 3 3

SMARTWATCH-FISICO 0 3

COMUNICACIONES 2 2

TELEFONO MOVIL 3 3
CLOUD 3 0

Tabla 17. Comparativa de Riesgo Real de categorías generales: Apple vs LG

Representación RIESGO Sistemas evaluados

Apple Watch LG G Watch R W110
3
SMARTWATCH-LOGICO
3
3
2

1 3
3
CLOUD SMARTWATCH-FISICO
0
0 0
-1

TELEFONO MÓVIL
22 COMUNICACIONES
33

Ilustración 10. Comparativa Riesgo Sistemas Apple y LG

Como se puede apreciar en la tabla 17, el Apple Watch destaca por ser más seguro en el
ámbito físico. Así mismo, para realizar una comparación más directa, se puede atender a los
puntos inseguros detectados en la fase de cálculo de riesgo de cada smartwatch, tal como se
muestra a continuación en la tabla 18.

CATEGORÍA APPLE WATCH LG G WATCH R W110

SMARTWATCH-LOGICO Puntos RIESGO Puntos RIESGO

Inseguros Inseguros
TOTAL TOTAL
Detectados Detectados

Autorización / 2 3 3 3
autenticación insuficiente
Falta de encriptación a 0 0 0 0
nivel transporte

Preocupaciones sobre la 0 0 0 3
privacidad

Configurabilidad de la 3 2 1 2
seguridad insuficiente

Software / Firmware 0 3 4 2
inseguro

Tabla 18. Comparativa Riesgo Real subcategorías Smartwatch-LOGICO: Apple vs LG

En la tabla 18 cabe resaltar cómo en las subcategoría “Configurabilidad insuficiente” el Apple

Watch se muestra más inseguro, así como en la de “Software/Firmware inseguro” se presenta
menos seguro el LG frente al Apple Watch.

Representación RIESGO Sistemas evaluados

(Subsistemas SMARTWATCH-LOGICO)
Apple Watch LG G Watch R W110

Autorización /
3
autenticación insuficiente
3
3
2

1
Software / Firmware Falta de encriptación a
inseguro 2 0 nivel transporte
0 0
-1

Configurabilidad de la 2 Preocupaciones sobre la

seguridad insuficiente privacidad
3

Ilustración 11. Comparativa Riesgo Subsistemas Smartwatch-LOGICO en Apple y LG

5. Conclusiones

El presente trabajo tenía como objetivo principal mostrar un posible camino para la mejora de
la seguridad de los Smartwatch, dispositivos pertenecientes al ámbito del Internet de las
Cosas, mediante la creación de un proceso sistematizado de evaluación de los elementos que
típicamente componen estos sistemas, basándose en un análisis de riesgos, y con la
particularidad de que pudiese ser llevado a cabo por los propios usuarios de estos dispositivos.

Así, para llegar al objetivo marcado, se ha implementado una metodología para el análisis de la
seguridad de dispositivos Smartwatch que, como se ha podido mostrar en el apartado de
evaluación, puede ser utilizada directamente por sus usuarios para evaluar este tipo de
sistemas, con unos resultados que representan los riesgos reales del sistema analizado y
recomendaciones ad-hoc en base a los riesgos identificados. Para llegar a esta solución,
primeramente se ha analizado un "Sistema de Smartwatch" típico que ha permitido obtener
los riesgos, controles y pruebas que el usuario podría utilizar para evaluar de forma “manual”
su sistema. Aunque si bien es cierto que un usuario podría aplicar esta metodología de forma
totalmente manual, tal como se apuntaba con anterioridad, esta aplicación manual no está
exenta de cierta complejidad, sobre todo en la parte de cálculo del riesgo, algo que podría
solucionarse fácilmente con su inclusión en una aplicación software que recibiera las
respuestas a las preguntas planteadas por el cuestionario, realizara los cálculos a nivel interno
y devolviera los resultados al usuario, sobre el riesgo y las recomendaciones para mejorar su
seguridad.

Es importante señalar que la identificación de riesgos potenciales, objetivos de control,

controles y pruebas se desarrollan una única vez en este documento, formando parte de la
fase que se ha denominado de conocimiento. El resultado obtenido de esta evaluación de
riesgos, o fase de conocimiento, es lo que deben/pueden utilizar los usuarios para evaluar su
"Sistema de Smartwatch", en la que se ha denominado como fase de aplicación. De hecho, con
los dos casos evaluados, el Apple Watch y el LG G Watch R W110, se ha demostrado la
viabilidad en casos reales de esta metodología, que no solo es capaz de analizar la seguridad
de estos sistemas, sino también recomendar, utilizando una serie de controles previamente
definidos, las medidas a llevar a cabo para mejorar la seguridad de los sistemas.

Finalmente, gracias a los resultados obtenidos y a la separación de la metodología en dos fases

bien diferenciadas, una de conocimiento y otra de aplicación, se ha constatado las
oportunidades que brinda esta metodología, en cuanto a su flexibilidad para poder ser
aplicada a otros dispositivos del Internet de las Cosas, mediante una serie de cambios mínimos
para su adaptación a esos nuevos dispositivos.

6. Trabajo futuro

Tal como se apuntaba desde distintas partes de la metodología, en estudios y trabajos futuros
se podría diseñar una aplicación software, posiblemente para su instalación en un Smartphone
o en el propio Smartwatch, que permitiera a un usuario evaluar de forma “semi-manual” la
seguridad de su "sistema de Smartwatch". Otro avance sobre este planteamiento sería que la
aplicación consiguiera analizar de forma totalmente automática el "Sistema de Smartwacth",
mostrando la fiabilidad del sistema y recomendaciones para mejorar su seguridad. Para
analizar de forma automática el sistema, esta aplicación debería tener acceso a las distintas
partes del sistema y/o utilizar herramientas para llevar a cabo los análisis sin la interacción del
usuario. También, en cuanto a las recomendaciones de seguridad se podría pensar en la
opción de aplicar estas mejoras de forma automática, si se tuviera acceso a la configuración de
seguridad del sistema desde esta nueva aplicación.

Además de los controles evaluados, centrados en seguridad lógica, física y electrónica,

también existen controles enfocados a motivos legales, donde se suelen tener en cuenta Leyes
de Propiedad Intelectual (LPI), Protección de Datos (LOPD), etc. Estos controles deben existir
para poder garantizar el cumplimiento de las leyes y normativa aplicable, teniendo la
posibilidad de ser tratado como línea de trabajo para ampliar la base de conocimiento creada
en la presente metodología, donde se prestara por tanto también atención a controles de tipo
normativo y legal, que como se mostró en el apartado referido al estado del arte, se
constituyen como uno de los retos a enfrentar en el ámbito del IoT.

Siguiendo con la mejora de la base de conocimiento, un fabricante o proveedor podría incluir

una sección concreta del producto que permitiera la evaluación de riesgos específicos de ese
sistema o dispositivo, lo que seguramente conllevaría en un incremento importante de su
seguridad, por mayor adaptación a la idiosincrasia del producto. Ejemplos posibles: sección del
sistema operativo (Android Wear, iOS, Watch OS...), marca del Smartwatch (Apple Watch,
Sansumg,...), etc. Terminando con mejoras a aplicar a la base de conocimiento, también se
podría actualizar más fácilmente esta base de la metodología con los propios avances que se
fueran llevando en este campo o incluso por los comentarios obtenidos de los propios
usuarios, si se habilitara algún sistema de “inteligencia colectiva” para esta mejora.

Finalmente, desde un enfoque mucho más académico y formal, se podría utilizar Watson de
IBM7 para la generación de las preguntas al usuario en base a un “core” de conocimiento,

7
Watson, desarrollado por la corporación IBM, es un sistema informático de inteligencia artificial capaz
de responder a preguntas formuladas en lenguaje natural.
según se fuera desarrollando con su utilización. El éxito mediático del sistema Watson al
participar en el concurso televisivo “Jeopardy” en EEUU y obtener mejores resultados que sus
oponentes humanos supuso un hito al ser capaz de responder a preguntas en lenguaje natural.
En ese concurso Watson no estaba conectado a Internet, sino que accedía a datos
almacenados en forma de conocimiento no estructurado. Utilizando tecnologías de “machine
learning”8, análisis estadístico y procesamiento de lenguaje natural para encontrar las claves
de cada pregunta, Watson comparaba posibles respuestas, estimaba la exactitud de las
mismas y respondía en menos de 3 segundos. Ese éxito permitió explorar aceleradamente su
uso en otros dominios profesionales como el diagnóstico médico (cáncer), finanzas
(inversiones empresariales en entornos de incertidumbre), o toma de decisiones en sistemas
complejos (como la optimización de exploraciones petrolíferas). Se aprovecha, asimismo, del
incremento paulatino de la capacidad de cálculo, acceso y almacenamiento de los sistemas
informáticos actuales, algo que podría ser muy interesante estudiar para la mejora de la
seguridad de los sistemas de IoT, tal como se ha presentado a lo largo de este estudio con la
metodología implementada.

Referencias

Ashton, K. (2009). That ‘Internet of Things’ Thing. RFID Journal. Recuperado de:
http://www.itrco.jp/libraries/RFIDjournal-That%20Internet%20of%20Things%20Thing.pdf

Fernández C. M. and Delgado B. (2014). Apuntes asignatura Auditoría Informática. Máster en

Seguridad Informática. Universidad Internacional de la Rioja (UNIR).

Beecham Research (2015). Wearable Technology Application Chart. Recuperado de:

http://www.beechamresearch.com/article.aspx?id=20

Bermejo, J. (2015). Apuntes asignatura Seguridad en el Software. Máster en Seguridad

Informática. Universidad Internacional de la Rioja (UNIR).

8
Maching learning o aprendizaje de máquinas es una rama de la inteligencia artificial cuyo objetivo se
centran en el desarrollo de técnicas que permitan a las computadoras aprender.
Bouhnick, G. (2015). The Fragmented World of Wearable Operating Systems. Recuperado de:
http://es.slideshare.net/MobileSpoon/wearables-the-comprehensive-list-of-smartwatch-
operating-systems

Chaudhuri, P. (2015). IoT As An Evolving Paradigm. Recuperado de:

https://www.linkedin.com/pulse/iot-evolving-paradigm-whitepaper-pras-chaudhuri

Cisco (2014). Cisco anuncia los ganadores del “Gran Desafío de Internet de las Cosas”.
Recuperado de: http://globalnewsroom.cisco.com/es/la/press-releases/cisco-anuncia-los-
ganadores-del-gran-desafio-de-i-1152073

Evans, D. Cisco IBSG. (2011). The Internet of Things. How the Next Evolution of the Internet Is
Changing Everything. Recuperado de:
https://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

Credit Suisse (2014). The Evolution of Wearables. Recuperado de: https://doc.research-and-

analytics.csfb.com/docView?language=ENG&source=ulg&format=PDF&document_id=8053495
60&serialid=g9lEUAU7uOFgKHIGT9ZG65xrGGoRvXYXhI1Ez/GEECU=

Credit Suisse (2013). The Future of Wearable Techonology. Recuperado de:

https://www.credit-suisse.com/ch/en/news-and-expertise/news/economy/sectors-and-
companies.article.html/article/pwp/news-and-expertise/2013/07/en/the-future-of-wearable-
technology.html

Cyr B., Horn W., Miao D. and Specter M. (2014). Security Analysis of Wearable Fitness Devices
(Fitbit). Recuperado de: https://courses.csail.mit.edu/6.857/2014/files/17-cyrbritt-webbhorn-
specter-dmiao-hacking-fitbit.pdf

DarkReading (2014). Bitdefender Research Exposes Security Risk of Android Wearable Devices.
Recuperado de: http://www.darkreading.com/partner-perspectives/bitdefender/bitdefender-
research-exposes-security-risks-of-android-wearable-devices-/a/d-id/1318005

ELDERECHO.COM (2014). Para el futuro, tendremos que incluir la seguridad como un requisito
ineludible de todos los avances tecnológicos. Recuperado de:
http://tecnologia.elderecho.com/tecnologia/ciberseguridad/incluir-seguridad-requisito-
ineludible-tecnologicos_14_751195003.html

ELPAIS (2015). ¿Qué hacen con nuestros datos en internet? Recuperado de:
http://tecnologia.elpais.com/tecnologia/2015/06/12/actualidad/1434103095_932305.html
Olivier Ezratty (2014). Rapport CES 2014. Recuperado de:
http://www.oezratty.net/wordpress/2014/rapport-ces-2014/

European Comission (2014). Opinion 8/2014 on the on Recent Developments on the Internet
of Things. Working Paper. Recuperado de: http://ec.europa.eu/justice/data-protection/article-
29/documentation/opinion-recommendation/files/2014/wp223_en.pdf

European Comission (2012). IoT Privacy, Data Protection, Information Security. Recuperado de:
http://ec.europa.eu/information_society/newsroom/cf/document.cfm?action=display&doc_id
=1753

EY (2015). Cybersecurity and the Internet of Things. Recuperado de:

http://www.ey.com/Publication/vwLUAssets/EY-cybersecurity-and-the-internet-of-
things/$FILE/EY-cybersecurity-and-the-internet-of-things.pdf

Floerkemeier, C., Langheinrich, M., Fleisch, E., Mattern, F. and Sarma, S. (2008). The Internet of
Things. First International Conference:IOT (26-28). March 2008. Zurich, Switzerland.

Flu-Project (2014). Modelado de amenazas. Recuperado de: http://www.flu-

project.com/2014/06/el-modelado-de-amenazas-parte-i.html

Foster, R. N. (1988). Innovation: The attacker's advantage. Summit Books.

Gartner (2014a). Gartner’s 2014 Hype Cycle for Emerging Technologies Maps the Journey to
Digital Business. Recuperado de: http://www.gartner.com/newsroom/id/2819918

Gartner (2014b). Gartner Says Over 20 Percent of Enterprises Will Have Digital Security Services
Devoted to Protecting Business Initiatives Using the Internet of Things by End of 2017.
Recuperado de: http://www.gartner.com/newsroom/id/2844317

Gubbi J., Buyya R., Marusic S., y Palaniswami M. (2013). Internet of Things (IoT): A vision,
architectural elements, and future directions. Recuperado de: http://ac.els-
cdn.com/S0167739X13000241/1-s2.0-S0167739X13000241-main.pdf?_tid=a50a746a-00b7-
11e5-9a87-00000aacb35e&acdnat=1432322625_9e51ca9551efa518690e8fd76dfc3b3c

HP (2015). Securing the Internet of Things: Mapping Attack Surface Areas Using the OWASP IoT
Top 10. RSAConference2015. Abril 2015. Recuperado de:
https://drive.google.com/file/d/0B52IUvO0LP6OdW1HMjRpM3VVUVE/view?pli=1

HP (2014). The home security Internet of Things paradox. Recuperado de:

http://h17009.www1.hp.com/pub/msc/4BE0693D-03B6-4491-A404-1449FD82A1F3.pdf
ICMA (2014). Tackling the Wearable Device Security Challenge. Recuperado de:
http://icma.org/en/Article/104996/Tackling_the_Wearable_Device_Security_Challenge

IDC (2015). Wearable Market Remained Strong in the First Quarter Despite the Pending Debut
of the Apple Watch. Recuperado de:
http://www.idc.com/getdoc.jsp?containerId=prUS25658315

IDC (2014). Worldwide and Regional Internet of Things (IoT) 2014–2020 Forecast: A Virtuous
Circle of Proven Value and Demand. Recuperado de:
http://www.idc.com/getdoc.jsp?containerId=248451

InfoWorld (2013). Thanks, NSA, you're killing the cloud. Recuperado de:
http://www.infoworld.com/article/2611421/cloud-computing/thanks--nsa--you-re-killing-the-
cloud.html

InfoWorld (2014). Security jobs are hot, thanks to the Internet of things. Recuperado de:
http://www.infoworld.com/article/2837501/it-jobs/security-jobs-are-hot-thanks-to-the-
internet-of-things.html

INTECO. (2011). Cuaderno de notas del Observatorio ¿Qué son las vulnerabilidades del
software? Recuperado de: http://www.jesusamieiro.com/wp-
content/uploads/2011/08/Que_son_las_vulnerabilidades_del_-software.pdf

Intel (2014). Transform Business with Intel IoT Gateways. Recuperado de:
http://www.intel.com/content/www/us/en/internet-of-things/gateway-solutions.html

IOT-A (2013a). Internet of Things Architecture. WP3-Guidelines for design. Deliverable D3.4.
Recuperado de: http://www.meet-iot.eu/deliverables-IOTA/D3_4.pdf

IOT-A (2013b). Final Architectural Reference Model for the IoT. Deliverable D1.5. Recuperado
de: http://www.iot-a.eu/public/public-documents/d1.5/at_download/file

ISACA (2014). Wearable Technology and Its Associated Security Risk. Recuperado de:
http://www.isaca.org/About-ISACA/-ISACA-Newsletter/Documents/2014/at-ISACA-Volume-
6_nlt_Eng_0314.pdf

ITSecurityGuru (2015a). Wearable Technology – Vulnerabilities are too often ignored.

Recuperado de: http://www.itsecurityguru.org/2015/03/09/wearable-technology-
vulnerabilities-are-too-often-ignored/
ITSecurityGuru (2015b). Fitness wearables are exposing personal information. Recuperado de:
http://www.itsecurityguru.org/2014/08/13/fitness-wearables-exposing-personal-information/

ITSecurityGuru (2014). Wearable technology creates new privacy issues for employers.
Recuperado de: http://www.itsecurityguru.org/2014/06/25/wearable-technology-creates-
new-privacy-issues-employers/

ITU (2005). The Internet of Things. ITU Internet Reports 2005. Recuperado de:
https://www.itu.int/wsis/tunis/newsroom/stats/The-Internet-of-Things-2005.pdf

LG (2014). Modelo LG G Watch R W110. Recuperado de: http://www.lg.com/es/wearables/lg-

LGW110-g-watch-r

López, D. (2012). Análisis de riesgos dinámicos en sistemas de información. Proyecto Fin de

Máster curso 2011-2012. Universidad Complutense de Madrid.

Mattern, F. and Floerkemeier, C. (2010). From the Internet of Computers to the Internet of
Things. Recuperado de: http://www.vs.inf.ethz.ch/publ/papers/Internet-of-things.pdf

Migicovsky A., Durumeric Z., Ringenberg J. and Halderman J.A. (2014). Outsmarting Proctors
with Smartwatches: A Case Study on Wearable Computing Security. Recuperado de:
https://jhalderm.com/pub/papers/smartwatch13.pdf

NDTV GADGETS (2015). Samsung Tops Smartwatch Sales in 2014 With 1.2 Million Units.
Recuperado de: http://gadgets.ndtv.com/wearables/news/samsung-tops-smartwatch-sales-in-
2014-with-12-million-units-statista-669852

Omicrono (2015). La seguridad de Apple Watch es así de siemple. Recuperado e:

http://www.omicrono.com/2015/05/la-seguridad-del-apple-watch-es-asi-de-simple/

OWASP (2014). The OWASP Internet of Things Top 10. Recuperado de:
https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=OWAS
P_Internet_of_Things_Top_10_for_2014

PWC. (2014). ISSA: OCtober 2014. The Internet of Things (IoT). Recuperado de:
http://www.issala.org/wp-content/uploads/ISSA_Internet-of-Things_PWC_v2.0.pdf
 SecurityIntelligente (2015). Management and Security Implications of the Smartwatch at Work.
Recuperado de: http://securityintelligence.com/management-and-security-implications-of-
the-smartwatch-at-work/#.VSa3ofDEo3g

SiliconANGLE (2013). 4 Security challenges of Wearable Computing. Recuperado de:

http://siliconangle.com/blog/2013/05/30/4-security-challenges-for-fitbit-google-glass-other-
wearable-devices/

SwatSolutions (2015). Data Security in a Wearables World. Recuperado de:

http://www.swatsolutions.com/data-security-in-a-wearables-world/

Symantec (2014). How safe is your quantified self? Recuperado de:

http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/
how-safe-is-your-quantified-self.pdf

TechXplore (2014). Security firm shows vulnerability of smarwatches to hacker attacks.

Recuperado de: http://techxplore.com/news/2014-12-firm-vulnerability-smartwatches-
hacker.html

Tejero A. and Martínez, I. (2014). Seguridad en el Internet de las Cosas. Madrid: Centro de
Apoyo a la Innovación Tecnológica (CAIT), Universidad Politécnica de Madrid.

TRENDMicro (2014). Smartwatches create new cybersecurity issues. Recuperado de:

http://blog.trendmicro.com/smartwatches-create-new-cybersecurity-issues/

Trends2read (2015). Los diferentes usos de la tecnología “wearable”. Recuperado de:

http://www.trends2read.com/es/los-diferentes-usos-de-la-tecnologia-wearable/

Vermesan O., Friess P., Guillemin P., Gusmeroli S., Sundmaeker H., Bassi A., Soler I., Mazura
M., Harrison M., Eisenhauer M. And Doody P. (2011). Internet of Things Strategic Research
Roadmap. Recuperado de: http://www.internet-of-things-
research.eu/pdf/IoT_Cluster_Strategic_Research_Agenda_2011.pdf

Weiser, M. (1991). The Computer for the 21st Century. Scientific American 265(9), 66–75

View publication stats