Criterios comunes

Los Criterios comunes para la evaluación de la seguridad de la tecnología de la información (denominados Criterios comunes o CC) es una norma internacional (ISO/IEC 15408) para la certificación de seguridad informática. Actualmente se encuentra en la versión 3.1 revisión 5.

Common Criteria es un marco en el que los usuarios de sistemas informáticos pueden especificar sus requisitos de seguridad funcional y garantía (SFR y SAR respectivamente) en un Objetivo de seguridad (ST), y puede tomarse de Perfiles de protección (PP). Los proveedores pueden entonces implementar o hacer afirmaciones sobre los atributos de seguridad de sus productos, y los laboratorios de pruebas pueden evaluar los productos para determinar si realmente cumplen con las afirmaciones. En otras palabras, Common Criteria garantiza que el proceso de especificación, implementación y evaluación de un producto de seguridad informática se ha llevado a cabo de manera rigurosa, estándar y repetible a un nivel acorde con el entorno de destino para su uso. Common Criteria mantiene una lista de productos certificados, incluidos los sistemas operativos, los sistemas de control de acceso, las bases de datos y los sistemas de gestión de claves.

Conceptos clave

Las evaluaciones de Common Criteria se realizan en productos y sistemas de seguridad informática.

• Meta de Evaluación (TOE)– el producto o sistema que es objeto de la evaluación. La evaluación sirve para validar las reclamaciones formuladas sobre el objetivo. Para ser de uso práctico, la evaluación debe verificar las características de seguridad del objetivo. Esto se hace a través de lo siguiente:
  • Perfil de protección (PP)– un documento, creado típicamente por un usuario o comunidad de usuarios, que identifica requisitos de seguridad para una clase de dispositivos de seguridad (por ejemplo, tarjetas inteligentes utilizadas para proporcionar firmas digitales o firewalls de red) relevantes para ese usuario con un propósito particular. Los proveedores de productos pueden optar por implementar productos que cumplan con uno o más PP, y tener sus productos evaluados contra esos PP. En tal caso, un PP puede servir como plantilla para el ST del producto (Objetivo de seguridad, según se define a continuación), o los autores del ST al menos asegurarán que todos los requisitos en PP relevantes también aparezcan en el documento ST del objetivo. Los clientes que buscan determinados tipos de productos pueden centrarse en los certificados contra el PP que satisface sus requisitos.
  • Meta de seguridad (ST)– el documento que identifica la seguridad propiedades del objetivo de evaluación. The ST may claim conformance with one or more PPs. El TOE se evalúa contra las NIF (Requisitos funcionales de seguridad). Otra vez, véase abajo) establecido en su ST, no más ni menos. Esto permite a los proveedores adaptar la evaluación para que coincidan con las capacidades previstas de su producto. Esto significa que un firewall de red no tiene que cumplir con los mismos requisitos funcionales que un sistema de gestión de bases de datos, y que de hecho se pueden evaluar diferentes firewalls contra listas completamente diferentes de requisitos. El ST suele publicarse para que los clientes potenciales puedan determinar las características específicas de seguridad que han sido certificadas por la evaluación.
  • Requisitos funcionales de seguridad– especificar seguridad individual funciones que puede ser proporcionado por un producto. El Criterio Común presenta un catálogo estándar de tales funciones. Por ejemplo, un SFR puede declarar cómo un usuario actuando un papel particular podría ser autenticado. La lista de NIF puede variar de una evaluación a la siguiente, incluso si dos objetivos son el mismo tipo de producto. Aunque los Criterios Comunes no prescriben que las NIF se incluyan en un ST, identifica las dependencias en las que el correcto funcionamiento de una función (como la capacidad de limitar el acceso según funciones) depende de otra (como la capacidad de identificar roles individuales).

El proceso de evaluación también trata de establecer el nivel de confianza que se puede depositar en las funciones de seguridad del producto a través de procesos de control de calidad:

• Necesidades de seguridad (SAR)– descripciones de las medidas adoptadas durante el desarrollo y evaluación del producto para asegurar el cumplimiento de la funcionalidad de seguridad reclamada. Por ejemplo, una evaluación puede requerir que todo el código fuente se mantenga en un sistema de gestión del cambio, o que se realicen pruebas funcionales completas. El Criterio Común proporciona un catálogo de estos, y los requisitos pueden variar de una evaluación a la siguiente. Los requisitos para determinados objetivos o tipos de productos se documentan en el ST y PP, respectivamente.
• Nivel de garantía de evaluación (EAL)– la calificación numérica que describe la profundidad y el rigor de una evaluación. Cada EAL corresponde a un conjunto de requisitos de seguridad (SAR, véase supra) que cubre el desarrollo completo de un producto, con un nivel determinado de rigor. Criterios comunes enumera siete niveles, siendo EAL 1 el más básico (y por lo tanto más barato para implementar y evaluar) y EAL 7 es el más estricto (y más caro). Normalmente, un autor de ST o PP no seleccionará los requisitos de seguridad individualmente, sino que elegirá uno de estos paquetes, posiblemente "aumentando" requisitos en algunas áreas con requisitos de un nivel superior. EALs superiores no necesariamente implican "mejor seguridad", sólo significan que la garantía de seguridad reclamada del TOE ha sido más ampliamente verificada.

Hasta ahora, la mayoría de los PP y la mayoría de los ST/productos certificados evaluados han sido para componentes de TI (por ejemplo, cortafuegos, sistemas operativos, tarjetas inteligentes). La certificación Common Criteria a veces se especifica para la adquisición de TI. Otras normas que contengan, por ejemplo, interoperabilidad, gestión de sistemas, formación de usuarios, suplemento CC y otras normas de productos. Los ejemplos incluyen la ISO/IEC 27002 y la protección básica de TI alemana.

Los detalles de la implementación criptográfica dentro del TOE están fuera del alcance del CC. En cambio, los estándares nacionales, como FIPS 140-2, brindan las especificaciones para los módulos criptográficos y varios estándares especifican los algoritmos criptográficos en uso.

Más recientemente, los autores de PP están incluyendo requisitos criptográficos para las evaluaciones CC que normalmente estarían cubiertos por las evaluaciones FIPS 140-2, ampliando los límites de CC a través de interpretaciones específicas del esquema.

Algunos esquemas de evaluación nacionales están eliminando gradualmente las evaluaciones basadas en EAL y solo aceptan productos para evaluación que afirmen conformidad estricta con un PP aprobado. Estados Unidos actualmente solo permite evaluaciones basadas en PP. Canadá está en proceso de eliminar gradualmente las evaluaciones basadas en EAL.

Historia

CC se originó a partir de tres estándares:

• ITSEC – El estándar europeo, desarrollado a principios de los años noventa por Francia, Alemania, Holanda y el Reino Unido. También fue una unificación de trabajos anteriores, como los dos enfoques del Reino Unido (el Plan de Evaluación del Reino Unido del CESG dirigido al mercado de defensa/inteligencia y el Libro Verde del DTI destinado a uso comercial), y fue adoptado por otros países, por ejemplo Australia.
• CTCPEC – El estándar canadiense siguió del estándar de DD de EE.UU., pero evitó varios problemas y fue utilizado conjuntamente por evaluadores de EE.UU. y Canadá. The CTCPEC standard was first published in May 1993.
• TCSEC – Departamento de Defensa de los Estados Unidos DoD 5200.28 Std, llamado el Libro Naranja y partes de la Serie Rainbow. El Libro Naranja se originó en el trabajo de Seguridad Informática incluyendo el Informe Anderson, hecho por la Agencia Nacional de Seguridad y la Oficina Nacional de Normas (el NBS finalmente se convirtió en NIST) a finales de los 70 y principios de los 80. La tesis central del Libro Naranja se deriva del trabajo realizado por Dave Bell y Len LaPadula para un conjunto de mecanismos de protección.

CC se produjo mediante la unificación de estos estándares preexistentes, principalmente para que las empresas que venden productos informáticos para el mercado gubernamental (principalmente para uso de defensa o inteligencia) solo necesiten que se evalúen con un conjunto de estándares. El CC fue desarrollado por los gobiernos de Canadá, Francia, Alemania, los Países Bajos, el Reino Unido y los EE. UU.

Organizaciones de pruebas

Todos los laboratorios de prueba deben cumplir con la norma ISO/IEC 17025, y los organismos de certificación normalmente estarán aprobados según la norma ISO/IEC 17065.

El cumplimiento de la norma ISO/IEC 17025 normalmente se demuestra a una autoridad de aprobación nacional:

• In Canada, the Standards Council of Canada (SCC) under Program for the Accreditation of Laboratories (PALCAN) accredits Common Criteria Evaluation Facilities (CCEF)
• En Francia, el Comité français d'accréditation[fr] (COFRAC) accredits Common Criteria evaluation facilities, commonly called Centre d'évaluation de la sécurité des technologies de l'information[fr] (CESTI). Las evaluaciones se realizan según las normas y estándares especificados por la Agence nationale de la sécurité des systèmes d'information (ANSSI).
• In Italy, the OCSI (Organismo di Certificazione della Sicurezza Informatica accredits Common Criteria evaluation laboratories
• In India, the STQC Directorate of the Ministry of Electronics and Information Technology evaluates and certifies IT products at assurance levels EAL 1 through EAL4.
• En el Reino Unido el Servicio de Acreditación del Reino Unido (UKAS) utilizó para acreditar Instalaciones de Evaluación Comercial (CLEF); el Reino Unido es desde 2019 sólo un consumidor en el ecosistema CC
• En EE.UU., el Instituto Nacional de Normas y Tecnología (NIST) Programa Nacional de Acreditación de Laboratorios Voluntarios (NVLAP) acredita los Laboratorios de Prueba de Criterios Comunes (CCTL)
• En Alemania, el Bundesamt für Sicherheit en der Informationstechnik (BSI)
• En España, el Centro Cryptologic Nacional (CCN) acredita a los Laboratorios de Prueba de Criterios Comunes que operan en el Plan Español.
• En los Países Bajos, el plan Países Bajos de certificación en la esfera de la seguridad informática (NSCIB) acredita las instalaciones de evaluación de la seguridad informática (ITSEF).
• En Suecia, el Órgano de Certificación Sueco de Seguridad de la TI (CSEC) otorga licencias a las instalaciones de evaluación de seguridad de la TI (ITSEF).

Las características de estas organizaciones fueron examinadas y presentadas en ICCC 10.

Acuerdo de reconocimiento mutuo

Además del estándar Common Criteria, también existe un MRA (Acuerdo de Reconocimiento Mutuo) de Common Criteria a nivel de subtratado, mediante el cual cada parte del mismo reconoce las evaluaciones contra el estándar Common Criteria realizadas por otras partes. Originalmente firmado en 1998 por Canadá, Francia, Alemania, el Reino Unido y los Estados Unidos, Australia y Nueva Zelanda se unieron en 1999, seguidos por Finlandia, Grecia, Israel, Italia, los Países Bajos, Noruega y España en 2000. Desde entonces, el Acuerdo ha sido renombró Acuerdo de reconocimiento de criterios comunes (CCRA) y la membresía continúa expandiéndose. Dentro de CCRA, solo se reconocen mutuamente las evaluaciones hasta EAL 2 (incluido el aumento con corrección de fallas). Los países europeos dentro de SOGIS-MRA también suelen reconocer EAL más altos. Las evaluaciones en EAL5 y superior tienden a involucrar los requisitos de seguridad del gobierno de la nación anfitriona.

En septiembre de 2012, la mayoría de los miembros de la CCRA produjeron una declaración de visión mediante la cual el reconocimiento mutuo de los productos evaluados por CC se reducirá a EAL 2 (incluido el aumento con corrección de fallas). Además, esta visión indica un alejamiento total de los niveles de garantía y las evaluaciones se limitarán a la conformidad con los perfiles de protección que no tienen un nivel de garantía establecido. Esto se logrará a través de grupos de trabajo técnicos que desarrollen PP en todo el mundo, y aún no se ha determinado completamente un período de transición.

El 2 de julio de 2014, se ratificó una nueva CCRA según los objetivos descritos en la declaración de visión de 2012. Los principales cambios en el Acuerdo incluyen:

• Recognition of evaluations against only a collaborative Protection Profile (cPP) or Evaluation Assurance Levels 1 through 2 and ALC_FLR.
• The emergence of international Technical Communities (iTC), groups of technical experts charged with the creation of cPPs.
• Un plan de transición de la CCRA anterior, incluido el reconocimiento de certificados emitidos en la versión anterior del Acuerdo.

Problemas

Requisitos

Common Criteria es muy genérico; no proporciona directamente una lista de requisitos o características de seguridad del producto para (clases de) productos específicos: esto sigue el enfoque adoptado por ITSEC, pero ha sido una fuente de debate para aquellos acostumbrados al enfoque más prescriptivo de otros estándares anteriores como TCSEC y FIPS 140-2.

Valor de la certificación

La certificación Common Criteria no puede garantizar la seguridad, pero puede garantizar que las afirmaciones sobre los atributos de seguridad del producto evaluado se verificaron de forma independiente. En otras palabras, los productos evaluados con respecto a un estándar de Common Criteria exhiben una cadena clara de evidencia de que el proceso de especificación, implementación y evaluación se ha llevado a cabo de manera rigurosa y estándar.

Se han certificado varias versiones de Microsoft Windows, incluidos Windows Server 2003 y Windows XP, pero Microsoft sigue publicando parches de seguridad para abordar las vulnerabilidades de seguridad para estos sistemas Windows. Esto es posible porque el proceso de obtención de una certificación Common Criteria permite que un proveedor restrinja el análisis a ciertas características de seguridad y haga ciertas suposiciones sobre el entorno operativo y la fuerza de las amenazas que enfrenta el producto en ese entorno. Además, el CC reconoce la necesidad de limitar el alcance de la evaluación para proporcionar certificaciones de seguridad rentables y útiles, de modo que los productos evaluados se examinen con un nivel de detalle especificado por el nivel de garantía o PP. Por lo tanto, las actividades de evaluación solo se realizan con cierta profundidad, uso de tiempo y recursos y ofrecen una seguridad razonable para el entorno previsto.

En el caso de Microsoft, las suposiciones incluyen A.PEER:

"Cualquier otro sistema con el que se comunique el TOE está bajo el mismo control de gestión y opera bajo las mismas limitaciones de política de seguridad. El TOE es aplicable a entornos en red o distribuidos sólo si toda la red opera bajo las mismas limitaciones y reside dentro de un solo dominio de gestión. No hay requisitos de seguridad que aborden la necesidad de confiar en los sistemas externos o los enlaces de comunicaciones a dichos sistemas".

Esta suposición está contenida en el perfil de protección de acceso controlado (CAPP) al que se adhieren sus productos. Sobre la base de esta y otras suposiciones, que pueden no ser realistas para el uso común de los sistemas operativos de uso general, se evalúan las funciones de seguridad declaradas de los productos de Windows. Por lo tanto, solo deben considerarse seguros en las circunstancias especificadas asumidas, también conocidas como configuración evaluada.

Ya sea que ejecute Microsoft Windows en la configuración evaluada precisa o no, debe aplicar los parches de seguridad de Microsoft para las vulnerabilidades en Windows a medida que continúan apareciendo. Si alguna de estas vulnerabilidades de seguridad es explotable en la configuración evaluada del producto, el proveedor debe retirar voluntariamente la certificación Common Criteria del producto. Alternativamente, el proveedor debe volver a evaluar el producto para incluir la aplicación de parches para corregir las vulnerabilidades de seguridad dentro de la configuración evaluada. El incumplimiento por parte del proveedor de tomar cualquiera de estos pasos resultaría en el retiro involuntario de la certificación del producto por parte del organismo de certificación del país en el que se evaluó el producto.

Las versiones certificadas de Microsoft Windows se mantienen en EAL4+ sin incluir la aplicación de ningún parche de vulnerabilidad de seguridad de Microsoft en su configuración evaluada. Esto muestra tanto la limitación como la fuerza de una configuración evaluada.

Críticas

En agosto de 2007, el columnista de Government Computing News (GCN), William Jackson, examinó críticamente la metodología Common Criteria y su implementación en EE. UU. por parte del Common Criteria Evaluation and Validation Scheme (CCEVS). En la columna se entrevistó a ejecutivos de la industria de la seguridad, investigadores y representantes de la National Information Assurance Partnership (NIAP). Las objeciones descritas en el artículo incluyen:

• La evaluación es un proceso costoso (a menudo medido en cientos de miles de dólares EE.UU.) – y el rendimiento del proveedor en esa inversión no es necesariamente un producto más seguro.
• La evaluación se centra principalmente en evaluar la documentación de evaluación, no en la seguridad real, la corrección técnica o los méritos del propio producto. Para las evaluaciones de EE.UU., sólo en EAL5 y superiores los expertos de la Agencia Nacional de Seguridad participan en el análisis; y sólo en EAL7 es necesario el análisis completo del código fuente.
• El esfuerzo y el tiempo necesarios para preparar pruebas de evaluación y otra documentación relacionada con la evaluación es tan engorroso que para el momento en que se termina el trabajo, el producto en evaluación es generalmente obsoleto.
• El aporte de la industria, incluyendo el de organizaciones como el Foro del Vendedor Común de Criterios, generalmente tiene poco impacto en el proceso en su conjunto.

En un trabajo de investigación de 2006, el especialista en informática David A. Wheeler sugirió que el proceso de criterios comunes discrimina las organizaciones y los modelos de desarrollo centrados en el software libre y de código abierto (FOSS). Los requisitos de aseguramiento de Common Criteria tienden a estar inspirados en la metodología tradicional de desarrollo de software en cascada. Por el contrario, gran parte del software FOSS se produce utilizando paradigmas ágiles modernos. Aunque algunos han argumentado que ambos paradigmas no se alinean bien, otros han intentado reconciliar ambos paradigmas. El politólogo Jan Kallberg expresó su preocupación por la falta de control sobre la producción real de los productos una vez que se certifican, la ausencia de un organismo organizacional con personal permanente que supervise el cumplimiento y la idea de que la confianza en las certificaciones de seguridad de TI de Common Criteria mantenerse a través de las fronteras geopolíticas.

En 2017, la vulnerabilidad ROCA se encontró en una lista de productos de tarjetas inteligentes certificados por Common Criteria. La vulnerabilidad destacó varias deficiencias del esquema de certificación Common Criteria:

• La vulnerabilidad reside en un algoritmo de generación de claves RSA que no ha sido publicado y analizado por la comunidad de criptanálisis. Sin embargo, el laboratorio de pruebas TÜV Informationstechnik GmbH (TÜViT) en Alemania aprobó su uso y el organismo de certificación BSI en Alemania emitió certificados Common Criteria para los productos vulnerables. El objetivo de seguridad del producto evaluado afirmó que las teclas RSA se generan según el algoritmo estándar. En respuesta a esta vulnerabilidad, BSI ahora planea mejorar la transparencia exigiendo que el informe de certificación al menos especifique si la criptografía patentada implementada no se ajusta exactamente a una norma recomendada. BSI no planea exigir que el algoritmo propietario sea publicado de ninguna manera.
• A pesar de que los órganos de certificación son ahora conscientes de que las reclamaciones de seguridad especificadas en los certificados de Criterios Comunes ya no se mantienen, ni ANSSI ni BSI han revocado los certificados correspondientes. Según BSI, sólo se puede retirar un certificado cuando se emitió bajo mala concepción, por ejemplo, cuando resulta que se presentaron pruebas erróneas. Después de que se expida un certificado, se debe presumir que la validez del certificado disminuye con el tiempo mejorando y descubriendo nuevos ataques. Los órganos de certificación pueden emitir informes de mantenimiento e incluso realizar una recertificación del producto. Sin embargo, estas actividades deben ser iniciadas y patrocinadas por el proveedor.
• Aunque varios productos certificados Common Criteria han sido afectados por el defecto ROCA, las respuestas de los proveedores en el contexto de la certificación han sido diferentes. Para algunos productos se publicó un informe de mantenimiento, en el que se afirma que sólo las claves RSA con una longitud de 3072 y 3584 bits tienen un nivel de seguridad de al menos 100 bits, mientras que para algunos productos el informe de mantenimiento no menciona que el cambio al TOE afecta a la funcionalidad de seguridad criptográfica certificada, pero concluye que el cambio está al nivel de la documentación de orientación y no tiene ningún efecto en la seguridad.
• Según BSI, los usuarios de los productos finales certificados deberían haber sido informados de la vulnerabilidad ROCA por los proveedores. Sin embargo, esta información no llegó oportunamente a las autoridades estonias que habían desplegado el producto vulnerable en más de 750.000 tarjetas de identidad estonias.

Enfoques alternativos

A lo largo de la vida útil de CC, no ha sido adoptado universalmente, ni siquiera por las naciones creadoras, y, en particular, las aprobaciones criptográficas se manejan por separado, como la implementación canadiense/estadounidense de FIPS-140 y los productos asistidos por CESG. (CAPS) en el Reino Unido.

El Reino Unido también ha producido una serie de esquemas alternativos cuando se ha descubierto que los plazos, los costos y los gastos generales del reconocimiento mutuo impiden el funcionamiento del mercado:

• Los esquemas CESG System Evaluation (SYSn) y Fast Track Approach (FTA) para garantizar sistemas gubernamentales en lugar de productos y servicios genéricos, que ahora se han fusionado en el CESG Tailored Assurance Service (CTAS)
• The CESG Claims Tested Mark (CCT Mark), which is aimed at handling less exhaustive assurance requirements for products and services in a cost and time efficient manner.

A principios de 2011, NSA/CSS publicó un artículo de Chris Salter, que proponía un enfoque orientado a la evaluación del perfil de protección. En este enfoque, se forman comunidades de interés en torno a los tipos de tecnología que, a su vez, desarrollan perfiles de protección que definen la metodología de evaluación para el tipo de tecnología. El objetivo es una evaluación más robusta. Existe cierta preocupación de que esto pueda tener un impacto negativo en el reconocimiento mutuo.

En septiembre de 2012, Common Criteria publicó una Declaración de visión que implementaba en gran medida las ideas de Chris Salter del año anterior. Los elementos clave de la Visión incluyeron:

• Las Comunidades Técnicas se centrarán en la autorización de Perfiles de Protección (PP) que apoyen su objetivo de resultados de evaluación razonables, comparables, reproducibles y rentables
• Las evaluaciones deben hacerse si es posible contra estos PP; si no el reconocimiento mutuo de las evaluaciones de Security Target se limitaría a EAL2.