“When we started work on Microsoft .NET more than two years ago, we set a new direction for the company -- and articulated a new way to think about our software. Rather than developing standalone applications and Web sites, today we're moving towards smart clients with rich user interfaces interacting with Web services. … However, even more important than any of these new capabilities is the fact that it is designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony. “
“When we started work on Microsoft .NET more than two years ago, we set a new direction for the company -- and articulated a new way to think about our software. Rather than developing standalone applications and Web sites, today we're moving towards smart clients with rich user interfaces interacting with Web services.
…
However, even more important than any of these new capabilities is the fact that it is designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony. “
Así anunciaba Bill Gates en el año 2002 el comienzo de la iniciativa conocida como Trustworthy Computing, enfocada en desarrollar una serie de procesos y prácticas enfocados en cuatro pilares específicos: Seguridad, Privacidad, Confiabilidad e Integridad en los Negocios en los diferentes productos y servicios ofrecidos por Microsoft.
En este artículo describiré brevemente uno de los resultados de esta iniciativa: Microsoft Security Development Lifecycle. Al final del mismo, les haré una invitación a que me compartan qué tipos de consideraciones de seguridad realizan en sus equipos.
Se trata de un proceso de QA, explicitando actividades obligatorias que deben ser aplicadas en las diferentes etapas del ciclo de desarrollo: Entrenamiento, Requerimientos, Diseño, Implementación, Verificación, Liberación, Respuesta.
El primer punto es crucial, considerar el entrenamiento en seguridad una etapa obligatoria propia del ciclo de desarrollo. El entrenamiento no es solo requerido para el desarrollador, sino también para los roles de tester o program manager (para conocer más del modelo de organización de equipos en Microsoft, ver MSF).
Algunos conceptos básicos incluidos en el entrenamiento requerido:
Dos libros para conocer más sobre prácticas de desarrollo seguro:
Durante el inicio del proyecto no sólo debe evaluarse las condiciones generales de seguridad y privacidad a ser consideradas durante todo el proyecto, sino hacerse un análisis de costos para asegurar dichas características. Cuanto más temprano identifiquemos defectos de seguridad en nuestro proyecto, menor será el costo de resolverlos, por eso es muy importante el planeamiento de los mismos:
Para ello debe realizarse un análisis de riesgos el cual incluya:
A su vez, se realiza un análisis de privacidad, que identifique el grado de sensibilidad de los datos a ser procesados por el software. A partir de este tipo de análisis, se definen las barreras de seguridad que debe cumplir el software.
Desde una perspectiva de seguridad, los elementos más importantes durante la fase de diseño son la definición de la arquitectura y guías de diseño de seguridad: La definición de capas, el uso o no de lenguajes fuertemente tipados, la definición de los menores privilegios requeridos, la minimización de la superficie de ataques, deben ser consideradas y aplicadas al software de acuerdo a los requerimientos definidos.
A su vez, el proceso definido establece algunas prácticas requeridas:
La definición de un Modelo de Amenazas cobra especial atención durante la fase de implementación. Los desarrolladores prestan especial atención a la correctitud del código, mitigando las amenazas de mayor prioridad, permitiendo a los testers asegurar que cada amenaza es realmente bloqueada y mitigada.
Las practicas recomendadas durante esta fase incluyen:
Creación de documentación para el usuario, informando sobre consideraciones de seguridad de la aplicación.
Establecer y Seguir las Mejores Practicas de Desarrollo:
Se trata del punto donde la funcionalidad es completa y entra en testeo beta de usuario. Se realiza beta testing, haciendo un gran esfuerzo por violar la seguridad del sistema, y realizando revisiones de seguridad periódicas de código.
El testeo de seguridad de comenzar muy temprano en la etapa de verificación. También se vuelve clave la definición de la superficie de ataque, dado que permitirá priorizar los defectos encontrados, entendiendo cuales de ellos deben ser corregidos inmediatamente.
Durante la liberación, el software debe someterse a una Revisión Final de Seguridad: Desde el punto de vista de la seguridad, está el producto listo para los clientes?
La Revisión Final de Seguridad no es un ejercicio donde simplemente se determina si pasa o no pasa; tampoco el objetivo es encontrar el resto de las vulnerabilidades del software, esto podría no lograrse nunca. En lugar de esto, la Revisión Final permite darle al equipo de producto y a la organización una visión general de la seguridad del software, y la probabilidad de que ocurran ataques una vez que es liberado a los clientes. Si se encontraran vulnerabilidades, la respuesta correcta no es simplemente corregirlas, sino revisar las faces anteriores y tomar otras acciones que permitan corregir las causas de raiz (por ejemplo mejorando el entrenamiento, perfeccionando las herramientas).
A pesar de aplicar el proceso durante el desarrollo, las prácticas de desarrollo actuales aún no permiten entregar software que esté completamente libre de vulnerabilidades – y existen razones para creer que esto no va a ocurrir nunca. Por ello, los grupos de producto deben prepararse para responder a nuevas vulnerabilidades encontradas aún cuando el software ya fué liberado.
Parte del proceso de respuesta involucra la generación de reportes de vulnerabilidades, y liberar actualizaciones cuando corresponda. El otro componente del proceso de respuesta, es llevar adelante post-mortems de vulnerabilidades reportadas, permitiendo tomar las acciones necesarias.El objetivo es lograr aprender de los errores y utilizar los reportes de vulnerabilidades para encontrar nuevas vulnerabildiades que aún no hayan sido encontradas, antes de poner a los clientes en riesgo.
Microsoft implementa SDL desde el año 2002. Productos como Windows Server 2003, Windows Vista, Windows 7, SQL Server 2005 en adelante son el resultado de la aplicación de las prácticas de ingeniería que surgieron a partir de la iniciativa de Trustworthy Computing.
Los equipos de ingeniería deben aplicar estos procesos de forma obligatoria, siendo la seguridad un rol central en el equipo. Visual Studio Team System, incluye una plantilla de proceso SDL. Herramientas como SDL Threat Modeling Tool facilitan la definición y administración de los Modelo de Amenazas.
Procesos Ágiles: Existen también definiciones adyacentes al proceso de SDL, enfocada a proveer prácticas y soluciones para equipos con metodologías ágiles, también descriptas dentro del documento: Microsoft Security Development Lifecycle
El post hasta aquí ha sido una muy breve descripción a manera de introducción al proceso seguido en equipos de Microsoft para asegurar la calidad en sus productos. Algunas de estas prácticas te habrán parecido comunes, y otras tal vez nuevas. Te invito me compartas qué significa para vos la seguridad, y cómo es considerada dentro de tu equipo de desarrollo.
Saludos!