ISO/IEC 15408 (Criterios Comunes):
ISO/IEC 15408 (Criterios Comunes): Evaluación criptográfica de productos de tecnologías de la información
| Región | Internacional (el Acuerdo de Reconocimiento de los Criterios Comunes abarca aproximadamente 31 países; en Estados Unidos, la evaluación corre a cargo de la Asociación Nacional para la Seguridad de la Información) |
| Ámbito de aplicación | Proveedores de productos de TI: sistemas operativos , dispositivos de red, sistemas de bases de datos, gestión de dispositivos móviles, correo electrónico, VPN y productos de cortafuegos que desean someterse a una evaluación con arreglo a un perfil de protección publicado. Organismos nacionales de certificación: NIAP en Estados Unidos, BSI en Alemania, CCCS en Canadá y organismos equivalentes que emiten y validan certificados. Laboratorios de ensayo acreditados (CCTL): laboratorios independientes que realizan la evaluación con arreglo al objetivo de seguridad de un producto. |
| Apartados pertinentes | ISO/IEC 15408:2022: la edición actual de los Criterios Comunes, partes 1 a 5 . Perfiles de protección aprobados por el NIAP: por ejemplo, el cPP para dispositivos de red y el cPP para el cifrado completo de unidades, que especifican los requisitos funcionales de seguridad criptográfica. Carta de política n.º 5 del NIAP (actualización 4): coordinación de las actividades de garantía criptográfica de los Criterios Comunes con los programas CAVP y CMVP del NIST. |
Visión general
Los Criterios Comunes, adoptados como norma ISO/IEC 15408:2022, constituyen el marco reconocido internacionalmente para evaluar la seguridad de los productos informáticos. Los proveedores especifican los requisitos de seguridad en un «objetivo de seguridad», que a menudo se elabora a partir de un «perfil de protección» publicado, y un laboratorio de ensayo acreditado verifica de forma independiente que el producto cumple con dichos requisitos. Los certificados expedidos en virtud del Acuerdo de Reconocimiento de los Criterios Comunes gozan de reconocimiento mutuo en todos los países signatarios, lo que evita la duplicación de evaluaciones para un mismo producto en cada mercado.
Los perfiles de protección específicos de criptografía y los requisitos funcionales de seguridad de la clase FCS de los Criterios Comunes suelen partir de la base de que los algoritmos criptográficos subyacentes ya han sido validados a través del Programa de Validación de Algoritmos Criptográficos (CAVP) del NIST o del CMVP. La Carta de Política n.º 5 del NIAP formaliza esa relación: una evaluación según los Criterios Comunes no sustituye a la validación del CAVP o del CMVP, sino que se basa en ella.
Por qué es importante
La certificación de los Criterios Comunes suele ser, literalmente, un requisito imprescindible para la contratación pública por parte de organismos gubernamentales y de defensa de todo el mundo, y no es una cuestión de interpretación; muchas normas nacionales de contratación pública la citan directamente como requisito básico para categorías como los dispositivos de red, las pasarelas VPN y las plataformas de gestión de dispositivos móviles.
Dado que la mayoría de los perfiles de protección incorporan actividades de garantía criptográfica que dan por hecho que los algoritmos subyacentes ya han sido validados según CAVP o CMVP, una deficiencia en el estado de validación FIPS se convierte también en una deficiencia en la evaluación de los Criterios Comunes. Esto vincula directamente este capítulo con el capítulo sobre FIPS 140-3 que aparece anteriormente en esta guía: un producto no puede superar satisfactoriamente la evaluación de los Criterios Comunes mientras su módulo criptográfico no haya sido validado o haya pasado a formar parte de la Lista Histórica del CMVP.
Cómo se aplica esto a la criptografía
La norma ISO/IEC 15408 (Criterios Comunes) aborda la criptografía a través de varias áreas de control interrelacionadas. Las áreas clave con implicaciones criptográficas directas son:
| Sección | Función | Lo que dice | Asistencia para los productos « Keyfactor » |
| ISO/IEC 15408-2, Clase FCS | Requisitos criptográficos para los objetivos de seguridad | Especifique los algoritmos criptográficos, los tamaños de clave y las operaciones que debe implementar el objeto de evaluación, así como la forma en que un laboratorio de ensayo los verificará. | AgileSec |
| PP aprobados por la NIAP (por ejemplo, cPP de dispositivos de red, cPP de cifrado completo de unidad) | Conformidad con el perfil de protección | Asignar las capacidades criptográficas al perfil de protección específico con arreglo al cual se evalúa un producto, preparadas de antemano para las actividades de verificación que llevará a cabo el laboratorio. | Command / AgileSec |
| Carta de política n.º 5 de la NIAP | Validación subyacente de CAVP/CMVP | Asegúrese de que los algoritmos y módulos a los que se hace referencia en el objetivo de seguridad ya cuenten con la validación CAVP y CMVP vigente antes de que comience la evaluación según los Criterios Comunes. | EJBCA |
| ISO/IEC 15408-3, Clase ALC | Gestión de la configuración de los componentes criptográficos | Demostrar la gestión de la configuración y los controles del ciclo de vida de los componentes criptográficos incluidos dentro de los límites del producto certificado. | Keyfactor Command |
| Continuidad de la garantía de la CCRA | Continuidad de la garantía tras los cambios criptográficos | Realizar un seguimiento de los cambios criptográficos, las actualizaciones de algoritmos y los parches de bibliotecas, comparándolos con la referencia certificada, para determinar cuándo debe llevarse a cabo una reevaluación o una revisión de la continuidad de la garantía. | AgileSec |
| ALC_FLR (corrección de defectos) | Comunicados de prensa sobre productos firmados | Firmar criptográficamente los parches y las actualizaciones publicados para un producto certificado, de modo que los clientes puedan comprobar que la versión sigue coincidiendo con la referencia evaluada. | SignServer / Signum |
Preparación para la auditoría
Las evaluaciones y los exámenes, ya sean realizados por la propia organización, llevados a cabo por un organismo regulador o revisados por un evaluador independiente, se centran en las pruebas demostradas y no únicamente en las declaraciones de política. Áreas clave que suelen analizar los examinadores y evaluadores:
- Precisión criptográfica del objetivo de seguridad: ¿Describe el objetivo de seguridad con precisión los algoritmos criptográficos, los modos y los tamaños de clave realmente implementados en el producto comercializado?
- Estado subyacente de CAVP/CMVP: ¿Cuentan los algoritmos y módulos a los que se hace referencia en el objetivo de seguridad con una validación CAVP y CMVP vigente y activa?
- Pruebas de las actividades de garantía del perfil de protección: ¿Existen pruebas de ensayo que respalden cada una de las actividades de garantía criptográfica especificadas en el perfil de protección aplicable?
- Documentación sobre gestión de la configuración: ¿Demuestra la documentación de clase ALC que se ejerce control sobre los componentes criptográficos dentro del ámbito evaluado?
- Seguimiento de cambios en la continuidad de la garantía: ¿Existe algún proceso para evaluar si una actualización de una biblioteca criptográfica o un cambio de algoritmo da lugar a una revisión de la continuidad de la garantía o a una reevaluación completa?
- Firma de parches y coincidencia de versiones: ¿Están firmados los parches emitidos para un producto certificado? ¿Coincide la versión implementada con la que cubre el certificado?
LLEVA ESTO A LA DIRECCIÓN
La certificación de los Criterios Comunes suele ser, literalmente, la puerta de acceso que determina si podemos vender a una entidad gubernamental o del sector de la defensa, y no una simple acreditación «que está bien tener». Y dado que la mayoría de los perfiles de protección dan por hecho que nuestra criptografía ya cuenta con la validación CAVP o CMVP, una deficiencia en nuestro estado de validación FIPS no solo nos cuesta directamente las ventas al sector federal, sino que también bloquea o retrasa la evaluación de los Criterios Comunes, que es la puerta de acceso a otros acuerdos.
El riesgo oculto es lo que ocurre tras la certificación: una actualización rutinaria de la biblioteca o un parche de algoritmo pueden invalidar silenciosamente la línea de base evaluada si no la supervisamos según los requisitos de continuidad de la garantía. Necesitamos saber, para cada producto certificado, exactamente qué componentes criptográficos se encuentran dentro de ese límite y si un cambio concreto requiere una revisión antes de su lanzamiento.
Cumplimientos normativos relacionados
ISO/IEC 27001:2022 para TI y Software
Ley de resiliencia cibernética para el sector manufacturero