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

2. Implementando OWASP
SAMM en Latinoamérica
Mateo Martínez
mateo.Martinez@owasp.org

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/

4. v1
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

7. OWASP SAMM v2
https://owaspsamm.org/model/

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.

14. Resumen del modelo

15. ¿Cómo implementar esto?

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.

40. ¿y? ¿Alguna herramienta?

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

46. 3. Implementación

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/

52. 3. Implementación
OWASP dependency-check-sonar-plugin
https://github.com/stevespringett/dependency-check-sonar-plugin

53. 3. Implementación
OWASP dependency-check-jenkins-plugin
https://plugins.jenkins.io/dependency-check-jenkins-plugin/

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

72. OWASP SAMM TOOLKIT

73. SAMM TOOLKIT
https://github.com/OWASP/samm/tree/master/Supporting%20Resources/v2.0/toolbox

74. SAMM TOOLKIT
https://github.com/OWASP/samm/tree/master/Supporting%20Resources/v2.0/toolbox

75. ¡MUCHAS GRACIAS!
Implementando OWASP
SAMM en Latinoamérica
Mateo Martínez
mateo.Martinez@owasp.org