Introduccin a los S-SDLC.

El conjunto de principios de diseo y buenas prcticas a implantar en el SDLC, para

detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adqui
sicin de aplicaciones, de forma que se obtenga software de confianza y robusto fr
ente ataques maliciosos, que realice solo las funciones para las que fue diseado,
que est libre de vulnerabilidades, ya sean intencionalmente diseadas o accidental
mente insertadas durante su ciclo de vida y se asegure su integridad, disponibil
idad y confidencialidad.
Con el continuo desarrollo es necesario avanzar de forma dinmica en las metodologa
s y procesos para insertar nuevas actividades con el objetivo de reducir el nmero
de debilidades y vulnerabilidades en el software, a este nuevo ciclo de vida co
n buenas prcticas de seguridad incluidas lo denominaremos S-SDLC
http://postgrados.unir.net/cursos/lecciones/ARCHIVOS_COMUNES/versiones_para_impr
imir/musi011/apuntesprofesort1.pdf

Descripcin 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 requ
ieren realizar software seguro. En la siguiente imagen se puede visualizar el es
quema 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 req
uisitos de seguridad existen en el proyecto, para ello puede necesitarse la part
icipacin de un asesor de seguridad en la implementacin del SDL. Se utilizar la figu
ra del asesor como gua a travs de los procedimientos del SDL. En este punto cada e
quipo de desarrollo debe tener en cuenta como requisitos las caractersticas de se
guridad para cada fase. Algunos requisitos pueden aparecer a posteriori, por eje
mplo cuando se realice el modelo de amenazas.
Las tareas de seguridad en las actividades de diseo son: los requisitos de diseo c
on sus necesidades de seguridad quedarn definidos. Se realizar documentacin sobre l
os elementos que se encuentren en la superficie de un ataque al software, y por l
timo, se realizar un modelo de amenazas, dnde pueden descubrirse nuevos requisitos
de seguridad.
Las tareas de seguridad en las actividades de implementacin son: aplicacin de los
estndares de desarrollo y de pruebas. Posteriormente se aplicar software que comp
ruebe la seguridad. Adems, se realizarn pruebas de revisin de cdigo.
Las tareas de seguridad en las pruebas de verificacin y validacin son: anlisis din
co sobre la aplicacin, revisiones de cdigo 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 revisin final
de toda la seguridad del proceso y crear un plan ejecutivo de respuesta ante in
cidentes, dnde se obtendr una retroalimentacin de todo lo que ocurre en la liberacin
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 cos
as tenemos que proteger primero o tener en cuenta. A continuacin se exponen las t
areas por orden de prioridad:
Revisin de cdigo. Tarea de anlisis de cdigo esttico, el cual debe ser escrito te
o conocimientos de seguridad y buenas prcticas de programacin. Fase de implementac
in.
Anlisis de riesgo. Esta tarea es ejecutada en tres fases y es de vital importanci
a en la toma de decisiones del proceso. Fase de requisitos, anlisis, diseo y testi
ng.
Test de intrusin (Pentesting). Tanto en la fase de testing como la liberacin de la
herramienta, este tipo de tareas pueden descubrir comportamientos anmalos 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 compor
tamiento. Fase de testing.
Requisitos de seguridad por parte de los desarrolladores. Fase de requisitos y a
nlisis.
Operaciones de seguridad.
Anlisis externo, no obligatorio. Durante todas las fases.
CLASP
Comprehensive LIghtweight Application Security Process, de OWASP. CLASP es un co
njunto de piezas, el cual podra ser integrado en otros procesos de desarrollo de
software. Tiene ciertas propiedades como son su fcil adopcin a otros entornos y la
eficiencia. Su fuerte es la riqueza de recursos de seguridad que dispone, lo cu
al deber ser implementado en las actividades del SDLC. Tiene esta fuerza debido a
que OWASP est detrs de ello.
CLASP se organiza en vistas, de las cuales dispone de cinco. A continuacin se enu
meran 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 role
s dentro de CLASP son muy importantes y existen siete: gerente, arquitecto, inge
niero de requisitos, diseador, codificador, tester y auditor de seguridad. Se pue
de 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 cump
lira CLASP.
La vista Activity-Assesment es importante, ya que identifica 24 actividades o ta
reas que pueden ejecutarse. Son tareas relacionadas con la seguridad del desarro
llo del software, como por ejemplo la identificacin de una poltica de seguridad, d
ocumentar los requisitos relevantes con la seguridad, realizacin de code-signing,
etctera.
La vista de vulnerabilidades es la encargada de clasificar los tipos de fallos d
e seguridad que se puedan encontrar en el software. Consta de 5 subgrupos.
http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_19.html

Writing Secure Code.

En la siguiente imagen se puede visualizar como este modelo se divide en etapas,
de las cuales tiene 13, y durante las distintas fases se van realizando etapas
para conseguir que la aplicacin sea segura. En la etapa inicial se habla de educa
cin al desarrollador en trminos de seguridad, esto se realiza justo antes de comen
zar las actividades de diseo de la aplicacin. Durante esta fase de diseo tambin se c
umplen las etapas de cuestiones relevantes a la seguridad y la realizacin del mod
elado de amenazas.
Una vez finalizada la fase de diseo se realiza una revisin del equipo de seguridad
del diseo de la aplicacin. En la fase de implementacin se crean documentos de segu
ridad, se preparan herramientas y se estudia las guas de buenas prcticas y codific
acin segura. En la fase de pruebas se utilizan las polticas de prueba seguras, se
revisan los fallos encontrados en el proceso hasta el momento y se realiza una r
evisin externa de la aplicacin. En la fase de mantenimiento se realiza una planifi
cacin de seguridad que indica como la empresa debe responder.

TSP-Secure
TSP extiende lo que plantea el TSP, Team Software Process, con el objetivo de co
nseguir un desarrollo de aplicaciones seguras mediante la intervencin en el proce
so de la gua ofrecida por CERT. Otro objetivo del TSP-Secure es el de conseguir q
ue las organizaciones puedan mejorar su manera de construir software seguro o de
calidad, y que ste sea compatible con el CMMI.
Los objetivos de TSP-Secure son, bsicamente tres, ser capaces de detectar los fal
los de seguridad en la generacin de cdigo (esto es aplicable al resto de S-SDLC es
tudiados en la asignatura), ser capaces de responder rpidamente ante la insercin d
e nuevas amenazas en el cdigo y promover la utilizacin de prcticas de seguridad par
a el desarrollo.
El flujo que cumple es el siguiente:

TSP-Secure necesita que se seleccione alguna (o ms de una) norma de codificacin se

gura durante la fase de requisitos. Miembros del equipo aplican pruebas de confo
rmidad, en temas de seguridad de la aplicacin, como parte del propio proceso de d
esarrollo, esto se va realizando en cada fase del SDLC, con el fin de verificar
que el cdigo es seguro.
El TSP-Secure dispone de planificacin, procesamiento, calidad, medicin y seguimien
to de los marcos de TSP. Esto hace que el desarrollo de aplicaciones seguras se
genere satisfaciendo un nivel 3 de madurez en CMMI.
http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_27.html

Oracle Software Security Assurance.

Este S-SDLC est compuesto de un nmero de actividades que se incluyen en las fases
conocidas de un SDLC para garantizar la seguridad del software de la empresa Ora
cle. Para lograr este objetivo se disponen de 5 elementos o tareas de seguridad
en el S-SDLC:
1. Manejo de vulnerabilidades.
2. Eliminacin de vulnerabilidad a travs de actualizaciones crticas.
3. Buenas prcticas y comparticin de stas en seguridad y codificacin segura.
4. Gestin de la configuracin de seguridad y herramientas de validacin y verifi
cacin.
5. Comunicacin de fallos de seguridad.
El manejo de vulnerabilidades se realiza en las fases de diseo, implementacin y te
sting. La eliminacin de vulnerabilidades se lleva a cabo durante todo el proceso,
pero sobretodo en su parte final (puesta en marcha y testing). Las buenas prctic
as se dan a los desarrolladores en la fase de requisitos y diseo. La gestin de con
figuracin se prepara al comenzar el proyecto y cubre, necesita que se seleccione
alguna (o ms de una) norma de codificacin segura durante la fase de requisitos, di
seo, implementacin y testing. Por ltimo, la comunicacin de fallos de seguridad es la
respuesta que pone la empresa a los usuarios, es un plan de respuesta ante inci
dentes cuando la aplicacin se libera.
http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_29.html