Resumen: PKI Maturity Model 2.0.0 está en vista previa pública, y su principal cambio es una nueva categoría de Criptografía en el módulo de Gobernanza. Las decisiones criptográficas que estaban dispersas entre la gestión de certificados y de claves ahora tienen un único lugar coherente.
Pedir a un proceso de gestión de certificados que gobernara conjuntos de cifrado siempre fue un error de categorización. 2.0.0 corrige la taxonomía en lugar de ampliarla.
El PKI Maturity Model es desarrollado por un grupo de trabajo del PKI Consortium. La versión 1.0.0 formalizó cinco niveles de madurez en cuatro módulos y quince categorías. Desde entonces, los evaluadores lo han utilizado en programas reales, y las dificultades que comunicaron han dado forma a esta revisión.
La versión 2.0.0 ya está disponible como vista previa pública. Este artículo repasa qué cambió y qué significa si ya ha completado una evaluación.
La nueva categoría de Criptografía
Gobernanza incorpora una categoría: Criptografía. Centraliza la gobernanza de algoritmos y parámetros criptográficos, protocolos y versiones, visibilidad de activos criptográficos, y ciclo de vida, retirada y agilidad criptográfica.
Anteriormente, esas cuestiones se encontraban dentro de Gestión de claves y Gestión de certificados como requisitos de conjuntos de cifrado. Esa ubicación generaba solapamientos y terminología ambigua. Como consecuencia, dos evaluadores podían discrepar razonablemente sobre dónde correspondía un hallazgo.
La nueva categoría contiene seis requisitos.
| Requisito | Qué evalúa un evaluador |
|---|---|
| Terminología y alcance | Si la terminología criptográfica y el alcance aplicables a la PKI están definidos y documentados |
| Algoritmos y parámetros | Si los algoritmos y parámetros en uso están documentados y formalmente aprobados |
| Protocolos y versiones | Si los protocolos y las versiones de protocolo en uso están documentados y aprobados |
| Visibilidad del uso | Si se ha establecido y se mantiene visibilidad sobre el uso criptográfico real |
| Ciclo de vida y retirada | Si están definidas las reglas de ciclo de vida y retirada criptográfica |
| Agilidad criptográfica | Si la agilidad está definida y gobernada: la capacidad de sustituir algoritmos o parámetros de forma controlada |
Lea esa lista junto a cualquier plan de migración poscuántica. Cuatro de los seis son requisitos previos para uno, y la mayoría de las organizaciones descubren que no pueden aportar evidencias de ellos.
Se eliminaron dos requisitos
La consolidación funciona en ambos sentidos. Gestión de certificados pierde «Los conjuntos de cifrado de certificados están documentados», y Gestión de claves pierde «Los conjuntos de cifrado y protocolos criptográficos están documentados y se mantienen».
Conviene explicar el razonamiento con claridad. Los conjuntos de cifrado son un concepto a nivel de protocolo, asociado principalmente con TLS y protocolos similares. Los certificados no los definen ni los negocian. Por tanto, mantener ese requisito en Gestión de certificados mezclaba la gobernanza criptográfica con la gestión del ciclo de vida de certificados.
Gestión de claves tenía el mismo problema desde la otra dirección. La aprobación de algoritmos y protocolos es una cuestión de gobernanza, no del ciclo de vida de las claves. Así, Gestión de claves se centra ahora exclusivamente en el ciclo de vida de las claves y Gestión de certificados en el ciclo de vida de los certificados.
Cambios que afectan a sus informes existentes
Varios cambios son estructurales y no sustantivos. Aun así, afectan a cualquier cosa que haya automatizado o guardado como marcador.
El nivel de madurez 2 cambia de nombre de «Básico» a «Fundacional». El número de nivel y la descripción de lo que significa alcanzarlo no cambian, por lo que el cambio de nombre busca transmitir mejor la intención. Los informes existentes de 1.0.0 siguen siendo válidos. Sin embargo, si vuelve a emitir uno, actualice la etiqueta.
Los identificadores estables sustituyen a los números basados en posición. Antes, las categorías y requisitos se referenciaban como G.1 y G.1.1; ahora son G.strategy-and-vision y G.strategy-and-vision.sponsor-support. Como los identificadores son estables, sobreviven a futuras versiones menores. Cualquier cosa que haya creado sobre los números necesitará una actualización única.
Las URL de las páginas de categorías también eliminaron sus prefijos numéricos, por lo que los marcadores que apunten a rutas con estilo 01-… deberían pasar al formato que contiene solo el identificador. Además, un catálogo compartido de referencias contiene ahora las normas, regulaciones y publicaciones citadas por el modelo, lo que permite mantener centralmente los títulos y enlaces entre versiones mayores.
Las herramientas se movieron y una fue retirada
Las herramientas de evaluación basadas en Excel se retiran a partir de 2.0.0 y son sustituidas por la autoevaluación web. Siguen accesibles en las URL etiquetadas como 1.0.0 y en la sección 1.0.0 del sitio web. Pero si automatizó contra una ruta fijada a la rama principal, ese enlace dejará de resolverse.
Los scripts de conversión CSV de Eramba se trasladaron a un repositorio de integraciones independiente. Del mismo modo, las extensiones publicadas ahora viven en su propio catálogo en lugar de distribuirse con el modelo central.
Si evaluó con 1.0.0
El impacto práctico es menor de lo que sugiere un salto de versión mayor.
Las categorías heredadas de 1.0.0 no tienen cambios de contenido más allá de la eliminación de los dos requisitos de conjuntos de cifrado. Por tanto, puede ser necesario reevaluar ligeramente las puntuaciones cuando ese requisito eliminado influyera de forma material en un nivel. Para la mayoría de las evaluaciones, el efecto es menor y se limita a un único requisito.
El trabajo real es aditivo. Las organizaciones que completaron una evaluación con 1.0.0 deberían añadir la categoría de Criptografía en su siguiente ciclo. Ese es el único lugar donde 2.0.0 plantea preguntas realmente nuevas.
Por qué esto importa más allá del modelo
OmniTrust participa en el grupo de trabajo de PKI Maturity Model, y creemos que esta revisión representa el tipo correcto de cambio. No persigue temas nuevos. En su lugar, corrige una taxonomía que había archivado la gobernanza criptográfica bajo gestión del ciclo de vida.
Esa corrección importa porque se está pidiendo al sector, todo al mismo tiempo, que inventaríe su criptografía, acorte la vigencia de los certificados y planifique una migración poscuántica. Nada de eso es posible sin saber qué algoritmos utiliza y quién los aprobó. Un modelo de madurez que dispersa esas preguntas entre tres categorías no puede medir si usted lo sabe.
El modelo se desarrolla de forma abierta y el grupo de trabajo agradece las aportaciones. Si se dedica profesionalmente a evaluar programas de PKI, la vista previa es el momento en que resulta más barato actuar sobre sus objeciones.
Puntos clave
- Gobernanza incorpora una categoría de Criptografía con seis requisitos que cubren algoritmos, protocolos, visibilidad del uso, ciclo de vida, retirada y agilidad.
- Se eliminaron dos requisitos de conjuntos de cifrado, uno de Gestión de certificados y otro de Gestión de claves.
- El nivel de madurez 2 cambia de nombre de Básico a Fundacional; el nivel y su significado no cambian.
- Identificadores de cadena estables sustituyen a los números basados en posición, y las URL de categorías eliminaron los prefijos numéricos.
- Las herramientas de evaluación de Excel se retiran en favor de la autoevaluación web; siguen disponibles copias etiquetadas como 1.0.0.
¿Es nuevo en el modelo? Empiece por PKI Maturity Model: de operaciones ad hoc a operaciones gobernadas. La nueva categoría de Criptografía es más fácil de demostrar cuando dispone de un inventario, por lo que crear un inventario de activos criptográficos es un complemento lógico. Para la parte de plataforma, consulte 10 cosas que puede crear con ILM, o hable con nosotros sobre una evaluación.
