Implementando owasp samm en latam
0 recomendaciones535 vistas
El documento describe la implementación del modelo OWASP SAMM (Software Assurance Maturity Model) en Latinoamérica. El modelo SAMM v2 consta de 15 prácticas de seguridad divididas en 5 funciones (gobierno, diseño, implementación, verificación y operaciones) y 3 niveles de madurez. El documento explica algunas de las prácticas de seguridad como modelado de amenazas, requerimientos de seguridad y pruebas de seguridad, destacando herramientas como OWASP Threat Dragon, Dependency Track y ZAP
Implementando owasp samm en latam
- 2. Implementando OWASP SAMM en Latinoamérica Mateo Martínez [email protected]
- 3. El modelo original OpenSAMM 1.0 fue escrito por Pravir Chandra y data de 2009. Durante los últimos 10 años, ha demostrado ser un modelo ampliamente distribuido y efectivo para mejorar las prácticas de software seguro en diferentes tipos de organizaciones. . v1 El nuevo modelo SAMM admite el desarrollo en cascada, iterativo, ágil y DevOps. El modelo es lo suficientemente flexible como para permitir a las organizaciones tomar un camino basado en su tolerancia al riesgo y la forma en que construyen y usan el software. v2 https://owaspsamm.org/
- 5. No se ve nada …
- 6. OWASP SAMM v1 (y 1.5) https://owasp.org/www-pdf-archive/SAMM_Core_V1-5_FINAL.pdf
- 8. El modelo de la versión 2.0 ahora admite actualizaciones frecuentes a través de pequeños cambios incrementales en partes específicas del modelo con actualizaciones periódicas de explicaciones, herramientas y orientación por parte de la comunidad. Actualizaciones Frecuentes:
- 9. Algunos cambios importantes : § Construcción ahora se ha transformado en diseño § Se incorpora una nueva función de negocio: implementación § Función comercial rediseñada: verificación § Nueva práctica de seguridad: gestión operativa § La habilitación operativa ya no existe y otras prácticas absorbieron sus actividades. § Las actividades ahora se ordenan en flujos lógicos en cada una de las 15 prácticas de seguridad divididas en dos flujos, que alinean y vinculan las actividades en la práctica en los diferentes niveles de madurez.
- 16. El enfoque típico: OWASP SAMM posee un modelo adecuado para apoyar la mejora continua, en cuyo caso el ciclo se ejecuta continuamente, generalmente en períodos de 3 a 12 meses. Preparación y análisis de contexto Evaluación frente al modelo Establecer objetivos Planificar la implementación Roll-out o puesta en marcha
- 17. OWASP SAMM v2 El nuevo SAMM v2 consta de los siguientes componentes: § El resumen ejecutivo y la introducción del modelo SAMM § Una guía de rápida con los pasos para mejorar su práctica de software seguro § Una caja de herramientas para SAMM actualizada para realizar evaluaciones y crear hojas de ruta § Una nueva iniciativa de SAMM para comparar su madurez y progreso con otras organizaciones y equipos similares (benchmarking)
- 18. 1. Gobierno
- 19. 1. Gobierno El gobierno se centra en los procesos y actividades relacionados con la forma en que una organización gestiona las actividades generales de desarrollo de software. Más específicamente, esto incluye preocupaciones que afectan a los grupos interfuncionales involucrados en el desarrollo, así como a los procesos comerciales establecidos a nivel de organización. 1.Gobierno 1.1 Estrategia y Métricas 1.2 Políticas y Cumplimiento 1.3 Educación y Líneamientos
- 20. 1. Gobierno 1.1 Estrategia y Métricas 1.Gobierno 1.1 Estrategia y Métricas 1.2 Políticas y Cumplimiento 1.3 Educación y Líneamientos
- 21. § Nivel 1 es la implementación inicial § Nivel 2 es una implementación estructurada § Nivel 3 es una operación optimizada. 3 Niveles de Madurez:
- 22. 1. Gobierno 1.1 Estrategia y Métricas
- 23. 1. Gobierno 1.1 Estrategia y Métricas
- 24. 1. Gobierno 1.1 Estrategia y Métricas
- 25. 1. Gobierno 1.1 Estrategia y Métricas
- 26. 1. Gobierno 1.1 Estrategia y Métricas
- 27. 1. Gobierno 1.1 Estrategia y Métricas
- 28. ¿viene algo más técnico?
- 29. No, seguimos un poco más con Gobierno J
- 30. 1. Gobierno 1.2 Políticas y Cumplimiento 1.Gobierno 1.1 Estrategia y Métricas 1.2 Políticas y Cumplimiento 1.3 Educación y Líneamientos
- 31. 1. Gobierno 1.2 Políticas y Cumplimiento
- 32. 1. Gobierno 1.3 Educación y Lineamientos 1.Gobierno 1.1 Estrategia y Métricas 1.2 Políticas y Cumplimiento 1.3 Educación y Líneamientos
- 33. 1. Gobierno 1.3 Educación y Lineamientos
- 34. 2. Diseño
- 35. 2. Diseño El diseño se refiere a los procesos y actividades relacionadas con la forma en que una organización define objetivos y crea software dentro de proyectos de desarrollo. En general, esto incluirá la recopilación de requisitos, la especificación de arquitectura de alto nivel y el diseño detallado. 2.Diseño 2.1 Modelado de Amenazas 2.2 Requerimientos de Seguridad 2.3 Arquitectura de Seguridad
- 36. 2. Diseño 2.1 Modelado de Amenazas
- 37. 2. Diseño 2.1 Modelado de Amenazas En el nivel de madurez 1, realiza un modelado de amenazas ad-hoc para aplicaciones de alto riesgo y utiliza listas de verificación de amenazas simples, como STRIDE. • S - Spoofing • T - Tampering • R - Repudiation • I - Integrity • D - Denial of Service • E – Elevation of privileges
- 38. 2. Diseño 2.1 Modelado de Amenazas En el Nivel 2, la metodología de modelado de amenazas incluye al menos: • Diagramas • identificación de amenazas • mitigaciones de fallas de diseño • cómo validar los artefactos del modelo de amenaza. Descubre amenazas a su aplicación con listas de verificación, como STRIDE o más amenazas específicas de la organización.
- 39. 2. Diseño 2.1 Modelado de Amenazas En el Nivel 3, el modelado de amenazas está integrado en su SDLC y se ha convertido en parte de la cultura de seguridad del desarrollador. Los patrones de riesgo reutilizables, que comprenden bibliotecas de amenazas relacionadas, fallas de diseño y mitigaciones de seguridad, se crean y mejoran, según los modelos de amenazas de la organización. Regularmente (por ejemplo, anualmente) revisa los modelos de amenazas existentes para verificar que no haya nuevas amenazas relevantes para sus aplicaciones. Automatiza partes de su proceso de modelado de amenazas con herramientas de modelado de amenazas. Integre sus herramientas de modelado de amenazas con otras herramientas de seguridad, como herramientas de verificación de seguridad y herramientas de seguimiento de riesgos.
- 41. 2. Diseño OWASP Threat Dragon https://threatdragon.org/
- 42. 2. Diseño OWASP Threat Dragon https://threatdragon.org/
- 43. 2. Diseño OWASP Threat Dragon https://threatdragon.org/
- 44. 2. Diseño 2.2 Requerimientos de Seguridad
- 45. 2. Diseño 2.3 Arquitectura de Seguridad
- 47. 3. Implementación La implementación se centra en los procesos y actividades relacionados con la forma en que una organización construye e implementa componentes de software y sus defectos relacionados. Las actividades dentro de la función de Implementación tienen el mayor impacto en la vida diaria de los desarrolladores. El objetivo general es entregar software funcional y confiable con defectos mínimos. 3.Implementación 3.1 Construcción segura (build) 3.2 Implementación segura (deploy) 3.3 Gestión de defectos
- 48. 3. Implementación 3.1 Construcción Segura (Secure Build)
- 49. Zzzzz….
- 50. 3. Implementación OWASP Dependency Track https://owasp.org/www-project-dependency-track/ Dependency-Track is an intelligent Supply Chain Component Analysis platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of- Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.
- 51. 3. Implementación OWASP Dependency Track https://owasp.org/www-project-dependency-track/
- 54. 3. Implementación 3.2 Implementación Segura (Secure Deployment)
- 55. 3. Implementación 3.3 Gestión de defectos
- 56. 4. Verificación
- 57. 4. Verificación La verificación se centra en los procesos y actividades relacionados con la forma en que una organización verifica y prueba los artefactos producidos durante el desarrollo del software. Esto generalmente incluye el trabajo de aseguramiento de la calidad, como las pruebas, pero también puede incluir otras actividades de revisión y evaluación. 4.Verificación 4.1 Evaluación de Arquitectura 3.2 Pruebas de requerimientos 3.3 Pruebas de seguridad (AST)
- 58. 4. Verificación 4.1 Evaluación de Arquitectura
- 59. 4. Verificación 4.2 Pruebas de requerimientos
- 60. 4. Verificación OWASP ZAP https://www.zaproxy.org/
- 61. 4. Verificación 4.3 Pruebas de seguridad (AST o Application Security Testing)
- 62. Ahora si! Hay más herramientas!
- 63. 4. Verificación 4.3 Pruebas de Seguridad – Stream A Nivel 1: Ejecución de herramientas SAST y DAST Nivel 2: Customización de reglas, filtrado de falsos positivos y mucho cuidado con falta de detecciones. Nivel 3: Automatización de procesos, Dashboards de control, KPIs e integración de herramientas por ejemplo de ticketing
- 64. 4. Verificación 4.3 Pruebas de Seguridad – Stream A
- 65. 4. Verificación 4.3 Pruebas de Seguridad – Stream A
- 66. 4. Verificación 4.3 Pruebas de Seguridad – Stream B Nivel 1: Revisión manual de vulnerabilidades con ayuda de SAST y DAST. “Las herramientas automatizadas son efectivas para encontrar varios tipos de vulnerabilidades, pero nunca pueden reemplazar la revisión manual de expertos.” Nivel 2: Ejecución de pentesting Black-box Nivel 3: low-friction automated tests integrated into development tools and build processes. Security champions and the central secure software group continuously review results from automated and manual security tests during development. Consider and implement security test correlation tools to automate the matching and merging of test results from dynamic, static, and interactive application scanners into one central dashboard, providing direct input towards Defect Management
- 67. 5. Operaciones
- 68. 5. Operaciones La función de operaciones abarca aquellas actividades necesarias para garantizar que se mantenga la confidencialidad, la integridad y la disponibilidad durante toda la vida operativa de una aplicación y sus datos asociados. El aumento de la madurez con respecto a esta función comercial proporciona una mayor seguridad de que la organización es resistente a las interrupciones operativas y responde a los cambios en el ambiente. 5.Operaciones 3.1 Gestión de Incidentes 3.2 Gestión del ambiente 3.3 Gestión de Operaciones
- 69. 5. Operaciones 5.1 Gestión de Incidentes
- 70. 5. Operaciones 5.2 Gestión del ambiente
- 71. 5. Operaciones 5.3 Gestión de Operaciones
- 75. ¡MUCHAS GRACIAS! Implementando OWASP SAMM en Latinoamérica Mateo Martínez [email protected]