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.