El ciclo de vida de desarrollo de seguridad de Trustworthy Computing

Artículo
01/17/2008

18 de Julio de 2005

Publicado: Marzo de 2005

Steve Lipner

Michael Howard

Ingeniería de seguridad y comunicaciones

Unidad tecnológica y empresarial de seguridad

Microsoft Corporation

Resumen: en este artículo se describe el ciclo de vida de desarrollo de seguridad (SDL, Security Development Lifecycle) de Trustworthy Computing (computación confiable), un proceso que Microsoft utiliza ahora para desarrollar software que pueda resistir ataques malintencionados. Este proceso incorpora varias actividades y materiales relacionados con la seguridad a cada una de las fases del proceso de desarrollo de software de Microsoft. Estas actividades y materiales incluyen el desarrollo de modelos de amenazas durante el diseño de software, el uso de herramientas de exploración del código de análisis estático durante la implementación y la realización de revisiones del código y pruebas de seguridad durante una "campaña de seguridad". Antes del lanzamiento de software sometido al SDL, un equipo independiente del grupo de desarrollo debe realizar una revisión final de seguridad. En comparación con el software que no se ha sometido al SDL, el software que ha seguido este proceso ha presentado una reducción considerable en el número de detección externa de vulnerabilidades de seguridad. En este artículo se describe el SDL y se comenta la experiencia obtenida durante su implementación en el software de Microsoft. (19 páginas impresas.) (Este artículo contiene vínculos a páginas en inglés.)

Nota. Este artículo es una versión actualizada de "The Trustworthy Computing Security Development Lifecycle" que se presentó por primera vez en la conferencia 2004 Annual Computer Security Applications Conference copatrocinada por IEEE y celebrada en Tucson, Arizona (EE.UU.) en diciembre de 2004.

En esta página

1. Introducción
1.1 El proceso de línea de base
1.2 Introducción al ciclo de vida de desarrollo de seguridad
2. El proceso de ciclo de vida de desarrollo de seguridad
2.1 Fase de requisitos
2.2 Fase de diseño
2.3 Fase de implementación
2.4 Fase de comprobación
2.5 Fase de lanzamiento
2.6 Fase de servicio técnico y mantenimiento
3. Implementación del ciclo de vida de desarrollo de seguridad en Microsoft
3.1 Aplicación obligatoria del SDL
3.2 Cursos obligatorios
3.3 Indicadores para equipos de producto
3.4 El equipo de seguridad central
4. Resultados de la implementación del ciclo de vida de desarrollo de seguridad en Microsoft
5. Observaciones sobre la aplicación del ciclo de vida de desarrollo de seguridad
5.1 Eficacia de los elementos del SDL
5.2 Herramientas, pruebas y revisiones del código
5.3 Inversiones
5.4 Resultados
6. Conclusiones
7. Agradecimientos
8. Referencias
9. Avisos

1. Introducción

Todos los proveedores de software deben tener en cuenta las amenazas de seguridad. La seguridad es un requisito básico para los proveedores de software, obligados por las fuerzas del mercado, dada la necesidad de proteger infraestructuras de gran importancia y crear y preservar la confiabilidad en la computación. Uno de los retos más importantes a los que se enfrentan todos los proveedores de software es crear un software más seguro que requiera menos actualizaciones y una administración de seguridad menos onerosa.

En el sector del software, la clave para cumplir la exigencia actual de una mayor seguridad está en implementar procesos reproducibles que proporcionen de manera confiable una mayor seguridad que se pueda medir. Por tanto, los proveedores de software deben adoptar un proceso de desarrollo más estricto que se centre, en mayor medida, en la seguridad. Este proceso debe diseñarse para minimizar el número de vulnerabilidades de seguridad presentes en el diseño, la programación y la documentación, así como para detectarlas y eliminarlas cuanto antes en el ciclo de vida de desarrollo. La necesidad de disponer de este proceso es mayor para el software profesional y doméstico que suele procesar información procedente de Internet, procesar información de identificación personal o controlar sistemas de gran importancia que pueden sufrir ataques.

Para lograr un software más seguro, hay que tener en cuenta tres aspectos: proceso reproducible, conocimientos del ingeniero e indicadores y responsabilidad. Este documento se centra en la reproducibilidad del proceso que propone el SDL, aunque también aborda los conocimientos del ingeniero y ofrece algunos indicadores globales que muestran el impacto actual de la aplicación de un subconjunto del SDL.

Si la experiencia de Microsoft es representativa, la adopción del SDL por otras organizaciones no debería suponer un costo prohibitivo para el desarrollo de software. Según la experiencia obtenida por Microsoft, las ventajas de ofrecer un software más seguro (por ejemplo, menor número de actualizaciones, mayor satisfacción de los clientes) compensan los costos.

El SDL implica cambiar los procesos de una organización de desarrollo de software mediante la integración de medidas que mejoren la seguridad del software. En este artículo se resumen estas medidas y se describe la manera de integrarlas en un ciclo de vida de desarrollo de software habitual. Estas modificaciones no pretenden examinar el proceso de manera exhaustiva, sino agregar puntos de control y materiales de seguridad bien definidos.

Este documento supone que hay un grupo central en la compañía (u organización de desarrollo de software) que controla el desarrollo y la evolución de las prácticas recomendadas de seguridad y las mejoras de los procesos, actúa como fuente de conocimientos para toda la organización y realiza una revisión (la revisión final de seguridad (FSR, Final Security Review)) antes del lanzamiento del software. Según la experiencia de Microsoft, la existencia de tal organización es vital para implementar adecuadamente el SDL, así como para mejorar la seguridad del software. No obstante, algunas organizaciones pueden plantearse delegar en un consultor o asesor externo esta función de "equipo de seguridad central". Este artículo describe la integración de un conjunto de pasos destinados a aumentar la seguridad del software durante el proceso de desarrollo de software que suelen utilizar grandes organizaciones de desarrollo de software. Microsoft ha diseñado e implementado estos pasos como parte de su iniciativa Trustworthy Computing. El objetivo de estas mejoras de procesos es reducir el número y la gravedad de las vulnerabilidades de seguridad del software utilizado por los clientes. En este documento, se hará referencia al proceso de desarrollo de software modificado, que se está implementando en estos momentos en Microsoft, como ciclo de vida de desarrollo de software (SDL, Software Development Lifecycle) de Trustworthy Computing.

Según la experiencia de Microsoft, el equipo de seguridad debe estar disponible para recurrir a él con frecuencia durante el diseño y el desarrollo del software, y es preciso confiarle información técnica y empresarial confidencial. Por estos motivos, la mejor solución es constituir un equipo de seguridad dentro de la organización de desarrollo de software (aunque tal vez sea preciso contratar a consultores que participen en la creación y entrenamiento de los miembros del equipo).

1.1 El proceso de línea de base

El proceso de desarrollo de software aceptado de manera general en Microsoft sigue aproximadamente el flujo que se muestra en la figura 1. A nivel general, este proceso muestra las prácticas habituales del sector.

Figura 1. Proceso de desarrollo de Microsoft estándar (haga clic en la imagen para ampliarla)

Aunque la figura 1 muestra cinco puntos básicos que parecen presentar el proceso de desarrollo como una "cascada", el proceso es, en realidad, similar a una espiral. Los requisitos y el diseño con frecuencia se revisan durante la implementación, para responder a los cambios en las realidades y las necesidades del mercado que surgen durante la implementación del software. Además, el proceso de desarrollo destaca la necesidad de disponer de código ejecutable prácticamente en todos los puntos, por lo que cada uno de los puntos básicos más importantes puede dividirse en realidad en la entrega de una serie de versiones que sean operativas y se puedan probar (por el equipo de desarrollo) de manera continua.

1.2 Introducción al ciclo de vida de desarrollo de seguridad

La experiencia en seguridad del software real ha permitido establecer una serie de principios de alto nivel para lograr un software más seguro. Microsoft hace referencia a estos principios como SD3+C – Seguro por diseño, Seguro por definición, Seguro en distribución y Comunicaciones. A continuación, se incluye una breve definición de estos principios:

Seguro por diseño: la arquitectura, el diseño y la implementación del software se deben realizar de manera que proteja tanto el software como la información que procesa, además de poder resistir ataques.
Seguro por definición: en el mundo real, el software no es nunca totalmente seguro, por lo que los diseñadores deben asumir que habrá errores de seguridad. Para minimizar los daños que se producirán cuando los atacantes descubran estos errores, el estado predeterminado del software debe elegir las opciones más seguras. Por ejemplo, el software debe ejecutarse con los mínimos privilegios necesarios y los servicios y las características que no sean necesarios de manera habitual deben deshabilitarse de manera predeterminada o establecer que sólo unos pocos usuarios puedan tener acceso a ellos.
Seguro en distribución: se debe incluir con el software información y herramientas que ayuden a los administradores y a los usuarios a utilizar este software con seguridad. Además, la implementación de las actualizaciones debe ser sencilla.
Comunicaciones: los programadores de software deben estar preparados para detectar las vulnerabilidades de seguridad del producto y deben comunicarse de manera abierta y responsable con los usuarios y los administradores para ayudarles a tomar las medidas de protección adecuadas (como la actualización o la implementación de soluciones alternativas).

Aunque todos los elementos de SD3+C imponen ciertos requisitos durante el proceso de desarrollo, los dos primeros elementos, seguro por diseño y seguro por definición, son los que más favorecen la seguridad. Seguro por diseño obliga a utilizar procesos que tratan de evitar la inclusión de vulnerabilidades de seguridad desde el principio, mientras que Seguro por definición exige que la exposición predeterminada del software, la "superficie de ataque", sea la mínima posible.

La incorporación de las medidas de seguridad que pretende integrar el paradigma SD3+C en el proceso de desarrollo existente conduce a la organización global del proceso que se muestra en la figura 2.

Figura 2. Mejoras del SDL en el proceso de desarrollo de Microsoft (haga clic en la imagen para ampliarla)

En la sección 2 de este documento se describen detalladamente los componentes del SDL. La sección 3 presenta un breve resumen de los detalles específicos de la implementación del SDL en Microsoft. La sección 4 proporciona algunos datos ilustrativos que demuestran que la aplicación desde el principio del SDL durante el desarrollo de Microsoft Windows Server 2003 y otros productos de software ha dado como resultado un menor número de vulnerabilidades de seguridad y una menor gravedad de éstas, en comparación con las versiones anteriores del software. La sección 5 ofrece algunas observaciones cualitativas sobre elementos del proceso, de acuerdo con la experiencia de Microsoft al aplicar el SDL. Por último, en la sección 6 se ofrecen las conclusiones generales.

2. El proceso de ciclo de vida de desarrollo de seguridad

Como se comentó anteriormente, este artículo no está destinado a ampliar los conocimientos del ingeniero. No obstante, es importante señalar que el programa de educación es básico para que el SDL se realice correctamente. Al terminar los estudios universitarios o profesionales sobre informática y disciplinas afines, por lo general no se disponen de los conocimientos necesarios para comenzar a trabajar en un equipo destinado al diseño, el desarrollo o la prueba de software seguro. Incluso si se han realizado cursos sobre seguridad, es más probable que se hayan estudiado algoritmos de cifrado y modelos de control de acceso que saturaciones de búfer y errores de resolución de nombres canónicos. En general, los diseñadores de software, los ingenieros y los encargados de las pruebas también carecen de los conocimientos adecuados sobre seguridad.

Teniendo esto en cuenta, toda organización que quiera desarrollar software seguro deberá asumir la responsabilidad de asegurarse de que sus empleados adquieren los conocimientos necesarios. La manera concreta de hacerlo depende del tamaño de la organización y los recursos disponibles. Una organización con un gran número de ingenieros puede crear un programa de educación interno que proporcione a sus ingenieros los conocimientos de seguridad de manera continua, mientras que una organización de menor tamaño es posible que deba recurrir a servicios de enseñanza externos. En Microsoft, todo el personal implicado en el desarrollo de software acude todos los años a un curso de "puesta al día en seguridad".

2.1 Fase de requisitos

La necesidad de considerar la seguridad "de abajo a arriba" es uno de los principios fundamentales del desarrollo de sistemas seguros. Teniendo en cuenta que muchos proyectos de desarrollo generan la siguiente versión a partir de la anterior, la fase de requisitos y el planeamiento inicial de una nueva versión o lanzamiento ofrece una oportunidad estupenda para crear software seguro.

Durante la fase de requisitos, el equipo de producto se pone en contacto con el equipo de seguridad central para solicitar la asignación de un asesor de seguridad (conocido como el encargado de la seguridad en la implementación del SDL en Microsoft) que actúa como punto de contacto, recurso y guía a través de los procedimientos de planeamiento. El asesor de seguridad ayuda al equipo de producto revisando los planes, aportando recomendaciones y asegurándose de que el equipo de seguridad planea los recursos necesarios de acuerdo con el programa de fechas del equipo de producto. El asesor de seguridad advierte al equipo de producto de los puntos básicos de seguridad y los criterios de salida que serán necesarios en función del tamaño, la complejidad y los riesgos del proyecto. El asesor de seguridad actúa como contacto entre el equipo de producto y el equipo de seguridad desde el inicio del proyecto hasta la finalización de la revisión final de seguridad y el lanzamiento del software. Este asesor también actúa como contacto entre el equipo de seguridad y la administración del equipo de producto, informando a este último del correcto avance de la seguridad del proyecto para evitar sorpresas de última hora relacionadas con la seguridad.

La fase de requisitos es la oportunidad ideal para que el equipo de producto se plantee cómo se integrará la seguridad en el proceso de desarrollo, identifique los objetivos de seguridad clave y, por lo demás, maximice la seguridad del software procurando minimizar el impacto sobre los planes y los programas. Como parte de este proceso, el equipo debe considerar cómo se integrarán las características de seguridad y las medidas de control con otros programas que probablemente se utilizarán con el software que están desarrollando. (El funcionamiento con otros programas es vital para responder a la necesidad de los usuarios de integrar los productos en sistemas seguros.) La consideración general por parte del equipo de producto de los objetivos, los retos y los planes de seguridad debe reflejarse en los documentos de planeamiento generados durante la fase de requisitos. Aunque es posible que estos planes cambien a medida que el proyecto avanza, articularlos desde el principio garantiza que no se pasa por alto ningún requisito ni surgen sorpresas de última hora.

Cada equipo de producto debe considerar los requisitos de características de seguridad como parte de esta fase. Aunque algunos requisitos de características de seguridad aparecerán a partir del modelo de amenazas, es probable que sean los requisitos de los usuarios los que dictaminen la inclusión de características de seguridad como respuesta a las demandas de los clientes. Los requisitos de características de seguridad también surgirán a partir de la necesidad de cumplir los estándares del sector y los procesos de certificación, como los criterios comunes. El equipo de producto debe detectar y reflejar estos requisitos como parte de su proceso de planeamiento normal.

2.2 Fase de diseño

La fase de diseño identifica la estructura y los requisitos globales del software. Desde el punto de vista de la seguridad, los elementos clave de la fase de diseño son:

Definir la arquitectura de seguridad y las directrices de diseño: definir la estructura global del software desde el punto de vista de la seguridad e identificar los componentes cuyo correcto funcionamiento es esencial para la seguridad (la "base de computación confiable"). La identificación de técnicas de diseño, como el uso de capas o lenguaje con tipos inflexibles, la aplicación de privilegios mínimos y la minimización de la superficie de ataque, que se aplican al software de manera global. (El uso de capas se refiere a la organización del software en componentes bien definidos que se estructuran para evitar dependencias circulares entre componentes. Los componentes se organizan en capas y una capa superior puede depender de los servicios de capas inferiores, pero se prohíbe que las capas inferiores dependan de las capas superiores.) Los detalles específicos de cada uno de los elementos de la arquitectura se indican en las especificaciones de diseño individuales, pero la arquitectura de seguridad corresponde a una perspectiva global sobre el diseño de seguridad.
Documentar los elementos de la superficie de ataque del software. Teniendo en cuenta que el software no logrará una seguridad perfecta, es importante que únicamente se expongan de manera predeterminada las características que utilicen la mayoría de los usuarios y que dichas características se instalen con el mínimo nivel de privilegios posible. La medición de los elementos de la superficie de ataque ofrece al equipo de producto un indicador continuo de la seguridad predeterminada y les permite detectar las instancias en las que el software es más susceptible de recibir ataques. Aunque algunas instancias con mayor superficie de ataque pueden estar justificadas por una mayor facilidad de uso o unas mejores funciones del producto, es importante detectar y considerar cada una de estas instancias durante el diseño y la implementación para lanzar el software con la configuración predeterminada más segura posible.
Realizar un modelado de las amenazas. El equipo debe realizar un modelado de amenazas por componentes. Mediante una metodología estructurada, el equipo de componentes identifica los activos que debe administrar el software y las interfaces que permitirán el acceso a dichos activos. El proceso de modelado de amenazas identifica las amenazas que pueden dañar a estos activos y la probabilidad de que se inflija dicho daño (estimación del riesgo). A continuación, el equipo de componente identifica las contramedidas que pueden mitigar el riesgo, ya sea mediante características de seguridad (por ejemplo, el cifrado) o mediante un funcionamiento correcto del software que proteja a los activos del daño. Por tanto, el modelado de amenazas ayuda al equipo de producto a identificar las necesidades de características de seguridad y las áreas en las que es necesario revisar con especial minuciosidad el código y probar la seguridad. El proceso de modelado de amenazas debe realizarse con una herramienta capaz de capturar modelos de amenazas en un formato que pueda leer un equipo para almacenarlo y actualizarlo.
Definir los criterios de publicación adicionales. Aunque los criterios de publicación de seguridad básicos deben definirse para toda la organización, puede que existan criterios concretos para determinados equipos de producto o lanzamientos de software que sea preciso cumplir para poder lanzar el software. Por ejemplo, un equipo de producto dedicado al desarrollo de una versión actualizada del software que se enviará a los clientes y que está expuesta a un gran número de ataques puede optar por exigir que la nueva versión no presente ninguna de las vulnerabilidades de seguridad detectadas durante cierto tiempo antes de considerar que está lista para su lanzamiento. (Es decir, el proceso de desarrollo debe descubrir las vulnerabilidades de seguridad y solucionarlas antes de que se detecten, en vez de tener que solucionarlas después de su detección.)

2.3 Fase de implementación

Durante la fase de implementación, el equipo de producto programa, prueba e integra el software. Los pasos destinados a eliminar los errores de seguridad o a impedir que se incluyan desde el principio son de gran utilidad, ya que reducen considerablemente la probabilidad de que las vulnerabilidades de seguridad lleguen a la versión final del software que se lanzará a los clientes.

Los resultados del modelado de amenazas ofrecen una orientación especialmente importante durante la fase de implementación. Los programadores deben asegurarse de que escriben correctamente el código para mitigar las amenazas de alta prioridad, mientras que los encargados de las pruebas deberán asegurarse de que estas amenazas se han bloqueado o mitigado de manera efectiva.

Los elementos del SDL que se aplican en la fase de implementación son:

Aplicar estándares de codificación y de pruebas. Los estándares de codificación evitan que los programadores incluyan errores que puedan producir vulnerabilidades de seguridad. Por ejemplo, el uso de construcciones de manipulación de búferes y de manejo de cadenas más seguras y coherentes ayuda a evitar la aparición de vulnerabilidades de seguridad de saturación del búfer. Los estándares de pruebas y las prácticas recomendadas permiten garantizar que las pruebas se centran en detectar posibles vulnerabilidades de seguridad, en vez de centrarse únicamente en el funcionamiento correcto de las características y las funciones del software.
Aplicar herramientas de comprobación de seguridad, incluidas herramientas de confusión. Estas herramientas ofrecen entradas estructuradas pero no válidas a las interfaces de programación de aplicaciones (API) de software y a las interfaces de red para maximizar la probabilidad de detectar errores que puedan ocasionar vulnerabilidades de seguridad del software.
Aplicar herramientas de exploración del código de análisis estático. Las herramientas pueden detectar algunos tipos de errores de codificación que producen vulnerabilidades de seguridad, incluidas saturaciones de búfer, desbordamientos con enteros y variables no inicializadas. Microsoft ha realizado una importante inversión en el desarrollo de este tipo de herramientas (las dos que se han utilizado durante más tiempo son PREfix y PREfast) y mejora continuamente estas herramientas a medida que surgen nuevos tipos de errores de codificación y vulnerabilidades de seguridad del software.
Realizar revisiones del código. Las revisiones del código complementan las herramientas automatizadas y las pruebas, ya que aplican el esfuerzo de programadores expertos para examinar el código fuente y detectar y eliminar posibles vulnerabilidades de seguridad. Estas revisiones constituyen un paso fundamental para eliminar las vulnerabilidades de seguridad del software durante el proceso de desarrollo.

2.4 Fase de comprobación

La fase de comprobación es el punto en el que software ya incorpora toda la funcionalidad y los usuarios pueden comenzar a probar la versión beta. Durante esta fase, mientras se prueba la versión beta del software, el equipo de producto realiza una campaña de seguridad que incluye revisiones del código de seguridad aparte de las realizadas en la fase de implementación, así como la realización de pruebas centradas en la seguridad.

Microsoft realizó campañas de seguridad durante la fase de comprobación de Windows Server 2003 y otras versiones de software a principios de 2002. Existían dos motivos para introducir la campaña de seguridad en el proceso:

El ciclo de vida del software de las versiones en cuestión había alcanzado la fase de comprobación, que era un punto adecuado para realizar las revisiones del código y las pruebas necesarias.
La realización de la campaña de seguridad durante la fase de comprobación asegura que la revisión del código y las pruebas se realizan con la versión terminada del software y ofrece una oportunidad de revisar tanto el código desarrollado o actualizado durante la fase de implementación como el código heredado que no se ha modificado.

El primero de estos motivos refleja un accidente histórico: la decisión de iniciar una campaña de seguridad se tomó en principio durante la fase de comprobación. Pero Microsoft ha llegado a la conclusión de que es una buena idea realizar una campaña de seguridad durante esta fase, tanto para asegurar que el software final cumple los requisitos como para permitir una revisión en detalle de todo el código heredado de versiones anteriores del software.

Hay que resaltar que las revisiones del código y las pruebas del código de alta prioridad (código que forma parte de la "superficie de ataque" del software) son esenciales para varias partes del SDL. Por ejemplo, estas revisiones y pruebas deben ser obligatorias en la fase de implementación para corregir cuanto antes los problemas, así como para identificar y corregir los orígenes de dichos problemas. También son fundamentales en la fase de comprobación cuando esté a punto de finalizarse.

2.5 Fase de lanzamiento

Durante la fase de lanzamiento, el software debe someterse a una revisión final de seguridad (FSR). Esta FSR debe responder a la siguiente pregunta: "Desde el punto de vista de la seguridad, ¿está este software preparado para los clientes?" La FSR se realiza en un plazo de dos a seis meses antes de la finalización del software, según el alcance del software. El software debe ser estable antes de la FSR y es de esperar que antes del lanzamiento sólo se realicen cambios mínimos y no relacionados con la seguridad.

La FSR es una revisión independiente del software que realiza el equipo de seguridad central de la organización. El asesor de seguridad del equipo de seguridad aconseja al equipo de producto sobre el ámbito de la FSR que requiere el software y ofrece al equipo de producto una lista de los requisitos de recursos antes de la FSR. El equipo de producto proporciona al equipo de seguridad los recursos y la información necesarios para llevar a cabo la FSR. Al comienzo de la FSR, el equipo de producto debe rellenar un cuestionario y entrevistarse con un miembro del equipo de seguridad asignado a la FSR. En toda FSR se deben revisar los errores que se identificaron en un principio como errores de seguridad, pero que tras analizarlos se consideró que no afectaban a la seguridad, para asegurarse de que este análisis es correcto. Una FSR también incluye una revisión de la capacidad del software para soportar vulnerabilidades de seguridad detectadas recientemente en un software similar. Una FSR para una versión de software importante requerirá realizar pruebas de penetración y, posiblemente, recurrir a asesores de revisión de seguridad externos que ayuden al equipo de seguridad.

La FSR no es únicamente un examen que se puede aprobar o suspender ni tampoco pretende detectar todas las vulnerabilidades de seguridad que quedan en el software, lo que no sería factible, sino proporcionar al equipo de producto y a la administración superior de la organización una idea global del nivel de seguridad del software y de la probabilidad de que pueda resistir ataques una vez que se haya entregado a los clientes. Si la FSR detecta patrones de vulnerabilidades de seguridad restantes, no bastará con solucionar las vulnerabilidades detectadas, sino que habrá que repetir la fase anterior y tomar las acciones necesarias para tratar los orígenes (por ejemplo, mejorar los conocimientos, mejorar las herramientas).

2.6 Fase de servicio técnico y mantenimiento

A pesar de la aplicación del SDL durante el desarrollo, las prácticas de desarrollo más avanzadas no consideran que se pueda publicar software que no tenga ninguna vulnerabilidad de seguridad (y hay buenos motivos para creer que siempre será así). Incluso aunque el proceso de desarrollo pudiera eliminar todas las vulnerabilidades de seguridad del software que se va a publicar, se descubrirían nuevos ataques y el software considerado "seguro" pasaría a ser vulnerable. Por tanto, los equipos de producto deben prepararse para responder a nuevas vulnerabilidades en el software que se entrega a los clientes.

Parte del proceso de respuesta consiste en la preparación para evaluar los informes de vulnerabilidades y lanzar consejos y actualizaciones de seguridad siempre que sea necesario. El otro componente del proceso de respuesta consiste en realizar una autopsia de las vulnerabilidades detectadas y tomar las medidas oportunas. Estas medidas pueden oscilar desde el lanzamiento de una actualización que resuelva un error aislado hasta la actualización de las herramientas de actualización del código para iniciar revisiones de código de los subsistemas principales. El objetivo durante la fase de respuesta consiste en aprender de los errores y utilizar la información de los informes de vulnerabilidades para detectar y eliminar otras vulnerabilidades antes de que se descubran en la práctica y se utilicen para poner en peligro a los clientes. El proceso de respuesta también ayuda a los equipos de producto y de seguridad a adaptar los procesos para que otros errores similares no se repitan en el futuro.

3. Implementación del ciclo de vida de desarrollo de seguridad en Microsoft

La implementación del SDL en Microsoft ha evolucionado desde las campañas de seguridad de principios de 2002. Para poder comenzar el proceso y trabajar con productos que estaban en fases avanzadas de desarrollo, las campañas de seguridad han comprimido en períodos relativamente cortos actividades que deberían haberse distribuido en varias fases del SDL. Las campañas de seguridad han afectado de manera considerable a los planes, los recursos y los programas de los equipos de producto, y hubiera sido mucho más difícil llevarlas a cabo sin el respaldo activo de la administración superior de Microsoft. Las campañas de seguridad se centraban en el modelado de amenazas, revisión del código y realización de pruebas (incluidas las de penetración). La revisión final de seguridad (FSR) se incorporó a finales de 2002 y a principios de 2003, antes del lanzamiento de Windows Server 2003, y tuvo un impacto considerable sobre la configuración predeterminada con la que se lanzó Windows Server 2003.

Tras las campañas iniciales de seguridad y las FSR, Microsoft puso en marcha un proyecto para formalizar el proceso de SDL. Hay cuatro resultados concretos del proyecto que merece la pena mencionar:

Directiva para implementar la aplicación obligatoria del SDL
Educación obligatoria del personal de ingeniería
Indicadores de los equipos de producto
Función del equipo de seguridad central

Las siguientes secciones tratan cada una de estas áreas

3.1 Aplicación obligatoria del SDL

Teniendo en cuenta los beneficios demostrados que aporta el SDL (consulte la sección 5), Microsoft ha decidido que la aplicación del SDL se convierta de manera formal en un requisito para una amplia gama de software. En el momento en que se redactó este documento, el SDL resulta obligatorio para todo el software que:

Se utilice para procesar información personal o confidencial.
Se utilice en una empresa u otra organización (incluidas organizaciones de enseñanza, gubernamentales o no lucrativas).
Se conecte a Internet o se utilice de otra manera en un entorno de red

Entre el software al que no se aplica la obligación anterior se incluyen aplicaciones independientes que no cumplen los criterios anteriores (por ejemplo, juegos infantiles para niños de corta edad, como la serie de "The Magic School Bus"). Hay que señalar que el SDL prohíbe que este software interfiera con la seguridad de la plataforma (sistema operativo u otro software) en el que se ejecute el software.

3.2 Cursos obligatorios

Un aspecto clave de las campañas de seguridad de principios de 2002 consistió en impartir cursos a todo el equipo de grupo de productos, programadores, encargados de pruebas, administradores de programas y personal de documentación. Para Microsoft, la asistencia a cursos anuales sobre seguridad por parte de ingenieros de organizaciones cuyo software se somete al SDL se ha convertido en un requisito obligatorio. Esta puesta al día anual es necesaria ya que la seguridad no es una materia estática: las amenazas, los ataques y las defensas evolucionan. Como resultado, incluso aquellos ingenieros completamente competentes y con conocimientos acerca de los aspectos de la seguridad que afectan a su software deberán realizar cursos adicionales a medida que cambie el panorama de la seguridad. Por ejemplo, la importancia de las vulnerabilidades de desbordamiento con enteros ha aumentado enormemente en los cuatro últimos años y se ha demostrado recientemente que algunos algoritmos de cifrado tienen vulnerabilidades anteriormente desconocidas.

Microsoft ha desarrollado una introducción común y una actualización sobre seguridad que se presenta a los ingenieros en cursos tanto presenciales como en formato digital. Microsoft ha utilizado este curso como base para cursos especializados por tecnología de software y por función de ingeniero. Microsoft trabaja en estos momentos en una programación de educación de seguridad que incluirá una mayor especialización por tecnología, función y nivel de conocimientos académicos.

Muchos asociados y clientes de Microsoft se han interesado por la disponibilidad de los procesos y los cursos sobre seguridad de Microsoft. Microsoft Press ha publicado varios libros basados en las prácticas internas de Microsoft acerca del modelo de amenazas, la codificación y el diseño seguros. Además, Microsoft Learning ofrece cursos basados en las prácticas internas de Microsoft.

3.3 Indicadores para equipos de producto

Como compañía, Microsoft se rige por el dicho "lo que no se mide, no se puede controlar". Aunque es muy difícil idear indicadores que midan de manera confiable la seguridad del software, hay indicadores que son claramente representativos de la seguridad del software. Estos indicadores oscilan desde la consideración de los conocimientos del personal de ingeniería (al comienzo del ciclo de vida de desarrollo) hasta los índices de vulnerabilidades descubiertas en el software que se ha entregado a los clientes.

Microsoft ha ideado un conjunto de indicadores de seguridad que los equipos de producto pueden utilizar para supervisar el éxito obtenido al implementar el SDL. Estos indicadores consideran la implementación por parte del equipo del SDL desde el modelado de amenazas pasando por la revisión del código y las pruebas de seguridad hasta la seguridad del software que indica la FSR. Como estos indicadores evolucionan con el tiempo, los equipos pueden realizar un seguimiento de su nivel (mejora, estabilización o deterioro) y comparar su nivel respecto al de otros equipos. Se informará con regularidad de los indicadores agregados a la administración ejecutiva de los equipos de producto y a los Microsoft Executives.

3.4 El equipo de seguridad central

Mucho tiempo antes de las campañas de seguridad de 2002, Microsoft había establecido el equipo Secure Windows Initiative (SWI) encargado de mejorar la seguridad del software y reducir las vulnerabilidades de Windows, así como de proporcionar ayuda sobre seguridad a los equipos de producto además de los dedicados al desarrollo de Windows. El equipo SWI desempeñó la función principal en la organización y la administración de la campaña de seguridad de Windows Server 2003 y ofreció cursos y consultoría en todas las campañas de seguridad realizadas a principios de 2002. Este equipo también realizó la FSR de Windows Server 2003, la primera del proceso de FSR.

Con la implementación formal del SDL, el equipo SWI desempeña ahora en Microsoft la función de equipo de seguridad central. Entre sus responsabilidades se incluyen:

Desarrollo, mantenimiento y mejora del SDL, incluida la definición de los aspectos obligatorios del proceso.
Desarrollo, mejora y realización de los cursos a los ingenieros.
Asignación de los "asesores de seguridad" que guían a los equipos de producto a través del proceso, realizan revisiones de los equipos de producto y se aseguran de que se responde a las preguntas planteadas por los equipos de producto de manera puntual, precisa y autorizada
Servicio de expertos en la materia en una amplia gama de temas de seguridad, asegurándose de que las preguntas realizadas a los asesores de seguridad o planteadas mediante ellos reciben respuestas puntuales y precisas.
Realización de las revisiones finales de seguridad antes del lanzamiento del software.
Investigación técnica de las vulnerabilidades detectadas en el software entregado a los clientes, para asegurarse de que se entienden las causas que las han originado y se tomen las medidas adecuadas.

La disponibilidad y la eficacia del equipo SWI han demostrado ser factores clave para la implementación del SDL en Microsoft. Microsoft desea tener un proceso escalable para desarrollar un software más seguro y este objetivo implica disponer de una competencia de seguridad distribuida entre todos los equipos de producto. Sin embargo, es fundamental disponer de un equipo de seguridad central y muy cualificado que se encargue de poner al día a los equipos de producto y les ayude a crear un software más seguro. También garantiza que la FSR la efectúa alguien ajeno al equipo de producto.

4. Resultados de la implementación del ciclo de vida de desarrollo de seguridad en Microsoft

Aunque es pronto para que Microsoft pueda afirmar de forma concluyente que el SDL mejora la seguridad del software Microsoft, los resultados obtenidos hasta la fecha son alentadores.

Windows Server 2003 fue el primer lanzamiento de sistema operativo de Microsoft en el que se implementaron partes importantes del SDL. La figura 3 muestra el número de boletines de seguridad publicados en un período de un año tras el lanzamiento de los dos sistemas operativos de servidor de Microsoft más recientes: Windows 2000 y Windows Server 2003. (Cuando se lanzó Windows 2000, Microsoft no disponía de un sistema formal de calificación de la gravedad de los boletines de seguridad. Microsoft ha evaluado todos los boletines de seguridad que se aplican a Windows 2000 respecto al sistema de calificación de la gravedad actual.) Como ya se ha comentado anteriormente en este artículo, Windows Server 2003 se desarrolló con la mayoría de los procesos del SDL (aunque no con todos), mientras que Windows 2000 no los incluyó.

Figura 3. Boletines de seguridad importantes y críticos de Windows antes y después del SDL

Las clases de gravedad se definen en https://www.microsoft.com/technet/security/bulletin/rating.mspx

Otros lanzamientos de software de Microsoft también han aplicado elementos del SDL. Los equipos de producto de SQL Server y Exchange Server también realizaron una campaña de seguridad (incluido el modelado de amenazas, las revisiones del código y las pruebas de seguridad) antes de lanzar un Service Pack, un lanzamiento de software que acumula soluciones para vulnerabilidades de seguridad y de otro tipo. Los resultados de la campaña de seguridad de SQL Server se incorporaron en SQL Server 2000 Service Pack 3 y los resultados de la campaña de seguridad de Exchange Server se incorporaron en Exchange 2000 Server Service Pack 3. Las figuras 4 y 5 muestran el número de boletines de seguridad publicados en los mismos períodos antes y después de los respectivos Service Pack (24 meses para SQL Server 2000 y 18 meses para Exchange 2000 Server).

Figura 4. Boletines de seguridad de SQL Server 2000 antes y después del SDL

Figura 5. Boletines de seguridad para Exchange Server 2000 antes y después del SDL

Otro ejemplo alentador es el del componente Internet Information Server de Windows Server 2003 (IIS 6). En los dos años que han transcurrido desde su lanzamiento, Microsoft ha publicado un boletín de seguridad que afecta al servidor Web, consistente en un componente (WebDAV) que no se instalaba de manera predeterminada.

Aunque las muestras de las vulnerabilidades de seguridad son reducidas y los períodos de tiempo son limitados, estos resultados demuestran que el SDL es eficaz. Microsoft continuará supervisando los índices de vulnerabilidades de Windows Server 2003 y los Service Packs de Exchange Server y SQL Server para ver cómo evoluciona esta tendencia. También analizará más software de Microsoft a medida que se lancen nuevas versiones tras una implementación completa del SDL para determinar si el número y el nivel de gravedad de las vulnerabilidades de seguridad siguen descendiendo.

5. Observaciones sobre la aplicación del ciclo de vida de desarrollo de seguridad

Los datos presentados en la sección anterior ofrecían información sobre "qué" se supone que debe hacer el SDL. Esta sección intenta responder a algunas preguntas sobre "cómo" funciona el proceso. Mientras que la sección anterior se basa estrictamente en números (Microsoft realiza un riguroso seguimiento de los informes de vulnerabilidad y los boletines de seguridad) esta sección se basa en casos particulares, en forma de observaciones y opiniones de los componentes del equipo SWI.

5.1 Eficacia de los elementos del SDL

El SDL se compone de un gran número de subprocesos componentes que se distribuyen por todo el ciclo de vida de desarrollo del software. Se ha solicitado al equipo SDL que asigne una prioridad a estos subprocesos en función de la eficacia, para determinar cuáles son los útiles y cuáles se han probado y resultan menos eficaces.

La opinión general del equipo SWI es que el modelado de amenazas es el componente de mayor prioridad del SDL. Evidentemente, el modelado de amenazas no se aplica de manera aislada, sino que afecta al diseño, la revisión del código y las pruebas. Un proceso que implementase únicamente el modelado de amenazas pero no tomase medidas a partir de los modelos (por ejemplo, que no comprobase la eficacia de las medidas tomadas para mitigar los problemas detectados) no tendría eficacia alguna. Las estadísticas en forma de recuentos de errores tienden a subestimar la función del modelado de amenazas, ya que gran parte de la contribución que realiza el modelado de errores consiste en asegurarse de que muchos de los errores que producirían vulnerabilidades de seguridad no lleguen a crearse. Sin embargo, la función del modelado de amenazas es de tal importancia para el proceso de desarrollo de software seguro que se sitúa claramente en el primer puesto de la lista.

El SDL sigue siendo un proceso relativamente nuevo en Microsoft, por lo que todavía no se ha dado ningún caso en el que se haya eliminado un componente del proceso. Sin embargo, hay un descubrimiento que no sorprenderá a los investigadores con larga experiencia en temas de seguridad: las pruebas de penetración no son la mejor manera de alcanzar la seguridad. Estas pruebas forman parte de la revisión final de seguridad (FSR) para un lanzamiento de software de importancia, pero las actividades del equipo de producto a través de todo el ciclo de vida se centran en el modelado de amenazas, las revisiones del código, el uso de herramientas automatizadas y las pruebas de confusión en vez de en las pruebas de penetración. Estas medidas son mucho más adecuadas a la hora de evitar o eliminar errores de seguridad que las clásicas pruebas de penetración ad hoc. Las pruebas de penetración de la FSR ayudan a determinar si el software está listo para su lanzamiento, pero no son una manera de encontrar y solucionar errores de seguridad. Si la prueba de penetración realizada en la FSR detecta muchos errores de seguridad es porque las fases anteriores no han sido suficientemente eficaces y la medida correcta consiste en repetir las actividades que se deberían haber realizado en esas fases, en lugar de solucionar únicamente los errores encontrados en las pruebas de penetración y lanzar al mercado el software.

5.2 Herramientas, pruebas y revisiones del código

Las herramientas de análisis estático, las pruebas de confusión y la revisión del código son elementos complementarios. Microsoft ha realizado una importante inversión en herramientas de exploración del código de análisis estático y las utiliza como parte integral del SDL. Estas herramientas son eficaces para encontrar muchos errores de codificación que pueden ocasionar vulnerabilidades de seguridad, en especial saturaciones del búfer. Sin embargo, ni siquiera las más avanzadas herramientas actuales consiguen detectar todos los errores. Las revisiones manuales del código siguen siendo necesarias en el SDL, tanto para detectar los errores que estas herramientas no detectan como para descubrir otras formas de mejorar estas herramientas. Un artículo de Microsoft Developer Network (MSDN) escrito por Michael Howard citaba en las referencias una introducción a la manera general de realizar las revisiones de seguridad del código que Microsoft enseña a sus ingenieros.

Una incorporación relativamente reciente al SDL es el especial hincapié que se hace en las pruebas de confusión, que han obtenido hasta la fecha unos resultados muy alentadores. A diferencia de las herramientas de exploración estática del código, las pruebas de confusión se deben crear (o al menos configurar) para cada formato de archivo o protocolo de red. Por este motivo, pueden descubrir errores que las herramientas de análisis estático son incapaces de detectar. Los modelos de amenazas ayudan a los equipos de producto a dar prioridad a determinadas interfaces y formatos a la hora de realizar pruebas. Los resultados de las pruebas de confusión no son completamente determinantes (ya que las herramientas se ejecutan durante un número definido de ciclos y no se garantiza que puedan detectar todos los errores), pero la experiencia ha demostrado que un cierto nivel asequible de pruebas de confusión puede detectar errores "interesantes" que, de otro modo, se explotarían como vulnerabilidades de seguridad.

5.3 Inversiones

La asistencia obligatoria a cursos de seguridad constituye una importante inversión para una compañía del tamaño de Microsoft dado el número de ingenieros con el que cuenta. Estos cursos combinan clases presenciales (con un profesor) y material en línea. El material en línea resulta especialmente útil para proporcionar cursos a pequeños equipos de ingeniería situados lejos de la sede de Microsoft. Las clases presenciales han sido especialmente eficaces cuando se impartía a todo un equipo en proceso de preparación para una campaña de seguridad y otras actividades clave. En estos casos, la experiencia de Microsoft sugiere que los resultados de estos cursos no dependen sólo de los conocimientos impartidos en las clases sino también de la realización de la campaña de seguridad. El efecto de los cursos de seguridad (que suelen durar medio día) queda amplificado por el hecho de que todos los componentes del grupo de trabajo están centrados en la seguridad.

El equipo de seguridad central (equipo SWI) ha crecido considerablemente durante los últimos años a medida que aumentaba la importancia que Microsoft daba a la seguridad. Por diseño, este equipo es pequeño en comparación con el número total de ingenieros con que cuenta Microsoft y recomienda métodos que pueden escalarse, lo que asegura que la responsabilidad y los recursos para crear un software más seguro recaen sobre los equipos de producto. Entre algunas estrategias que reflejan la importancia que se da a la escabilidad se incluye el hincapié que se hace en los cursos y las herramientas, la asignación de asesores de seguridad que ayudan al equipo de producto a solucionar sus propios problemas (en vez de solucionar los problemas planteados por el equipo) y el uso de revisiones (incluida la FSR) para proporcionar al equipo de producto información sobre el nivel de preparación del software para su lanzamiento.

5.4 Resultados

La última prueba del SDL consiste en ver hasta qué punto elimina o mitiga las vulnerabilidades del software de Microsoft. La experiencia, resumida en la sección 4, demuestra que el SDL supera esta prueba. Microsoft también evalúa las vulnerabilidades detectadas de manera externa para ver su efecto sobre las versiones de software que se están desarrollando. Las experiencias recientes han demostrado que las medidas de seguridad planeadas para nuevas versiones o implementadas en ellas bloquean ataques que son eficaces en versiones anteriores en un número cada vez mayor de casos. Al realizar esta revisión sobre Windows XP Service Pack 2, que se ha lanzado recientemente al mercado, se determinó que los cambios de seguridad que se habían planeado pero todavía no se habían implementado o comentado públicamente eliminaban un importante número de vulnerabilidades que investigadores de seguridad ajenos a Microsoft habían detectado en versiones anteriores de Windows.

6. Conclusiones

La experiencia de Microsoft indica que el SDL reduce la incidencia de vulnerabilidades de seguridad. La implementación inicial del SDL (en Windows Server 2003, SQL Server 2000 Service Pack 3 y Exchange 2000 Server Service Pack 3) ha conseguido mejorar considerablemente la seguridad del software. Además, las versiones posteriores de software, que incorporan las mejoras realizadas al SDL, también parece que siguen mejorando la seguridad del software.

La implementación incremental de los elementos que componen el SDL también ha producido un aumento en las mejoras, lo que se considera fruto de la eficacia del proceso. El proceso no es perfecto y sigue evolucionando, de hecho, es poco probable que alcance la perfección o deje de evolucionar en un futuro próximo.

El desarrollo y la implementación del ciclo de vida de desarrollo de seguridad representa una importante inversión para Microsoft y constituye un importante cambio en la manera de diseñar, desarrollar y probar el software. La importancia cada vez mayor del software para la sociedad resalta la necesidad de Microsoft y de todo el sector de mejorar la seguridad del software. Por tanto, Microsoft ha publicado este artículo sobre el SDL y libros sobre técnicas concretas (consulte las referencias) para compartir su experiencia con todo este sector.

7. Agradecimientos

El desarrollo inicial de este artículo comenzó a finales de 2002 como un esfuerzo conjunto de los autores actuales. Los borradores se han ido actualizando a medida que evolucionaba el SDL y la versión actual se preparó durante el verano y el otoño de 2004. Los autores desean agradecer las contribuciones de Matt Thomlinson, Matt Lyons, Jamil Villani y Eric Bidstrup (el resto de los componentes del equipo Microsoft Secure Windows Initiative) a la definición y el perfeccionamiento del SDL. Además de los colaboradores citados, Scott Charney y Phil Reitinger de Microsoft y Jeannette Wing de la universidad Carnegie Mellon University han aportado comentarios especialmente útiles sobre los borradores. Los autores también desean mostrar su agradecimiento a Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri y James Whittaker por sus comentarios y sugerencias sobre este artículo.

8. Referencias

Mundie, Craig, Trustworthy Computing White Paper

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004

Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2003

Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank and Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004

9. Avisos

La información que contiene este documento representa el punto de vista actual de Microsoft Corporation sobre los temas que se tratan en la fecha de la publicación. Puesto que Microsoft debe hacer frente a las condiciones cambiantes del mercado, no se debe interpretar como un compromiso por parte de Microsoft, que no puede garantizar la exactitud de la información que se presente después de la fecha de la publicación.

Este artículo técnico responde a fines meramente informativos. MICROSOFT NO OFRECE GARANTÍAS, EXPRESAS, IMPLÍCITAS O LEGALES EN RELACIÓN A LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO.

Queda bajo responsabilidad del usuario cumplir todas las leyes de derechos de autor aplicables. Sin limitar los derechos de propiedad, no se puede reproducir, almacenar o introducir en un sistema de recuperación, ni transmitir ninguna parte de este documento de ninguna manera o por ningún medio (electrónico, mecánico, fotocopiado, grabación u otro), o con ningún propósito, sin el permiso expreso por escrito de Microsoft Corporation.

Microsoft puede ser titular de patentes, solicitudes de patentes, marcas comerciales, derechos de autor u otros derechos de la propiedad intelectual que cubran los temas tratados en este documento. A excepción de lo indicado explícitamente en el contrato de licencia por escrito de Microsoft, este documento no le otorga ninguna licencia para estas patentes, marcas, derechos de autor u otra propiedad intelectual.

Microsoft, MSDN, Windows y Windows Server son marcas comerciales o marcas registradas de Microsoft Corporation en Estados Unidos y/o en otros países.

Compartir a través de