Criterios comunes

Los Criterios Comunes para la Evaluación de Seguridad de Tecnologías de la Información (denominados Criterios Comunes o CC ) son un estándar internacional ( ISO / IEC 15408) para la certificación de seguridad informática . Actualmente se encuentra en la versión 3.1 revisión 5. ^[1]

Los criterios comunes son un marco en el que los usuarios de sistemas informáticos pueden especificar sus requisitos funcionales y de garantía de seguridad (SFR y SAR, respectivamente) en un objetivo de seguridad (ST), y pueden tomarse de perfiles de protección (PP). Luego, los proveedores pueden 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 proporciona garantía de 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 uso objetivo. ^[2] Common Criteria mantiene una lista de productos certificados, incluidos sistemas operativos, sistemas de control de acceso, bases de datos y sistemas de gestión de claves. ^[3]

Conceptos clave

Se realizan evaluaciones de Criterios Comunes sobre productos y sistemas de seguridad informática.

Objetivo de evaluación (TOE) : el producto o sistema que es objeto de la evaluación. La evaluación sirve para validar las afirmaciones hechas sobre el objetivo. Para que sea de utilidad práctica, 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, generalmente creado por un usuario o una comunidad de usuarios, que identifica los 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 para un Propósito particular. Los proveedores de productos pueden optar por implementar productos que cumplan con uno o más PP y evaluar sus productos con respecto a esos PP. En tal caso, un PP puede servir como plantilla para el ST (objetivo de seguridad, como se define a continuación) del producto, o los autores del ST se asegurarán al menos de que todos los requisitos en los PP relevantes también aparezcan en el documento ST del objetivo. Los clientes que buscan tipos particulares de productos pueden centrarse en aquellos certificados con el PP que cumpla con sus requisitos.
- Objetivo de seguridad (ST) : el documento que identifica las propiedades de seguridad del objetivo de evaluación. El ST puede alegar conformidad con uno o más PP. El TOE se evalúa frente a los SFR (Requisitos Funcionales de Seguridad. Nuevamente ver más abajo) establecidos en su ST, ni más ni menos. Esto permite a los proveedores adaptar la evaluación para que coincida con precisión con las capacidades previstas de su producto. Esto significa que un firewall de red no tiene que cumplir los mismos requisitos funcionales que un sistema de gestión de bases de datos y que, de hecho, diferentes firewalls pueden evaluarse frente a listas de requisitos completamente diferentes. El ST generalmente se publica para que los clientes potenciales puedan determinar las características de seguridad específicas que han sido certificadas por la evaluación.
- Requisitos funcionales de seguridad (SFR) : especifican funciones de seguridad individuales que puede proporcionar un producto. Common Criteria presenta un catálogo estándar de dichas funciones. Por ejemplo, un SFR puede indicar cómo se puede autenticar a un usuario que desempeña un rol particular . La lista de SFR puede variar de una evaluación a otra, incluso si dos objetivos son el mismo tipo de producto. Aunque Common Criteria no prescribe que se incluya ningún SFR en una ST, identifica dependencias en las que el funcionamiento correcto de una función (como la capacidad de limitar el acceso según los roles) depende de otra (como la capacidad de identificar roles individuales). ).

El proceso de evaluación también intenta establecer el nivel de confianza que se puede depositar en las características de seguridad del producto a través de procesos de aseguramiento de calidad :

Requisitos de garantía de seguridad (SAR) : descripciones de las medidas tomadas durante el desarrollo y la evaluación del producto para garantizar 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 de cambios o que se realicen pruebas funcionales completas. Los Criterios Comunes proporcionan un catálogo de estos, y los requisitos pueden variar de una evaluación a otra. Los requisitos para objetivos o tipos de productos particulares están documentados en la 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 paquete de requisitos de garantía de seguridad (SAR, ver arriba) que cubre el desarrollo completo de un producto, con un nivel determinado de rigor. Common Criteria enumera siete niveles, siendo EAL 1 el más básico (y por lo tanto más barato de implementar y evaluar) y EAL 7 el más estricto (y más caro). Normalmente, un autor ST o PP no seleccionará los requisitos de aseguramiento individualmente sino que elegirá uno de estos paquetes, posiblemente "aumentando" los requisitos en algunas áreas con requisitos de un nivel superior. Los EAL más altos no implican necesariamente "mejor seguridad", solo significan que la garantía de seguridad declarada del TOE se ha verificado más ampliamente .

Hasta ahora, la mayoría de los PP y los ST/productos certificados más evaluados han sido para componentes de TI (por ejemplo, firewalls, sistemas operativos , tarjetas inteligentes).

A veces se especifica la certificación Common Criteria para la adquisición de TI. Otros estándares que contienen, por ejemplo, interoperación, gestión de sistemas, capacitación de usuarios, suplementos CC y otros estándares de productos. Los ejemplos incluyen la norma 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 del PP están incluyendo requisitos criptográficos para las evaluaciones de CC que normalmente estarían cubiertos por las evaluaciones FIPS 140-2, ampliando los límites del 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 una conformidad estricta con un PP aprobado. Actualmente, Estados Unidos solo permite evaluaciones basadas en PP.

Historia

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

ITSEC : la norma europea, desarrollada a principios de la década de 1990 por Francia, Alemania, los Países Bajos 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 CESG del Reino Unido dirigido al mercado de defensa/inteligencia y el Libro Verde DTI destinado al uso comercial), y fue adoptado por algunos otros países, por ejemplo Australia.
CTCPEC – El estándar canadiense surgió del estándar del Departamento de Defensa de EE. UU., pero evitó varios problemas y fue utilizado conjuntamente por evaluadores de EE. UU. y Canadá. La norma CTCPEC se publicó por primera vez en mayo de 1993.
TCSEC : Departamento de Defensa de los Estados Unidos, DoD 5200.28 Std, llamado Libro Naranja y partes de la Serie Rainbow . El Libro Naranja se originó a partir del trabajo sobre seguridad informática, incluido el Informe Anderson, realizado por la Agencia de Seguridad Nacional y la Oficina Nacional de Estándares (la NBS finalmente se convirtió en NIST ) a finales de los años 1970 y principios de los 1980. La tesis central del Libro Naranja se deriva del trabajo realizado por Dave Bell y Len LaPadula sobre un conjunto de mecanismos de protección.

CC se produjo unificando estos estándares preexistentes, predominantemente de modo que las empresas que venden productos informáticos para el mercado gubernamental (principalmente para uso de Defensa o Inteligencia) solo necesitaran evaluarlos según un conjunto de estándares. El CC fue desarrollado por los gobiernos de Canadá, Francia, Alemania, Países Bajos, Reino Unido y Estados Unidos.

Organizaciones de prueba

Todos los laboratorios de pruebas 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 ante una autoridad de aprobación nacional:

En Canadá, el Consejo de Normas de Canadá (SCC) bajo el Programa de Acreditación de Laboratorios (PALCAN) acredita las Instalaciones de Evaluación de Criterios Comunes (CCEF)
En Francia, el Comité français d'accréditation [fr] (COFRAC) acredita las instalaciones de evaluación Common Criteria, comúnmente llamadas Centre d'évaluation de la sécurité des technologies de l'information [fr] (CESTI). Las evaluaciones se realizan de acuerdo con las normas y estándares especificados por la Agence nationale de la sécurité des systèmes d'information (ANSSI).
En Italia, el OCSI (Organismo di Certificazione della Sicurezza Informatica acredita los laboratorios de evaluación Common Criteria
En India, la Dirección STQC del Ministerio de Electrónica y Tecnología de la Información evalúa y certifica productos de TI en niveles de garantía EAL 1 a EAL 4. ^[4]
En el Reino Unido, el Servicio de Acreditación del Reino Unido (UKAS) solía acreditar las Instalaciones de Evaluación Comercial (CLEF) Archivado el 28 de octubre de 2015 en Wayback Machine ; El Reino Unido es desde 2019 solo un consumidor en el ecosistema CC.
En los EE. UU., el Programa Nacional Voluntario de Acreditación de Laboratorios (NVLAP) del Instituto Nacional de Estándares y Tecnología (NIST ) acredita los Laboratorios de Pruebas de Criterios Comunes (CCTL)
En Alemania, el Bundesamt für Sicherheit in der Informationstechnik (BSI)
En España, el Centro Criptológico Nacional (CCN) acredita a los Laboratorios de Ensayos de Criterios Comunes que operan en el Sistema Español.
En los Países Bajos, el esquema holandés de certificación en el área de seguridad de TI (NSCIB) acredita las instalaciones de evaluación de seguridad de TI (ITSEF).
En Suecia, el organismo sueco de certificación de seguridad de TI (CSEC) otorga licencias para las instalaciones de evaluación de seguridad de TI (ITSEF).

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

Acuerdo de reconocimiento mutuo

Además del estándar de Criterios Comunes, también existe un MRA (Acuerdo de Reconocimiento Mutuo) de Criterios Comunes a nivel de subtratado, mediante el cual cada parte reconoce las evaluaciones en comparación con el estándar de Criterios Comunes realizadas por otras partes. Originalmente firmado en 1998 por Canadá, Francia, Alemania, el Reino Unido y los Estados Unidos, Australia y Nueva Zelanda se adhirieron en 1999, seguidas por Finlandia, Grecia, Israel, Italia, los Países Bajos, Noruega y España en 2000. Desde entonces, el Acuerdo ha sido renombrado 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 del SOGIS-MRA normalmente también reconocen EAL más altos. Las evaluaciones en EAL5 y superiores 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 con 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 a nivel mundial, y hasta el momento no se ha determinado completamente un período de transición.

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

Reconocimiento de evaluaciones únicamente contra un Perfil de Protección colaborativo (cPP) o Niveles de Garantía de Evaluación 1 a 2 y ALC_FLR.
El surgimiento de Comunidades Técnicas Internacionales (CTI), grupos de expertos técnicos encargados de la creación de CPP.
Un plan de transición de la CCRA anterior, incluido el reconocimiento de los certificados emitidos según la versión anterior del Acuerdo.

Asuntos

Requisitos

Criterios Comunes 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 según un estándar de Criterios Comunes 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, incluidas Windows Server 2003 y Windows XP . Archivado el 30 de septiembre de 2017 en Wayback Machine , pero Microsoft aún publica 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 al proveedor restringir el análisis a ciertas características de seguridad y hacer ciertas suposiciones sobre el entorno operativo y la intensidad 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 útiles y rentables, 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, los supuestos incluyen A.PEER:

"Se supone que cualquier otro sistema con el que se comunica el TOE está bajo el mismo control de gestión y opera bajo las mismas restricciones 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 restricciones y reside dentro de un dominio de gestión único. No existen requisitos de seguridad que aborden la necesidad de confiar en sistemas externos o en 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. Basándose en esta y otras suposiciones, que pueden no ser realistas para el uso común de sistemas operativos de propósito general, se evalúan las funciones de seguridad declaradas de los productos Windows. Por lo tanto, solo deben considerarse seguros en las circunstancias especificadas y 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 debería reevaluar el producto para incluir la aplicación de parches para corregir las vulnerabilidades de seguridad dentro de la configuración evaluada. Si el proveedor no toma cualquiera de estos pasos, el organismo de certificación del país en el que se evaluó el producto retirará involuntariamente la certificación del 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 fortaleza 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 Estados Unidos por parte del Common Criteria Evaluación y Validación Esquema (CCEVS). ^[7] En la columna se entrevistó a ejecutivos de la industria de la seguridad, investigadores y representantes de la Asociación Nacional de Aseguramiento de la Información (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 estadounidenses) y el retorno de esa inversión para el proveedor 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 producto en sí. Para las evaluaciones estadounidenses, sólo en EAL5 y superiores participan en el análisis expertos de la Agencia de Seguridad Nacional; y sólo en EAL7 se requiere un análisis completo del código fuente.
El esfuerzo y el tiempo necesarios para preparar la evidencia de la evaluación y otra documentación relacionada con la evaluación es tan engorroso que cuando se completa el trabajo, el producto en evaluación generalmente está obsoleto.
Los aportes de la industria, incluidos los de organizaciones como el Foro de Proveedores de Criterios Comunes, generalmente tienen poco impacto en el proceso en su conjunto.

En un artículo 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). ^[8] Los requisitos de garantía de Common Criteria tienden a inspirarse 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, ^[9] otros han intentado reconciliarlos. ^[10] 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 están certificados, la ausencia de un organismo organizacional con personal permanente que supervise el cumplimiento y la idea de que la confianza en los Criterios Comunes de TI- Las certificaciones de seguridad se mantendrán más allá de las fronteras geopolíticas. ^[11]

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

La vulnerabilidad residía en un algoritmo de generación de claves RSA local que no ha sido publicado ni analizado por la comunidad de criptoaná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 claves RSA se generan según el algoritmo estándar. En respuesta a esta vulnerabilidad, BSI ahora planea mejorar la transparencia al exigir que el informe de certificación al menos especifique si la criptografía patentada implementada no se ajusta exactamente a un estándar recomendado. BSI no planea exigir que el algoritmo propietario se publique de ninguna manera.
Aunque los organismos de certificación ahora son conscientes de que las afirmaciones de seguridad especificadas en los certificados Common Criteria ya no son válidas, ni ANSSI ni BSI han revocado los certificados correspondientes. Según BSI , un certificado sólo puede retirarse cuando se emitió bajo un concepto erróneo, por ejemplo, cuando resulta que se presentaron pruebas erróneas. Después de que se emite un certificado, se debe suponer que la validez del certificado disminuye con el tiempo a medida que se descubren nuevos ataques y mejoras. Los organismos 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.
Si bien varios productos certificados por Common Criteria se han visto afectados por la falla de ROCA, las respuestas de los proveedores en el contexto de la certificación han sido diferentes. Para algunos productos se emitió un informe de mantenimiento que establece que solo 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 en el TOE afecte funcionalidad de seguridad criptográfica certificada, pero concluye que el cambio se realiza a nivel de documentación de orientación y no tiene ningún efecto en la garantía.
Según BSI , los proveedores deberían haber informado a los usuarios de los productos finales certificados sobre la vulnerabilidad ROCA . Sin embargo, esta información no llegó a tiempo a las autoridades estonias, que habían utilizado el producto vulnerable en más de 750.000 documentos de identidad estonios .

Aproximaciones alternativas

A lo largo de la vida 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 el Esquema de productos asistidos por CESG (CAPS). ) ^[13] en el Reino Unido.

El Reino Unido también ha elaborado una serie de sistemas alternativos cuando se ha descubierto que los plazos, los costos y los gastos generales del reconocimiento mutuo impedían el funcionamiento del mercado:

Los esquemas de Evaluación del Sistema CESG (SYSn) y Enfoque de Vía Rápida (FTA) para garantizar sistemas gubernamentales en lugar de productos y servicios genéricos, que ahora se han fusionado en el Servicio de Garantía a Medida (CTAS) de CESG ^[14]
La marca CESG Claims Tested (Marca CCT), que tiene como objetivo manejar requisitos de aseguramiento menos exhaustivos para productos y servicios de una manera eficiente en términos de costos y tiempo.

A principios de 2011, NSA/CSS publicó un artículo de Chris Salter, que proponía un enfoque de evaluación orientado al perfil de protección . En este enfoque, se forman comunidades de interés en torno a 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. ^[15] El objetivo es una evaluación más sólida. Existe cierta preocupación de que esto pueda tener un impacto negativo en el reconocimiento mutuo. ^[dieciséis]

En septiembre de 2012, Common Criteria publicó una Declaración de Visión ^[17] que implementaba en gran medida los pensamientos de Chris Salter del año anterior. Los elementos clave de la Visión incluyeron:

Las comunidades técnicas se centrarán en la creación de perfiles de protección (PP) que respalden su objetivo de obtener resultados de evaluación razonables, comparables, reproducibles y rentables.
Si es posible, las evaluaciones deben realizarse en función de estos PP; de lo contrario, el reconocimiento mutuo de las evaluaciones de Security Target se limitaría a EAL2.

Ver también

Referencias

^ "Publicaciones: Portal CC" . Consultado el 6 de enero de 2024 .
^ "Criterios comunes: establecimiento de seguridad de las comunicaciones". Archivado desde el original el 1 de febrero de 2021 . Consultado el 2 de marzo de 2015 .
^ "Productos certificados con criterios comunes" . Consultado el 30 de diciembre de 2023 .
^ "Descripción general del sistema de certificación de criterios comunes de la India (IC3S)" . Consultado el 30 de diciembre de 2023 .
^ "Acuerdo sobre el reconocimiento de certificados de criterios comunes en el ámbito de la seguridad de las tecnologías de la información" (PDF) . 2014-07-02 . Consultado el 30 de diciembre de 2023 .
^ "Declaración de visión del Comité de Gestión de Criterios Comunes" (PDF) . 2012-09-01 . Consultado el 30 de diciembre de 2023 .
^ Bajo ataque: Common Criteria tiene muchos críticos, pero ¿está recibiendo una mala reputación? Archivado el 23 de abril de 2021 en Wayback Machine Government Computer News, consultado el 14 de diciembre de 2007.
^ Wheeler, David (11 de diciembre de 2006). "Software libre/de código abierto (FLOSS) y Software Assurance/Seguridad del software" (PDF) . Consultado el 30 de diciembre de 2023 .
^ Wäyrynen, J.; Bodén, M.; Boström, G. "Ingeniería de seguridad y programación extrema: ¿un matrimonio imposible?". Apuntes de conferencias sobre informática . doi :10.1007/978-3-540-27777-4_12.
^ Beznosov, Konstantin; Kruchten, Philippe (16 de octubre de 2005). "Hacia una garantía de seguridad ágil" . Consultado el 30 de diciembre de 2023 .
^ Kallberg, enero (1 de agosto de 2012). "Los criterios comunes se combinan con la realpolitik: confianza, alianzas y posible traición" (PDF) . Consultado el 30 de diciembre de 2023 .
^ Parsovs, Arnis (3 de marzo de 2021). Tarjeta de identidad electrónica de Estonia y sus desafíos de seguridad (Doctor) (en estonio). Universidad de Tartu. págs. 141-143 . Consultado el 30 de diciembre de 2023 .
^ "CAPS: Programa de productos asistidos por el CESG". Archivado desde el original el 1 de agosto de 2008.
^ Servicios de certificación y aseguramiento de Infosec (IACS) Archivado el 20 de febrero de 2008 en Wayback Machine.
^ Salter, Chris (10 de enero de 2011). "Reformas de criterios comunes: mejores productos de seguridad mediante una mayor cooperación con la industria" (PDF) . Archivado desde el original (PDF) el 17 de abril de 2012.
^ Brickman, Joshua (11 de marzo de 2011). "Reformas" de "criterios comunes": hundirse o nadar: ¿cómo debería manejar la industria la revolución que se está gestando con criterios comunes?". Archivado desde el original el 29 de mayo de 2012.
^ "Declaración de visión del Comité de Gestión de la CCRA para la dirección futura de la aplicación de la CC y la CCRA" (DOCX) . 2012-09-18 . Consultado el 30 de diciembre de 2023 .

enlaces externos

El sitio web oficial del Proyecto Criterios Comunes
Los documentos estándar de Criterios Comunes
Lista de productos evaluados según Common Criteria
Lista de laboratorios de criterios comunes autorizados
Hacia una garantía de seguridad ágil
Acrónimos de criterios comunes importantes
Foro de usuarios de criterios comunes
Información adicional sobre criterios comunes en Google Knol
Proyecto OpenCC: documentos, plantillas y herramientas CC con licencia de Apache gratuitos
Tarjeta de referencia rápida de criterios comunes
Hoja de referencia del proceso de criterios comunes
Cronograma del proceso de Criterios Comunes