OWASP SAMM
Software Assurance Maturity Model
Version 1.5
Lic. Paola Rodríguez
Modelos de Madurez.
Modelo de Madurez OWASP SAMM.
Caso Práctico: Empresa Financiera
Cambios de OWASP SAMM 1.5 a 2.0.
Agenda
Identificar cómo está la organización
en relación al “debe ser”
de las buenas prácticas.
Criterios de Selección
Modelos de Madurez
Identificar cómo está la organización
en relación al “debe ser”
de las buenas prácticas.
Criterios de Selección para Empresas Financieras ???
Modelos de Madurez
OWASP SAMM
Criterios de Selección para Empresas Financieras
Nuevo Enfoque basado en:
- Requisitos basados en Objetivos de Control
Modelos de Madurez
Criterios de Selección para Empresas Financieras
Alcance: Los requisitos del SLC seguro de PCI, se aplican a los procesos, la tecnología y el proveedor de Software que participan en el Diseño, Desarrollo, Implantación y Mantenimiento de los productos y servicios de software del proveedor.
Modelos de Madurez
Gobierno de Seguridad del Software
Ingeniería del Software Seguro
Software Seguro y Gestión del Dato
Gobierno de Seguridad del Software
Funciones
Criterios de Selección para Empresas Financieras
Gobierno - Objetivo de Control 2: POLÍTICA Y ESTRATEGIA DE SEGURIDAD DE SOFTWARE.
Modelos de Madurez
¡OWASP SAMM ES UNA BUENA ELECCIÓN!
Modelo de Madurez para el Aseguramiento
del Software es un marco de trabajo para ayudar
a las organizaciones a formular e implementar una ESTRATEGIA DE SEGURIDAD para software que sea adecuada a las necesidades específicas que está enfrentando la organización.
OWASP SAMM
LOS PROVEEDORES DE SOFTWARE DEBERÍAN DE ADOPTAR LOS MARCOS O METODOLOGÍAS EXISTENTES O DESARROLLAR LOS SUYOS PROPIOS DE ACUERDO CON LAS MEJORES PRÁCTICAS ACEPTADAS POR LA INDUSTRIA PARA LA GESTIÓN SEGURA DEL CICLO DE VIDA DEL SOFTWARE
Aquellos que desarrollan sus propias metodologías deben entender cómo se diferencian de las metodologías aceptadas por la industria, identificar cualquier omisión y garantizar que se mantienen las pruebas suficientes para demostrar claramente de qué forma sus metodologías son al menos tan eficaces como las aceptadas por la industria.
OWASP SAMM
OWASP SAMM
En forma resumida, OWASP SAMM permite a las organizaciones:
Trabaja con 4 Funciones de Negocio
Enfocado en los procesos y actividades relacionadas a como una organización gestiona las actividades del desarrollo de software a nivel global.
Refiere a los procesos y actividades relacionados a como una organización define metas y crea software dentro de proyectos de desarrollo.
Enfocada en los procesos y actividades relacionadas a como una organización verifica y prueba artefactos producidos a través del desarrollo del Software.
Abarca los procesos y actividades relacionadas con la forma en que una organización administra la liberación de sistemas.
Entendiendo el Modelo
Para cada Función de Negocio, se definen 3 Prácticas de Seguridad.
Estrategia y Métricas
Educación y Orientación.
Evaluación de Amenazas.
Requisitos de Seguridad.
Arquitectura de Seguridad.
Revisión de Diseño.
Revisión de Código.
Pruebas de Seguridad.
Administración de Vulnerabilidades.
Fortalecimiento de Ambientes.
Habilitación Operativa.
Entendiendo el Modelo
Para cada Práctica de Seguridad existen 3 niveles de Madurez bien definidos y un nivel inicial (cero) implícito. En general representan:
Punto de inicio, implícito, las actividades en la Práctica no se han realizado.
Entendimiento inicial y provisión ad hoc de la Práctica de Seguridad.
Incremento en la eficiencia y/o efectividad de la Práctica de Seguridad.
Dominio amplio de la Práctica de Seguridad.
0
1
2
3
Entendiendo el Modelo
Entendiendo el Modelo
EMPRESA: CASO-EMPRESA-FINANCIERA
Rubro: Empresa Financiera
Producto: Software para medio de pagos (tarjetas de crédito, tarjetas de débito, prepagas, etc.).
Tamaño de la Organización: Mediana (aprox. 80 personas en Uruguay).
Software Factory: Conformada por las siguientes áreas: PMO, Desarrollo, Soporte, QA, Compliance, Release Control.
Marco Regulatorio: PCI-DSS para versión X.Y del Producto
Caso Práctico
EMPRESA: CASO-EMPRESA-FINANCIERA
Retos:
Caso Práctico
Situación Inicial del Modelo de Madurez OWASP SAMM
Caso Práctico
GOB | Estrategia y Métricas | Respuesta | Peso | Prom | Rating |
SM1 | ¿Existe un programa de aseguramiento de la seguridad del software? | No | 0 | 0 | 0,13 |
| ¿Entienden los interesados en el negocio el perfil de riesgos de la organización? | No | 0 | | |
| ¿Es de conocimiento de los desarrolladores los planes a futuro para el programa de aseguramiento? | No | 0 | | |
SM2 | ¿Están la mayoría de los recursos y aplicaciones organizados por riesgo? | Si, un % menor | 0.2 | 0,133 | |
| Se utiliza el riesgo para adaptar las actividades de aseguramiento | No | 0 | | |
| ¿La organización entiendo lo que es la valoración del riesgo? | Si, un % menor | 0.2 | | |
SM3 | ¿Se recolectan los datos por proyecto del costo de las actividades de aseguramiento? | No | 0 | 0 | |
| ¿Se comparan los gastos de seguridad con otras organizaciones similares? | No | 0 | | |
Caso Práctico
GOB | Política y Cumplimiento | Respuesta | Peso | Prom | Rating |
PC1 | ¿Los involucrados en los proyectos, conocen el estado de cumplimiento del mismo? | Si, la mayoría de ellos | 1 | 1 | 1,55 |
| ¿Se consideran los requisitos de cumplimiento específicamente en los proyectos? | Si | 1 | | |
PC2 | ¿La organización utiliza políticas y estándares para controlar el desarrollo de software? | Si, existe un standard | 0.5 | 0,350 | |
| Los equipos de proyecto, son capaces de solicitar una auditoría de cumplimiento con políticas y estándares. | Si, un % menor | 0.2 | | |
PC3 | Los proyectos ¿son auditados periódicamente para asegurar un base de cumplimiento? | Si, un % menor | 0.2 | 0.2 | |
| ¿La organización usa auditorías sistemáticas para recolectar y controlar evidencia de cumplimiento? | Si, localizada en x áreas de negocio | 0.2 | | |
Caso Práctico
GOB | Educación y Orientación | Respuestas | Peso | Prom | Rating |
EG1 | ¿Los desarrolladores, reciben capacitación de alto nivel en seguridad? | Si, anualmente | 1 | 0,750 | 1,70 |
| ¿Los equipos de proyecto, saben donde encontrar las prácticas definidas y tienen acceso? | Si, al menos la mitad | 0.5 | | |
EG2 | ¿El personal involucrado con el proceso de desarrollo recibe entrenamiento y orientación en seguridad acorde a su rol? | Si, al menos la mitad | 0.5 | 0,350 | |
| Los stakeholders tiene la capacidad de contratar a expertos en seguridad para sus proyectos? | Si, un % menor | 0.2 | | |
EG3 | ¿La capacitación en seguridad se controla de forma centralizada y se distribuye de forma coherente en toda la organización? | Si, los equipos controlan y distribuyen | 0.2 | 0.6 | |
| ¿Se avalúan a los desarrolladores luego de recibido la capacitación? | Si, anualmente | 1 | | |
Caso Práctico
Caso Práctico
OP | Gestión de Incidentes | Respuestas | Peso | Prom | Rating |
IM1 | ¿Existe un punto de contacto en los proyectos para problemas de seguridad o incidentes? | Si | 0.5 | 0,667 | 1,07 |
| ¿Su organización tiene un equipo de respuesta de seguridad asignado? | Si, existe proceso maduro | 1 | | |
| ¿Los equipos de proyecto conocen su(s) punto(s) de seguridad de contacto y equipo(s) de respuesta? | Si, al menos la mitad | 0.5 | | |
IM2 | ¿Utiliza la organización un proceso consistente para el informe y manejo de incidentes? | Si, para algunos proyectos | 0.2 | 0.2 | |
| ¿Las partes interesadas del proyecto son conscientes de las divulgaciones de seguridad relevantes relacionadas con sus proyectos de software? | Si, % menor | 0.2 | | |
IM3 | ¿Se inspeccionan los incidentes en busca de causas raíz para generar más recomendaciones? | Si, % menor | 0.2 | 0.2 | |
| ¿Los proyectos recopilan y reportan consistentemente datos y métricas relacionadas con incidentes? | Si, % menor | 0.2 | | |
Caso Práctico
OP | Fortalecimiento del Ambiente | Respuestas | Peso | Prom | Rating |
EH1 | ¿Los proyectos documentan los requisitos de seguridad del entorno operativo? | Si, un % menor | 0.2 | 0.2 | 1,15 |
| ¿Los proyectos comprueban si hay actualizaciones de seguridad para componentes de software de terceros? | Si, un % menor. | 0.2 | | |
EH2 | ¿Se utiliza un proceso coherente para aplicar actualizaciones y parches a dependencias críticas? | Si, un % menor | 0.2 | 0.2 | |
| ¿Los proyectos aprovechan la automatización para comprobar el estado de las aplicaciones y del entorno? | Si, un % menor | 0.2 | | |
EH3 | ¿Las partes interesadas conocen las opciones de herramientas adicionales para proteger el software mientras se ejecuta en las operaciones? | Si, existe un estándar. | 0.5 | 0.750 | |
| ¿Existe una línea base de seguridad mínima para el estado del entorno (control de versiones, aplicación de revisiones, etc.)? | Si, anualmente | 1 | | |
| | | | | |
Caso Práctico
OP | Fortalecimiento del Ambiente | Respuestas | Peso | Prom | Rating |
OE1 | ¿Se entregan notas de seguridad con cada versión de software? | Si, un % menor | 0.2 | 0,2 | 1,55 |
| ¿Se documentan las alertas relacionadas con la seguridad y las condiciones de error por proyecto? | Si, un % menor | 0.2 | | |
OE2 | ¿Los proyectos utilizan un proceso de gestión del cambio que se entiende bien? | Si | 1 | 0,6 | |
| ¿Los equipos de proyecto ofrecen una guía de seguridad operativa con cada lanzamiento de producto? | Si, un % menor | 0.2 | | |
OE3 | ¿Se auditan las versiones del proyecto para obtener información de seguridad operativa adecuada? | Si | 0.5 | 0.750 | |
| ¿La firma de código se realiza rutinariamente en componentes de software mediante un proceso coherente? | Si | 1 | | |
| | | | | |
Caso Práctico
Caso Práctico
Roadmap para Procesos Relacionados con GOBIERNO
Caso Práctico
Roadmap para Procesos Relacionados con GOBIERNO
Caso Práctico
Roadmap para Procesos Relacionados con OPERACIONES
Caso Práctico
Roadmap para Procesos Relacionados con OPERACIONES
Caso Práctico
Recomendaciones en base a Roadmap obtenido
Que alcanzaron el NIVEL de Madurez 1, se recomienda comenzar a trabajar en llevarlas al NIVEL de Madurez 2.
Caso Práctico
OWASP SAMM 2.0 - Estructura
OWASP SAMM 2.0
PCI SLC & SAMM
PCI Secure Software LifeCycle. | OWASP SAMM |
Gobierno de Seguridad del Software. OC1- Responsabilidad y Recursos de Seguridad. OC2 – Política y Estrategia de Seguridad del Software. | Gobierno |
Ingeniería de Software Seguro. OC3 – Identificación y Mitigación de Amenazas. OC4 – Detección y Mitigación de las Vulnerabilidades. | Construcción/Evaluación de Amenazas Operaciones/Gestión de Incidentes |
Software Seguro y Gestión del Dato. OC5 – Gestión del Cambio. OC6 – Protección de la Integridad del Software. OC7 – Protección de Datos Confidenciales. | Operaciones/Gestión de Incidentes Gobierno |
Comunicaciones de Seguridad. OC8 – Guía de Implementación del Proveedor del Software. OC9 – Comunicaciones con las partes interesadas. OC10 – Información sobre la Actualización del Software. | Operaciones Operaciones/Gestión de Incidentes Gobierno |
Principales Cambios:
OWASP SAMM 2.0
Gestión de Operaciones.
Habilitación Operativa
eliminada.
Principales Cambios:
OWASP SAMM 2.0
Principales Cambios:
OWASP SAMM 2.0
Principales Cambios:
OWASP SAMM 2.0
Principales Cambios:
OWASP SAMM 2.0
Muchas Gracias!!!