Ciclo de vida de desarrollo agil de software seguro

Ciclo de vida de desarrollo agil desoftware seguro

Miguel Hernandez Bejarano*[email protected]

Luis Eduardo Baquero Rey*[email protected]

Coleccion INVESTIGACION

* Grupo de Investigacion en Ingenierıa Aplicada (GUIAS).

Catalogacion en la Publicacion Fundacion Universitaria Los Libertadores

Hernandez Bejarno, MiguelCiclo de vida de desarrollo agil de software seguro Miguel Hernandez Bejarano / Luis Eduardo Baque-

ro Rey, – Bogota: Fundacion Universitaria Los Libertadores, 2020.108 paginas, ilustraciones, graficas; 26 cm (Coleccion Investigacion)

ISBN: 978-958-5478-41-1 (impreso) | ISBN: 978-958-5478-44-2 (digital)

1. Seguridad en el software – 2. Metodologıas agiles – 3. Desarrollo de software seguro – 4. Seguridadinformatica. I Hernandez Bejarano, Miguel, Autor II. Fundacion Universitaria Los Libertadores.

SCDD 005.8 B222c –dc23 FULL BIBLIOTECA

Primera Edicion: Bogota, diciembre de 2020©Fundacion Universitaria Los Libertadores.

Cra. 16 No. 63A-68/ Tel. 2544750.www.ulibertadores.edu.co

Juan Manuel Linares VenegasPresidente del Claustro

Angela Marıa Merchan BasabeRectora

©Miguel Hernandez Bejarano©Luis Eduardo Baquero ReyAutores

Jefferson Miguel Hernandez CaceresDiagramacion

Diego A. Martınez CardenasCoordinador Editorial

Los autores declaran que esta investigacion fue financiada por la Fundacion Universitaria Los Libertadoresen el marco de la Convocatoria de Investigaciones internas de la institucion. Los conceptos emitidos en estapublicacion son responsabilidad expresa de los autores y no comprometen de ninguna forma a la institucion.Se autoriza la reproduccion del texto citando autor y fuente, unicamente con fines academicos. En casodistinto, se requiere solicitar autorizacion por escrito al editor. Escrito en LaTeX.

Agradecimientos

Los autores expresan especial agradecimiento a todas aquellas personas que de una u otra manera hancontribuido para que esta obra haya sido posible, empezando por los estudiantes del semillero de investigacionen seguridad informatica donde nacio la idea del proyecto, a los colegas del programa de Ingenierıa de Sistemas,a los colegas del Grupo de Investigacion en Ingenierıa Aplicada (GUIAS), a los directivos de la Facultad deIngenierıa y Ciencias Basicas, y en general a la Fundacion Universitaria Los Libertadores por brindar losespacios y el apoyo financiero necesario.

A Dios, a mi esposa Flor Angela e hijos (Jefferson, Julieth y Oscar).Miguel

A Dios, mi familia, colegas y estudiantesEduardo

Prologo

Nos encontramos inmersos en una sociedad donde el consumo de datos sobre diversas plataformas conectadosa traves de Internet requiere de un alto nivel prestacional por parte de diversos sectores y actores tecnologicos,como proveedores de servicio, fabricantes, ası como el sector de la industria del software. Soluciones basadasen aplicaciones que soportan solicitudes para el ingreso o consumo de datos en tiempo real sobre cualquierarea: ludica, consumo, ocio, trabajo, educacion, entre otros. Esta variedad de soluciones demanda grandesdesafıos, orientados a cada vez mas altos niveles de prestaciones que puedan ofrecer, tales como la disponi-bilidad, robustez, interoperabilidad, integridad, etc., de cada uno de sus componentes, incluyendo aspectostrascendentales propios para lograr mitigar riesgos y vulnerabilidades de seguridad.

La realidad de la cantidad de procesos que se desprenden de soluciones informaticas es tan variada, que,para llevar a cabo su correcto desarrollo bajo especificaciones y estandares, requieren de un alto nivel demadurez en todos y cada uno de los procesos establecidos en las etapas de desarrollo de software. Es asıcomo la presente obra, presenta una de esas realidades inmersas sobre un variado ecosistema de solucionesdigitales basadas en software; enfocado puntualmente sobre estrategias y metodos para mitigar riesgos deseguridad dentro de procesos enmarcados en el ciclo de vida del desarrollo de software. Lo anterior, bajodiversas miradas que presenta el mercado informatico a partir de metodologıas agiles. Indudablemente unaapuesta que permite acercarnos a una de serie de consideraciones y criterios que todo equipo, empresa o casamatriz de desarrollo necesitan conocer e identificar, con el proposito de poder cubrir aspectos esenciales enel despliegue de aplicaciones y soluciones informaticas que logren ser distribuidas sobre el mercado.

Dentro de la presente obra, el lector podra encontrar apartados orientados a destacar el panorama quepresentan las metodologıas de desarrollo agil dentro del contexto de software seguro. Ası mismo, la relevanciaque presenta el desarrollo agil, de la mano de estrategias y buenas practicas para el desarrollo seguro delsoftware. Finalmente, los autores exponen de manera detallada y validando mediante caso de estudio aplicado,una propuesta metodologica partiendo de los principios de ciclo de vida de desarrollo de software, y el usode estrategias de seguridad a considerar en cada una de las fases planteadas.

Me place encontrar dentro de la literatura nacional, este tipo de apuestas orientadas a ofrecer espaciosde analisis, reflexion y propuestas concretas asociadas a metodos de desarrollo de software agil a partirde estrategias de seguridad, sobre todo, en el marco de una variada industria de software apalancada poremprendimientos de base tecnologica, donde el software como actor del ecosistema digital, es uno de losinsumos valiosos para una sociedad que demanda cada vez mas servicios en lınea.

Paulo Alonso Gaona Garcıa, Ph.D

i

Introduccion

El mercado es cada dıa mas exigente en cuanto a desarrollo de software se refiere. Ya no es suficiente con que lascasas desarrolladoras de programas informaticos cumplan a cabalidad con los requerimientos de funcionalidadque satisfacen las necesidades del cliente, sino que ademas se deben involucrar aspectos relevantes de losrequisitos no funcionales que de alguna manera mitiguen los posibles riesgos a los que pueda estar expuestoel producto cuando este se encuentre en la etapa productiva, pues el numero de vulnerabilidades es cada vezmayor, lo que pone en riesgo la informacion y, por ende, la continuidad del negocio de las organizaciones.

Las herramientas agiles buscan dar soluciones informaticas oportunas con la participacion activa y directa delcliente, y pueden ofrecer mayor seguridad a las aplicaciones desarrolladas al involucrarlas con un ciclo de vidade desarrollo de software seguro. Esta obra da cuenta de los resultados obtenidos durante una investigacionaplicada a la integracion de un ciclo de vida de desarrollo de software seguro (S-SDLC), de fundamentosteoricos y herramientas existentes para el desarrollo agil de este tipo de proyectos y de buenas practicas deseguridad de la informacion en los desarrollos de productos software. Para ello, se propuso una metodologıaimplementada bajo las circunstancias del planteamiento de un caso de estudio hipotetico, que podrıa ser real.

Es conveniente resenar la concepcion del proyecto desde el semillero de investigacion en seguridad informatica,que posteriormente se planteo en el marco de la convocatoria interna de proyectos de investigacion institu-cional en la lınea de investigacion de Innovacion y Emprendimiento, como parte integrante del Grupo deInvestigacion en Ingenierıa Aplicada (GUIAS).

El objetivo fundamental en la seguridad del software es la construccion de aplicaciones informaticas de mejorcalidad, mas robustas y libres de fallos, que implementen el principio de resiliencia, es decir, que siganfuncionando correctamente ante ataque malicioso (McGraw, 2006).

En respuesta a la creciente tasa de danos y perjuicios causados a las empresas por explotacion de las vulnera-bilidades de seguridad en los productos de software, se requiere de mayor esfuerzo para desarrollar softwaremas seguro (Keramati y Mirian-Hosseinabadi, 2008).

Para tal efecto, este documento se presenta en seis capıtulos, de la siguiente manera:

En el capıtulo 1 se realiza un estudio comparativo de diferentes ciclos de vida de desarrollo de softwareseguro y se determinan sus ventajas y desventajas, para luego establecer la conveniencia de su aplicabilidadcon metodologıas agiles de desarrollo de software, partiendo de la flexibilidad y las caracterısticas que ofrecen,lo que producira un analisis de resultados y su posterior discusion. Ello servira de insumo para la industriaen este campo.

ii

En el capıtulo 2 se estudian los principales elementos y tecnicas agiles implicadas en el desarrollo de un pro-ducto software, a fin de determinar los principales elementos aportantes para el desarrollo de la investigacion.

El capıtulo 3 trata sobre las buenas practicas y los estandares de seguridad de la informacion, como lanorma ISO 27001 y los Common Criteria (CC); estudia organizaciones como Open Web Application SecurityProject (OWASP), que aportan esfuerzos importantes para el desarrollo de aplicaciones web seguras; comparaherramientas para el desarrollo de software seguro y para el analisis de codigo, como UMLsec, e identifica laspropiedades que debe cumplir un software seguro y las amenazas a dicha seguridad.

En el capıtulo 4 se presentan las fases del ciclo de vida de desarrollo de software propuesto, la metodologıaadoptada, el caso de estudio planteado y su desarrollo en los terminos ya enunciados, adoptando el marco detrabajo SCRUM.

Finalmente, en los capıtulos 5 y 6 se hace un analisis de los resultados obtenidos y se relacionan las principalesconclusiones producto del desarrollo del proyecto, respectivamente.

Con esta investigacion se busca adoptar una buena practica que de respuesta a requisitos de seguridad quedeben contemplar los equipos de desarrollo agil de software, con el fin de construir productos mas establesy robustos, fundamentales en materia de seguridad informatica, en pro de garantizar la confidencialidad,disponibilidad e integridad de un producto software. Entretanto, tambien pretende servir de apoyo a laacademia en la formacion de nuevos profesionales, como un insumo a tener en cuenta en las lıneas de Ingenierıade Software y Seguridad de la Informacion.

iii

Indice general

1. Ciclos de vida de desarrollo de software seguro 61.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2. Tipos de ciclos de vida de desarrollo de software seguro . . . . . . . . . . . . . . . . . . . . . 6

1.2.1. McGraw’s Seven Touchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.2. Microsoft Security Development Lifecycle (SDL) . . . . . . . . . . . . . . . . . . . . . 81.2.3. Correctness by Construction (CbyC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.4. Comprehensive, Lightweight Application Security Process (CLASP) . . . . . . . . . . 101.2.5. Software Assurance Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.6. Team Software Process (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.7. Otras metodologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3. Caracterısticas de los S-SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4. Modelado de amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2. El desarrollo agil en el software 212.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.1. El manifiesto agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.2. Las tecnicas agiles y la madurez de la industria del software . . . . . . . . . . . . . . . 222.1.3. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.4. Metodologıa XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.5. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.6. OpenUP/Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.7. SD3+C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3. Buenas practicas en seguridad de la informacion 293.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Estandares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1. Norma ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2. Common Criteria (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3. Organizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.1. Common Weakness Enumeration (CWE) . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2. Web Application Security Consortium (WASC) . . . . . . . . . . . . . . . . . . . . . . 303.3.3. The Open Web Application Security Project (OWASP) . . . . . . . . . . . . . . . . . 303.3.4. Secure Software Programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4. Desarrollo de software seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.1. Security Requirements Engineering Process (SREP) . . . . . . . . . . . . . . . . . . . 34

3.5. Buenas practicas de seguridad del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6. Herramientas de desarrollo de software seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.1. Casos de mal uso (casos de abusos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.2. UMLsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.3. Herramientas para analisis de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7. Seguridad en el software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1

3.7.1. Propiedades de un software seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.7.2. Amenazas a la seguridad del software . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4. Metodologıa y caso de estudio 374.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. S-SDLC propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.1. Fase de Capacitacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.2. Fase de Construccion de los requerimientos y Casos de abuso . . . . . . . . . . . . . . 384.2.3. Fase de Analisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.4. Fase de Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3. Fase de Codificacion y pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1. Fase de Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2. Fase de Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4. Fase de Auditorıa de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5. Metodologıa adoptada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.7. Desarrollo del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.7.1. Fase de Capacitacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.7.2. Fase de Construccion de los requerimientos y Casos de abuso . . . . . . . . . . . . . . 434.7.3. Ejecucion del sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.7.4. Fase de Analisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.7.5. Fase de Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.7.6. La seguridad en las bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7.7. Seguridad en motores de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 614.7.8. Fase de Codificacion y pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7.9. Algunas pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.8. La seguridad framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.8.1. Framework Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.8.2. Framework PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.9. Fase de implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.9.1. Salvaguardas de los sistemas operativos . . . . . . . . . . . . . . . . . . . . . . . . . . 994.9.2. Arquitectura de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.10. Fase de Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.11. Fase de Auditorıa de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5. Analisis de resultados 107

6. Conclusiones 108

Bibliografıa 109

2

Indice de figuras

1.1. Touchpoints de Gary McGraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2. Ciclo de vida de Microsoft SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Ciclo de vida de Microsoft SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4. Ciclo de vida de Microsoft SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5. Relacion de los niveles de vistas CLASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.6. Organizacion SAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.7. STRIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1. Valores del manifiesto agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2. Principios del manifiesto agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3. Enfoque SD3+C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1. Top 10 de OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2. Vulnerabilidades asociadas al Top 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3. OWASP Cloud-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1. Fases del S-SDLC propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3. Ciclo Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4. Scrum adoptado para el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5. Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6. Historia de usuario Ingreso al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.7. Historia de usuario Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.8. Historia de usuario Renovacion de contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.9. Historia de usuario Realizar pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.10. Historia de usuario Consultar temas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.11. Historia de usuario Buscar revistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.12. Caso de abuso Ingreso al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.13. Historia de usuario HU01 - Iteracion 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.14. Ajuste historia de usuario HU02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.15. Planeacion de historia de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.16. Historia de usuario HU03 - Iteracion 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.17. Sprint propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.18. Tablero Kanban para historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.19. Tablero Kanban incluyendo seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.20. Diagrama de clases del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.21. Diagrama de clases de la revista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.22. Seguridad en Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.23. Tabla de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.24. Modelo E-R para Suscriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.25. Modelo E-R para la Revista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.26. Capas de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3

4.27. Estadısticas de los lenguajes de programacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.28. To de los leguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.29. Seguridad en .Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.30. Seguridad en PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.31. Seguridad en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.32. Pruebas de ingreso al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.33. Captcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.34. Apache Shiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.35. Java de cifrado simplificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.36. Spring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.37. jGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.38. Codelnigter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.39. Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.40. Autenticacion y autorizacion en Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.41. Aspectos de seguridad en profundidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.42. Elementos de una arquitectura segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.43. Internet Information Server (IIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.44. Servidor Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.45. Servidor NGINX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.46. Servidores web mas utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4

Indice de tablas

1.1. Relacion de actividades sugeridas para el desarrollo CLASP . . . . . . . . . . . . . . . . . . . 121.2. S-SDLC vs. actividades de ingenierıa de requisitos y diseno . . . . . . . . . . . . . . . . . . . 171.3. Actividades de implementacion y verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4. S-SDLC vs. recursos y usos a nivel empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1. Caracterısticas generales en las metodologıas agiles . . . . . . . . . . . . . . . . . . . . . . . . 232.2. Caracterısticas comunes en metodologıas agiles . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3. Seguridad en XP y Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4. Flexibilidad del tablero Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1. Metodologıas agiles integradas en el S-SDLC propuesto . . . . . . . . . . . . . . . . . . . . . 424.2. Historia de usuario del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3. Epopeya para sistema de logueo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4. Identificacion de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.5. Valores cuantitativos del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6. Matriz de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.7. Tarjetas CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.8. Categorizacion de los lenguajes de programacion . . . . . . . . . . . . . . . . . . . . . . . . . 704.9. Pruebas a historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.10. Pruebas de caja blanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.11. Pruebas de caja negra - Ingreso al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.12. Pruebas de caja negra - Busqueda de revistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.13. Pruebas de caja negra - Registrar un suscriptor . . . . . . . . . . . . . . . . . . . . . . . . . . 934.14. Cronograma de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.15. Checklist de auditorıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5

Capıtulo 1

Ciclos de vida de desarrollo desoftware seguro

1.1. Introduccion

En el proceso de desarrollo de software normalmente se involucra lo que se conoce como ciclo de vida dedesarrollo de software, donde se agotan una serie de fases o etapas, con sus respectivas ventajas y desventajassegun el paradigma adoptado. Hay diversos modelos y algunos de ellos tienen un enfoque de desarrollo desoftware seguro. En este capıtulo se estudian varios modelos y se realiza un analisis comparativo para resaltarsus principales caracterısticas, que a la vez pueden ser considerados para los fines de la investigacion.

1.2. Tipos de ciclos de vida de desarrollo de software seguro

Actualmente, la seguridad es un requerimiento no funcional que puede ser definido como la calidad y capacidaddel software al momento de enfrentarse a la explotacion de las vulnerabilidades causadas por las aplicaciones.Por eso, se han disenado una serie de metodologıas incluidas en el proceso de desarrollo de software seguro,en pro de eliminar o mitigar dichas vulnerabilidades e integrar la seguridad como un componente basico en laarquitectura de cualquier producto de software(Kang J & Park J. H. 2018). Existen varias metodologıas queestablecen una serie de pasos o etapas denominadas ciclo de vida de desarrollo de software seguro (S-SDLC,por sus siglas en ingles), que promueven un software mas seguro y capaz de resistir a ataques. A continuacion,se describen algunas de ellas:

6

1.2.1. McGraw’s Seven Touchpoints

Gary McGraw (2006) plantea siete puntos clave en el desarrollo de un producto de software seguro, estable-cidos en 2004 por el Instituto de Ingenierıa Electrica y Electronica (IEEE, por sus siglas en ingles), conocidoscomo el modelo de Gary McGraw y Cigital. Es considerado uno de los tres pilares de la seguridad de software,ya que une los aspectos tecnicos y practicos del desarrollo y de esa manera hace enfasis en el empleo de buenaspracticas. Para ello, recomienda tener en cuenta una revision externa y los siguientes aspectos:

La revision del codigo. Los proyectos de software producen al menos un codigo fuente por artefacto.A nivel de codigo, la atencion se centra en los errores de ejecucion y en identificar las vulnerabilidadesque puedan afectar el desarrollo del producto. Para brindar una mayor proteccion al software a pruebade intrusiones, es necesario completar todas las fases del modelo.

Analisis de riesgos de arquitectura. En el ambito del diseno y la arquitectura, un sistema debe sercoherente y presentar un frente de seguridad unificada que se constituye por el trabajo en equipo entrelos arquitectos, disenadores y analistas. De esta manera se genera una documentacion desde diferentesopticas. Al implementar un proceso de analisis de riesgos y seguridad se brindan al arquitecto pautaspara el inicio de la construccion, sin descartar una probable aparicion de amenazas en cualquier etapadel proyecto. Estos analisis deben ser constantes durante todo el proceso de construccion de la aplicacionde software.

Las pruebas de penetracion. Es una etapa muy util, especialmente si el analisis de riesgos dearquitectura esta orientado a las pruebas, y se realiza mediante intrusiones de hacking etico controlado,con el fin de identificar inconvenientes que se pudieran presentar a futuro, cuyo proposito es implementarprocesos para evitar y prevenir los posibles ataques.

Pruebas de seguridad basadas en el riesgo. Cubren dos estrategias: la prueba de funcionalidadde seguridad con tecnicas estandar de pruebas funcionales y la prueba de seguridad basada en el riesgocon base en patrones de ataque, ya que estos no siempre son evidentes. Estas pruebas de seguridaddeben contemplar actividades orientadas a la identificacion, analisis y seguimiento del riesgo.

La construccion de los casos de abuso. Segun Gary McGraw (2006), es una forma directa y cercanade entrar en la mente del atacante, pues la creacion de los casos de abuso requiere una cobertura explıcitapara identificar, revisar y fortalecer lo que debe ser protegido, de que o quien y por cuanto tiempo.

Los requisitos de seguridad. Aunque en el inicio de todo proyecto de software se determinan losrequerimientos funcionales y no funcionales desde la percepcion del usuario, estos deben estar enfocadosal proceso de seguridad. Ademas, deben ser validados y actualizados periodicamente, con el fin derestablecer y renovar los protocolos y procesos dispuestos para este fin.

Las operaciones de seguridad. Los ataques ocurren, independientemente del esfuerzo de diseno eimplementacion, por lo que el monitoreo del comportamiento del software es una tecnica defensivaesencial. Igualmente, el comportamiento de seguridad del software debe ser monitoreado de manerarecurrente y continua, lo cual se ha convertido actualmente en la principal forma de defensa de unsistema de informacion. Su punto de partida se encuentra en la identificacion de riesgos.

Revision externa. Es una evaluacion imparcial y objetiva realizada por personal externo al proyecto.

La Figura 1.1 ilustra los siete puntos propuestos por Gary McGraw.

7

Figura 1.1: Touchpoints de Gary McGraw

Fuente: http://www.swsec.com/resources/touchpoints/

1.2.2. Microsoft Security Development Lifecycle (SDL)

El proceso SDL de Microsoft (2016) es una metodologıa compuesta por 16 actividades divididas en las fasesque componen la tecnica y que estan encaminadas al mejoramiento del desarrollo de software. Fue propuestaen 2004 por Microsoft e incluye un proceso de modelado de amenazas, que busca identificar vulnerabilidadesa nivel de codigo.Con el proposito de optimizar el acoplamiento segun el tipo de desarrollo, SDL cuenta con dos versiones de

ejecucion:SDL version rıgida, enfocada en equipos de proyectos y desarrollo de productos de gran envergadura donde

los cambios son mınimos.SDL version agil, cuyos desarrollos son incrementales con aumento en la frecuencia de ejecucion y seguimiento

de actividades, haciendo enfasis en su seguridad. Recomendada para desarrollos web.Como parte diferencial de las metodologıas de desarrollo de software seguro, SDL cuenta con una etapa de

“entendimiento de seguridad” y “aseguramiento”, en la cual se da seguimiento a cada uno de los resultadosdel proceso.La Figura 1.2 ilustra las fases del ciclo de vida Microsoft Security Development Lifecycle (SDL).

Fuente: https://www.microsoft.com/en-us/sdl/

Figura 1.2: Ciclo de vida de Microsoft SDL

8

La Figura 1.3 describe las fases de esta metodologıa. Fuente: Microsoft.


1.2.3. Correctness by Construction (CbyC)

Esta metodologıa busca la creacion de codigo de manera correcta desde su inicio, procurando corregir y elimi-nar errores desde su ingreso, para lo cual se apalanca en procesos rigurosos de seguridad con requerimientosmuy detallados.

En una primera entrega, la metodologıa CbyC presenta una vision completa del sistema con funcionalidaden general limitada, pero que permitira los ajustes y mejoras en cada iteracion (Hall y Chapman, 2002).

De acuerdo con Amey (2006), corresponde a un metodo practico para desarrollar aplicaciones de softwareque requieren un nivel de seguridad crıtico y que ademas sea demostrable. A continuacion, se describen lasprincipales actividades de las fases involucradas en este ciclo de vida:

Fase de requerimientos. Se especifica el proposito, las funciones, los requerimientos de usuario y setiene en cuenta la definicion de requerimientos no funcionales expresados en los diagramas de clases.Cada requerimiento debe pasar por el proceso de validacion de seguridad a la amenaza correspondiente.

Fase de diseno de alto nivel. Detalla la estructura interna del sistema, como la estructura de la basede datos y los mecanismos para las transacciones y comunicaciones, teniendo como punto principal los

9

requerimientos no funcionales en cuanto a su ambito de seguridad en cada punto algido.

Fase de especificacion del software . Es el espacio donde se fundamentan las especificaciones de lainterfaz de usuario (look and feel), mediante el desarrollo de un prototipo para la posterior validacioncon el cliente.

Fase de diseno detallado. Se define la serie de modulos y actividades y la funcionalidad referida.

Fase de especificacion de los modulos. Define el estado y el comportamiento encapsulado en cadamodulo de la aplicacion de software, apoyado en los procesos que contienen informacion.

Fase de codificacion. Escenario para impedir cualquier ambiguedad posible, incluyendo tambien elcodigo de la aplicacion de software. En esta fase se induce el desarrollo de pruebas con el fin de disminuiry eliminar los errores presentes en el codigo, y se podra definir de forma paralela si debe ser creada unanueva version del codigo.

Fase de especificacion de pruebas. Como particularidad en la metodologıa CbyC, no es necesarioejecutar un proceso de pruebas de unidad ni caja blanca, puesto que su foco central es realizar estasvalidaciones a nivel de sistema y con miras al cumplimiento de las especificaciones, comportamientos yrequerimientos no funcionales.

Fase de software del software CbyC. Utiliza la metodologıa de tipo agil. En la primera entrega secuenta con una estructura de todas las interfaces y elementos de comunicacion, con una funcionalidadmuy limitada. La metodologıa presenta un enfoque tecnico con el cual pretende disminuir los defectos,aumentando considerablemente su capacidad para minimizar fallas, lo que beneficia su implementacionen el desarrollo de software.

La Figura 1.4 describe el ciclo de vida CbyC, correspondiente a la secuencia establecida para la construccionde sus fases, cuyas pautas emplean la metodologıa de desarrollo agil, en el cual se reciben retroalimentacionesa medida que se entrega y valora el producto en construccion. Lo anterior permite adelantar actividadesen paralelo como el diseno de alto nivel y la especificacion del software, especificaciones de prueba y disenodetallado.


Fuente: http://recibe.cucei.udg.mx/revista/es/vol2-no3/computacion05.html

1.2.4. Comprehensive, Lightweight Application Security Process (CLASP)

El uso de esta metodologıa dirige a los desarrolladores en el proceso de revision y validacion desde las primerasetapas del ciclo de vida del desarrollo de software, de manera que este proceso se convierta en estructurado(The Open Web Application Secutity Project [OWASP], 2016).

Facilita su integracion a cualquier desarrollo de software, articulando cada una de las actividades aplicadas auno o mas roles previamente identificados: gerente del proyecto, arquitecto, especificador de requerimientos,disenador, implementador (equipos de desarrollo), tester (grupo de pruebas), auditor de seguridad (De Win,

10

B. Scandariatoc R. Buyens, K. Gregoire, J. Joosen, W. , 2009)

Vista CLASP. La metodologıa plantea 104 fallas de seguridad agrupadas en 5 niveles de vistas, que tienenconsigo actividades relacionadas en la Figura 1.5.

Figura 1.5: Relacion de los niveles de vistas CLASP

Fuente: Owasp.org

Las 24 acciones indicadas en las vistas de implementacion y evaluacion de actividades para la metodologıase describen en la Tabla 1.1.Recursos CLASP. Como apoyo a los procesos de planificacion y ejecucion de actividades, CLASP presenta

una serie de recursos o herramientas que permiten el acceso a los diferentes artefactos.

Caso de uso de vulnerabilidad. Escenario donde se describen los puntos en los cuales se presenta vulne-rabilidad en las aplicaciones de software, que pretende dar al usuario una vista facil al respecto y establecerclaras relaciones de causa y efecto.

1.2.5. Software Assurance Maturity Model

El Software Assurance Maturity Model (SAMM) es un marco abierto para ayudar a las organizaciones aformular y aplicar una estrategia para la seguridad del software que se adapte a los riesgos especıficos queenfrenta la organizacion. Los recursos proporcionados por SAMM ayudaran a:

Evaluar una organizacion de seguridad de software.

Construir un programa de seguridad de software equilibrado mediante estrategias de seguridad conenfoque en las iteraciones que se puedan definir.

Demostrar mejoras concretas para un programa de garantıa de la seguridad.

11

Tabla 1.1: Relacion de actividades sugeridas para el desarrollo CLASP

Actividad Proposito Rol Frecuencia

Direccionar los problemasde seguridad reportados.

Certificar que los riesgosidentificados sean consideradosy direccionadosde manera correcta.

Disenador. Cuando se requiera.

Disenos de clase conpropiedad de seguridad.

Elaborar polıticas deseguridad para los campos dedatos individuales.

Disenador.Una vez poriteracion.

Aplicar los disenos deseguridad del proyecto.

Reforzar el diseno deaplicaciones mediante laimplementacion de disenos deseguridad.Identificar los riesgos deseguridad que puedan serproporcionados por terceros.

Disenador.Al menos una vezpor iteracion.

Definir y medir las actividades relacionadas con la seguridad dentro de una organizacion. SAMM pre-senta cuatro funciones principales, cada una compuesta por tres practicas de seguridad, como lo muestrala Figura 1.6.

SAMM define cuatro funciones crıticas de negocio de alto nivel, a saber:

Gobernabilidad. Esta centrada en la definicion de la estrategia y en los procesos y polıticas relacionadoscon la gestion del S-SDLC en una organizacion.

Construccion. Se refiere a los procesos y actividades que la organizacion debe seguir para el desarrollo de laaplicacion, lo cual incluye la administracion del producto, la recoleccion de requerimientos, las especificacionesde la arquitectura a alto nivel, la definicion del diseno detallado y la implementacion de la aplicacion.

Verificacion. Se enfoca en los procesos relacionados con la revision y pruebas de los artefactos producidosdurante el desarrollo del software; incluye aseguramiento de calidad y diferentes tipos de pruebas.

Implementacion. Son las actividades relacionadas con la liberacion de la aplicacion.

Desarrollo. Espacio donde se aborda la gestion de vulnerabilidades, el fortalecimiento del entorno y lasactividades operativas.

1.2.6. Team Software Process (TSP)

Proporciona un marco de procesos y metodos disciplinados para la aplicacion de los principios de ingenierıade software en el equipo a nivel individual. El uso de TSP ayuda a las organizaciones a establecer una practicade ingenierıa madura y disciplinada que produce software seguro y confiable en menos tiempo y con costosmas bajos (Software Engineering Institute [SEI], 2010).

Algunos de los aspectos mas importantes de TSP son: Planeacion de calidad. El equipo desarrolla unaestimacion del numero de defectos que seran inyectados durante el desarrollo y luego construye un plan paraeliminar esos defectos. Una de las principales diferencias filosoficas es que los equipos TSP intentan eliminarla gran mayorıa de los defectos, si no todos, antes de las pruebas del sistema de software.

Planificacion y estimacion. Son realizadas por los miembros individuales del equipo orientado por unentrenador TSP, lo cual les permite mayor apropiacion de sus planes y compromisos. Las estimaciones sevuelven mas precisas a medida que cada miembro del equipo mejora sus habilidades de estimacion, a traves

12

Actividad Proposito Rol Frecuencia

Construir guıaoperacionalde seguridad.

Proporcionar a los interesadosdocumentacion en medidasoperacionales de seguridad.Suministrar los documentosnecesarios que formalicen elproceso de seguridad de laaplicacion.

Implementador.Una vez poriteracion.

Diseno de loscasos de usoindebido.

Informar a los interesadossobre los riesgos y las razonesde las decisiones relevantesque han sido tomadas para laseguridad.

Especificador derequerimientos.

Segun seanecesario, sinimportar las vecesen cada ejecucion.

Documentacion derequerimientosde seguridad.

Documentar a nivel de negociolos requisitos funcionalesde seguridad.


Una vez poriteracion y cuandosea necesario.

Identificar superficiede ataque.

Especificar estructuradamentecada punto de entrada (input)del programa.Facilita elproceso de analisis.

Disenador.

Recomendado alterminar la fase dediseno y continuaren la fase deelaboracion.

Identificar la polıticageneral de seguridad.

Proporciona los requerimientosde seguridad del negocio.Compara el nivel de seguridadde varios productosde la org.


Una vez poriteracion.

Identificar los recursosy lımites de laconfianza.

Identificar la base estructuradapara interpretar los requisitosde seguridad del sistema

Arquitecto.Una vez poriteracion.

Identificar los rolesde los usuariosy las capacidadesde los recursos.

Precisar los roles del sistema,ası como las capacidades yrecursos a los que tendraacceso cada uno.

Arquitecto.Una vez poriteracion.

Identificar,implementar yrealizar pruebas deseguridad.

Identificar riesgos que no hansido evidenciados en la fase deimplementacion o que han sidoidentificados en el procesooperativo. Se comporta comomecanismo de captura defallos.

TESTER

Generalmente,repetidas vecesdurante cadaiteracion.

Implementarinterfaz decontratos.

Identificar los errores a nivel defiabilidad desde el inicio delproceso.

Implementador.

Cuando sonmodificados losmetodos o lasfunciones.

Programainstitucional de

sensibilizacionde seguridad.

Asegurar que los miembros delproyecto podran enfrentar losinconvenientes de seguridadcon la suficiente eficacia paravolverla un objetivo mediante laentrega de cuentas.

Gerente delproyecto.

En marcha.

13

Actividad Proposito Rol FrecuenciaIntegrar la seguridaden el origendel proceso deadmiracion.

Automatizar el analisis deseguridad a nivel de losprocesos de aplicacion y larecoleccion de datos.

Implementador. Cuando sea necesario.

Controlar lasestadısticas

de seguridad

Llevar control metrico de loscasos de seguridadpresentados.

Gerente delproyecto

En marcha.

Generar firma delcodigo.

Proporcionar a los interesadosla forma de validar el origen yla integridad del softwareentregado.

Implementador.Una vez liberada laaplicacion odesarrollo.

Hacer analisis deseguridad de losrequisitos y diseno(modelado deamenazas).

Identificar las amenazas,mitigar los riesgos y fortalecerlos requisitos de seguridadestablecidos.

Auditor deseguridad.

Cuando seanecesario.

Ejecutar monitoreode seguridaden la fuente.

Encontrar las vulnerabilidadesa nivel de software.

Auditor deseguridad.

Incremental, al finalde cada iteracion.

Investigar y evaluarla seguridad delas solucionestecnologicas.

Evaluar los niveles deseguridad que se puedanpresentar por terceros.

Disenador.Cuando seanecesario.

Especificar laconfiguracion

y nivel deseguridad delas BD.

Especificar los niveles deseguridad para los usuarios yterceros que puedan acceder ala base de datos.

Disenador (BD).Cuando seanecesario

Especificar elentornooperacional.

Documentar los supuestos yrequisitos de seguridad, demanera que pueda servalidado el impacto operacional.


Cuando seanecesario.

Verificar losatributos de

seguridad delos recursos.

Confirmar que los procesos deseguridad establecidos en lapolıtica se encuentren en elsoftware.

testerUna vez poriteracion.

14

Figura 1.6: Organizacion SAMM

Fuente: SAMM.

15

del uso de datos reales.

Proceso de software personal. Los desarrolladores individuales estan especıficamente capacitados entecnicas personales para producir software de alta calidad con previsibilidad mejorada del horario.

Equipos autogestionados. Los miembros del equipo participan en la gestion general del proyecto. MetricsFramework y datos. Cuatro medidas simples se capturan mientras las personas estan haciendo el trabajo.Estas medidas permiten que los individuos y los equipos realmente entiendan donde estan y como estafuncionando el proceso. El TSP incluye un conjunto completo de metricas de calidad y planificacion.

Entrenamiento. Un entrenador TSP trabaja hombro a hombro con el equipo al implementar el TSP. Estoasegura que se esten llevando a cabo todas las actividades de TSP segun lo planeado y que cada individuosea consciente, a traves de sus metricas personales, de que tan bien esta desempenando su labor y dondepuede mejorar (Wyrwa, 2012).

1.2.7. Otras metodologıas

Oracle Software Security Assurance: sus productos de servidor de bases de datos han logrado consisten-temente altas calificaciones de certificacion de seguridad en todos los criterios en los que participa. Lasplataformas donde se realizan las evaluaciones incluyen versiones evaluadas de Linux u Oracle Solaris.

Appropriate and Effective Guidance in Information Security (AEGIS).

Rational Unified Process-Secure (RUPSec).

Secure Software Development Model (SSDM).

Waterfall-Based Software Security Engineering Process Model.

1.3. Caracterısticas de los S-SDLC

En las siguientes tablas se relacionan y establecen las principales caracterısticas de los S-SDLC, incluyendoademas de los mencionados a CLASP, TSP-Secure y OPENSAMM:

16

Tabla 1.2: S-SDLC vs. actividades de ingenierıa de requisitos y diseno

Item SDL CbyCMcGraw’sSevenTouchpoints

CLASPTSP-secure

OPEN-SAMM

Activi-dadesde inge-nierıarequi-sitos

La fase deplanificaciones el espa-cio apropiadopara ladefiniciony el estable-cimiento dela seguridadde la fiabi-lidad de unaaplicacionde software.Al conocerlos riesgos,se podranidentificar ycorregir loserrores deseguridad.

En la fasede requeri-mientos seespecifica elproposito, lasfunciones ylos requeri-mientos nofuncionales.Cada requeri-miento debepasar por unproceso detrazabilidadde requeri-miento deseguridad ala amenaza.

La seguridaddebe ser ocu-pada directa-mente a nivelde requisitos.Se deben in-cluir tanto lasnecesidadesde seguridadcomo deseguridadfuncional.Brinda unbuen conoci-miento delsoftwarealineado ensu entornoreal. Se iden-tifican activos,entornoy riesgos.

Los requi-sitos deseguridadconstan delos siguientespasos: i)identificarlas funcionesy los recursosdel sistemay ii) deter-minar lasinteraccionesde recursosa travesdel tiempode vidadel sistema.

Activi-dades derequeri-mientos.Algunosporcentajesde las vul-nerabili-dades. Semodelanlas amenazas o eldesarrollode loscasosde abuso.

Los requi-sitos deseguridaddeben estarintegradoscon las nece-sidades delnegocio,comola auten-ticacion, laautorizacionde los usua-rios y lavalidacionde lasentradas dedatos.

Activi-dadesdediseno

Es la etapadel ciclo devida paradeterminarrequerimien-tos de diseno,analisis delos espaciosde ataques,modelos deamenazas ymedidas paramitigar elriesgo utili-zando unanalisisdinamico.

En la etapade disenode alto nivelse puntualizaen la estruc-tura internadel sistema(como laestructurade las basesde datos,elementospara las tran-sacciones ycomunica-ciones).

Los disenado-res arquitec-tos y analistasdeben docu-mentar de for-ma clara lashipotesise identificarposibles ata-ques, para lafase de laarquitecturabasada enlas especifi-caciones delanalisis ydiseno delos riesgos.

Compromi-sos: inves-tigar lastecnologıasque satisfa-cen los re-quisitos deseguridad.Se documen-ta la super-ficie de ata-que de unaaplicacionde software.

Se tienenen cuentaciertos por-centajes devulnerabi-lidades queson inclui-das durantelas activi-dades delos reque-rimientos yel disenode actividades.

Se orientaa la eva-luacion deldiseno delsoftwarey los pro-blemas rela-cionadoscon la arqui-tectura,detectandoproblemasde maneraanticipada.

17

Tabla 1.3: Actividades de implementacion y verificacion


CLASPTSP-secure

OPEN-SAMM

Activi-dadespurebasde veri-ficaciony vali-dacion

Los equiposde desarro-llo defineny establecenuna lista delas herra-mientasaprobadapor el lıderde seguri-dad delequipo delproyecto;el equipodebe realizarun analisisestatico alcodigo fuente.

Los modulosse caracteri-zaran portener bajoacoplamientoy alta cohe-sion. Utilizaun desa-rrollo itera-tivo y larevision delcodigo.

Las actividadesconstructivasse orientanal diseno, ladefensa, y lafuncionalidad,se planteancambios arealizar en laespecificacionde requisitos,diseno o imple-mentacion paramitigar o eliminar losriesgos.

El equipode desarro-llo por logeneraltiene laexperien-cia enseguridad.Sigueny cumplenlos requisi-tos segurosde codifi-cacion,las polı-ticas ynormas.

Algunasvulnerabi-lidades sonrevisadasdurante lasactividadesde la deter-minacion derequerimien-tos y disenode activida-des y codifi-cacion

Adminis-trar vulne-rabilidadesimplicael manejode estas yde inciden-tes de segu-ridad, asıcomo larecoleccionde metricase informa-cion.

Activi-dadesdepruebasdeverifi-cacion yvalidi-cion.

El softwareya es total-mente funcio-nal. Se reali-zan pruebasal softwareen el areade la super-ficie deataque.

En las prue-bas se tienenen cuentalas especifi-caciones delsoftware, losrequerimien-tos y el dise-no de alto ni-vel. Se realizan pruebasde valoreslımites ypruebas decomporta-miento a losrequeri-mientos nofuncionales.

La prueba defuncionalidadde la seguri-dad se llevaa cabo contecnicas estan-dar de pruebasfuncionalesy pruebasde seguridad,con base enel riesgo apartir depatrones deataque. Unbuen plan depruebas deseguridad haceambas cosas.

Las pruebasse realizanpararequisitosde seguri-dad, ademasde los requi-sitos denegocio.Se pue-den ejecutarlas herra-mientas deevaluacionautomatiza-das.

Eliminalas vulnera-bilidades in-yectadas du-rante lasfases anterio-res, a partirde la revi-sion de codi-go, el anali-sis dinamico,el analisisestatico ylas pruebasde seguridad.

Verificar yvalidar elcodigo com-prende losrequerimien-tos del nego-cio relacio-nados con ladisponibili-dad, integri-dad y confi-dencialidad,ası comouna revisiondel Top 10de OWASP.

18

Tabla 1.4: S-SDLC vs. recursos y usos a nivel empresarial


CLASPTSP-secure

OPEN-SAMM

Recursos

Recurso hu-mano capa-citado y ac-tualizado enasistenciade personalde seguri-dad, tecnolo-gia y econo-mıa.

Recurso hu-mano capa-citado y ac-tualizado entecnolo-gia y econo-mıa.

Recurso hu-mano capa-citado y ac-tualizado entecnolo-gia y econo-mıa. Estametdolo-gıa es cıclicay tiene unoctavo ıtemque corres-ponde a unarevisionexterna,otra visiondel exterior.



Recurso hu-mano capa-citado y ac-tualizado entecnolo-gia y econo-mıa. Algunasherramien-tas para larevisionde codigo,comoCodeCrawler,Orion y O2.

Usoporlaempre-sa

Integracionde la ver-sion agildel SDL conmetodologıasagiles,aplicadoa un casopractico,utilizalenguajesde la suitede Microsoft.

Empresasde diferen-tes secto-res.

Empresas delos sectoresaeronautico,aeroespacial,defensa,seguridad dela informa-cion, seguri-dad y emergencias, sani-dad, transpor-te,telecomu-nicacionesy TIC.

Sectoresenergeticos.Empresasdel sectorpublicoy privado.

Pequenasy medianasempresas.

SAMM sedefinio pen-sando enla flexibi-lidad, demodo quepueda serutilizadopor lasorganiza-ciones pe-quenas,medianasy gran-des.

1.4. Modelado de amenazas

Es una herramienta formal que puede aplicarse al ciclo de vida del desarrollo de software, la cual le permiteestablecer y evaluar los riesgos y amenazas a las que puede exponerse una aplicacion de software.

Un modelo util es STRIDE (Microsoft, 2009), que puede agrupar amenazas por categorıas, como las presen-tadas en la Figura 1.7.

El modelado de amenazas STRIDE es una forma de garantizar que las aplicaciones no sufran a la suplantacionde identidad, la manipulacion de datos, el repudio, la revelacion de informacion, la denegacion de servicios yla elevacion de privilegios. En la siguiente tabla se relacionan las amenazas con las propiedades que protegencontra ellas.

19

Figura 1.7: STRIDE

20

Ciclo de vida de desarrollo agil de software seguro

Documents

Transcript of Ciclo de vida de desarrollo agil de software seguro