Ciclo de Vida de Desarrollo Seguro de Software (es-ES)
El Ciclo de Vida de Desarrollo de Software Seguro (SDL) es un proceso de desarrollo de software que ayuda a los desarrolladores a crear software más seguro y cumplir los requisitos de cumplimiento de seguridad, reduciendo al mismo tiempo los costes de desarrollo. Esta metodología en particular, fue impulsada y desarrollada por Microsoft y puede acceder a ella visitando este sitio.
En términos generales, esta metodología consta de 17 prácticas agrupadas en 7 fases, que son:
ENTRENAMIENTO
Práctica #1 de SDL: Entrenamiento básico de seguridad
Esta práctica es un requisito previo para implementar el SDL. Los conceptos básicos para la construcción de un mejor software incluyen diseño seguro, modelado de amenazas, codificación segura, pruebas de seguridad y las mejores prácticas que rodean la privacidad. Más información sobre esta fase aquí.
REQUISITOS
Práctica #2 de SDL: Establecer requisitos de seguridad y privacidad
Definir e integrar los requisitos de seguridad y privacidad de forma temprana facilita la identificación de los hitos clave y entregables y minimiza las interrupciones en los planes y los horarios.
Práctica #3 de SDL: Crear puertas de calidad / barras de errores
Definir niveles mínimos aceptables de seguridad y calidad de privacidad al inicio ayuda a un equipo a comprender los riesgos asociados con los problemas de seguridad, identificar y solucionar errores de seguridad durante el desarrollo y aplicar los estándares en todo el proyecto.
Práctica #4 de SDL: Realizar evaluaciones de riesgos de seguridad y privacidad
Examinar el diseño de software basado en los costos y los requisitos reglamentarios ayuda a un equipo a identificar qué partes del proyecto requerirán modelado de amenazas y revisiones de diseño de seguridad antes del lanzamiento y determinarán la Clasificación de impacto de privacidad de una característica, producto o servicio.
Más información sobre esta fase aquí.
DISEÑO
Práctica #5 de SDL: Establecer requisitos de diseño
Teniendo en cuenta las preocupaciones de seguridad y privacidad las primeras ayudan a minimizar el riesgo de interrupciones en el horario y reducir los gastos de un proyecto.
Práctica #6 de SDL: Análisis / Reducción de Superficies de Ataque
Reducir las oportunidades de los atacantes para explotar un potencial punto débil o vulnerabilidad requiere un análisis exhaustivo de la superficie de ataque general e incluye la inhabilitación o restricción del acceso a los servicios del sistema, aplicando el principio de los privilegios mínimos y empleando defensas estratificadas siempre que sea posible.
Práctica #7 de SDL: Usar la modelización de amenazas
La aplicación de un enfoque estructurado a los escenarios de amenazas durante el diseño ayuda a un equipo de manera más eficaz y menos costosa identificar vulnerabilidades de seguridad, determinar los riesgos de esas amenazas y establecer mitigaciones apropiadas.
Más información sobre esta fase aquí.
IMPLEMENTACIÓN
Práctica #8 de SDL: Utilizar Herramientas Aprobadas
Publicar una lista de herramientas aprobadas y comprobaciones de seguridad asociadas (como opciones y advertencias de compilador / vinculador) ayuda a automatizar y aplicar las prácticas de seguridad fácilmente ya un bajo costo. Mantener la lista actualizada regularmente significa que se usan las últimas versiones de herramientas y permite incluir nuevas funcionalidades y protecciones de análisis de seguridad.
Práctica #9 de SDL: Depreciar funciones inseguras
El análisis de todas las funciones del proyecto y las API y la prohibición de aquellas que se consideran inseguras ayuda a reducir los posibles errores de seguridad con muy pocos costos de ingeniería. Las acciones específicas incluyen el uso de archivos de encabezado, compiladores más recientes o herramientas de análisis de código para comprobar el código de las funciones de la lista prohibida y, a continuación, reemplazarlas por alternativas más seguras.
Práctica #10 de SDL: Realizar análisis estático
Analizar el código fuente antes de compilar proporciona un método escalable de revisión del código de seguridad y ayuda a garantizar que se siguen políticas de codificación segura.
Más información sobre esta fase aquí.
VERIFICACIÓN
Práctica # 11 de SDL: Realizar análisis dinámico
La realización de la verificación en tiempo de ejecución comprueba la funcionalidad del software mediante herramientas que supervisan el comportamiento de la aplicación en caso de corrupción de la memoria, problemas de privilegios de usuario y otros problemas críticos de seguridad.
Práctica # 12 de SDL: Pruebas de Fuzzing
Inducir fallos del programa mediante la introducción deliberada de datos malformados o aleatorios en una aplicación ayuda a revelar posibles problemas de seguridad antes de la liberación, mientras que requiere una inversión de recursos modesta.
Práctica # 13 de SDL: Revisión de superficie de ataque
La revisión de la medición de la superficie de ataque al completar el código ayuda a asegurar que cualquier cambio de diseño o implementación en una aplicación o sistema se ha tenido en cuenta y que los nuevos vectores de ataque creados como resultado de los cambios han sido revisados y mitigados incluyendo modelos de amenaza.
Más información sobre esta fase aquí.
LIBERACIÓN
Práctica 14 de SDL: Crear un plan de respuesta a incidentes
La preparación de un plan de respuesta a incidentes es crucial para ayudar a enfrentar las nuevas amenazas que pueden surgir con el tiempo. Incluye la identificación de contactos de emergencia de seguridad apropiados y el establecimiento de planes de servicio de seguridad para el código heredado de otros grupos dentro de la organización y para el código de terceros con licencia.
Práctica # 15 de SDL: Realizar la revisión final de seguridad
La revisión deliberada de todas las actividades de seguridad que se realizaron ayuda a asegurar la disponibilidad de la versión de software. La revisión final de seguridad (FSR, por sus siglas en inglés) generalmente incluye el examen de modelos de amenazas, resultados de herramientas y desempeño en contra de las puertas de calidad y barras de fallos definidas durante la Fase de Requisitos.
Práctica # 16 de SDL: Certificar lanzamiento y Archivado
La Certificación de software antes de un lanzamiento ayuda a garantizar la seguridad y los requisitos de privacidad se cumplieron. Archivar todos los datos pertinentes es esencial para realizar tareas de mantenimiento posteriores a la liberación y ayuda a reducir los costos a largo plazo asociados con la ingeniería de software sostenida.
Más información sobre esta fase aquí.
RESPUESTA
Práctica # 17 de SDL: Ejecutar un plan de respuesta a incidentes
Ser capaz de implementar el plan de respuesta a incidentes instituido en la fase de lanzamiento es esencial para ayudar a proteger a los clientes de vulnerabilidades de seguridad o privacidad de software que surgen.