No se puede proteger lo que no se ve: el argumento fundamental para el descubrimiento criptográfico.

Cada organización en funcionamiento RSAEl cifrado basado en ECC, TLS o AES tiene un conjunto de datos criptográficos. La mayoría de las organizaciones no tienen idea de qué contiene.

Eso no es una crítica; es una realidad estructural. Criptografía Nunca se diseñó para ser administrado como los servidores o las aplicaciones. No tiene dirección IP. No genera ninguna alerta al finalizar su vida útil. Se ejecuta silenciosamente en segundo plano en casi todos los sistemas que usted utiliza, hasta que algo falla, hasta que un organismo regulador solicita documentación que usted no puede proporcionar, o hasta que un modelo de amenazas que usted descartó como teórico se vuelve lo suficientemente real como para que alguien con recursos reales decida actuar al respecto.

El resultado es predecible. Las organizaciones acumulan deuda criptográfica durante años sin percatarse de su alcance total. SHA-1 persiste en sistemas que nadie ha tocado en años. Triple-DES Sigue funcionando en terminales de pago configuradas en otra época. Las claves codificadas se encuentran en repositorios que los desarrolladores dejaron de usar hace mucho tiempo. Los certificados operan en una infraestructura que nadie posee formalmente. Y en algún lugar de su entorno en la nube, un microservicio se ejecuta con configuraciones de cifrado predeterminadas que nadie decidió deliberadamente.

Este es el problema del descubrimiento criptográfico, y está presente en todas las demás iniciativas criptográficas que su organización deberá ejecutar. Preparación para el cumplimiento, migración post-cuántica, gestión del ciclo de vida del certificadoy la gobernanza clave: todas ellas requieren saber con qué se cuenta antes de que pueda comenzar cualquier trabajo significativo.

La verdadera magnitud del problema 

Cuando las organizaciones intentan por primera vez un inventario criptográficoConstantemente se sorprenden por lo que encuentran, no porque los hallazgos sean inesperados, sino porque son muchos y muy pocos estaban registrados en algún sistema de información existente.

Según el documento n.° 158 del BIS, entre el 70 y el 90 por ciento del software empresarial se ensambla a partir de componentes de terceros. Cada uno de esos componentes conlleva decisiones criptográficas que la organización que los implementa nunca tomó directamente: versiones de bibliotecas vinculadas a dependencias obsoletas, conjunto de cifrado Valores predeterminados establecidos en el momento en que se escribió la biblioteca, elecciones de algoritmos integradas en el código que se incluye en un producto cuyo proveedor nunca ha publicado una divulgación criptográfica.

La mecánica cuántica aplicada Migración de PQC El marco de trabajo estima más de 320 llamadas a funciones criptográficas en una sola aplicación de banca móvil. En el conjunto de sistemas de una empresa, el número total de activos criptográficos, algoritmos, claves, certificados, protocolos e implementaciones de bibliotecas asciende a cientos de miles. La mayoría de las organizaciones solo han documentado formalmente una pequeña fracción de esta cantidad.

La diferencia entre lo que las organizaciones creen que poseen en su infraestructura criptográfica y lo que realmente está en producción no es una discrepancia menor en el inventario. Es la causa principal de cada incumplimiento normativo, de cada retraso en la corrección de errores y de cada proyecto de migración que tarda el doble de lo previsto. 

¿Por qué su sistema de herramientas actual tiene puntos ciegos estructurales?

El instinto natural al iniciar un inventario criptográfico es recurrir a las herramientas existentes: ejecutar el escáner de vulnerabilidades, exportar el sistema de gestión de certificados, consultar la CMDB. Si bien cada una de estas herramientas captura información útil, todas presentan limitaciones estructurales que ninguna configuración puede superar.

Plataformas de gestión de certificados Gestiona los certificados que registraste con ellos. No tienen ningún mecanismo para detectar certificados aprovisionados fuera de tu flujo de trabajo gestionado, el certificado que un desarrollador solicitó directamente a una CA pública, el que generó automáticamente una plataforma en la nube o el que aún se ejecuta en un entorno de prueba que nunca se desactivó. 

Escáneres de vulnerabilidad Informan sobre qué es accesible y qué servicios están en funcionamiento. No revelan qué conjuntos de cifrado se están negociando activamente en el tráfico este-oeste entre las capas de su aplicación, las conexiones internas de servicio a servicio que son invisibles en el perímetro y que casi nunca se rigen por las mismas políticas TLS que el tráfico externo entrante.

CMDB No registran la infraestructura oficialmente aprovisionada. Omiten los recursos en la nube implementados fuera de los flujos de trabajo estándar, los dispositivos OT que la administración de instalaciones aprovisionó de forma independiente, los sistemas de empresas adquiridas que se integraron en las operaciones pero nunca en el registro de activos, y cualquier sistema cuyo propietario abandonó la organización sin documentarlo.

No se trata de fallos de la herramienta. Son limitaciones de diseño. Cada herramienta fue construida para un propósito específico, y ese propósito no era descubrimiento criptográficoPara cerrar estas brechas, es necesario tratar el descubrimiento como una disciplina de múltiples capas, no como un simple escaneo que se realiza una sola vez y luego se olvida.

Las cinco capas de descubrimiento y lo que revela cada una.

Un inventario criptográfico completo requiere cinco capas de descubrimiento distintas. No son intercambiables ni redundantes. Cada una revela lo que las demás, por su estructura, no pueden.

Método de capas	Lo que encuentra de forma única
Análisis pasivo del tráfico de red	Negociación de protocolos en vivo en producción, lo que realmente se está utilizando, no solo lo que está configurado.
Análisis de código estático	Claves codificadas, importaciones de bibliotecas obsoletas y opciones de algoritmos fijas en la lógica de la aplicación.
Configuración y escaneo de certificados	Políticas de conjuntos de cifrado en infraestructura administrada; certificados espejo a través de registros CT.
Análisis binario y de tiempo de ejecución	Postura criptográfica de los dispositivos del proveedor, sistemas OT y firmware que no se puede leer directamente.
Investigación manual	Protocolos personalizados, esquemas propietarios, integraciones no documentadas y contexto organizacional.

Capa 1: Análisis pasivo del tráfico de red

El análisis pasivo de redes es el único método de descubrimiento que revela qué protocolos criptográficos se negocian realmente en producción, en contraposición a lo que las configuraciones indican que debería ser negociable. Esta distinción es más importante de lo que la mayoría de los equipos creen. 

Un servidor configurado para admitir TLS 1.3 Aún es posible negociar TLS 1.1 con puntos finales heredados que no pueden ofrecer un mejor rendimiento. Un balanceador de carga que aplica conjuntos de cifrado modernos en el perímetro no tiene control sobre las conexiones de backend entre los servidores de aplicaciones y las bases de datos, que ejecutan el protocolo de cifrado con el que fue programada originalmente la aplicación. Implementado en derivaciones de red o puertos SPAN en puntos de agregación clave, el análisis pasivo captura metadatos de handshake TLS en tiempo real de esas conexiones sin descifrar el tráfico ni sobrecargar los sistemas de producción.

El programa de inventario criptográfico de Santander, presentado por Jaime Gómez García en la Conferencia PQC 2025 del Consorcio PKI, logró visibilidad en 9,000 instancias de Apache a nivel mundial mediante el uso de herramientas existentes adaptadas, en lugar de plataformas de descubrimiento diseñadas específicamente para este fin. La capa 1 es donde suelen surgir las sorpresas más significativas desde el punto de vista operativo.

Capa 2: Análisis de código estático 

El análisis estático examina los repositorios de código fuente en busca de material criptográfico integrado directamente en la lógica de la aplicación, como valores de clave codificados, importaciones de bibliotecas obsoletas y parámetros explícitos de tamaño de clave en las llamadas de generación de claves. Estas representan decisiones criptográficas fijas a nivel de código que no se pueden modificar sin una redistribución completa.

Una llamada a hashlib.sha1() en una aplicación de producción no es solo una advertencia sobre un algoritmo obsoleto. Es una tarea de corrección que requiere un cambio de código, un ciclo de compilación, un ciclo de pruebas y un despliegue. En una base de código empresarial que contiene cientos de miles de llamadas a funciones criptográficas, la capa 2 es donde se hace visible por primera vez el verdadero alcance del esfuerzo de migración a nivel de aplicación. 

Capa 3: Configuración y escaneo de certificados 

Esta capa cubre las políticas de conjuntos de cifrado configuradas en balanceadores de carga, firewalls y concentradores VPN, así como el inventario de certificados en toda su red. PKI entorno e infraestructura en la nube.

Los registros de Transparencia de Certificados (CT) son la fuente menos utilizada en esta capa. Cada certificado de confianza pública Autoridad de certificación (CA) es necesario presentar cada certificado Se emiten registros CT, que son de acceso público. Una consulta de registros CT sobre sus dominios devuelve todos los certificados emitidos para ellos, incluidos aquellos que nunca se registraron en su sistema de gestión de certificados. Estos son sus certificados sombra, y están sujetos a la normativa, independientemente de que aparezcan o no en su inventario gestionado.

Capa 4: Análisis binario y en tiempo de ejecución 

Para dispositivos de proveedores, firmware integrado y sistemas OT donde no se dispone del código fuente, el análisis binario y en tiempo de ejecución es el único método viable para evaluar la seguridad criptográfica real. Esto se aplica a cajeros automáticos y terminales de punto de venta, dispositivos de red, sistemas de control industrial y cualquier dispositivo cuya implementación criptográfica resida en un firmware que su organización no haya desarrollado y que no pueda inspeccionar directamente.

NIST CSWP 39 Los documentos indican que el ciclo promedio de actualización de un sistema de tecnología operativa (OT) es de 20 años. En la práctica, esto significa que los algoritmos criptográficos obsoletos pueden permanecer arraigados en entornos de tecnología operativa durante una década o más, sin ningún mecanismo de actualización ni proceso de gobernanza que los haya intervenido. 

Capa 5: Investigación manual

revisiones de documentación de arquitectura, HSM y KMS El análisis de los registros de auditoría, la documentación de seguridad del proveedor y las entrevistas estructuradas con los responsables de la plataforma y el sistema completan el panorama del descubrimiento. La investigación manual revela los protocolos personalizados, los esquemas de cifrado propietarios y las integraciones no documentadas que cualquier capa automatizada pasaría por alto, y proporciona el contexto organizacional que transforma los hallazgos técnicos brutos en información realmente útil.

Cada capa descubre lo que las demás no pueden. Omitir cualquiera de ellas implica heredar permanentemente sus puntos ciegos.

Las obligaciones de cumplimiento ya están en vigor. 

Para las organizaciones sujetas a DORA, PCI DSS 4.0 o NIS2Un inventario criptográfico no es una recomendación de buenas prácticas, sino una obligación legal vigente y de obligado cumplimiento. 

Artículo 9.2 de DORA Requiere que las entidades financieras mantengan un registro actualizado de todos los activos de información, incluidos explícitamente los activos criptográficos, para todos los sistemas de TIC que dan soporte a funciones críticas o importantes. Artículo 7.4 de DORA Además, exige que este registro incluya todos los certificados digitales y los dispositivos en los que se almacenan. Ambas disposiciones han sido exigibles desde Enero 17, 2025.

Requisito 12.3.3 de PCI DSS Requiere un inventario documentado y mantenido continuamente de todos los conjuntos de cifrado criptográfico y protocolos en uso, con una justificación comercial por cada entrada, monitoreo activo de viabilidad y una estrategia de respuesta documentada para cualquier vulnerabilidad criptográfica identificada. Este requisito ha sido exigible desde Marzo 31, 2025.

Ninguna de estas fechas límite es futura. Ambas son obligaciones vigentes hoy. Una organización que no puede presentar la documentación requerida durante una revisión de supervisión no tiene una laguna en su plan estratégico; tiene una laguna en un requisito exigible que está en vigor desde principios de este año.

La justificación comercial para crear un inventario criptográfico no requiere una evaluación de amenazas cuánticas ni un mandato formal para una migración post-cuántica. El mero cumplimiento normativo ha sido una justificación más que suficiente desde enero de 2025.

Cómo la consultoría en cifrado puede ayudarle a crear su inventario criptográfico.

Comprender el problema del descubrimiento es el primer paso. Contar con la plataforma adecuada para abordarlo es el segundo, y ahí es donde entra en juego CBOM Secure.

CBOM seguro es la plataforma de descubrimiento e inventario criptográfico automatizado (ACDI) de Encryption Consulting, diseñada específicamente para ejecutar las cinco capas de descubrimiento como una única capacidad integrada. Los sensores de red pasivos capturan la negociación de protocolos en tiempo real en el tráfico de producción. El análisis estático se integra directamente con los sistemas de control de versiones para escanear el código propio y los árboles de dependencias de terceros. La enumeración de certificados se ejecuta continuamente contra los registros CT y los sistemas de gestión de certificados. Las consultas a la API en la nube cubren el cifrado en reposo y las configuraciones de gestión de claves en todas las cuentas en la nube conectadas. Los flujos de trabajo de investigación manual alimentan directamente el CBOM en tiempo real, lo que garantiza que nada descubierto fuera de las herramientas automatizadas pase desapercibido.

Cada entrada de CBOM se enriquece automáticamente con el estado de vulnerabilidad cuántica, el enrutamiento de propiedad y el etiquetado de brechas de cumplimiento normativo en DORA, PCI DSS 4.0y NIS2, de modo que su equipo siempre trabaje a partir de una visión priorizada y contextualizada del patrimonio, no de una recopilación de hallazgos sin procesar.

CBOM Secure no genera una lista de hallazgos y deja que su equipo determine cómo abordarlos. Crea un sistema de registro controlado y mantenido continuamente que transforma los hallazgos en acciones, desde el primer análisis hasta cada cambio posterior en su entorno.

Donde empezar 

El alcance total de un inventario criptográfico puede resultar abrumador. No es necesario abordarlo todo de una vez.

• Comience con las capas 1 y 3: Sus balanceadores de carga, concentradores VPN y proxies inversos ya están en su CMDB, tienen propietarios identificables y sus configuraciones criptográficas se pueden descubrir con las herramientas que la mayoría de las organizaciones ya tienen.
• Construye el inventario gradualmente, no todo a la vez: El marco de migración de Applied Quantum PQC recomienda lograr primero una cobertura integral de las capas 1 y 2, con un plazo de semanas a meses según el tamaño del sistema, y ​​comenzar la evaluación de riesgos de esas entradas de inmediato, en lugar de esperar a tener un inventario completo antes de iniciar cualquier corrección. Puede comenzar a secuenciar las correcciones en lo que ya conoce mientras continúa mejorando la visibilidad del resto.
• Contacta ya con tus proveedores estratégicos: Si algún componente de su entorno, suministrado por un proveedor, depende de una biblioteca criptográfica o un módulo de seguridad de hardware (HSM) cuya actualización posterior a la computación cuántica no se ha comunicado, es necesario iniciar esa conversación hoy mismo. Los plazos de los proveedores están completamente fuera de su control. La única variable que puede influir es el momento en que inicie la comunicación.

Conclusión

El descubrimiento criptográfico El problema no es un desafío futuro, sino una realidad actual. La mayoría de las organizaciones operan con importantes discrepancias entre lo que creen que contiene su infraestructura criptográfica y lo que realmente está en producción. Estas discrepancias no son inofensivas. Son la razón por la que los proyectos de migración se estancan, las auditorías de cumplimiento revelan hallazgos inesperados y los plazos de remediación se extienden mucho más allá de las estimaciones iniciales.

Se estimaba que la migración de SHA-1 a SHA-256 tardaría cinco años. Tardó más de diez. La transición poscuántica es más compleja en todos los sentidos, y las obligaciones de cumplimiento de DORA y PCI DSS 4.0 ya están en vigor. Cada mes sin un inventario completo y controlado supone un mes de riesgo creciente.

Saber con qué se cuenta no es la meta final, sino el punto de partida. Pero es el primer paso que deben superar todas las demás iniciativas, procesos de cumplimiento, migración y gobernanza. Las organizaciones que logren esa visibilidad ahora estarán preparadas cuando sea necesario.

Parte 2 Esta serie trata sobre qué hacer con lo que se encuentra: cómo una lista de materiales criptográficos transforma los datos de descubrimiento en un sistema de registro gobernado y cómo utilizarlo para impulsar la evidencia de cumplimiento, la priorización de riesgos y la planificación de la migración de PQC.