Microsoft Security Development Lifecycle (III de VII) – Requisitos de diseño

En la pasada entrega se habló sobre los requisitos de seguridad con los que deben contar las aplicaciones, además de la forma identificar los aspectos funcionales del software en los que se requiere centrar la atención ante una previsible revisión, en esta ocasión se centrará la atención en el plano del diseño como principal medida de protección para aplicaciones, ya que ese es el punto de partida  de las debilidades y errores que los atacantes aprovechan para hacer su trabajo.

A la hora de empezar el desarrollo de una aplicación se debe que tener en cuenta que un buen diseño llevará consigo menos costes de tiempo y dinero y que ya que desde su concepción inicial debemos incidir mucho en el aspecto de la seguridad para tener la certeza de que nuestro proceso creativo será completamente fiable y libre de vulnerabilidades.

Es por ello que resulta prioritario analizar cada una de las funcionalidades que va a prestar nuestro proyecto para asegurar la privacidad y seguridad de la misma, diseñando para ello un protocolo  que se debe seguir en toda la fase de desarrollo de código, ya que de esta forma evitamos futuros costes de mantenimiento o reparación de sectores defectuosos que podrían significar perdida económica, por ejemplo se infiltra alguien en nuestro sistema y actúa de forma malintencionada accediendo a información privilegiada o incluso en un extremo podría llevar a problemas con la legislación local.Para ilustrar éste hecho vamos a servirnos de un ejemplo práctico visto en el libro “Análisis Forense Digital en entornos Windows”, donde a través de una infiltración en un sistema informático se utilizó el equipo victima para realizar publicaciones en una red pedófila, involucrando directamente al director de dicha empresa que fue arrestado por dicho acto. Es por ello, que hay que pensárselo dos veces antes de dejar el más mínimo agujero de seguridad en nuestras infraestructuras.

Establecer requisitos de diseño

¿Por qué debería seguir ésta practica en ésta etapa de desarrollo?

Ya que en ésta etapa se deben describir todas las especificaciones o características del software para que la estructura a desarrollar sea lo mas fiable posible, ya que al considerar la seguridad y privacidad en una etapa temprana minimiza el riesgo de que la planificación del proyecto sea interrumpido para la construcción de sistema de defensa frente a ataques, lo cual podría provocar grandes cambios en la estructura del trabajo que se está realizando.

En todo proyecto, los aspectos de seguridad y privacidad deben ser tratados con calma y detalle para evitar cualquier fuga, de esta forma el trabajo de realizar el ciclo de pruebas, cerca del final del proyecto será mucho mas sencillo, ya que no tendremos que detenernos a corregir fallos ni a analizar tan a fondo dichos requerimientos, ni estamos en riesgo de reenfocar el proyecto en gran medida lo cual también pondría en riesgo cumplir con los tiempos de entrega o peor aun, la herramienta podría causar fallos o daños a la corporación en tiempo de producción.

También es importante que nuestro equipo de desarrollo entienda la diferencia entre las características seguras, y características de seguridad, ya que posiblemente en nuestro diseño 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 puede ser la autenticación Kerberos, funciones Hash o la funcionalidad de cualquier cortafuegos.

Reducción de la superficie vulnerable frente a ataques

¿Por qué debería seguir ésta practica en ésta etapa de desarrollo?

Realizando este proceso se reduce el riesgo de la seguridad, dando a los atacantes menos oportunidades para explotar un potencial punto débil o vulnerabilidad.      

Al pensar en reducción de superficie de ataque se entiende rápidamente como securizar exhaustivamente partes de nuestra aplicación de forma que se tenga controlado los puntos débiles de nuestro desarrollo o posibles vulnerabilidades, de forma de dar la mínima oportunidad a un atacante para aprovecharlos.Es por ello que un análisis exhaustivo proporcionara un mejor conocimiento de la superficie de ataque global del producto.

Entre las medidas a las que se suele recurrir son aplicar privilegios mínimos, firewalls, IDS, mod_evasive, SSL, restringir el acceso a los servicios del sistema, medidas de defensa por capas.

Las medidas de reducción de ataques deben ser abordadas siguiendo los patrones de riesgo o modelos de amenazas, es decir, analizar los puntos donde sería fácil auditar nuestra aplicación siguiendo una lista de posibles vulnerabilidades hasta encontrar la vía de acceso a la información que contiene nuestro sistema. Si después de seguir éste modelo, nuestro sistema sigue siendo fiable estaremos siguiendo el camino correcto hacia el desarrollo seguro.

Modelos de amenazas

¿Por qué debería seguir ésta practica en ésta etapa de desarrollo?

El modelado de amenazas permite a los equipos de desarrollo encontrar eficazmente los problemas de seguridad de diseño. La mitigación de los problemas de seguridad es menos costosa si se realiza durante el diseño.

Los modelos o tipos comunes de riesgos se usan en entornos donde existe un potencial riesgo para la seguridad de ésta forma podemos ir directamente a los posibles origines de fallos de seguridad e intentar erradicarlos de inicio. Esta táctica permite a los equipos simular el entorno donde se va a implantar la aplicación, luego encontrar, documentar y enumerar las implicaciones de seguridad que se encuentren.

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.

Entre las medidas o elementos que nos pueden ser útiles en esta etapa podemos encontrar los siguientes:

• SDL Developer Starter Kit - Principios de modelado de amenazas, y Principios de la herramienta de modelado de amenazas.
• Descubrir fallas de seguridad de diseño utilizando el Método de STRIDE.
• Revitalizar el proceso de modelado de amenazas
• Modelos de amenazas mejorar su proceso de seguridad
•  Introducción a SDL Threat Modeling Tool

En la siguiente entrada analizaremos la necesidad de utilizar las mejores herramientas para implementar nuestra aplicación en el entorno corporativo de forma que dichas herramientas nos ayuden a automatizar y hacer cumplir las prácticas de seguridad fácilmente y a un bajo costo.

Si quieres aprender más secretos, configuraciones, integraciones, desarrollo de PowerShell te recomendamos leer el libro de Pablo González y Ruben Alonso “PowerShell: La navaja suiza de los administradores de sistemas”. Si quieres aprender mucho más sobre los secretos de lo sistemas Microsoft Windows, te recomendamos leer el libro de Sergio de los Santos "Máxima Seguridad en Windows: Secretos Técnicos" y, por último, te recordamos que si te ha gustado el artículo puedes suscribirte al Canal RSS de Windows Técnico para estar al día de las novedades e información técnica de interés.

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