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 adqui sición 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 diseñado, que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas 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 dinámica en las metodología s 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 co n buenas prácticas de seguridad incluidas lo denominaremos S-SDLC http://postgrados.unir.net/cursos/lecciones/AR http://postgrados.unir .net/cursos/lecciones/ARCHIVOS_COMUNES/versiones_ CHIVOS_COMUNES/versiones_para_impr para_impr imir/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 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 prim primer er luga lugar r se se debe debe form formar ar a los los desa desarr rrol olla lado dore res s en en seg segur urid idad ad para para que que todo todos s los componentes se desarrollen conociendo las amenazas. · Las Las tar tarea eas s de de segu seguri rida dad d en en las las acti activi vida dade des s de requ requis isit itos os son: son: esta establ blec ecer er que que req req uisitos de seguridad existen en el proyecto, para ello puede necesitarse la part icipación de un asesor de seguridad en la implementación del SDL. Se utilizará la figu ra del asesor como guía a través de los procedimientos del SDL. En este punto cada e quipo de desarrollo debe tener en cuenta como requisitos las características de se guridad para cada fase. Algunos requisitos pueden aparecer a posteriori, por eje mplo cuando se realice el modelo de amenazas. · Las Las tar tarea eas s de de seg segur urid idad ad en las las act activ ivid idad ades es de dise diseño ño son: son: los los req requi uisi sito tos s de de dis diseñ eño o c on sus necesidades de seguridad quedarán definidos. Se realizará documentación 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, dónde pueden descubrirse nuevos requisitos de seguridad. · Las Las tare tareas as de segu seguri rida dad d en las las acti activi vida dade des s de impl implem emen enta taci ción ón son: son: apli aplica caci ción ón de los los estándares de desarrollo y de pruebas. Posteriormente se aplicará software que comp ruebe la seguridad. Además, se realizarán pruebas de revisión de código. · Las Las tar tarea eas s de de seg segur urid idad ad en las las pru prueb ebas as de veri verifi fica caci ción ón y val valid idac ació ión n son son: : aná análi lisi sis s din din co 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 in cidentes, 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é cos as tenemos que proteger primero o tener en cuenta. A continuación se exponen las t areas por orden de prioridad: · Revisión de código. Tarea de análisis de código estático, el cual debe ser escrito te o conocimientos de seguridad y buenas prácticas de programación. Fase de implementac ión. · Análisis 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, análisis, diseño y testi ng. · 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 compor tamiento. Fase de testing. · Requisitos de seguridad por parte de los desarrolladores. Fase de requisitos y a nálisis. · Operaciones de seguridad. · Análisis externo, no obligatorio. Durante todas las fases. CLASP Comprehensive LIghtweight Application Security Process, de OWASP. CLASP es un co njunto 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 cu al 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 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, diseñador, 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 liría 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 identificación de una política de seguridad, d ocumentar 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 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 aplicación sea segura. En la etapa inicial se habla de educa ción al desarrollador en términos de seguridad, esto se realiza justo antes de comen zar las actividades de diseño de la aplicación. Durante esta fase de diseño también se c umplen las etapas de cuestiones relevantes a la seguridad y la realización del mod elado de amenazas. Una vez finalizada la fase de diseño se realiza una revisión del equipo de seguridad del diseño de la aplicación. En la fase de implementación se crean documentos de segu ridad, se preparan herramientas y se estudia las guías de buenas prácticas y codific ación segura. En la fase de pruebas se utilizan las políticas de prueba seguras, se revisan los fallos encontrados en el proceso hasta el momento y se realiza una r evisión externa de la aplicación. En la fase de mantenimiento se realiza una planifi cación 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 intervención en el proce so de la guía 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, básicamente tres, ser capaces de detectar los fal los de seguridad en la generación de código (esto es aplicable al resto de S-SDLC es tudiados en la asignatura), ser capaces de responder rápidamente ante la inserción d e nuevas amenazas en el código y promover la utilización de prácticas de seguridad par a el desarrollo. El flujo que cumple es el siguiente: TSP-Secure necesita que se seleccione alguna (o más de una) norma de codificación se gura durante la fase de requisitos. Miembros del equipo aplican pruebas de confo rmidad, en temas de seguridad de la aplicación, como parte del propio proceso de d esarrollo, esto se va realizando en cada fase del SDLC, con el fin de verificar que el código es seguro. El TSP-Secure dispone de planificación, procesamiento, calidad, medición 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 número 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. 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 verifi cación. 5. Comunicación de fallos de seguridad. El manejo de vulnerabilidades se realiza en las fases de diseño, implementación y te
sting. 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áctic as se dan a los desarrolladores en la fase de requisitos y diseño. La gestión de con figuración se prepara al comenzar el proyecto y cubre, necesita que se seleccione alguna (o más de una) norma de codificación segura durante la fase de requisitos, di señ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 inci dentes cuando la aplicación se libera. http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_29.html
