DOCUMENTO DE ANALISIS POST-MORTEM

Ingeniería de Sistemas CIS1310SD03 DOCUMENTO DE ANALISIS POST-MORTEM El siguiente documento provee información sobre la comparación de lo escrito en la propuesta de Trabajo de Grado vs la realidad. RAUL CALERO ASENCIOS PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C. 2013

Contenido 1. Metodología propuesta vs. Metodología realmente usada... 3 2. Actividades propuestas vs. Actividades realizadas... 5 3. Efectividad en la estimación del proyecto... 6 4. Costo estimado vs. Costo real del proyecto... 8 5. Efectividad en la estimación y mitigación de los riesgos del proyecto... 9

1. Metodología propuesta vs. Metodología realmente usada FASE METODOLOGICA Identificación del problema y motivación Definición de los objetivos de la solución Diseño y desarrollo Demostración METODOLOGIA PROPUESTA Mediante búsquedas de información en bases de datos, journals y blogs de seguridad informática se abarcará el problema y se propiciará la motivación. Se realizará una organización de la información y la bibliografía, a partir de las bases de datos ISI, ACM, entre otras, con la ayuda de la herramienta Zotero. Las búsquedas tendrán como filtro el número de citas que tenga la revista o el autor, el año de publicación del artículo y las palabras clave de la investigación Se establecerá como característica principal de los objetivos que se van a formular, el modelo SMART: Specific (Específico) Measurable (Medible) Achievable (Alcanzable) Realistic (Retador) Timely (Temporal) Luego se definirá el alcance del proyecto con respecto a tiempo, recursos humanos y recursos físicos. Metodología de diseño de modelos a partir de arquitectura adaptado a la problemática, el cual cumple las siguientes fases: - Identificar y analizar los riesgos Lo que se va proteger, se identifican los riesgos en la arquitectura de la plataforma Android versión 4.1. - Definir las políticas de seguridad Lo que se puede o no se puede hacer, en este caso en la plataforma Android versión 4.1. - Diseñar la arquitectura Modificación de la arquitectura de la plataforma Android versión 4.1 con la adición de los principios de seguridad involucrados y los ataques en los componentes afectados. Como muchos de los ataques van a involucrar más de un componente, las pruebas se van a basar en dos aspectos: el METODOLOGIA EJECUTADA Se siguió la metodología propuesta. Se siguió la metodología propuesta. Se siguió la metodología propuesta. No se siguió la metodología propuesta.

Evaluación primero será una prueba de los ataques con el modelo de seguridad propuesto y sin este. Dichas pruebas estarán basadas en el tipo de Pruebas funcionales con una adaptación al proyecto. Es decir, mediante una herramienta de software se realizará la trazabilidad componente a componente de la arquitectura de la plataforma Android versión 4.1 identificando cuales se ven afectados por los ataques y los posibles casos en los que pueda fallar el modelo antes de usar la herramienta. Luego usando el modelo, se hará un informe para cada ataque que se realice, en el cual se especifiquen los componentes que el modelo encontró como afectados y los posibles principios de seguridad involucrados. Al final, se aplicará el método de Prueba de aceptación modificado para los desarrolladores (prueba beta), quienes registrarán los problemas o las utilidades del modelo propuesto. Metodología basada en: - Listas de chequeo - Encuestas Las listas de chequeo se basarán específicamente en el modelo de Construx Software Development Best Practices: CxOne Checklist en especial, en la lista de chequeo para arquitectura, pero con ligeras modificaciones. Estas listas se usarán para verificar que la arquitectura del modelo este bien definida y que los principios y/o componentes identificados concuerden con las pruebas de trazabilidad. Las encuestas estarán conformadas por preguntas abiertas y cerradas, se realizarán de forma personal a cada desarrollador y se concentrarán en la utilidad del modelo para Cambios: Se seleccionaron tres (3) ataques los cuales se probarían en el dispositivo y en el modelo para confrontar los componentes identificados en ambas pruebas. No se identificaron casos en los que el modelo pueda fallar. No se realizó la prueba beta con desarrolladores del modelo de seguridad. Si se realizó el informe por cada ataque donde se identificaron los componentes comprometidos a partir de los principios de seguridad. Se realizó algo adicional: sugerencias por cada capa y dependiendo de cada principio para mitigar los ataques. Se siguió con una parte de la metodología y la otra no se logró hacer. Se realizaron las listas de chequeo basadas en Construx checklist para arquitectura para verificar que la arquitectura del modelo estaba bien definida. Cambios: No se realizaron encuestas sobre la utilidad del modelo para desarrolladores.

Comunicación estos. La metodología para la comunicación y divulgación del trabajo se realizará por medio de un artículo científico que se pondrá a disposición de la comunidad académica. Se siguió la metodología propuesta. 2. Actividades propuestas vs. Actividades realizadas Se realizaron dos actividades adicionales, ambas en la fase de Demostración: - La primera, donde se realizaron sugerencias de mecanismos de seguridad por cada capa de la arquitectura del modelo dependiendo del principio que se vea afectado (teniendo en cuenta que los principios para el Trabajo de Grado eran: Integridad, Confidencialidad y Disponibilidad). - La segunda, donde al final de las pruebas funcionales y las pruebas sobre el modelo de seguridad de los ataques, se establecen sugerencias acerca de cómo mitigar los tres ataques realizados.

Ingeniería de Sistemas 3. Efectividad en la estimación del proyecto FASE METODOLOGICA ACTIVIDADES H.E E. H.R Identificación del Investigar acerca de los mecanismos de seguridad de los dispositivos móviles Android 5 SI 12 problema y motivación Investigar acerca de la arquitectura de la plataforma Android versión 4.1,sus componentes y la 8 SI 16 interacción entre estos. Clasificar los ataques basados en los tres principales principios de la seguridad de la información. 6 SI 6 Definición de los Redactar objetivos específicos tipo SMART a partir de la investigación hecha y el alcance planteado 8 SI 5 objetivos de la solución para el proyecto. Diseño y desarrollo Analizar la interacción de los ataques en los componentes de la plataforma Android versión 4.1. 10 SI 17 Investigar acerca de los modelos de seguridad existentes actualmente y sus características. 6 SI 4 Investigar acerca de la estructura y formulación de un modelo de seguridad. 8 SI 12 Desarrollo del modelo de seguridad: definir los ataques encontrados por cada componente, sus 12 SI 18 consecuencias y los principios que se ven afectados. Investigar acerca de las políticas de seguridad en la plataforma Android versión 4.1. 16 SI 30 Desarrollo del modelo de seguridad: definir las políticas de seguridad del modelo. 20 SI 35 Desarrollo del modelo de seguridad: elaborar la arquitectura del modelo de seguridad con 42 SI 56 componentes, ataques y principios involucrados. Pruebas Elegir dos ataques encontrados en la investigación para realizar las pruebas. 2 NO 2 Realizar pruebas de los dos ataques en los dispositivos móviles Android 4.1 de la Universidad 8 NO 18 Javeriana. Buscar herramientas de software para realizar la trazabilidad de los ataques. 10 SI 8 Hacer la trazabilidad de los componentes arquitectónicos de la plataforma afectados por el ataque 10 SI 22 mediante el uso de la herramienta encontrada. Probar el modelo de seguridad para dos ataques frente a desarrolladores expertos. 9 NO 0 Evaluación Preparar las encuestas sobre el uso del modelo de seguridad para los desarrolladores presentes en la 3 NO 0 demostración. Efectuar las encuestas y recolectar los resultados obtenidos. 2 NO 0 Realizar listas de chequeo con respecto al modelo de seguridad (principios y componentes 3 SI 6 identificados) y la trazabilidad de los ataques. Analizar los resultados de las encuestas, las listas de chequeo y elaborar conclusiones. 2 NO 2 Realizar correcciones al modelo de seguridad en caso de ser necesario. 12 SI 6 Comunicación Realizar documentación del proyecto de investigación por medio de un artículo formato ACM. 14 SI 14 TOTAL HORAS 216

De la tabla anterior se obtiene la siguiente información: - H.E / E. / H.R significan respectivamente: Horas estimadas / Ejecutado y Horas reales - Las actividades en color - Las actividades enmarcadas en rojo, son actividades que no se realizaron, pero que en su lugar se realizaron otras. Por ejemplo, en la primera actividad de la fase de pruebas dice que no se realizó porque no se eligieron dos ataques sino tres para las pruebas. En la segunda actividad de esta fase de Pruebas (que está en rojo), no se probaron dos ataques en el dispositivo móvil de la Universidad, sino tres (es por esto que las horas suben de 8 a 18) - Las actividades enmarcadas en amarillo, fueron las que definitivamente no se realizaron - La actividad enmarcada en rojo de la fase de evaluación, no significa que no se haya realizado, sino que no se tuvieron en cuenta resultados de las encuestas, ya que estas nunca se realizaron De esa misma tabla se obtiene que: FASE METODOLOGICA TOTAL DE HORAS ESTIMADAS TOTAL DE HORAS REALES DIFERENCIA Identificación del problema y 19 34-15 motivación Definición de los objetivos de la 8 5 3 solución Diseño y desarrollo 114 172-58 Pruebas 39 50-11 Evaluación 22 14 8 Comunicación 14 14 0 TOTAL HORAS PARA DESARROLLAR EL TG 216 289-73 Los principales motivos por los que existe una diferencia de 73 horas entre las horas estimadas y las horas reales son: - La mala estimación para el desarrollo de la arquitectura del modelo de seguridad. - La disponibilidad de información en cuanto a políticas de seguridad de la plataforma y ataques.

Ingeniería de Sistemas 4. Costo estimado vs. Costo real del proyecto El costo que se estimó en la propuesta de Trabajo de Grado fue el siguiente: Recursos Físicos Dispositivos móviles Android 0 INTERNET 4MB S/. 15,000 Papel ALTA BLANCURA MULTIPROPOSITO PANAMERICANA - TAMAÑO CARTA S/. 6,300 TINTA IMPRESORA S/. 35,000 ELECTRICIDAD S/. 20,700 Tiempo SALARIO RECIEN GRADUADO JAVERIANO S/. 2,914,830 Recursos Humanos SALARIO DIRECTOR TRABAJO GRADO S/. 1,350,000 TOTAL S/. 4,341,830 Teniendo en cuenta la estimación de tiempo del capítulo anterior, en donde mis horas de trabajo pasan de 216 a 289, el costo real del proyecto sería: - 1 día equivale a 8 horas de trabajo - En un mes (teniendo en cuenta que aproximadamente un mes tiene 30 días) se trabajan 240 horas - En 240 horas, el salario mínimo de un Ingeniero de Sistemas es de $3 238 700 pesos - En 289 horas de trabajo, el salario pasa a ser $3 899 934 pesos Con respecto a los recursos físicos hubo dos cambios: - Con respecto al consumo de Internet, en donde el precio normal de uso de Internet en un mes (720 horas) es de $50.000 pesos, teniendo en cuenta que la cantidad de horas empleadas para el proyecto cambia de 216 a 289, para 289 horas el valor del Internet de 4MB sube a $20.069 pesos - Con respecto a la electricidad en donde el nuevo costo teniendo en cuenta las horas, ahora va ser de $27.695 pesos

Sumando todo lo anterior, el costo real del proyecto es: Dispositivos móviles Android 0 INTERNET 4MB S/. 20,069 Recursos Físicos Papel ALTA BLANCURA MULTIPROPOSITO PANAMERICANA - TAMAÑO CARTA S/. 6,300 TINTA IMPRESORA S/. 35,000 ELECTRICIDAD (consumo promedio mensual) S/. 27,695 Tiempo SALARIO RECIEN GRADUADO JAVERIANO S/. 3,899,934 Recursos Humanos SALARIO DIRECTOR TRABAJO GRADO S/. 1,350,000 TOTAL S/. 5,338,998 Lo que concluye que el Trabajo de Grado hubiese costado más de lo esperado. 5. Efectividad en la estimación y mitigación de los riesgos del proyecto Se acertó en lo siguiente: RIESGO PROBABILIDAD ESTRATEGIA 4 Agregar tiempo extra para la actividad cuando suceda esto, aparte de las 12 horas semanales. El tiempo para desarrollar una actividad dura más que lo programado en el cronograma. Se estimó que era muy probable que el tiempo para desarrollar una actividad dure más de lo programado, lo cual se logra evidenciar en la diferencia de 216 a 289 horas de trabajo y se acertó en la estrategia del tiempo extra. RIESGO PROBABILIDAD ESTRATEGIA 3 Establecer un porcentaje de error del modelo con respecto a su finalidad. El modelo no identifica todos los componentes afectados por los ataques. Se estimó que el modelo tenía una probabilidad moderada de no identificar todos los componentes afectados por los ataques, lo cual sucede y se corrobora con las pruebas funcionales de dichos ataques.

Los dispositivos móviles establecidos para las pruebas no se encuentran disponibles. Documento de Trabajo de Grado - <Proyecto de investigación> RIESGO PROBABILIDAD ESTRATEGIA 2 Contactar personas con dispositivos móviles Android versión 4.1 para un posible préstamo. Se estimó que era poco probable que los dispositivos móviles establecidos para las pruebas no estén disponibles, lo cual sucedió ya que dichos dispositivos estuvieron siempre a disposición del proyecto. Se falló en lo siguiente: RIESGO PROBABILIDAD ESTRATEGIA 1 Realizar la actualización del sistema operativo de los dispositivos móviles con permiso de la Facultad de Ingeniería de Sistemas. Los dispositivos móviles establecidos para las pruebas no poseen la versión del sistema operativo especificado para estas. Se estimó que era raro que los dispositivos móviles establecidos para las pruebas no posean la versión del sistema operativo especificado, lo cual si sucedió porque estos dispositivos que posee la Pontificia Universidad Javeriana tienen la versión 4.0.4 del sistema operativo. Pero la estrategia si se llevó a cabo, pues se realizó un root del dispositivo y una actualización a Android Jelly Bean 4.1