Criterios comunes

Los Criterios Comunes para la Evaluación de la Seguridad de las Tecnologías de la Información (conocidos como Common Criteria o CC ) son una norma internacional ( ISO / IEC 15408) para la certificación de la seguridad informática . Actualmente se encuentra en la versión 3.1 revisión 5. ^[1]

Common Criteria es 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 los 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 prueba pueden evaluar los productos para determinar si realmente cumplen con las afirmaciones. En otras palabras, Common Criteria proporciona la 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 que es acorde con el entorno de destino para su uso. ^[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

Las evaluaciones de Criterios Comunes se realizan en 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 realizadas 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 mediante lo siguiente:
- Perfil de protección (PP) : 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 cortafuegos 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 hacer que sus productos se evalúen en relación con esos PP. En tal caso, un PP puede servir como plantilla para el ST del producto (objetivo de seguridad, como se define a continuación), o los autores del ST al menos se asegurarán 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 según el PP que cumpla con sus requisitos.
- Objetivo de seguridad (ST) : documento que identifica las propiedades de seguridad del objetivo de evaluación. El ST puede declarar la conformidad con uno o más PP. El TOE se evalúa en relación con los SFR (Requisitos funcionales de seguridad; nuevamente, consulte a continuación) 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 con los mismos requisitos funcionales que un sistema de gestión de bases de datos y que, de hecho, se pueden evaluar diferentes firewalls en relación con 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. Los Criterios comunes presentan 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 en particular . La lista de SFR 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 ningún SFR que deba incluirse en un ST, identifican 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 la calidad :

Requisitos de garantía de seguridad (SAR) : descripciones de las medidas adoptadas durante el desarrollo y la evaluación del producto para garantizar el cumplimiento de la funcionalidad de seguridad declarada. Por ejemplo, una evaluación puede exigir 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 requisitos, y los requisitos pueden variar de una evaluación a otra. Los requisitos para objetivos o tipos de productos particulares se documentan en los Criterios comunes y los Criterios de garantía de seguridad, 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 dado de rigurosidad. 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 de ST o PP no seleccionará los requisitos de garantía 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 ha sido verificada más ampliamente .

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, firewalls, sistemas operativos , tarjetas inteligentes).

La certificación Common Criteria se especifica a veces para la adquisición de TI. Otras normas que contienen, por ejemplo, interoperabilidad, gestión de sistemas, formación de usuarios, complementan la CC y otras normas de productos. Algunos ejemplos son la ISO/IEC 27002 y la protección de la línea base de TI alemana .

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

Más recientemente, los autores de PP están incluyendo requisitos criptográficos para las evaluaciones de CC que normalmente estarían cubiertas por las evaluaciones FIPS 140-2, ampliando los límites de la 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 cumplir estrictamente con un PP aprobado. En la actualidad, Estados Unidos solo permite evaluaciones basadas en PP.

Historia

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

ITSEC : Norma europea desarrollada a principios de los años 90 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 del CESG del Reino Unido, destinado al mercado de defensa e inteligencia, y el Libro Verde del DTI, destinado al uso comercial), y fue adoptada por otros países, como Australia.
CTCPEC : el estándar canadiense se inspiró en el estándar del Departamento de Defensa de los Estados Unidos, pero evitó varios problemas y fue utilizado conjuntamente por evaluadores de ambos países. El estándar CTCPEC se publicó por primera vez en mayo de 1993.
TCSEC – Norma DoD 5200.28 del Departamento de Defensa de los Estados Unidos , denominada Libro Naranja y partes de la Serie Arcoiris . 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 Normas (NBS, por sus siglas en inglés ) a fines de la década de 1970 y principios de la de 1980. 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.

El CC se creó unificando estos estándares preexistentes, principalmente para que las empresas que vendieran productos informáticos para el mercado gubernamental (principalmente para uso en defensa o inteligencia) solo necesitaran evaluarlos 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 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), en el marco del Programa de Acreditación de Laboratorios (PALCAN), acredita los Centros 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 la 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 los 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 el único 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 a 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 Esquema Español.
En los Países Bajos, el sistema 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 TI (CSEC) otorga licencias para Instalaciones de Evaluación de Seguridad TI (ITSEF).

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

Acuerdo de reconocimiento mutuo

Además del estándar Common Criteria, también existe un Common Criteria MRA (Mutual Recognition Arrangement) a nivel de sub-tratado, por 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 renombrado Common Criteria Recognition Arrangement ( CCRA ) y la membresía continúa expandiéndose. ^[5] Dentro del CCRA, solo las evaluaciones hasta EAL 2 son reconocidas mutuamente (incluyendo el aumento con la corrección de fallas). Los países europeos dentro del SOGIS-MRA generalmente 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 elaboraron una declaración de visión en virtud de la cual el reconocimiento mutuo de los productos evaluados por CC se reducirá a EAL 2 (incluida la mejora con la corrección de defectos). 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 por completo un período de transición.

El 2 de julio de 2014, se ratificó un nuevo CCRA ^[6] según los objetivos delineados en la declaración de visión de 2012. ^[7] Los principales cambios al Acuerdo incluyen:

Reconocimiento de evaluaciones únicamente frente a 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 (iTC), grupos de expertos técnicos encargados de la creación de CPP.
Un plan de transición respecto del CCRA anterior, incluido el reconocimiento de los certificados emitidos bajo la versión anterior del Acuerdo.

Asuntos

Requisitos

Common Criteria es muy genérico; no proporciona directamente una lista de requisitos de seguridad de productos o características 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 sí puede asegurar 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 Common Criteria muestran una cadena clara de evidencia de que el proceso de especificación, implementación y evaluación se llevó a cabo de manera rigurosa y estandarizada.

Varias versiones de Microsoft Windows, incluyendo Windows Server 2003 y Windows XP , han sido certificadas, ^[8] pero Microsoft sigue publicando parches de seguridad para abordar vulnerabilidades de seguridad para estos sistemas Windows. Esto es posible porque el proceso de obtención de una certificación Common Criteria permite a un proveedor restringir el análisis a ciertas características de seguridad y hacer ciertas suposiciones sobre el entorno operativo y la fuerza de las amenazas a las que se 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 garantía 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 solo si toda la red opera bajo las mismas restricciones y reside dentro de un único dominio de gestión. 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. En base a 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 asumidas, también conocidas como configuración evaluada .

Independientemente de si ejecuta Microsoft Windows en la configuración evaluada exacta o no, debe aplicar los parches de seguridad de Microsoft para las vulnerabilidades de Windows a medida que sigan apareciendo. Si alguna de estas vulnerabilidades de seguridad se puede explotar en la configuración evaluada del producto, el proveedor debe retirar voluntariamente la certificación Common Criteria del producto. Como alternativa, el proveedor debe volver a evaluar el producto para incluir la aplicación de parches que solucionen las vulnerabilidades de seguridad dentro de la configuración evaluada. Si el proveedor no sigue alguno 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 permanecen 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 solidez de una configuración evaluada.

Críticas

En agosto de 2007, el columnista William Jackson de Government Computing News (GCN) examinó críticamente la metodología Common Criteria y su implementación en los Estados Unidos por parte del Common Criteria Evaluation and Validation Scheme (CCEVS). ^[9] 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 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 la evaluación de la documentación de evaluación, no en la seguridad real, la corrección técnica o los méritos del producto en sí. En el caso de las evaluaciones estadounidenses, solo en el nivel EAL5 y superior participan en el análisis expertos de la Agencia de Seguridad Nacional; y solo en el nivel EAL7 se requiere un análisis completo del código fuente.
El esfuerzo y el tiempo necesarios para preparar la evidencia de evaluación y otra documentación relacionada con la evaluación son tan engorrosos 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 Common Criteria discrimina a las organizaciones y modelos de desarrollo centrados en el software libre y de código abierto (FOSS). ^[10] Los requisitos de garantía de Common Criteria tienden a inspirarse en la metodología tradicional de desarrollo de software en cascada . En contraste, gran parte del software FOSS se produce utilizando paradigmas ágiles modernos . Aunque algunos han argumentado que ambos paradigmas no se alinean bien, ^[11] otros han intentado reconciliar ambos paradigmas. ^[12] 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 las certificaciones de seguridad informática de Common Criteria se mantendrá a través de las fronteras geopolíticas. ^[13]

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

La vulnerabilidad residía en un algoritmo de generación de claves RSA desarrollado internamente 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 de acuerdo con el algoritmo estándar. En respuesta a esta vulnerabilidad, BSI ahora planea mejorar la transparencia al exigir que el informe de certificación especifique al menos si la criptografía propietaria 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 saben 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 solo se puede retirar cuando se emitió de manera errónea, por ejemplo, cuando resulta que se presentaron pruebas incorrectas. Una vez emitido un certificado, se debe presumir que la validez del certificado disminuye con el tiempo debido a la aparición de ataques nuevos y mejorados. 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 según Common Criteria se han visto afectados por la falla 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 indica 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 afecta la funcionalidad de seguridad criptográfica certificada, pero concluye que el cambio se encuentra a nivel de documentación de orientación y no tiene efecto sobre la garantía.
Según BSI , los usuarios de los productos finales certificados deberían haber sido informados de la vulnerabilidad de ROCA por los proveedores. Sin embargo, esta información no llegó a tiempo a las autoridades estonias, que habían implementado el producto vulnerable en más de 750.000 documentos de identidad estonios .

Enfoques alternativos

A lo largo de la vida de CC, no ha sido adoptado universalmente ni siquiera por los países creadores, en particular, las aprobaciones criptográficas se manejan por separado, como por ejemplo la implementación canadiense/estadounidense de FIPS-140 y el Esquema de Productos Asistidos CESG (CAPS) ^[15] en el Reino Unido.

El Reino Unido también ha elaborado una serie de planes alternativos cuando se ha comprobado que los plazos, los costes y los gastos generales del reconocimiento mutuo impiden el funcionamiento del mercado:

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

A principios de 2011, la NSA/CSS publicó un artículo de Chris Salter en el que se proponía un enfoque orientado a la evaluación basado en perfiles 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. ^[17] 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. ^[18]

En septiembre de 2012, Common Criteria publicó una Declaración de Visión ^[19] que implementaba en gran medida las ideas de Chris Salter del año anterior. Los elementos clave de la Visión incluían:

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 deberían realizarse en relación con estos PP; de lo contrario, el reconocimiento mutuo de los objetivos de seguridad se limitaría a EAL2.

Véase 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 2021-02-01 . Consultado el 2015-03-02 .
^ "Productos certificados según 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 .
^ "Miembros de la CCRA". Portal de Criterios Comunes . Archivado desde el original el 22 de agosto de 2008.
^ "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 2023-12-30 .
^ "Declaración de visión del Comité de Gestión de Criterios Comunes" (PDF) . 2012-09-01 . Consultado el 2023-12-30 .
^ "Las versiones de Windows obtienen el nivel 4+ de Common Criteria EAL". Noticias sobre seguridad de la información y tecnología de redes . 14 de diciembre de 2005. Archivado desde el original el 14 de octubre de 2006.
^ 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 garantía de software/seguridad de 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: ¿una unión imposible?". Apuntes de clase en 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, Jan (1 de agosto de 2012). "Common Criteria se encuentra con la Realpolitik: confianza, alianzas y posible traición" (PDF) . Consultado el 30 de diciembre de 2023 .
^ Parsovs, Arnis (3 de marzo de 2021). La tarjeta de identidad electrónica de Estonia y sus desafíos de seguridad (doctorado) (en estonio). Universidad de Tartu. pp. 141–143 . Consultado el 30 de diciembre de 2023 .
^ "CAPS: Esquema de productos asistidos por el CESG". Archivado desde el original el 1 de agosto de 2008.
^ Servicios de certificación y aseguramiento de la seguridad informática (IACS) Archivado el 20 de febrero de 2008 en Wayback Machine .
^ Salter, Chris (10 de enero de 2011). "Reformas de Common Criteria: 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). "Las reformas de Common Criteria: ¿hundirse o nadar? ¿Cómo debería la industria manejar la revolución que se está gestando con Common Criteria?". 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 del CC y la CCRA" (DOCX) . 2012-09-18 . Consultado el 2023-12-30 .

Enlaces externos

El sitio web oficial del Proyecto Common Criteria
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 importantes de criterios comunes
Foro de usuarios de Common Criteria
Información adicional sobre criterios comunes en Google Knol
Proyecto OpenCC: documentación, plantillas y herramientas CC con licencia Apache gratuita
Tarjeta de referencia rápida de criterios comunes
Hoja de referencia del proceso de Criterios comunes
Cronograma del proceso de Criterios Comunes