Comparación De Ciclos De Vida De Desarrollo De Software Seguro (S-SDLC)

Introducción a los S-SDLC.

El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC, para detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adquisición de aplicaciones, de forma que se obtenga software de confianza y robusto frente ataques maliciosos, que realice solo las funciones para las que fue diseñado, que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o accidentalmente insertadas durante su ciclo de vida y se asegure su integridad, disponibilidad y confidencialidad.

Con el continuo desarrollo es necesario avanzar de forma dinámica en las metodologías y procesos para insertar nuevas actividades con el objetivo de reducir el número de debilidades y vulnerabilidades en el software, a este nuevo ciclo de vida con buenas prácticas de seguridad incluidas lo denominaremos S-SDLC

http://postgrados.unir.net/cursos/lecciones/ARCHIVOS_COMUNES/versiones_para_imprimir/musi011/apuntesprofesort1.pdf

Descripción resumida de los diferentes tipos de S-SDLC.

Microsoft Trustworthy Computing SDL

Este ciclo de vida es bastante popular y muy utilizado por las empresas que requieren realizar software seguro. En la siguiente imagen se puede visualizar el esquema del S-SDLC:

Las tareas que se llevan a cabo son las siguientes:

• En primer lugar se debe formar a los desarrolladores en seguridad para que todos los componentes se desarrollen conociendo las amenazas.

• Las tareas de seguridad en las actividades de requisitos son: establecer que requisitos de seguridad existen en el proyecto, para ello puede necesitarse la participación de un asesor de seguridad en la implementación del SDL. Se utilizará la figura del asesor como guía a través de los procedimientos del SDL. En este punto cada equipo de desarrollo debe tener en cuenta como requisitos las características de seguridad para cada fase. Algunos requisitos pueden aparecer a posteriori, por ejemplo cuando se realice el modelo de amenazas.

• Las tareas de seguridad en las actividades de diseño son: los requisitos de diseño con sus necesidades de seguridad quedarán definidos. Se realizará documentación sobre los elementos que se encuentren en la superficie de un ataque al software, y por último, se realizará un modelo de amenazas, dónde pueden descubrirse nuevos requisitos de seguridad.

• Las tareas de seguridad en las actividades de implementación son: aplicación de los estándares de desarrollo y de pruebas. Posteriormente se aplicará software que compruebe la seguridad. Además, se realizarán pruebas de revisión de código.

• Las tareas de seguridad en las pruebas de verificación y validación son: análisis dinámico sobre la aplicación, revisiones de código desde el punto de vista de la seguridad y pruebas centradas en la seguridad del software.

• Se necesita generar un plan de incidentes al final del proceso, una revisión final de toda la seguridad del proceso y crear un plan ejecutivo de respuesta ante incidentes, dónde se obtendrá una retroalimentación de todo lo que ocurre en la liberación del software.

http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s.html

McGraw's

Propone unas prioridades para las tareas de seguridad y de este modo saber qué cosas tenemos que proteger primero o tener en cuenta. A continuación se exponen las tareas por orden de prioridad:

• Revisión de código. Tarea de análisis de código estático, el cual debe ser escrito teniendo conocimientos de seguridad y buenas prácticas de programación. Fase de implementación.

• Análisis de riesgo. Esta tarea es ejecutada en tres fases y es de vital importancia en la toma de decisiones del proceso. Fase de requisitos, análisis, diseño y testing.

• Test de intrusión (Pentesting). Tanto en la fase de testing como la liberación de la herramienta, este tipo de tareas pueden descubrir comportamientos anómalos en la herramienta. Fase de testing.

• Test de caja negra basados en riesgos. Fase de testing.

• Casos de abuso o fuzzing a los inputs de la herramienta para comprobar su comportamiento. Fase de testing.

• Requisitos de seguridad por parte de los desarrolladores. Fase de requisitos y análisis.

• Operaciones de seguridad.

• Análisis externo, no obligatorio. Durante todas las fases.

CLASP

Comprehensive LIghtweight Application Security Process, de OWASP. CLASP es un conjunto de piezas, el cual podría ser integrado en otros procesos de desarrollo de software. Tiene ciertas propiedades como son su fácil adopción a otros entornos y la eficiencia. Su fuerte es la riqueza de recursos de seguridad que dispone, lo cual deberá ser implementado en las actividades del SDLC. Tiene esta fuerza debido a que OWASP está detrás de ello.

CLASP se organiza en vistas, de las cuales dispone de cinco. A continuación se enumeran las distintas vistas:

• Concepts view

• Role-Based view.

• Activity-Assesment

...