Metodologías de seguridad en el desarrollo de la democracia electrónica. Javier Martín José A. Rubio

Transcripción

1 Metodologías de seguridad en el desarrollo de la democracia electrónica Javier Martín José A. Rubio

2 Índice Introducción al problema Panorama de las metodologías de seguridad OCTAVE SSE-CMM Conclusiones

3 Introducción al problema Aplicación de las nuevas tecnologías para la evolución de la democracia Proyecto TED: Towards Electronic Democracy La apuesta de la Unión Europea European Science Foundation

4 Introducción al problema Altos requerimientos de seguridad Sistema complejo Diversos módulos, programadores Cómo manejar/administrar dicha complejidad de diseño? Ingeniería del software!!!

5 Panorama de las metodologías de seguridad Diversas metodologías de gestión de la seguridad Tratan con diversos aspectos Diseño Implementación Monitoreo

6 Panorama de las metodologías de seguridad Hemos de poder asegurar diferentes niveles de Confidencialidad Integridad Disponibilidad

7 Panorama de las metodologías de seguridad Common Criteria (ISO-IEC-15408) Certificado de seguridad internacional Especifica los requerimientos de seguridad a cumplir para cumplir con un determinado nivel de seguridad Empieza a ser un requisito para concurrir a concursos internacionales Checklist con multitud de preguntas

8 Panorama de las metodologías de seguridad TCSEC (Trusted Computer Security Evaluation Criteria) Definido por el Departamento de Defensa de EEUU Se centra en el sistema operativo y bases de datos Define siete conjuntos de criterios de evaluación: D, C1, C2, B1, B2, B3 y A1

9 Panorama de las metodologías de seguridad TQM (Total Quality Management) La calidad de los sistemas puede y debe ser administrada De igual forma, el nivel de seguridad puede ser cuantificado Uso de métodos estadísticos

10 OCTAVE OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) Organizado en tres fases Métodos de mejora y planificación estratégica basadas en el riesgo para la seguridad Hay métodos para organizaciones/sistemas grandes y pequeños

11 OCTAVE Fase 1: Desarrollar una lista de elementos a proteger y ataques que los afectan Hemos de determinar cuales son nuestros recursos más importantes Hemos de estudiar la forma en que estos recursos se pueden ver afectados

12 OCTAVE Fase 2: Identificar los puntos vulnerables en la infraestructura Identificar los puntos por los cuales se podrían producir acciones no autorizadas en el sistema A nivel de red, arquitectura, sistema operativo y aplicaciones

13 OCTAVE Fase 3: Desarrollo de planes y estrategias de seguridad Analizar los riesgos que pueden afectar a los elementos críticos de nuestro sistema Decidir como protegernos de dichos riesgos

14 OCTAVE Sirve para evaluar toda la infraestructura: desde el software al hardware Uso de procedimientos como Escaneo de vulnerabilidades conocidas Verificación y pruebas de penetración en el sistema Verificación de la evolución de la seguridad del sistema

15 Proceso de desarrollo con el modelo CMM Objetivo Presentar la adecuación de las técnicas y métodos de UML (Unified Modeling Language) al proceso de mejora de una organización, tomando como modelo el CMM (Capability Maturity Model)

16 Proceso de desarrollo con UML y el modelo CMM Modelo CMM Áreas Claves del Proceso (KPA) en un Proyecto de Desarrollo Software.

17 Proceso de desarrollo con el modelo CMM Modelo CMM: Objetivos Objetivo 1: Determinar el nivel de madurez del Proceso de Desarrollo que permita establecer un indicador de Calidad del proceso. -> 5 Niveles de Madurez Objetivo 2: Servir de guía en el Proceso de Desarrollo permitiendo la Mejora Continua de la organización -> Control de Procesos

18 Proceso de desarrollo con el modelo CMM N5: Optimizado N4: Gestionado Resultados cuantificados, con opción de mejora Medidas de Producto y Proceso. Registro de valores de Calidad N3: Definido N2: Repetible Desarrollo y Mantenimiento documentado y Estandarizado Gestión del proceso seguimiento de: coste, planificación y funcionalidad N1: Inicial El éxito del proceso depende del esfuerzo individual

19 Proceso de desarrollo con el modelo CMM Claves del Proceso Objetivos Compromisos sobre distintas Unid.Negocio Capacidades organizativas y técnicas Actividades Métodos de supervisar la implantación Métodos de verificar la implantación

20 Proceso de desarrollo con el modelo CMM Proceso Desarrollo Software NIVEL 2: Repetible Gestión de Requisitos Planificación del Proyecto Seguimiento y Supervisión del Proyecto Software Gestión de Subcontratación del Software Garantía de Calidad del Software Gestión de Configuración del Software

21 Proceso de desarrollo con el modelo CMM Proceso Desarrollo Software Nivel 3: Definido Enfoque del proceso de la organización Definición del proceso de organización Programa de formación Gestión de integración del software Ingeniería de productos software Coordinación entre grupos Revisiones periódicas

22 Proceso de desarrollo con el modelo CMM Proceso Desarrollo Software Nivel 4: Gestionado Gestión cuantitativa del proceso Gestión de calidad del software Nivel 5: Optimización Prevención de defectos Gestión de la tecnología Gestión de cambios en el proceso

23 El CMM y la mejora continúa del proceso de software El CMM trata de guiar a las organizaciones en la selección de estrategias para mejorar el proceso y la calidad del software.

24 CMM El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un método de definir y gestionar los procesos a realizar por una organización. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

25 CMM DEFINICIONES Un modelo Un proceso

26 CMM El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI. Su homólogo en Europa es la Fundación ESI (European Software Institute), con sede en Bilbao (España).

27 CMM 1 El modelo CMM 2 Otros modelos CMM del SEI 3 El modelo CMMI 4 Otros modelos CMM 4.1 SSE-CMM 4.2 Capability Inmaturity Model 5 Crítica 6 Referencias 6.1 En Wikipedia 6.2 Bibliografía 6.3 Enlaces externos

28 CMM 1.- El modelo CMM A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de Este modelo establece un conjunto de prácticas o procesos clave agrupadas en Areas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser: Definidas en un procedimiento documentado Provistas (la organización) de los medios y formación necesarios Ejecutadas de un modo sistemático, universal y uniforme(institucionalizadas) Medidas Verificadas

29 CMM A su vez estas Areas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. Los niveles son: 1 - Inicial. 2 - Repetible. 3 - Definido. 4 - Gestionado. 5 - Optimizado.

30 CMM Otros modelos CMM del SEI SE-CMM El Modelo de Capacidad y Madurez en la Ingeniería de Sistemas fue publicado por el SEI en noviembre de Está dedicado a las actividades de ingeniería de sistemas. Define 18 áreas de proceso divididas en tres grupos: ❿ Ingeniería (7) ❿ Proyectos (5) ❿ Organizativas (6) No utiliza niveles de madurez generales sino que en cada área de proceso una organización puede alcanzar un determinado nivel de madurez. Al igual que el SW-CMM, ha sido integrado en el CMMI.

31 CMM IDP-CMM El Modelo de Capacidad y Madurez para el Desarrollo Integrado de Productos fue propuesto como un borrador por el SEI en 1997, pero quedó integrado en el CMMI al publicarse este en el año P-CMM Modelo de Capacidad y Madurez para Recursos Humanos SA-CMM Modelo de Capacidad y Madurez para la Adquisición de Software

32 CMM El modelo CMMI En diciembre de 2000, el SEI publicó un nuevo modelo, el CMMI o "Modelo de Capacidad y Madurez - Integración", con el objetivo de realizar algunas mejoras respecto al SW-CMM e integrarlo con el SE-CMM y el IPD-CMM, que pasaban a ser considerados como "obsoletos". El CMMI incluye cuatro disciplinas, en función de la amplitud de los procesos que cubre: ❿ CMMI-SW : Software ❿ CMMI-SE/SW : + Ingeniería de sistemas ❿ CMMI-SE/SW/IPPD : + Desarrollo integrado de procesos y productos ❿ CMMI-SE/SW/IPPD/SS : + Gestión de proveedores A su vez se presenta en dos posibles representaciones, "Por niveles" y "Continua". En el primer caso permite evaluar el nivel de madurez de una organización en todas las áreas de proceso, mientras que el segundo permite evaluar el nivel en cada área independientemente.

33 CMM Las principales diferencias con el SW-CMM, además de la inclusión de las tres nuevas disciplinas para integrar los tres modelos antiguos, son: ❿ Pone un mayor énfasis en el uso continuo de métricas ❿ Insiste en la necesidad de la trazabilidad desde los requerimientos al producto final ❿ Desglosa y detalla las áreas de proceso relativas a la ingeniería ❿ Cambia el nombre a los niveles 2 y 4 que pasan a llamarse "gestionado" y "gestionado cuantitativamente". El SEI ha desarrollado también un nuevo método de evaluación de las organizaciones según CMMI denominado SCAMPI.

34 CMM Otros modelos CMM SSE-CMM El System Security Engineering Capability Maturity Model o Modelo de Capacidad y Madurez en la Ingeniería de Seguridad de Sistemas es un modelo derivado del CMM y que describe las características esenciales de los procesos que deben existir en una organización para asegurar una buena seguridad de sistemas. Ha sido desarrollado por la "International Systems Security Engineering Association (ISSEA)", organización sin ánimo de lucro patrocinada por un buen número de compañías dedicadas a la seguridad de sistemas. Nació a partir de 1993 bajo los auspicios de la Agencia Nacional de Seguridad (NSA) de los E.U.A., con la participación de numerosas compañías de los sectores de tecnologías de la información, seguridad y defensa. La primera versión data de 1997 y la actual (v3.0) fue publicada en junio de 2003.

35 CMM Pretende servir como: ❿ Herramienta para que las organizaciones evalúen las prácticas de ingeniería de seguridad y definan mejoras a las mismas. ❿ Mecanismo estándar para que los clientes puedan evaluar la capacidad de los proveedores de ingeniería de seguridad. ❿ Base para la organización de un mecanismo de evaluación y certificación. A diferencia del CMM original, las áreas de proceso no están agrupadas en función de los niveles de madurez, sino que define 22 áreas para cada una de las cuales se puede alcanzar un nivel en función del cumplimiento de unas "características comunes". Existen 11 áreas de procesos de ingeniería y otras 11 dedicadas a la gestión de proyectos y organización. El método de evaluación se denomina SSAM (SSE-CMM Appraisal Method).

36 CMM Capability Inmaturity Model Con mucho sentido del humor, y bastante conocimiento de causa, Anthony Finkelstein describió que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se llega a producir software), proponiendo que existen niveles negativos o de inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de idiotez: 0 - Tonto. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su gran preocupación es la reutilización del software. 1 - Estúpido. Organizaciones obstructivas. Imponen procesos contraproductivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios. 2 - Lunático. Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas. Su gran objetivo es la programación automática.

37 CMM Crítica Frecuentemente se critica al modelo CMM por no ser más específico en la definición de los procesos. Para guiar a las organizaciones a definir y mejorar sus procesos indica qué actividades han de realizar, pero nada sobre cómo hacerlo. Esto es así tanto en lo referente a la ingeniería como a las herramientas o técnicas de gestión, aunque hace una curiosa excepción en las revisiones por pares (peer reviews). Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da ninguna guía concreta del tipo de métricas que son aceptables para una correcta práctica profesional. Los técnicos se quejan a menudo de la enorme carga de "papeleo" que impone el modelo, viéndolo más como un mecanismo de control por la dirección que una herramienta que les ayude en su trabajo. También resulta muy complejo, más todavía el CMMI, lo que hace que durante algún tiempo resulte para mucha gente algo esotérico.

38 Conclusiones Gran diversidad de metodologías de gestión y desarrollo de sistemas Métodos necesarios para el tratamiento de sistemas complejos Cuando el sistema alcanza cierto tamaño necesidad de formalizar su gestión y desarrollo