Prácticas de Microsoft SDL

Prácticas de Microsoft SDL

Práctica #1 - Proporcionar Capacitación
La seguridad es el trabajo de todos. Los desarrolladores, ingenieros de servicio y gerentes de
programas y productos deben comprender los conceptos básicos de seguridad y saber
cómo incorporar la seguridad en software y servicios para hacer que los productos sean más
seguros, al mismo tiempo que abordan las necesidades empresariales y ofrecen valor para el
usuario.

La formación eficaz complementará y reaplicará las políticas de seguridad, las prácticas, los
estándares y los requisitos de seguridad del software de SDL, y se guiará por conocimientos
derivados de datos o de las nuevas capacidades técnicas disponibles.

Aunque la seguridad es el trabajo de todos, es importante recordar que no todo el mundo

necesita ser un experto en seguridad ni esforzarse por convertirse en un probador de
penetración competente. Sin embargo, asegurar que todos entiendan la perspectiva del
atacante, sus objetivos y el arte de lo posible ayudará a captar la atención de todos y elevar
la barra de conocimiento colectivo.

Práctica #2 - Definir requisitos de seguridad

La necesidad de considerar la seguridad y la privacidad es un aspecto fundamental del
desarrollo de aplicaciones y sistemas altamente seguros e independientemente de la
metodología de desarrollo que se utilice, los requisitos de seguridad deben actualizarse
continuamente para reflejar los cambios en la funcionalidad y cambios en el panorama de
amenazas. Obviamente, el momento óptimo para definir los requisitos de seguridad es
durante las etapas iniciales de diseño y planificación, ya que esto permite a los equipos de
desarrollo integrar la seguridad de maneras que minimicen la interrupción. Los factores que
influyen en los requisitos de seguridad incluyen (pero no se limitan a) los requisitos legales y de
la industria, las normas internas y las prácticas de codificación, la revisión de incidentes
anteriores y las amenazas conocidas. A estos requisitos se les debe realizar un seguimiento a
través de un sistema de seguimiento de trabajo a través de la telemetría derivada de la
canalización de ingeniería.

Enlaces útiles:
Azure DevOps / Azure Boards

Práctica #3- Definir métricas e informes de cumplimiento

Es esencial definir los niveles mínimos aceptables de calidad de seguridad y hacer que los
equipos de ingeniería sean responsables de cumplir con esos criterios. Definir estos primeros
ayuda a un equipo a comprender los riesgos asociados con los problemas de seguridad,
identificar y corregir defectos de seguridad durante el desarrollo y aplicar los estándares a lo
largo de todo el proyecto. Establecer una barra de errores significativa implica definir
claramente los umbrales de gravedad de las vulnerabilidades de seguridad (por ejemplo,
todas las vulnerabilidades conocidas descubiertas con una clasificación de gravedad
"crítica" o "importante" deben corregirse con un marco de tiempo especificado) y nunca
relajarse una vez que se ha establecido.
 Prácticas de Microsoft SDL
Para realizar un seguimiento de los indicadores clave de rendimiento (KPI) y garantizar que se
completen las tareas de seguridad, los mecanismos de seguimiento de errores y/o de
seguimiento de trabajo utilizados por una organización (como VSTS “Visual Studio Team
Services”) deben permitir que los defectos de seguridad y los elementos de trabajo de
seguridad se etiqueten claramente como seguridad y se marquen con su gravedad de
seguridad adecuada. Esto permite un seguimiento preciso y la generación de informes del
trabajo de seguridad.

Enlaces útiles:
Ejemplo de barra de errores de privacidad de SDL
Agregar o modificar un campo para realizar un seguimiento de los requisitos de datos en
VSops
Agregar una barra de errores de seguridada Microsoft Team Foundation Server 2010
Ejemplo de barra de errores de seguridad de SDL

Práctica #4 - Realizar modelado de amenazas

El modelado de amenazas debe utilizarse en entornos en los que exista un riesgo significativo
para la seguridad. El modelado de amenazas se puede aplicar a nivel de componente,
aplicación o sistema. Es una práctica que permite a los equipos de desarrollo considerar,
documentar y discutir las implicaciones de seguridad de los diseños en el contexto de su
entorno operativo planificado y de una manera estructurada.

La aplicación de un enfoque estructurado a escenarios de amenazas ayuda a un equipo a

identificar de forma más eficaz y menos costosa las vulnerabilidades de seguridad,
determinar los riesgos de esas amenazas y, a continuación, realizar selecciones de
características de seguridad y establecer mitigaciones adecuadas.

Enlaces útiles:
Modelado de amenazas

Práctica #5- Establecer requisitos de diseño

El SDL suele considerarse como actividades de garantía que ayudan a los ingenieros a
implementar "características seguras", ya que las características están bien diseñadas con
respecto a la seguridad. Para lograr esto, los ingenieros normalmente se basarán en
características de seguridad, como criptografía, autenticación, registro y otros. En muchos
casos, la selección o implementación de características de seguridad ha demostrado ser tan
complicada que es probable que las opciones de diseño o implementación den lugar a
vulnerabilidades. Por lo tanto, es crucial que estos se apliquen de manera coherente y con
una comprensión coherente de la protección que proporcionan.

Práctica #6- Definir y usar estándares de criptografía

Con el auge de la computación móvil y en la nube, es de vital importancia garantizar que
todos los datos, incluida la información sensible a la seguridad y los datos de gestión y
control, estén protegidos contra la divulgación o alteración no deseada según la transmisión
o el almacenamiento. El cifrado se utiliza normalmente para lograr esto. Tomar una elección
incorrecta en el uso de cualquier aspecto de la criptografía puede ser catastrófico, y es
mejor desarrollar estándares de cifrado claros que proporcionen detalles sobre cada
 Prácticas de Microsoft SDL
elemento de la implementación de cifrado. Esto debe dejarse en servicio de expertos. Una
buena regla general es usar solo bibliotecas de cifrado investigadas por la industria y
asegurarse de que se implementan de una manera que permita reemplazarlas fácilmente si
es necesario.

Enlaces útiles:
Recomendaciones criptográficas de Sdl de Microsoft

Práctica #7- Administrar el riesgo de seguridad del uso de

componentes de terceros
Hoy en día, la gran mayoría de los proyectos de software se construyen utilizando
componentes de terceros (tanto comerciales como de código abierto). Al seleccionar
componentes de terceros para usar, es importante comprender el impacto que una
vulnerabilidad de seguridad en ellos podría tener a la seguridad del sistema más grande en
el que están integrados. Tener un inventario preciso de componentes de terceros y un plan
para responder cuando se descubren nuevas vulnerabilidades ayudará mucho a mitigar
este riesgo, pero se debe considerar una validación adicional, dependiendo del apetito de
riesgo de su organización, el tipo de componente utilizado y el impacto potencial de una
vulnerabilidad de seguridad.

Enlaces útiles:
Gestión de riesgos de seguridad inherentes al uso de componentes de terceros
Gestión de riesgos de seguridad inherentes al uso de software de código abierto

Práctica #8- Usar herramientas aprobadas

Defina y publique una lista de herramientas aprobadas y sus comprobaciones de seguridad
asociadas, como las opciones y advertencias del compilador/vinculador. Los ingenieros
deben esforzarse por utilizar la versión más reciente de las herramientas aprobadas, como las
versiones del compilador, y aprovechar las nuevas funciones y protecciones de análisis de
seguridad.

Enlaces útiles:
Herramientas recomendadas, compiladores y opciones para x86, x64 y ARM(herramientas
heredadas)
SDL Tools

Práctica #9- Realizar pruebas de seguridad de análisis

estático (SAST)
El análisis del código fuente antes de la compilación proporciona un método altamente
escalable de revisión del código de seguridad y ayuda a garantizar que se sigan directivas
de codificación segura. SAST se integra normalmente en la canalización de confirmación
para identificar vulnerabilidades cada vez que se compila o empaqueta el software. Sin
embargo, algunas ofertas se integran en el entorno del desarrollador para detectar ciertos
defectos como la existencia de funciones inseguras u otras funciones prohibidas y
reemplazarlas con alternativas más seguras a medida que el desarrollador está codificando
activamente. No hay un solo tamaño que se adapte a todas las soluciones y los equipos de
 Prácticas de Microsoft SDL
desarrollo deben decidir la frecuencia óptima para realizar SAST y tal vez implementar
múltiples tácticas, para equilibrar la productividad con una cobertura de seguridad
adecuada.

Enlaces útiles:
Microsoft DevSkim
Reglas de Roslyn
Mercado de seguridad VSTS
Análisis de código para C/C++
BinSkim
FxCop (herramienta heredada)
Lista de herramientas para el análisis de código estático (Wikipedia)

Práctica #10- Realizar pruebas de seguridad de análisis

dinámico (DAST)
Realizar la verificación en tiempo de ejecución del software completamente compilado o
empaquetado comprueba la funcionalidad que solo es evidente cuando todos los
componentes están integrados y en ejecución. Esto se logra normalmente mediante una
herramienta o conjunto de ataques o herramientas precompilados que supervisan
específicamente el comportamiento de las aplicaciones en busca de daños en la memoria,
problemas de privilegios de usuario y otros problemas de seguridad críticos. Al igual que SAST,
no hay una solución única para todos y mientras que algunas herramientas, como las
herramientas de escaneo de aplicaciones web, se pueden integrar más fácilmente en la
canalización de integración continua / entrega continua, otras pruebas DAST como el
fuzzing requieren un enfoque diferente.

Enlaces útiles:
Mercado de seguridad VSTS
Pruebas de penetración automatizadas con fuzzing de caja blanca

Práctica #11- Realizar pruebas de penetración

Las pruebas de penetración son un análisis de seguridad de un sistema de software realizado
por profesionales de seguridad cualificados que simulan las acciones de un hacker. El
objetivo de una prueba de penetración es descubrir posibles vulnerabilidades resultantes de
errores de codificación, errores de configuración del sistema u otras debilidades de
implementación operativa, y como tal la prueba normalmente encuentra la mayor variedad
de vulnerabilidades. Las pruebas de penetración a menudo se realizan junto con revisiones
de código automatizadas y manuales para proporcionar un mayor nivel de análisis de lo que
normalmente sería posible.

Enlaces útiles:
Analizador de superficie de ataque
Ejemplo de barra de errores de seguridad de SDL
 Prácticas de Microsoft SDL

Práctica #12- Establecer un proceso estándar de respuesta

a incidentes
Preparar un plan de respuesta a incidentes es crucial para ayudar a abordar las nuevas
amenazas que pueden surgir con el tiempo. Debe crearse en coordinación con el equipo de
respuesta a incidentes de seguridad de productos (PSIRT) dedicado de su organización. El
plan debe incluir a quién contactar en caso de una emergencia de seguridad y establecer
el protocolo para el servicio de seguridad, incluidos los planes de código heredado de otros
grupos dentro de la organización y para código de terceros. ¡El plan de respuesta a
incidentes debe probarse antes de que sea necesario!

Enlaces útiles:
Guía de referencia de respuesta a incidentes de Microsoft
Uso de Azure Security Center para una respuesta a incidentes
Administración de incidentes de seguridad de Office 365
Respuesta a incidentes de Microsoft y responsabilidad compartida por la informática en la
nube
Centro de respuesta de seguridad de Microsoft

Fuente:

Microsoft Security Development Lifecycle Practices. (n.d.). Recuperado de

https://www.microsoft.com/en-us/securityengineering/sdl/practices