Modelos de desarrollo seguro de software
4 recomendaciones11,077 vistas
El documento presenta la necesidad de implementar un modelo de desarrollo seguro de software (S-SDLC) debido al aumento de ataques cibernéticos y los altos costos de solucionar vulnerabilidades. Se detalla cómo un S-SDLC puede reducir significativamente tanto el número de vulnerabilidades como los costos asociados con su corrección, al integrar prácticas de seguridad desde las fases iniciales del desarrollo. Además, se describen metodologías, estrategias de implementación y los beneficios de fomentar una cultura de seguridad en las organizaciones dedicadas al desarrollo de software.
Modelos de desarrollo seguro de software
- 1. MODELOS DE DESARROLLO SEGURO DE SOFTWARE Andrés Caro 1
- 2. $whoami Andrés Caro 2 • Profesor Titular de Universidad – Universidad de Extremadura • Área Lenguajes y Sistemas Informáticos • Doctor e Ingeniero en Informática • Director Cátedra ViewNext-UEx Seguridad y Auditoría de Sistemas Software • Grados de Ingeniería en Informática • Ingeniería de Computadores • Ingeniería del Software • Máster en Ingeniería Informática • Organización de cursos / jornadas • I Foro CIBER (noviembre 2016) • Curso Experto Profesional Derecho Tecnológico e Informática Forense • Hacking ético – Seguridad informática • LOPD – ENS • Peritaje – Informática forense • Cibercooperante @_AndresCaro_ andresc@unex.es 2
- 3. Por qué un modelo de desarrollo seguro (S-SDLC) Necesidad: Ataques cibernéticos y coste de solucionar fallos 3 Multitud de ataques cibernéticos con graves consecuencias Fuente: http://map.norsecorp.com 3
- 4. Por qué un modelo de desarrollo seguro (S-SDLC) Necesidad: Ataques cibernéticos y coste de solucionar fallos 4 Coste de solucionar vulnerabilidades Fuente: Instituto Nacional de Estándares y Tecnología (NIST) Incremento del +40% de los ciberataques en España Fuente: (CCN-CERT) 4
- 5. Por qué un modelo de desarrollo seguro (S-SDLC) Necesidad: Ataques cibernéticos y coste de solucionar fallos 5 60 % de los ciberataques se cometen desde dentro (datos mundiales) Fuente: IBM Security Summit 2016 Fuente: IBM Security Summit 2016 5
- 6. Por qué un modelo de desarrollo seguro (S-SDLC) Causas: Falta de seguridad desde el inicio de los proyectos 6 Falta de integración de seguridad en los procesos de desarrollo Aplicar la seguridad en fases finales y más complejas de los proyectos Pérdidas económicas Pérdidas temporales Pérdida de clientes Confianza - Credibilidad Consecuencias: altos costes, retrasos y reputación empresarial 6
- 7. Por qué un modelo de desarrollo seguro (S-SDLC) Necesidad: Generar una conciencia y cultura de la seguridad en las áreas implicadas en el ciclo de vida de un sistema 7 Fuente: IBM Security Summit 2016 7
- 8. Por qué un modelo de desarrollo seguro (S-SDLC) Necesidad: Generar una conciencia y cultura de la seguridad en las áreas implicadas en el ciclo de vida de un sistema 8 DELIVERY • AS-SDLC (Agile Secure – SDLC) • SAST – Static Application Security Testing • Automatización test QA & TESTING • DAST – Dynamic Application Security Testing • Pen-Testing ITS A&I CENTRO DE COMPETENCIA EN SEGURIDAD 8
- 9. Por qué un modelo de desarrollo seguro (S-SDLC) Análisis cuantitativo 9 Reducción número de vulnerabilidades y criticidad: • Alrededor de un 40-50 % de reducción en el número de vulnerabilidades tras la implantación de un S-SDLC en el primer año (un 75-80 % sobre vulnerabilidades críticas). • Una reducción de un 50 % en el número de vulnerabilidades implica una reducción de un 75% en los costes de gestión de la configuración y respuesta a incidentes. 75 % de las vulnerabilidades están relacionadas con las aplicaciones * Haciendo una equiparación del tamaño de los módulos Fuente: Microsoft Security Blog & Microsoft Technet Security Blog Fuente: Piloto implantación proyecto EOSA 9
- 10. Por qué un modelo de desarrollo seguro (S-SDLC) Análisis cuantitativo 10 Reducción de costes de resolución de defectos: • Alrededor de un 30 % de reducción en el coste de solucionar defectos y vulnerabilidades en una fase temprana del ciclo de desarrollo frente a realizar en la fase de pre-producción (post-release). • Además se incluirían costes adicionales por pérdida de productividad y confianza por parte del cliente o usuario final. • Un S-SDLC se ocupa desde el principio y sistemáticamente de las actividades relativas a la seguridad del software durante todo el ciclo de desarrollo, de manera que las vulnerabilidades y su corrección se lleven a cabo en fases incluso previas a la fase de desarrollo, reduciendo sensiblemente los costes globales del desarrollo.. 75 % de las vulnerabilidades están relacionadas con las aplicaciones Fuente: National Institute of Standards and Technology (NIST) Fuente: Piloto implantación proyecto EOSA * Haciendo una equiparación del tamaño de los módulos 10
- 11. Por qué un modelo de desarrollo seguro (S-SDLC) Solución: Análisis de Metodologías y estándares de seguridad 11 Analizar modelos y detectar actividades recurrentes y fundamentales Metodologías de Desarrollo de Software Seguro 11
- 12. Por qué un modelo de desarrollo seguro (S-SDLC) Solución: Análisis de Metodologías y estándares de seguridad 12 Metodologías de Desarrollo de Software Seguro 12
- 13. Por qué un modelo de desarrollo seguro (S-SDLC) Metodologías de Desarrollo de Software Seguro por Defecto 13 Flexibilidad de aplicación empresarial • 4 Funciones de Negocio • 12 Actividades de Seguridad Directiva obligatoria en Microsoft desde 2004: • Más popular y utilizado. • Abundante documentación de los procesos. 13
- 14. Actividades de Seguridad Identificadas 14 Aproximaciones a un S-SDLC • ESTRATEGIA Y ORIENTACIÓN (Top 10 OWASP, CERT, CWE) • FORMACIÓN EN SEGURIDAD de los grupos implicados en el desarrollo. • Identificación y DEFINICIÓN DE RIESGOS de negocio del cliente. • Obtención y validación de los REQUISITOS DE SEGURIDAD. • Análisis y MODELADO DE AMENAZAS que proteja la superficie de ataques. • REVISIÓN DEL DISEÑO. • REVISIÓN DEL CÓDIGO. • TESTING DE SEGURIDAD. • VALIDACIÓN DE SALIDAS garantizando la seguridad del código liberado. • EVALUACIÓN Y MÉTRICAS confirmando el seguimiento de la seguridad. • Implantación de un PLAN DE RESPUESTA A INCIDENTES. Repositorio de vulnerabilidades y gestión del conocimiento Estado del proyecto Observatorio de Seguridad Preventivo Reactivo Nuevas Actividades Propuestas: Carencias detectadas de otros modelos. 14
- 15. Metamodelo de desarrollo seguro Viewnext (S-SDLC) Estructura: Áreas de desarrollo. 15 Políticas Metodología SDL Supervisión Observatorio Divididas en 4 Áreas de Desarrollo: • Definición de objetivos y directrices globales y sectoriales. • Implicación de todos los grupos. Formación. • Conocimiento de los riesgos. • Construcción de software seguro por defecto: • Requisitos, Modelado de amenazas. Diseño seguro. Análisis de código. Testing de seguridad. • Evaluación continua. • Cumplimiento de seguridad. • Conocimiento instantáneo del estado. • Nuevos tipos de ataques y vulnerabilidades. • Aprendizaje continuo. • Convertir medidas reactivas en preventivas. 15
- 16. Modelo de desarrollo seguro Viewnext (S-SDLC) Estructura Metamodelo: Actividades de seguridad 16 ÁREAS DE DESARROLLO ACTIVIDADES DE SEGURIDAD 16
- 17. Modelo de desarrollo seguro Viewnext (S-SDLC) Conexión Metamodelo: Actividades de seguridad 17 Políticas Metodología Supervisión Observatorio17
- 18. Modelo de desarrollo seguro Viewnext (S-SDLC) Metodología SDL: Actividades 18
- 19. Modelo de desarrollo seguro Viewnext (S-SDLC) Evaluación inicial del nivel de seguridad Proyectos con nuevos desarrollos Proyectos en mantenimiento 19
- 20. Modelo de desarrollo seguro Viewnext (S-SDLC) Niveles de Seguridad: Estándar, Moderado y Crítico. 20 20 Estándar Moderado Crítico Comprensión inicial y disposición específica para adoptar las actividades. Incremento de la eficacia y eficiencia de las actividades Realización sofisticada de las actividades acordes a un marco regulatorio específico. Validación Nivel SimbologíaDescripción 20
- 21. Modelo de desarrollo seguro Viewnext (S-SDLC) Adaptaciones del modelo global Viewnext. TIPO DE PROYECTO METODOLOGÍA FASES AMS ÁGIL DISEÑO TÉCNICO -> FIN DESARROLLO 0 TRADICIONAL ANÁLISIS FUNCIONAL->FIN Tipología 1 • DESARROLLO 0 • SCRUM • ANÁLISIS -> FIN Metamodelo – Modelo Teórico base Tipología 2 • AMS/DESARROLLO 0 • TRADICIONAL • DISEÑO TÉCNICO-> FIN Tipología 3 • DESARROLLO 0 • SCRUM • DISEÑO TÉCNICO-> FIN 21
- 22. Modelo de desarrollo seguro Viewnext (S-SDLC) 22 El modelo de ciclo de vida desarrollo seguro para ADM-DW está basado en el modelo de desarrollo seguro corporativo de Viewnext, que establece 4 áreas de aplicación y 14 actividades relacionadas con la definición de un modelo preventivo, integrado e integral. Modelo Desarrollo Seguro Viewnext Modelo Adaptación Ciclo de Vida Aplicación del Modelo Memoria de Aplicación •4 áreas/14 actividades •2 modelos de implantación (nuevos desarrollos / mantenimientos) •AS-SDLC (Agile Secure – Software Development Life Cycle) •WS-SDLC (Waterfall Secure – Software Development Life Cycle) •Categorización del ciclo de vida del proyecto •Particularización y contextualización del modelo adaptado adecuado •Bitácora de aplicación •Métricas e indicadores •Lecciones aprendidas •Conclusiones y siguientes pasos
- 23. ¿Cómo se implanta el S-SDLC en mi proyecto? 23 Metodología: 4 Fases de implantación 2016 Formación y Definición de indicadores de seguridad Evaluación inicial de seguridad Medición del coste de solucionar fallos Integración Modelo de Desarrollo Seguro Aplicación metodología SDL Medición coste metodología SDL Optimización del Modelo de Desarrollo Seguro Contrastar nivel de seguridad FORMACIÓN Y PREPARACIÓN DEL ECOSISTEMA EVALUACIÓN DE LA SEGURIDAD INTEGRACIÓN DEL MODELO SDLC RETROSPECTIVA Y MEJORA CONTINUA Preparación de herramientas Formación de la población Equipo de Calidad y Pruebas Requisitos | Modelado de amenazas | Buenas prácticas Cuestionario de implantación
- 24. ¿Cómo se implanta el S-SDLC en mi proyecto? 24 Metodología: Fases en las que más interviene ADM DW. RETROSPECTIVA Y MEJORA CONTINUA Riesgo de Exposición | Nivel de Riesgo | Análisis y resolución de vulnerabilidades | Nivel de inversión FORMACIÓN Y PREPARACIÓN DEL ECOSISTEMA FORMACIÓN (EQUIPO COMPLETO) Analista de Negocio Diseñador Desarrollador ECOSISTEMA DE SEGURIDAD RTC INTEGRACIÓN DEL MODELO SDLC Requisitos -> Amenazas -> Prácticas seguras de codificación Definición exhaustiva de: – Tipos de usuario y sus privilegios. – Ciclo de vida de los privilegios. – Principio del mínimo privilegio. – Fallar seguro ante escalada de privilegios.
- 25. ¿Cómo se implanta el S-SDLC en mi proyecto? 25 Metodología: Trazabilidad de Requisitos – Amenazas – Buenas prácticas. ¿Qué tipo de aplicativo es? • Aplicación Web. • Web Service. • Aplicación móvil. ¿El sitio web requiere autenticación? • Si. o Registro del estado de las operaciones de autenticación. • No, existe funcionalidad para perfiles públicos. ¿Cómo se autentica el usuario? • Usuario y contraseña o Login de sesión y criterios de contraseña segura. • Doble factor de autenticación. • Certificado Digital. • Sin autenticar. ¿Se almacenan los estados de las peticiones de autenticación en un Log? • Se almacenan sólo los intentos fallidos para su posterior análisis. ¿Existe una política de directiva de grupos - GPO (Group Policy Object)? • Cumplir criterios de contraseña segura. • Temporalidad (cambiar contraseñas cada dos meses.) • Imposibilidad de repetir la misma contraseña. Responder un cuestionario básico Identificar temas de seguridad MODELADO DE AMENAZAS IDENTIFICACIÓN DE: • ACTIVOS. • ENTIDADES EXTERNAS. • PUNTOS DE ENTRADA.
- 26. Resultado final Comparativa de costes VS nivel de seguridad Coste corrección de vulnerabilidades Coste de seguridad global Coste por fase sin aplicar seguridad Coste por fase con seguridad 0 5 10 15 20 A D C T Post-P 0 5 10 15 20 A D C T SEG. 0 5 10 15 20 A D C T Post-P 0 5 10 15 20 A D C T Post-P PROYECTO SIN SEGURIDAD PROYECTO CON MODELO SDLC 26
- 27. Implantación Modelo de Desarrollo Seguro en Viewnext Proyecto Piloto EOSA: Contexto Nuevos Desarrollos con intervención desde la fase de toma de requisitos y análisis funcional. Metodología ágil SCRUM (ciclos de liberación frecuentes). Tipología 1 • DESARROLLO 0 • SCRUM • ANÁLISIS -> FIN Equipo Multifuncional 73% 27% 27% Temporalidad módulo desarrollados ALMACENES - 1997h PERSONAL - 747h
- 28. Implantación Modelo de Desarrollo Seguro en Viewnext 28 EOSA: Fase 2 - Auditoria y resolución de fallos de seguridad - ALMACENES Proyectos en mantenimiento Detectar fallos de seguridad 0 5 10 15 20 Coste resolver las vulnerabilidadesAplicar testing de seguridad y revisión de código
- 29. Implantación Modelo de Desarrollo Seguro en Viewnext 29 EOSA: Fase 2 - Auditoria y resolución de fallos de seguridad - ALMACENES Auditoria y resolución de fallos de seguridad (horas/fase) 0 200 400 600 800 1000 1200 Gestión Análisis y Diseño Construcción Testing Incidencias 98,85 494,25 1186,2 197,7 187,561 CENTRO DE CALIDAD Y PRUEBAS
- 30. Implantación Modelo de Desarrollo Seguro en Viewnext EOSA: Fase 2 - Auditoria y resolución de fallos de seguridad Tipos y categorías de vulnerabilidades 25 vulnerabilidades DAST
- 31. Implantación Modelo de Desarrollo Seguro en Viewnext 31 EOSA: Fase 2 - Auditoria y resolución de fallos de seguridad Riesgo de vulnerabilidades por módulo
- 32. Implantación Modelo de Desarrollo Seguro en Viewnext 32 EOSA: Fase 3 - Implantación de actividades y coste - PERSONAL Implantación en nuevos desarrollos Incremento de coste en cada fase Coste por fase de aplicar seguridadAplicar la seguridad en todo el proceso de construcción del software 0 5 10 15 20
- 33. Implantación Modelo de Desarrollo Seguro en Viewnext 33 EOSA: Fase 3 - Implantación de actividades y coste - PERSONAL Implantación del modelo en nuevos desarrollos e incremento de coste por cada fase 0 50 100 150 200 250 300 350 400 450 Gestión Análisis y Diseño Construcción Testing Incidencias 49 215 383 54 1 27,5 21 8 10 63 CENTRO DE CALIDAD Y PRUEBAS
- 34. Implantación Modelo de Desarrollo Seguro en Viewnext 34 Proyecto Piloto EOSA: Fase 3 - Implantación de actividades y coste ALMACENES PERSONAL Resto Seguridad FASE Seguridad Resto 99 13 GESTIÓN 1 49 494 6,5 ANÁLISIS Y DISEÑO 27,5 215,5 1186 87 DESARROLLO 21 383 198 10 TESTING 8 54 71 INCIDENCIAS 10 61 AUDITORIAS 63
- 35. Implantación Modelo de Desarrollo Seguro en Viewnext 35 Proyecto Piloto EOSA: Fase 4 - Comparativa de costes y nivel de seguridad Coste corrección de vulnerabilidades Coste de seguridad global Coste por fase sin aplicar seguridad Coste por fase con seguridad 0 5 10 15 20 A D C T Post-P 0 5 10 15 20 A D C T SEG. 0 5 10 15 20 A D C T Post-P 0 5 10 15 20 A D C T Post-P
- 36. Implantación Modelo de Desarrollo Seguro en Viewnext 36 Proyecto Piloto EOSA: Fase 4 - Comparativa de costes y nivel de seguridad Coste corrección de vulnerabilidades Coste de seguridad global Coste por fase sin aplicar seguridad Coste por fase con seguridad 0 250 500 750 1000 G A y D C T Post-P 98,85 494,25 1186,2 197,7 187,5 0 50 100 150 200 G A y D C T SEG. 0 50 100 150 200 A D C T Post-P 187,5 0 100 200 300 400 500 G A y D C T Post-P 49 215 383 541 27,5 21 8 10 67,5
- 37. Implantación Modelo de Desarrollo Seguro en Viewnext 37 Proyecto Piloto EOSA: Conclusiones de auditoría • Dedicando mayor atención en la fase de análisis, reducimos drásticamente el tiempo de desarrollo, no así el de diseño y pruebas. • Dedicando atención en la toma de requisitos, concienciamos al cliente para poder dedicar tiempo en esta área de desarrollo que da por cubierta, erróneamente, en la mayoría de los casos. • El análisis de código estático es fácil de corregir, no así el manual que puede requerir incluso cambios arquitectónicos. • Menor impacto y mayor seguridad al incorporar el desarrollo seguro en fases tempranas del desarrollo.
- 38. Implantación Modelo de Desarrollo Seguro en Viewnext 38 Proyecto Piloto EOSA: Conclusiones de equipo • Incremento en la conciencia de la necesidad de un desarrollo seguro. • Impacto temporal en la resolución de vulnerabilidades cuando se detectan en fases avanzadas del desarrollo y en los módulos que no han contemplado la seguridad. • Contraprestaciones – Inversión adicional por parte del equipo para la implantación y adopción inicial del modelo. • Incertidumbre sobre los módulos desarrollados sin tener en cuenta la seguridad.
- 39. 39 ¿Cuándo replantearme la aplicación de un S-SDLC? • Has tenido incidentes de seguridad o has actuado de forma reactiva. • Es una demanda interna o existe alguna normativa de seguridad. • Es una exigencia del sector de negocio. • Existe un marco regulatorio sobre ciberseguridad. • Lo propongo al cliente como una mejora u objetivo estratégico. • Aporta ventaja competitiva al negocio. • Tengo la capacidad de inversión. ¿Cuándo replantearme la aplicación de un SDLC? Si… REPLANTÉATE UN S-SDLC. ¿Has sumado 1 o más? 1 1 1 1 1 1 1
- 40. GRACIAS POR SU ATENCIÓN 40