1. Introducción a la normalización y la certificación
La normalización se puede definir básicamente como el conjunto de actividades de coordinación de criterios, métodos de medida y límites de ensayo relativos a unas especificaciones técnicas, encaminadas a obtener un documento (norma), de carácter esencialmente técnico, en el que se respetan los puntos de vista de todas las partes interesadas, que es editado por un organismo de normalización que está a disposición del público en general. En todo este proceso intervienen diferentes partes (actores) entre los que se encuentran fundamentalmente los siguientes: - Fabricantes y suministradores
- Usuarios
- Administración
- Otros: Universidades, Organismos de Investigación, etc.
En el proceso de elaboración de una especificación técnica se trata de que participen todos los actores de una manera transparente y de que lleguen a un acuerdo, mejor si es por
consenso. Para que el trabajo tenga resultados satisfactorios es necesario que alguien gestione el desarrollo de este proceso. Ese alguien es el Organismo de Normalización.
Los Organismos de Normalización son aquellas entidades que sirven de marco para elaborar las normas, garantizando la imparcialidad del proceso de normalización, por medio de la puesta en común de los puntos de vista de todas las partes interesadas, con el fin de desarrollar y adoptar un documento (norma) por acuerdo de todas ellas.
En España el organismo oficial de normalización es AENOR, que edita las normas UNE. AENOR desarrolla estas tareas al amparo del R.D. 1614/85 y de la Orden del Ministerio de Industria y Energía de 26 de febrero de 1986.
De la estructura de AENOR forma parte el Comité Técnico de Normalización 71 (CTN/AEN 71) relativo a Tecnología de la información (TI). Este Comité es homólogo al ISO/IEC/JTC1 constituido a nivel internacional en 1987 para trabajar en la normalización en el área de las tecnologías de la información, con excepción de las relativas a aplicaciones específicas, tales como sistemas de automatización industrial, control de procesos o radiocomunicaciones. Está estructurado en los siguientes Subcomités:
- CTN 71/ SC 7 'Ingeniería de Sistemas de Información' - CTN 71/ SC 17 'Tarjetas de identificación y crédito'
- CTN 71/SC 18 'Sistemas de Textos y Oficinas'
- CTN 71/ SC 21 'Gestión, Transferencia y Recuperación de Información para Interconexión de Sistemas Abiertos (OSI)'
- CTN 71/SC 22 'Lenguajes'
- CTN 71/ SC 27 'Técnicas de Seguridad en Tecnología de la Información'
Dentro de la estructura del ISO/IEC/JTC 1 existen también otros Subcomités, aunque no están constituidos en el marco del CTN/71. Por lo tanto, el Subcomité cuyas tareas nos interesan más en el contexto de la Seguridad de los Sistemas de Información es el SC 27. En él existen los siguientes grupos de trabajo:
GT 1 'Guías, servicios y requisitos de seguridad' GT 2 'Técnicas y mecanismos de seguridad'
GT 3 'Criterios de evaluación de seguridad'
Este breve panorama sobre la organización de la normalización
quedaría incompleto si no mencionáramos el papel de SOGIS: Grupo de altos funcionarios en materia de seguridad de los sistemas de información, Comité creado por Decisión 92/242/CEE del Consejo de las Comunidades Europeas de 31 de marzo de 1992 relativa a la Seguridad de los sistemas de información. SOGIS noconstituye en sentido estricto un organismo de normalización, mas bien su misión es la de asesorar a la Comisión Europea sobre acciones en materia de seguridad de los sistemas de información. Sin embargo, su papel ha sido muy activo en este sentido, ya que el Plan de acción previsto en la Decisión 92/242/CEE incluía en la línea de actuación IV el desarrollo de las especificaciones, normalización, evaluación y certificación de la seguridad de los sistemas de información. De hecho, tal ha sido, a mi juicio, la importancia de los trabajos desarrollados por SOGIS desde su creación, que van a constituir la referencia básica del resto de mi comunicación.
En la actualidad el plazo de vigencia del plan de acción de la Decisión 92/242/CEE, que era de 24 meses, ha concluido, por lo que se está en el proceso de elaboración de una nueva Decisión que continúe el camino iniciado, la cual podría ser aprobada en el segundo semestre de este año, coincidiendo con la Presidencia española.
Pasando a la certificación, ésta se puede definir básicamente
como la acción de confirmar un hecho, en nuestro caso el que un producto o servicio es conforme con unas normas o especificaciones técnicas, reglamentos, directivas, etc., por medio de la extensión de un certificado o marca. Cuando la certificación se realiza por parte de un organismo de la
Administración, se conoce con el nombre de homologación.
En todo proceso de certificación intervienen diferentes agentes entre los que se encuentran los siguientes:
- Fabricantes y suministradores
- Administración
- Laboratorios de ensayos
- Entidades de inspección
- Organismos de certificación
Estos intervienen, en distinto número y en distintas partes del proceso de certificación, en función del procedimiento de certificación elegido.
Los Organismos de Certificación son aquellas entidades imparciales, pertenecientes o no a la Administración Pública,
que poseen la competencia y fiabilidad necesaria para hacer
funcionar un sistema de certificación y en las que están representados los intereses de todas las partes implicadas en el funcionamiento del sistema. Si la gestión del organismo es independiente de las partes interesadas, el organismo de certificación se califica de independiente. En España el organismo nacional de certificación es AENOR. Son clásicos los tres sistemas de certificación que siguen:
Certificación por primera parte: El fabricante garantiz su producto. Certificación de segunda parte: El comprador comprueba y da el visto bueno a las características del producto. Certificación de tercera parte: En este sistema la certificación se realiza por una organización independiente (tercera parte) del fabricante (primera parte) y del cliente (segunda parte), o por el sistema de certificación administrado por un Organismo de certificación.
En su actividad de certificación AENOR concede diferentes
marcas, tales como:
- la marca AENOR de Calidad N, que certifica la calidad, seguridad y aptitud de los productos de acuerdo con las normas que les corresponden. A fecha de noviembre de 1994 existían 16288 productos españoles certificados.
- la marca AENOR de Seguridad S certifica la seguridad obligatoria de determinados productos para circular por los mercados europeos, de acuerdo igualmente con las normas que les corresponden.
- la marca ER de Registro de Empresa certifica el sistema de aseguramiento de la calidad de la empresa, de acuerdo con las normas UNE 66 900 /ISO 9000. En Noviembre de 1994 existían 509 empresas españolas certificadas.
- la marca AENOR de Medio Ambiente certifica los productos que cumplen los criterios ecológicos exigidos, según normas UNE 77 801 93 y UNE 77 802 93.
2. La seguridad de los S.I. en las organizaciones
La identificación de requisitos de seguridad a partir de los propios del negocio es una tarea compleja y con frecuencia no bien entendida. El Libro Verde de la Seguridad de los Sistemas de Información (SSI) de la Comisión Europea plantea el Modelo de Seguridad orientada a la Empresa que figura en el diagrama siguiente y que a continuación se comenta. (figura 1).
La protección de los sistemas de información necesita tomar en consideración los requisitos empresariales del 'negocio'. Estos requisitos no incluyen sólo la funcionalidad 'propia' de la empresa, sino que también deben incluir requisitos inter-empresas. Debe considerar la funcionalidad y garantía de los componentes básicos de la TI, las aplicaciones de usuario final, las herramientas de integración (como el correo elec-trónico), los sistemas operativos, los servicios y protocolos de comunicación, y las plataformas finales y de 'software' básico.
El equilibrio entre funcionalidad (qué hace) y garantía (cómo lo hace, con qué calidad) determinará la extensión de la aceptación de los sistemas de información electrónica como una parte integral de la infraestructura de TI, tanto pública como corporativa, para soportar las acciones del negocio.
En lo que sigue, voy a tratar de presentar con mayor detalle las diferentes piezas del modelo propuesto. Para ello, empezaré por los OBJETIVOS de Seguridad. Un objetivo de seguridad es una descripción de la seguridad que la organización está intentando lograr. En otrs palabras, por qué se necesita tal o cual función/control de seguridad. Es una declaración del usuario o empresa que describe por qué se necesita un aspecto de seguridad. Es una meta o propósito del usuario / negocio al que se dirige la seguridad. Por ejemplo, considérese el tema de la integridad de datos y el objetivo de 'prevenir la modificación de datos no autorizada'. El objetivo de seguri-dad tiene el propósito de asegurar que existan mecanismos apropiados para preservar la integridad de datos. Estos datos pueden referirse a los almacenados en una base de datos médica, en una base de datos de un banco, en un sistema de reservas aéreas o en un sistema de información geográfica.
3. Servicios de seguridad
Dentro del Modelo de Referencia adoptado, pasamos ahora a considerar la funcionalidad de seguridad. Existe una amplia
variedad de servicios de seguridad, algunos de los que pue-den considerarse más importantes se describen brevemente a continuación.
- Servicios de no repudio:
El no repudio de origen/recepción significa que un usuario determinado, llamado el originador/receptor, no puede repudiar
(en otras palabras, negar) haber firmado/recibido un documento electrónico concreto. No sirve para probar quién fue el autor del documento. Estos servicios en el campo de la comunicación electrónica cubren las funcionalidades de la firma autógrafa, pero de una manera más segura, ya que existe una conexión lógica entre la firma digital y el mensaje.
- Autenticación:
La autenticación de origen es la contrapartida del no repudio en el sentido de que aquí la cuestión es permitir al creador probar quién creó el documento, como algo opuesto al no repudio de origen, que permite a todo el mundo probar que
alguien ha firmado un determinado documento en el que
normalmente se compromete a algo. La diferencia es que con los servicios de no repudio, el receptor es capaz de probar algo, mientras que la autenticación de origen pertenece al transmisor. También podemos considerar de manera análoga la autenticación de la entidad destino o el caso de una autenticación mutua, en el que ambas entidades comunicantes se autentican respectivamente ante la otra.
- Declaración de propiedad
Algunos documentos físicos convencionales, tales como el
'conocimiento de embarque' o la 'letra de cambio' deben ser negociables con el carácter de títulos al portador. En el campo de la comunicación electrónica se precisa tener algo equivalente. El objetivo aquí es que un documento electrónico en un momento determinado pueda probarse que es propiedad (temporal) de un usuario en concreto. La provisión de documentos electrónicos negociables debe incluir:
. Unicidad del documento: un documento debe existir sólo en un único ejemplar válido, de modo que no pueda ser vendido más de una vez por su propietario. . Autenticidad del documento: un documento debe ser inalterable, y el origen del documento debe ser identificable.
. Transferibilidad: el documento debe poder transferirse a través de redes de comunicación.
. Almacenaje y comunicación libre de fallos: la recuperación después de un fallo debe ser posible, tanto cuando el documento esté amacenado como cuando es transmitido entre dos entidades.
- Intercambio justo de valores
Cuando documentos comerciales negociables cambian de manos, a menudo se entregan a cambio de otra cosa, por ejemplo otro documento negociable, alguna forma de pago, o alguna información que pueda ser de valor suficiente para el receptor. La entidad que da el documento puede quedarse preocupada con la posibilidad de no recibir a cambio el objeto o la información acordado.
En el mundo del EDI interactivo el problema puede ser más
serio que con documentos físicos convencionales. Se puede mantener una comunicación eficaz con entidades muy alejadas y con las que apenas se ha mantenido una relación comercial previa, lo que redunda en una menor confianza que en el caso de que se produzca un encuentro físico.
- Disociación
A medida que crece el registro y la comunicación de datos,
se presentan nuevas situaciones en las que las personas ven amenazada su privacidad. En su forma más general la disociación es un servicio con el objetivo de prevenir que estos datos personales sean localizados y recogidos. La cuestión es por tanto permitir que se efectúen accesos, llamadas o transacciones sin revelar la identidad del usuario. Ejemplos prácticos se presentan en los sistemas de peaje de autopistas y en la facturación de la telefonía móvil sin revelar la historia de desplazamientos del usuario.
- Registro horario
En las comunicaciones electrónicas, se precisa un equivalente digital al sello de fecha y hora del mundo del papel. Este sello debe ser emitido por una organización que sea confiable, segura ('trusted'). Si estos registros horarios son simplemente añadidos internamente por el emisor o receptor de un mensaje, entonces en caso de litigio será difícil establecer si éstos eran erróneos o han sido falsificados.
4. Mecanismos de seguridad
Se utilizan mecanismos de seguridad para implementar un servicio o una combinación de ellos. Los mecanismos de seguridad se apoyan principalmente en técnicas criptográ-ficas y en la utilización de una Tercera Parte Confiable o Segura (TTP: Trusted Third Party), a las que voy a referirme a continuación.
- La firma digital
El Glosario de Términos de Criptografía del CESID define a
la firma digital en los términos siguientes: "Datos añadidos o transformación criptográfica de una unidad de datos que prueba al receptor de dicha información la fuente y/o integridad de los datos contra posibles falsificaciones. Es un mecanismo de seguridad, e incluye el proceso de firmado y el de verificación de la firma".
Un aspecto a destacar en esta cuestión es que las comunicaciones abiertas requieren algoritmos normalizados públicamente disponibles. Entre las características necesarias para este tipo de mecanismos de firma digital se incluyen las
siguientes:
. que sea prácticamente irrompible.
. que tenga un espacio de claves suficientemente amplio, rendimiento (requisitos detiempo y espacio para firma y verificación), tamaño de la clave razonable, etc. . que incluya generación de claves.
Durante muchos años la tecnología de clave pública propor-cionada por RSA (Rivest, Shamir, Adleman) ha constituido la referencia fundamental en el campo de la firma digital. Funciona del siguiente modo: . Se utilizan claves distintas para el cifrado y el descifrado. Tanto el origen como el receptor tienen claves públicas que son conocidas por uno y otro y claves privadas que no son conocidas por el otro. Para cifrar un mensaje, el origen lo haría usando la clave pública del receptor. Una vez cifrado, el mensaje puede ser sólo descifrado por el receptor utilizando
su clave privada.
En 1991, el Congreso de los EEUU ordenó al NIST que llevara a cabo las actuaciones pertinentes para disponer de un estándar de firma digital, que recibió el nombre de DSA (Digital Signature Algorithm), de modo que, una vez publicado este estándar, existían dos posibilidades de elección: RSA, como estándar de facto, y DSA, como estándar oficial de los EEUU. En principio la Comisión Europea acordó colaborar con el NIST para el uso y adopción de DSA en Europa, sobre la base de la disponibilidad de DSA sin pago alguno de 'royalties', pero la posterior decisión del NIST de conceder una licencia exclusiva a la empresa Public Key Partners (PKP), originó una fuerte oposición europea. Puestas así las cosas, la postura europea se decantó a favor de RSA, por su amplia disponibilidad en productos comerciales: más de tres millones de productos utilizan hoy esta tecnología, mientras que para DSA el mercado es prácticamente inexistente. De cualquier manera, en este debate todavía no se ha dicho la última palabra.
- Terceras partes confiables (TTP‘s)
Cuando un grupo de usuarios quiere comunicarse de manera
segura utilizando métodos criptográficos deben tomarse algunas medidas para distribuir y actualizar las claves necesarias. Generalmente cada usuario tiene que obtener una clave proporcionada por cada uno de los restantes usuarios con los que quiere comunicarse, con independencia del servicio que se requiera. Para un pequeño grupo de carácter estable eso puede llevarse a cabo directamente por los propios usuarios, pero cuando se trata de grupos más amplios y abiertos, el problema se complica rápidamente, de modo que es necesario hacer intervenir a una TTP.
Los servicios de una TTP pueden ser considerados como
servicios de comunicación de valor añadido disponibles para los usuarios que desean mejorar la confianza de los servicios que utilizan. Por consiguiente las TTP‘s tienen que ser capaces de ofrecer valor añadido respecto a la disponibilidad, integridad, confidencialidad y garantía. Aunque las TTP‘s se pueden establecer en un país determinado en base a su legislación propia, deben ser confiables para la comunidad internacional. Los principales servicios que una TTP puede ofrecer son los siguientes: - Asignación de nombres y direcciones a individuos y empresas. - Certificación, esto es, validación de que su nombre y dirección tiene determinadas credenciales (p.ej. una clave pública por firma).
- Gestión de claves para firma.
. Gestión de claves para confidencialidad.
- Servicios de gestión para Nombres y Credenciales. - Servicios de seguridad.
5. Evaluación de productos, sistemas, servicios y aplicaciones
En mayo de 1990 Francia, Alemania, Los Países Bajos y el Reino Unido publicaron los Information Technology Security Evaluation Criteria (ITSEC) basados en los trabajos realizados en estos países. ITSEC se ha desarrollado intensamente hasta la versión 1.2, que data de junio de 1991. Precursor de este producto fue el Trusted Computer System Evaluation Criteria, generalmente conocido por TCSEC o 'Libro Naranja', publicado inicialmente en 1983 y utilizado para la evaluación de productos por el Departamento de Defensa de los Estados Unidos. Para situar ITSEC en el contexto de la SSI hay que partir del
hecho de que la información en sistemas de TI tiene que estar protegida contra amenazas que conduzcan a daños en los activos. Estas amenazas pueden ser deliberadas (ataques) o inadvertidas (errores o fallos). Para reducir el riesgo hay que seleccionar unas contramedidas específicas, que pueden ser de naturaleza física, relativas al personal, organizativas o técnicas. Las contramedidas técnicas son las funciones y mecanismos de seguridad del propio sistema de TI (p.ej.: control de accesos, auditoría y recuperación de errores). Las restantes contramedidas, relativas a los aspectos físicos, de personal u organizativos constituyen el grupo de contramedidas no técnicas. Pues bien, la evaluación de ITSEC se refiere principalmente a contramedidas técnicas.
Luego de la publicación de ITSEC, los cuatro Estados Miembros autores de los criterios colaboraron para producir un primer borrador de una Metodología armonizada que acompañara a estos criterios. De esta manera y con el apoyo de SOGIS, surgió ITSEM, cuya versión 1.0 data de septiembre de 1993 y que se encuentra en la actualidad en período de prueba. El objetivo específico de ITSEM es asegurar que existe un conjunto armonizado de métodos de evaluación que complementa a ITSEC.
Una importante limitación a tener en cuenta en ITSEC/ITSEM es que la evaluación se refiere a la seguridad de productos de TI y (en alguna medida) de sistemas de TI. Por el momento, no cubren la evaluación de servicios y aplicaciones. Ciñéndonos al caso de los servicios de telecomunicación, la idea de proporcionar un servicio de seguridad como parte de un servicio de telecomunicación dará lugar a que todas las entidades involucradas en la provisión del servicio de telecomunicación, también tendrán que participar en la provisión del servicio de seguridad. Puede incluso que se necesiten entidades adicionales, como una TTP para gestión de claves o servicios de autenticación. Todas estas entidades utilizarán sistemas y productos para proporcionar su parte del servicio de telecomunicación/seguridad. El servicio total, por consiguiente, se proporciona a través de la interacción de todas las entidades.
El esquema que en la actualidad incluye ITSEC/ITSEM está orientado, como hemos dicho más arriba, a la evaluación técnica de productos y sistemas. No cubre medidas organizativas, de personal, administrativas o de tipo físico no relacionadas con la TI. Pero muchos servicios de seguridad en telecomunicaciones descansarán no sólo en medidas técnicas de seguridad, sino también en otros controles de los mencionados. Para ello, es claro que se precis una extensión del esquema de evaluación de ITSEC/ITSEM para cubrir estos aspectos.
Por todo esto, la integración de todas las medidas de seguridad debe verificarse a fin de garantizar su consistencia, integridad y eficacia. Si este es el caso de los servicios, la situación se agrava con las aplicaciones, cuya seguridad es el verdadero interés del usuario, dado que la utilización de productos, sistemas y servicios seguros es condición necesaria, pero no suficiente para que el usuario vea satisfechos sus requisitos de protección de la aplicación.
ITSEC e ITSEM son documentos técnicos, dirigidos funda-mentalmente a los actores que participan en una evaluación
(en primer lugar, los evaluadores, pero también los patrocinado-res y certificadores),aunque también tienen interés para suministradores, desarrolladores, acreditadores de sistemas y usuarios. Desde la perspectiva del usuario, adoptada en esta comunicación, son documentos de difícil lectura. Por ello, vamos a tratar de resumir a continuación algunos de los conceptos clave manejados.
El primero de estos conceptos es el de Objetivo de Evaluación (Target of Evaluation: TOE). Recibe este nombre un producto o sistema de TI sujeto a una evaluación de seguridad. Un TOE puede construirse a partir de varios componentes. Algunos no contribuirán a satisfacer los objetivos de seguridad del TOE; otros sí. Estos últimos se denominan ejecutores de la seguridad (security enforcing). También puede haber entre los primeros algunos componentes que, sin ser ejecutores de la seguridad, deben operar correctamente para que el TOE ejecute la seguridad; éstos reciben el nombre de relevantes para la seguridad (security relevant). La combinación de los componentes ejecutores de la seguridad y relevantes para la seguridad se denomina a menudo la Base Informática Segura (Trusted Computing Base: TCB).
Para que un TOE satisfaga sus objetivos de seguridad debe
incorporar funciones ejecutoras de la seguridad apropiadas,
cubriendo áreas tales como control de accesos, auditoría y recuperación de errores. Estas funciones deben definirse de manera clara y comprensible tanto para el patrocinador como para el evaluador independiente. Pueden especificarse individualmente o mediante referencia a unas clases de funcio-nalidad predefinidas. ITSEC incluye diez ejemplos de clases de funcionalidad, de las cuales cinco corresponden estrecha-mente con los requisitos de confidencialidad de TCSEC.
Otras clases de funcionalidad predefinidas hacen énfasis en diferentes aspectos de la seguridad. Así, la clase F-IN está orientada a TOEs con altos requisitos de integridad en programas y datos (p.ej: bases de datos); F-AV establece altos requisitos de disponibilidad, por lo que resulta de aplicación en el control de procesos de fabricación, etc.
ITSEC distingue entre la confianza en la corrección de la implantación de funciones y mecanismos ejecutores de la seguridad y confianza en su efectividad. La evaluación de efectividad establece si las funciones y mecanismos ejecutores de la seguridad proporcionadas en el TOE satisfarán los objetivos de seguridad establecidos. El TOE es evaluado en relación con su adecuación a la funcionalidad, integración de funcionalidad, consecuencias de vulnerabilidades y facilidad de uso. Además se evalúa la fortaleza de los mecanismos del TOE, de acuerdo con tres niveles: básico, medio y alto.
La evaluación de corrección se orienta a conocer si las
funciones y mecanismos ejecutores de la seguridad están
correctamente implementados. ITSEC define siete niveles de evaluación de E0 a E6, representando niveles crecientes de confianza en la corrección. E0 representa una confianza inadecuada. E1 representa un punto entrada en lo que se refiere a confianza y E6 es el nivel más alto de confianza. La corrección se contempla desde el punto de vista de construcción del TOE, considerando tanto el proceso de desarrollo como el ntorno de desarrollo, y también desde el punto de vista de la operación del TOE.
Los criterios establecidos en ITSEC permiten una selección de funciones de seguridad arbitrarias, y definen siete niveles de evaluación con una confianza creciente en la capacidad del TOE para alcanzar su objetivo de seguridad. Así, estos criterios pueden aplicarse para cubrir una gama más amplia de productos y servicios que en el caso del TCSEC.
Aunque en sentido general no se puede hablar de una relación directa entre los niveles de evaluación de ITSEC con los requisitos de confidencialidad de las clases de TCSEC, dado que ITSEC contiene unos cuantos requisitos que no aparecen explícitamente en TCSEC, en ITSEC se ha intentado establecer la siguiente correspondencia con las claves de TCSEC (Tabla 1) donde en la columna relativa a Tabla 2
ITSEC TCSEC
E0 <-> D F-C1, E1 <-> C1 F-C2, E2 <-> C2 F-B1, E3 <-> B1 F-B2, E4 <-> B2 F-B3, E5 <-> B3 F-B3, E6 <-> A1‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
TOTAL Serio Moderado Menor
ITSEC se ha situado a la izquierda de cada uno de los niveles de evaluación (E1 a E6) una clave de funcionalidad predefinida en los criterios. Así F-C1 es una clase de funcionalidad derivada de los requisitos de funcionalidad de la clase C1 de ITCSEC: proporciona control de accesos discrecional, y análogamente en los demás casos.
Es evidente que la situación de mantener criterios de evaluación
diferentes en Europa y Estados Unidos no es deseable para ninguno de los actores que participan en el proceso,
especialmente para los fabricantes que tendrán que llevar a cabo evaluaciones diferentes contra diferentes criterios y esquemas para un determinado producto. Esto aumenta innecesariamente el coste de los productos sin ninguna mejora de las características de seguridad.
Por ello, en 1993 se decidió iniciar un esfuerzo para armonizar ITSEC y los Criterios Federales con el objetivo de producir un conjunto de criterios unificados para Europa y Norteamérica compatible con las prácticas existentes en ambas regiones en 1994. En este sentido, también el GT 3 del ISO/IEC JTC 1/SC 27 está trabajando en una norma ISO de criterios de evaluación basada en ITSEC y los Criterios Federales. El primer producto de este esfuerzo conjunto es la publicación de los Common Criteria for Information Technology Security Evaluation (Preliminary Draft. Versión 0.9), de fecha 31-10-94.
La armonización de los criterios de evaluación es el primer paso para alcanzar el reconocimiento mutuo de certificados. Necesita que vaya acompañada de acuerdos sobre la metodología de evaluación, los esquemas de evaluación y las prácticas de certificación y acreditación.
6. Evaluaciones de calidad y seguridad
Dos factores clave para el éxito de la mejora en el mercado de la seguridad son que las evaluaciones sean asequibles y que los productos y sistemas estén desarrollados de modo que a priori se prevea el cumplimiento de los requisitos de ITSEC o de los criterios que puedan sustituir a ITSEC en el futuro. Debe comprenderse que en muchas situaciones de la industria, en tanto que característica muy importante del producto odel servicio, es sólo un aspecto de un objetivo más amplio que es la calidad del producto o la calidad del servicio.
En este sentido, no podemos prescindir del relevante trabajo
realizado en el campo de la calidad del 'software' y su ingeniería, el cual puede ser muy valioso para la comunidad profesional de la seguridad. Varios estándares se orientan a determinar la calidad a través de un enfoque de evaluación y certificación, en particular las normas de la serie ISO-9000.
Estos estándares están muy consolidados y la demanda de certificados basados en ellos crece rápidamente. Existe por ello una necesidad urgente de armonizar los contenidos de ITSEC/ITSEM, a fin de aprovechar los beneficios aportados por los estándares de calidad, con el fin de reducir los costes y la necesidad de llevar a cabo procesos de evaluación y certificación independientes para calidad y seguridad.
Si se examinan con detalle los estándares de calidad y se
comparan con ITSEC/ITSEM se ve que, a pesar de estar basados en las mismas ideas y principios fundamentales, existen algunos conflictos a la hora de llevar a cabo las evaluaciones, bien porque los requisitos son diferentes o porque lo son los enfoques de evaluación. En este sentido, el Libro Verde de la SSI propone lo siguiente:
- Deberíamos disponer de una distinción mayor entre requisitos específicos de seguridad y los relativos a la calidad, de modo que fuera explícita la cobertura de los distintos sistemas de evaluación.
- El proceso de actualización de ITSEC/ITSEM debería llevarse a cabo, por lo que se refiere a la documentación requerida, por ejemplo, de modo que fuera directamente compatible con la requerida en otros dominios. - Parte de los requisitos ITSEC vigentes podrían reemplazarse por requisitos propios de certificados de calidad relevantes, y presumiblemente también ocurra lo mismo a la inversa.
Un aspecto particular de la racionalización de los procesos de evaluación y certificación que se refieren a la calidad y a la seguridad, es el que afecta a las instalaciones de evaluación (ITSEF‘s en la metodología de ITSEC/ITSEM). En este sector existen normas internacionales y europeas (ISO Guide 25 y EN45001) establecidas para proporcionar orientaciones generales a la acreditación y operación de laboratorios de ensayo. Estos estándares proporcionan un marco para la realización de ensayos objetivos de todo tipo de productos, no sólo los de TI. Por ello, en el campo de la evaluación y certificación de la SSI el cumplimiento de estos estándares es una necesidad, dado que hará más fácil el proceso para el reconocimiento mutuo de certificados.
No obstante, para tener en cuenta las particularidades de la SSI, en cuyo caso hay situaciones en que resulta muy complicado el cumplimiento de la letra de la norma, en determinados países se están desarrollando interpretaciones específicas de la norma EN45001 para el área de la SSI.
Referencias
[1] ANIEL. ‘La Normalización y la Certificación en el Sector Electrónico". Diciembre 1990.
[2] Comisión Europea. ‘Information Technology Security Evaluation Criteria (ITSEC)". Junio 1991.
[3] CESID. ‘Glosario de Términos de Criptología". Dic,1991.
[4] Diario Oficial de las Comunidades Europeas (Nº L 123). ‘Decisión del Consejo de 31 de marzo de 1992 relativa a la Seguridad de los Sistemas de información". 8.5. 1992.
[5] OCDE. ‘Las líneas directrices para la Seguridad de los sistemas de Información". 26.11.1992.
[6] Comisión Europea. ‘Information Technology Security Evaluation Manual (ITSEM)". Septiembre 1993.
[7] Comisión Europea. ‘Green Paper on the Security of Information Systems". Abril 1994.
[8]ComisiónEuropea.‘INFO SEC‘94.Security Inves-tigations". Mayo 1994.