Pinceladas sobre seguridad

La plantilla de procesos MSF-Agile+SDL para TFS 2010

Bryan Sullivan

Cualquier persona que lea regularmente esta revista estará familiarizada con Microsoft Team Foundation Server (TFS) y los beneficios de productividad que los equipos de desarrollo pueden obtener de su uso (si no está familiarizado con TFS, consulte el artículo de Chris Menegay en nuestra Visita guiada de Visual Studio 2005. Aunque aborda una versión antigua, proporciona información general útil de los tipos de características que puede aprovechar en TFS).

Si usted usa TFS, probablemente también esté familiarizado con la plantilla de procesos de Microsoft Solutions Framework (MSF) for Agile Software Development, mejor conocida como MSF-Agile, que se incluye con TFS. El tema de la columna de este mes es la nueva plantilla de procesos de MSF-Agile más ciclo de vida de desarrollo de seguridad (SDL, Security Development Lifecycle). MSF-Agile+SDL está desarrollada sobre la plantilla MSF-Agile y agrega características de seguridad y privacidad de SDL al proceso de desarrollo.

Puede descargar la plantilla MSF-Agile+SDL para Visual Studio Team System 2008 ó 2010 desde microsoft.com/sdl. Antes de descargarla, sin embargo, es conveniente que sepa lo que se ha incluido en ella. Comencemos.

Tareas de SDL

Lo fundamental de SDL son sus requisitos y recomendaciones de seguridad, actividades que los equipos de desarrollo deben realizar durante el ciclo de vida de desarrollo para asegurar una mejor seguridad y privacidad en el producto final. Estos requisitos incluyen actividades de directivas, tales como la creación de un plan de respuesta a incidentes de seguridad, así como actividades técnicas como el modelado de amenazas y la realización de análisis de vulnerabilidades estadísticas. Todas estas actividades están representadas en la plantilla de MSF-Agile+SDL como elementos de trabajo de tareas de SDL.

Probablemente la principal diferencia entre tareas de SDL y los elementos de trabajo estándar que representan tareas funcionales es que los miembros del equipo del proyecto no deben crear directamente las tareas de SDL ellos mismos. Algunas tareas de SDL se crean automáticamente cuando el equipo del proyecto se crea por primera vez. Son relativamente sencillas; tareas de seguridad que se realizan una sola vez, como la identificación del miembro del equipo que será el contacto principal de seguridad. La plantilla de procesos crea automáticamente otras tareas de SDL en respuesta a acciones del usuario (más específicamente, las crea automáticamente el servicio web de controladora de SDL-Agile que se implementa en el nivel de aplicación de TFS).

Siempre que un usuario agrega una nueva iteración al proyecto, la plantilla agrega nuevas tareas de SDL al proyecto, que representan las tareas de seguridad que se deben realizar durante la iteración. Un buen ejemplo de una tarea de SDL por iteración es el modelado de amenazas: el equipo debe evaluar los cambios que realiza durante el transcurso de la iteración para identificar posibles nuevas amenazas y mitigaciones.

Por último, siempre que un usuario revisa un nuevo proyecto de Visual Studio o sitio web en el repositorio de control de código fuente del equipo, la plantilla agrega tareas de SDL para reflejar el trabajo de seguridad que se debe realizar específicamente para dicho proyecto. Por ejemplo, siempre que se agrega un nuevo proyecto C o C++, se crean tareas de SDL para asegurar el uso de compilador de defensa de desbordamiento del búfer y configuraciones del vinculador, como el marcador /dynamic­base para la selección aleatoria del diseño del espacio de direcciones y el marcador /gs para la comprobación de seguridad de búfer.

La plantilla es lo suficientemente sofisticada como para reconocer la diferencia entre proyectos nativos C/C++ y proyectos de Microsoft .NET Framework, y no agrega requisitos no válidos. Los marcadores /dynamicbase y /gs no tienen significado para el código C# y dichas tareas de SDL no se crearán para proyectos C#. En su lugar, los proyectos C# reciben tareas de seguridad específicas de .NET, como la revisión de cualquier uso de AllowPartiallyTrustedCallersAttribute. Asimismo, la plantilla también puede distinguir aplicaciones de cliente/servidor y aplicaciones independientes de escritorio de sitios web y servicios web, y sólo agrega el conjunto correspondiente de tareas SDL en consecuencia.

Flujo de trabajo y excepciones de tareas de SDL

El estado y la razón de las transiciones de flujo de trabajo para tareas de SDL también son diferentes de las de tareas funcionales. Una tarea se puede marcar como cerrada por varias razones diferentes: finalizada, eliminada del proyecto, aplazada a una iteración posterior o incluso obsoleta e irrelevante en lo sucesivo para el proyecto. De estas razones, sólo la de finalizada se aplica a tareas de SDL.

Los términos que siguen la SDL no pueden simplemente eliminar requisitos de seguridad y privacidad de sus proyectos. La inclusión o exclusión de requisitos funcionales en los proyectos se puede negociar astutamente por razones técnicas o empresariales, pero los requisitos de seguridad se deben mantener en un estándar superior. No es imposible que alguna vez se omita una tarea de SDL, pero se debe seguir un nivel de proceso superior para que esto llegue a ocurrir.

Si, por cualquier razón, un equipo no puede realizar una tarea de SDL requerida, debe solicitar a su asesor de seguridad una excepción a esta tarea. El equipo o su administración eligen al asesor de seguridad del equipo al comienzo del proyecto. Esta persona debe tener experiencia en seguridad y privacidad de aplicaciones y, de ser posible, no debe estar trabajando directamente en el proyecto; no debe ser uno de los desarrolladores, administradores de programas o evaluadores del proyecto.

En Microsoft existe un grupo centralizado de asesores de seguridad que trabajan en la división de Seguridad de Trustworthy Computing. Estos asesores de seguridad después trabajan con los equipos de productos individuales directamente. Si su organización tiene los recursos para crear un grupo dedicado de asesores de seguridad, excelente. De lo contrario, lo mejor es seleccionar a la persona con la experiencia más sólida en seguridad.

Es decisión del asesor de seguridad del equipo aprobar o rechazar cualquier solicitud de excepción de una tarea de SDL. El equipo crea una solicitud de excepción configurando el estado de tarea de SDL en Exception Requested (Excepción solicitada) y llenando los campos Justification (Justificación), Resolution Plan (Plan de resolución) y Resolution Timeframe (Período de tiempo de resolución). Cada tarea de SDL también tiene un campo Exception Rating (Calificación de excepción) de sólo lectura que representa el riesgo de seguridad subjetivo inherente de no cumplir con el requisito, que va de 4 (menor riesgo) a 1 (crítico, mayor riesgo). El asesor de seguridad evalúa las razones del equipo en relación con la calificación de excepción y cierra la tarea de SDL con Reason of Approved (razón de aprobación) o la reactiva con Reason of Denied (razón de rechazo).

Sin embargo, aunque la solicitud se apruebe, la mayoría de las excepciones no duran para siempre. Aquí es donde interviene el campo Resolution Timeframe. Los equipos generalmente solicitan excepciones para un determinado número de iteraciones; por lo general, una sola iteración, pero a veces pueden ser hasta tres. Una vez que se ha alcanzado el número de iteraciones especificadas, la plantilla de procesos finaliza la excepción y reactiva la tarea de SDL.

Errores de seguridad

Después de asegurar que se cumplan los requisitos de seguridad y privacidad, la función más importante del SDL es asegurar que los productos no se envíen con errores de seguridad conocidos. El seguimiento de errores de seguridad en forma separada de los errores funcionales es fundamental para asegurar el buen estado de seguridad del producto.

A diferencia de las tareas de SDL, la plantilla MSF-Agile+SDL no agrega un segundo tipo de elemento de trabajo de error de SDL para distinguir errores de seguridad de errores funcionales. En su lugar, agrega los campos Security Cause (Causa de seguridad) y Security Effect (Efecto de seguridad) al tipo de elemento de trabajo de error existente. Siempre que un miembro del equipo presente un nuevo error, si el error es estrictamente funcional sin implicaciones de seguridad, el buscador simplemente deja estos campos en sus valores predeterminados de Not a Security Bug (No es un error de seguridad). Sin embargo, si el error sí representa una posible vulnerabilidad de seguridad, el buscador configura Security Cause en uno de los siguientes valores:

• Arithmetic error (Error aritmético)
• Buffer overflow/underflow (Desbordamiento/subdesbordamiento del búfer)
• Cross-Site Scripting (Scripting entre sitios)
• Cryptographic weakness (Debilidad criptográfica)
• Directory traversal (Cruce seguro de directorios)
• Incorrect/no error messages (Mensajes de incorrecto/sin error)
• Incorrect/no pathname canonicalization (Canonización incorrecta/sin nombre de ruta)
• Ineffective secret hiding (Ocultamiento de secreto ineficaz)
• Race condition ()
• SQL/script injection (Inyección de SQL/script)
• Unlimited resource consumption (Consumo de recursos ilimitado, denegación de servicio)
• Weak authentication (Autenticación débil)
• Weak authorization/inappropriate permission or ACL (Autorización débil/permiso o ACL inadecuados)
• Other (Otro)

El buscador también establece Security Effect en uno de los valores STRIDE:

• Spoofing (Suplantación de identidad)
• Tampering (Manipulación)
• Repudiation (Rechazo)
• Information Disclosure (Divulgación de información)
• Denial of Service (Denegación de servicio)
• Elevation of Privilege (Elevación de privilegios)

Por último, el buscador también puede elegir establecer el valor Scope (De alcance) del error. En pocas palabras, Scope define cierta información subjetiva adicional acerca del error que, a continuación, se usa para determinar su gravedad. Los valores permitidos para Scope varían según el valor de Security Effect seleccionado. Por ejemplo, si elige Elevation of Privilege para Security Effect, las posibles opciones de Scope incluyen:

• (Cliente) Un usuario remoto tiene la capacidad de ejecutar código arbitrario o de obtener más privilegios que los que tiene destinados.
• (Cliente) Un usuario remoto tiene la capacidad de ejecutar código arbitrario con amplia acción del usuario.
• (Cliente) Un usuario de bajos privilegios local puede elevarse a sí mismo o a otro usuario, administrador o sistema local.
• (Servidor) Un usuario anónimo remoto tiene la capacidad de ejecutar código arbitrario o de obtener más privilegios que los que tiene destinados.
• (Servidor) Un usuario autenticado remoto tiene la capacidad de ejecutar código arbitrario o de obtener más privilegios que los que tiene destinados.
• (Servidor) Un usuario autenticado local tiene la capacidad de ejecutar código arbitrario o de obtener más privilegios que los que tiene destinados.

Se puede ver que los ejes de la gravedad de las vulnerabilidades de Elevation of Privilege (esto es, las características que hacen que una Elevation of Privilege sea peor que otra) tienen que ver con condiciones tales como el sitio del ataque (si es el cliente o el servidor) y el nivel de autenticación del atacante (anónimo o autenticado). Sin embargo, si elige otro Security Effect, como Denial of Service, las opciones de Scope cambian para reflejar los ejes de gravedad de ese efecto en particular:

• (Cliente) Denegación de servicio que exige la reinstalación del sistema o de los componentes
• (Cliente) Denegación de servicio que exige el reinicio o provoca comprobación de pantalla azul o error
• (Cliente) Denegación de servicio que exige el reinicio de la aplicación
• (Servidor) Denegación de servicio por parte de un usuario anónimo con una pequeña cantidad de datos
• (Servidor) Denegación de servicio por parte de un usuario anónimo sin amplificación en instalación predeterminada o común
• (Servidor) Denegación de servicio por parte de un usuario autenticado que exige el reinicio o la reinstalación del sistema
• (Servidor) Denegación de servicio por parte de un usuario autenticado en instalación predeterminada o común

Una vez que se han escrito todos los valores de Security Cause, Security Effect y Scope, la plantilla usa estos datos para calcular una gravedad mínima para el error. El usuario puede elegir establecer la gravedad real del error más alto que el nivel mínimo, por ejemplo, establecer el error como un “1–Critical” (“1 Crítico”) en lugar de “2–High” (“2 Alto”), pero nunca al revés. Esto puede parecer demasiado estricto, pero evita la tentación de bajar la gravedad del error para cumplir con fechas de envío o fechas límites del sprint (un sprint es un período de tiempo breve, normalmente entre 15 y 60 días).

Si desea obtener más información acerca de las razones para establecer una metodología de nivel de error más objetiva, lea la columna de Pinceladas sobre seguridad de marzo de 2010, “Agregue una barra de errores de seguridad a Microsoft Team Foundation Server 2010” (msdn.microsoft.com/magazine/ee336031). El proceso para agregar un nivel de seguridad a TFS que detallé en dicho artículo ya está incorporado en la plantilla MSF-Agile+SDL.

Por último, existe un campo opcional más en el elemento de trabajo de error. Puede usar el campo Origin (Origen) para especificar el nombre de la herramienta de seguridad automatizada que encontró el error originalmente (si lo hay), o puede dejar el campo en su valor predeterminado de “User” (“Usuario”) si un usuario encontró el error a través de revisión o pruebas de código manuales.

Con el tiempo, recopilará suficientes datos para determinar cuál de las herramientas de prueba ofrece más por el mismo precio. Para facilitar esta determinación, la plantilla MSF-Agile+SDL incluye un informe de Excel llamado Bugs by Origin (Errores por origen), que muestra un gráfico de barras de vulnerabilidades desglosado por campo Origin.

Puede personalizar este informe para que filtre los datos según Severity (Gravedad), Security Cause o Security Effect. Si desea ver las herramientas que funcionan mejor para el hallazgo de vulnerabilidades de scripting entre sitios, o las herramientas que han encontrado los errores de Elevation of Privilege de mayor gravedad, eso también es fácil de hacer.

Flujo de trabajo de errores

De la misma manera en que no se pueden aplazar las tareas de SDL, no es posible aplazar ningún error con implicaciones de seguridad (esto es, ningún error cuyo Security Effect esté configurado en un valor distinto de Not a Security Bug). El equipo debe solicitar una excepción para retrasar la fijación de cualquier error de seguridad con gravedad de “3 – Moderate” (“3 Moderado”) o superior.

El proceso para esto es idéntico al proceso de solicitud de excepción para tareas de SDL: un miembro del equipo establece el estado en Exception Requested y escribe detalles para los campos Justification, Exception Resolution (Resolución de excepción) y Exception Timeframe (Período de tiempo de excepción). El asesor de seguridad del equipo, a continuación, revisa la solicitud de excepción y la aprueba (configurando State en Closed with a Reason of Approved) o la rechaza (configurando State en Active with a Reason of Denied).

Security Queries (Consultas de seguridad) y Security Dashboard (Panel de seguridad)

Además, la plantilla MSF-Agile+SDL también incluye varias nuevas consultas de equipo para simplificar el seguimiento del proceso. Estas nuevas consultas aparecen en la carpeta Security Queries (Consultas de seguridad) en Team Explorer e incluyen:

• Active Security Bugs (Errores de seguridad activos)
• My Security Bugs (Mis errores de seguridad)
• Resolved Security Bugs (Errores de seguridad resueltos)
• Open SDL Tasks (Tareas de SDL abiertas)
• My SDL Tasks (Mis tareas de SDL)
• Open Exceptions (Excepciones abiertas (incluye tanto tareas como errores, y es especialmente útil para asesores de seguridad))
• Approved Exceptions (Excepciones aprobadas)
• Security Exit Criteria (Criterios de salida de seguridad)

La mayoría de estas consultas no necesitan explicación, pero las consultas de Security Exit Criteria sí la necesitan. Para cumplir con su compromiso de SDL para determinada iteración, el equipo debe haber finalizado todas las siguientes actividades:

• Todo requisito de tarea de SDL de cada sprint recurrente para dicha iteración se debe finalizar o debe tener una excepción aprobada por el asesor de seguridad del equipo
• No debe haber requisitos de tareas SDL expiradas de una sola vez o de depósito
• Todos los errores con implicancias de seguridad de gravedad “3 – Moderate” o mayor deben estar cerrados o tener una excepción aprobada por el asesor de seguridad del equipo

Los términos de cada sprint, de una sola vez y de depósito en este contexto se refieren al concepto de SDL-Agile de requisitos de organización basados en la frecuencia con la que se deben finalizar. Los requisitos de cada sprint son requisitos recurrentes, y se deben realizar en cada iteración. Los requisitos de una sola vez son requisitos no recurrentes y sólo se deben finalizar una vez. Los requisitos de depósito son requisitos recurrentes, pero sólo se deben realizar una vez cada seis meses.

El análisis detallado de este sistema de clasificación está más allá del alcance de este artículo, pero si desea aprender más acerca de este sistema, lea el artículo de la revista MSDN Magazine “Agile SDL: Optimice las prácticas de seguridad para un desarrollo ágil” de la edición de noviembre de 2008.

La intención de la consulta Security Exit Criteria es proporcionar a los miembros del equipo una manera fácil para comprobar cuánto trabajo les queda para finalizar su compromiso de SDL. Si configura un sitio de SharePoint para su proyecto de equipo de MSF-Agile+SDL cuando lo crea (normalmente esto se hace en forma automática), también verá los resultados de la consulta Security Exit Criteria en Security Dashboard del proyecto de equipo.

El nuevo Security Dashboard está disponible sólo para proyectos MSF-Agile+SDL (consulte la Figura 1). De manera predeterminada, esto incluye consultas Security Exit Criteria, Open SDL Tasks, Open Exceptions y Security Bugs (Errores de seguridad), pero se pueden personalizar si lo desea. Security Dashboard también se configura como la página del portal del proyecto predeterminada para todos los proyectos MSF-Agile+SDL, pero si desea cambiar a otro panel predeterminado, sólo abra la biblioteca de documentos Dashboards (Paneles), seleccione el panel que desea usar y elija la opción “Set as Default Page” (“Establecer como página predeterminada”).

Figura 1 Security Dashboard de MSF-Agile+SDL

Criteria (Criterios), Open SDL Tasks, Open Exceptions y Security Bugs, pero se pueden personalizar si lo desea. Security Dashboard también se configura como la página del portal del proyecto predeterminada para todos los proyectos MSF-Agile+SDL, pero si desea cambiar a otro panel predeterminado, sólo abra la biblioteca de documentos Dashboards, seleccione el panel que desea usar y elija la opción “Set as Default Page”.

Directivas de protección

La última característica de la plantilla de procesos de MSF-Agile+SDL es el conjunto de directivas de protección de SDL. Estas directivas ayudan a impedir que los desarrolladores validen código que viole ciertos requisitos de SDL y que, por lo tanto, pueda crear vulnerabilidades de seguridad. Las directivas de protección de SDL están disponibles según se muestra en la Figura 2.

Figura 2 Directivas de protección de MSF-Agile+SDL

Directiva de protección de SDL	Descripción
APIs no admitidas por SDL	Asegura que la opción del compilador trate a la advertencia C4996 (uso de una función desusada) como error. Dado que la mayoría de las funciones de biblioteca en tiempo de ejecución que pueden provocar saturaciones de búfer (por ejemplo, strcpy, strncpy y gets) han caído en desuso en favor de alternativas más seguras (strcpy_s, strncpy_s y gets_s, respectivamente), el uso de esta directiva de protección puede mejorar significativamente la resistencia de la aplicación a ataques de saturación de búfer.
Comprobación de seguridad del búfer de SDL	Asegura que se active la opción Enable Buffer Security Check (/GS) (Activar comprobación de seguridad del búfer (/GS)) del compilador. Esta opción reorganiza la pila del programa compilado para incluir una cookie de seguridad o un valor canary que aumente significativamente la dificultad para que un atacante escriba una vulnerabilidad de seguridad confiable de cualquier vulnerabilidad de desbordamiento de pila.
SDL DEP y ASLR	Asegura que se activen las opciones del vinculador Data Execution Prevention (/NXCOMPAT) (Prevención de ejecución de datos (/NXCOMPAT)) y Randomized Base Address (/DYNAMICBASE) (Dirección base aleatoria (/DYNAMICBASE)). Estas opciones distribuyen de manera aleatoria las direcciones en las que se cargan aplicaciones en la memoria y ayudan a prevenir que se ejecute código en la memoria destinado a asignarse como datos. Especialmente cuando se usa en combinación, estas dos opciones son fuertes medidas de defensa en profundidad contra ataques de saturación del búfer.
Controladores de excepción segura de SDL	Asegura que se active la opción del vinculador /SAFESEH. Esta opción ayuda a impedir que atacantes definan controladores de excepción malintencionados, que podrían comprometer el sistema. /SAFESEH crea una tabla de controladores de excepción legítimos en el tiempo de vinculación, y no permite que se ejecuten otros controladores de excepción.
Variables sin inicializar de SDL	Asegura que el nivel de advertencia del compilador esté configurado en nivel 4 (/W4), el más estricto. El uso de esta opción marca código en el que puedan haberse usado variables sin inicializar, lo que podría provocar posibles vulnerabilidades de seguridad.

Es simple activar cualquiera o todas las directivas de protección de SDL. En Team Explorer, haga clic con el botón secundario en un Team Project (Proyecto de equipo) y seleccione la opción Source Control (Control de código fuente) en el menú contextual. Elija la pestaña Check-in Policy (Directiva de protección) y agregue las directivas de SDL que desea aplicar (consulte la Figura 3). Es importante tener en cuenta que la aplicación de directivas de protección se realiza en la máquina cliente, no en el servidor TFS, por lo que deberá instalar las directivas de protección de SDL en la máquina de cada desarrollador.

Figura 3 Adición de directivas de protección

Conclusión

Para que cualquier metodología de desarrollo sea eficaz, debe ser fácil de automatizar y administrar. La plantilla de procesos de MSF-Agile+SDL ayuda significativamente con estos dos requisitos. Si ya usa la plantilla de procesos de MSF-Agile que se incluye con TFS, ya sabe cómo usar la plantilla de MSF-Agile+SDL; es un supraconjunto estricto de la plantilla de MSF-Agile con el que ya está familiarizado. Descárguela de microsoft.com/sdl y comience a crear productos más seguros y con mayor conciencia de la privacidad hoy.

Bryan Sullivan es administrador de programas del equipo de ciclo de vida de desarrollo de seguridad de Microsoft, donde se especializa en aplicaciones web y problemas de seguridad de .NET. Es el autor de “Ajax Security” (Addison-Wesley, 2007).

Gracias al siguiente experto técnico por revisar este artículo: Michael Howard