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

Seguimos hoy con la cuarta entrada sobre los S-SDLC en Flu Project. La idea sigue siendo especificar y contar características de estos, y ver qué aportan frente al resto. El sexto S-SDLC que se detalla es Oracle Software Security Assurance. Este S-SDLC está compuesto de un número de actividades que se incluyen en las fases conocidas de un SDLC para garantizar la seguridad del software de la empresa Oracle. Para lograr este objetivo se disponen de 5 elementos o tareas de seguridad en el S-SDLC:

1. Manejo de vulnerabilidades.
2. Eliminación de vulnerabilidad a través de actualizaciones críticas.
3. Buenas prácticas y compartición de éstas en seguridad y codificación segura.
4. Gestión de la configuración de seguridad y herramientas de validación y verificación.
5. Comunicación de fallos de seguridad.

El manejo de vulnerabilidades se realiza en las fases de diseño, implementación y testing. La eliminación de vulnerabilidades se lleva a cabo durante todo el proceso, pero sobretodo en su parte final (puesta en marcha y testing). Las buenas prácticas se dan a los desarrolladores en la fase de requisitos y diseño. La gestión de configuración se prepara al comenzar el proyecto y cubre, fase de requisitos, diseño, implementación y testing. Por último, la comunicación de fallos de seguridad es la respuesta que pone la empresa a los usuarios, es un plan de respuesta ante incidentes cuando la aplicación se libera. 

¿Con qué nos quedamos?

Realmente elegir un modelo puede ser algunas veces algo rígido, por lo que proponemos realizar una mezcla de cosas, y sobretodo ser capaces de amoldar las cosas que nos interesan a nuestra forma de trabajar. Por ello, he visto cómo en muchas ocasiones se aplicaba el de Microsoft, aunque no siempre con todas las tareas debido a los tiempos de proyecto. Por ello, creo que el S-SDLC que cogería como base es el de Microsoft, pero modificando ciertos aspectos que creo que podrían ayudar a la mejora del proceso, al menos de forma práctica.

Mi propuesta es modificarlo de la siguiente manera:

En primer lugar, y tras definir los roles de los participantes en el proyecto, todos deben asistir a la formación en seguridad por parte de expertos en la materia. Siempre habrá una figura de security manager que tomará la decisión final sobre las posibles incidencias en temas de seguridad en el proyecto. Esta figura debe ser alguien experto en la materia y con la suficiente experiencia. El security manager realizará en paralelo con el project manager un seguimiento del proyecto. 

En todas las fases del SDLC se realizará una review de estado, es decir, desde la fase de requisitos hasta la liberación se realizará una revisión de seguridad de todo lo que se tenga hasta ese instante. Además, se extiende el modelado de amenazas a cada una de las siguientes fases  (requisitos, diseño e implementación). De este modo será incremental, y las amenazas pueden ir saliendo en cada fase poco a poco. 

Se realizarán pruebas de pentesting sobre las aplicaciones en 3 fases, después de implementar, en la de verificación y antes de liberar se pasará una nueva prueba de intrusión. Todo esto debe ser guiado por Q&A dónde se integrará un proceso de seguridad, dónde se encuentre la figura del Security Manager, y disponga de un equipo con él para llevar a cabo todo lo necesario en el proyecto. 

Y tú, ¿Cómo llevarías un S-SDLC de la teoría a la práctica?