PROPUESTA PARA TRABAJO DE GRADO

Transcripción

1 PROPUESTA PARA TRABAJO DE GRADO TÍTULO Analizador Estático de Código para Políticas de Control de Acceso MODALIDAD Aplicación Práctica OBJETIVO GENERAL Desarrollar una herramienta de Software que permita asegurar la consistencia entre modelos de control de acceso y el código que los implementa en un proyecto con Round-trip Engineering. ESTUDIANTE(S) Ariel Arturo López Lesmes Documento Celular Teléfono fijo Correo Javeriano cc ariel.lopez@javeriana.edu.co DIRECTOR Ing. Jaime Andres Pavlich Mariscal Documento Celular Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo cc Ext. jpavlich@javeriana.edu.co Pontificia Universidad 4731 Javeriana; Profesor Departamento de Sistemas 1

2 Contenido 1 OPORTUNIDAD O PROBLEMÁTICA DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA FORMULACIÓN JUSTIFICACIÓN IMPACTO ESPERADO DEL PROYECTO IMPACTO AMBIENTAL IMPACTO SOCIAL IMPACTO TECNOLÓGICO 6 2 DESCRIPCIÓN DEL PROYECTO OBJETIVO GENERAL FASES METODOLÓGICAS Y OBJETIVOS ESPECÍFICOS FASE DE INVESTIGACIÓN FASE DE DESARROLLO FASE DE VALIDACIÓN 7 3 ENTREGABLES O RESULTADOS ESPERADOS ENTREGABLES O RESULTADOS ESPERADOS 8 4 PROCESO FASE DE INVESTIGACIÓN METODOLOGÍA ACTIVIDADES FASE DE DESARROLLO METODOLOGÍA ACTIVIDADES FASE DE VALIDACIÓN METODOLOGÍA ACTIVIDADES 13 5 GESTIÓN DEL PROYECTO ESTIMACIÓN DE LA DURACIÓN DEL PROYECTO ESTIMACIÓN DEL COSTO DEL PROYECTO ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO 18 6 MARCO TEÓRICO / ESTADO DEL ARTE TRABAJOS IMPORTANTES EN EL ÁREA FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO EXPERIENCIAS PREVIAS 26 2

3 7 REFERENCIAS Y BIBLIOGRAFÍA REFERENCIAS BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO 29 3

4 1 Oportunidad o Problemática 1.1 Descripción de la Oportunidad o Problemática En el proceso de desarrollo de software es importante garantizar que los requerimientos de seguridad son tenidos en cuenta desde el inicio, para asegurar que el producto, una vez terminado, cumple con las restricciones de seguridad requeridas por los stakeholders. En particular, cuando hablamos de control de acceso, Limitar el acceso a los recursos de los sistemas de información sólo a usuarios, programas, procesos u otros sistemas autorizados [3], es importante garantizar que los requerimientos de este tipo son tenidos en cuenta a lo largo del proceso de desarrollo, evitando que una vez implementados los requerimientos funcionales, sea después difícil, costoso o hasta imposible implementar los requerimientos de control de acceso[4]. Una de las mejores formas de combatir la complejidad del proceso de desarrollo de software, es a través del uso de la abstracción y la descomposición del problema que se intenta solucionar [1]. El desarrollo dirigido por modelos (Model Driven Development), en adelante MDD, se basa precisamente en eso, consiste en la aplicación de modelos para elevar el nivel de abstracción a un nivel en el que el desarrollador pueda construir fácilmente la aplicación [2]. El desarrollo dirigido por modelos permite generar relaciones entre diferentes modelos, y a partir de estos, generar artefactos con un mayor o menor nivel de abstracción[2]. Utilizando el enfoque de MDD podemos lograr un acercamiento a la resolución del problema anteriormente mencionado. Es posible incluir, a través de diferentes modelos, los requerimientos de control de acceso y los requerimientos funcionales al inicio del proceso de desarrollo, y generar a partir de ellos el código que los implementa correctamente [5]. Uno de los problemas asociados a este enfoque es el de Round-Trip Engineering, en adelante RTE, el cual ocurre cuando uno de dos artefactos interrelacionados es modificado de tal forma que afecta el estado del otro [2]. El caso critico de este problema se presenta cuando los cambios ocurren en un artefacto con un nivel bajo de abstracción que está relacionado con uno de alto nivel de abstracción[2]. Por ejemplo, es mayor la dificultad de reflejar los cambios de código (artefacto de bajo nivel de abstracción) a modelos (artefacto de alto nivel de abstracción) que de modelos a código. Una de las razones es que cuando el proceso involucra tecnologías de trasformación, los cambios en el código pueden perderse una vez se realice la generación de los modelos, esto puede deberse a que las tecnologías de transformación generan nombres de variables inadecuados y pueden modificar, reordenar o eliminar detalles que pueden ser útiles para el programador pero no necesariamente para una maquina [2]. Este problema afecta directamente la solución propuesta anteriormente, ya que se debe permitir que el código generado a partir de los modelos pueda ser modificado, garantizándose la consistencia entre ese código y los modelos. Mantener esta consistencia permite realizar futuras iteraciones en el proceso de desarrollo, garantizando que los requerimientos de control de acceso se tienen en cuenta a medida que se implementan los requerimientos funcionales. 4

5 1.2 Formulación Cómo implementar una herramienta de Software que asegure la consistencia entre los modelos de control de acceso y el código que los implementa en un proyecto con Round-Trip Engineering? 1.3 Justificación En cuanto más temprano encontremos errores, más fácil es repararlos. Lo ideal sería darnos cuenta de los error inmediatamente los cometemos o tan pronto como sea posible, y no cuando hacemos pruebas o revisiones muchos después de que se han cometido [12]. Si en el proceso de desarrollo se tuviera a disposición una herramienta de software que realice un análisis de los cambios efectuados en el código del proyecto y determine si dichos cambios son consistentes con los modelos de control de acceso previamente definidos, permitiría a los desarrolladores tener un mecanismos de verificación, asegurándoles que los requerimientos de control de acceso se mantienen a medida que se avanza en las iteraciones del proceso de desarrollo, dando como resultado, que la aplicación desarrollada implementa correctamente los requerimientos de control de acceso desde el inicio hasta su versión final. Tener un mecanismo de validación entre código y modelos, permite garantizar que los cambios que se propagarán a los modelos cumplen con las restricciones de seguridad definidas previamente, esto permite que en la siguiente iteración de proceso de desarrollo las políticas de control de acceso estén correctamente implementadas a pesar de los cambios realizados en el código y el continuo paso de iteraciones. 1.4 Impacto Esperado del Proyecto impacto Ambiental Al ser este un proyecto de desarrollo de software, cuyo objetivo final es entregar una herramienta de software (intangible), se considera que no existe un impacto ambiental más allá del consumo de energía de los computadores, el papel y los servicios públicos que sean necesario usar en el desarrollo el proyecto. El producto final no beneficiará ni perjudicará el medio ambiente de ninguna forma Impacto Social Al ser este un proyecto de desarrollo de software, con el que se intentan resolver aspectos netamente técnicos, no se espera ningún impacto social directo. Sin embargo, este proyecto intenta que los requerimientos de control de acceso tengan un mecanismo de validación a lo largo del proceso de 5

6 desarrollo de software, garantizando que la aplicación construida cumpla con las restricciones de seguridad a nivel de control de acceso que se definieron inicialmente. Esto permite que las aplicaciones construidas sean mucho más seguras, mejorando la privacidad y confidencialidad de la información de las personas u organizaciones que las utilizan Impacto tecnológico Este proyecto tendrá un impacto considerable en el ámbito tecnológico. Dicho impacto será visible en el proceso de desarrollo de software, ya que los desarrolladores tendrán un herramienta de software (analizador estático de código) que en tiempo de desarrollo, a medida que realicen cambios en el código, les indique si existen inconsistencias entre ese código y los modelos de control de acceso relacionados. La herramienta permitirá que el desarrollador realice cambios en el código que no violen las políticas de control de acceso definidas en los modelos, garantizando que la aplicación alcance los niveles de seguridad esperados. Contar con una herramienta de este tipo sería un paso inicial para solucionar el problema de RTE asociado con MDA [2], ya que se podría empezar a generalizar la aplicación de la herramienta desde control de acceso a otro tipo de concerns. Cabe aclarar que esta generalización es posible ya este proyecto se encuentra enmarcado en el desarrollo de un framework que mejore las capacidades de RTE de los generadores de código para asegurar la consistencia de las políticas de control de acceso tanto en código como en los modelos, de acá en adelante SARE [8]. Luego, si se quisiera generalizar la aplicación a otros concerns, se necesitará generalizar de igual forma el uso de SARE. 6

7 2 Descripción del Proyecto 2.1 Objetivo general Desarrollar una herramienta de Software que permita asegurar la consistencia entre modelos de control de acceso y el código que los implementa en un proyecto con Round-Trip Engineering. 2.2 Fases Metodológicas y Objetivos Específicos En esta sección se especifican las fases metodológicas propuestas para el desarrollo del trabajo. Además de las fases metodológicas, se relacionan los objetivos específicos que se espera queden completados en cada una de las fases propuestas Fase de investigación. 1. Analizar las plataformas de desarrollo y las herramientas existentes para determinar cuáles serán usadas en el desarrollo de la herramienta. Se presentará un documento donde se muestre este análisis Fase de desarrollo. 2. Definir los requerimientos que debe implementar la herramienta a través de un Software Requirements Specification (SRS). 3. Especificar el diseño de la herramienta a través de un Software Design Description (SDD). 4. Desarrollar un prototipo de la herramienta Fase de validación 5. Validar la herramienta a través de un caso de estudio. 7

8 3 Entregables o Resultados Esperados 3.1 Entregables o Resultados Esperados Los entregables de este proyecto serán los propios de un proyecto de desarrollo de software junto con los requeridos para el trabajo de grado: Documento donde se especifiquen los requerimiento de la herramienta. Adaptación de Software Requirements Specification (SRS), según estándar IEEE Std Documento donde se especifica el diseño de la herramienta. Adaptación de Software Design Description (SDD), según estándar IEEE Std Prototipo de la herramienta. Se entregará el código fuente así como la documentación asociada. Caso de estudio (proyecto de desarrollo de software con la aplicación de la herramienta). Se incluirá código fuente de este proyecto con la documentación asociada. Memoria del trabajo de grado. Página web con la publicación de todos los entregables definidos en los puntos anteriores. 8

9 4 Proceso Por ser un proyecto de aplicación práctica, para el cual, el desarrollo de divide en fases claramente demarcadas, se adoptarán diferentes metodologías dependiendo del objetivo y los resultados esperados en cada fase del proyecto. Dentro de cada fase se espera cumplir uno o más objetivos específicos. Se han identificado las siguientes fases: 4.1 Fase de Investigación Metodología En esta fase se realizará una revisión de la bibliografía con fin de recopilar información que permita establecer bases sólidas para el desarrollo de la herramienta. A partir de dicha revisión, se espera además, analizar el aporte de otras investigaciones al tema de estudio para determinar puntos de partida, reutilización de artefactos y selección de las tecnologías que mejor soporten el desarrollo de la aplicación. Esta fase se desarrollará siguiendo una metodología de tipo especulativa, en la que se pretende analizar la mayor cantidad de bibliografía y sintetizarla en las bases teóricas del proyecto Actividades En la fase de investigación se desarrollara el primer objetivo específico, analizar las plataformas de desarrollo y las herramientas existentes para determinar cuáles serán usadas en el desarrollo de la herramienta. Se presentara una documento donde se muestre este análisis. Para esto se realizaran dos grupos de actividades la primer es Consultar, analizar y documentar en un marco teórico, la bibliografía en temas de control de acceso y desarrollo dirigido por modelos, así como cualquier otro concepto importante para el desarrollo de la propuesta. La segunda es consultar, analizar y documentar en un estado del arte, los trabajos de investigación existentes relacionados con esta propuesta, definiendo similitudes, diferencias y posibles mejoras. Las actividades para cumplir este objetivo son: 1. Construir una base de datos bibliográfica: Se incluirá bibliografía en temas de control de acceso basado en roles, desarrollo dirigido por modelos, Round-Trip Engineering, análisis estático de código y cualquier otro tema importante que se descubra a medida que se avanza en el desarrollo de proyecto. 2. Encontrar el material bibliográfico más significativo: Realizar una lectura rápida sobre los elementos de la base de datos bibliográfica y determinar cuáles son los de mayor impacto para el proyecto. 3. Realizar resumen de bibliografía significativa: Leer en detalle los artículos seleccionados en la actividad anterior y hacer un resumen de su contenido, determinando en que puntos es importante o influye en el desarrollo del proyecto. 9

10 4. Construcción de marco teórico: Tomar los resumes desarrollados en la actividad anterior, sintetizar su contenido y escribir un marco teórico para el proyecto. 5. Identificar trabajos relacionados: Realizar una búsqueda de los trabajos o herramientas de software que tengan alguna característica en común con la herramienta que se propone desarrollar en este proyecto. 6. Análisis de las características comunes con otros trabajos encontrados: Realizar un análisis de los trabajos encontrados en la actividad anterior, identificando similitudes, diferencias y mejoras propuestas. 7. Identificar plataformas de desarrollo: Realizar un búsqueda de las plataformas de desarrollo disponibles y seleccionar la más adecuada para la ejecución del proyecto. 8. Construcción del estado del arte: El estado del arte se construirá a partir del análisis realizado en la actividad anterior, identificando qué cosas (conceptos, algoritmos, estrategias, etc.) se van a incorporar al proyecto, cómo se van a mejorar otras y cuales no se tendrán en cuenta. 4.2 Fase de desarrollo Metodología Como se indicó en la sección de impacto tecnológico, el proyecto descrito en esta propuesta se encuentra enmarcado en el proyecto SARE [8]. En SARE se ha adoptado la metodología de desarrollo ágil de software SCRUM [6], por ende la fase de desarrollo de este proyecto también será guiada según esta metodología. A pesar de que en SCRUM, la fase de desarrollo es un proceso empírico, en el cual, muchos de sus procesos internos no están definidos y los entregables pueden ir cambiando conforme lo dicta el entorno y el mismo proceso de desarrollo [6], se definieron ciertos entregables y actividades obligatorias para esta fase. Es preciso aclarar que las actividades de esta fase serán realizadas adoptando una visión BLACK BOX del proceso de desarrollo, donde algunas actividades pueden ser desarrolladas en forma secuencial, otras de forma iterativa y otras de forma incremental [6]. La fase de desarrollo será caracterizada por la flexibilidad en el contenido y las fechas de entregas de cada release, desarrollo individual, revisión continua (cada semana) y alta colaboración externa. Cabe resaltar que con flexibilidad en el contenido, se quiere decir que el release puede estar incompleto o estar mucho más avanzado de lo requerido. Con flexibilidad en el tiempo de entrega se quiere decir que el release puede ser presentado antes de lo previsto o después de lo previsto, todo depende de su complejidad y su extensión. 10

11 La fase de desarrollo se dividirá en dos subfases, la fase de planeación y la fase Sprint. Dentro de cada una de estas fases se espera cubrir completa o parcialmente algunos objetivos, para lo cual se adoptarán las siguientes practicas propias de la metodología SCRUM [6]: Fase de planeación (pre-game): Selección del release más apropiado para desarrollo inmediato. Definición de fecha de entrega de cada release. Continua evaluación y control de riesgos. Identificar cualquier dificultad en el desarrollo o implementación. Definir reuniones de revisión. Fase Sprint (game): Sprint iterativo hasta que se alcance el desarrollo de la herramienta. Sprint de duración de una semana máximo dos. Revisión del sprint correspondiente. o Revisión del trabajo realizado en el sprint. o Asignación de tareas para el siguiente sprint. o Asignación de siguiente revisión Actividades Dentro de la fase de planeación se espera cumplir el objetivo de definir los requerimientos que debe implementar la herramienta a través de un Software Requirements Specification (SRS), es preciso aclarar que el SRS que se defina será una versión adaptada y reducida del estándar IEEE Std Las actividades para cumplir este objetivo son: 1. Determinar estrategia de clasificación, obtención y especificación de requerimientos. 2. Identificar y especificar requerimientos funcionales. 3. Identificar y especificar requerimientos no funcionales. 4. Validar requerimientos con el director del proyecto: Se presentará una primera versión de los requerimientos de la herramienta a desarrollar al director del proyecto. Se realizarán las correcciones pertinentes según la retroalimentación obtenida. 5. Construir el Software Requirements Specification: Se construirá una primera versión completa de la especificación de requerimientos siguiendo el estándar IEEE Std Se debe tener en cuenta que a medida que avanza el proyecto se pueden agregar, eliminar o modificar requerimientos. a través de las siguientes actividades. Otro de los objetivos que se espera cumplir dentro de la fase Sprint es el de Definir el diseño del sistema a través de un Software Design Description (SDD), es preciso aclarar que el SDD que se 11

12 defina será una versión adaptada y reducida del estándar IEEE Std Las actividades para cumplir este objetivo son: 6. Diseñar la arquitectura de la herramienta: Identificar componentes a desarrollar, componentes reutilizables y su relación. Como mínimo se realizará un diagrama de componentes. 7. Realizar el diseño de la herramienta: se harán los diagramas de estructura y de comportamiento que se consideren necesarios. Como mínimo se realizara un diagrama de clases y diagramas de secuencia. 8. Validar la arquitectura y el diseño de la herramienta con el director el proyecto: Se presentarán los diagramas desarrollados al director del proyecto y se realizarán las correcciones pertinentes según la retroalimentación obtenida. 9. Construir el Software Design Description: Se construirá una primera versión completa de la especificación del diseño de la herramienta siguiendo el estándar IEEE Std Se debe tener en cuenta que a medida que avanza el proyecto se puede refinar el diseño propuesto. El último objetivo de que se espera cumplir en esta fase SCRUM de desarrollo es el de desarrollar un prototipo de la herramienta. Dentro de esta fase se espera además desarrollar actividades típicas del proceso de desarrollo de software como el desarrollo y aplicación de casos de pruebas y la documentación completa de la herramienta. Las actividades para cumplir este objetivo son: 10. Construir prototipo inicial. 11. Construcción de casos de prueba: Se construirán los casos de prueba para mostrar el correcto o incorrecto funcionamiento de la herramienta. 12. Aplicación de casos de prueba: Se aplicarán los casos de prueba desarrollados en la actividad anterior y se documentarán los resultados obtenidos. 13. Refinamiento del prototipo: Se tomarán los resultados de la aplicación de los casos de prueba y se realizarán las correcciones y mejoras necesarias al prototipo inicial para construir una primera versión estable de la herramienta. 14. Documentación y manuales de uso: Se hará la documentación completa de la herramienta, especificando los requerimientos de instalación, manual de instalación y manual de uso. 12

13 4.3 Fase de validación Metodología En la fase de validación se identificará un caso de estudio que tenga las características necesarias para demostrar el correcto funcionamiento y aplicación de la herramienta a un problema de la vida real. Se utilizará una metodología de tipo inductivo en la que se buscará generalizar la aplicación de la herramienta a cualquier proyecto de software que cumpla con las características definidas para el uso de la herramienta. En esta fase se espera cumplir el objetivo de validación de la herramienta desarrollada. Para esto se identificara un caso de estudio y se Aplicación de la herramienta al caso de estudio. Los elementos a validar en el caso de estudio son, esencialmente, aquellos relacionados con el aseguramiento de la consistencia entre modelos y código a lo largo del procesos de desarrollo. Se utilizará el OWASP Application Security Verification Standard, específicamente el área de requerimientos V4 de control de acceso, para validar la aplicación de la herramientas [7]. En caso de ser necesario, se harán las correcciones pertinentes a la herramienta según lo muestren los resultados de la aplicación del OWASP-ASVS al caso de estudio Actividades Dentro de la fase de validación se espera cumplir el objetivo de Validar la herramienta a través de un caso de estudio. Las actividades para cumplir este objetivo son: 1. Identificar caso de estudio: Seleccionar un caso de estudio que tenga las características necesarias y suficientes para la demostración del correcto funcionamiento de la herramienta. 2. Identificar requerimientos funcionales y no funcionales: identificar los requerimientos del proyecto de desarrollo que involucra el caso de estudio. Se delimitara el alcance del desarrollo según sea necesario, garantizando que sea suficiente para la validación de la herramienta. 3. Identificar requerimientos de control de acceso: Identificar las políticas de control de acceso que se debe cumplir desde el inicio hasta el final del proceso de desarrollo del caso de estudio. 4. Preparación del entorno de desarrollo: Se requiere de por lo menos dos herramientas de software para la correcta aplicación de la herramienta desarrollada al caso de estudio [8]. Se configurará y adecuara el entorno de desarrollo para el caso de estudio. 5. Aplicación de la herramienta al caso de estudio: Se ejecutará un proyecto de desarrollo utilizando la herramienta como mecanismo de aseguramiento de consistencia entre modelos de control de acceso y código. 13

14 6. Evaluación de la correcta implementación de los requerimientos de control de acceso: Una vez terminado el desarrollo del caso de estudio se hará una validación de la implementación de los requerimientos de control de acceso según OWASP-ASVS V4. 7. Corrección de la herramienta: De ser necesario se harán correcciones a la herramienta según lo dicte los resultados de la aplicación al caso de estudio. 8. Documentación del caso de estudio: Se documentará la aplicación de la herramienta al caso de estudio, especificando los resultados y las conclusiones. 9. Elaboración de la memoria del trabajo de grado: Se elaborará el documento con la descripción de todo el trabajo realizado. 10. Elaboración de página web con los resultados del proyecto: En esta página web estarán disponibles todos los documentos y resultados del trabajo realizado. 14

15 5 Gestión del Proyecto 5.1 Estimación de la duración del Proyecto A pesar de que el proyecto debe ser desarrollado en 19 semanas contadas a partir del 23 de Julio de 2012 hasta el 7 de diciembre de 2012, se plantea adicionar 4 semanas más, contadas a partir del 25 de Junio, con el objetivo de cubrir a cabalidad las actividades propuestas y garantizar el desarrollo del completo del proyecto. En la siguiente figura se ilustra una distribución de las actividades definidas para el desarrollo del proyecto en función del tiempo. Las fases están diferenciadas por colores, siento el color azul la fase de investigación, el color verde la fase de desarrollo y el color rojo la fase de validación. Ilustración 1: Cronograma Se espera dedicar 10 horas semanales de trabajo para el desarrollo del proyecto entre las semanas 1 a la 4. Entre las semanas 5 a 23 se espera dedicar 25 horas a la semana al desarrollo del proyecto. Esto nos da una total de 23 semanas, es decir 475 horas de trabajo. Se eliminan 25 horas por la semana de receso y 20 horas por días festivos. 5.2 Estimación del costo del Proyecto Para el desarrollo del proyecto se hace necesario contar con diferentes recursos: personas, computadores, libros que sirvan como soporte al desarrollo del proyecto, servicios como internet y electricidad. Estos recursos ayudan a mejorar el conocimiento del problema y soportan el desarrollo del proyecto. 15

16 Después de un análisis de la naturaleza del proyecto y los factores que pueden incidir en su desarrollo, se determinó que los siguientes recursos son necesarios para lograr los objetivos planteados: Recursos humanos : Se necesitan 475 horas de trabajo del estudiante. Se necesitan 40 horas de trabajo del director del proyecto. Recursos físicos: Se necesita un computador en el cual se desarrollara el proyecto. Se necesita un lugar para el desarrollo del proyecto. Se necesita pagar un monto por los derechos de cursar la asignatura Trabajo de grado. Se necesita desplazarse a la universidad una vez a la semana a una reunión con el director. Servicios: Se necesita servicios de electricidad. Se necesitan servicios de conexión a internet. Servicio de biblioteca. En las siguientes tablas se presenta una cuantificación de los recursos necesarios para el desarrollo del proyecto. RECURSOS HUMANOS RECURSO CANTIDAD / UNIDAD VALOR POR HORA VALOR TOTAL Hora de trabajo del director del proyecto Hora de trabajo del estudiante 40 horas horas Desplazamientos 36 viajes

17 Como recurso principal de trabajo se cuenta con una maquina MACBOOK PRO con procesador 2,3 GHz Intel Core i5 y 4GB de memoria. Se utilizó el método de depreciación en line recta como se muestre en el siguiente cuadro. Depreciación por línea recta Valor del activo ,00 Vida útil (Años) 5,00 Año Cuota depreciación Depreciación acumulada Valor neto en libros , , , , , , , , , , , , , ,00 - Como se aprecia en el cuadro anterior, la depreciación anual de la maquina es de $ COP. El resumen de los recursos físicos necesarios para el desarrollo del proyecto se muestra en la siguiente tabla. RECURSOS FÍSICO RECURSO CANTIDAD / UNIDAD VALOR POR UNIDAD VALOR TOTAL Computador 6 meses Lugar de trabajo 515 horas 0 0 Valor de la asignatura Trabajo de grado 4 créditos RECURSO CANTIDAD / UNIDAD SERVICIOS VALOR POR UNIDAD VALOR TOTAL Electricidad 6 meses

18 Internet 6 meses Biblioteca 6 meses 0 0 Se estima que para el desarrollo del proyecto se necesitan $ COP con los cuales se cubrirán o adquirirán los recursos necesarios para cumplir con los objetivos trazados en este proyecto. 5.3 Estimación de los riesgos del Proyecto Debido a la complejidad del proyecto, los riesgos son una parte muy importante que se deben tener en cuenta continuamente para garantizar el cumplimiento de los objetivos definidos. Con el uso de la metodología SCRUM se da prioridad al análisis de los riesgos para reducir la probabilidad y el impacto de hechos adversos en el desarrollo del proyecto. Esto se logra haciendo que el análisis de riesgos sea parte del proceso diario de desarrollo a través de las reuniones de planeación y revisión. Además, se tomarán practicas propias de la metodología como el uso de una tablero donde se pondrán los eventos adversos que podrían presentarse en determinadas situaciones. El manejo de riesgos se hará en una seria de pasos: Identificación de riesgos: se realizará en las reuniones de revisión junto con el director. Además se dedicarán 5 minutos al inicio de cada sesión de trabajo para plasmar en el tablero los riesgo que se consideren relevantes en la actividad que se está desarrollando. Análisis: si el riesgo se considera de alto impacto se discutirá a la mayor brevedad con el director del proyecto para poder tomar las decisiones pertinentes. El tener ciclos de desarrollo de máximo una semana, facilita tener un control sobre estas situaciones y no permitir que tengan un impacto considerable sobre las actividades que se desarrollan. Control y monitoreo: una vez identificado y analizado el riesgo, se empezara a hacer un seguimiento a través del tablero, identificando el estado de la situación y si es necesario tomar acciones inmediatas. Si el riesgo se considera superado o muy poco probable de aparecer se procederá retíralo del tablero. El tablero será el mecanismo para mantener presente los aspectos de considerable cuidado en cada actividad de desarrollo. Este mecanismo hará que siempre se tengan en mente los factores de riesgo reduciendo la probabilidad de que un descuido los haga aparecer. Aunque el proyecto no se ha iniciado, ya se pueden enunciar algunos de los factores que podrán llegar a tener un impacto negativo en el desarrollo del proyecto y que requerirán especial atención y seguimiento a lo largo de este. 18

19 Riesgos técnicos Cambios no esperados en el proceso de desarrollo. Errores en la selección de alguna tecnología de soporte. Complejidad en el aprendizaje de alguna tecnología de soporte. Metas muy grandes para cada iteración. No contar con las tecnologías de las que se depende para la validación de la herramienta. Perdida de información por daño en alguna máquina. Riesgos Administrativos Riesgos internos Mala planeación de cada iteración. Revisiones o controles demasiados flexibles. Mala estimación de recursos, en especial del tiempo. Mala distribución del tiempo Falta de compromiso con el proyecto Agenda apretada del director del trabajo Riesgos externos Malas condiciones de salud Asuntos familiares Manifestaciones que afecten el desplazamiento. Una vez identificados los riegos iniciales se propone una priorización con fin de determinar cuáles son los que representan un mayor impacto para el proyecto, permitiendo tener especial atención en cada actividad del proyecto. Se usa una priorización sencilla determinando si su impacto es bajo, medio o alto. Se especificará por qué se considera de esta forma y como se pretende mitigar ese impacto Cambios no esperados en el proceso de desarrollo. o Impacto: medio o Razón: adoptar la metodología SCRUM hace que el proceso de desarrollo sea flexible y se considere este aspecto a menudo. o A través de reuniones de planeación y revisión semanales se espera controlar este tipo de situaciones, permitiendo actuar rápidamente en respuesta a cualquier indicio de aparición de este riesgo 19

20 Errores en la selección de alguna tecnología de soporte. o Impacto: alto o Razón: concluir que se seleccionó inadecuadamente una tecnología de soporte en una etapa avanzada del proyecto puede traer consecuencias de alto impacto. Se podría haber perdido mucho tiempo y no llegar a completar las actividades planteadas. o Se mitigará a través de un análisis detallado y cuidadoso de las tecnologías de soporte cuando esto sea necesario. En este análisis se espera tener una alta participación del director del proyecto, quien con su experiencia podrá guiar el proceso de selección de herramientas de una forma satisfactoria. De ser necesario se acudirá a consultoría externa con el profesor del departamento de ingeniería de sistemas que se considera puede aportar en la toma de la decisión. Complejidad en el aprendizaje de alguna tecnología de soporte. o Impacto: bajo o Razón: se espera que el aprendizaje de cada herramienta no sea fácil. Se dedicará el tiempo suficiente para esta actividad. o Escoger tecnologías con un adecuado nivel de documentación servirá para mitigar este riesgo. De igual forma se espera que esta situación se presente continuamente, debido a esto, se dedicará el tiempo suficiente para aprender a usar cada tecnología necesaria. Metas muy grandes para cada iteración. o Impacto: bajo o Razón: por trabajos previos con el director de proyecto, se cuenta con la experiencia suficiente para determinar la cantidad de trabajo que se puede realizar para cada revisión. o Este riesgo se mitigará a través de acuerdos de parte y parte. Se expresará la cantidad de trabajo que se considera se puede realizar en comparación de la asignación que hace el director. No contar con las tecnologías de las que se depende para la validación de la herramienta. o Impacto: alto o Razón: para la fase de validación de la herramienta en construcción se necesita de dos herramientas más. La primera es un generador de código, el cual para la fecha en que se escribe esta propuesta ya se encuentra prácticamente terminado. La segunda es un generador de ingeniería reversa el cual no se ha empezado a desarrollar. El punto crítico es que dicho generador inverso es realizado por el mismo estudiante y director de la presente propuesta. o Se dispondrá del mes de Junio y Julio para el desarrollo de dicha herramienta faltante, para ello se dedica alrededor de 6 horas diarias 6 días por semana para avanzar lo mas que se pueda y no perjudicar la fase de validación de este proyecto. Perdida de información por daño en alguna máquina. 20

21 o o o Impacto: alto Razón: perder información implica retrasar el progreso del proyecto y hacer nuevamente actividades que ya se habían terminado. Se usará SVN [10] como mecanismo de control de versiones de código. Y Dropbox[9] como mecanismo de administración de documentos. Esto implica que la información del proyecto no estará en un único equipo, garantizado que la probabilidad de que este riesgo se presente sea prácticamente nula. Mala planeación de cada iteración. o Impacto: bajo o Razón: debido a que se espera que cada iteración sea de una o máximo dos semanas, no se requiere de una estricta planeación para cada iteración, en caso de cometer algún error no será de gran impacto ya que se podrá actuar rápidamente. o Se espera hacer iteraciones sencillas y de la menor cantidad de tiempo posible. Revisiones o controles demasiados flexibles. o Impacto : medio o Razón: se puede caer en demasiada flexibilidad y no llegar a realizar adecuadamente las actividades planteadas. o Se cuenta con el compromiso del director quien estará guiando todo el proceso. Además está el compromiso del estudiante quien es consciente de la importancia de realizar cada actividad con el nivel de calidad necesario. Mala estimación de recursos, en especial del tiempo. o Impacto: alto o Razón: podría traer como consecuencia dejar actividades inconclusas o mal realizadas, así como no lograr cumplir con los objetivos trazados. o El estudiante estará cursando únicamente la asignatura de Trabajo de grado y una asignatura de la Maestría en ingeniería de sistemas y computación, lo cual da una disponibilidad casi total de tiempo para el desarrollo del proyecto. En cuanto a los otros recursos, a excepción del tiempo del director, no se consideran determinantes o de alto impacto. Mala distribución del tiempo o Impacto: alto o Razón: podría traer como consecuencia dejar actividades inconclusas o mal realizadas, así como no lograr cumplir con los objetivos trazados. o Se cuenta con las revisiones semanales, en las que se revisara el trabajo realizado. De esta forma se podrá determinar si no se está dedicando el tiempo suficiente y se tomarán las medidas correspondientes. Falta de compromiso con el proyecto 21

22 o o o Impacto: Alto Razón: Si no se adquiere un compromiso con el proyecto, no será posible realizarlo en el tiempo que se tiene disponible. Es poco probable que esta situación se presente ya que se ha venido trabajando en el proyecto por casi 6 meses y se ha aprendido mucho. El estudiante está muy motivado y le gusta el tema del proyecto. Agenda apretada del director del trabajo o Impacto: Alto o Razón.: por estar enmarcado este proyecto en una más grande, se necesita del tiempo y trabajo de director. o El director tiene una cantidad de horas semanales dedicadas exclusivamente al proyecto. Sin embargo se tratara de ser tan autónomo como sea posible. Malas condiciones de salud o Impacto : Medio o Razón: Se podría perder tiempo que ya se tenía planeado usar en el desarrollo del proyecto. o En caso de presentarse esta situación se reasignará el tiempo perdido. Asuntos familiares o Impacto: Bajo o Razón: Los asunto familiares podrían retrasar a lo sumo dos o tres días. o En caso de presentarse esta situación se reasignará el tiempo perdido. Manifestaciones que afecten el desplazamiento. o Impacto: Bajo o Razón: Podría afectar solo reuniones planeadas ya que la mayor cantidad de las actividades del proyecto se realizaran en la casa del estudiante. o En caso de presentarse esta situación se reasignará la reunión perdida. 22

23 6 Marco Teórico / Estado del Arte 6.1 Fundamentos y conceptos relevantes para el proyecto. EL desarrollo dirigido por modelos (MDD) se basa en la simple noción de construir modelos que representan un sistema y después transformarlos en algo real [22]. Un modelo se define como un conjunto coherente de elementos utilizados para describir algo [22]. Un modelo puede ser expresado a través de un leguaje como UML [24], a través del cual se puede mostrar tanto la estructura como el comportamiento del sistema. Estos modelos no representan únicamente el sistema de forma horizontal, sino también de forma vertical, a través del uso de diferentes niveles de abstracción, así en los nivel más bajos, los modelos se expresan en términos de conceptos específicos de una tecnología [1], esto se logra, por ejemplo extendiendo el lenguaje de modelado para representar esos conceptos específicos, en el caso de UML a través de perfiles. Un concepto importante es el de meta-modelo, Un meta-modelo define la estructura, la semántica y las restricciones de una familia de modelos, una familia de modelos se refiere a un conjunto de modelos que comparten semántica y sintaxis [25]. Entonces, la idea de MDD es la creación de modelos, cuya estructura, semántica y sintaxis es dada por un meta-modelo, para representar la estructura y comportamiento de una sistema [25], así, se eleva el nivel de abstracción en el que los desarrolladores pueden construir más fácilmente las aplicaciones [2]. Finalmente se involucran tecnologías de transformación para obtener el código que implementa esos modelos previamente definidos [26]. Desde esta perspectiva de desarrollo, existe un problema importante. Es muy probable que los modelos no tengan el nivel suficiente de detalle para que el código que se genere represente una aplicación completamente funcional. Se requiere que a nivel de código, los desarrolladores modifiquen o incluyan partes específicas de la funcionalidad que no se logró generar a partir de los modelos. En este nuevo enfoque llamado Round-Trip Engineering[11], los ingenieros crean modelos que representan el sistema, a través de herramientas de generación de código se genera el código que implementa dichos modelos, posteriormente se permite que los desarrolladores modifiquen o complementen el código generado y finalmente se requiere de un proceso de ingeniería inversa [27] en el que se actualizan los cambios en el código para que sean visibles en los modelos, de esta forma se mantiene la consistencia entre código y modelos El problema yace en que mantener la consistencia entre los modelo y el código no es una tarea simple, debido a que en muchos casos las transformaciones entre modelos y código no son 1:1, lo que produce una pérdida de importante de información [2]. 23

24 En las organizaciones generalmente se asignan responsabilidades a los empleados de acuerdo con su cargo o rol dentro de la organización. Esta es la idea en que se basa el Control de Acceso Basado en Roles (RBAC), la cual es una de las técnicas más interesantes y prometedoras para diseñar e implementar políticas de seguridad [16]. Algunos de los conceptos importantes de RBAC son: sujetos, permisos, roles, usuarios, control de accesos, grupos y recursos [17]. Un sujeto es una entidad activa en la forma de persona, dispositivo o proceso, que causa el flujo de información entre objetos o cambia en estado del sistema. Los permisos son una descripción del tipo de la interacción autorizada que un sujeto puede tener con un objeto. Un Rol es una función dentro de la organización que describe la autoridad y las responsabilidades que son conferidos a un usuario asignado a un rol. Un usuario es cualquier persona que interactúa directamente con el sistema. El control de acceso se refiere a limitar el acceso a los recursos de un sistema solo a usuarios, proceso u otros sistemas autorizados. Un grupo es un conjunto de usuarios y un recurso es cualquier cosa usada o consumida durante la ejecución de una función. [17]. La noción central de RBAC es que los permisos están asociados a roles, y los usuarios son asignados a los roles. Los roles son creados dependiendo de las funciones de un trabajo en la organización y los usuarios son asignados a esos roles basados en sus responsabilidades y calificaciones [17]. Para el manejo de la seguridad a nivel de control de acceso en este proyecto se usara el módulo CincoSecurity [19]. CincoSecurity implementa RBAC y provee gran flexibilidad en el control de acceso para los diferentes elementos de una aplicación web, como la invocación de una operación de un componente de negocio, el acceso a una página web y el acceso a los elementos dentro de esa página. La innovación presentada por CincoSecurity es que implementa varios conceptos importantes: Un caso de uso es una capacidad del sistema para entregar un resultado útil e indivisible al usuario. Un módulo en un conjunto de casos de uso relacionados. Un rol fino se refiere a la asignación de un rol para cada caso de uso, el rol tiene el mismo nombre del caso de uso. Además se asigna un rol para invocar cada uno de los servicios en el caso de uso. Los Perfiles de seguridad son un conjunto de roles finos donde cada rol representa el derecho a invocar un servicio de un caso de uso [19]. La implementación de CincoSecurity y de la herramienta propuesta en este proyecto se basan en la tecnología Java EE5 [20], y se apoyara en las facilidades ofrecidas por Seam Framework[21]. Existen muchas formas de encontrar errores en el código de un programa, se podrían construir casos de prueba y utilizar herramientas como JUnit [15] para ejecutarlos sobre el programa y encontrar las fallas que este tiene. Otra forma de encontrar errores es hacer revisiones de código por parte de personal especializado, pero esto podría ser poco sostenible, ya que reunir este personal y ponerlos a analizar el código podría tomar mucho tiempo y entrenamiento previo[12]. Como muchos de los errores pueden caer en ciertas categorías conocidas, existen herramientas de software que se encargan de buscar errores en el código sin necesidad de ejecutarlo. Esta búsqueda se centra en la relación del código analizado con ciertos patrones de errores que puede reconocer la herramienta, este proceso se conoce como Análisis estático de código [12]. 24

25 La idea detrás de un Analizador estático de código es que encuentre las fallas, errores o debilidades de un programa, indique su impacto o severidad e indique la ubicación [13]. Para esto el analizador lee el programa y construye una representación abstracta de él, la cual utiliza para encontrar los patrones de errores que puede reconocer. Dos limitaciones importantes en el Análisis estático de código y las herramientas que lo realizan son los falsos positivos y los falsos negativos. Los falsos positivos se refieren a que la herramienta reporta una posible vulnerabilidad que en realidad no lo es. Por el contrario, un falso negativo se refiere a que la herramienta pasa por alto una vulnerabilidad inminente, la cual no es reportada al programador [14]. 6.2 Trabajos Importantes en el área Muchos tipos de vulnerabilidades a nivel de seguridad como problemas de autenticación y control de acceso son muy difíciles de encontrar de forma automática. El estado del arte actual solo permite que aplicaciones del tipo de análisis estático de código encuentren un porcentaje relativamente pequeño de este tipo de fallos [14]. Findbugs es una herramienta libre de análisis estático de código desarrollada en la universidad de MaryLand, que analiza código Java y detecta alrededor 300 patrones de errores. Entre los errores que es capaz de detectar esta herramienta se encuentran malas practicas de programación, errores de correctitud, errores experimentales, internacionalización, vulnerabilidad a código malicioso, correctitud de multihilos, desempeño, seguridad entre otros. Aunque findbugs identifica fallas de seguridad, solo lo hace a nivel de inyección SQL, Scripting a nivel de servels y JSP y conexión a bases de datos. No se contempla la detección de fallos a nivel de control de acceso [28]. PMD es una herramienta que analiza código java y busca posibles fallos como sentencias try/catch /finally/switch vacias; código muestro como variables sin usar; código no optimo, uso excesivo de String/StringBuffer; expresiones complejas, sentencias if innecesarias, ciclos for que podrían ser ciclos while y código duplicado. Aunque PMD no ofrece reglas de chequeo para políticas de control de acceso, permite ser extendido para crear las reglas de chequeo propias usando Java o XPath [31]. OWASP LAPSA [29] es una herramienta que permite a los desarrolladores detectar vulnerabilidades aplicaciones construidas en Java Empresarial. Esta herramienta es distribuida como un plugin de Eclipse y se centra en el escaneo del código JEE para detectar vulnerabilidades producto de inyección de datos no confiables con fin de manipular en comportamiento de la aplicación. Entre las categorías de detección de vulnerabilidades se encuentra la manipulación de parámetros, manipulación de URL, inyección SQL, inyección XPath, inyección XML, inyección LDAP, entre otros. Aunque LAPSA es un analizador en busca de vulnerabilidades a nivel de seguridad, estas no incluyen las de control de acceso. Hay otras alternativas como OWASP ORIZON Project pero al igual que las anteriores, no aborda el análisis del código en busca de fallas a nivel de control de acceso. 25

26 Pistoia et al [35] describen los métodos de análisis de código para RBAC. Pistoia et al [34] proponen un analizador estático para JEE con RBAC. En ninguno de los dos casos se tiene en cuenta una perspectiva que involucre modelos que representen las políticas de control de acceso para el análisis del código. SAVES es un analizador estático de código que detecta posibles fallas a nivel de control de acceso en aplicaciones Java EE con RBAC [32]. Aunque es una herramienta exitosa, ya que encuentra fallos potenciales de seguridad sin reportar falsos positivos[32], no realiza la verificación a partir de modelos que representan las políticas de control de acceso. Fischer et al. [33] proponen un analizador para Java extendiendo del framework JavaCop para chequeo de seguridad a nivel de Object-sensitive RBAC. Nuevamente, esta aproximación no realiza la verificación a partir de modelos que representan las políticas de control de acceso. Muchas de las aplicaciones existentes para analizar código en busca de fallas de seguridad se centran únicamente en el código fuente de la aplicación en construcción: La diferencia principal de estas herramientas con la que se propone en este proyecto es que en la herramienta propuesta se realizará un análisis del código para compararlo con una representación de un Modelo de políticas de control de acceso con el fin de identificar las inconsistencias entre estos dos artefactos. 6.3 Experiencias previas El estudiante y el director han venido trabajando en un proyecto de investigación denominado Security Assurance for Roundtrip Engineering (SARE) [8] cuyo objetivo es desarrollar un marco de trabajo que apoye la evolución de los elementos de control de acceso en software dentro de un entorno de Round- Trip Engineering. Durante el primer semestre de 2012, el estudiante tomo un curso denominado Proyecto especial bajo la instrucción del director. El objetivo de este curso consiste en desarrollar un generador de código para aplicaciones Java EE y un motor de ingeniería inversa, ambos pertenecientes a SARE. Cabe aclarar que el proyecto descrito en esta propuesta es parte del proyecto SARE, esto quiere decir que tanto el generador de código como el motor de ingeniería inversa, desarrollados en el curso de Proyecto Especial, son productos claves para la validación del analizador estático de código para políticas de control de acceso que se pretende desarrollar. Se tiene presente entonces, que el proyecto descrito en esta propuesta, es una tercera fase SARE y una continuación del trabajo desarrollador en el curso de Proyecto Especial. 26

27 7 Referencias y Bibliografía 7.1 Referencias [1] S. Sendall and W. Kozaczynski, Model transformation: the heart and soul of modeldriven software development, IEEE Software, vol. 20, no. 5, pp , Oct [2] B. Hailpern and P. Tarr, Model-driven development: The good, the bad, and the ugly, IBM Systems Journal, vol. 45, no. 3, pp , [3] A. Telecom, Glossary T , [4] P. Devanbu y S. Stubblebine, «Software Engineering for Security: a Roadmap», Proceedings of the Conference on The Future of Software Engineering, [5] J. A. Pavlich-Mariscal, S. A. Demurjian, and L. D. Michel, A framework for security assurance of access control enforcement code, Computers & Security, vol. 29, no. 7, pp , Oct [6] K. Schwaber, SCRUM Development Process, in Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages, and Applications (OOPSLA, 1995, pp [7] OWASP, «V4 - Access Control Verification Requirements». Fecha de consulta: Marzo 23, URL: [8] J. A. Pavlich and A. López, SARE: Security Assurance for Roundtrip Engineering. [Online]. Available: [Accessed: 02-May-2012]. [9] Dropbox Inc., DropBox. [Online]. Available: [Accessed: 05- Dec-2012]. [10] C. M. Pilato, B. Collins-Sussman, and B. W. Fitzpatrick, Version Control with Subversion, Second ed. O Reilly Media, [11] Krzysztof Czarnecki, J. Foster, Zhenjiang Hu, Ralf Lämmel, Andy Schürr, and James Terwilliger. Bidirectional transformations: A Cross-Discipline perspective. In Richard Paige, editor, Theory and Practice of Model Transformations, volume 5563 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [12] P. Louridas, Static code analysis, IEEE Software, vol. 23, no. 4, pp , Jul