Deuda criptográfica: qué es, por qué se acumula y cómo saldarla

La criptografía está presente en todas partes, y precisamente por eso es tan fácil pasarla por alto. Protege los datos en tránsito, en reposo y en uso. Autentifica las conexiones, verifica las identidades de personas y máquinas, y garantiza la integridad del código, los contenedores y las actualizaciones de software . Funciona de forma discreta detrás de los protocolos de Internet, el tráfico de red, las aplicaciones, los servidores y todos los dispositivos que interactúan con ellos.

Y como simplemente funciona, se da por hecho que es seguro. Ojos que no ven, corazón que no siente. La ausencia de problemas visibles se confunde con una garantía: si un sistema está en funcionamiento, la criptografía subyacente debe de estar bien, ¿no? No del todo. Cuando la criptografía falla, rara vez se enciende un indicador en el panel de control ni se envía una alerta por Slack. Falla en silencio, dejando los sistemas expuestos mucho antes de que alguien pueda rastrear la interrupción o la brecha hasta un certificado caducado o un algoritmo débil.

Ese silencio es el problema. Año tras año, la criptografía desatendida y obsoleta se acumula hasta convertirse en un pasivo que se agrava con el tiempo y que solo ahora está saliendo a la luz en auditorías, marcos normativos y fallos operativos. Ese pasivo tiene un nombre: deuda criptográfica.

¿Qué es la deuda criptográfica?

La deuda criptográfica es la acumulación de elementos criptográficos desconocidos, no gestionados y obsoletos que se va acumulando a lo largo de años de prácticas del tipo «configurar y olvidarse». Se trata del peso colectivo de claves, certificados, algoritmos, protocolos y bibliotecas que se implementaron en su momento y nunca se gestionaron de forma activa, y cuya resolución resulta cada vez más costosa cuanto más tiempo se deja sin abordar.

La criptografía no se mantiene segura por sí sola. Envejece. Las investigaciones en curso revelan nuevas vulnerabilidades, los conocimientos matemáticos avanzan, los algoritmos mejoran y los ordenadores son cada vez más rápidos y potentes. Lo que se consideraba seguro en el momento de su implantación puede caer silenciosamente por debajo de un umbral de seguridad aceptable. Algoritmos como DES, MD5, SHA-1 y RSA-512, por ejemplo, llevan mucho tiempo obsoletos y son fáciles de explotar, pero siguen presentes en aplicaciones heredadas, firmware y servidores web.

La deuda se genera porque la mayoría de los equipos consideran que los componentes criptográficos son algo de lo que se encargará el proveedor del sistema operativo, la aplicación o la plataforma a través de actualizaciones rutinarias. Sin una gestión activa, herramientas y un marco de gobernanza que se sumen a esas actualizaciones, la criptografía se degrada de forma natural. Gran parte de la infraestructura criptográfica actual se diseñó hace más de treinta años y ha tenido dificultades para mantenerse al día con las arquitecturas informáticas modernas. El resultado es una base que está envejeciendo, que se malinterpreta ampliamente, que es en gran medida invisible y que puede fallar con un impacto significativo. La deuda criptográfica es omnipresente e invisible. «Es el problema que subyace a todos los demás problemas», así la describió Chris Hickman, director de seguridad de la información (CISO) de Keyfactor, durante unpaseo por el parque. En qué se diferencia la deuda criptográfica de la deuda técnica habitual

Todos los equipos de ingeniería conocen la deuda técnica: ese atajo que se toma para lanzar el producto ahora y refactorizarlo más adelante. La deuda criptográfica parece similar a primera vista, pero se comporta de forma muy diferente. La deuda criptográfica es como la deuda técnica, pero con un reloj de cuenta atrás.

Las diferencias son importantes porque cambian la forma en que hay que gestionar la deuda. La deuda técnica ordinaria suele ser una decisión que tú mismo has tomado y que puedes revertir. La deuda criptográfica, a menudo, no implica ninguna mala decisión: el algoritmo era adecuado cuando se eligió, pero el modelo de amenazas ha cambiado desde entonces. La deuda ordinaria la nota el equipo responsable del código en cada sprint. La deuda criptográfica la utilizan todos, pero no es responsabilidad de nadie, por lo que permanece invisible hasta que algo falla. Esto se debe, en parte, a que la criptografía no ha sabido evolucionar para adaptarse a las nuevas realidades técnicas, tanto en ingeniería como en gobernanza.

La tabla siguiente pone de manifiesto la diferencia.

Dimensión	Deuda técnica ordinaria	Deuda criptográfica
Origen	Un atajo que te has tomado. Envía ahora, refactoriza más tarde.	La decisión fue acertada en su momento; el modelo de amenazas ha cambiado.
Devengo	Más o menos lineal. Se paga cada vez que se modifica el código.	Una función escalonada. Nada, nada, nada, y luego una fecha de obsolescencia o una ruptura.
Visibilidad	El equipo responsable lo nota en cada sprint. Las consecuencias se dejan sentir más adelante.	Invisible. Las pruebas se superan, no se produce ningún deterioro. Deja de funcionar cuando la seguridad se va deteriorando con el tiempo. Requiere una detección activa.
Radio de la explosión	Normalmente se limita al módulo al que pertenece.	Supera los límites de confianza. Impone restricciones a todos los pares, dispositivos conectados y certificados emitidos.
¿Quién fija el plazo?	Sí, es así. Se descuida cuando se descuidan las prioridades.	El NIST, el CA/Browser Forum, los organismos reguladores, los adversarios. No es negociable, no es tu plazo.
Retroactividad	La refactorización lo resuelve todo. El código antiguo ya no existe.	La deuda de confidencialidad no se puede saldar. El tráfico captado hoy sigue siendo nuestro.
«Hecho» significa	Las pruebas han salido bien, la costura ha desaparecido.	Es objeto de controversia. «Crypto-agile» no se ha migrado; «hybrid» no está terminado.
Riesgo	Mayores costes de mantenimiento y menor productividad.	Vulnerabilidades de seguridad, interrupciones del servicio, pérdida de confianza.

Por qué se acumula la deuda criptográfica

La deuda criptográfica no se queda quieta. Hay varias fuerzas que la empujan hacia un punto de inflexión, y todas ellas están acelerando al mismo tiempo.

• La presión en materia de cumplimiento normativo va en aumento.
  Normativas como PCI DSS 4.0, NIS2 y DORA están formalizando las prácticas de seguridad criptográfica, y los requisitos de inventario se están convirtiendo en la norma. Los auditores plantean preguntas difíciles y esperan respuestas claras. Sin visibilidad, una auditoría se convierte en una carrera contrarreloj costosa en lugar de un simple informe.
• La vigencia de los certificados se está reduciendo.
  TLS /SSL La vigencia de los certificados ha pasado de 398 días en 2020 a 200 días en la actualidad, y se prevé que se reduzca a tan solo 47 días para 2029. Si además se tiene en cuenta el aumento del número de certificados que necesita una empresa, esto supone un incremento de entre 10 y 12 veces en la carga de trabajo relacionada con las renovaciones. Para una organización con tan solo 2 000 certificados, esto supone al menos 43 renovaciones al día. Una sola renovación olvidada puede provocar la interrupción de un servicio crítico.
• La cadena de suministro de software de código abierto ( software ) es cada vez más compleja.
  Entre el 70 % y el 90 % del software de código abierto ( software ) se compone actualmente de código de terceros, incluidas bibliotecas de software de código abierto ( open-source ), SDK de proveedores y API, y muchos de esos componentes incorporan sus propias funciones criptográficas. Cuando surge un fallo, los equipos que no disponen de un inventario dedican su tiempo de respuesta a buscar el problema en lugar de solucionarlo.
• La transición hacia la era poscuántica está reduciendo el margen de tiempo disponible.
  Las nuevas normas de criptografía poscuántica (PQC), los plazos establecidos para la retirada progresiva de la criptografía convencional y la amenaza inmediata de los ataques del tipo«Harvest Now, Decrypt Later» (recoger ahora, descifrar más tarde)hacen que el margen de tiempo para una migración gradual se esté reduciendo. Los expertos prevén que, en un plazo de entre 5 y 15 años aproximadamente, habrá ordenadores cuánticos capaces de descifrar la criptografía de clave pública.

Estas fuerzas no son el problema de fondo. Son el foco de atención que obliga a las organizaciones a hacer frente a décadas de deuda acumulada.

Dónde reside la deuda criptográfica

La criptografía se esconde en más lugares de los que la mayoría de los equipos imaginan. Un ordenador personal estándar viene de fábrica con más de 500 elementos criptográficos integrados en el firmware, los sistemas operativos y las aplicaciones. Si multiplicamos esa cifra por el conjunto de los sistemas de una empresa, queda clara la magnitud de la deuda oculta. Es compleja, fragmentada y, a menudo, invisible, y se acumula en varias capas.

• Sistemas centrales:claves y certificados ocultos en almacenes de claves no gestionados, archivos de configuración y servicios a nivel del sistema dentro de los sistemas operativos, las bases de datos y los servidores de aplicaciones. Cuando no están documentados, provocan interrupciones del servicio y fallos en las auditorías.
• Dispositivos finales:cientos de elementos por dispositivo en el firmware, los sistemas operativos y las aplicaciones. Las herramientas de protección de dispositivos finales suelen detectar estos activos, pero rara vez los inventarían ni los gestionan.
• Infraestructura de red:TLS, SSH y comunicaciones seguras mediante IPSec; sin embargo, los conjuntos de cifrado débiles, los certificados caducados y las configuraciones erróneas interrumpen con frecuencia los servicios y dejan los datos expuestos.
• Entornos en la nube:los servicios de PKI, KMS y HSM están dispersos entre múltiples proveedores y cuentas, lo que dificulta su supervisión.
• Entornos de CI/CD:claves, bibliotecas, algoritmos y raíces de confianza dispersas por el código fuente, los binarios, las estaciones de trabajo de los desarrolladores y las herramientas del proceso de integración, lo que genera riesgos en la cadena de suministro y retrasa los lanzamientos.
• Dependencias de terceros y de « open-source »:riesgo criptográfico heredado que no se incluye en el inventario si no se dispone de una lista de materiales criptográficos (CBOM).
• Sistemas de seguridad:Los HSM, los KMS, las PKI y las herramientas de gestión del ciclo de vida de los certificados, diseñadas para regular la criptografía, suelen funcionar de forma aislada, lo que agrava la fragmentación en lugar de resolverla.

Los riesgos de la deuda criptográfica

Las vulnerabilidades criptográficas no son fallos técnicos aislados. Se trata de riesgos sistémicos que afectan al tiempo de actividad, al cumplimiento normativo y a la confianza, razón por la cual los fallos criptográficos figuran entre los «Top 10» de OWASP. La exposición va mucho más allá de los sistemas internos: el 91 % de los CISO señalan un aumento de los incidentes de ciberseguridad relacionados con terceros, pero solo el 3 % tiene visibilidad sobre sus cadenas de suministro de « software ». Las clases concretas de vulnerabilidades incluyen las siguientes.

• Claves codificadas, reutilizadas y expuestas:las claves de firma de código, las claves SSH y los tokens de API incrustados en el código fuente y en los archivos de configuración se filtran a través de repositorios públicos, auditorías e ingeniería inversa. Las filtraciones de secretos en los repositorios de open-source aumentaron un 12 % interanual, y las claves privadas SSH y de cifrado representaron más del 40 % de dichas filtraciones.
• Protocolos no cifrados y obsoletos:Telnet, LDAP, SMTP y SNMPv2 siguen transmitiendo datos en texto plano, y los errores de configuración suelen dejar activas las versiones no cifradas. En un estudio realizado en 2023 sobre más de 200 TB de tráfico de red, el 61 % estaba totalmente sin cifrar y hasta el 80 % presentaba algún fallo en su cifrado que podía ser vulnerado.
• Algoritmos y conjuntos de cifrado obsoletos:Algoritmos como DES, MD5, SHA-1 y RSA-512 llevan mucho tiempo en desuso y son fáciles de vulnerar, pero siguen presentes en sistemas heredados y muchas organizaciones aún confían en ellos. Incluso los sistemas que admiten un cifrado sólido a veces recurren a protocolos y conjuntos de cifrado débiles, lo que los expone a ataques de rebaja de nivel.
• Riesgos relacionados con los certificados:los certificados caducados, autofirmados y de larga duración son una de las principales causas de interrupciones del servicio, que pueden suponer un coste de entre 5.600 y 9.000 dólares por minuto, ya que los equipos se ven obligados a reemitirlos y sustituirlos con urgencia. Analizamos la gestión de certificados con todo detalle en nuestraguía específica.
• Criptografía no conforme y vulnerable a los ataques cuánticos:la criptografía personalizada no documentada, basada en bibliotecas defectuosas, puede pasar desapercibida durante años hasta que una auditoría la ponga de manifiesto, y algoritmos de uso generalizado como RSA y ECDSA siguen expuestos a futuros ataques cuánticos.

Si se plantean correctamente, se trata de riesgos empresariales, no solo técnicos. Uninventario criptográficose integra directamente en la gestión de riesgos empresariales (ERM), donde los fallos criptográficos se traducen en riesgos operativos, de reputación y financieros, incluyendo repercusiones en el balance, multas regulatorias y una menor resiliencia del servicio.

La criptografía poscuántica (PQC) y el reloj cuántico

La computación cuántica supone una amenaza fundamental para la criptografíaque protege la Internet moderna. En 1994, el algoritmo de Shor demostró que un ordenador cuántico lo suficientemente potente podría resolver de manera eficiente los problemas de factorización de números grandes y del logaritmo discreto, que constituyen la base de la criptografía asimétrica actual. Se prevé que, en un plazo de entre 5 y 15 años, exista un ordenador cuántico con capacidad criptográfica suficiente para descifrar la criptografía de clave pública, razón por la cual el sector está avanzando ahora hacia la migración de su infraestructura criptográfica a estándares resistentes a la computación cuántica.

Esa migración es difícil y delicada. Afecta a todas las unidades de negocio y a toda la cadena de valor, exige recursos considerables y puede llevar una década o más de planificación y ejecución hasta completarse. Es posible que algunos sistemas existentes nunca logren una transición sin problemas. Descuidar la deuda criptográfica complica aún más las cosas: cada clave desconocida, cada algoritmo no documentado y cada certificado no gestionado añade fricción a una migración hacia una criptografía resistente a los ataques cuánticos que ya de por sí es compleja, lo que retrasa la protección real frente a adversarios con capacidad cuántica.

La amenaza no se limita al futuro. En los ataques del tipo «recoger ahora, descifrar más tarde» (también denominados «almacenar ahora, descifrar más tarde»), los atacantes capturan datos cifrados hoy y los almacenan para descifrarlos una vez que los ordenadores cuánticos alcancen su madurez. Por lo tanto, los datos con un largo periodo de confidencialidad están en peligro ya mismo. Si quieres profundizar en el tema, los artículos explicativos de Keyfactorsobre «harvest now, decrypt later», la criptografía poscuántica y los pasos clave para una criptografía resistente a la computación cuántica son puntos de partida útiles.

Inventario criptográfico: la base para saldar la deuda

No se puede gestionar lo que no se ve, ni proteger lo que no se encuentra. Un inventario criptográfico es la base fundamental para obtener una visión basada en el riesgo de su entorno criptográfico. Se trata de un registro dinámico y exhaustivo de todos los activos criptográficos presentes en su infraestructura digital ampliada, y responde a las preguntas que realmente importan: ¿qué tenemos?, ¿dónde está?, ¿qué eficacia tiene? y ¿qué debemos solucionar primero?

Un buen inventario incluye claves, certificados, secretos, algoritmos, almacenes de claves, cifrados, protocolos y bibliotecas, además de cómo se configura y utiliza cada uno de ellos en la práctica. Esa última parte es lo que distingue a un inventario completo de un CBOM.

CBOM frente al inventario criptográfico operativo

Una lista de componentes criptográficos (CBOM, por sus siglas en inglés) recoge las capacidades criptográficas integradas en una aplicación, como los algoritmos compatibles (AES-256, RSA-2048, etc.), las bibliotecas (OpenSSL, Bouncy Castle, etc.) y los tipos de claves. Se puede generar a partir del código fuente y ofrece una visión rápida de la arquitectura criptográfica de una versión software . Lo que no te indica es cómo está configurada esa software en tu entorno. Un CBOM puede indicar que una aplicación es compatible tanto con SHA-1 como con SHA-256, pero no revelará cuál de los dos has habilitado realmente.

Un inventario criptográfico operativo aporta esa capa que faltaba: los certificados, claves, conjuntos de cifrado y configuraciones específicos que se utilizan en la práctica. La mejor forma de entender el CBOM es como un elemento fundamental del inventario operativo más amplio, que también recoge la configuración, el uso, las dependencias y las políticas en sistemas heterogéneos.### Por qué es difícil crearlo

La enorme omnipresencia de la criptografía hace que la elaboración de un inventario exhaustivo sea un proyecto exigente. Los activos se ocultan en fuentes heterogéneas repartidas entre sistemas heredados, servicios en la nube y aplicaciones de terceros compiladas. Las dependencias de terceros limitan la visibilidad. Las herramientas tradicionales de gestión de vulnerabilidades y amenazas nunca se diseñaron para crear un inventario criptográfico, por lo que dejan lagunas. Los entornos cambian constantemente, por lo que el inventario debe mantenerse actualizado. La automatización es esencial para alcanzar la escala necesaria, pero las herramientas automatizadas tienen puntos ciegos, lo que significa que sigue siendo necesaria la validación por parte de expertos para filtrar el ruido y confirmar qué es lo que realmente se está utilizando.

Diez principios estratégicos

El documento técnico «Inventario criptográfico» propone diez principios para orientar esta labor:

1. buscar el apoyo de la dirección,
2. ampliarse gracias a la automatización,
3. optimizar la intervención manual,
4. dar prioridad a las iniciativas,
5. aprovechar el contexto para aportar valor,
6. generar información útil,
7. aprovechar la IA para ampliar las capacidades,
8. incluyen la criptografía de los proveedores,
9. definir una fuente de referencia fiable, y
10. Elaborar una estrategia para gestionar los falsos positivos.

Juntos convierten los hallazgos iniciales en un programa priorizado y basado en el riesgo, en lugar de un ejercicio interminable de recopilación de datos.

¿De quién es?

Dado que la criptografía la utiliza todo el mundo pero no es propiedad de nadie, la responsabilidad debe asignarse de forma deliberada. En la mayoría de las grandes organizaciones, esa responsabilidad recae en el CIO o el CISO, de modo que un ejecutivo de alto nivel es el responsable último de la criptografía y del inventario criptográfico. La responsabilidad diaria suele distribuirse entre DevSecOps, TI, un equipo criptográfico especializado y el departamento de cumplimiento de normas de seguridad mediante un modelo RACI (responsable, a quien se le exige rendir cuentas, consultado, informado), en el que los expertos en criptografía actúan como autoridad consultiva para que las decisiones nunca se tomen sin contar con los conocimientos especializados adecuados.

Agilidad criptográfica

La agilidad criptográfica es la capacidad de cambiar de forma rápida y eficaz entre algoritmos, bibliotecas, claves, tokens, certificados y protocolos sin que ello suponga una interrupción operativa significativa. Debe considerarse una propiedad fundamental de la infraestructura criptográfica moderna, ya que es lo que permite reducir la deuda criptográfica de forma sostenible, en lugar de tener que realizar múltiples limpiezas aisladas.

Es fundamental señalar que la necesidad de agilidad no está ligada únicamente a la amenaza cuántica. La criptografía no debe ser un componente de la pila tecnológica de una empresa que se configure una vez y se olvide. Hay numerosos factores que obligan a realizar actualizaciones y cambios con el paso del tiempo, entre ellos la degradación de la seguridad, los requisitos de compatibilidad y la evolución de las normas de cumplimiento. La agilidad se consigue, en parte, mediante la abstracción de la API de las primitivas criptográficas, de modo que los algoritmos puedan intercambiarse cuando sea necesario, en lugar de estar integrados de forma fija en cada aplicación. Para profundizar en cómo avanzar hacia este objetivo, consulta la guía de Keyfactorsobre la «criptoagilidad» y la preparación para la migración poscuántica.

Modernización criptográfica: un proceso repetible desde el descubrimiento hasta la «criptoagilidad»

La modernizaciónno es una decisión única en materia de criptografía poscuántica. Se trata de un programa por etapas, y organismos reguladores como la CISA, la NSA y el NIST dejan claro que las empresas no deben pasar directamente al despliegue de la criptografía poscuántica (PQC). El consenso es «primero el inventario», seguido de la evaluación de riesgos y una arquitectura criptoágil. El propio modelo de madurez de criptoagilidad del NIST refuerza esta idea: las organizaciones no alcanzan un nivel repetible de agilidad hasta que el descubrimiento y la corrección de problemas criptográficos se automatizan y se mantienen de forma continua. Un programa práctico se desarrolla a lo largo de cuatro fases.

1. Detección e inventario criptográfico.
   Establecer un inventario criptográfico proactivo vinculado a los sistemas críticos para el negocio, correlacionando los activos con la elección de algoritmos, el tamaño de las claves, los plazos de caducidad, las cadenas de confianza y los patrones de uso. El resultado es una referencia defendible y un mapa de riesgos, no solo más datos.
2. Corrección y refuerzo basados en el riesgo.
   Elimina las dependencias frágiles sometiendo los certificados no gestionados y las CA «en la sombra» a un control del ciclo de vida; elimina los algoritmos obsoletos; actualiza los tamaños de clave débiles; corrige las configuraciones de protocolo inseguras y estandariza la emisión y la firma. Refuerza las prácticas básicas de seguridad antes de incorporar la PQC.
3. Automatización y «criptoagilidad» a gran escala.
   Convierte la emisión, renovación, rotación y revocación en flujos de trabajo coordinados y basados en políticas, integrados con plataformas en la nube y de DevOps. Incorpora una supervisión continua del estado de seguridad y patrones de rotación con un tiempo de inactividad mínimo, de modo que los cambios criptográficos se conviertan en una tarea rutinaria y segura de repetir.
4. Gobernanza para la adopción sostenible de la PQC.
   Utilizar los organismos de normalización (plazos del NIST, la IETF, el ETSI, la ISO/IEC y la CNSA 2.0) como guía, traducir sus recomendaciones en políticas y patrones de diseño aplicables, y llevar a cabo la gobernanza siguiendo un ritmo que se ajuste a las métricas operativas y a la presentación de informes a la dirección.

En resumen, la visibilidad establece la verdad, la automatización elimina la fragilidad y la criptoagilidad hace que el progreso sea repetible.

Cómo Keyfactor ayudarte Keyfactor

La reducción de la «deuda criptográfica» consiste, en última instancia, en pasar de considerar la criptografía como un pasivo oculto a verla como una capacidad regulada, y ahí es precisamente donde se centra « Keyfactor ».

• Garantizar la visibilidad.
  Keyfactor AgileSecproporciona visibilidad criptográfica y un inventario de los centros de datos, las cuentas en la nube, los terminales, los entornos OT/IoT y los entornos de aplicaciones, incluyendo los flujos de trabajo de firma que a menudo quedan fuera del ámbito de visibilidad de las PKI tradicionales.
• Consolidar las operaciones relacionadas con los certificados.
   Keyfactor Command integra los certificados no gestionados y las CA en la sombra en una gestión automatizada del ciclo de vida, de modo que la emisión, la renovación, la rotación y la aplicación de políticas se convierten en operaciones controladas en lugar de medidas de emergencia.
• Estandarizar la emisión y la firma.
   Keyfactor EJBCA ofrece una PKI de nivel empresarial preparada para la era cuántica, y Keyfactor SignServer centraliza la firma de código, firmware y documentos, sustituyendo las implementaciones locales a medida por servicios compartidos auditables.
• Proporcionar una capa de control para la «criptoagilidad».
  En conjunto, estos componentes proporcionan la capa de control persistente que permite poner en práctica la modernización en el día a día. Gracias a la colaboración entre Keyfactor e IBM Consulting, esa capa de control se combina con una estrategia resistente a la computación cuántica y una implementación a escala empresarial, lo que permite traducir las decisiones de la hoja de ruta en medidas secuenciadas y justificables