El ciclo de vida de desarrollo de seguridad (SDL) es un proceso de control de seguridad orientado al desarrollo de software. Siendo una iniciativa corporativa y una directiva obligatoria desde el año 2004, SDL ha desempeñado un papel muy importante en la integración de la seguridad y de la privacidad en el software y la cultura de Microsoft. Con un enfoque tanto holístico como práctico, SDL tiene como objetivo reducir el número y la gravedad de las vulnerabilidades en el software.
¿Por qué usar SDL?
Es una manera de evitar problemas de seguridad en el desarrollo, como:
- Anticipando Fallas en el Código: esas fallas que se detectan en la ejecución de la aplicación.
- Atacantes atacan todo el código: proteger todo el desarrollo, no solo un componente. Los intrusos atacan todo el software y buscan fallas.
- No enfocarse en “hacerlo bien la próxima vez”: clásica excusa para dejar las mejoras en próximas etapas.
- Remover código viejo: el software se modifica y no hay un proceso de mejora que permita borrar código que ya no forma parte en la nueva versión.
- Eliminar funciones antiguas: mejoradas por otras.
- Reemplazar protocolos viejos
- Problemas de perfomance: permite mejorar el desarrollo, haciéndolo mas perfomante.
- Reconocer que el código fallará y reducir la superficie de ataque.
Conceptos Básicos
El proceso SDL de Microsoft se basa en tres conceptos básicos: formación, mejora continua de los procesos y responsabilidad. La formación continua de los roles técnicos dentro de un grupo de desarrollo de software es fundamental. Si se invierte de manera apropiada en la transferencia de los conocimientos, las organizaciones podrán responder adecuadamente a los cambios que sufren las tecnologías y las amenazas. Dado que los riesgos para la seguridad no son estáticos, SDL destaca especialmente la importancia de comprender la causa y el efecto de las vulnerabilidades de seguridad y requiere una evaluación periódica de los procesos de SDL y la introducción de cambios como respuesta a los avances tecnológicos o las nuevas amenazas. Se recopilan datos para evaluar la eficacia de la formación, se usan métricas de procesos para documentar su conformidad y métricas posteriores al lanzamiento ayudan a definir los futuros cambios. Por último, SDL requiere el archivado de todos los datos necesarios para realizar el mantenimiento de una aplicación en caso de que surjan problemas. Si lo combinan con detallados planes de comunicación y de respuesta en materia de seguridad, las organizaciones podrán orientar de manera concisa y contundente a todas las partes implicadas.
El modelo de optimización de SDL está estructurado en torno a cinco áreas de capacidades que, en líneas generales, se corresponden con las fases del ciclo de vida de desarrollo de software:
1)Formación, directivas y capacidades organizativas
2) Requisitos y diseño
3) Implementación
4) Comprobación
5) Lanzamiento y respuesta
¿Donde aplicar SDL?
Es de vital importancia definir claramente las expectativas de una organización con respecto a los tipos de proyectos que se van a someter a los controles impuestos por el proceso SDL de Microsoft. Por experiencia, se recomienda someter a SDL las aplicaciones con una o varias de las siguientes características:
- Aplicaciones implementadas en un entorno empresarial
- Aplicaciones que procesan información de identificación personal (PII) u otro tipo de información confidencial
- Aplicaciones que se comunican frecuentemente a través de Internet u otras redes
Teniendo en cuenta la propagación de las tecnologías informáticas y la evolución del entorno de amenazas, quizás sea más fácil identificar los proyectos de desarrollo de aplicaciones que no estén sujetos a los controles de seguridad como los de SDL.
Actividades de seguridad simplificadas de SDL
En términos sencillos, el proceso SDL de Microsoft es un conjunto de actividades de seguridad obligatorias, que se presentan en el orden en que deben llevarse a cabo y se agrupan por cada una de las fases de un ciclo de vida de desarrollo de software tradicional. Muchas de las actividades descritas aportarían ciertos beneficios en materia de seguridad si se implementaran de manera independiente. Sin embargo, la experiencia en Microsoft demuestra que las actividades de seguridad realizadas como parte de un proceso de desarrollo de software aportan mayores beneficios que las actividades implementadas de manera poco sistemática o de modo ad hoc.
Actividades de Seguridad Obligatorias
Los diferentes procedimientos están encuadrados en diferentes actividades, como las veremos a continuación.
Formación - Seguridad Básica
Procedimiento 1 de SDL: requisitos de formación
Todos los miembros de un equipo de desarrollo de software deben recibir una formación apropiada con el fin de mantenerse al corriente de los conceptos básicos y últimas tendencias en el ámbito de la seguridad y privacidad. Las personas con roles técnicos (desarrolladores, evaluadores y administradores de programas) que están directamente implicadas en el desarrollo de programas de software deben asistir como mínimo una vez al año a una clase de formación en materia de seguridad.
Primera fase: requisitos
Procedimiento 2 de SDL: requisitos de seguridad
La necesidad de considerar la seguridad y la privacidad "desde el primer instante" es un aspecto fundamental del desarrollo de un sistema seguro. La fase de planificación inicial es el momento más apropiado para definir los requisitos de fiabilidad de un proyecto de software.
Procedimiento 3 de SDL: umbrales de calidad y límites de errores
Se usan umbrales de calidad y límites de errores para establecer niveles mínimos aceptables de calidad en materia de seguridad y privacidad. Al definir estos criterios al comienzo de un proyecto, se comprenderán mejor los riesgos asociados a los problemas de seguridad y los equipos podrán identificar y corregir los errores de seguridad durante el desarrollo.
Procedimiento 4 de SDL: evaluación de los riesgos de seguridad y privacidad
Las evaluaciones de los riesgos de seguridad (SRA) y de privacidad (PRA) son procesos obligatorios que identifican los aspectos funcionales del software que requieren una revisión exhaustiva. Dichas evaluaciones deben incluir la siguiente información:
1. (Seguridad) Partes del proyecto que van a requerir modelos de riesgos antes del lanzamiento.
2. (Seguridad) Las partes del proyecto que van a requerir revisiones del diseño de seguridad antes del lanzamiento.
3.(Seguridad) Partes del proyecto (si procede) que van a requerir pruebas de penetración por parte de un grupo externo al equipo de proyecto y acordado mutuamente.
4. (Seguridad) Requisitos de análisis o de pruebas adicionales que el asesor de seguridad considera necesarios para mitigar los riesgos de seguridad.
5. (Seguridad) Ámbito específico de los requisitos en materia de pruebas de exploración de vulnerabilidades mediante datos aleatorios.
6. (Privacidad) ¿Cuál es el nivel de impacto sobre la privacidad?
Segunda fase: diseño
Procedimiento 5 de SDL: requisitos de diseño
El momento más oportuno para influir en la fiabilidad del diseño de un proyecto es la etapa inicial de su ciclo de vida. Es muy importante que se estudien detenidamente las cuestiones de seguridad y de privacidad durante la fase de desarrollo. La mitigación de los problemas de seguridad y de privacidad es mucho menos costosa si se realiza en la etapa inicial del ciclo de vida de un proyecto. Los equipos de proyecto deben evitar abordar deprisa y corriendo las características de seguridad y de privacidad y las mitigaciones cerca del final del desarrollo de un proyecto.
Además, es de suma importancia que los equipos de proyecto entiendan la diferencia entre "características seguras" y "características de seguridad". Es perfectamente posible que se implementen características de seguridad que, en realidad, son inseguras. Las características seguras se definen como características cuya funcionalidad está debidamente diseñada con respecto a la seguridad, incluida una rigurosa validación de todos los datos antes de su procesamiento o una implementación criptográficamente robusta de bibliotecas para los servicios de cifrado. El término características de seguridad describe la funcionalidad de un programa que tiene implicaciones para la seguridad, como la autenticación Kerberos o un firewall.
Procedimiento 6 de SDL: reducción de la superficie de ataques
La reducción de la superficie de ataques está estrechamente relacionada con los modelos de riesgos, si bien aborda los problemas de seguridad desde una perspectiva ligeramente diferente. La reducción de la superficie de ataques es una forma de reducir el riesgo dando a los atacantes menos oportunidades para aprovechar un posible punto débil o una posible vulnerabilidad. Para reducir la superficie de ataques, se cierra o se restringe el acceso a los servicios del sistema, se aplica el principio de privilegios mínimos o se usan en la medida de lo posible defensas por capas.
Procedimiento 7 de SDL: modelos de riesgos
Los modelos de riesgos se usan en entornos donde existe un riesgo significativo para la seguridad. Este procedimiento permite a los equipos de desarrollo considerar, documentar y describir de manera estructurada las implicaciones para la seguridad de los diseños en el marco de su entorno operativo previsto. Los modelos de riesgos también permiten estudiar los problemas de seguridad en el nivel de los componentes o aplicaciones. La creación de un modelo de riesgos es un trabajo de equipo que implica a los administradores de programas o proyectos, desarrolladores y evaluadores; además, es la principal tarea de análisis de seguridad que se realiza en la fase de diseño del software.
El método preferido para generar modelos de riesgos es la herramienta de creación de modelos de riesgos de SDL. Esta herramienta se basa en la taxonomía de la clasificación de amenazas según el método STRIDE.
Tercera fase: implementación
Procedimiento 8 de SDL: usar herramientas aprobadas
Todos los equipos de desarrollo deben definir y publicar una lista de las herramientas aprobadas y de las comprobaciones de seguridad asociadas, como las advertencias y las opciones del compilador o del vinculador. Esta lista la debe aprobar el asesor de seguridad del equipo de proyecto. En términos generales, los equipos de desarrollo deben procurar usar la versión más reciente de las herramientas aprobadas a fin de aprovechar las nuevas protecciones y funciones de análisis de seguridad.
Procedimiento 9 de SDL: prohibir funciones no seguras
Un gran número de las funciones y API de uso común no son seguras de cara al actual entorno de amenazas. Los equipos de proyecto deben analizar todas las funciones y API que se van a usar con un proyecto de desarrollo de software y prohibir las que consideran inseguras. Una vez determinada la lista de funciones prohibidas, los equipos de proyecto deben usar archivos de encabezado (por ejemplo, banned.h y strsafe.h), compiladores más recientes o herramientas de análisis de código para comprobar si hay funciones prohibidas en el código (incluido código heredado si procede) y reemplazarlas por alternativas más seguras.
Procedimiento 10 de SDL: análisis estático
Los equipos de proyecto deben realizar un análisis estático del código fuente. Este tipo de análisis permite revisar el código de seguridad de forma escalable y contribuye a asegurar que se observan las directivas de codificación segura. En general, por sí solo, el análisis de código estático no puede reemplazar una revisión de código manual. El equipo de seguridad y los asesores de seguridad deben ser conscientes de las ventajas y desventajas de las herramientas de análisis estático y deben estar preparados para ampliar dichas herramientas con otras o con la revisión humana, según procede.
Cuarta fase: comprobación
Procedimiento 11 de SDL: análisis dinámico de los programas
Es necesario comprobar los programas de software en tiempo de ejecución para asegurar que su funcionalidad sea acorde con el diseño. Esta tarea de comprobación debe especificar las herramientas que supervisan el comportamiento de las aplicaciones para detectar si la memoria está dañada, si hay problemas con los privilegios de los usuarios u otro tipo de problemas de seguridad críticos. El proceso SDL usa herramientas en tiempo de ejecución como AppVerifier, junto con otras técnicas como pruebas de exploración de vulnerabilidades mediante datos aleatorios, para lograr los niveles de cobertura deseados de las pruebas de seguridad.
Procedimiento 12 de SDL: pruebas de exploración de vulnerabilidades mediante datos aleatorios
Este tipo de pruebas es una forma especializada de análisis dinámico que se usa para provocar errores en los programas introduciendo deliberadamente datos aleatorios o de formato incorrecto en una aplicación. Esta estrategia se deriva del uso previsto de la aplicación y de sus especificaciones funcionales y de diseño. Es posible que el asesor de seguridad requiera un número adicional de estas pruebas o amplíe su ámbito o duración.
Procedimiento 13 de SDL: revisión de los modelos de riesgos y de la superficie de ataques
En muchas ocasiones, una aplicación se desvía de manera significativa de las especificaciones funcionales y de diseño creadas durante las fases de requisitos y de diseño de un proyecto de desarrollo de software. Por ello, es muy importante que se revisen los modelos de riesgos y la medición de la superficie de ataques de una aplicación una vez completado su código. De este modo, se asegura que se toman en consideración los cambios de diseño o de implementación realizados en el sistema y que se revisan y se mitigan los nuevos vectores de ataque creados como resultado de los cambios.
Quinta fase: lanzamiento
Procedimiento 14 de SDL: plan de respuesta a incidentes
Cada lanzamiento de software sujeto a los requisitos de SDL debe incluir un plan de respuesta a incidentes. Incluso los programas sin vulnerabilidades conocidas en el momento de su lanzamiento pueden estar expuestos a nuevas amenazas. El plan de respuesta a incidentes debe incluir:
- Un equipo de ingeniería sostenida identificado o, si el equipo es demasiado reducido para tener recursos de ingeniería sostenida, un plan de respuesta a emergencias en el que se identifica el personal de ingeniería, marketing, comunicaciones y administración que representa el primer punto de contacto en caso de una emergencia de seguridad.
- Contactos con capacidad para tomar decisiones y disponibilidad las 24 horas del día y los 7 días de la semana.
- Planes de servicios de seguridad para código heredado de otros grupos dentro de la organización.
- Planes de servicios de seguridad para código de terceros bajo licencia, incluidos nombres de archivo, versiones, código fuente, datos de contacto de terceros y permiso contractual para realizar cambios (si procede).
Procedimiento 15 de SDL: revisión de seguridad final
La revisión de seguridad final es una inspección deliberada de todas las actividades de seguridad realizadas con una aplicación de software antes de su lanzamiento. Esta revisión la lleva a cabo el asesor de seguridad con ayuda del personal de desarrollo habitual y de los responsables de los equipos de seguridad y de privacidad. La revisión de seguridad final no consiste en "penetrar y parchear", ni tampoco en realizar las actividades de seguridad que se han omitido o se han olvidado. Suele consistir en un estudio de los modelos de riesgos, las solicitudes de excepciones, los resultados de las herramientas y el rendimiento teniendo en cuenta los umbrales de calidad y los límites de errores previamente determinados
Procedimiento 16 de SDL: lanzamiento o archivado
Las versiones RTM (Release To Manufacturing) y RTW (Release To Web) dependen de la finalización del proceso SDL. El asesor de seguridad asignado a la versión debe certificar (mediante la revisión de seguridad final y otros datos) que el equipo de proyecto ha cumplido los requisitos de seguridad. De manera similar, para todos los productos que tienen al menos un componente con el nivel de impacto en la privacidad P1, el asesor de privacidad del proyecto debe certificar que el equipo de proyecto ha cumplido los requisitos de privacidad para que se pueda enviar el software.
Herramientas recomendadas
−SDL Threat Modeling Tool version 3.1.8
http://www.microsoft.com/download/en/details.aspx?id=2955
−Anti-Cross Site Scripting (Anti-XSS) Library
http://msdn.microsoft.com/en-us/security/aa973814
−AppVerifier
http://www.microsoft.com/download/en/details.aspx?id=20028
Bibliografía
Microsoft Security Development Lifecycle Tools
http://www.microsoft.com/security/sdl/adopt/tools.aspx
El ciclo de vida de desarrollo de seguridad de Trustworthy Computing
http://msdn.microsoft.com/es-es/library/ms995349.aspx#EXAA
Microsoft Security Development Lifecycle (SDL) for Line-of-Business Applications
http://msdn.microsoft.com/en-us/library/dd831975.aspx
Fuente: Microsoft. Basado en la Guía "
Implementación simplificada del proceso SDL de Microsoft"
1 comentario:
Gracias por la información. Que Dios lo bendiga mucho y a su familia. Cuídate.
Publicar un comentario