SDL consiste en un proceso de garantía de la seguridad, centrado en el desarrollo software.
SDL es el conjunto de procesos que marca Microsoft en el desarrollo software atacando de dos maneras:
- Con 4 niveles dentro del Modelo
- Colocando actividades en cada uno de las fases del ciclo de vida clásico del proceso de desarrollo
Como todo producto Microsoft está orientado a integrase con lo suyo. Así dependiendo de la fase donde estemos diseño, implementación ofrece plantillas o analizadores que se integran de manera perfecta con Visual Studio Team System 2008.
Os adjunto un resumen muy breve del producto, que la verdad viene bien explicado en la web o en las MSDN.
Desde 2004 se ha instaurado en Microsoft como algo obligatorio en toda la empresa para conseguir con SDL mejorar la seguridad del software. SDL tiene como objetivo reducir tanto el número como la gravedad de los bugs del software. SDL se introduce en todas las fases del desarrollo software.
SDL está basado en tres conceptos básicos:
- Educación
- Mejora en el proceso continuo
- Responsabilidad
La educación continua y la mejora de los miembros de un equipo de desarrollo software es crítica. Invertir en formación ayuda a las empresas a estar preparadas ante los cambios tecnológicos y las amenazas que se deriven de ello. Porque el riesgo no es estático, SDL hace el énfasis más fuerte en entender la causa y el efecto de las vulnerabilidades (bugs) en la seguridad. Necesita una evaluación periódica de los procesos SDL y una presentación de los cambios en respuesta a los cambios en la tecnología o a las posibles amenazas. Se recogen los datos obtenidos para evaluar la efectividad de la prueba realizada (entrenamiento); se usan procesos de métricas para confirmar la conformidad del proceso y las métricas a posteriori (post-release) ayudan como una guía a futuros cambios. Finalmente, SDL almacenará todos los datos que podrán ser utilizados a posteriori. Cuando esto se combina con una respuesta detallada tanto de la seguridad de la aplicación como de los planes de comunicación, una empresa puede proporcionar una orientación concisa y convincente a todas las partes afectadas con el problema.
Modelo de Optimización de Microsoft SDL
La integración de los conceptos de desarrollo seguro en un proceso de desarrollo puede ser costosa e intimidante si no se hacen de forma correcta. El éxito o el fracaso dependen de variables como el tamaño del equipo de desarrollo, los recursos que se poseen (tiempo, talento, presupuesto) y el apoyo por parte de la gerencia. El impacto de estos intangibles pueden ser controlados mediante la comprensión de los elementos que componen las buenas prácticas en la seguridad y estableciendo implementaciones prioritarias basadas en los niveles de madurez del equipo.
El modelo de optimización de SDL ha sido diseñado para facilitar de manera gradual una implementación consistente reduciendo los riesgos. El modelo permite hacer cosas tanto a los desarrolladores como a los managers:
- Crear una visión practica y una hoja de ruta para ir avanzando por los niveles de SDL en cada una de las 5 areas del desarrollo software:
- Formación, Normas, y características a seguir
- Requerimientos y diseño
- Implementación
- Verificación
- Lanzamiento y Respuesta
- Mostrar un esquema práctico y las actividades rentables en cada una de las 5 fases teniendo en cuenta el presupuesto, la planificación y los esfuerzos del equipo de desarrollo del software.
El modelo de optimización de SDL consiste en:
|
|
Una introducción a SDL e indicaciones de cómo usarlo |
| Un cuestonario para mostrar el estado actual de la seguidad del desarrollo en los niveles de SDL |
| Tres guias de implementacion con detalles de los pasos necesarios a realizar para ir avanzando en los distintos niveles de madurez en cada una de las 5 areas del desarrollo. |
Aplicación de SDL
Es importante dejar claro los tipos de proyectos que pueden ser objeto de los controles impuestos por SDL. La experiencia sugiere que se elijan teniendo en cuenta una o más de las siguientes características:
- Desarrollo de un producto propio
- Procesos de identificacion personal (PII) u otra informacion confidencial
- Comunicaciones periodicas con Internet o con otras redes.
Roles, Responsabilidades de las personas encargadas de la Seguridad
SDL incluye criterios generales y descripciones para los roles que van a llevar la seguridad y la privacidad. Estos roles se indican durante de la Fase de Requisitos del proceso SDL. Estos roles son de carácter consultivo y proporcionan a la empresa la estructura necesaria para identificar, catalogar y mostrar las cuestiones de seguridad presentes en el desarrollo de un producto software.
Estos roles incluyen:
- Rol de Asesorar, Revisar: estos roles se diseñan para tener una visión global acerca de la seguridad; con permisos para aceptar o rechazar los planes de seguridad del equipo
- Un Equipo formado por los mejores: estos roles son los que negocian, aceptan y marcan un mínimo en los requisitos de seguridad y el mantenimiento de las líneas claras de comunicación durante el desarrollo del producto software.
Actividades del Proceso SDL
Es un conjunto de actividades de seguridad obligatorias, que se van a mostrar en el orden en que deberían ocurrir y agrupadas por las fases que marcan el ciclo de vida clásico en el desarrollo del software. Muchas de las actividades expuestas deberían proporcionar cierto grado de seguridad si su implementación se lleva a cabo de manera independiente. De todos modos, desde la propia experiencia, Microsoft recomienda que las actividades correspondientes a la seguridad se ejecuten como una parte más del proceso de desarrollo, consiguiendo mayor grado de seguridad que actividades desarrolladas por partes o hechas ad-hoc para un proyecto.
Es importante que si la empresa se centra en la calidad, utilice las herramientas y la automatización de SDL, puesto que le ofrece resultados completos y exactos y no se queda simplemente en un documento aislado obtenido en una fase del ciclo de desarrollo.
Actividades Obligatorias de Seguridad
Existen 16 actividades obligatorias de seguridad que todo equipo que vaya a emplear SDL debe realizar. Estas actividades se revisan de manera constante y son fruto del conocimiento y la experiencia de los equipos de Microsoft. Como se acaba de comentar estas 16 actividades marcan un mínimo de realización por parte del equipo, que puede añadir todas las actividades que considere necesarias.
Requisitos Pre-SDL
Practica 1, Formación: todos los miembros del equipo deben recibir la formación adecuada para tener todos los conceptos acerca de la seguridad y la privacidad que se va a llevar a cabo en el proyecto.
La formación básica estaría centrada en temas como:
- Diseño de seguridad: reducción de ataques, principios de mínimos privilegios, seguridad mínima establecida, etc.
- Amenazas en el diseño (modelado): restricciones de la arquitectura, implicaciones propias del modelo, etc.
- Codificación segura: errores aritméticos, bucles infinitos, Cross-site Scripting( de las aplicaciones Web), criptografía no muy robusta, etc.
- Test de seguridad: diferencias entre test de seguridad y test funcionales, métodos de testeo de la seguridad, etc.
- Privacidad: en lo relativo a los datos, asumir riesgos, aprender buenas prácticas, etc.
Fase 1 Requisitos
Practica 2, Requisitos de Seguridad: Lo fundamental en el desarrollo de un sistema de seguridad para un producto es considerar que la seguridad y la privacidad son lo primero. El punto óptimo donde definir la integridad del producto se debe decidir durante las etapas iniciales. Esta definición temprana de requisitos, permite a los equipos identificar las claves de los resultados, permitiendo la integración de la seguridad de manera que minimice “el encontronazo” con la planificación del desarrollo.
Practica 3, Umbrales de Calidad: Se marca lo que se considera como nivel mínimo de calidad que se quiere adoptar. Definiendo estos criterios el equipo empieza a asumir los riesgos asociados a la seguridad y privacidad de los datos del proyecto. Por ejemplo, todos los “warning” de la compilación deben estar arreglados antes de subir el código al repositorio. También sería una buena práctica tener un gráfico donde reflejar los niveles de calidad alcanzados, es un indicador muy bueno con vida a lo largo de todo el proyecto.
Practica 4, Seguridad y Evaluación de Riesgos: Son procesos obligatorios que identifican aspectos funcionales del software y para los cuales se necesita dedicación:
- Aspectos relacionados con la seguridad:
- ¿Que parte del proyecto necesita un modelo de riesgos antes de ser lanzada?
- ¿Qué parte del proyecto necesita diseño de seguridad antes de ser lanzada?
- ¿Existen test adicionales de seguridad o requisitos que se consideran necesarios para minimizar los riesgos en la seguridad?
- ¿Cuál va a ser el ámbito de los requisitos de test?
- ¿Cómo se evalúa el impacto de la privacidad de los datos?
Fase 2 Diseño
Practica 5, Requisitos de Diseño: El sitio ideal para marcar el grado de fiabilidad que deseamos en nuestro proyecto es en la parte inicial del ciclo de vida del proyecto, por eso es muy importante considerar todo lo relacionado con la seguridad y el control de los datos en la etapa de diseño. Además es importante que el equipo distinga entre características de seguridad y características seguras:
- Características Seguras: son aquellas cuya funcionalidad cumple con unos mínimos como validación de los datos antes de procesarlos, o cuenta con una implementación de librerías robustas en materia de criptografía, etc.
- Características de Seguridad: describe características tales como autenticación, firewall, etc.
Practica 6, Reducción de Posibles Puntos de Ataque: Se trata de reducir los riesgos de ataque, cuidando los posibles puntos débiles que se tengan en el producto: restringir los accesos a los sistemas, aplicando principios de privilegios en los perfiles, etc.
Practica 7, Modelos de Amenazas: Este punto se indica sobre todo para sistemas donde el riesgo de la seguridad es alto. Con esta práctica se pretende que los equipos documenten y discutan acerca de las implicaciones que puede tener el modelo de seguridad planteado en el contexto real del proyecto. En realidad está pensado para realizarlo de manera conjunta entre desarrolladores, managers, testeadores.
Fase 3 Implementación
Practica 8, Herramientas: En el equipo, todos deben trabajar del mismo modo, con una lista de herramientas aprobadas por todos y que permitan la integración de las mismas con otras que lancen avisos acerca del cumplimiento o no de la seguridad marcada para el proyecto.
Practica 9, Funciones Obsoletas: El equipo debe analizar las API’s que se utilizaran para descartar aquellas que se consideran obsoletas y por lo tanto inseguras. Una opción de trabajo es crear una lista con las funciones inseguras, utilizar ficheros tales como banned.h o strsafe.h, emplear últimas versiones de los compiladores, o utilizar herramientas para escanear el código y verificar que no existen las funciones obsoletas.
Practica 10, Análisis Estático: Un análisis estático del código fuente puede permitir al equipo que de verdad se están cumpliendo los criterios de seguridad marcados. Esto se debería realizar combinado aplicaciones de análisis de código junto con un trabajo por parte del equipo.
Fase 4 Verificación
Practica 11, Análisis Dinámico del Programa: Los programas de verificación del código en tiempo de ejecución son necesarios para asegurar que el programa hace lo que se esperaba según el diseño marcado. La tarea de verificación especifica las herramientas que se emplean por ejemplo en hacer un seguimiento del estado de la memoria por si en algún momento se corrompe, o el cumplimiento de los permisos dados a los usuarios. En el proceso SDL se utilizan herramientas como AppVerifier, junto con otras técnicas como “fuzz testing” para asegurarse que se cumplen los niveles de seguridad marcados.
Practica 12, “Fuzz Testing”: Es una práctica por la que se induce al programa a fallar mediante datos incorrectos o aleatorios. Se parte de la funcionalidad prevista de la aplicación y se va ampliando el alcance de los test poco a poco.
Practica 13, Revisión de los Puntos Débiles y la Amenazas: Una aplicación es algo vivo, y lo normal es que haya cambios respecto a lo especificado en la fase de diseño. Esto lo que implica es que también se debe revisar lo que en su día se puso como posible amenaza, o parte de débil de la aplicación y por lo tanto susceptible en la seguridad.
Fase 5 Lanzamiento de la Aplicación
Practica 14, Plan para responder a Incidencias: Dentro de los equipo se debe marcar desde donde incluir todas las incidencias, a como clasificarlas, quien contesta en cada caso, etc.
Practica 15, Revision Final del Plan de Seguridad: Consiste en realizar una revisión sobre todas las prácticas llevadas a cabo acerca de la seguridad de la aplicación. No se pretende que esta práctica sea la oportunidad para incluir aquellas actividades que se han olvidado realizar, sino lo que hace es examinar los sistemas de excepciones, las posibles amenazas marcadas, etc.
Practica 16, Archivo con los Datos Seguridad: Para completar el proceso SDL se pide que el equipo incorpore los datos que indican que como mínimo ha realizado las 16 practicas del proceso SDL. Además todos los datos se guardan, permitiendo de este modo revisarlos a posteriori. Esto incluye la revisión del código fuente, los documentos donde se marcan los puntos débiles, un plan de respuesta ante una emergencia, licencias de terceros, etc.
Para todas las fases…
En cada una de las fases existen una serie de herramientas que van desde plantillas para Visual Studio Team System 2008 hasta en la parte de implementación analizadores estáticos de los ensamblados, de código C/C++, de vulnerabilidades para prevenir XSS (Cross Site Scripting).
En la página web se puede ver: http://www.microsoft.com/security/sdl/default.aspx
y también hay información en la MSDN: http://msdn.microsoft.com/en-us/library/cc307748.aspx
Conclusión
El objetivo de este trabajo es proporcionar un framework sencillo para introducir las prácticas de seguridad en el proceso de desarrollo de software. Esto se realiza mediante una serie de actividades que se llevan a cabo durante el proceso de desarrollo por parte de un equipo que tendrá como objetivo final cumplir con los objetivos marcados en el modelo Microsoft SDL, como óptimos.
Mientras que el proceso mencionado establece un umbral mínimo para el cumplimiento de SDL, SDL no significa que no sea ampliable. Los equipos de desarrollo pueden utilizar SDL como una guía y adecuarse a los recursos y las prácticas de la empresa.
Normalmente los conceptos que se discuten están reconocidos como buenas prácticas de la seguridad y no son específicos de Microsoft o de Windows. Todas se pueden aplicar sobre diferentes sistemas operativos, plataformas de hardware, y metodologías de desarrollo y hacer una aplicación gradual de algunas de estas técnicas probablemente tendría una influencia beneficiosa sobre la seguridad y la privacidad de una aplicación en fase de desarrollo.
Se puede argumentar que incluso unas prácticas sencillas de los procesos de seguridad realizadas de común acuerdo por todo el equipo de desarrollo puede conducir a mejoras de manera global que las realizadas de forma individual.
El SDL Microsoft es un proceso de libre disposición para la mejora de software en los aspectos de seguridad y privacidad. Se ha aplicado en numerosos programas de software y sobre millones de líneas de código de producción. SDL se compone de medidas obligatorias que siguen el proceso de desarrollo de software tradicional, pero es lo suficientemente flexible como para permitir la adición de otras políticas y técnicas, creando así una metodología de desarrollo de software que sirva como una guía dentro de la empresa. La combinación de procesos, formación, y herramientas produce distintos beneficios: prevenir errores, mejor competencia técnica, optimización del software, lo que se traduce en un menor riesgo tanto para la producto como para el usuario del mismo.
