Microsoft Security Development Lifecycle (II de VII) – Requisitos de seguridad

En la pasada entrega se habló sobre los requisitos previos que debe tener una corporación en temas de seguridad, y sobre la necesidad de tener en el equipo de desarrollo de software algún integrante capacitado en temas relacionados con ataque y defensa de contra vulnerabilidades.

El objetivo de esta entrega es hablar sobre los requisitos que deben cumplir las aplicaciones en materia de seguridad, e identificar los aspectos funcionales del software en los que se requiere centrar la atención ante una previsible revisión.

Es por ello que surge la pregunta:

¿Donde aplicar SDL?

Las corporaciones que realizan desarrollo de software, deben hoy en día definir de forma clara y concisa los tipos de proyectos que van a ser sometidos a SDL de Microsoft, es  por ello que se debería analizar una serie de características que deben cumplir las aplicaciones para que sean candidatas a pasar dicho proceso.

Dicho software debe cumplir alguna de las siguientes características:

·         Ser aplicaciones implementadas en un entorno empresarial.

·         Ser aplicaciones que procesan información de identificación personal u otro tipo de información que se necesita que permanezca de forma confidencial.

·         Ser aplicaciones que se comunican frecuentemente a través de Internet u otras redes.

A veces es más sencillo identificar a los proyectos que no requieren pasar este proceso, sin embargo en los que si deben hacerlo siempre hay que considerar la constante evolución de las tecnologías de información, con lo cual y de manera paralela, también avanzan las técnicas de explotación de vulnerabilidades, lo cual supone una fuerte amenaza para la información que se maneja.

¿Por qué aplicar esta medida?

La definición temprana de los requisitos de privacidad y seguridad permite la integración de dichos elementos en el proceso de desarrollo y reduce al mínimo cualquier interrupción en la planificación y los plazos establecidos.

Las pruebas de calidad e intervalos de error se utilizan para establecer los niveles mínimos aceptables de seguridad y la calidad en lo que a privacidad se refiere. Definiendo estos criterios en el inicio de un proyecto se mejora la comprensión de los riesgos asociados con cuestiones de seguridad, permite a los equipos identificar y corregir errores durante el desarrollo.

Algunas maneras de evitar estos problemas es:

·         Anticipando Fallas en el Código: esas fallas que se detectan en la ejecución de la aplicación.

·         Los atacantes agreden a todo el código, por lo tanto es importante proteger todo el desarrollo, no solo un componente. Los intrusos atacan todo el software y buscan fallas por donde obtener lo que desean.

·         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.

·         Remplazar protocolos viejos.

·         Reconocer que el código fallará y reducir la superficie de ataque.

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.

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.

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. Partes del proyecto que van a requerir modelos de riesgos antes del lanzamiento.
2. Las partes del proyecto que van a requerir revisiones del diseño de seguridad antes del lanzamiento.
3. 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. Requisitos de análisis o de pruebas adicionales que el asesor de seguridad considera necesarios para mitigar los riesgos de seguridad.
5. Ámbito específico de los requisitos en materia de pruebas de exploración de vulnerabilidades mediante datos aleatorios.

Todos estos requisitos llevan a una pregunta importante: ¿Cuál es el nivel de impacto sobre la privacidad? Este balance es importante en cada desarrollo Sin embargo y buen análisis de requisitos y una buena implementación conlleva a la consecución de ambos objetivos sin que el software deje de ser funcional.

En la próxima entrega se verán aspectos de diseño que deben cumplir las aplicaciones para evitar caer en el abismo de la vulnerabilidad frente a ataques externos.

Por último, recuerda suscribirte al Canal RSS de Windows Técnico para recibir información como la que aparece aquí reflejada y otras actividades de interés que publicamos regularmente en este blog.

Microsoft Security Development Lifecycle (I de VII) – Introducción y primera fase
Microsoft Security Development Lifecycle (II de VII) – Requisitos de seguridad
Microsoft Security Development Lifecycle (III de VII) – Requisitos de diseño
Microsoft Security Development Lifecycle (IV de VII) – Implementación
Microsoft Security Development Lifecycle (V de VII) – Comprobación
Microsoft Security Development Lifecycle (VI de VII) – Lanzamiento
Microsoft Security Development Lifecycle (VII de VII) – Respuesta