Compartir a través de


Ciclo de vida de desarrollo de seguridad de Microsoft (SDL)

La seguridad y la privacidad nunca deben ser una previsión posterior al desarrollo de software seguro. Debe haber un proceso formal para garantizar que el equipo de desarrollo tenga en cuenta la seguridad y la privacidad en todos los puntos del ciclo de vida del producto. El ciclo de vida de desarrollo de seguridad (SDL) de Microsoft inserta requisitos de seguridad completos, herramientas específicas de la tecnología y procesos obligatorios en el desarrollo y el funcionamiento de todos los productos de software. Todos los equipos de desarrollo de Microsoft deben cumplir los procesos y requisitos de SDL. Esta adhesión da como resultado software más seguro con menos vulnerabilidades y menos graves a un costo de desarrollo reducido.

Proceso de ciclo de vida de desarrollo de seguridad.

El SDL de Microsoft consta de siete componentes, incluidas cinco fases principales y dos actividades de seguridad auxiliares. Las cinco fases principales son los requisitos, el diseño, la implementación, la verificación y la versión. Cada una de estas fases contiene comprobaciones y aprobaciones obligatorias para garantizar que todos los requisitos de seguridad y privacidad y los procedimientos recomendados se aborden correctamente. Las dos actividades de seguridad auxiliares, entrenamiento y respuesta, se realizan antes y después de las fases principales respectivamente para asegurarse de que se implementan correctamente y el software permanece seguro después de la implementación.

Formación

Todos los empleados de Microsoft deben completar la formación general de seguridad y reconocimiento de privacidad, así como formación específica relacionada con su rol. Los nuevos empleados reciben formación inicial al contratar y se requiere formación de actualización anual a lo largo de su empleo en Microsoft.

Los desarrolladores e ingenieros también deben participar en el entrenamiento específico del rol para mantenerlos informados sobre los conceptos básicos de seguridad y las tendencias recientes en el desarrollo seguro. También se anima a todos los empleados a tiempo completo, a los internos, al personal contingente, a los subcontratistas y a los terceros a buscar formación avanzada en seguridad y privacidad.

Requisitos

Cada producto, servicio y característica que Microsoft desarrolla comienza con requisitos de seguridad y privacidad claramente definidos. Estos requisitos constituyen la base de aplicaciones seguras e informan de su diseño. Los equipos de desarrollo definen estos requisitos en función de factores como el tipo de datos que controla el producto, las amenazas conocidas, los procedimientos recomendados, las regulaciones y los requisitos del sector, y las lecciones aprendidas de incidentes anteriores. Una vez definido, el equipo de desarrollo documenta y realiza un seguimiento claro de los requisitos.

El desarrollo de software es un proceso continuo, lo que significa que los requisitos de seguridad y privacidad asociados cambian a lo largo del ciclo de vida del producto para reflejar los cambios en la funcionalidad y el panorama de amenazas.

Diseño

Una vez que defina los requisitos de seguridad, privacidad y funcionalidad, puede empezar a diseñar el software. Como parte del proceso de diseño, cree modelos de amenazas para ayudar a identificar, clasificar y evaluar posibles amenazas según el riesgo. Mantenga y actualice los modelos de amenazas a lo largo del ciclo de vida de cada producto a medida que realice cambios en el software.

Diagrama de modelado de amenazas.

El proceso de modelado de amenazas comienza definiendo los distintos componentes de un producto y cómo interactúan entre sí en escenarios funcionales clave, como la autenticación. Cree diagramas de Data Flow (DFD) para representar visualmente las interacciones clave del flujo de datos, los tipos de datos, los puertos y los protocolos utilizados. Use DFD para identificar y priorizar las amenazas para la mitigación que agregue a los requisitos de seguridad del producto.

Los equipos de servicio usan la Threat Modeling Tool de Microsoft para crear modelos de amenazas, que permiten al equipo:

  • Comunicación sobre el diseño de seguridad de sus sistemas
  • Análisis de diseños de seguridad para posibles problemas de seguridad mediante una metodología probada
  • Sugerir y administrar la mitigación de problemas de seguridad

Antes de publicar cualquier producto, revise todos los modelos de amenazas para ver si son precisos y completos, incluida la mitigación de riesgos inaceptables.

Implementación

La implementación comienza con los desarrolladores que escriben código según el plan que crearon en las dos fases anteriores. Microsoft proporciona a los desarrolladores un conjunto de herramientas de desarrollo seguras para implementar de forma eficaz todos los requisitos de seguridad, privacidad y función del software que diseñan. Estas herramientas incluyen compiladores, entornos de desarrollo seguros y comprobaciones de seguridad integradas.

Verificación

Antes de publicar cualquier código escrito, debe completar varias comprobaciones y aprobaciones para comprobar que el código se ajusta a SDL, cumple los requisitos de diseño y está libre de errores de codificación. Una revisión manual la realiza un revisor que no es el ingeniero que desarrolló el código. La separación de tareas es un control importante en este paso para minimizar el riesgo de que el código se escriba y libere, lo que conduce a daños accidentales o malintencionados.

También debe ejecutar varias comprobaciones automatizadas integradas en la canalización para analizar el código durante la protección y cuando se compilan las compilaciones. Las comprobaciones de seguridad usadas en Microsoft se dividen en las siguientes categorías:

  • Análisis de código estático: analiza el código fuente en busca de posibles errores de seguridad, incluida la presencia de credenciales en el código.
  • Análisis binario: evalúa las vulnerabilidades en el nivel de código binario para confirmar que el código está listo para producción.
  • Escáner de credenciales y secretos: identifica las posibles instancias de la exposición de credenciales y secretos en el código fuente y los archivos de configuración.
  • Examen de cifrado: valida los procedimientos recomendados de cifrado en el código fuente y la ejecución de código.
  • Pruebas aproximadas: usa datos incorrectos e inesperados para ejercer API y analizadores para comprobar si hay vulnerabilidades y validar el control de errores.
  • Validación de configuración: analiza la configuración de los sistemas de producción en función de los estándares de seguridad y los procedimientos recomendados.
  • Gobernanza de componentes (CG): detección y comprobación de software de código abierto de la versión, vulnerabilidad y obligaciones legales.

Si el revisor manual o las herramientas automatizadas encuentran algún problema con el código, notifican al remitente. El remitente debe realizar los cambios necesarios antes de volver a enviar el código para su revisión.

Además, los proveedores internos y externos realizan periódicamente pruebas de penetración en Microsoft servicios en línea. Las pruebas de penetración proporcionan otro medio para detectar errores de seguridad que otros métodos no detectaron. Para obtener más información sobre las pruebas de penetración en Microsoft, consulte Simulación de ataques en Microsoft 365.

Versión

Después de pasar todas las pruebas y revisiones de seguridad necesarias, las compilaciones no se publican inmediatamente para todos los clientes. El proceso de lanzamiento libera sistemática y gradualmente compilaciones en grupos más grandes y grandes, lo que se conoce como anillos, en lo que se denomina proceso de implementación segura (SDP). Los anillos SDP generalmente se pueden definir como:

  • Anillo 0: el equipo de desarrollo responsable del servicio o la característica
  • Anillo 1: Todos los empleados de Microsoft
  • Anillo 2: Usuarios fuera de Microsoft que han configurado su organización o usuarios específicos para que estén en el canal de versión de destino
  • Anillo 3: Versión estándar mundial en subfásicas

Las compilaciones permanecen en cada uno de estos anillos durante un número adecuado de días con períodos de carga elevados, excepto en el anillo 3, ya que la compilación se prueba adecuadamente para la estabilidad en los anillos anteriores.

Respuesta

Después de la versión, todos los servicios de Microsoft se registran y supervisan ampliamente. Un sistema de supervisión propietario centralizado casi en tiempo real identifica posibles incidentes de seguridad. Para obtener más información sobre la supervisión de seguridad y la administración de incidentes de seguridad en Microsoft, consulte Introducción a la supervisión de seguridad y Administración de incidentes de seguridad de Microsoft.