Software Assurance Maturity Model

Slides:



Advertisements
Presentaciones similares
Microsoft Solution Framework v.4 Agile (MSF)
Advertisements

Metodologías ágiles.
CERTIFICACION ISO 9000, ,12207 Y MODELO CMM
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
CALIDAD EN DESARROLLO DE SOFTWARE
¿ PREGUNTAS DE NUESTRO TEMARIO ?. 1.- ¿ ES NECESARIO ESTAR CERTIFICADO EN ALGUNA NORMA O MODELO ?
DISEÑO ORIENTADO AL OBJETO
Seguridad en el Ciclo de Vida de Desarrollo
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
PMO Vicepresidencia TyO _Servicios PMO
Equipo 11 -Enríquez Chávez Jocelyn -Martínez Arvallo Diana Berenice
Rojas Figueroa, Erick.. Inicios 1998 con la creación ISACA en donde se centró en la gestión pública, ayudando a mejorar el desempeño de TI y conformidad.
“8 Principios de la Gestión Administrativa”
Modelos de Proceso del Software
Fases para el desarrollo de un proyecto Web
Evaluación de Productos
SOLUCIÓN DE PROBLEMAS Y TOMA DE DECISIONES
INSTITUTO TECNOLÓGICO SUPERIO DE LIBRES
Gestión de proyectos Resumen de escenario
Gung Ho! Gung Ho! Gestión de los Stakeholders
 Tema del proyecto  Integrantes y roles del equipo  Objetivos del proyecto  Alcance.
Evaluación de sistemas de cómputo
Técnicas para la obtención de requerimientos
Joselín González Bermúdez
Modelo de cambio para la reforma del Sector de Educación.
Modelo de Capacidad y Madurez
Por favor dar doble Click al siguiente Video
REQUERIMIENTOS DE SOFTWARE
Unidad VI Documentación
Business in Action Solutions SL | Paseo de la Castellana, 115 | Madrid | Tel: | |
Procedimiento para el establecimiento de indicadores de gestión
COBIT 4.1 SISTESEG.
DBAccess Aliado Estratégico de TI.
Universidad Simón Bolívar Cátedra: Administración de materiales
Ingeniería de Requerimiento
Plan de Sistemas de Información (PSI)
Ximena Romano – Doris Correa
Niveles de medición e impacto de funciones de recursos humanos
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
CRM Customer Relationship Management Gerente de Relaciones con los Clientes.
Desarrollo de Software Orientado a Objetos (deficiencias)
Metodologías Lsi. Katia Tapia A., Mae.
Roles de Open UP.
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Conceptos sobre GESTIÓN DE PROYECTOS
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
INGENIERIA DEL CONOCIMIENTO Toribio Sarmiento Miguel Sesarego Cruz Rosmery.
Administración Integral del Proyecto
Proyecto Master - Alberto Salgado - (C) Creative Commons V3.0 Master en Dirección y Gestión de las TIC Proyecto DETI Marco de trabajo para la evaluación.
Estructurar tus ideas para hacerlas realidad
Ciclo de Vida del Software
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
Consultoría de Análisis de Negocio para Osinergmin
Proceso de desarrollo de Software
QUÉ ES ITIl? (Information technology infrastucture library)
SOLUCIONES EMPRESARIALES
Métodos instruccionales
Especialización en Gestión de Proyectos
HABILIDADES DEL SIGLO XXI
Modelo de procesos de software
Planificación de Sistemas de Información
Marco Integrado de Control Interno, con enfoque COSO III, 2013
CICLO DE VIDA DE UN SOFTWARE. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que forman parte de.
PRÁCTICA TRADOS Gestión de Proyectos. Objetivo Esta práctica tiene como objetivo: – Crear un proyecto. – Aprender a gestionar un paquete de proyecto.
Experiencia de México Taller sobre TIC y Compras Públicas.
Consejo Superior de la Judicatura Sala Administrativa XVIII Edición: “Seguridad Jurídica, Cultura de Paz y Desarrollo Social" Modelo litigio en línea o.
Sistemas de calidad en el desarrollo de software.
Junio, 2013.
Transcripción de la presentación:

Software Assurance Maturity Model http://www.opensamm.org Pravir Chandra OpenSAMM Project Lead chandra@owasp.org Traducido al Castellano por jcrespo@germinus.com

Agenda Revisión de las iniciativas existentes para considerar la seguridad en el ciclo de vida de desarrollo1 seguro Entendiendo el modelo Aplicando el modelo Examinando los niveles y acciones del modelo SAMM y el mundo real [1] Ciclo de vida de desarrollo (Software Development LiveCycle – SDLC)

Al final, será capaz de… Evaluar las prácticas de seguridad existentes en una organización. Construir un plan de garantía de calidad del software equilibrado en etapas bien definidas. Demostrar las mejoras concretas del plan de calidad en la seguridad. Definir y medir actividades relacionadas con la seguridad en el conjunto de la Organización.

Revisión de iniciativas existentes para un ciclo de vida de desarrollo seguro

CLASP Comprehensive, Lightweight Application Security Process Centrado en 7 buenas prácticas de desarrollo de aplicaciones seguras Cubre al completo el ciclo de vida del software (no únicamente la fase de desarrollo) Adaptable a cualquier proceso de desarrollo Define roles en todo el SDLC 24 procesos basados en definición de roles Comienzo simple y adaptación según necesidades

Microsoft SDL Construido internamente para software MS Extendido y hecho público para otros Sólo para versiones MS

Touchpoints El modelo de Gary McGraw y Cigital

[2] ISV: Independient Software Vendors Lecciones aprendidas Microsoft SDL Muy pesado, bueno para grandes ISVs2 Touchpoints De alto nivel, no es lo suficientemente detallado desde un punto de vista operativo CLASP Amplia colección de actividades, pero sin asignación de prioridades TODOS: Buenos para que expertos puedan usarlos como referencia, pero complicado para que gente sin conocimientos de seguridad lo usen como guía [2] ISV: Independient Software Vendors

Premisas para un Modelo de Madurez El entorno de una organización cambia lentamente en el tiempo. Los cambios deben ser secuenciales persiguiendo un objetivo concreto a largo plazo No hay una única solución que funcione para todas las organizaciones Una solución debe permitir elegir entre opciones que consideren el riesgo adaptado a la organización La orientación de las actividades relacionadas con la seguridad deben ser presciptivas Un solución debe proporcionar los detalles suficientes para su comprensión por personas que no formen parte del equipo de seguridad. Sobre todo, debe ser sencillo, bien definido y medible.

Así pues, un modelo viable debe... Definir los componentes básicos de un proceso de calidad Diseñar todas las funciones con una estructura organizativa que pueda ser mejorada con el tiempo Definir cómo deben relacionarse los componentes básicos Hacer que los cambios en cada iteración sean asimilabes sin esfuerzo Definir los detalles de cada componente básico claramente Aclarar las partes relevantes para la seguridad de la manera más genérica posible (para cualquier empresa que realice desarrollo de software)

Entendiendo el modelo

SAMM Business Functions Se comienza con el núcleo de actividades presentes en cualquier organización que realiza desarrollo software El nombre asignado es genérico, pero deberían ser identificables por cualquier desarrollador o gestor

SAMM Security Practices Por cada una de las funciones de negocio (Bussiness Functions) se definen 3 Prácticas de Seguridad (‘Security Practices’). Las ‘Security Practices’ cubren todas las áreas relevantes para la calidad de la seguridad en el software. Cada una de ellas en un ‘nicho’ de mejora

Por debajo de cada Security Practice Tres objetivos secuenciales para cada ‘Security Practice’ definen cómo ir mejorando a lo largo del tiempo. Esto establece el concepto de ‘Nivel’ en el que una organización se encuentra al cumplir una determinada ‘Práctica’ Los tres niveles para cada ‘Práctica’ corresponden generalmente a : (0: Punto de partida implicito cuando la Práctica es incumplida) 1: Comprensión inicial y disposición específica para adoptar la ‘Practica’ 2: Incrementar la eficacia y/o eficiencia de la ‘Práctica’ 3: Dominio completo de la ‘Práctica’

Un ejemplo...

Por cada Nivel, SAMM define... Objetivo Actividades Resultados Umbrales de satisfacción Coste Personal Niveles relacionados

Acercamiento a la mejora iterativa Dado que cada una de las 12 ‘Prácticas’ es un área de madurez, los objetivos sucesivos representan los componentes básicos para cualquier programa de mejora de la seguridad en el desarrollo. En pocas palabras, la idea es definir un plan de mejora de la seguridad en el desarrollo de la siguiente forma: Seleccionar ‘Prácticas’ de seguridad a potenciar en la siguiente fase del plan de mejora. Logar el siguiente ‘Objetivo’ en cada ‘Practica’ mediante la realización de las ‘Actividades’ asociadas a los ‘Umbrales de Satisfacción’

Aplicando el modelo

Realización de Evaluaciones SAMM incluye documentos de evaluación para cada ‘Práctica’ de seguridad

Proceso de Evaluación Se permite tanto evaluaciones superficiales como detalladas Es posible que las organizaciones se encuentren en niveles intermedios (+)

Creación de Cuadros de Mando (ScoreCard) Análisis de gap Capturando las puntuaciones de evaluaciones detalladas versus niveles de rendimiento esperados. Seguimiento de mejoras Comparando las puntuaciones acumuladas de antes y despues de una iteración del programa de mejora Medida contínua Capturando puntuaciones en períodos de tiempo constantes para planes de mejora que ya estén en marcha

Plantillas de Planes de Mejora (Roadmap) Para hacer los “componentes básicos” del modelo utilizables, SAMM define Plantillas de Planes de mejora (Roadmaps) para diferentes Organizaciones Tipo. Desarrolladores de Software Independientes (ISVs) Proveedores de servicios Online (OSP) Organizaciones de servicios financieos (FSO) Administraciones Públicas (AAPP) Las Organizaciones tipo se han elegido porque: Representan los casos de uso más comunes Los riesgos típicos del software son distintos en función del tipo de organización La definición de un plan de mejor de la seguridad óptimo es diferente en cada caso.

Definición de un Programa de Mejora de la Seguridad

Casos de éxito Un tutorial completo con explicaciones concisas acerca de cómo afectan a la mejora de la organización las decisiones que se han tomadoEach Fases descritas en detalle Restricciones de la Organización La elección de construir o adquirir A día de hoy existe un caso de estudio, y hay vario en proceso a través de socios de la industria

Analizando los niveles y actividades del modelo

La versión 1.0 de SAMM

SAMM y el mundo real

Historia de SAMM Versión Beta liberada en Agosto de 2008 1.0 publicada en March 2009 Fundada originalmente po Fortify Todavía permanece involucrada activamente y haciendo uso de este modelo Publicada bajo licencia Creative Commons Attribution Share-Alike Donada al proyecto OWASP, actualmente es un proyecto propio de OWASP

Contribuciones de Expertos Definida en base a la experiencia recogida con cientos de organizaciones. Incluye expertos en seguridad, desarrolladores, arquitectos, gestores de desarrollo y gestores de Tecnologías de la Información.

Apoyo de la industria Varios casos disponibles en los siguientes referencias:

El proyecto OpenSAMM http://www.opensamm.org Dedicado a definir, mejorar y probar el marco de referencia de SAMM. Siempre tecnológicamente independiente, pero con amplia participación de la industria Abierto y conducido por la comunidad Objetivo de publicación de nuevas versiones cada 6-12 meses Proceso de gestión de cambios Propuestas de mejoras en SAMM (SAMM Enhancement Proposals - SEP)

Planes de Futuro Relacionarlo a reculaciones y estándares existentes (muchos en proceso actualmente) PCI, COBIT, ISO-17799/27002, ISM3, etc. Planes de actuación adicionales donde se identifiquen necesidades. Incorporación de casos de estudio adicionales Feedback para refinamiendo del modelo Traducciones a otros lenguajes

Otros acercamientos “modernos” Microsoft SDL Optimization Model Fortify/Cigital Building Security In Maturity Model (BSIMM)

SDL Optimization Model Hecho por MS para hacer la adpción de SDL más sencilla

BSIMM Framework derivado de la versión Beta de SAMM Basado en los datos recopliados de 9 grandes corporaciones

Repaso rápido sobre el suo de SAMM Evaluar las prácticas de seguridad en el desarrollo de software existentes en una compañía. Definir un plan adaptado de mejora en la seguridad del software basado en iteraciones bien definidas. Cuantificar mejoras concretas durante la aplicación del plan de mejora en la seguridad. Definir y medir actividades relacionadas con la seguridad en una organización.

Involúcrate!!! Utiliza SAMM y cuéntalo Blog, email, etc. Las últimas novedades en http://www.opensamm.org Inscríbete en la lista de correo

Gracias por tu tiempo! Preguntas? http://www.opensamm.org Pravir Chandra OpenSAMM Project Lead chandra@owasp.org Traducido al Castellano por jcrespo@germinus.com