Más información sobre la privacidad y seguridad en el diseño
El SDL de Microsoft destaca la importancia de la seguridad y la privacidad por diseño. Las características de seguridad y privacidad no deben ser complementos, sino componentes centrales de nuestros productos y servicios. La seguridad se basa en nuestros productos mediante la definición de requisitos de seguridad al principio del ciclo de vida de las características, el mantenimiento de modelos de amenazas actualizados para todos los componentes y características de servicio principales y la necesidad de revisar el código manual de todo el código fuente.
Requisitos de seguridad y privacidad
Los requisitos de seguridad y privacidad deben informar al diseño de todas las aplicaciones y sistemas altamente seguros. En Microsoft, todos los productos, servicios y características que desarrollamos comienzan con requisitos de seguridad y privacidad claramente definidos. Dado que el desarrollo de software es un proceso continuo, actualizamos continuamente estos requisitos a lo largo del ciclo de vida de un producto para reflejar los cambios tanto en la funcionalidad necesaria como en el panorama de amenazas. Entre los factores que influyen en los requisitos de seguridad y privacidad se incluyen la naturaleza del software que se está desarrollando, las amenazas de seguridad conocidas, las lecciones aprendidas de los incidentes de seguridad, los requisitos legales y del sector, y los estándares internos y las prácticas de codificación.
El momento óptimo para definir los requisitos de seguridad y privacidad es durante las fases iniciales de diseño y planeamiento de un producto o característica. Esto permite a los equipos de desarrollo integrar características de seguridad en la funcionalidad principal de un producto. Por ejemplo, una pregunta que formulamos sobre cada producto durante la fase de diseño es si el producto controlará información confidencial, como los datos de los clientes. SDL de Microsoft incluye requisitos de seguridad y privacidad para ayudar a los desarrolladores a implementar procedimientos recomendados para el control de datos confidenciales y garantizar que nuestro software recopila, procesa y almacena datos confidenciales de forma segura en cumplimiento de los requisitos pertinentes. Los requisitos de SDL para el control de datos confidenciales incluyen cifrado, registro y preparación para la respuesta a incidentes para proteger los datos confidenciales y proporcionar a los equipos de respuesta de seguridad de Microsoft las funcionalidades de auditoría necesarias para investigar y responder a posibles incidentes de seguridad.
Modelos de amenazas y diagramas de flujo de datos (DFD)
Una vez que el diseño de un producto incluye requisitos de seguridad y privacidad claramente definidos, los equipos de desarrollo crean modelos de amenazas para visualizar las amenazas de seguridad y privacidad que es más probable que afecten al producto. El modelado de amenazas ayuda a identificar, clasificar y evaluar posibles amenazas según el riesgo para que los desarrolladores puedan proponer e implementar mitigaciones adecuadas. Sdl requiere que los equipos de desarrollo de Microsoft mantengan modelos de amenazas actualizados y diagramas de flujo de datos (DFD) para todos los componentes y características principales del servicio.
El modelado de amenazas comienza por definir componentes de un producto o característica y diagramar sus relaciones entre sí para escenarios funcionales clave, como la autenticación o el control de datos confidenciales. Los diagramas de modelado de amenazas incluyen flujos de datos, funciones y procesos relevantes para ayudar a visualizar las amenazas al servicio. Como parte del proceso de modelado de amenazas, los equipos de servicio crean y mantienen DFD que documenta todos los flujos de datos, puertos y protocolos usados por un componente o característica de servicio.
Los diagramas completados se usan para identificar amenazas al sistema y priorizar las amenazas para la mitigación. Los equipos de desarrollo proponen e implementan mitigaciones de riesgos expuestos por sus modelos de amenazas. Se agregan nuevas mitigaciones a los requisitos de seguridad del producto, validan en el código durante la revisión manual del código y las pruebas automatizadas, y se revisan como parte del proceso de aprobación antes del lanzamiento.
Dado que el desarrollo de software moderno con Agile enfatiza la entrega rápida de características a los clientes, el modelado de amenazas es un proceso continuo. Para garantizar la coherencia entre los equipos de desarrollo y ayudar a mantener actualizados los modelos de amenazas, Microsoft requiere que sus desarrolladores usen la Threat Modeling Tool de Microsoft para todos los modelos de amenazas. El Threat Modeling Tool permite a cualquier desarrollador o arquitecto de software de Microsoft:
- Comunicarse sobre el diseño de seguridad de sus sistemas.
- Analice los diseños de seguridad para detectar posibles problemas de seguridad mediante una metodología probada.
- Sugiera y administre mitigaciones para problemas de seguridad.
Durante la revisión de seguridad antes del lanzamiento, todos los modelos de amenazas se revisan para comprobar la precisión y la integridad, incluidas las mitigaciones de riesgos inaceptables. Estas revisiones mantienen la responsabilidad y fomentan el diseño orientado a la seguridad.
Revisión manual del código
Nuestros equipos de desarrollo usan Azure DevOps Git para el control de versiones en todos los repositorios de código nuevos. Para comprobar que todo el código desarrollado en Microsoft se ajusta a los requisitos de diseño y SDL, el SDL requiere la revisión manual del código por parte de un revisor independiente antes de que los cambios de código se puedan proteger en una rama de versión. Los revisores de código comprueban si hay errores de codificación y comprueban que los cambios de código cumplen los requisitos de diseño y SDL, pasan pruebas funcionales y de seguridad y funcionan de forma confiable. También revisan la documentación, las configuraciones y las dependencias asociadas para asegurarse de que los cambios de código se documentan correctamente y no provocarán efectos secundarios imprescriptibles.
Si un revisor encuentra problemas durante la revisión del código, puede pedir al remitente que vuelva a enviar el código con los cambios sugeridos y pruebas adicionales. Los revisores de código también pueden decidir bloquear la inserción en el repositorio por completo para el código que no cumple los requisitos. Todos los cambios en el código enviados para su lanzamiento deben ser claramente atribuidos a un único desarrollador y revisados por un revisor independiente para mantener la responsabilidad. Además, todos los cambios en el código de lanzamiento deben registrarse y conservarse durante al menos 18 meses para proporcionar un registro auditable de todos los cambios de código, junto con su autor, justificación comercial, resultados de pruebas y el revisor que aprobó el cambio.