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 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]

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 obtenerse de los perfiles de protección (PP). Los proveedores pueden implementar o hacer afirmaciones sobre los atributos de seguridad de sus productos, y los laboratorios de pruebas pueden evaluarlos productos para determinar si realmente cumplen con las afirmaciones. En otras palabras, Common Criteria proporciona la seguridad 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 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 Common Criteria 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 hechas sobre el objetivo. Para que sea 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, normalmente 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) relevante 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 frente a 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 se asegurarán al menos de que todos los requisitos de 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 cumplan con sus requisitos.
  • Security Target (ST)  : el documento que identifica las propiedades deseguridaddel objetivo de evaluación. El ST puede reclamar conformidad con uno o más PP. El TOE se evalúa contra 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 una base de datos.sistema de gestión, y que diferentes cortafuegos pueden de hecho ser evaluados contra 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)  : especifique las funciones de seguridad individuales que puede proporcionar un producto. Common Criteria presenta un catálogo estándar de tales funciones. Por ejemplo, un SFR puede indicar cómo se puede autenticar a un usuario que desempeña una función 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 Common Criteria no prescribe ningún SFR para ser incluido en un ST, identifica dependencias donde 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 tomadas 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 requerir que todo el código fuente se mantenga en un sistema de gestión de cambios o que se realicen pruebas funcionales completas. Common Criteria proporciona un catálogo de estos y los requisitos pueden variar de una evaluación a otra. Los requisitos para determinados objetivos o tipos de productos están documentados en ST y PP, respectivamente.
• Nivel de garantía de la 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 determinado nivel de rigor. Common Criteria enumera siete niveles, siendo EAL 1 el más básico (y por lo tanto más económico 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 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 nonecesariamente implican "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 productos certificados / ST evaluados han sido para componentes de TI (por ejemplo, cortafuegos, sistemas operativos , tarjetas inteligentes). La certificación de Criterios Comunes a veces se especifica para la adquisición de TI. Otros estándares que contienen, por ejemplo, interoperación, gestión de sistemas, capacitación de usuarios, CC de suplemento y otros estándares de productos. Los ejemplos incluyen ISO / IEC 27002 ) y la protección de línea de base 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 de CC que normalmente estarían cubiertos por las evaluaciones de 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. Los Estados Unidos actualmente solo permiten 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 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 Esquema de Evaluación CESG Reino Unido destinado 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 siguió al estándar del Departamento de Defensa de EE. UU., Pero evitó varios problemas y fue utilizado conjuntamente por evaluadores de EE. UU. Y Canadá. El estándar CTCPEC se publicó por primera vez en mayo de 1993.
• TCSEC  - El 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 de 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 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.

CC se elaboró ​​unificando estos estándares preexistentes, predominantemente para que las empresas que venden productos informáticos para el mercado gubernamental (principalmente para uso de Defensa o Inteligencia) solo necesitaran evaluarlos en función de 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 prueba

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

El cumplimiento con ISO / IEC 17025 generalmente se demuestra a una autoridad de aprobación nacional:

• En Canadá, el Consejo de Normas de Canadá (SCC) del Programa para la Acreditación de Laboratorios (PALCAN) acredita 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 llamado 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 laboratorios de evaluación Common Criteria
• En el Reino Unido, el Servicio de Acreditación del Reino Unido (UKAS) solía acreditar las Instalaciones de Evaluación Comercial (CLEF) ; el Reino Unido es desde 2019 solo un consumidor en el ecosistema CC
• En los EE. UU., El Programa Nacional de Acreditación de Laboratorios Voluntarios (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 los Laboratorios de Ensayos de Criterios Comunes que operan en el Esquema 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 a las Instalaciones de Evaluación de Seguridad de TI (ITSEF).

Las características de estas organizaciones fueron examinadas y presentadas en ICCC 10. ^[4]

Acuerdo de reconocimiento mutuo

Además del estándar Common Criteria, también existe un Common Criteria MRA (Acuerdo de Reconocimiento Mutuo) a nivel de sub-tratado, mediante el cual cada una de las partes reconoce las evaluaciones contra el estándar Common Criteria realizadas por otras partes. Firmado originalmente 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 Acuerdo de Reconocimiento de Criterios Comunes ( CCRA ) y la membresía continúa expandiéndose. Dentro de la CCRA, solo las evaluaciones hasta EAL 2 se reconocen mutuamente (incluido el aumento con corrección de fallas). Los países europeos dentro del antiguo acuerdo ITSEC 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 emitieron una declaración de visión por 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 hasta ahora no se ha determinado completamente un período de transición.

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

• Reconocimiento de evaluaciones solo 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 las Comunidades Técnicas Internacionales (iTC), grupos de expertos técnicos encargados de la creación de las CPC.
• Un plan de transición de la CCRA anterior, incluido el reconocimiento de certificados emitidos bajo la versión anterior del Acuerdo.

Problemas

Requisitos

Common Criteria es muy genérico; no proporciona directamente una lista de requisitos de seguridad del producto 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 que están acostumbrados al enfoque más prescriptivo de otras normas 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 clara cadena 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 todavía 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 de Criterios Comunes 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 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 una 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:

"Se asume 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 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. Sobre la base de 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 de Windows. Por lo tanto, solo deben considerarse seguros en las supuestas circunstancias especificadas, 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 reevaluar 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 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 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 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 los Estados Unidos mediante el Common Criteria Evaluation and Validation Scheme (CCEVS). ^[5] En la columna se entrevistó a ejecutivos de la industria de la seguridad, investigadores y representantes de 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 del proveedor sobre 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 producto en sí. Para las evaluaciones de EE. UU., Solo en EAL5 y superiores participan en el análisis los expertos de la Agencia de Seguridad Nacional; y solo 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 Common Criteria Vendor's Forum , 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 contra las organizaciones y los modelos de desarrollo centrados en el software libre y de código abierto (FOSS). ^[6] Los requisitos de aseguramiento de los Criterios Comunes 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, ^[7] otros han intentado reconciliar ambos paradigmas. ^[8] El politólogo Jan Kallbergexpresó 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 organizativo con personal permanente que supervise el cumplimiento y la idea de que la confianza en las certificaciones de seguridad de TI de Common Criteria se mantendrá en todos los aspectos geopolíticos límites. ^[9]

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 el Esquema de productos asistidos de CESG (CAPS ) ^[10] en el Reino Unido.

El Reino Unido también ha elaborado una serie de planes alternativos cuando se ha descubierto que los plazos, los costes 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 los sistemas gubernamentales en lugar de productos y servicios genéricos, que ahora se han fusionado en el CESG Tailored Assurance Service (CTAS) ^[11]
• La marca CESG Claims Tested Mark ( marca CCT), cuyo objetivo es manejar requisitos de garantía menos exhaustivos para productos y servicios de una manera eficiente en cuanto a costos y tiempo.

A principios de 2011, NSA / CSS publicó un artículo de Chris Salter, que proponía un enfoque orientado al perfil de protección hacia la evaluación. En este enfoque, las comunidades de interés se forman 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. ^[12] 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 . ^[13]

En septiembre de 2012, Common Criteria publicó una declaración de visión que implementa 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 resultados de evaluación razonables, comparables, reproducibles y rentables.
• Si es posible, se deben realizar evaluaciones frente a estos PP; si no, el reconocimiento mutuo de las evaluaciones de Security Target se limitaría a EAL2

Ver también

• Modelo Bell-LaPadula
• Certificado obligatorio de China
• Nivel de garantía de la evaluación
• FIPS 140-2
• Aseguramiento de información
• ISO 9241
• ISO / IEC 27001
• Pruebas de usabilidad
• Verificación y validación

Referencias

1. "Los criterios comunes" .
2. "Criterios comunes - establecimiento de seguridad de la comunicación" .
3. "Productos certificados de criterios comunes" .
4. "Esquemas de criterios comunes en todo el mundo" (PDF) .
5. Under Attack: Common Criteria tiene muchos críticos, pero ¿está recibiendo un bum rap? Government Computer News, consultado el 14 de diciembre de 2007
6. Free-Libre / Software de código abierto (FLOSS) y Software Assurance
7. Wäyrynen, J., Bodén, M. y Boström, G., Ingeniería de seguridad y programación extrema: ¿un matrimonio imposible ?
8. Beznosov, Konstantin; Kruchten, Philippe. "Hacia una garantía de seguridad ágil" . Archivado desde el original el 19 de agosto de 2011 . Consultado el 14 de diciembre de 2007 .
9. Los criterios comunes se encuentran con la Realpolitik: confianza, alianzas y posible traición
10. "CAPS: Esquema de productos asistidos por CESG" . Archivado desde el original el 1 de agosto de 2008.
11. Infosec Assurance and Certification Services (IACS) Archivado el 20 de febrero de 2008 en Wayback Machine.
12. "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.
13. "Reformas de" Criterios Comunes "—Hundirse o nadar— ¿Cómo debería la industria manejar la revolución que se elabora con Criterios Comunes?" . Archivado desde el original el 29 de mayo de 2012.

Enlaces externos

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