Ciclo de vida de desarrollo de seguridad y seguridad de aplicaciones web

(Security Development Lifecycle & Web Application Security) (Diapositiva 1)

El taller de Principios de diseño seguro presenta la función que cumple el ciclo de vida del desarrollo de la seguridad de Microsoft (SDL)
en el diseño de aplicaciones de confianza y proporciona una descripción general de los principios de diseño seguro empleados en la
SDL, que incluyen:
reducción de la superficie de ataque; privacidad básica; modelado de amenazas; defensa en profundidad; privilegios mínimos; y
valores predeterminados de seguridad.

Abordar este tema permitirá a nuestra organización mejorar nuestras prácticas de desarrollo de aplicaciones y la seguridad de nuestras
aplicaciones

El objetivo de este curso es proporcionar una descripción general del proceso SDL de Microsoft y sus fases. Le proporcionará
información valiosa sobre herramientas y técnicas útiles que lo ayudarán a crear un software más seguro.

En este curso, nosotros:

Mire el ciclo de vida del desarrollo de seguridad de Microsoft (SDL)
Revise brevemente algunos conceptos de diseño, desarrollo y prueba seguros
Explore los problemas de seguridad que surgen si estos principios de diseño, codificación y prueba no se aplican correctamente
Esto le proporcionará información que puede utilizar para hacer que su software sea más seguro.

Nota: Este curso está destinado a familiarizarse con los principios y principios de diseño de seguridad.

Road Map - Mapa vial (Diapositiva 2)

Introducción: Amenazas de seguridad y conceptos del ciclo de vida del desarrollo de la seguridad (SDL)
Principios de diseño seguro
Principios de modelado de amenazas de SDL
Principios de implementación segura
Principios de verificación de seguridad
SDL en Application Lifecycle Management (ALM) con servicios de DevOps de Azure
Los 10 principales riesgos de seguridad de aplicaciones web de OWASP

¿Qué es SDL? What’s SDL? (Diapositiva 3)

El ciclo de vida del desarrollo de la seguridad (SDL, por sus siglas en inglés) es un proceso de desarrollo de software que ayuda a los
desarrolladores a crear un software más seguro y cumplir con los requisitos de cumplimiento de seguridad, al tiempo que reduce los
costos.
https://www.microsoft.com/en-us/sdl - aquí es donde se define la definición anterior.

El ciclo de vida del desarrollo de la seguridad (SDL) es un proceso de garantía de seguridad que se centra en el desarrollo de software.
Como una iniciativa de la empresa y una política obligatoria desde 2004, la SDL ha desempeñado un papel fundamental en la
integración de la seguridad y la privacidad en el software y la cultura de Microsoft. Combinando un enfoque holístico y práctico, el
objetivo de SDL es reducir la cantidad y la gravedad de las vulnerabilidades en el software. El SDL introduce seguridad y privacidad en
todas las fases del proceso de desarrollo.
Microsoft SDL se basa en tres conceptos básicos: educación, mejora continua de procesos y responsabilidad. La educación y
capacitación continua de los roles de trabajo técnico dentro de un grupo de desarrollo de software es crítica. La inversión adecuada en
la transferencia de conocimiento ayuda a las organizaciones a reaccionar adecuadamente a los cambios en la tecnología y el panorama
de amenazas. Debido a que el riesgo de seguridad no es estático, el SDL pone un gran énfasis en comprender la causa y el efecto de
las vulnerabilidades de seguridad y requiere una evaluación regular de los procesos de SDL y la introducción de cambios en respuesta a
los nuevos avances tecnológicos o nuevas amenazas. Los datos se recopilan para evaluar la efectividad de la capacitación, las métricas
en proceso se utilizan para confirmar el cumplimiento del proceso y las métricas posteriores al lanzamiento ayudan a guiar los cambios
futuros. Finalmente, el SDL requiere el archivo de todos los datos necesarios para dar servicio a una aplicación en una crisis. Cuando se
combina con una respuesta de seguridad detallada y planes de comunicación, una organización puede brindar una orientación concisa
y convincente a todas las partes afectadas.

Participantes y roles en el proceso de SDL (Diapositiva 4)

Gerentes / Gerencia Soporta la implementación de SDL dentro de la organización. Institutos requisitos de cumplimiento para la
formación. Apoya los esfuerzos de entrenamiento de SDL Equipo de desarrollo (PM, Dev, Test) Desarrolla productos con las mejores
prácticas de seguridad utilizando el conocimiento obtenido de la capacitación de SDL. Asesor de seguridad Actúa como enlace entre los
equipos de desarrollo y seguridad. Revisa los artefactos generados durante el proceso de lanzamiento de SDL Proporciona experiencia /
orientación sobre la mitigación de problemas de seguridad descubiertos cuando sea necesario Realiza la revisión final de seguridad del
producto antes del lanzamiento.
(Diapositiva 5)

Gol:
Reduce el número de vulnerabilidades en tu código
Reduzca la severidad de las vulnerabilidades que echa de menos.

El proceso de Microsoft SDL

El SDL es un proceso de garantía de seguridad de desarrollo de software que consiste en prácticas de seguridad agrupadas por siete
fases del ciclo de vida tradicional del desarrollo de software. Las experiencias en Microsoft han demostrado que las prácticas de
seguridad ejecutadas en orden cronológico ayudaron a obtener mayores ganancias de seguridad y beneficios de costos que a partir de
la implementación ad hoc. El proceso SDL no es específico de Microsoft ni de la plataforma Windows y puede aplicarse a diferentes
sistemas operativos, plataformas, metodologías de desarrollo y proyectos de cualquier tamaño.

Pre-SDL Requisitos: Entrenamiento seguridad (Diapositiva 6)

Evaluar el conocimiento de la organización sobre seguridad y privacidad y establecer un programa de capacitación según sea necesario
Establecer criterios de formación.
Contenido que cubre diseño, desarrollo, prueba y privacidad seguros.
Establecer frecuencia mínima de entrenamiento.
Los empleados deben asistir a n clases por año.
Establecer umbrales mínimos aceptables de entrenamiento en grupo.
Objetivos de capacitación organizativa (por ejemplo, el 80% de todo el personal técnico capacitado antes del producto RTM)

Fase uno: requisitos (Diapositiva 7)

Oportunidad de considerar la seguridad al inicioion
de un proyecto.
El equipo de desarrollo identifica los requisitos de seguridad y privacidad.
Equipo de desarrollo identifica contactos de seguridad y privacidad
Asesor de seguridad asignado
El Asesor de Seguridad revisa el plan del producto, hace recomendaciones, puede establecer requisitos adicionales
Mandar el uso de un sistema de seguimiento de errores / asignación de trabajo
Defina y documente las barras de errores de seguridad y privacidad.

Fase dos: diseño

Defina y documente la arquitectura de seguridad, identifique los componentes críticos de seguridad.
Identificar técnicas de diseño (capas, código administrado, privilegios mínimos, minimización de la superficie de ataque)
Documentar la superficie de ataque y el límite a través de la configuración predeterminada.
Defina los criterios de envío de seguridad suplementarios debido a problemas de productos únicos
Pruebas de scripting entre sitios
La desaprobación de crypto débil
Modelado de amenazas
Revisión sistemática de las características y la arquitectura del producto desde un punto de vista de seguridad
Identificar amenazas y mitigaciones.
Requisitos específicos de los servicios en línea.

Fase Tres: Implementación

Revisión completa del espectro: se utiliza para determinar los procesos, la documentación y las herramientas necesarias para garantizar
una implementación y operación seguras
Especificación de herramientas de construcción aprobadas y opciones
Análisis estático (PREFix, / analyse (PREfast), FXCop)
APIs prohibidas
Uso de protecciones de “defensa en profundidad” del sistema operativo (NX, ASLR y HeapTermination)
Requisitos específicos de los servicios en línea (por ejemplo, secuencias de comandos entre sitios, inyección SQL, etc.)
Considere otras recomendaciones (por ejemplo, Lenguaje de anotación estándar (SAL))

Fase cuatro: verificación

Comenzó lo antes posible: se realizó después de la etapa de "código completo"
Iniciar la planificación de la respuesta de seguridad, incluidos los planes de respuesta para los informes de vulnerabilidad.
Re-evaluar la superficie de ataque
Fuzz testing: archivos, controles instalables y código de red
Llevar a cabo un "impulso de seguridad" (según sea necesario, cada vez más raro)
No sustituye el trabajo de seguridad realizado durante el desarrollo.
Revisión de código
Pruebas de penetración y otras pruebas de seguridad.
Revisar diseño y arquitectura ante nuevas amenazas.
Requisitos específicos de los servicios en línea.

Fase cinco: Lanzamiento

Plan de respuesta
Creación de una política de soporte claramente definida, consistente con las políticas corporativas de MS
Proporcionar un plan de respuesta a incidentes de seguridad de software (SSIRP)
Identificar contactos para MSRC y recursos para responder a eventos
Información de contacto 24x7x365 para 3-5 personas de ingeniería, 3-5 de marketing y 1-2 de gestión (PUM y superior)
Asegure la capacidad de dar servicio a todo el código, incluidas las versiones "fuera de banda" y todos los códigos de terceros con
licencia.

Revisión final de seguridad

Verifique que se cumplan los requisitos de SDL y que no haya vulnerabilidades de seguridad conocidas
Proporciona una visión independiente de la "preparación de la nave de seguridad"

El FSR NO es:
Una prueba de penetración - no se permite "penetrar y parchar"
La primera vez que se revisa la seguridad.
Un proceso de firma
Concepto clave: las tareas para esta fase se usan como un factor determinante para enviar o no, no se usan como una fase "general"
para el trabajo perdido en fases anteriores
Archivo
Plan de respuesta de seguridad completo
Documentación del cliente al día.
Archive el código fuente RTM, los símbolos y los modelos de amenazas en una ubicación central
Completar las aprobaciones finales en Checkpoint Express: validación de las políticas de seguridad, privacidad y cumplimiento
corporativo

Requisitos post-SDL: Respuesta

“Planifica el trabajo, trabaja el plan…”
Ejecución en las tareas de respuesta descritas durante las fases de lanzamiento y planificación de Security Response

Requisitos Pre-SDL: Entrenamiento de Seguridad / Pre-SDL Requirements: Security Training

Evaluar el conocimiento de la organización sobre seguridad y privacidad: establecer un programa de capacitación según sea necesario
Establecer criterios de formación. Contenido que cubre diseño, desarrollo, prueba y privacidad seguros. Establecer frecuencia mínima
de entrenamiento. Los empleados deben asistir a n clases por año. Establecer umbrales mínimos aceptables de entrenamiento en
grupo. Objetivos de capacitación organizativa (por ejemplo, el 80% de todo el personal técnico capacitado antes del producto RTM)

Todos los miembros de los equipos de desarrollo de software deben recibir la capacitación adecuada para mantenerse informados
sobre los conceptos básicos de seguridad y las tendencias recientes en materia de seguridad y privacidad. Las personas que desarrollan
programas de software deben asistir al menos a una clase de capacitación en seguridad cada año. La capacitación en seguridad puede
ayudar a garantizar que el software se cree teniendo en cuenta la seguridad y la privacidad, y también puede ayudar a los equipos de
desarrollo a mantenerse actualizados sobre los problemas de seguridad. Se recomienda encarecidamente a los miembros del equipo del
proyecto que busquen educación adicional sobre seguridad y privacidad que sea apropiada para sus necesidades o productos.
Una serie de conceptos clave de conocimiento son importantes para la seguridad exitosa del software. Estos conceptos se pueden
categorizar ampliamente como conocimientos de seguridad básicos o avanzados. Cada miembro técnico de un equipo de proyecto
(desarrollador, evaluador, administrador de programas) debe estar expuesto a los conceptos de conocimiento en las siguientes
subsecciones.
En esta página
Conceptos básicos Conceptos básicos Requisitos de seguridad Recomendaciones de seguridad Recomendaciones de privacidad
Recursos
Conceptos básicos
Diseño seguro, incluyendo los siguientes temas:
Reducción de la superficie de ataque.
Defensa en profundidad
Principio de privilegio mínimo
Valores predeterminados seguros
Modelado de amenazas, incluyendo los siguientes temas:
Visión general del modelado de amenazas
Diseñar a un modelo de amenaza.
Codificación a un modelo de amenaza.
Probando a un modelo de amenaza
Codificación segura, incluyendo los siguientes temas:
Desbordamientos de búfer
Errores aritméticos de enteros
Secuencias de comandos de sitios cruzados
inyección SQL
Criptografía débil
Problemas de código gestionado (Microsoft .NET / Java)
Pruebas de seguridad, incluyendo los siguientes temas:
Pruebas de seguridad versus pruebas funcionales
Evaluación de riesgos
Metodologías de prueba
Automatización de pruebas
Privacidad, incluyendo los siguientes temas:
Tipos de datos de privacidad
Mejores prácticas de diseño de privacidad
Análisis de riesgo
Mejores prácticas de desarrollo de privacidad
Mejores prácticas de prueba de privacidad
Parte superior de la página

Conceptos avanzados
Los conceptos de capacitación anteriores establecen una línea de base de conocimiento adecuada para el personal técnico. A medida
que el tiempo y los recursos lo permitan, se recomienda que explore otros conceptos avanzados. Los ejemplos incluyen (pero no se
limitan a):
Diseño y arquitectura de seguridad.
Diseño de interfaz de usuario
Las preocupaciones de seguridad en detalle
Procesos de respuesta de seguridad.
Implementando mitigaciones de amenazas personalizadas
Requerimientos de seguridad
Todos los desarrolladores, evaluadores y administradores de programas deben completar al menos una clase de capacitación en
seguridad cada año. Las personas que no hayan tomado una clase en los conceptos básicos de diseño, desarrollo y pruebas de
seguridad deben hacerlo.
Al menos el 80 por ciento del personal del equipo del proyecto que trabaja en productos o servicios debe cumplir con los estándares
enumerados anteriormente antes de que se publique su producto o servicio. Los gerentes relevantes también deben cumplir con estas
normas. Se recomienda encarecidamente a los equipos del proyecto que planifiquen la capacitación en seguridad al inicio del proceso
de desarrollo para que la capacitación se complete lo antes posible y tenga un efecto positivo máximo en la seguridad del proyecto.
Recomendaciones de seguridad
Recomendamos que el personal que trabaja en todas las disciplinas lea las siguientes publicaciones:
Escribir código seguro, segunda edición (ISBN 9780735617223; ISBN: 0-7356-1722-8)
Descubra defectos de diseño de seguridad utilizando el enfoque STRIDE (ISBN: 0-7356-1991-3).
Recomendaciones de privacidad
Microsoft recomienda que el personal que trabaja en todas las disciplinas lea los siguientes documentos:
Apéndice A: Privacidad de un vistazo (muestra)
Pautas de privacidad de Microsoft para desarrollar productos y servicios de software

Fase uno: requisitos

Oportunidad de considerar la seguridad al inicio de un proyecto.
El equipo de desarrollo identifica los requisitos de seguridad y privacidad.
Equipo de desarrollo identifica contactos de seguridad y privacidad
Asesor de seguridad asignado
El Asesor de Seguridad revisa el plan del producto, hace recomendaciones, puede establecer requisitos adicionales
Mandar el uso de un sistema de seguimiento de errores / asignación de trabajo
Defina y documente las barras de errores de seguridad y privacidad.

La fase de requisitos de la SDL incluye el inicio del proyecto, cuando considera la seguridad y la privacidad a nivel básico, y un análisis
de costos, cuando determina si los costos de desarrollo y soporte para mejorar la seguridad y la privacidad son consistentes con las
necesidades del negocio.

Asignar un asesor de seguridad / privacidad (Diapositiva 9)

Autoridad para aceptar o rechazar planes
PYMES ajenas al equipo del proyecto.

Si el proyecto está sujeto a las políticas de SDL, se le debe asignar un asesor de seguridad que sirve como punto de contacto para su
Revisión de seguridad final (FSR). Es de interés para el equipo del proyecto registrarse con prontitud y establecer los requisitos de
seguridad por los cuales serán responsables. También se le harán algunas preguntas técnicas al equipo como parte de una evaluación
de riesgos de seguridad para ayudar al asesor de seguridad a identificar posibles riesgos de seguridad. (Ver Análisis de costos en este
documento).

Identifique al asesor de privacidad que servirá como el primer punto de contacto de su equipo para obtener asistencia de privacidad y
recursos adicionales.

Combinación de roles consultivos. La función de asesor de seguridad puede combinarse con la función de asesor de privacidad si se
puede identificar a una persona con las habilidades y experiencia adecuadas.

Definir barra de errores (Diapositiva 10)

Defina y documente una barra de errores para la privacidad y seguridad.
Asegúrese de que se pueda consultar en cualquier momento una base de datos de errores para todos los problemas de seguridad
(TFS)
Phase1: http://msdn.microsoft.com/en-us/library/cc307412.aspx

Defina y documente la barra de errores de seguridad de un proyecto. Este conjunto de criterios establece un nivel mínimo de calidad.
Definirlo al inicio de un proyecto mejora la comprensión de los riesgos asociados con los problemas de seguridad y permite a los
equipos identificar y corregir errores de seguridad durante el desarrollo. El equipo del proyecto debe negociar una barra de errores
aprobada por el asesor de seguridad con aclaraciones específicas del proyecto y (según corresponda) requisitos de seguridad más
estrictos especificados por el asesor de seguridad. Sin embargo, la barra de errores nunca debe estar relajada, incluso cuando se
acerca la fecha de lanzamiento de un proyecto. Los ejemplos de la barra de errores se pueden encontrar en el Apéndice M: Barra de
errores de privacidad de SDL y en el Apéndice N: Barra de errores de seguridad de SDL.

Barra de errores de privacidad (muestra): http://msdn.microsoft.com/en-us/library/cc307403.aspx

Barra de errores de seguridad (muestra): http://msdn.microsoft.com/en-us/library/cc307404.aspx

Asegúrese de que las herramientas de informe de errores puedan realizar un seguimiento de los errores de seguridad y que se pueda
consultar dinámicamente una base de datos para todos los errores de seguridad en cualquier momento. El propósito de esta consulta
es examinar errores de seguridad no fijados en el FSR. El sistema de seguimiento de errores del proyecto debe adaptarse al valor de
clasificación de la barra de errores registrado con cada error.

Iniciar un plan de seguridad (Diapositiva 11)

Identificar los requisitos de tiempo y recursos para
Entrenamiento del equipo
Modelado de amenazas
Impulsos de seguridad y pruebas de penetración.
Revisión final de seguridad

Es útil crear un documento de plan de seguridad durante la fase de diseño, para delinear los procesos y elementos de trabajo que su
equipo seguirá para integrar la seguridad en su proceso de desarrollo. El plan de seguridad debe identificar el tiempo y los requisitos
de recursos que el Ciclo de vida del desarrollo de la seguridad prescribe para actividades individuales. Estos requisitos deben incluir:
Entrenamiento del equipo
Modelado de amenazas
Empuje de seguridad
Revisión final de seguridad (FSR)
El plan de seguridad debe reflejar la perspectiva general de un equipo de desarrollo sobre los objetivos, desafíos y planes de seguridad.
Los planes de seguridad pueden cambiar, pero articular uno anticipadamente ayuda a garantizar que no se pasen por alto los requisitos
y evitar sorpresas de última hora. Se incluye un plan de seguridad de muestra en el Apéndice O. http://msdn.microsoft.com/en-
us/library/cc307405.aspx

Evaluación de riesgos de seguridad y privacidad (diapositiva 12)

¿Qué partes requieren un modelo de amenaza?
¿Qué partes requieren revisiones de diseño de seguridad?
¿Qué porciones requieren pruebas de penetración?
¿Cuál es el alcance específico de los requisitos de prueba de fuzz?
¿Otras preocupaciones o tipos de pruebas?
¿Qué es la Clasificación de Impacto a la Privacidad?

Las evaluaciones de riesgos de seguridad (SRA) y las evaluaciones de riesgos de privacidad (PRA) son procesos obligatorios que
identifican aspectos funcionales del software que requieren una revisión profunda. Tales evaluaciones deben incluir la siguiente
información:
(Seguridad) ¿Qué partes del proyecto requerirán modelos de amenaza antes del lanzamiento?
(Seguridad) ¿Qué partes del proyecto requerirán revisiones de diseño de seguridad antes del lanzamiento?
(Seguridad) ¿Qué partes del proyecto (si corresponde) requerirán pruebas de penetración por parte de un grupo de mutuo acuerdo
que sea externo al equipo del proyecto?
(Seguridad) ¿Hay algún requisito de análisis o prueba adicional que el asesor de seguridad considere necesario para mitigar los riesgos
de seguridad?
(Seguridad) ¿Cuál es el alcance específico de los requisitos de prueba fuzz?
(Privacidad) ¿Qué es la Clasificación de Impacto a la Privacidad? La respuesta a esta pregunta se basa en las siguientes pautas:
P1 Alto Riesgo de Privacidad. La característica, el producto o el servicio almacena o transfiere la PII, cambia la configuración o las
asociaciones de tipo de archivo, o instala software.
P2 Riesgo de privacidad moderado. El único comportamiento que afecta a la privacidad en la característica, producto o servicio es una
transferencia de datos anónima, iniciada por el usuario y por única vez (por ejemplo, el usuario hace clic en un enlace y el software
sale a un sitio web).
P3 bajo riesgo de privacidad. No existe ningún comportamiento dentro de la característica, producto o servicio que afecte la privacidad.
No se transfieren datos anónimos ni personales, no se almacena ninguna PII en la máquina, no se modifica la configuración en nombre
del usuario y no se instala ningún software.

Determine la Calificación de Impacto a la Privacidad (PIR) a través de una evaluación inicial (Diapositiva 13)
P1 alto riesgo de privacidad
P2 Medio riesgo de privacidad
P3 bajo riesgo de privacidad

Requisitos de privacidad
Complete la evaluación inicial del Apéndice C: Cuestionario de privacidad de SDL. Una evaluación inicial es una forma rápida de
determinar la Calificación de Impacto en la Privacidad de un proyecto y estimar cuánto trabajo es necesario para cumplir con las Pautas
de Privacidad de Microsoft para el Desarrollo de Productos y Servicios de Software.
La Clasificación de Impacto en la Privacidad (P1, P2 o P3) mide la sensibilidad de los datos que su software procesará desde un punto
de vista de privacidad. Puede encontrar más información sobre las Clasificaciones de Impacto en la Privacidad en el Capítulo 8 del Ciclo
de Vida del Desarrollo de la Seguridad. Las definiciones generales de impacto en la privacidad se definen a continuación:
P1 - Alto riesgo de privacidad: la característica, el producto o el servicio almacena o transfiere información de identificación personal
(PII) o informes de errores; supervisa al usuario con una transferencia continua de datos anónimos; cambia la configuración o
asociaciones de tipo de archivo; o instala software.
P2 - Riesgo de privacidad moderado: el único comportamiento que afecta a la privacidad en la característica, producto o servicio, es
una transferencia de datos anónima iniciada por el usuario por única vez (por ejemplo, el usuario hace clic en un enlace y sale a un
sitio web).
P3 - Bajo riesgo de privacidad: no existen comportamientos dentro de la característica, el producto o el servicio que afecten la
privacidad. No se transfieren datos anónimos ni personales, no se almacena ninguna PII en la máquina, no se modifica la configuración
en nombre del usuario y no se instala ningún software.
Los equipos de productos deben completar solo el trabajo que sea relevante para su Calificación de Impacto de Privacidad. Complete la
evaluación inicial al principio de la fase de planificación / requisitos del producto, antes de escribir las especificaciones detalladas o el
código.

Recomendaciones de privacidad
Si su Calificación de impacto en la privacidad es P1 o P2, comprenda sus obligaciones e intente reducir su riesgo. El conocimiento
temprano de todos los pasos necesarios para implementar un proyecto con un alto riesgo de privacidad podría ayudarlo a decidir si los
costos valen el valor empresarial ganado. Revise la guía en Comprenda sus obligaciones e intente reducir su riesgo del Apéndice C:
Cuestionario de privacidad de SDL. Si su Calificación de impacto en la privacidad es P1, programe una “verificación de validez” con el
experto en privacidad de su organización. Esta persona debe poder guiarlo a través de la implementación de un proyecto de alto riesgo
y podría tener otras ideas para ayudarlo a reducir su riesgo.

Phase Two: Design - Fase dos: diseño – Diapositiva 14

Defina y documente la arquitectura de seguridad, identifique los componentes críticos de seguridad.
Identificar técnicas de diseño (capas, código administrado, privilegios mínimos, minimización de la superficie de ataque)
Documentar la superficie de ataque y el límite a través de la configuración predeterminada.
Defina los criterios de envío de seguridad suplementarios debido a problemas de productos únicos
Pruebas de scripting entre sitios
La desaprobación de crypto débil
Modelado de amenazas
Revisión sistemática de las características y la arquitectura del producto desde un punto de vista de seguridad
Identificar amenazas y mitigaciones.
Requisitos específicos de los servicios en línea.

Diapositiva 15 - Phase Three: Implementation - Fase Tres: Implementación

Establezca, comunique y siga las prácticas recomendadas para desarrollar código seguro.
Especificación de herramientas de construcción aprobadas y opciones
Análisis estático (PREFix, / analyse (PREfast), FXCop)
APIs prohibidas
Uso de protecciones de “defensa en profundidad” del sistema operativo (NX, ASLR y HeapTermination)
Requisitos específicos de servicios en línea, por ejemplo. Creación de scripts entre sitios, inyección SQL, etc.
Considere otras recomendaciones, por ej. Lenguaje de anotación estándar (SAL)

La fase de implementación es cuando el usuario final de su software es lo más importante en su mente. Durante esta fase, creará la
documentación y las herramientas que el cliente utiliza para tomar decisiones informadas sobre cómo implementar su software de
forma segura. Con este fin, la fase de implementación es cuando establece las mejores prácticas de desarrollo para detectar y eliminar
los problemas de seguridad y privacidad al inicio del ciclo de desarrollo.

Diapositiva 16 Phase Four: Verification - Fase cuatro: verificación

Comenzó lo antes posible: se realizó después de la etapa de "código completo"
Iniciar la planificación de la respuesta de seguridad, incluidos los planes de respuesta para los informes de vulnerabilidad.
Re-evaluar la superficie de ataque
Fuzz testing: archivos, controles instalables y código de red
Llevar a cabo un "impulso de seguridad" (según sea necesario, cada vez más raro)
No sustituye el trabajo de seguridad realizado durante el desarrollo.
Revisión de código
Pruebas de penetración y otras pruebas de seguridad.
Revisar diseño y arquitectura ante nuevas amenazas.
Requisitos específicos de los servicios en línea.
Durante la fase de verificación, se asegura de que su código cumpla con los principios de seguridad y privacidad que estableció en las
fases anteriores. Esto se realiza a través de pruebas de seguridad y privacidad, y un impulso de seguridad, que es un enfoque de todo
el equipo en las actualizaciones de modelos de amenazas, revisión de códigos, pruebas y revisión y edición de documentación
exhaustiva. Una revisión de privacidad de la versión pública también se completa durante la fase de verificación.

Diapositiva 17 - Phase Five: Release - Fase cinco: Lanzamiento

Prepara tu software para el consumo público.
Planificación
Revisión de seguridad final y Revisión de privacidad
Lanzamiento a Fabricación / Lanzamiento a Web

La fase de lanzamiento es cuando prepara su software para el consumo público y, lo que es más importante, se prepara a sí mismo y a
su equipo para lo que sucede una vez que el software está en manos del usuario. Uno de los conceptos centrales en la fase de
lanzamiento es la planificación: trazar un plan de acción, en caso de que se descubran vulnerabilidades de seguridad o de privacidad
en su lanzamiento, y esto también se traslada al post-lanzamiento, en términos de ejecución de respuesta. Para este fin, se requiere
una Revisión de seguridad final y una revisión de privacidad antes del lanzamiento.

Diapositiva 18 Phase Five: Release – Planning / Fase cinco: Lanzamiento – Planificación

Cualquier software puede ser lanzado con problemas de seguridad desconocidos o problemas de privacidad, a pesar de los mejores
esfuerzos e intenciones. Incluso los programas que no tienen vulnerabilidades conocidas en el momento del lanzamiento pueden estar
sujetos a nuevas amenazas que pueden surgir y pueden requerir una acción. Del mismo modo, los defensores de la privacidad pueden
plantear problemas de privacidad después de su publicación. Debe prepararse antes del lanzamiento para responder a posibles
incidentes de seguridad y privacidad. Con una planificación adecuada, debería poder abordar muchos de los incidentes que podrían
ocurrir en el curso de las operaciones comerciales normales.
Su equipo debe estar preparado para una explotación de una vulnerabilidad de día cero, una para la cual no existe una actualización de
seguridad. Su equipo también debe estar preparado para responder a una emergencia de seguridad del software. Si crea un plan de
respuesta de emergencia antes del lanzamiento, ahorrará tiempo, dinero y frustración cuando se requiera una respuesta de
emergencia por razones de seguridad o de privacidad.

Requerimientos de seguridad
El equipo del proyecto debe proporcionar información de contacto para las personas que responden a incidentes de seguridad.
Normalmente, estas respuestas se manejan de manera diferente para los productos y servicios.
Proporcionar información sobre qué equipo de ingeniería sostenida (SE) existente ha aceptado ser responsable de la respuesta a
incidentes de seguridad para el proyecto. Si el producto no tiene un equipo SE identificado, debe proporcionar un plan de respuesta de
emergencia (ERP) y proporcionárselo al equipo de respuesta a incidentes. Este plan debe incluir información de contacto para tres a
cinco recursos de ingeniería, tres a cinco recursos de marketing y uno o dos recursos de administración que son los primeros puntos de
contacto cuando necesita movilizar a su equipo para un esfuerzo de respuesta. Alguien debe estar disponible las 24 horas del día, los
siete días de la semana, y los contactos deben comprender sus funciones y responsabilidades y poder ejecutarlas cuando sea
necesario.
Identifique a alguien que sea responsable del servicio de seguridad. Todo el código desarrollado fuera del equipo del proyecto
(componentes de terceros) debe enumerarse por nombre de archivo, versión y fuente (de dónde proviene).
Debe tener un proceso de respuesta de seguridad efectivo para el código de servicio que se ha heredado o reutilizado de otros
equipos. Si ese código tiene una vulnerabilidad, el equipo de lanzamiento puede tener que lanzar una actualización de seguridad,
aunque no haya desarrollado el código.
También debe tener un proceso de respuesta de seguridad efectivo para el código de servicio que ha sido licenciado por terceros en
forma de objeto o fuente. Para el código con licencia, también debe considerar los requisitos contractuales con respecto a qué parte
tiene derechos y obligaciones para realizar modificaciones, acuerdos de nivel de servicio (SLA) asociados y derechos de redistribución
para cualquier modificación de seguridad.

Cree un modelo de mantenimiento documentado que aborde la necesidad de lanzar parches inmediatos en respuesta a las
vulnerabilidades de seguridad y no depende completamente de los paquetes de servicios poco frecuentes.
Desarrolle una política consistente y comprensible para la respuesta de seguridad para los componentes que se lanzan fuera del
programa de lanzamiento regular del producto (fuera de banda) pero que se puede usar para actualizar o mejorar el software después
del lanzamiento. Por ejemplo, Windows debe planificar una respuesta a las vulnerabilidades de seguridad en un componente, como
DirectX, que se distribuye como parte del sistema operativo pero que también puede actualizarse independientemente del sistema
operativo, ya sea directamente por el usuario o por la instalación de otros Productos o componentes.
Desactive el seguimiento y la depuración en las aplicaciones ASP.NET antes de la implementación. Esto neutraliza las siguientes
vulnerabilidades de seguridad posibles:
Cuando el rastreo está habilitado para la página, cada navegador que lo solicita también obtiene la información de rastreo que contiene
datos confidenciales sobre el estado interno del servidor y el flujo de trabajo. Esta información podría ser sensible a la seguridad.
Cuando la depuración está habilitada para la página, los errores que ocurren en el servidor dan como resultado un conjunto completo
de datos de seguimiento de pila presentados al navegador. Estos datos pueden exponer información sensible a la seguridad sobre el
flujo de trabajo del servidor.

Requisitos de privacidad
Para los proyectos P1 y P2, identifique a la persona que será responsable de responder a todos los incidentes de privacidad que
puedan ocurrir. Agregue la dirección de correo electrónico de esta persona a la sección Respuesta al incidente del Cuestionario de
privacidad de SDL (Apéndice C). Si esta persona cambia de posición o abandona el equipo, identifique un nuevo contacto y actualice
todos los formularios del Cuestionario de privacidad de SDL para los cuales se incluyó a esa persona como el líder de respuesta a
incidentes de privacidad.
Identifique recursos adicionales de desarrollo y control de calidad en el equipo del proyecto para trabajar en problemas de respuesta a
incidentes de privacidad. El responsable de la respuesta a incidentes de privacidad es responsable de definir estos recursos en la
sección Respuesta a incidentes del Cuestionario de privacidad de SDL.
Después del lanzamiento, si ocurre un incidente de privacidad, debe estar preparado para seguir el Marco de respuesta de escalada de
privacidad de SDL (Apéndice K), que puede incluir evaluación de riesgos, diagnóstico detallado, planificación de acciones a corto y
largo plazo e implementación de planes de acción. Su respuesta puede incluir la creación de un parche, responder a consultas de los
medios de comunicación y comunicarse con contactos externos influyentes.

Diapositiva 19 - Phase Five: Release - Final Security Review / Fase cinco: Lanzamiento - Revisión final de seguridad
Revisión final de seguridad
Verifique que se cumplan los requisitos de SDL y que no haya vulnerabilidades de seguridad conocidas
Proporciona una visión independiente de la "preparación de la nave de seguridad"
Validar las excepciones de SDL en el proyecto.
Concepto clave: las tareas para esta fase se usan como un factor determinante para enviar o no, no se usan como una fase "general"
para el trabajo perdido en fases anteriores

A medida que se acerca el final de su proyecto de desarrollo de software, debe asegurarse de que el software sea lo suficientemente
seguro como para ser enviado. La Revisión de seguridad final (FSR) ayuda a determinar esto. El equipo de seguridad asignado al
proyecto debe realizar la FSR con la ayuda del equipo del producto para garantizar que el software cumpla con todos los requisitos de
SDL y cualquier otro requisito de seguridad adicional identificado por el equipo de seguridad (como pruebas de penetración o pruebas
de fuzz adicionales).
Una Revisión de seguridad final puede durar desde unos pocos días hasta seis semanas, dependiendo de la cantidad de problemas y la
capacidad del equipo para realizar los cambios necesarios.
Es importante programar el FSR con cuidado, es decir, debe permitir suficiente tiempo para abordar cualquier problema grave que se
pueda encontrar durante la revisión. También debe permitir suficiente tiempo para un análisis exhaustivo; el tiempo insuficiente podría
hacer que realice cambios significativos una vez que se complete el FSR.

El proceso de FSR
Defina una fecha de vencimiento para toda la información del proyecto que se requiere para iniciar el FSR. Para minimizar la posibilidad
de retrasos inesperados, planee realizar un FSR de cuatro a seis semanas antes de la publicación en la fabricación (RTM) o la
publicación en la web (RTW). Es posible que su equipo necesite revalidar decisiones específicas o cambiar el código para solucionar
problemas de seguridad. El equipo debe comprender que se debe realizar un trabajo de seguridad adicional durante el FSR.
La FSR no puede comenzar hasta que haya completado las revisiones de los hitos de seguridad requeridos durante el desarrollo. Los
hitos incluyen revisiones de errores en profundidad, revisiones de modelos de amenazas y la ejecución de todas las herramientas
obligatorias de SDL.
Volver a reunir a los equipos de liderazgo de desarrollo y seguridad para revisar y responder a las preguntas planteadas durante el
proceso de FSR.

Revise los modelos de amenazas. El asesor de seguridad debe revisar los modelos de amenazas para garantizar que se identifiquen y
mitiguen todas las amenazas y vulnerabilidades conocidas. Tener modelos de amenazas completos y actualizados al momento de la
revisión.
Revise los problemas de seguridad que se aplazaron o rechazaron para la versión actual. La revisión debe garantizar que se cumpla con
un estándar de seguridad mínimo y consistente durante todo el ciclo de desarrollo. Los equipos ya deben haber revisado todos los
problemas de seguridad según los criterios establecidos para la liberación. Si la versión no tiene una barra de errores de seguridad
definida, su equipo puede usar la barra de errores de seguridad estándar de SDL.
Validar los resultados de todas las herramientas de seguridad. Debería haber ejecutado estas herramientas antes del FSR, pero un
asesor de seguridad podría recomendar que también ejecute otras herramientas. Si los resultados de la herramienta son inexactos o
inaceptables, es posible que deba volver a ejecutar algunas herramientas.

Asegúrese de haber hecho todo lo posible por eliminar las vulnerabilidades que cumplen con los criterios de gravedad de su
organización para que no haya vulnerabilidades conocidas. En última instancia, el objetivo de SDL es eliminar las vulnerabilidades de
seguridad de los productos y servicios. Ninguna versión de software puede pasar una FSR con vulnerabilidades conocidas que se
considerarían críticas, importantes, moderadas o bajas.
Enviar solicitudes de excepción a un asesor de seguridad para su revisión. Si su equipo no puede cumplir con un requisito específico de
SDL, debe solicitar una excepción. Normalmente, dicha solicitud se realiza con bastante antelación a la FSR. Un asesor de seguridad
revisa estas solicitudes y, si el riesgo de seguridad general es tolerable, podría optar por otorgar la excepción. Si el riesgo de seguridad
no es aceptable, el asesor de seguridad rechazará la solicitud de excepción. Es mejor abordar todas las solicitudes de excepción lo
antes posible en la fase de desarrollo del proyecto.

Posibles resultados FSR

Los posibles resultados de un FSR incluyen:
Aprobado FSR. Si todos los problemas identificados durante el FSR se corrigen antes de RTM / RTW, el asesor de seguridad debe
certificar que el proyecto ha cumplido con éxito todos los requisitos de SDL.
Aprobado FSR (con excepciones). Si todos los problemas identificados durante el FSR se corrigen antes de que RTM / RTW o el asesor
de seguridad y el equipo puedan alcanzar un compromiso aceptable sobre los requisitos de SDL que el equipo del proyecto no pudo
resolver, el asesor de seguridad debe identificar las excepciones y certificar que todos los demás aspectos del proyecto han cumplido
con éxito todos los requisitos de SDL.
Todas las excepciones y problemas de seguridad que no se hayan abordado en la versión actual deben registrarse y, a continuación,
deben solucionarse y corregirse en la próxima versión.

Escalamiento FSR. Si un equipo no cumple con todos los requisitos de SDL, y el asesor de seguridad y el equipo del producto no
pueden alcanzar un compromiso aceptable, el asesor de seguridad no puede aprobar el proyecto y el proyecto no puede ser liberado.
Los equipos deben corregir cualquier requerimiento de SDL que puedan o escalar a una administración superior para tomar una
decisión.
Las escalas ocurren cuando el asesor de seguridad determina que un equipo no puede cumplir con los requisitos definidos o está en
violación de un requisito de SDL. Normalmente, el equipo tiene una justificación comercial que les impide cumplir con el requisito. En
tales casos, el asesor de seguridad y el equipo deben trabajar juntos para redactar un informe de escalado consolidado que resuma el
problema, incluida una descripción del riesgo de seguridad o privacidad y la razón detrás de la escalada. Esta información normalmente
se proporciona al ejecutivo de la unidad de negocios y al ejecutivo con responsabilidad corporativa de seguridad y privacidad, para
ayudar a la toma de decisiones.
Si un equipo no sigue los procedimientos correctos de FSR, ya sea por un error de omisión o por negligencia intencional, el resultado
es un fallo inmediato de FSR. Ejemplos incluyen:
Errores de omisión, como no documentar correctamente toda la información requerida.
Reclamaciones engañosas y negligencia voluntaria, que incluyen:
Reclamaciones de "No sujeto a SDL" contrariamente a la evidencia.
Las reclamaciones de "FSR pasan" en contra de la evidencia, y el software RTM / RTW sin la firma apropiada.
Un incidente de este tipo puede tener consecuencias muy graves posteriormente, y siempre se envía inmediatamente al personal
ejecutivo del equipo del proyecto y al ejecutivo a cargo de la seguridad y la privacidad.

Requerimientos de seguridad
El equipo del proyecto debe proporcionar toda la información requerida antes de la fecha de inicio programada del FSR. De lo
contrario, puede demorar la finalización de la FSR. Si el programa se desliza significativamente antes de que comience la FSR,
comuníquese con el asesor de seguridad asignado para reprogramar.
Una vez finalizado el FSR, el asesor de seguridad firma el proyecto tal como está o proporciona una lista de los cambios necesarios.
Para los servicios en línea y / o aplicaciones LOB, se requiere que los servicios de lanzamiento de proyectos tengan un puntaje de
seguridad de B o superior para pasar con éxito el FSR. Tanto las operaciones como los grupos de productos son responsables del
cumplimiento. La seguridad de un producto se gestiona en muchos niveles. Las vulnerabilidades, ya sea en el código o en el nivel del
host, ponen en riesgo todo el producto (y posiblemente el entorno).

Requisitos de privacidad
Repita la revisión de privacidad para cualquier problema abierto que se haya identificado en la revisión de privacidad previa al
lanzamiento o para los cambios sustanciales realizados en el producto después de la revisión de privacidad previa al lanzamiento. Los
cambios materiales incluyen la modificación del estilo de consentimiento, la revisión sustancial del lenguaje de un aviso, la recopilación
de diferentes tipos de datos o la presentación de nuevos comportamientos. Si no se realizaron cambios materiales, no se requieren
revisiones o aprobaciones adicionales.
Una vez finalizada la revisión de la privacidad, su asesor de privacidad firma el producto tal como está o proporciona una lista de los
cambios necesarios.

Recomendaciones de seguridad
Asegúrese de que el equipo del producto esté evaluando constantemente la gravedad de las vulnerabilidades de seguridad con
respecto al estándar que se utiliza durante el impulso de seguridad y FSR. De lo contrario, se podrían reactivar una gran cantidad de
errores de seguridad durante la FSR.
Diapositiva 20 - Phase Five: Release - Final Security Review / Fase cinco: Lanzamiento - Revisión final de seguridad
Posibles resultados FSR
Aprobado FSR
Aprobado FSR (con excepciones)
Escalada FSR

A medida que se acerca el final de su proyecto de desarrollo de software, debe asegurarse de que el software sea lo suficientemente
seguro como para ser enviado. La Revisión de seguridad final (FSR) ayuda a determinar esto. El equipo de seguridad asignado al
proyecto debe realizar la FSR con la ayuda del equipo del producto para garantizar que el software cumpla con todos los requisitos de
SDL y cualquier otro requisito de seguridad adicional identificado por el equipo de seguridad (como pruebas de penetración o pruebas
de fuzz adicionales).
Una Revisión de seguridad final puede durar desde unos pocos días hasta seis semanas, dependiendo de la cantidad de problemas y la
capacidad del equipo para realizar los cambios necesarios.
Es importante programar el FSR con cuidado, es decir, debe permitir suficiente tiempo para abordar cualquier problema grave que se
pueda encontrar durante la revisión. También debe permitir suficiente tiempo para un análisis exhaustivo; el tiempo insuficiente podría
hacer que realice cambios significativos una vez que se complete el FSR.

El proceso de FSR
Defina una fecha de vencimiento para toda la información del proyecto que se requiere para iniciar el FSR. Para minimizar la posibilidad
de retrasos inesperados, planee realizar un FSR de cuatro a seis semanas antes de la publicación en la fabricación (RTM) o la
publicación en la web (RTW). Es posible que su equipo necesite revalidar decisiones específicas o cambiar el código para solucionar
problemas de seguridad. El equipo debe comprender que se debe realizar un trabajo de seguridad adicional durante el FSR.
La FSR no puede comenzar hasta que haya completado las revisiones de los hitos de seguridad requeridos durante el desarrollo. Los
hitos incluyen revisiones de errores en profundidad, revisiones de modelos de amenazas y la ejecución de todas las herramientas
obligatorias de SDL.
Volver a reunir a los equipos de liderazgo de desarrollo y seguridad para revisar y responder a las preguntas planteadas durante el
proceso de FSR.

Revise los modelos de amenazas. El asesor de seguridad debe revisar los modelos de amenazas para garantizar que se identifiquen y
mitiguen todas las amenazas y vulnerabilidades conocidas. Tener modelos de amenazas completos y actualizados al momento de la
revisión.
Revise los problemas de seguridad que se aplazaron o rechazaron para la versión actual. La revisión debe garantizar que se cumpla con
un estándar de seguridad mínimo y consistente durante todo el ciclo de desarrollo. Los equipos ya deben haber revisado todos los
problemas de seguridad según los criterios establecidos para la liberación. Si la versión no tiene una barra de errores de seguridad
definida, su equipo puede usar la barra de errores de seguridad estándar de SDL.
Validar los resultados de todas las herramientas de seguridad. Debería haber ejecutado estas herramientas antes del FSR, pero un
asesor de seguridad podría recomendar que también ejecute otras herramientas. Si los resultados de la herramienta son inexactos o
inaceptables, es posible que deba volver a ejecutar algunas herramientas.

Asegúrese de haber hecho todo lo posible por eliminar las vulnerabilidades que cumplen con los criterios de gravedad de su
organización para que no haya vulnerabilidades conocidas. En última instancia, el objetivo de SDL es eliminar las vulnerabilidades de
seguridad de los productos y servicios. Ninguna versión de software puede pasar una FSR con vulnerabilidades conocidas que se
considerarían críticas, importantes, moderadas o bajas.
Enviar solicitudes de excepción a un asesor de seguridad para su revisión. Si su equipo no puede cumplir con un requisito específico de
SDL, debe solicitar una excepción. Normalmente, dicha solicitud se realiza con bastante antelación a la FSR. Un asesor de seguridad
revisa estas solicitudes y, si el riesgo de seguridad general es tolerable, podría optar por otorgar la excepción. Si el riesgo de seguridad
no es aceptable, el asesor de seguridad rechazará la solicitud de excepción. Es mejor abordar todas las solicitudes de excepción lo
antes posible en la fase de desarrollo del proyecto.

Posibles resultados FSR

Los posibles resultados de un FSR incluyen:
Aprobado FSR. Si todos los problemas identificados durante el FSR se corrigen antes de RTM / RTW, el asesor de seguridad debe
certificar que el proyecto ha cumplido con éxito todos los requisitos de SDL.
Aprobado FSR (con excepciones). Si todos los problemas identificados durante el FSR se corrigen antes de que RTM / RTW o el asesor
de seguridad y el equipo puedan alcanzar un compromiso aceptable sobre los requisitos de SDL que el equipo del proyecto no pudo
resolver, el asesor de seguridad debe identificar las excepciones y certificar que todos los demás aspectos del proyecto han cumplido
con éxito todos los requisitos de SDL.
Todas las excepciones y problemas de seguridad que no se hayan abordado en la versión actual deben registrarse y, a continuación,
deben solucionarse y corregirse en la próxima versión.
Escalamiento FSR. Si un equipo no cumple con todos los requisitos de SDL, y el asesor de seguridad y el equipo del producto no
pueden alcanzar un compromiso aceptable, el asesor de seguridad no puede aprobar el proyecto y el proyecto no puede ser liberado.
Los equipos deben corregir cualquier requerimiento de SDL que puedan o escalar a una administración superior para tomar una
decisión.
Las escalas ocurren cuando el asesor de seguridad determina que un equipo no puede cumplir con los requisitos definidos o está en
violación de un requisito de SDL. Normalmente, el equipo tiene una justificación comercial que les impide cumplir con el requisito. En
tales casos, el asesor de seguridad y el equipo deben trabajar juntos para redactar un informe de escalado consolidado que resuma el
problema, incluida una descripción del riesgo de seguridad o privacidad y la razón detrás de la escalada. Esta información normalmente
se proporciona al ejecutivo de la unidad de negocios y al ejecutivo con responsabilidad corporativa de seguridad y privacidad, para
ayudar a la toma de decisiones.

Si un equipo no sigue los procedimientos correctos de FSR, ya sea por un error de omisión o por negligencia intencional, el resultado
es un fallo inmediato de FSR. Ejemplos incluyen:
Errores de omisión, como no documentar correctamente toda la información requerida.
Reclamaciones engañosas y negligencia voluntaria, que incluyen:
Reclamaciones de "No sujeto a SDL" contrariamente a la evidencia.
Las reclamaciones de "FSR pasan" en contra de la evidencia, y el software RTM / RTW sin la firma apropiada.
Un incidente de este tipo puede tener consecuencias muy graves posteriormente, y siempre se envía inmediatamente al personal
ejecutivo del equipo del proyecto y al ejecutivo a cargo de la seguridad y la privacidad.

Requerimientos de seguridad
El equipo del proyecto debe proporcionar toda la información requerida antes de la fecha de inicio programada del FSR. De lo
contrario, puede demorar la finalización de la FSR. Si el programa se desliza significativamente antes de que comience la FSR,
comuníquese con el asesor de seguridad asignado para reprogramar.
Una vez finalizado el FSR, el asesor de seguridad firma el proyecto tal como está o proporciona una lista de los cambios necesarios.
Para los servicios en línea y / o aplicaciones LOB, se requiere que los servicios de lanzamiento de proyectos tengan un puntaje de
seguridad de B o superior para pasar con éxito el FSR. Tanto las operaciones como los grupos de productos son responsables del
cumplimiento. La seguridad de un producto se gestiona en muchos niveles. Las vulnerabilidades, ya sea en el código o en el nivel del
host, ponen en riesgo todo el producto (y posiblemente el entorno).

Requisitos de privacidad
Repita la revisión de privacidad para cualquier problema abierto que se haya identificado en la revisión de privacidad previa al
lanzamiento o para los cambios sustanciales realizados en el producto después de la revisión de privacidad previa al lanzamiento. Los
cambios materiales incluyen la modificación del estilo de consentimiento, la revisión sustancial del lenguaje de un aviso, la recopilación
de diferentes tipos de datos o la presentación de nuevos comportamientos. Si no se realizaron cambios materiales, no se requieren
revisiones o aprobaciones adicionales.
Una vez finalizada la revisión de la privacidad, su asesor de privacidad firma el producto tal como está o proporciona una lista de los
cambios necesarios.

Diapositiva 21 Phase Five: Release - Release to Manufacturing/Release to Web - Phase Five: Release - Release to
Manufacturing / Release to Web
RTM o RTW está condicionado a la finalización del ciclo de vida del desarrollo de la seguridad
El asesor de seguridad debe certificar que su equipo cumple con los requisitos de seguridad
El asesor de privacidad debe certificar que su equipo ha cumplido con los requisitos de privacidad (P1)

La versión del software para la fabricación (RTM) o la versión para la web (RTW) está condicionada a la finalización del proceso del
ciclo de vida del desarrollo de la seguridad tal como se define en este documento. El asesor de seguridad asignado al lanzamiento debe
certificar que su equipo ha cumplido con los requisitos de seguridad. De manera similar, para todos los productos que tienen al menos
un componente con una calificación de impacto de privacidad de P1, su asesor de privacidad debe certificar que su equipo ha cumplido
con los requisitos de privacidad antes de poder enviar el software.

Requerimientos de seguridad
Para facilitar la depuración de los informes de vulnerabilidad de seguridad y para ayudar a los equipos de herramientas a investigar los
casos en los que las herramientas automatizadas no pudieron identificar las vulnerabilidades de seguridad, todos los equipos de
productos deben enviar símbolos para todos los productos lanzados públicamente como parte del proceso de publicación. Este requisito
es necesario solo para los binarios RTM / RTW y cualquier binario posterior al lanzamiento que se publique públicamente a los usuarios
(como paquetes de servicio o actualizaciones, entre otros).
Diseñe e implemente un proceso de aprobación para garantizar la seguridad y el cumplimiento de otras políticas antes de realizar el
envío. Este proceso debe incluir el reconocimiento explícito de que el producto pasó con éxito el FSR y fue aprobado para su
lanzamiento.
Requisitos de privacidad
Diseñe e implemente un proceso de aprobación para garantizar la privacidad y el cumplimiento de otras políticas antes de realizar el
envío. Este proceso debe incluir el reconocimiento explícito de que el producto pasó con éxito el FSR y fue aprobado para su
lanzamiento.

Requisitos post-SDL: Respuesta – Diapositiva 22

“Planifica el trabajo, trabaja el plan…”
Ejecución en las tareas de respuesta descritas durante las fases de lanzamiento y planificación de Security Response
Después de lanzar un programa de software, el equipo de desarrollo del producto debe estar disponible para responder a cualquier
posible vulnerabilidad de seguridad o problemas de privacidad que justifiquen una respuesta. Además, desarrolle un plan de respuesta
que incluya preparativos para posibles problemas posteriores al lanzamiento.

Beneficios de SDL – Diapositiva 23

https://www.microsoft.com/en-us/SDL/about/benefits.aspx

Implementación exitosa de SDL – Diapositiva 24

El apoyo ejecutivo es clave.
La capacitación en seguridad es clave, así como un requisito fundamental de SDL.
Entienda su organización y su proceso de desarrollo de software
Empieza pequeño. Crecer orgánicamente, proyecto por proyecto.
Base sus criterios en los resultados, no en el proceso
Busque ayuda externa; Utilice expertos para aumentar sus capacidades
Llegar a empresas similares con objetivos similares. Aprende de ellos. Evalúa tus esfuerzos junto a los suyos.

Entender el nivel de madurez de su organización – Diapositiva 25

¿Cómo es tu proceso de desarrollo?
¿Cómo se asignan el tiempo y los recursos?
Comprar a los gerentes de proyectos, desarrolladores y probadores
Apoyo de la gerencia
Conoce tu nivel de madurez SDL

El contenido de la diapositiva es bastante explicativo y la idea es que necesita comprender cómo su organización maneja la seguridad
actualmente (donde se encuentra). Si hay puntos débiles, mejoras y / o no estás donde quieres estar (eres más reactivo que proactivo)
de lo que necesitas hacer. Su organización puede realizar la evaluación de SDL o puede pedirle ayuda a Microsoft con eso.
Para más información sobre esta evaluación:
Ver el modelo de optimización de Microsoft SDL
https://www.microsoft.com/en-us/download/details.aspx?id=2830
SDL en procesos de desarrollo ágil – Diapositiva 26