Mostrando entradas con la etiqueta ISO 15408. Mostrar todas las entradas
Mostrando entradas con la etiqueta ISO 15408. Mostrar todas las entradas
miércoles, 29 de abril de 2009 3 comentarios

ISO 15408 y el DNI-e, PP para el desarrollo de aplicaciones (Parte I)

Hoy me voy a extender algo más de lo habitual pero el tema lo merece y lo tenía pendiente hace algún tiempo. Mucho se habla de nuestro magnífico DNI-e y hemos de estar orgullosos en parte por disponer de un mecanismo nacional de identificación. Sin embargo, este mecanismo técnico no es infalible y hemos de entender todas las piezas que interactuan en su uso para entender la importancia del anuncio del INTECO.
Cuando pasamos a hablar de la seguridad en productos software o hardware la norma de referencia es ISO 15408 más conocida como "Common Criteria". Y este post va de eso, voy a tratar de explicar de que va esta norma y de la importancia que tiene el hecho de que el INTECO lleve un año haciendo el esfuerzo de traducir unos perfiles de protección(PP que luego explicaré que és) para nuestro DNI-e. En esta Parte I me centraré en explicar la relevancia para la seguridad de ISO 15408 y en el siguiente qué significa esto del PP para el DNI-e.

¿Qué viene a solucionar ISO 15408?
Muchos sistemas y productos de Tecnologías de la Información (en adelante, productos y sistemas IT) están diseñados para satisfacer y realizar tareas específicas y puede ocurrir, normalmente por razones económicas, que determinados aspectos de seguridad se encuentren delegados en funciones de seguridad de otros productos o sistemas de propósito general sobre los cuales ellos trabajan como pueden ser sistemas operativos, componentes software de propósito específico o plataformas hardware. Por tanto, las medidas de salvaguarda dependen del correcto diseño y funcionamiento de los servicios de seguridad que implementan otros sistemas o productos IT más genéricos. Sería deseable por tanto, que éstos estuvieran sometidos a evaluación para conocer en que medida nos ofrecen garantías y podemos depositar confianza en ellos.
También muchos clientes y consumidores de sistemas y productos IT carecen de los conocimientos necesarios o recursos suficientes para juzgar por ellos mismos si la confianza que depositan en estos sistemas o productos IT es adecuada y desearían no obtener esa certeza solamente en base a la información que proporcionan los fabricantes o las especificaciones de los desarrolladores.

¿Qué es ISO 15408?
La norma ISO/IEC 15408 define un criterio estándar a usar como base para la evaluación de las propiedades y características de seguridad de determinado producto o sistema IT. Ello permite la equiparación entre los resultados de diferentes e independientes evaluaciones, al proporcionar un marco común con el que determinar los niveles de seguridad y confianza que implementa un determinado producto en base al conjunto de requisitos de seguridad y garantía que satisface respecto a esta norma obteniendo de esa forma una certificación oficial de nivel de seguridad que satisface.
Por tanto, la norma ISO/IEC 15408 proporciona una guía muy útil a diferentes perfiles relacionados con las tecnologías de la seguridad
  • Por un lado, desarrolladores de productos o sistemas de tecnologías de la información, que pueden ajustar sus diseños.

  • Por otro lado, consumidores que pueden conocer el nivel de confianza y seguridad que los productos de tecnologías de la información y sistemas le ofrecen.

  • En último lugar, los evaluadores de seguridad, que juzgan y certifican en que medida se ajusta una especificación de un producto o sistema IT a los requisitos de seguridad deseados.



¿Cómo se organiza ISO 15408?
Los Criterios Comunes (por no llamarla ISO 15408) establecen unos criterios de evaluación basados en un análisis riguroso del producto o sistema IT a evaluar y los requisitos que este satisface. Para ello, establece una clasificación jerárquica de los requisitos de seguridad. Se determinan diferentes tipos de agrupaciones de los requisitos siendo sus principales tipos los que vemos a continuación:

  • Clase: Conjunto de familias comparten un mismo objetivo de seguridad.

  • Familia: un grupo de componentes que comparten objetivos de seguridad pero con diferente énfasis o rigor.

  • Componente: un pequeño grupo de requisitos muy específicos y detallados. Es el menor elemento seleccionable para incluir en los documentos de perfiles de protección (PP) y especificación de objetivos de seguridad (ST).


Veamos con un ejemplo como se clasifica de esta forma, requisitos de seguridad relacionados con la autenticación.
  • Clase: Identificación y autenticación

  • Familias de la clase:
    - Fallos de autenticación
    - Definición de atributos de usuario
    - Autenticación de usuario
    - Identificación de usuario

  • Componentes de la familia Autenticación de usuario
    - Tiempo de espera para la autenticación
    - Acciones antes de autenticar
    - Mecanismos de autenticación simple
    - Mecanismos de autenticación múltiple


La norma ISO/IEC 15408 se presenta como un conjunto de tres partes diferentes pero relacionadas. A continuación, describimos cada una de ellas:

Parte 1. Introducción y modelo general.
Define los principios y conceptos generales de la evaluación de la seguridad en tecnologías de la información y presenta el modelo general de evaluación. También establece cómo se pueden realizar especificaciones formales de sistemas o productos IT atendiendo a los aspectos de seguridad de la información y su tratamiento.
- Protection Profile (PP): una conjunto de requisitos funcionales y de garantías independientes de implementación dirigidos a identificar un conjunto determinado de objetivos de seguridad en un determinado dominio. Especifica de forma general que se desea y necesita respecto a la seguridad de un determinado dominio de seguridad. Ejemplos podrían ser PP sobre firewalls, PP sobre control de acceso, etc.

- Security Target (ST): un conjunto de requisitos funcionales y de garantías usado como especificaciones de seguridad de un producto o sistema concreto. Especifica que requisitos de seguridad proporciona o satisface un producto o sistema, ya basados en su implementación. Ejemplos podrían ser ST para Oracle v.7, ST para CheckPoint Firewall-1 etc.

Parte 2. Requisitos Funcionales de Seguridad
Este tipo de requisitos definen un comportamiento deseado en materia de seguridad de un determinado producto o sistema IT y se agrupa en clases. Contiene las siguientes clases:
    FAU- Auditoria
    FCO- Comunicaciones
    FCS- Soporte criptográfico
    FDP- Protección de datos de usuario
    FIA- Identificación y autenticación de usuario
    FMT- Gestión de la seguridad
    FPR- Privacidad
    FPT- Protección de las funciones de seguridad del objetivo a evaluar
    FRU- Utilización de recursos
    FTA- Acceso al objetivo de evaluación
    FTP- Canales seguros


Parte 3. Requisitos de Garantías de Seguridad
Este tipo de requisitos establecen los niveles de confianza que ofrecen funciones de seguridad del producto o sistema. Trata de evaluar que garantías proporciona el producto o sistema en base a los requisitos que se satisfacen a lo largo del ciclo de vida del producto o sistema. Contiene las siguientes clases:

    ACM- Gestión de la configuración
    ADO- Operación y entrega
    ADV- Desarrollo
    AGD- Documentación y guías
    ALC- Ciclo de vida
    ATE- Prueba
    AVA- Evaluación de vulnerabilidades
    APE- Evaluación de perfiles de protección (PP)
    ASE- Evaluación de objetivos de seguridad (ST)
    AMA- Mantenimiento de garantías


¿Qué se certifica con ISO 15408?
En este sentido, los Common Criteria o ISO/IEC 15408, proporcionan también unos niveles de garantía (EAL) como resultado final de la evaluación. Estos consisten en agrupaciones de requisitos vistos anteriormente en un paquete, de forma que obtener cierto nivel de garantía equivale a satisfacer por parte del objeto de evaluación ciertos paquetes de requisitos. Todo proceso de evaluación comienza con la definición del objeto a evaluar, que definimos a continuación:
  • Target of Security (TOE): Documento que realiza una descripción del producto o sistema que se va a evaluar, determinando los recursos y dispositivos que utiliza, la documentación que proporciona y el entorno en el que trabaja.




El principal objetivo de la norma ISO/IEC 15408, como hemos visto, es establecer de forma estándar un criterio de evaluación de la seguridad de los productos y sistemas IT. Ya hemos visto como la medición se realiza en base a un conjunto de requisitos y la demostración de que éstos son satisfechos. Esta norma nos proporciona dos tipos diferentes de evaluación.
  • Evaluación de Perfiles de Protección (PP)

  • El objetivo de tal evaluación es demostrar que un PP es completo, consistente y técnicamente sólido. Podrá ser utilizado como base para establecer requisitos destinados a definir un objetivo de seguridad (ST). Herramienta útil ya que permite definir especificaciones de seguridad independientes de implementación, que pueden ser utilizadas como base de especificaciones para productos o sistemas.

  • Evaluación de Objetivos de Evaluación (TOE)

  • Utilizando un objetivo de seguridad (ST) previamente evaluado como base, el objetivo de la evaluación es demostrar que todos los requisitos establecidos en el ST se encuentran implementados en el producto o sistema IT.


Respecto a los niveles de seguridad que se pueden lograr, voy a tratar resumidamente de describir cada uno de ellos a continuación.
EAL 1. Functionally tested
Proporciona un nivel básico de seguridad realizado a través del análisis de las funciones de seguridad usando especificaciones informales de aspectos funcionales, de interfaz y las guías y documentación del producto o sistema IT para entender el comportamiento de seguridad.
Es aplicable cuando se requiere confianza en la correcta operación pero las amenazas de seguridad no se contemplan como un peligro serio. Este tipo de evaluación proporciona evidencias de que las funciones de seguridad del TOE se encuentran implementadas de forma consistente con su documentación y proporcionan una protección adecuada contra las amenazas identificadas.

EAL 2. Structurally tested
Exige, además de los requisitos del nivel anterior, haber realizado una descripción informal del diseño detallado, haber realizado pruebas en el desarrollo en base a las especificaciones funcionales , una confirmación independiente de esas pruebas, un análisis de la fuerza de las funciones de seguridad implementadas y evidencias de que el desarrollo ha verificado la respuesta del producto o sistema IT a las vulnerabilidades mas comunes. Requiere de la cooperación del equipo de desarrollo que entregue información obre el diseño y resultados de pruebas. Este tipo de evaluación es adecuado en circunstancias en donde desarrolladores o usuarios requieren cierto nivel de garantías de seguridad cuando no tienen acceso a toda la documentación generada en la fase de desarrollo.

EAL 3. Methodically tested and checked
Este nivel establece unos requisitos que obligan en la fase de diseño a un desarrollo metódico determinando. Este nivel añade a los requisitos del nivel anterior, el uso de controles de seguridad en los procesos de desarrollo que garantizan que el producto no ha sido manipulado durante su desarrollo. Por tanto, se realiza un análisis de las funciones de seguridad, en base a las especificaciones funcional de alto nivel, la documentación, guías del producto y los test obtenidos en la fase de prueba.

EAL 4. Methodically designed, tested and reviewed
Requiere, además de los requisitos del nivel anterior, un análisis de vulnerabilidad independiente que demuestre resistencia a intrusos con bajo potencial de ataque y una especificación de bajo nivel del diseño de la implementación

EAL 5. Semiformally designed and tested
Representa un cambio significativo respecto al nivel anterior puesto que requiere de descripciones semiformales del diseño y la arquitectura además de completa documentación de la implementación. Además se realiza un completo análisis de vulnerabilidad que pruebe la resistencia frente atacantes de potencial medio y mejora los mecanismos de control para garantizar y demostrar que el producto no es manipulado con respecto a las especificaciones durante el desarrollo.

EAL 6. Semiformally verified design and tested
Añade respecto a los requisitos del nivel anterior, un detallado análisis de las funciones de seguridad, una representación estructurada de su implementación y semiformal demostración de la correspondencia entre las especificaciones de alto y bajo nivel con la implementación. Además debe demostrarse con un análisis de vulnerabilidades independiente, que en el desarrollo se ha probado la robustez de las funciones de seguridad frente a atacantes de alto potencial de daño.

EAL 7. Formally verified design and tested
Es el nivel de certificación más alto. Debe probarse formalmente las fases de desarrollo y prueba. Además se exige una evaluación independiente de la confirmación de los resultados obtenidos, de las pruebas para detectar vulnerabilidades durante la fase de desarrollo así como sobre la robustez de las funciones de evaluación. Además, deberá realizarse un análisis independiente de vulnerabilidades para demostrar resistencia frente a un atacante de alto potencial.

¿Qué beneficios va a proporcionar ISO 15408?
    La aparición de la norma ISO/IEC 15408 proporciona un criterio internacional que permite evaluar bajo criterios rigurosos y estrictos que protecciones en materia de seguridad nos proporciona un determinado producto o sistema IT. Los acuerdos firmados por diferentes países, permiten el reconocimiento mutuo de certificaciones realizadas en los diferentes organismos de certificación reconocidos internacionalmente. Ello facilita que los principales fabricantes de software estén evaluando sus productos para proporcionar “valor añadido” en la confianza y seguridad que en ellos se puede depositar.
    Estos niveles de certificación serán mínimos exigibles para la selección y adquisición de software. Por otro lado, la aparición de diferentes perfiles de protección para diversos entornos de seguridad proporcionará conjuntos de especificaciones técnicas que se incorporarán a futuros desarrollos, proporcionando requisitos de seguridad establecidos ya en las fases de diseño de productos y sistemas IT. Todo ello contribuirá, seguramente, al incremento de la calidad y seguridad de los diferentes productos y sistemas IT, y por tanto, de la confianza que podrá depositarse en ellos.


Nota: Este post es un extracto del artículo que publiqué en el número 46 de la revista SIC del Año 2001 aunque creo que sigue técnicamente actualizado.
martes, 18 de noviembre de 2008 0 comentarios

El ciclo de desarrollo seguro del software (SDLC)

Desde hace unos días y con lo agitado del mundillo informático por el tema de mañana, la manifestación 19-N, parece que está llegando el momento de "tirar de la manta" y destapar los trapos sucios que deja la industria del software y su ausencia de regulación.

No quiero defender en ningún momento la "titulitis", pero hay una evidencia clara que todos los días pagamos caro, el software es inseguro. No voy a entrar en profundizar mucho sobre las causas dado que otros blogs amigos ya lo han hecho con gran calidad (Security at Work) y profundidad (Hispasec).

Mi aportación viene más a contar la R-(evolución) de Microsoft en este tema. Ni que decir tiene que saben de lo que hablan. Han pasado de conocerse a sí mismos a intentar conocer a su enemigo (siguiendo la filosofía de Sun Tzu). Y ahora, fruto de ese esfuerzo y de la madurez de su estrategia para robustecer el software, van a la raíz del asunto: las metodologías del desarrollo software.

Esta r-(evolución) no es nueva: lleva ya algunos años en marcha y Vista creo que es el primer producto con este enfoque desde su nacimiento. Pero no contentos con eso, explican al resto cómo deben hacerse las cosas.
Para quien no tenga claro de que va esto, recomiendo ver este video What is Microsoft Application Threat Modeling?
Los resultados de este proceso son un conjunto de requisitos de seguridad necesarios para lograr que la aplicación sea robusta. En este video se pueden consultar los resultados de usar esta herramienta.

Como habréis podido observar quienes hayáis visto los videos, ¡Esto sí es SEGURIDAD en el DISEÑO de la solución SOFTWARE!.

Para quien tenga más hambre de conocimientos, puede saciar su sed en Microsoft Application Threat Modeling. También es destacable que todo este material es de acceso libre y que no cabe duda que es una gran contribución al mundo de la Ingeniería del Software.
La herramienta puede ser descargada en Microsoft Threat Analysis & Modeling v2.1.2
jueves, 4 de octubre de 2007 0 comentarios

Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información.

Leo vía Sociedad de la Información la publicación en el BOE de la Orden PRE/2740/2007, de 19 de septiembre, por la que se aprueba el Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información.
Algunos os preguntaréis, ¿dónde encaja esto? o ¿qué parte de la confianza en las tecnologías construye?. En este post, voy a tratar de explicar qué sentido tiene este reglamento y en qué estándares se basa.
Por hacer algo de historia, en mis comienzos en esto de la seguridad cuando trabajaba en Madrid tuve oportunidad de publicar en el número 46 de septiembre del 2001 de la Revista SIC un extenso artículo al respecto de los conocidos como "Common Criteria" o ISO 15408. En este artículo se detalla la estructura de la norma y qué tipo de certificación se obtiene al aplicarla sobre un producto o sistema TI.

Para garantizar la seguridad de la información es necesario poder garantizar también la seguridad de los productos TI que forman parte de un sistema. Pongo un ejemplo que se entenderá fácil. En la problemática de la firma electrónica, es necesario demostrar que los dispositivos utilizados durante el proceso de firma no son vulnerables y garantizan la fiabilidad de las operaciones de firma al utilizar el lector de tarjeta electrónica, la propia tarjeta inteligente o criptográfica, el sistema operativo que realiza las operaciones, etc. Por tanto, vemos que la confianza del proceso de firma, se basa en parte en la suma de la confianza que nos proporcionan cada una de las piezas tecnológicas que participan de ese proceso. De hecho, en la Ley 59/2003 de firma electrónica, se establece como definición de firma electrónica reconocida a aquella firma electrónica avanzada almacenada sobre un dispositivo seguro.
Para esta finalidad de certificar productos TI se utiliza por tanto la norma ISO 15408 conocida como "Common Criteria" que permite en un laboratorio verificar los requisitos de seguridad que un dispositivo presenta. Estos requisitos a su vez pueden ser de dos clases:
- Requisitos funcionales: lo que el aparato hace o garantiza.
- Requisitos de garantías: lo que el aparato bajo ningún concepto realizará.
Toda esta documentación sobre qué requisitos tiene un equipo y cómo se configura para obtener la certificación es pública y se encuentra en la página de Common Criteria. Podéis ver la cantidad de dispositivos certificados que existen actualmente y la documentación respecto al proceso de certificación en la dirección Lista de productos certificados.

Como ejemplo familiar podéis ver el resultado de la evaluación de nuestro DNI-Electrónico.
Los productos certificados suelen tener dos documentos: el Security Target que es lo que se va a tratar de evaluar en el producto que en el caso del DNI-e puede leerse en ST-DNI-e y el resultado de la certificación que se puede leer en este
enlace.

Todas estas regulaciones aparecen en la Web del Consejo Superior de Informática, dependiente del Ministerio de Administraciones Públicas. Para quien quiera ubicarse ante tanta normativa, puede consultar la siguiente dirección.

Por tanto, ha sido necesario establecer dentro del marco jurídico español un esquema de certificación y su correspondiente rglamento para poder definir qué requisitos tienen que cumplir los organismos certificadores españoles de productos TI y que normas y metodologías deben usar, ya sean públicos o privados. Precísamente este es el objeto del decreto publicado donde se define el "Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información". España tiene firmado un acuerdo con otros países para reconocer los certificados expedidos por laboratorios extranjeros, dado que hasta hace poco no contabamos con un organismo de certificación propio. Ahora ya tenemos en España nuestro Centro Criptológico Nacional como el Organismo de Certificación (OC) del Esquema Nacional de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información (ENECSTI), según lo dispuesto respectivamente en la Ley 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia, y el Real Decreto 421/2004, de 12 de marzo, por el que se regula el Centro Criptológico Nacional que ha sido el organismo que ha certificado el DNI electrónico.
 
;