�����������������������������������������������������������������������������������������

���������������������������������������������������������������������������������

Metodolog�as de desarrollo de software seguro con propiedades agiles

Secure software development methodologies with agile properties

Metodologias seguras de desenvolvimento de software com propriedades �geis

Samuel Alfredo L�pez-Rodr�guez ^I

samu.lpz@gmail.com

�https://orcid.org/0000-0001-8848-537X��

V�ctor Ren� Garc�a-Pe�a ^II

sercomgar@hotmail.com

https://orcid.org/0000-0002-3088-3559 ���

Correspondencia: samu.lpz@gmail.com

Ciencias Sociales y Pol�ticas

Art�culo de investigaci�n

*Recibido: 01 de septiembre de 2020 *Aceptado: 23 de septiembre 2020 * Publicado: 28 de octubre de 2020

       I.            Master Universitario en Ingenier�a de Software y Sistemas Inform�ticos, Ingeniero en Sistemas, Actividades de Docencia en la Metodolog�a Aprendizaje Basado en Proyectos ABP, Universidad Laica Eloy Alfaro de Manab�, Manta, Ecuador.

    II.            �Diploma Superior en Dise�o Curricular por Competencias, Magister en Redes de Comunicaciones, Ingeniero en Sistemas e Inform�tica, Licenciado en Sistemas Computacionales, T�cnico Ejecutivo Analista de Sistemas, Tecn�logo en Computaci�n e Inform�tica, Universidad Laica Eloy Alfaro de Manab�, Manta, Ecuador.

Resumen

Actualmente los avances tecnol�gicos est�n acelerando la construcci�n vertiginosa de software, estos se encargan de procesar grandes vol�menes de datos sensibles ya sea de personas o de organizaciones, aquello hace que la seguridad del software ya no sea considerada como un requisito no funcional, es ahora un elemento de suma importancia. Los ciberdelincuentes se han convertidos en expertos en perpetrar ataques por medio de la explotaci�n de vulnerabilidades en el software, se hace necesario analizar las nuevas tendencias en cuanto a su construcci�n mediante la implementaci�n de metodolog�as de desarrollo seguro. La seguridad es un tema que inquieta a investigadores y desarrolladores, que buscan un producto con el menor n�mero de vulnerabilidades posible, pero a su vez tambi�n buscan un m�todo de desarrollo �gil, por lo tanto, buscan implementar estas metodolog�as, pero no es f�cil identificar las diferencias entre cada una de ellas, puesto que son variadas y complejas. Se observa entonces la importancia de investigar las metodolog�as de desarrollo para obtener un producto software m�s seguro, en base a esto se plante� el objetivo de analizar las metodolog�as de desarrollo seguro, mediante la recolecci�n y tratamiento de la literatura correspondiente, un an�lisis comparativo de sus caracter�sticas y su exposici�n en el desarrollo. Como conclusi�n principal se corrobora la existencia de diferentes metodolog�as que se enfocan en la seguridad, pero de acuerdo a la bibliograf�a consultada solo las metodolog�as de desarrollo seguro Microsoft SDL y BSIMM poseen propiedades agiles.

Palabras Clave: Tecnolog�a de la Informaci�n y comunicaci�n; seguridad inform�tica; Metodolog�as; software; desarrollo.

Abstract

Currently technological advances are accelerating the rapid construction of software, these are responsible for processing large volumes of sensitive data either from individuals or organizations, that makes software security is no longer considered as a non-functional requirement, it is now an element of paramount importance. Cybercriminals have become experts in perpetrating attacks by exploiting vulnerabilities in software, it is necessary to analyze new trends in terms of its construction through the implementation of secure development methodologies. Security is an issue that worries researchers and developers, who seek a product with as few vulnerabilities as possible, but in turn also seek an agile development method, therefore, they seek to implement these methodologies, but it is not easy to identify the differences between each of them, since they are varied and complex. It is then observed the importance of investigating the development methodologies to obtain a more secure software product, based on this, the objective of analyzing the secure development methodologies was raised, through the collection and treatment of the corresponding literature, a comparative analysis of their characteristics and their exposure in the development. As main conclusion it is corroborated the existence of different methodologies that focus on security, but according to the consulted bibliography only the secure development methodologies Microsoft SDL and BSIMM have agile properties.

Keywords: Information and communication technology; information security; methodologies; software; development.

Resumo

Atualmente os avan�os tecnol�gicos est�o acelerando a r�pida constru��o de software, estes s�o respons�veis pelo processamento de grandes volumes de dados sens�veis de indiv�duos ou organiza��es, o que faz com que a seguran�a de software n�o seja mais considerada como um requisito n�o funcional, � agora um elemento de suma import�ncia. Os cibercriminosos se tornaram especialistas em perpetrar ataques explorando vulnerabilidades em software, � necess�rio analisar novas tend�ncias em termos de sua constru��o atrav�s da implementa��o de metodologias seguras de desenvolvimento. A seguran�a � uma quest�o que preocupa pesquisadores e desenvolvedores, que buscam um produto com o m�nimo de vulnerabilidades poss�vel, mas por sua vez tamb�m buscam um m�todo de desenvolvimento �gil, portanto, procuram implementar estas metodologias, mas n�o � f�cil identificar as diferen�as entre cada uma delas, uma vez que s�o variadas e complexas. Observa-se ent�o a import�ncia de investigar as metodologias de desenvolvimento para obter um produto de software mais seguro, com base nisso o objetivo de analisar as metodologias de desenvolvimento seguro foi levantado, atrav�s da coleta e tratamento da literatura correspondente, uma an�lise comparativa de suas caracter�sticas e sua exposi��o no desenvolvimento. Como principal conclus�o, � corroborada a exist�ncia de diferentes metodologias com foco na seguran�a, mas de acordo com a bibliografia consultada, apenas as metodologias de desenvolvimento seguro Microsoft SDL e BSIMM possuem propriedades �geis.

Palavras-chave: Tecnologia da informa��o e comunica��o; seguran�a inform�tica; metodolog�as; software; desenvolvimento.

Introducci�n

Las metodolog�as de desarrollo se originan como una respuesta a la crisis de los a�os 70 que desencadeno un conjunto de problemas relacionados al proceso de construcci�n de un producto software eficaz, de calidad y a tiempo, existen numerosas metodolog�as dotadas con variadas caracter�sticas que las lleva a afrontar el desarrollo de software de diferentes formas, buscando obtener un producto de calidad, al pasar los a�os algunas de ellas han quedado obsoletas y no responden a los nuevos desaf�os, la realidad actual exige la construcci�n guiada por m�todos adaptables a los cambios basados en la seguridad y agilidad.

Los cambios de requisitos de un producto software cuando se solicita su construcci�n y adem�s cuando est� en plena etapa de desarrollo, conlleva la utilizaci�n de metodolog�as modernas que dejen atr�s las tradicionales, debido a que sus conceptos son muy r�gidos, no permiten la adaptabilidad y no toman en cuenta la seguridad, en consecuencia, estas no permiten satisfacer las necesidades del cliente. Para afrontar esta problem�tica se han establecido metodolog�as que usan t�cnicas agiles, que disminuyen el tiempo de fabricaci�n del producto software, fallos t�cnicos, vulnerabilidades, rigidez al cambio de requisitos y a la evoluci�n.

Un producto software puede ser vulnerable, ya sea por propios fallos de construcci�n o por ataques provocados, para conseguir la disminuci�n de vulnerabilidades y que el producto sea considerado seguro, se deben aplicar medidas como la integraci�n de conceptos de seguridad en todas sus etapas de elaboraci�n. Al utilizar una metodolog�a de construcci�n que permita integrar la seguridad desde el ciclo de vida del software, se busca conseguir un producto robusto de confianza, que realice solo las funciones para lo que fue creado, minimizando comportamientos inesperados de manera que se asegure la integridad, confiabilidad y confidencialidad.

El prop�sito del presente art�culo es analizar las metodolog�as seguras, que aplican conceptos de seguridad en el ciclo de vida del software, y que cuenten con propiedades para construir un software de forma �gil,� para ello se llev� a cabo una comparativa obteniendo como resultado que existen numerosas metodolog�as que se enfocan espec�ficamente en la seguridad, pero de acuerdo a la bibliograf�a consultada solo las metodolog�as Microsoft SDL y BSIMM aplican la seguridad y adem�s tienen propiedades agiles.

Materiales y m�todos

El tipo de investigaci�n llevada a cabo fue de tipo hermen�utica, descriptiva y heur�stica, con el prop�sito de seleccionar y analizar varias fuentes documentales cient�ficas, la informaci�n concerniente se someti� a un proceso de exploraci�n, revisi�n bibliogr�fica, resumen y descripci�n (Guirao et al., 2008). El trabajo expondr� una comparativa de las metodolog�as de desarrollo de software seguro para lo cual se han realizado las siguientes etapas:

Etapa 1. Investigaci�n de estudios previos, relacionados al tema obtenidos de fuentes bibliogr�ficas.

Etapa 2. Selecci�n y tratamiento de la informaci�n sobre las diferentes metodolog�as encontradas.

Etapa 3. An�lisis comparativo de la informaci�n seleccionada y comprobaci�n de ella.

Etapa 4. Obtenci�n de la discusi�n y establecimiento de la conclusi�n sobre las metodolog�as de desarrollo de software seguro.

Microsoft Trustworthy Computing SDL

Microsoft ha establecido formalmente su desarrollo de software de seguridad mejorando el proceso SDL, durante sus "empujes de seguridad" de 2002, modificando sus procesos tradicionales de desarrollo de software integrando tareas y puestos de control destinados expresamente a mejorar la seguridad del software producidos por esos procesos, persiguiendo como prop�sito disminuir los defectos de dise�o y el� nivel de da�o de cualquier falla de sus productos (Pradeep, 2014).

Microsoft ha declarado que su software desarrollado bajo el proceso SDL Inicialmente demostrado una reducci�n del 50 por ciento en los boletines de sus principales productos en comparaci�n con versiones de los mismos productos desarrollados antes de SDL; Las estimaciones m�s recientes de Microsoft demandan hasta un 87 por ciento en los boletines de seguridad (Goertzel et al., 2007).

Modelo del proceso SDL optimizado de Microsoft

El modelo de Microsoft fue creado considerando variables como el tama�o de la organizaci�n, sus recursos, la parte directiva adem�s de tomar en cuenta que el desarrollo seguro es un proceso que puede resultar costoso y complicado adem�s de causar preocupaciones de c�mo aplicarlo, las fases del modelo son (Microsoft Corporation, 2010):

�         Formaci�n, directivas y capacidades organizativas

�         Requisitos y dise�o

�         Implementaci�n

�         Comprobaci�n

�         Lanzamiento y respuesta

Actividades de seguridad de SDL simplificadas.

�         Las actividades propuestas implementadas como parte del proceso de desarrollo del software aportan beneficios en materia de seguridad, adem�s es viable a�adir actividades opcionales que quedan a juicio del asesor o equipo de seguridad.

Ilustraci�n 1: Ciclo de vida de desarrollo de software de Microsoft: simplificado

Oracle Software Security Assurance Process

Oracle Corporation afirma haber adoptado un proceso de desarrollo seguro en el que todos los desarrolladores est�n obligados a seguir normas de codificaci�n segura y utilizar bibliotecas est�ndar de funciones de seguridad (autenticaci�n, criptograf�a), y realizar pruebas de seguridad extensivas que incluyen pruebas de penetraci�n, exploraci�n automatizada de vulnerabilidades, validaciones contra listas de verificaci�n de seguridad y seguridad de terceros (gobierno e industria). Sus productos se env�an con gu�as de configuraci�n seguras y las pr�cticas de gesti�n de la vulnerabilidad incluyen parches cr�ticos correcciones a la base de c�digo principal, las cuales se utilizan para informar las revisiones (Oracle, 2020). Oracle Software Security Assurance (OSSA) es una metodolog�a de desarrollo seguro que incluye la seguridad en todas las fases del ciclo de vida del desarrollo de software, abarca el dise�o y arquitectura, construcci�n, pruebas y mantenimiento de todos sus productos (Oracle Corporation, 2014).

Oracle ha formado a sus profesionales en la utilizaci�n de las normas de codificaci�n seguras de conocimiento general en las �reas de principios, dise�os y vulnerabilidades frecuentes para aportar una gu�a en cuestiones como la privacidad y validaci�n de datos, administraci�n de los usuarios. Los est�ndares deben estar aplicados en el dise�o y construcci�n de sus productos, las normas de seguridad se han desarrollado por a�os e incorporan las mejores pr�cticas, as� como las lecciones aprendidas de las pruebas de vulnerabilidades, adem�s la metodolog�a permite la evaluaci�n, pruebas y an�lisis de todos sus productos a lo largo de su vida �til (Oracle Corporation, 2014).

La pruebas y an�lisis incluyen tanto de sus componentes funcionales como aquellos no funcionales con la finalidad de verificar las caracter�sticas y la calidad del producto, se desarrollan diversos tipos de pruebas a las diferentes caracter�sticas de producto. Las pruebas funcionales son ejecutadas t�picamente por equipos de control de calidad, los cuales verifican las caracter�sticas de seguridad que previamente se hab�an planificado (Oracle Corporation, 2014).

Oracle utiliza el software Critical Patch Update para actualizar sus productos mediante parches cr�ticos de seguridad que son lanzados incluso fuera del plazo, como alternativa en caso de vulnerabilidades particularmente criticas tambi�n ofrecen instrucciones y procedimientos para el manejo de ellas, esto proporciona ventajas a los clientes como (Oracle Corporation, 2014):

�         Seguridad m�xima. Las vulnerabilidades son remediadas por orden de severidad, las vulnerabilidades m�s cr�ticas son corregidas por actualizaciones de parches.

�         Menores costos de administraci�n. Mediante un plan de revisi�n de seguridad fijo se revisa el funcionamiento del producto y de los parches.

�         Administraci�n simplificada de parches: las actualizaciones de parches son acumulativas.

CLASP

Desarrollado por el experto en seguridad de software John Viega, arquitecto jefe de seguridad y vicepresidente de McAfee, Inc., Comprehensive, Lightweight Application Security Process (CLASP), est� metodolog�a fue dise�ada para insertar seguridad en cada fase del ciclo de vida. CLASP ha sido puesto en libertad bajo licencia de c�digo abierto. Su principal caracter�stica es un conjunto de 30 actividades que se centran en la seguridad, estas pueden integrarse en el proceso de desarrollo de cualquier proyecto. CLASP brinda un enfoque prescriptivo y proporciona documentaci�n continua de actividades que las organizaciones deben realizar para mejorar la seguridad. Algunas de las 30 actividades clave incluyen lo siguiente (OWASP, 2016):

�         Monitorizar las m�tricas de seguridad

�         Identificar las funciones y los requisitos del usuario

�         Investiga y eval�a las soluciones de seguridad

�         Realizar an�lisis de seguridad del dise�o del sistema

�         Identificar e implementar pruebas de seguridad.

Seven Touchpoints for Software Security

En su libro Building Security, Gary McGraw describe 7 puntos e identifica a su juicio las pr�cticas de seguridad m�s destacadas que ser�n aplicadas a los artefactos en cada fase de desarrollo, estos puntos de contacto basados en la efectividad y experiencia se ordenan de la siguiente manera: (McGraw G. R., 2006).

�         Revisi�n del c�digo (los errores)

�         An�lisis de riesgo arquitect�nico (defectos encontrados)

�         Pruebas de penetraci�n

�         Pruebas de seguridad basados en el riesgo

�         Casos de abuso

�         Requisitos de seguridad

�         Operaciones de seguridad

Conjuntamente con los siete puntos de contacto, McGraw menciona otro, este �Bonus� es el octavo y consiste en un an�lisis externo, este punto ser� realizado de forma independiente y consistir� en la realizaci�n de pruebas, evaluaciones y revisiones del software (Goertzel et al., 2007).

TSP-Secure

El Centro de Coordinaci�n del instituto de ingenier�a de software (SEI) y el Equipo de respuesta de emergencia inform�tica (CERT) de la Universidad Carnegie Mellon CMU (CERT / CC) desarroll� el equipo proceso de software para desarrollo de software seguro (TSP-Secure). Los objetivos de TSP-Secure son reducir o eliminar las vulnerabilidades resultado de errores de dise�o e implementaci�n de las aplicaciones, y proporcionar la capacidad de predecir posibles vulnerabilidades en el software entregado (Davis, 2006). Construido en el TSP de SEI, la filosof�a central de TSP-Secure incorpora dos valores fundamentales (Goertzel et al., 2007):

1.      Los ingenieros y gerentes deben establecer y mantener un ambiente de trabajo en equipo. Los procesos operativos de TSP ayudan a crear ingenier�a y fomentar un entorno orientado al equipo.

2.      TSP est� dise�ado para guiar a los ingenieros a trav�s del proceso de ingenier�a, se reduzca la probabilidad de que inadvertidamente salte pasos, organizar pasos en un orden improductivo, o pasar tiempo innecesario averiguando el siguiente movimiento.

Es una metodolog�a que se cre� con el objetivo de crear un producto en de muy alta calidad en poco tiempo, se enfoca en el trabajo en equipo, en el rendimiento y en aprovechar eficientemente los recursos. TSP cuenta con un c�mulo de procesos bien definidos que muestran lo que se debe realizar en cada etapa y como esta se conecta con otra.

Building Security In Maturity Model (BSIMM)

Es una metodolog�a que naci� como una iniciativa del estudio de la seguridad en el desarrollo del software, su construcci�n se bas� en datos adquiridos en 67 propuestas de seguridad de diversas empresas. BSIMM es un apoyo para medir la seguridad puesto que por medio de esta es posible comparar y contrastar la propia seguridad con la que tienen otras empresas, estas mediciones son �tiles para planificar, estructurar y ejecutar la evoluci�n de la seguridad del software. El prop�sito de BSIMM es cuantificar las actividades con otras iniciativas de seguridad para ello utiliza un marco de referencia con una terminolog�a general para exponer los elementos m�s visibles de las iniciativas de seguridad, esto permite comparar iniciativas (McGraw, Migues, & West, 2013).

Tabla 1: Modelo de Referencia para la Seguridad del Software (MRSS)

Fuente: (McGraw, Migues, & West, 2013)

Open SAMM

Modelo de madurez para el aseguramiento de Software (SAMM) que sirve como marco de trabajo para exponer e implementar estrategias de seguridad para el software, fue definido para ser flexible y que pueda ser aplicado en toda organizaci�n, los recursos que brinda SAMM tienen como objetivo lo siguiente (Chandra, 2013).

�         Evaluar las pr�cticas de desarrollo seguro en una organizaci�n

�         Construir un programa de seguridad con etapas bien definidas

�         Mostrar mejoras concretas en el programa seguridad de aplicaciones

�         Definir y medir las actividades relacionadas a la seguridad en toda organizaci�n

Ilustraci�n 2: SAMM / Software Assurance

Fuente: (Chandra, 2013)

Appropriate and Effective Guidance in Information Security (AEGIS)

Es una metodolog�a socio t�cnica de ingenier�a de software creada para dotar de seguridad a sistemas fundamentados en modelos activos, determinaci�n de requisitos de seguridad, an�lisis de riesgo y entorno de uso. El prop�sito es dar a los desarrolladores herramientas intuitivas y simples para desarrollar un software seguro, considerando las necesidades del usuario y fomentando la seguridad (Fl�chais, 2005).

Ilustraci�n 3: Diagrama de actividad AEGIS

Fuente: (Fl�chais, 2005)

Rational Unified Process-Secure (RUPSec)

Es un modelo extendido del RUP (Proceso racional unificado) al que se le a�ade extensiones de seguridad, con el prop�sito de adicionar e integrar artefactos, actividades y roles al RUP para la captura, modelado y documentaci�n de los requisitos y amenazas de seguridad del software, garantizando que este proceso sea implementado en todas las etapas de desarrollo subsiguiente (Ayatollahzadeh et al., 2005)

La metodolog�a RUPSec propone que las actividades y artefactos se basen en los casos de uso del RUP, a�adiendo casos de mal uso de uso para despu�s desarrollar medidas que contrarrestaran las amenazas que fueron identificadas previamente con los casos de mal uso, las extensiones de seguridad al RUP se agregan a las siguientes actividades (Goertzel et al., 2007).

�         Mantener las reglas comerciales.

�         Determinar los actores del negocio y sus casos de uso, documentado los aspectos de seguridad y sus casos de uso.

�         Definir las entidades y empleados, precise el nivel de acceso de cada uno.

�         Determinar los requisitos de automatizaci�n, requisitos de seguridad empresarial y pol�ticas de seguridad.

�         Detallar los requisitos del software y definir los requisitos de seguridad.

Secure Software Development Model (SSDM)

Modelo desarrollado por el investigador Simon Adesina quie buscaba dar respuesta a los problemas de seguridad surgidos en los procesos de desarrollo de las empresas de software, el SSDM integra ingenier�a de seguridad usando un modelo unificado que integra un conjunto de t�cnicas para producir un software seguro (Sodiya et al., 2006). SSDM delimita un flujo de trabajo seguro que consta de cuatro fases:

�         Capacitaci�n en seguridad. Educar al personal en conceptos de seguridad, conciencia, conocimiento de ataques, atacantes, intenciones e inter�s de los atacantes y el conocimiento de pr�cticas seguras.

�         Modelado de amenazas. Indique a los usuarios los atributos del software, identifique a los posibles atacantes dentro del ambiente de operaci�n, as� como sus objetivos, t�cnicas, patrones y comportamientos, con la finalidad de construir un perfil del atacante. posteriormente determine las vulnerabilidades en funci�n del modelo de amenaza.

�         Especificaciones de seguridad. Enliste los posibles ataques y defina las probables medidas a tomar cuando se presenten problemas como, errores de desarrollo, implementaci�n, monitoreo de seguridad, adaptaci�n a situaciones de seguridad.

�         Revisi�n de las especificaciones de seguridad. Revisi�n, pruebas de penetraci�n de los posibles ataques identificados y los que a futuro se podr�an presentar.

Waterfall-Based Software Security Engineering Process Model

El modelo en cascada fue propuesto por Winston W. Royce en 1970, es secuencial y su progreso es hacia abajo siguiendo una lista de fase una de tras de otra, pero solo cuando se complete fase anterior se podr� seguir a la siguiente (Bassil, 2012). Ha sido modificado por (Zulkernine & Ahamed, 2016) y sugieren la integraci�n al modelo actividades de seguridad y artefactos, las actividades se exponen a continuaci�n.

Tabla 2: Waterfall-Based Software Security Engineering Process Model

Fuente: (Goertzel et al., 2007).

Viewnext

Es un modelo S-SDLC con adaptaci�n �gil propuesto por� (Caro, 2016) que aplica un concepto que se conoce como ciclo de vida de desarrollo de software seguro �gil, sin embargo, no se especifica c�mo se debe implementar, la estructura del metamodelo es la siguiente.

�                Pol�ticas: Estrategias y orientaci�n, formaci�n, definici�n de riesgos.

�                Metodolog�a SDL: Validaci�n de requisitos, modelado de amenazas, revisi�n de c�digo, revisi�n de desarrollo, Testing de seguridad, validaci�n de salidas.

�                Supervisi�n: Evaluaci�n y m�tricas, estado del proyecto

�                Observatorio: Repositorio de vulnerabilidad, observatorio de seguridad, plan de respuesta e incidentes.

An�lisis y discusi�n de resultados

Tabla 3: Comparaci�n de propuestas de seguridad

SSDL

Completa integraci�n SDL en gran medida basado en el an�lisis de riesgos y basado en un conjunto de actividades para cada fase, integrado en el paquete de desarrollo de Microsoft. Adecuado para desarrolladores de sistemas operativos y grandes empresas de software.

7 mejores pr�cticas que se pueden aplicar al SDL existente

Iniciativa de seguridad

12 mejores pr�cticas reales utilizadas por la industria con 3 niveles de madurez. Puede usarse como punto de referencia

Fuente: (Association Information, 2014)

Las propuestas en la tabla comparativa muestran que todas las contribuciones poseen pr�cticas de seguridad, con diferentes enfoques, pero tienen similitudes en cuanto a la formaci�n del personal, revisi�n de c�digo, revisi�n arquitect�nica, pruebas de penetraci�n, documentaci�n y pol�ticas de seguridad, que busca un prop�sito fabricar un producto software m�s seguro.

Tabla 4: Comparaci�n de las propuestas de seguridad m�s destacadas

Fuente: (Gerr, 2010)

En esta comparativa seg�n (Gerr, 2010)� se exponen las propuestas de seguridad de m�s popularidad, en la cual SDL termina siendo la que mayor popularidad debido a la documentaci�n existente, la utilizaci�n de menos recursos, esto indica que ser�a la m�s indicada para empezar un proyecto, pero se debe considerar que no todos los proyectos son iguales y no todas las organizaciones se acoplan a los diferentes m�todos, as� que pueden existir diferencias pero tienen en com�n ser las m�s conocidas, documentadas y que ofrecen la gu�a para la construcci�n de un producto seguro y robusto.

Recolectar y evaluar m�tricas, mejorar la estrategia de medici�n

Modelado riguroso y completo de amenazas. En el nivel de dise�o detallado: evaluar el impacto del proyecto en la privacidad del usuario y la reducci�n de la superficie de ataque

El enfoque principal est� en el modelo de amenaza: identificaci�n de amenazas y evaluaci�n de riesgos

Implementaci�n y prueba

Aparte de las pautas de codificaci�n segura, SDL no tiene actividades de implementaci�n reales. Enfoque en pruebas de seguridad, sombrero mayormente negro

Enfatiza la importancia de las pruebas de seguridad: tres de los siete puntos de contacto se ocupan de las pruebas de seguridad. Prueba de sombrero blanco y sombrero negro.

Se centra en el plan de respuesta que define qu� hacer cuando se descubre una nueva vulnerabilidad. La comunicaci�n con el cliente es importante

Tabla 5: Comparaci�n entre SDL y Touchpoints

Fuente: Adaptado de (Tiirik, 2013)

De la tabla comparativa se extrae lo siguiente:

�         SDL es m�s r�gido, cuenta con un conjunto de procesos y actividades bien definidos mientras que touchpoints es m�s ligero y adaptable.

�         La educaci�n en seguridad del software es un punto fuerte de SDL el equipo de desarrollo debe estar bien entrenado, mientras que en touchpoints el entrenamiento no es algo fundamental, pero se reconoce su importancia.

�         SDL describe de c�mo organizar el personal que est� inmerso en el proyecto, mientras que touchpoints maneja una estrategia de medici�n contante mediante m�tricas.

�         En la fase de an�lisis y requisitos SDL enfatiza la importancia de la codificaci�n segura y utiliza escenarios para realizar el modelado de amenazas, mientras que touchpoints se enfatiza en pruebas de seguridad como caja blanca y caja negra.

�         La etapa final del proyecto tanto SDL como touchpoints realizan revisiones de seguridad mientras que la primera realiza pruebas de caja negra y una revisi�n de seguridad final, touchpoints usa caja negra y caja blanca, las dos se destacan por la utilizaci�n de herramientas automatizadas de revisi�n de c�digo.

Tabla 6: An�lisis comparativo de S-SDLC a nivel de recursos, artefactos, propiedades �giles y uso

Fuente: Adaptado de (Mohino et al., 2019)

Cada metodolog�a expuesta se fundamenta en la seguridad, pero solo dos resaltan en su uso en la industria y que cuentan con propiedades agiles, Microsoft SDL y BSIMM.

Discusi�n

La inc�gnita planteada en esta investigaci�n sali� del prop�sito de conocer las metodolog�as seguras que tengan propiedades agiles, se analiz� la bibliograf�a y se hizo una comparativa, destacando las propiedades y actividades principales de las metodolog�as seguras. Las metodolog�as Microsoft SDL con su proceso simplificado �gil donde se incluyen actividades de seguridad y BSIMM que tiene atributos agiles que se adaptan a las tendencias del mercado, son las metodolog�as seguras que tienen propiedades agiles, pero (Mohino et al., 2019) desatacan tambi�n Viewnext, propuesta que no se especifica como debe implementarse y que todav�a no reporta uso en el mercado, raz�n por la cual no podr�a ser usada en los actuales momentos, puesto que como menciona (R�os & Suntaxi, 2008) para seleccionar una metodolog�a es necesario que el equipo tenga un grado de conocimiento, adem�s (Carvajal, 2008) tambi�n destaca que es necesario que exista documentaci�n, certificaci�n y formaci�n, por estos motivos esta no ser�a una opci�n para comenzar a construir software seguro de forma �gil.�

En cuanto a que metodolog�a segura es mejor que otra (Goertzel et al., 2007) definen 9 metodolog�as que han sido exitosas en m�ltiples proyectos a nivel mundial y que en ellas se aplica un modelo est�ndar de ciclo de vida, todas se fundamentan en la incorporaci�n de pr�cticas de seguridad. (Hudaib et al., 2017) mencionan que elegir un proceso de desarrollo es un verdadero desaf�o sin conocer la diferencia entre ellas, y como menciona (Brito Abundis, 2013) la mejor metodolog�a es aquella que se adapta al contexto, lo cierto es que el �xito y buenos resultados que pueda tener una metodolog�a, depender� del producto a fabricar y de algunos criterios como el grado de formaci�n y conocimiento del equipo, documentaci�n disponible y certificaci�n de la metodolog�a.

Por ultimo existen varios estudios y publicaciones en donde se utilizan metodolog�as seguras y agiles como lo es el trabajo expuesto por (Siponen et al., 2007) que indica c�mo se pueden integrar las funciones de seguridad en un m�todo �gil llamado desarrollo basado en caracter�sticas, mientras que (Ge et al., 2006) presenta un proceso �gil para producir aplicaciones web seguras pero indican adem�s que la investigaci�n que lleva a cabo no es el desarrollo de un nuevo m�todo o proceso que se ocupa de cuestiones de seguridad, por el contrario se investig� los m�todos de desarrollo y se los integro para abordar el desarrollo de aplicaciones web seguras, confirm�ndose la necesidad de crear nuevas metodolog�as que integren la seguridad y agilidad al proceso de desarrollo.

Las opiniones de los autores y los resultados obtenidos en el an�lisis de las diferentes metodolog�as seguras, resaltan que las metodolog�as de desarrollo seguras m�s �ptimas para construir un producto software seguro de forma �gil son Microsoft SDL y BSIMM, debido a sus actividades de seguridad, popularidad, uso en la industria, documentaci�n, facilidad de implementaci�n, y sus propiedades ag�lales.

Conclusiones

En la actualidad existen varias metodolog�as de desarrollo seguro, muchas de estas comparten procesos semejantes y sus pr�cticas de seguridad son muy similares, buscan que el producto software sea desarrollado con el menor n�mero de vulnerabilidades, adem�s que las organizaciones y usuarios cuenten con una capa de protecci�n ante posibles ataques.

El estudio de las metodolog�as demostr� la posibilidad de mejorar la forma en c�mo se construye software a�adi�ndole la seguridad y sus caracter�sticas junto con las t�cnicas agiles al proceso de desarrollo, permitiendo la construcci�n de productos software de calidad que pueden acoplarse en entornos altamente cambiantes conservando la seguridad.

Las metodolog�as Microsoft SDL y BSIMM se enfocan en la seguridad y poseen propiedades agiles, siendo las alternativas m�s �ptimas para la construcci�n de un producto de calidad, siguiendo pr�cticas de seguridad y agilidad, est�n bien documentadas, certificadas y son muy utilizadas en la industria.�

Referencias

1.           Association Information. (2014). Software Design and Development: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications. IGI Global.

2.           Ayatollahzadeh, M., Jaferian, P., Elahi, G., Baghi, H., & Sadeghian, B. (2005). RUPSec: An Extension on RUP for Developing Secure Systems - Requirements Discipline. PWASET, 208-212.

3.           Bassil, Y. (2012). A Simulation Model for the Waterfall Software Development Life Cycle. ArXiv.

4.           Brito Abundis, C. J. (2013). Metodolog�as para desarrollar software. ReCIBE.

5.           Caro, A. (2016). Modelos de Desarrollo Seguro del Software. Obtenido de http://web.fdi.ucm.es/posgrado/conferencias/AndresCaroLindo-slides.pdf

6.           Carvajal, J. (2008). Metodolog�as �giles: Herramientas y Modelo de desarrollo para aplicaciones Java EE como metodolog�a empresarial. Obtenido de https://upcommons.upc.edu/handle/2099.1/5608?locale-attribute=es

7.           Chandra, P. (2013). Software Assurance Maturity Model. San Fransisco: OWASP.

8.           Davis, N. (2006). CISA. Obtenido de https://us-cert.cisa.gov/bsi/articles/knowledge/sdlc-process/secure-software-development-life-cycle-processes#tsp

9.           Fl�chais, I. (2005). Designing Secure and Usable Systems. University College of London, 57-59.

10.       Ge, X., Paige, R., Polack, F., Howard, C., & Brooke, P. (2006). Agile development of secure web applications. ICWE '06 Proceedings of the 6th international conference on Web engineering.

11.       Gerr, D. (2010). Companies Actually Using Secure Development Life Cycles? Computer Society.

12.       Goertzel, K. M., Winograd, T., McKinley, H. L., Oh, L. J., Colon, M., McGibbon, T., . . . Vienneau, R. (2007). Software Security Assurance. ATAC , DACS.

13.       Guirao-Goris, J., Olmedo Salas, A., & Ferrer Ferrandis, E. (2008). El art�culo de revisi�n. Revista Iberoamericana de Enfermeria Comunitaria, 15-25.

14.       Hudaib, A., AlShraideh, M., Surakhi, O., & Khanafseh, M. (2017). A Survey on Design Methods for Secure Software Development. International journal of Computersand Technology, 1047-7062.

15.       Laskowski, J. (2011). Agile IT Security Implementation Methodology. Reino Unido: Packt Publishing Ltd.

16.       McGraw, G. R. (2006). Software Security: Building Security In Addison-Wesley Software Security. Pearson Education.

17.       McGraw, G., Migues, S., & West, J. (2013). Bsimm. Obtenido de http://www.fundacionsadosky.org.ar/wp-content/uploads/2014/07/BSIMM-V-esp.pdf

18.       Microsoft Corporation. (2010). Microsoft Corporation. Obtenido de https://www.microsoft.com/en-us/sdl/default.aspx

19.       Mohino, J. d., Higuera, J. B., & Higuera, J. R. (2019). The Application of a New Secure Software Development Life Cycle (S-SDLC) with Agile Methodologies. Electronics, 04-06.

20.       Oracle. (2020). Oracle Software Security Assurance. Obtenido de https://www.oracle.com/es/corporate/security-practices/assurance/

21.       Oracle Corporation. (2014). Oracle. Obtenido de http://www.oracle.com/us/support/library/software-security-assurance-2293569.pdf

22.       OWASP. (2016). OWASP. Obtenido de https://www.owasp.org/index.php/CLASP_Concepts

23.       Pradeep, V. (2014). MSPoweruser. Obtenido de https://mspoweruser.com/microsoft-talks-about-sdl-and-how-it-changed-the-security-landscape-in-the-software-industry/

24.       R�os, E., & Suntaxi, W. (2008). Desarrollo de un sistema inform�tico para los procesos de cosecha y post cosecha de la camaronera Pampas de Cayanca. Obtenido de https://bibdigital.epn.edu.ec/bitstream/15000/1072/1/CD-1905.pdf

25.       Siponen, M., Baskerville, R., & Kuivalainen, T. (2007). Extending Security in Agile Software Development Methods. Idea Group.

26.       Sodiya, A., Onashoga, S., & Ajay�, O. (2006). Towards Building Secure Software Systems . Issues in Informing Science and Information Technology , 635-645.

27.       Tiirik, K. (2013). Comparison of SDL and Touchpoints. Obtenido de https://courses.cs.ut.ee/MTAT.03.246/2013_spring/uploads/Main/essay09.pdf

28.       Zulkernine, M., & Ahamed, S. I. (2016). Software Security Engineering: Toward Unifying Software Engineering and Security Engineering. Enterprise Information Systems Assurance and System Security: Managerial and Technical, 215-236.

�2020 por los autores. Este art�culo es de acceso abierto y distribuido seg�n los t�rminos y condiciones de la licencia Creative Commons Atribuci�n-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0) (https://creativecommons.org/licenses/by-nc-sa/4.0/).

����������������������������������������������������������������������������������������������������������������������������������������������������������