Ciclos de Vida del Software Seguros (S-SDLC) (Parte II)

En el artículo de hoy seguimos avanzando en otros S-SDLC que podemos encontrar y utilizar en nuestros ciclos de vida de desarrollo de software. En el artículo anterior se presentaban los conceptos y el S-SDLC de Microsoft, el cual es uno de los más utilizados. 

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 (code review). 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 view.

• Activity-Implementation view.

• Vulnerability view.

Todas las vistas se interconectan entre sí, y este detalle es importante. Los roles dentro de CLASP son muy importantes y existen siete: gerente, arquitecto, ingeniero de requisitos, diseñador, codificador, tester y auditor de seguridad. Se puede ver que la seguridad se encuentra incluida, con una figura importante, dentro del proceso. Todos los roles deben estar en cualquier proyecto, sino no se cumpliría CLASP.

La vista Activity-Assesment es importante, ya que identifica 24 actividades o tareas que pueden ejecutarse. Son tareas relacionadas con la seguridad del desarrollo del software, como por ejemplo la identificación de una política de seguridad, documentar los requisitos relevantes con la seguridad, realización de code-signing, etcétera. 

La vista de vulnerabilidades es la encargada de clasificar los tipos de fallos de seguridad que se puedan encontrar en el software. Consta de 5 subgrupos.

En el próximo artículo seguiremos hablando de otros S-SDLC que nos ayudan en nuestros desarrollos.