Keyfactor Days 2027: participa en la conferencia sobre seguridad y confianza que se celebrará en San Diego ¡Inscríbete ya!

Criterios Comunes (ISO/IEC 15408): qué supone la evaluación criptográfica para los proveedores de productos informáticos

Equipo de Keyfactor Equipo de Keyfactor
Criterios Comunes (ISO/IEC 15408): qué supone la evaluación criptográfica para los proveedores de productos informáticos

Para muchos compradores del sector público y de defensa, un certificado de Criterios Comunes no es algo que simplemente esté bien tener. Es un requisito imprescindible. Si tu producto no puede acreditarlo, el trato suele quedar descartado antes incluso de que comience la negociación.

Esta es la tensión que la mayoría de los proveedores descubren demasiado tarde: los Criterios Comunes se asientan sobre tu base criptográfica. Una deficiencia en tu estado de validación FIPS no queda aislada. Puede convertirse silenciosamente en un problema relacionado con los Criterios Comunes, que sale a la luz justo cuando un laboratorio comienza a analizar tu objetivo de seguridad.

Los Criterios Comunes se han adoptado como norma ISO/IEC 15408:2022, el marco reconocido internacionalmente para evaluar la seguridad de los productos de TI. Esta guía explica qué son, por qué son importantes, cómo se relacionan con la criptografía, cómo prepararse para una auditoría y cómo se vinculan con la norma FIPS 140-3.

¿Qué son los Criterios Comunes (ISO/IEC 15408)?

Los Criterios Comunes constituyen un método estructurado para demostrar que una configuración definida del producto, el «objeto de evaluación», cumple con las declaraciones de seguridad específicas que se hacen sobre él, verificadas por un tercero acreditado y no por el propio proveedor.

El funcionamiento es sencillo. Los fabricantes especifican los requisitos de seguridad en un «objetivo de seguridad», que suele basarse en un «perfil de protección» publicado. A continuación, un laboratorio de ensayos acreditado verifica de forma independiente que el producto cumple efectivamente con dichos requisitos. Los certificados expedidos en el marco del Acuerdo de Reconocimiento de los Criterios Comunes (CCRA) gozan de reconocimiento mutuo entre los países signatarios, por lo que el producto evita tener que someterse a evaluaciones duplicadas en cada mercado al que acceda.

Hay algunos roles que garantizan la transparencia del sistema:

  • Los organismos nacionales de certificación expiden certificados basándose en la evaluación de un laboratorio: el NIAP (que gestiona el programa CCEVS de EE. UU.), el BSI en Alemania y el CCCS en Canadá. Las normas varían. El NIAP solo acepta evaluaciones basadas en perfiles de protección, por lo que un objetivo de seguridad basado únicamente en el nivel EAL no constituye una vía de acceso al mercado estadounidense.
  • Los laboratorios de ensayo acreditados llevan a cabo la evaluación en función del objetivo de seguridad de un producto. La etiqueta varía según el programa: CCTL en EE. UU., CCEF en Canadá, ITSEF en Alemania y en el marco de la EUCC.

A quiénes se aplica y dónde

Los Criterios Comunes tienen un alcance internacional. La CCRA abarca aproximadamente 31 países; el programa es el Programa de Evaluación y Validación de los Criterios Comunes (CCEVS), administrado por la Asociación Nacional para la Seguridad de la Información (NIAP) y gestionado por la NSA. Los laboratorios llevan a cabo la evaluación; la NIAP valida el resultado y expide el certificado.

Se aplica de forma más directa a los proveedores de productos de TI que desean someterse a una evaluación con respecto a un perfil de protección publicado, incluidos los sistemas operativos, los dispositivos de red, los sistemas de bases de datos, la gestión de dispositivos móviles, el correo electrónico, las VPN y los productos de cortafuegos. Los organismos nacionales de certificación y los laboratorios de ensayo acreditados completan el ecosistema.

Si quieres consultar las fuentes primarias, las que son relevantes en este contexto son la norma ISO/IEC 15408:2022 (partes 1 a 5), los perfiles de protección aprobados por el NIAP, como el cPP para dispositivos de red y el cPP para el cifrado completo de unidades, y la Carta de Política n.º 5 del NIAP, que coordina las actividades de garantía criptográfica de los Criterios Comunes con los programas CAVP y CMVP del NIST.

Por qué los Criterios Comunes son importantes para la evaluación criptográfica

El argumento comercial es claro: para los compradores del sector público y de defensa de todo el mundo, la certificación suele ser, literalmente, un requisito imprescindible para la contratación pública, y no una cuestión de interpretación. Muchas normas nacionales de contratación pública la mencionan 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.

Los requisitos varían según el programa. Esta guía se basa en el NIAP, el programa estadounidense. Los programas europeos, como el BSI y la ANSSI, aplican sus propias directrices criptográficas en lugar de las del CAVP.

La conexión criptográfica es lo que suele confundir a la gente. Los perfiles de protección específicos de criptografía y los requisitos funcionales de seguridad de la clase FCS suelen dar por hecho que los algoritmos 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.

Cómo se relaciona el estándar «Common Criteria» con la criptografía

La norma ISO/IEC 15408 aborda la criptografía a través de varias áreas de control interrelacionadas. Cada una de ellas tiene una implicación criptográfica directa. Algunas cuentan con el respaldo de herramientas; otras son obligaciones de proceso que recaen en los equipos de desarrollo y de cumplimiento normativo y que no se pueden adquirir.

Área de controlQué se necesita
Requisitos criptográficos de «Security Target» (15408-2, Clase FCS)Especifique los algoritmos, los tamaños de clave y las operaciones que debe implementar el objeto de evaluación, así como la forma en que el laboratorio los verificará.
Conformidad con el perfil de protecciónAsignar las capacidades criptográficas al perfil de protección específico con el que se evalúa un producto, de forma preconfigurada para las actividades de verificación del laboratorio.
Fundamentos de la validación del CAVP/CMVP (Carta de política n.º 5 de la NIAP)Asegúrese de que los algoritmos y módulos a los que se hace referencia en el objetivo de seguridad ya cuenten con las validaciones CAVP y CMVP vigentes antes de que comience la evaluación.
Gestión de la configuración de los componentes criptográficos (15408-3, Clase ALC)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.
Continuidad de la garantía tras los cambios criptográficos (CCDB, NIAP)Realizar un seguimiento de las actualizaciones de los algoritmos y los parches de las bibliotecas con respecto a la línea de base certificada para determinar cuándo debe activarse una reevaluación o una revisión de continuidad de la garantía.
Versiones firmadas del producto (FPT_TUD_EXT.1 y FPT_TUD_EXT.2, actualización de confianza)Firmar criptográficamente los parches y las actualizaciones para que los clientes puedan comprobar que una versión sigue coincidiendo con la referencia evaluada.

La pauta es la misma en las seis áreas: la criptografía debe estar definida, validada, controlada y ser trazable, no basta con que exista.

La dependencia FIPS que no puedes omitir

Esta es la relación que frena las evaluaciones. Dado que la mayoría de los perfiles de protección incorporan actividades de garantía criptográfica que presuponen el uso de algoritmos validados según CAVP o CMVP, cualquier deficiencia en el estado de validación FIPS se traduce en una deficiencia en la evaluación según los Criterios Comunes.

En pocas palabras: un producto no puede superar correctamente la evaluación de los Criterios Comunes mientras su módulo criptográfico no esté validado o haya pasado a formar parte de la Lista Histórica del CMVP. Los certificados existentes no se invalidan con carácter retroactivo, pero a partir de esa fecha un certificado 140-2 ya no es válido para nuevas adquisiciones federales, y los plazos actuales de revisión del CMVP superan con creces el año. La mayoría de los cPP exigen una validación CAVP y CMVP vigente y activa para cumplir con las actividades de garantía del FCS, por lo que un certificado caducado puede retrasar o bloquear la certificación, dependiendo del perfil de protección aplicable.

Este riesgo tiene una fecha límite. Los módulos que aún cumplen con la norma FIPS 140-2 se enfrentan a la transición a la «Lista histórica del CMVP» el 21 de septiembre de 2026, lo que puede comprometer la validez de un certificado existente. Si tu evaluación depende de uno de esos módulos, el plazo para la migración ya ha comenzado. (Cuando se publique el capítulo sobre FIPS 140-3, este será el lugar idóneo para incluir un enlace al mismo, con el fin de ofrecer una explicación más detallada.)

Preparación para la auditoría de los Criterios Comunes: qué es lo que examinan los evaluadores

Los evaluadores se basan en pruebas demostradas, no solo en declaraciones de política. Cada evaluación de los Criterios Comunes se lleva a cabo en un laboratorio acreditado, y el organismo de certificación valida el resultado. No existe una vía de autoevaluación ni una alternativa gestionada por el organismo regulador. Las seis áreas que se indican a continuación son las que examinan el laboratorio y el validador. Considéralas como una lista de comprobación:

  • Precisión criptográfica del «Security Target». ¿Describe el «Security Target» con precisión los algoritmos, 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 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 para cada actividad de garantía criptográfica del perfil de protección correspondiente?
  • Documentación sobre gestión de la configuración. ¿La documentación de clase ALC muestra que se controla los componentes criptográficos dentro del ámbito evaluado?
  • Seguimiento de los cambios para garantizar la continuidad. ¿Existe algún proceso para decidir cuándo una actualización de la biblioteca o un cambio en el algoritmo da lugar a una revisión o a una reevaluación completa?
  • Firma de parches y comprobación de la versión. ¿Están firmados los parches? ¿Coincide la versión implementada con la que cubre el certificado?

Cómo Keyfactor ayudarte Keyfactor

Al reunir toda la información, surge un modelo operativo claro. AgileSec facilita el descubrimiento criptográfico y garantiza la continuidad. Keyfactor Command Se encarga de la gestión del ciclo de vida de los certificados y las claves. EJBCA Ofrece una infraestructura de clave pública (PKI) basada en módulos validados. SignServer y las versiones de los productos se firman c Signum .

Hay un atajo muy útil que merece la pena destacar. « EJBCA » incluye un certificado de Criterios Comunes conforme al perfil de protección NIAP para autoridades de certificación y figura en la lista de componentes del CSfC. Esto significa que la función de autoridad de certificación viene ya evaluada, en lugar de convertirse en un componente más dentro de tu propio ámbito de evaluación.

El valor reside en una visión continua y lista para ser presentada como prueba de la criptografía que subyace a un certificado, en lugar de una preparación apresurada en las semanas previas a una auditoría.

Conclusión y próximos pasos

Los Criterios Comunes premian a los proveedores que consideran la criptografía como una base regulada y respaldada continuamente por pruebas, y ponen en evidencia a aquellos que no lo hacen. El certificado final no es más que un subproducto de esa disciplina.

Empieza por donde se concentra el riesgo. Evalúa tu inventario criptográfico y el estado de la validación FIPS con suficiente antelación a la evaluación, confirma que tu «objetivo de seguridad» se ajusta a lo que realmente se comercializa y asegúrate de que todos los módulos a los que se hace referencia cuenten con una validación vigente y activa. A partir de ahí, asocia cada área de control a un proceso repetible, en lugar de a una auditoría puntual.

¿Estás listo para ver cómo Keyfactor da respuesta a cada área de control de los Criterios Comunes? Solicitar una demo.

¿Tienes alguna pregunta sobre los Criterios Comunes? Tenemos las respuestas.

What is Common Criteria (ISO/IEC 15408)?
Common Criteria is the internationally recognized framework for evaluating IT product security, adopted as ISO/IEC 15408:2022. Vendors define requirements in a Security Target, and an accredited lab independently verifies that the product meets those claims.

What is a Security Target versus a Protection Profile?
A Security Target states the security requirements a specific product claims to meet, and it is often built from a published Protection Profile. A Protection Profile is a standardized set of requirements for a product category, such as the Network Device cPP or Full Drive Encryption cPP. Where a Protection Profile applies, the Security Target must claim exact conformance to it, meaning it cannot add or drop mandatory requirements.

Does Common Criteria replace FIPS 140-3 validation?
No. NIAP Policy Letter #5 makes clear that a Common Criteria evaluation is not a substitute for CAVP or CMVP validation. The underlying algorithms and modules should already hold current validation before evaluation begins.

Why do buyers require Common Criteria certification?
For government and defense buyers worldwide, certification is frequently a literal procurement gate. Many national procurement rules cite it directly as a baseline for categories like network devices, VPN gateways, and mobile device management platforms.

Are Common Criteria certificates recognized across countries?
Yes. Certificates issued under the Common Criteria Recognition Arrangement are mutually recognized across signatory nations, spanning roughly 31 countries, so vendors avoid duplicate evaluations in each market.

What do assessors look for in a Common Criteria evaluation?
Assessors focus on demonstrated evidence, including Security Target accuracy, active CAVP/CMVP status, Protection Profile assurance activity evidence, configuration management documentation, assurance continuity change tracking, and patch signing with version matching.

What happens to a certificate when we change cryptography?
Cryptographic changes are tracked against the certified baseline under the CCDB assurance continuity requirements and your scheme’s maintenance policy. . Depending on the change, this can trigger an Assurance Continuity review or a full re-evaluation.

How does the CMVP Historical List affect a Common Criteria certificate?
A product cannot cleanly pass evaluation while its cryptographic module sits unvalidated or has moved to the CMVP Historical List. Modules still on FIPS 140-2 face the September 21, 2026 transition, so plan migration ahead of that date.

Suscríbase a The Source

Stay secure with Keyfactor's monthly newsletter, packed with expert insights and practical steps for quantum-readiness.

Continuar leyendo

Cumplimiento

Explicación de la NIS2: por qué todo responsable de seguridad necesita una estrategia de criptografía

Leer más
Cumplimiento

El Marco de controles de seguridad para clientes de SWIFT: Criptografía para la banca corresponsal

Leer más
Cumplimiento

CMMC 2.0 y NIST SP 800-171: una guía práctica sobre criptografía e infraestructura de clave pública (PKI) para la base industrial de defensa

Leer más