Protocolo de seguridad para contenidos de aprendizaje ...

Protocolo de seguridad para contenidos de aprendizaje interactivo de realidad aumentada

Cristian David Jiménez Ramírez, [email protected]

Hervin Duvan Posso Peña, [email protected]

Trabajo de Grado presentado para optar al título de Ingeniero de Sistemas

Asesor: Carlos Arturo Castro Castro, Magíster (MSc) en Geoinformática.

Universidad de San Buenaventura Colombia

Facultad de Ingenierías

Ingeniería de Sistemas

Medellín, Colombia

2020

Citar/How to cite [1]

Referencia/Reference

Estilo/Style:

IEEE (2014)

[1] C. D Jiménez Ramírez y H. D. Posso Peña, “Protocolo de seguridad para

contenidos de aprendizaje interactivo de realidad aumentada.”, Trabajo de grado

Ingeniería de Sistemas, Universidad de San Buenaventura Medellín, Facultad de

Ingenierías, 2020.

Grupo de Investigación: Modelamiento y Simulación Computacional

Línea de investigación en Ingeniería del Software

Bibliotecas Universidad de San Buenaventura

Biblioteca Fray Alberto Montealegre OFM - Bogotá.

Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

Departamento de Biblioteca - Cali.

Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13

TABLA DE CONTENIDO

RESUMEN ....................................................................................................................................... 1

ABSTRACT ..................................................................................................................................... 2

I. INTRODUCCIÓN ........................................................................................................................ 3

II. PLANTEAMIENTO DEL PROBLEMA .................................................................................... 4

A. Antecedentes ........................................................................................................................... 6

III. JUSTIFICACIÓN ....................................................................................................................... 9

IV. OBJETIVOS ............................................................................................................................ 10

A. Objetivo general .................................................................................................................... 10

B. Objetivos específicos ............................................................................................................. 10

V. HIPÓTESIS ............................................................................................................................... 11

VI. MARCO TEÓRICO ................................................................................................................. 12

A. Ingeniería del software ....................................................................................................... 12

1) Ciclo de vida del software ............................................................................................... 13

a) Planeación ................................................................................................................ 13

b) Análisis ..................................................................................................................... 13

c) Diseño ....................................................................................................................... 14

d) Implementación ........................................................................................................ 14

e) Pruebas ..................................................................................................................... 15

B. Pruebas del software ........................................................................................................... 15

1) Metodologías de testing ................................................................................................... 15

C. Pentesting ........................................................................................................................... 17

1) Fases del Pentesting ......................................................................................................... 17

a) Recopilación de información ................................................................................... 17

b) Escaneo ..................................................................................................................... 17

c) Análisis de vulnerabilidades ..................................................................................... 17

d) Explotación ............................................................................................................... 18

e) Reportes .................................................................................................................... 18

D. Seguridad Informática ........................................................................................................ 18

1) Confidencialidad .............................................................................................................. 18

2) Integridad ......................................................................................................................... 19

3) Disponibilidad ................................................................................................................. 19

4) Tipos de vulnerabilidades ................................................................................................ 19

5) Tipos de ataques .............................................................................................................. 20

a) Ataques Activos ....................................................................................................... 20

b) Ataques Pasivos ........................................................................................................ 20

E. Realidad Aumentada ............................................................................................................... 21

1) Arquitectura de un sistema de realidad aumentada ......................................................... 21

2) Clasificación según el hardware que lo soporta .............................................................. 22

3) Clasificación según la tecnología utilizada ..................................................................... 22

VII. METODOLOGÍA ................................................................................................................... 23

A. Revisión de la literatura sobre el desarrollo de contenidos de realidad aumentada ........... 24

B. Identificación de las prácticas de desarrollo de los contenidos de realidad aumentada ..... 24

C. Implementación de pruebas ................................................................................................ 25

D. Identificación y corrección de fallas .................................................................................. 26

E. Diseño del protocolo de pruebas ........................................................................................ 27

F. Documentación de la investigación .................................................................................... 27

VIII. RESULTADOS ..................................................................................................................... 28

A. Protocolo ............................................................................................................................ 28

1) Fase 1 Recolección y Análisis ......................................................................................... 28

a) Definición general .................................................................................................... 29

b) Arquitectura .............................................................................................................. 29

c) Conclusiones ............................................................................................................ 30

2) Fase 2 Exploración y Pruebas: ......................................................................................... 30

G. Selección de metodologías de pruebas ............................................................................... 31

3) Fase 3 Evaluación y Calidad ........................................................................................... 31

a) Nivel de calidad del proceso .................................................................................... 34

b) Calidad y seguridad de Targets ................................................................................ 35

REFERENCIAS ............................................................................................................................. 36

ANEXOS ........................................................................................................................................ 39

LISTA DE TABLAS

TABLA I. VALORACIÓN CUANTITATIVA DE LA CALIDAD ............................................. 32

TABLA II. ESTRUCTURA DEL MODELO DE EVALUACIÓN DE SOFTWARE EDUCATIVO

........................................................................................................................................................ 33

TABLA III. CATEGORÍAS, CARACTERÍSTICAS, SUB-CARACTERÍSTICAS Y NÚMERO

DE MÉTRICAS ............................................................................................................................. 33

TABLA IV. EL NIVEL DE CALIDAD DEL PRODUCTO ES DETERMINADO SEGÚN ...... 34

|LISTA DE FIGURAS

Fig. 1. Referente Teórico ................................................................................................................ 12

Fig. 2.Actividades planteadas para el cumplimiento de los objetivos. .......................................... 23

Fig. 3. Diagrama de flujo de implementación de pruebas. ............................................................. 26

PROTOCOLO DE SEGURIDAD PARA CONTENIDOS DE APRENDIZAJE INTERACTIVO… 1

RESUMEN

Con la incorporación de nuevas tecnologías en el ámbito de la educación y el aprendizaje virtual,

ha aumentado de forma exponencial el desarrollo de aplicaciones interactivas y contenidos de

realidad aumentada enfocadas al aprendizaje, pero a su vez, crecen los riesgos de ser vulnerados

dichos sistemas por cibercriminales con el propósito de exponer y aprovechar la información

privada de las universidades, empresas y usuarios finales para fines delictivos ocasionando desde

pérdidas económicas hasta problemas legales en las organizaciones.

En esta investigación, se busca abordar el tema de seguridad informática en el desarrollo de

contenidos de realidad aumentada, pasando por la seguridad en servidores web, análisis de riesgos,

tipos de vulnerabilidades, políticas de seguridad, metodologías de desarrollo y testeo de software,

entre otros. Planteando así las bases necesarias en los autores responsables de este trabajo para

poder entrar a analizar estos contenidos y dar respuesta a preguntas como ¿Qué tan seguras son

estas aplicaciones? ¿Cómo se construyen estos contenidos para que sean seguros y de alta calidad?

¿Qué riesgos presenta para los dispositivos o computadoras alojar estas aplicaciones y contenidos

de realidad aumentada? ¿Cómo mitigar o dar solución a los posibles riesgos y fallas que estos

contenidos puedan generar?

Finalmente, se espera tener un protocolo de pruebas en base a los resultados se obtuvieron con cada

una de las aplicaciones testeadas, qué errores o falencias se pudieron haber encontrado, cuáles

fueron las técnicas empleadas para solucionar dichas falencias y qué recomendaciones se deben

seguir al momento de empezar a crear un contenido de esta clase.

Palabras clave: Ingeniería del software, Realidad aumentada, Seguridad informática, Contenidos

de aprendizaje interactivo, Protocolo de seguridad.


ABSTRACT

With the incorporation of new technologies in the field ofeducation and virtual learning, it has ex

ponentially increasedthe development of interactive applications and augmentedreality content fo

cused on learning, but in turn, the risksgrow If these systems are violated by cybercriminals with

thepurpose of exposing and taking advantage of the privateinformation of the universities, compa

nies and end users forcriminal purposes resulting from economic losses to legalproblems in the O

rganizations.

In this research, it seeks to address the issue of computersecurity in the development of augmente

d reality content,through Web server security, risk analysis, types ofvulnerabilities, security polic

ies, methodologies of Softwaredevelopment and testing, among others. Thus posing thenecessary

bases in the authors responsible for this work tobe able to enter to analyze these contents and to a

nswer toquestions like how safe are these applications? How arethese contents built to be safe an

d of high quality? What arethe risks for devices or computers hosting these applicationsand augm

ented reality content? How to mitigate or to solvethe possible risks and failures that these content

s cangenerate?

Finally, it is expected to have a test protocol based on theresults were obtained with each of the a

pplications tested,which errors or flaws could have been found, which were thetechniques used to

solve these flaws and whatRecommendations should be followed when you startcreating a conte

nt of this class.

Keywords: Software engineering, Augmented reality, Cybersecurity, Interactive learning content,

Security protocol.


I. INTRODUCCIÓN

En esta investigación, se busca abordar el tema de calidad y seguridad en el desarrollo de

contenidos de realidad aumentada, pasando por el análisis de riesgos, tipos de vulnerabilidades,

políticas de seguridad, metodologías de desarrollo y testeo de software, entre otros. Proporcionando

un protocolo que sirva como base a los futuros estudiantes de la Universidad de San Buenaventura

interesados en desarrollar estos contenidos garantizando la calidad y seguridad de los mismos.

La realidad aumentada consiste en la sobre posición de información virtual en un entorno real;

suele ser confundida con la realidad virtual por el motivo de compartir características como lo son

gráficos 2D y 3D generados de forma computacional, pero su gran diferencia se fija en el hecho de

que la realidad aumentada en ningún momento priva al usuario de interactuar con su entorno real,

puesto que no representa un reemplazo total del mundo que percibe.

Pese a que la realidad aumentada, al ser una tecnología emergente, aún no presenta una oportunidad

potencial para los ciberdelincuentes ni un riesgo alto para los usuarios, a medida que esta tecnología

se convierta en parte de nuestra vida cotidiana, aumentarán los intereses en la manipulación y

vulneración de estos sistemas. Debido a esto, es de gran importancia abordar desde ahora el tema

de la calidad y seguridad en la construcción de estos aplicativos buscando minimizar riesgos a

futuro.

En cuanto al tema de seguridad web y migración a la nube, es anexo el cual tiene como objetivo

principal realizar una introducción sobre la seguridad de las aplicaciones web en general,

presentando un enfoque en arquitecturas resilientes, con mejores prácticas de seguridad y

migración como también en la importancia de las auditorias de las aplicaciones web, mediante

técnicas de pruebas penetración (Hacking Ético) y auditorias de seguridad al código fuente de las

aplicaciones, para identificar vulnerabilidades que atenten contra la disponibilidad, integridad y

confidencialidad de la información. Para ello en el anexo se presenta una arquitectura e

implementación de un aplicativo el cual tiene por nombre WEB SNIES en AmazonWeb Services


II. PLANTEAMIENTO DEL PROBLEMA

En los últimos tiempos se ha intensificado la necesidad del ser humano de utilizar dispositivos

electrónicos, sistemas de información y telecomunicaciones para llevar a cabo desde importantes

procesos y tareas en la industria hasta actividades comunes de la vida cotidiana [1]. Debido a este

gran auge en la tecnología, han aumentado también exponencialmente los riesgos y la

vulnerabilidad de los sistemas, dejando como resultado importantes daños en los mismos y robos

masivos de información con fines delictivos [2-3].

A pesar de que instituciones responsables de la seguridad informática desarrollan constantemente

nuevas y sofisticadas tecnologías para combatir el cibercrimen, los grupos de ciberdelincuentes

innovan también en sus técnicas y herramientas que les permiten quebrantar la seguridad de los

sistemas de sus víctimas y así lucrarse a costa de ellas, aprovechando principalmente el

desconocimiento de las muchas organizaciones y personas que poseen unas bases muy limitadas

en torno a cómo proteger sus sistemas e información privada.

El informe anual de ciberseguridad de Norton en el 2016 expuso la cantidad de personas que se

vieron afectadas por algún delito informático llegando a cifras de 689 millones de personas en

diferentes países del mundo, generando pérdidas de aproximadamente $125.9 billones de dólares

[4]. Mientras que, en 2017, se vio un aumento del 34.6% en el número de personas afectadas,

llegando a una cifra de 928 millones de personas en 20 países, entre ellos se encuentran países

como China, India y Estados Unidos como mayores afectados con un índice de 352.7, 186.44 y

143.7 millones de personas respectivamente [5]. En cuanto a las pérdidas económicas, el aumento

fue de 36.6% dejando bajas a nivel mundial de $172 billones de dólares.

Mientras que algunos delitos informáticos tienen como objetivo la información personal de los

ciudadanos mediante ataques a sus dispositivos móviles, correos electrónicos etc. Otros, por su

parte, van enfocados a las organizaciones y entidades educativas, en busca de vulnerar la seguridad

de sus sistemas por medio de software malicioso, con el fin de adquirir, controlar y manipular


información privada y de gran importancia [6], llegando incluso a afectar los sistemas de copias de

seguridad haciendo imposible la recuperación de la información.

Casos como el del rasomware Wannacry, permiten dimensionar el alcance y el poder que tienen

estos códigos maliciosos en la red, llegando a alcanzar a más de 230.000 ordenadores en 150 países

[7]. La explotación de este malware se dio por medio de una vulnerabilidad llamada Ethernalblue

encontrada en Windows que, haciendo uso del protocolo TCP, se filtró en todos los dispositivos a

los que consiguió acceso, haciendo copias de los archivos y cifrando la información para que no

pudiera ser utilizada por el propietario. Luego de esto se solicitaba una remuneración en Bitcoins

[6] para el descifrado de la información.

Las universidades también han sido objeto de ataques, como son los casos de Yale, Stanford,

Berkeley y Harvard, las cuales fueron objetivo de cibercriminales en los años 2011, 2013, 2014 y

2015 respectivamente, perdiendo una numerosa cantidad de información del personal, estudiantes

y exalumnos, como nombres, números de seguridad social y de tarjetas de crédito, entre otros [8].

En el sistema educativo colombiano, entre el 1 de enero del 2017 y el 20 de febrero del 2018, según

el informe de ciber incidentes de la Policía Nacional, se presentaron 544 ataques [9]. En la

Universidad del Tolima, por ejemplo, se modificaron las notas de más de 1800 estudiantes [10],

alterando temporalmente el sistema evaluativo de la entidad.

Muchos más casos como los anteriormente descritos, salen constantemente en medios de

telecomunicaciones en donde se ve afectada la información privada de alguna persona o entidad.

Es de destacar que, aunque en algunas ocasiones las vulnerabilidades de los sistemas se dan por

una mala configuración, en su mayor parte se deben a errores o malas prácticas de programación

de los propios desarrolladores [11], que no son identificados y mitigados en una fase previa de

pruebas, dejando bugs en los sistemas que son aprovechados para los fines ya mencionados.

Comprendiendo el alcance de una mala implementación en el desarrollo y testing del software, es

de interés de la Universidad de San Buenaventura contar con una metodología segura para el

desarrollo de software, que permita que los contenidos de realidad aumentada puedan ser


publicados en el servidor de la universidad con unas favorables condiciones de seguridad. Según

el docente investigador Carlos Arturo Castro Castro, esto permitirá verificar la disponibilidad,

integridad y confidencialidad de los contenidos ya existentes y servirá de guía para la creación de

contenidos futuros.

Por ende, desde el programa de Ingeniería de sistemas se desea indagar en la literatura existente de

la ciberseguridad, la verificación y la validación del software, con el fin de generar unos

lineamientos basados en los resultados de la experimentación con diferentes metodologías de testeo

en diferentes frameworks, para la construcción segura de los contenidos de realidad aumentada,

protegiendo así la integridad de la información en la Universidad de San Buenaventura.

A. Antecedentes

Ya es un saber común que los cibercriminales se encuentran constantemente en búsqueda de

agujeros de seguridad alojados en las aplicaciones empresariales para vulnerar los sistemas y robar

información para lucrarse de esto. Así lo afirma [12] en donde una de cada dos empresas que

participaron en el estudio fueron víctimas de ataques informáticos. Por ello, es de gran importancia

para las casas desarrolladoras de software y cualquier programador independiente, contar con una

metodología de pruebas que prevenga, en un alto porcentaje, futuros problemas a las

organizaciones.

Partiendo del concepto de verificación y validación de software, como parte fundamental del ciclo

de vida de desarrollo del mismo, [13] y [14] enfatizan en la importancia de un proceso de testing

que analice tanto los elementos funcionales (comportamiento esperado del software) como los no

funcionales (seguridad, desempeño, tolerancia a fallas) del software, yendo a la par con el proceso

de desarrollo, es decir, desde la fase de planeación se debe llevar un paralelo entre la fase de pruebas

y las demás fases del ciclo de vida definiendo las métricas de evaluación y los niveles de aceptación

de dichas métricas.

Así mismo, en [15], también aborda el tema del testing tomando como foco el software basados en

componentes, proponiendo una metodología de testeo la cual consta de 4 diferentes partes,


planeación de pruebas, diseños de casos de prueba, ejecución de pruebas y evaluación de pruebas;

con los cuales actúa sobre el ciclo de vida del software garantizando la calidad de este.

Debido a la necesidad de unificar el ciclo de vida del desarrollo de software (SDLC) con las

técnicas existentes para mejorar los aspectos de seguridad de este, en [16] se realiza una revisión

de diferentes metodologías de desarrollo seguro como lo son: Microsoft Trustworthy Computing

SDL, Appropriate an Effective Guidance In Information Security (AEGIS), Comprehesive,

Lightweight Application Security Process (CLASP), entre otras. Dejando como resultado un

comparativo en donde se resaltan las actividades tendencias en cada una de las fases del SDLC

como unas recomendaciones que se deben tener en cuenta para garantizar el correcto

funcionamiento en la unicidad de estas dos disciplinas.

Otros, por su parte, proponen realizar las pruebas de calidad de una forma aislada o independiente

a dicho proceso. Beatriz Pérez Lamancha en [17], expone que las pruebas deben ser independientes

a la metodología de desarrollo utilizada, siendo aplicadas a una versión ejecutable de la aplicación

sin tener en cuenta el código fuente. Para ello, en la tesis se estudian diferentes metodologías y

técnicas de testeo, proponiendo posteriormente una metodología que ha servido como guía para la

realización de pruebas funcionales; metodología que actualmente es usada en el Laboratorio de

Testing Funcional del Centro de Ensayos del Software (CES).

Para la realización de pruebas en torno al tema de seguridad, en [18] se propone la utilización de

herramientas de testing y pentesting alojadas en KALI-LINUX como son Maltego, Nmap,

Metasploit y técnicas como la ingeniería social, el phising, entre otras, para hacer un análisis de la

seguridad en las aplicaciones que corren en sistemas operativos Windows y Android. Como

resultado obtuvo una valoración completa basada en el producto de las pruebas realizadas con cada

una de las herramientas para saber qué medidas tomar en caso de ser encontradas fallas importantes

en las aplicaciones.

La realidad aumentada (AR) modifica la interacción de las personas con el mundo real. permitiendo

añadir componentes virtuales al mundo físico sin afectarlo. Pero ¿Qué tan segura es esta nueva

tecnología?, tanto [19] como [20] exponen la preocupación de no tener un buen control en la salida


visual de las aplicaciones AR, dejando una brecha para que otras aplicaciones y códigos maliciosos

accedan a los sensores de entrada alterando la percepción de la salida de la información. De igual

forma, ambos artículos proponen modelos que actúan como filtros desde el momento en el que

entra la información por medio de sensores o códigos QR, hasta el momento de su salida por medio

del display, realizando diferentes tipos de análisis tanto a nivel de compatibilidad como en la misma

comunicación con el aplicativo y sus posibles servicios; evitando que la información sea

modificada intencionalmente por programas maliciosos.

Los artículos citados en este apartado aportan diferentes metodologías y técnicas enfocadas a

garantizar la calidad y seguridad del software; para la elaboración del protocolo de pruebas se

resaltan los diferentes procesos de testeo propuestos en (Cristía. Op. cit., p.19), que juntos con las

herramientas, técnicas y metodologías de ethical hacking descritas y usadas en (Veloz. Op. cit.,

p.18), podrían ser implementadas esperando abarcar todos los desarrollos y escenarios de pruebas

posibles. Por otro lado, los trabajos (Lebeck. Op. cit., p.18) y (Lebeck. Op. cit., p.18) presentan

procesos de verificación y validación de la información, viables y con oportunidad de ser

reestructurados.


III. JUSTIFICACIÓN

La fase de pruebas en el ciclo de vida de desarrollo de software permite la oportuna identificación

de bugs y agujeros de seguridad pasados por alto en fases previas, permitiendo la estabilización de

los aplicativos antes de ser desplegados en producción. Ante una mala implementación o una mala

planeación de un proceso de pruebas eficiente, se pueden desatar un sinfín de posibles

vulnerabilidades en los sistemas informáticos que pueden ser aprovechados por los

ciberdelincuentes.

Para la Universidad de San Buenaventura, no contar con un protocolo de pruebas establecido para

la verificación de tecnologías emergentes, como lo es la realidad aumentada, deja una brecha en

los desarrollos realizados por los estudiantes de diferentes ingenierías que pueden convertirse en

potenciales peligros para la integridad de la información de la Universidad.

Por este motivo, en el presente trabajo se generará un protocolo de pruebas basado en los resultados

que se obtengan de un conjunto de aplicativos de realidad aumentada expuestos a diferentes

metodologías de testing y pentesting, permitiendo establecer unos lineamientos de desarrollo

seguro a seguir por los estudiantes y docentes de la universidad de San Buenaventura con el

objetivo de disminuir el riesgo de alojar estos contenidos en los servidores de la universidad.


IV. OBJETIVOS

A. Objetivo general

Desarrollar un protocolo seguridad con énfasis en pruebas para los contenidos interactivos que

implementan realidad aumentada y que están siendo desarrollados en la Universidad de San

Buenaventura, basándose en diferentes metodologías de testing y pentesting garantizando que, en

el despliegue y uso de estos, se preserve la confidencialidad, disponibilidad e integridad de la

universidad.

B. Objetivos específicos

Elaborar un diagnóstico preliminar de los contenidos de realidad aumentada desarrollados por

los estudiantes de la Universidad de San Buenaventura, en dónde queden evidenciados los

resultados los productos entregados.

Diseñar un plan de pruebas e implementarlo en los contenidos de realidad aumentada

desarrollados en la universidad de San Buenaventura, para identificar sus posibles fallas y

vulnerabilidades garantizando la seguridad y la calidad de estos.

Elaborar un protocolo de seguridad que garantice la integridad, disponibilidad y

confidencialidad de la información de la universidad al alojar contenidos de aprendizaje

interactivos de realidad aumentada en sus servidores.


V. HIPÓTESIS

La creación de un protocolo de pruebas para los contenidos de aprendizaje interactivo de realidad

aumentada permitirá a los estudiantes de la Universidad de San Buenaventura contar con unos

lineamientos seguros a la hora de desarrollar estos contenidos, garantizando la integridad,

disponibilidad y confidencialidad de los sistemas informáticos de la Universidad.


VI. MARCO TEÓRICO

Siendo el centro de esta investigación de seguridad en los contenidos de realidad aumentada

enfocados al aprendizaje interactivo, en la Figura 2 se plantea un diagrama que describe la relación

entre la realidad aumentada con los aspectos generales del ciclo de vida de desarrollo de software,

las diferentes metodologías de pruebas que existen y los ataques informáticos que pueden afectar

cualquier sistema de información.

A. Ingeniería del software

Se define como una disciplina encargada de preocuparse por abarcar todos los aspectos de la

fabricación de software, pasando por todas las fases de su ciclo de vida hasta las herramientas,

metodologías y teorías que guíen el proceso de desarrollo a un producto rentable [21], dependiendo

del problema que se quiera solucionar.

Fig. 1. Referente Teórico


1) Ciclo de vida del software

El desarrollo de software conlleva un ciclo de vida conformado por unas fases pensadas para

mantener un control en su construcción, buscando el cumplimiento de los requerimientos de los

clientes de una manera eficiente, segura y ágil [22]. Actualmente no existe solo una metodología

de desarrollo que rija rigurosamente las fases que se deben seguir en la elaboración de software

[23]. Sin embargo, existen unas fases fundamentales que se explican a continuación.

a) Planeación

Siendo símil a la fase inicial de cualquier proyecto de cualquier disciplina, el proceso de desarrollo

de software debe contar con una fase inicial de planeación en donde realizan actividades cuyos

resultados son necesarios para poder seguir con las fases posteriores. Estas actividades son:

delimitación del proyecto, estudios de viabilidad, estimación de costos y análisis de riesgos. Cada

una de ellas apunta a aspectos fundamentales que se deben tener claros antes de continuar el ciclo

de vida.

b) Análisis

Para poder empezar a desarrollar cualquier tipo de software, se debe tener claro inicialmente qué

es lo que se quiere hacer. La fase de análisis consta de la elicitación de requerimientos de los

clientes plasmándolos en unos formatos guías (casos de uso, historias de usuario, entre otros) que

permitan entender claramente la funcionalidad que debe tener el sistema según las necesidades del

cliente.

Esta tarea de realiza por medio de entrevistas a los interesados tratando de dejar claro qué es lo que

se quiere hacer.


c) Diseño

Teniendo ya establecido en las fases previas el qué se quiere hacer, en la fase de diseño se procede

a determinar el cómo se va a hacer. Para ello, se deben proponer tres modelos que empezarán a

regir el desarrollo del software en las fases siguientes:

Modelo arquitectónico: en el cual se define la arquitectura con la que se va a desarrollar el

sistema.

Modelo de base de datos: en donde se define la estructura que tendrá la base de datos del

sistema.

Modelo gráfico: en el que se plasma una propuesta de interfaz de usuario teniendo en cuenta

los dos modelos anteriores.

La fase de diseño es iterativa, por lo que las primeras versiones de estos modelos están sometidas

a cambios conforme se avance en el desarrollo del proyecto.

d) Implementación

Una vez se tengan claros los ítems realizados en las fases anteriores, se procede a la fase de

implementación en donde se inicia la codificación del aplicativo a desarrollar (Berzal. Op., cit.

p.15.). Sin embargo, antes de entrar en materia de programación se deben escoger las mejores

herramientas dependiendo del tipo de sistema que se vaya a desarrollar.

Es clave resaltar que el desarrollo de esta fase debe estar medido por los modelos analizados y

establecidos en la fase de diseño, respetando así la estructura que se decidió utilizar, el modelo de

datos y la interfaz gráfica.


e) Pruebas

La fase de pruebas consiste en evaluar el correcto funcionamiento del sistema según los

requerimientos y alcances establecidos en las fases iniciales para determinar si se está construyendo

el producto correctamente (verificación) y, por otro lado, evaluar durante o al final del proyecto si

se está construyendo el producto correcto dependiendo de las especificaciones establecidas

inicialmente (validación).

B. Pruebas del software

El proceso de pruebas de software consiste en someter a un sistema informático a diferentes

entornos o panoramas con condiciones específicas, como lo son ataques a su estructura,

compatibilidad, calidad y seguridad; con la finalidad de observar, analizar y evaluar su

comportamiento [24].

1) Metodologías de testing

Para llevar a cabo las pruebas de software, se hace uso de diferentes técnicas y metodologías de

testeo, que pueden ser clasificadas, según el tipo de prueba que se esté realizando y según el

enfoque con cual esta se realiza.

Según el tipo de prueba que se esté realizando:

Pruebas estructurales: También llamadas pruebas de caja blanca, son aquellos tipos de

pruebas diseñadas y destinadas a evaluar el código fuente del programa (Lamancha. Op. cit., p.

8), garantizando que sus estructuras lógicas estén desarrolladas de la forma correcta evitando

posibles errores como bucles infinitos, desbordamientos de información o bien errores

matemáticos.


Dentro del tipo de pruebas estructurales encontramos: pruebas basadas en el flujo de control,

pruebas basadas en el flujo de datos y pruebas mutantes.

Pruebas Funcionales: También conocidas como pruebas de caja negra y a diferencia de las

pruebas de caja blanca, no se necesita conocer el código fuente del sistema, debido a que este

tipo de pruebas se aplica sobre la interfaz de usuario, usando un conjunto de datos de entrada

al sistema y analizando sus salidas, garantizando que la relación entrada – salida o bien usuario

– sistema sea correcta.

Dentro del tipo de pruebas funcionales encontramos: pruebas de partición de equivalencia,

pruebas de análisis del valor limite, tablas de decisión, máquinas de estado finito, grafos causa

efecto, pruebas de caso de uso, pruebas de dominios.

Según el enfoque con el cual se realiza:

Pruebas unitarias: Las pruebas unitarias o pruebas de componentes, consiste en evaluar de

forma independiente cada subprograma o algoritmo que conforman el software [25];

segmentando el código fuente en sus diferentes funciones, clases, métodos o instancias y

verificando su correcto funcionamiento. Las pruebas unitarias suelen estar relacionadas a

pruebas estructurales.

Pruebas de integración: Las pruebas de integración son realizadas con la finalidad de

garantizar que, si bien un software ha pasado las pruebas unitarias de forma exitosa, este siga

funcionando de forma correcta cuando los subprogramas interactúen entre sí [15].

Para evaluar la interacción entre los diferentes componentes del sistema, existen diferentes

estrategias de integración, entre las cuales encontramos: integración ascendente, integración

descendente, integración de esqueleto, integración Ad hoc. Las pruebas de integración suelen

estar relacionadas tanto a pruebas funcionales como a pruebas estructurales.

Pruebas del sistema: Consiste en verificar que el software cumpla los requerimientos

funcionales y no funcionales previamente especificados en la etapa de análisis del ciclo de vida

de este [24]; evaluando aspectos como calidad, seguridad, desempeño y compatibilidad con su


entorno de ejecución (hardware) y con otros sistemas informáticos. Las pruebas de sistema

suelen estar relacionadas a tipo de pruebas funcionales.

C. Pentesting

El Pentesting tienen como objetivo fundamental verificar mediante la implementación de 5

diferentes fases de análisis y diversos enfoques, el nivel de seguridad de un aplicativo, sistema o

red frente a posibles delitos informáticos [26]; revelando vulnerabilidades o fallas que podrían

representar un riesgo potencial.

1) Fases del Pentesting

a) Recopilación de información

Se busca obtener la mayor cantidad de información posible, mediante técnicas de ingeniería social

y practicas informáticas enfocadas en la captura y análisis del tráfico de información en la red de

la organización.

b) Escaneo

Haciendo uso de la información previamente recopilada, se buscan efectuar un escaneo detallado,

con el objetivo de hallar posibles vulnerabilidades del sistema que posterior mente puedan ser

usadas como entrada al sistema. En te escaneo suelen encontrarse las famosas back-doors o puertas

traseras.

c) Análisis de vulnerabilidades

Esta fase busca la estructurar un plan de ataque dependiendo del tipo de vulnerabilidad encontrado

en la fase de escaneo.


d) Explotación

En esta fase se implementa el pan estructurado en la fase anterior con el objetivo de entrar en el

sistema y tomar control de este; por lo cual, por primera vez durante todo el proceso, la seguridad

e integridad del sistema se ve comprometida y puesta a prueba.

e) Reportes

Una vez finalizadas las fases anteriores, se debe construir un informe en el cual se expongan las

vulnerabilidades encontradas y eminentes riesgos y consecuencias que estas pueden presentar para

integridad y bienestar de la organización.

Por lo general el reporte también cuenta con un apartado en el cual se habla sobre las debilidades

y fortalezas del sistema a cuanto al tema de seguridad se refiere y su comportamiento al momento

de haberse llevado a cabo la fase de explotación.

D. Seguridad Informática

Cuando se habla de seguridad informática, se hace referencia a todo esquema, proceso o

metodología, que tenga como objetivo principal proteger la información alojada o almacenada en

un sistema informático, frente a posibles ataques que busquen dañar, modificar u obtener dicha

información [28-29]; garantizando el cumplimiento de los pilares fundamentales de la gestión y

seguridad de la información (confidencialidad, integridad y disponibilidad).

1) Confidencialidad

La confidencialidad, tiene como objetivo, mediante la autenticación, autorización y cifrado;

prevenir que la información sea divulgada de forma inapropiada a personal o sistemas no

autorizados.


2) Integridad

La integridad, busca garantizar que la información permanezca intacta y sin alteraciones, frente a

posibles eventualidades como ataques informáticos o modificaciones no autorizadas.

3) Disponibilidad

La disponibilidad, pretende mantener la información al alcance del personal o sistema autorizado,

cuando estos lo requieran.

4) Tipos de vulnerabilidades

Una vulnerabilidad informática, es toda aquella brecha, desperfecto, falla o debilidad del sistema

[29], que puede presentarse debido a errores en la codificación, problemas y debilidades en el

entorno de ejecución o malas prácticas de seguridad, que si bien, no son detectados y corregidos a

tiempo, ponen en riesgo los activos informáticos de la organización.

Vulnerabilidades en equipos físicos:

Cableado de red.

Routers.

Red de informática (computadores, teléfonos, impresoras, cámaras).

Servidores.

Vulnerabilidades en programas o aplicaciones informáticas:

Sistemas operativos.

Bases de datos.

Servidores.

Aplicaciones web y de escritorio.

Aplicaciones móviles.

Antivirus.


5) Tipos de ataques

Un ataque informático es la materialización de una amenaza, la cual ha logrado infiltrarse en el

sistema, al explotar o aprovechar una vulnerabilidad en la seguridad de este [29].

Debido a los daños ocasionados, los ataques pueden clasificarse en ataques activos y ataques

pasivos.

a) Ataques Activos

Son aquellos ataques que mediante el uso de diferentes técnicas informáticas delictivas como lo

son la suplantación de identidad, la interceptación de información y la degradación de servicio

(López. Op. cit., p. 5); buscan alterar la información alojada en el sistema e interrumpir o inhabilitar

su comunicación.

b) Ataques Pasivos

Se dice que un ataque es pasivo cuando su objetivo principal, solo es acceder a la información

almacenada en el sistema con el fin de obtener información valiosa, sin modificarla o eliminarla,

como lo hace el ataque activo.

A su vez, dichos ataques (activos o pasivos) pueden llevarse a cabo mediante diferentes técnicas

entre las cuales encontramos:

Interrupción.

Intercepción.

Fabricación.

Phishing.

Keyloggers.

Fuerza bruta.

Spoofing.


Sniffing.

Dos.

DDos.

E. Realidad Aumentada

La realidad aumentada es la sobreposición de información virtual en un plano real [31-32]; suele

ser confundida con la realidad virtual por el motivo de compartir características como lo son

gráficos 2D y 3D generados de forma computacional, pero su gran diferencia se fija en el hecho de

que la realidad aumentada en ningún momento priva al usuario de interactuar con su entorno real,

puesto que no representa un reemplazo total del mundo que percibe por uno virtual [32].

1) Arquitectura de un sistema de realidad aumentada

El nivel de integración de la realidad-virtualidad, depende ampliamente de la visualización y

seguimiento, dos elementos fundamentales en la arquitectura de un sistema de realidad aumentada

[33].

Donde el proceso de visualización es la encargada de generar los elementos virtuales y combinarlos

con el entorno real para posteriormente exponerlos al usuario por medio de una interfaz o pantalla,

pero para que el proceso de visualización pueda generar los elementos virtuales de forma tal que

encajen en los reales. Se hace indispensable conocer la posición y orientación del usuario y los

elementos reales presentes en su campo de visión; es aquí cuando el proceso de seguimiento es el

encargado de otorgar dicha información al proceso de visualización.


2) Clasificación según el hardware que lo soporta

La forma en la que se expone al usuario la realidad aumentada puede clasificarse dependiendo

hardware sobre el cual se ejecuta la aplicación. Para mejor comprensión los clasificaremos en

grupos enumerados del 1 al 3.

Grupo 1: En este grupo se encuentran las computadoras de mesa y portátiles.

Grupo 2: En este grupo se ubican aquellos dispositivos que por lo general su hardware es de

menor tamaño que los del grupo anterior, como lo son los celulares y tabletas electrónicas.

Grupo 3: En este grupo se ubican todos equipos creados y diseñados con el objetivo específico

de exponer aplicaciones de realidad aumentada; aquí encontramos las gafas de realidad

aumentada [34].

3) Clasificación según la tecnología utilizada

Para el uso de la sobreposición de elementos virtuales, la realidad aumentada apoyarse en el uso

de 3 tipos de tecnologías.

Patrones de disparo: consiste en generar cierto elemento de realidad virtual a partir de la lectura

de una determinada figura, imagen o código. Esta tecnología pone una identificación real a

cada elemento virtual.

Geolocalización: utiliza los satélites para proporcionar una ubicación más exacta del usuario y

los elementos reales captados por él dispositivo, permitiendo al aplicativo de realidad

aumentada brindar elementos virtuales con más precisión.

Interacción con internet: Este tipo de tecnología es capaz de analizar un elemento real en

específico y relacionarlo con una consulta a internet, brindando los resultados de dicha

búsqueda en forma virtual [35].


VII. METODOLOGÍA

Para la universidad de San Buenaventura es necesario contar con un protocolo de pruebas para los

contenidos de realidad aumentada desarrollados y por desarrollar, que garantice la disponibilidad,

integridad y confidencialidad de la información de la Universidad al momento de publicarlos en

sus servidores.

Se plantearon unas actividades a seguir como propuesta metodológica para el cumplimiento de

cada objetivo específico, teniendo como foco el cumplimiento del objetivo general. En la siguiente

figura se observan cuáles son las actividades planteadas.

Fig. 2.Actividades planteadas para el cumplimiento de los objetivos.


A. Revisión de la literatura sobre el desarrollo de contenidos de realidad aumentada

Como actividad inicial se realizará una revisión de la literatura sobre el desarrollo de contenidos

de realidad aumentada, teniendo en cuenta factores como: qué lenguajes de programación se

utilizan, cuáles frameworks son los más populares y cómo funcionan, qué patrones de diseño se

deben utilizar y qué prácticas de programación segura existen para este tipo de contenidos.

La recolección de esta información se realizará por medio de libros físicos y medios electrónicos,

extrayendo lo necesario en un documento digital que servirá a los autores del presente proyecto

como apoyos teóricos en las siguientes actividades de la metodología.

La elaboración de esta actividad tendrá como objetivo una correcta capacitación de los autores en

el tema de realidad aumentada, garantizando así a los lectores un mayor nivel de confianza en los

resultados finales de la investigación.

B. Identificación de las prácticas de desarrollo de los contenidos de realidad aumentada

En esta actividad se realizará un análisis de los contenidos de realidad aumentada desarrollados por

los estudiantes de la universidad de San Buenaventura, para identificar los diferentes componentes

de su desarrollo y las características de los frameworks en los que fueron construidos. Esto con el

fin de entender su funcionamiento y facilitar posteriormente la selección de las metodologías de

testing y pentesting que se van a utilizar.

Se tomarán los siguientes aspectos generales para la evaluación de los contenidos. Sin embargo,

estos pueden estar sujetos a cambios mientras se vaya avanzando en el desarrollo del proyecto.

Manejo de autenticaciones: en caso de que la aplicación requiera autenticación por parte del

usuario, se analizarán los métodos utilizados para cumplir con esta funcionalidad.

Acceso a los datos: por lo general, toda aplicación requiere mantener una comunicación con

una base de datos para consultar, ingresar, actualizar o borrar información. Por esto, es

importante analizar también las maneras en las que se realizan las conexiones y como se


ejecutan las cadenas de consultas (procedimientos almacenados, funciones o querys quemados

en el código).

Arquitectura: se deberá identificar el patrón de diseño para entender el flujo de ejecución de los

aplicativos, ya que este varía dependiendo de las capas que se manejen.

Interacción con el usuario: se analizarán los métodos utilizados en la comunicación entre el

lado del cliente y el lado del servidor, para entender cómo es el flujo de la información y las

técnicas utilizadas para su visualización.

De igual manera, en esta fase de la metodología se deben identificar los criterios de selección de

las metodologías de testing y pentesting según resultados del análisis de los contenidos existentes.

Toda la información recolectada servirá como base para la realización de la siguiente actividad.

Debido a esto, es necesario documentar los resultados mientras se analiza cada uno de los aspectos

descritos anteriormente.

C. Implementación de pruebas

El descubrimiento de bugs y agujeros de seguridad dentro de los contenidos serán las bases para el

desarrollo del protocolo. Por esto, es necesario implementar rigurosamente las metodologías de

testing y pentesting seleccionadas con anterioridad, buscando siempre el acatamiento de los pilares

del protocolo: la integridad, disponibilidad y confidencialidad.

La implementación de las pruebas se puede apreciar de forma muy general en el siguiente diagrama

de flujo. Dicho proceso se realizará con cada una de ellas.


Como se puede observar en el diagrama, cada una de las pruebas seleccionadas debe ser realizada

a cada uno de los contenidos, si presentan errores deben ser corregidos y todo debe quedar

documentado para poder generar el protocolo. Al momento de escribir esta metodología no se tiene

un número fijo de contenidos de realidad aumentada a evaluar, pero si se tiene certeza de que, por

motivos de tiempo, se someterán a las pruebas un máximo de tres aplicativos todos realizados por

estudiantes de la universidad de San Buenaventura. Por otro lado, el número de pruebas que se van

a realizar está sometido a las posibles debilidades encontradas en las actividades anteriores.

D. Identificación y corrección de fallas

Analizando los resultados de las pruebas, se determinarán los bugs y las fallas de los contenidos

que pueden presentar una amenaza para los servidores de la universidad. Por otro lado, se analizará

el código fuente de los contenidos para detectar malas prácticas programación como lo son: querys

quemados en el código, conexiones no cerradas a la base de datos, exposición de fuentes de

servicios web utilizados, entre otros.

Fig. 3. Diagrama de flujo de implementación de pruebas.


E. Diseño del protocolo de pruebas

Basado en todos los resultados obtenidos en las actividades anteriores, se procederá a documentar

los lineamientos establecidos como necesarios para una correcta construcción y evaluación de los

contenidos de realidad aumentada, que sirva como base a los futuros estudiantes de la Universidad

que deseen desarrollar este tipo de contenidos.

Este documento será el protocolo y estará divido inicialmente en tres secciones:

Explicación de metodologías de testing y pentesting utilizadas: en la cual se dará una

explicación del funcionamiento de cada una de las metodologías utilizadas, el por qué se

escogieron y las ventajas que presenta su aplicación.

Ejemplos de aplicación y resultados: en donde se mostrarán ejemplos de las aplicaciones de las

metodologías a los contenidos de realidad aumentada para que, el protocolo, cumpla su papel

de guía en los procesos de desarrollo de contenidos de realidad aumentada.

Lineamientos de programación segura: en esta sección de propondrán lineamientos de

programación segura que podrán ser adquiridos por los estudiantes interesados en desarrollar

estos tipos de contenidos.

Esta estructura es una propuesta inicial, pero puede verse afectada durante el desarrollo de la

investigación

F. Documentación de la investigación

Como actividad final, se deberá documentar todo el desarrollo del presente trabajo desde las

primeras actividades realizadas hasta los últimos resultados obtenidos. Esto con el fin de dejar

plasmado el trabajo de investigación realizado y sirva como fuente de conocimientos para otras

interesadas.


VIII. RESULTADOS

A. Protocolo

El estudiante, docente o grupo del seminario de investigación que implemente el protocolo, debe

tener conocimientos base sobre el funcionamiento y uso de sistemas informáticos, ingeniería de

requisitos, diagramas UML, modelado de datos y testing. El protocolo propuesto en este trabajo de

grado servirá de herramienta a estudiantes y docentes de la universidad de San Buenaventura al

momento de determinar si un contenido de realidad aumentada es un desarrollo seguro y de calidad

para ser desplegado y usado por los estudiantes.

El protocolo, está compuesto por 3 fases mediante las cuales se pretende establecer un orden en el

cual se verifique y garantice la calidad y seguridad de los contenidos de aprendizaje interactivo de

realidad aumentada, desarrollados en la universidad; abarcando todo el ciclo de vida del software,

desde etapa de análisis hasta la etapa de despliegue.

Fase 1: Recolección y Análisis.

Fase 2: Exploración y Pruebas.

Fase 3: Evaluación y Calidad.

1) Fase 1 Recolección y Análisis

En la ingeniería del software, el modelo de requisitos tiene como objetivo describir en la etapa

inicial del desarrollo de software, cómo deberá ser el funcionamiento de este según las

especificaciones de los clientes en las entrevistas realizadas por los analistas, y establecer cuáles

serán las restricciones que limitarán el producto. Este modelo se puede dividir en varias ramas que

ayudan a un mejor entendimiento de los objetivos del software a construir, entre estas están:

Modelo basado en escenarios: describe la representación del sistema desde el punto de vista de

los usuarios.


Modelo basado en datos: describe el espacio de información, los objetos de datos y las

relaciones entre estos.

Modelo basado en clases: describe las funciones y los atributos de las entidades que conforman

el sistema y el cómo se relacionan entre ellas.

Para realizar un modelo de requisitos se seleccionan entre una amplia variedad de representaciones

de texto y diagramas, los más adecuados según las necesidades que se requieran ilustrar. La

verificación y validación de los productos de este modelo de requisitos se realiza mediante unas

técnicas de validación estáticas, que consisten en comprobar la correspondencia entre un programa

y sus especificaciones, más no que sea funcional.

Así pues, un buen resultado de la fase de análisis de requisitos brinda al desarrollador y a los

analistas los medios para medir la calidad del software una vez es desarrollado. Por ello, el

propósito de esta fase consiste en analizar y sintetizar la información existente y otorgada por el

semillero de investigación sobre cada contenido desarrollado, en cuanto a documentación y ciclo

de vida de software se refiere.

Esta Fase está compuesta por 3 ítems los cuales deben ser ejecutados en orden propuesto:

a) Definición general

El estudiante o docente deberá resumir el problema que se quería resolver con el desarrollo del

contenido puesto en cuestión. Para este resumen se tendrá en cuenta la información que se debió

entregar del proceso de desarrollo del software (manual de usuario y manual técnico,

requerimientos funcionales y casos de uso etc.).

b) Arquitectura

El estudiante o docente deberá ilustrar, analizar y explicar de forma breve, la arquitectura o

estructura en la que se realizó la entrega de la aplicación y su correspondiente documentación


(Casos de uso, diagramas de clases, modelos de bases de datos, historias de usuario, diagramas de

flujo, código fuente, etc.).

c) Conclusiones

El estudiante o docente deberá realizar una breve conclusión del estado en el que se encuentra la

arquitectura y documentación analizada, puesto que esta información servirá de insumo en la fase

3 (“Fase de Evaluación y Calidad”) del protocolo propuesto, para validad la calidad del proceso de

desarrollo.

2) Fase 2 Exploración y Pruebas:

Con la finalidad de verificar la calidad y seguridad de los contenidos, en esta fase el estudiante,

docente o grupo del semillero, deberá realizar la instalación del contenido de realidad aumentada

para luego interactuar con él y ponerlo a prueba; La instalación y uso se realizarán siguiendo los

manuales otorgados con la aplicación, con esto se pretende verifica que los manuales estén

completos y sean claros y fáciles de entender para el usuario final.

Si no se cuente con el manual o guía de instalación y uso, quien este implementando el protocolo

deberá analizar y buscar la forma de poder desplegar o ejecutar el contenido plasmando los pasos

implementados para su despliegue y requerimientos del sistema, en el apartado “Requerimientos e

Instalación” presente en el anexo “Plantilla Protocolo de calidad y seguridad para contenidos

interactivos de realidad aumentada”. Las tablas presentes en el apartado “Requerimientos e

Instalación” está basada en las “características resaltantes del formato SOFED-01” y la dimensión

técnica de “Orientaciones para el uso pedagógico de la evaluación de software educativo”

propuesto por González.

Una vez instalado el Contenido de realidad aumentada, es necesario realizar pruebas, es necesario

realizar pruebas de funcionalidad, confiabilidad y usabilidad en busca de vulnerabilidades, bugs o

errores lógicos que puedan causar fallos en la aplicación u ocasionar perdida de la información.

Para ello se hará uso del plan de pruebas presente en el anexo “Plantilla Protocolo de calidad y


seguridad para contenidos interactivos de realidad aumentada” el cual deberá ser acoplado y

diligenciado de acuerdo a las características del contenido de realidad aumentada en cuestión.

Si se desea realizar pruebas de pentesting a los contenidos de realidad aumentada que son

aplicaciones móviles para el sistema operativo Android, se propone hacer uso de Quick Android

Review Kit (QARK) debido a su facilidad de uso y efectividad permitiendo realizar análisis tanto

de los archivos. APK como del código fuente. Para su correcta configuración, revisar el anexo

“Configuración de QARK” presente en los entregables del proyecto.

G. Selección de metodologías de pruebas

Siendo conscientes de la existencia de las numerosas metodologías de testing y pentesting que

existen, es necesario tener claro cuáles son las que se van a utilizar para una correcta verificación

y validación de los contenidos de realidad aumentada. Dichos criterios de selección estarán dados

por los factores deterministas encontrados en la actividad previa a la presente, en donde se debieron

haber identificado las debilidades de los aplicativos para poder ser expuestas a sus correspondientes

pruebas y, en caso de ser encontrada una falla, proceder a realizar las respectivas correcciones en

las actividades posteriores.

Para la selección de las metodologías de testing, se revisará la literatura sobre el tema en diferentes

libros y se tendrán como base diferentes ejemplos de aplicaciones de otros trabajos de investigación

publicados por la comunidad académica. Por otro lado, las metodologías de pentesting serán

seleccionadas del proyecto abierto de seguridad en aplicaciones web (OWASP), quienes exponen

gran cantidad de metodologías de pentesting enfocadas a diferentes necesidades de las

aplicaciones, las cuales deberán ser adaptadas a los contenidos de realidad aumentada.

3) Fase 3 Evaluación y Calidad

Después de haber ejecutado la fase 1 y 2 del presente protocolo, en esta fase final, se busca verificar

y realizar una retro alimentación del estado y el nivel de calidad que posee el contenido de realidad

aumentada. Para ello será necesario ejecutar en orden los siguientes cinco ítems mediante los cuales


se hace uso de diferentes modelos, metodologías y técnicas basadas en estándares internacionales

de calidad.

Para la valoración de la calidad y el diligenciamiento de los respectivos formatos, se hará uso de la

tabla normalizada en [36] permitiendo así obtener una valoración cuantitativa de cada ítem o

característica.

TABLA I. VALORACIÓN CUANTITATIVA DE LA CALIDAD

Nota: tomado de [36]

Nivel de calidad del producto: Para la verificación del nivel de calidad del producto, se hará uso

del modelo “Calidad Sistemática del Software Educativo” [37]. En este modelo, se realiza una

adecuación del modelo MOSCA hacia la evaluación de software educativo enfocándose en la

perspectiva de calidad de producto establecida por la ISO/IEC 9126; pero enfocando su valoración

solo en las características de funcionalidad, usabilidad y fiabilidad permitiendo determinar así el

nivel de calidad en el que este se encuentra (básica, intermedia o avanzada).

El modelo “Calidad Sistemática del Software Educativo” [38], está estructurado en 4 niveles

(categorías, características, sub-características, métricas) mediante los cuales se realiza la

evaluación del software educativo.


TABLA II. ESTRUCTURA DEL MODELO DE EVALUACIÓN DE SOFTWARE EDUCATIVO


TABLA III. CATEGORÍAS, CARACTERÍSTICAS, SUB-CARACTERÍSTICAS Y NÚMERO DE MÉTRICAS


Para determinar el nivel de calidad del producto, la metodología usa el algoritmo planteado en

MOSCA, el cual se determina que, como primer requisito para hacer uso del algoritmo, la categoría

de funcionalidad debe ser satisfecha para luego poder proceder con la verificación de la satisfacción

de las otras 2 categorías (Usabilidad. Fiabilidad). Desacuerdo a lo establecido en el algoritmo

propuesto en MOSCA, para que una categoría pueda determinarse satisfecha, debe cumplir con un

mínimo de características asociadas satisfechas (2 de 3 para funcionalidad, 3 de 4 para usabilidad

y 2 de 3 para fiabilidad). Dado que el sistema de evaluación del algoritmo está basado en una


calificación cuantitativa en una escala de 1 a 5, una característica o sub-característica es

considerada satisfecha si el 75% de las métricas evaluadas asociadas, cuentan con una calificación

mayor o igual a 4.

TABLA IV. EL NIVEL DE CALIDAD DEL PRODUCTO ES DETERMINADO SEGÚN


Para la evaluación de los contenidos de realidad aumentada de la universidad, se preseleccionaron

métricas adecuadas a cada categoría:

a) Nivel de calidad del proceso

Un producto o desarrollo de software, es el resultado de la ejecución de diferentes etapas, es por

ello que la calidad en la ejecución y el cumplimiento de cada etapa, contribuirán en la calidad y

seguridad del producto final.

Para garantizar la calidad del proceso de desarrollo del software, el estudiante, docente o grupo del

semillero deberá completar 2 tablas creadas a partir de los elementos básicos que ciclo de vida del

software debe tener, entre los cuales se encuentran:

Requisitos funcionales.

Requisitos no funcionales.

Casos de uso.

Historias de usuario.

Modelo entidad relación (MER) (de ser necesario).

Base de datos.

Código fuente.

Ejecutable o URI.

Funcionalidad Usabilidad Fiabilidad Nivel de calidad del producto de software

Satisfecha No Satisfecha No Satisfecha Básico

Satisfecha Satisfecha No Satisfecha Intermedio

Satisfecha No Satisfecha Satisfecha Intermedio

Satisfecha Satisfecha Satisfecha Avanzado


Manual técnico.

Manual de usuario.

El sistema de valoración utilizado en estas tablas es una valoración calificativa, definida de la

siguiente manera:

B: representa que el artefacto fue realizado correctamente y es aprobado.

R: representa que el artefacto está bien, pero necesita correcciones para ser aprobado.

M: representa que el artefacto no fue realizado correctamente y no puede ser aprobado.

C: representa que el artefacto está completo.

I: representa que el artefacto está incompleto.

b) Calidad y seguridad de Targets

Para la garantizar el nivel de calidad y seguridad de los targets (marcadores personalizados, códigos

QR.) utilizados como base de información para proyecciones de contenido de realidad aumentada

dentro de las aplicaciones, en este protocolo se hará uso del analizador SDK de Vuforia el cual

evaluará ciertos atributos de nuestro Target tales como:

Detalles.

Contrastes.

Patrones repetitivos.

Formato.

Otorgando al finalizar la evaluación una calificación mediante un esquema de puntación con

estrellas, de 1 a 5 con el objetivo de facilitar y optimizar su detección por medio de la cámara.

Para aplicar este paso y obtener el resultado de calidad del target, (Anexo “Calidad del Target”).


REFERENCIAS

[1] C. A. R. Haro, “La Seguridad Informática,” Rev. Cienc. Unemi, vol. 4, no. 5, pp. 26–33,

2015.

[2] Cisco, “Informe anual de ciberseguridad,” 2016. [Online]. Available: shorturl.at/klnzF.

[Accessed: 18-May-2018].

[3] M. G. Ignacio, “Delitos Informáticos en Latinoamérica :,” in XLIII Jornadas Argentinas de

Informática e Investigación Operativa, 2014, pp. 129–139.

[4] N. Cyber, S. Insights, and G. Results, “2017 Norton Cyber Security Insights Report Global

Results,” 2017. [Online]. Available: www.shorturl.at/fnuyF. [Accessed: 15-May-2018].

[5] Norton, “Norton Cyber Security Insights Report,” Norton Cyber Security Insights Report

2016, 2016. [Online]. Available: www.shorturl.at/cdhnV. [Accessed: 15-May-2018].

[6] M. J. Arnaltes, “-MISTIC- Ransomware,” 2017. [Online]. Available: shorturl.at/enW59.

[Accessed: 10-May-2018].

[7] Avast, “Ransomware WannaCry: qué es y cómo proteger su PC.” [Online]. Available:

shorturl.at/jpEWY. [Accessed: 20-May-2018].

[8] UpGuard, “The Lucrative Rewards of Hacking Higher Education,” 2017. [Online].

Available: shorturl.at/pJKQW. [Accessed: 20-May-2018].

[9] Policía Nacional, “Ciberincidentes | Centro Cibernético Policial.” [Online]. Available:

shorturl.at/ijmwQ. [Accessed: 20-May-2018].

[10] El espectador, “Estudiantes de la Universidad del Tolima mejoraron sus notas por

manipulación de hacker,” 2018. [Online]. Available: https://goo.gl/HzQGu4. [Accessed: 20-

May-2018].

[11] P. A. López, Seguridad informática. Madrid: Editex, 2010.

[12] ESET, “Eset Security Report Latinoamérica 2017,” Eset Security Report Latinoamérica

2017, 2017. [Online]. Available: shorturl.at/jxL04. [Accessed: 21-May-2018].

[13] M. Cristia, “Introducción al Testing de Software,” pp. 1–8, 2009.

[14] J. A. Mera-Paz, “Análisis del proceso de pruebas de calidad del software,” J. Eng. Educ.,

vol. 12, no. 20, pp. 163–176, 2016.

[15] J. C. Ochoa, “Metodología para testing de software basado en componentes,” Universidad

EAFIT, 2010.


[16] M. Castellaro, S. Romaniz, J. Ramos, and P. Pessolani, “Hacia la Ingeniería de Software

Seguro,” Fac. Reg. St. Fe - Univ. Tecnológica Nac., vol. 610, p. 10, 2009.

[17] B. P. LAMANCHA, “Proceso de testing funcional independiente,” Universidad de la

república, 2006.

[18] J. Veloz, A. Alcivar, G. Salvatierra, and C. Silva, “Ethical hacking, una metodología para

descubrir fallas de seguridad en sistemas informáticos mediante la herramienta KALI-

LINUX,” Año, vol. 11, no. 1, pp. 1–12, 2017.

[19] K. Lebeck, T. Kohno, and F. Roesner, “How to Safely Augment Reality : Challenges and

Directions,” Proc. 17th Int. Work. Mob. Comput. Syst. Appl., pp. 45–50, 2016.

[20] K. Lebeck, K. Ruth, T. Kohno, and F. Roesner, “Securing Augmented Reality Output,”

Proc. - IEEE Symp. Secur. Priv., no. Oakland, pp. 320–337, 2017.

[21] D. Ramos, R. Noriega, J. R. Laínez, A. Durango, and I. C. Academy, Curso de ingeniería

del software: 2° edición, 2nd ed. 2017.

[22] F. Berzal, “El ciclo de vida de un sistema de información,” 2015. [Online]. Available:

shorturl.at/bjrVX. [Accessed: 22-May-2018].

[23] D. Cap, Ciclo de vida del software. 2005.

[24] J. M. Peño, “Pruebas de Software. Fundamentos y Técnicas,” E.T.S.I. y Sistemas de

Telecomunicación (UPM), 2015.

[25] I. Sommerville, “Procesos del software,” in Ingeniería del software, 7th ed., Madrid:

Pearson Educación, 2005, pp. 60–79.

[26] R. M. Martí, “Desarrollo e implementación práctica de un PENTEST,” Universidad

politécnica de Valencia, 2016.

[27] F. N. S. Solarte, E. R. E. Rosero, and M. del C. Benavides, “Metodología de análisis y

evaluación de riesgos aplicados a la seguridad informática y de información bajo la norma

ISO/IEC 27001,” Rev. Tecnológica - ESPOL, vol. 28, no. 5, pp. 492–507, 2015.

[28] Á. G. Vieites, Enciclopedia de la seguridad informática 2° edición, 2nd ed. 2011.

[29] J. F. R. Buendía, Seguridad Informática. Madrid, 2013.

[30] X. Basogain, M. Olabe, K. Espinosa, and C. R. J. C. Olabe, “Realidad Aumentada en la

Educación : una tecnología emergente,” Semana, no. 5, pp. 12–15, 2010.

[31] D. A. Redondo, “Realidad aumentada,” Univ. Carlos III Madrid, pp. 70–72, 2007.

[32] C. Prendes, “Experiencias Prácticas Augmented Reality and Education : Analysis of,” Pixel-


Bit. Rev. Medios y Educ. (46), 187-203., p. 187, 2015.

[33] C. Carrecedo, J., Martínez, “Realidad Aumentada: Una Alternativa Metodológica en la

Educación Primaria Nicaragüense,” Ieee-Rita, vol. 7, no. 2, pp. 102–108, 2012.

[34] J. Fombona Cadavieco, M. Á. Pascual Sevillano, and M. F. Madeira Ferreira Amador,

“Realidad aumentada, una evolución de las aplicaciones de los dispositivos móviles,” Píxel-

Bit. Rev. Medios y Educ., vol. 41, pp. 197–210, 2012.

[35] C. A. Reyes, “Realidad aumentada en las aulas de educación infantil : herramientas para el

aprendizaje,” no. 1994.

[36] P. A. Gutiérrez Bobadilla and S. V. Herrera Moreno, “MODELO DE EVALUACIÓN DE

USABILIDAD Y CORRESPONDENCIA DIDÁCTICA DE UN SOFTWARE LÚDICO.”

Bogotá, p. 154, 2013.

[37] M. Pérez, M. G. Diaz-Antón, A. Grimán, and L. E. Mendoza Morales, “Calidad Sistémica

del Software Educativo,” no. November, 2003.

[38] X. Arrieta, “Análisis y comparación de diversos modelos de evaluación de software

educativo Analysis and Comparison of Different Models of Educational Software

Evaluation,” no. 3, pp. 45–67, 2008.


ANEXOS

Anexo 1. Calidad del target

Protocolo_Seguridad_Contenidos_Jimenez_2020_Anexo1.pdf

Anexo 2. Configuración de QARK


Anexo 3. Plantilla de protocolo de calidad y seguridad


Anexo 4. Ejemplos






Protocolo de seguridad para contenidos de aprendizaje ...

Documents

Transcript of Protocolo de seguridad para contenidos de aprendizaje ...