Inventario criptográfico desde el tráfico de red

Se puede construir buena parte de un inventario criptográfico de forma pasiva, leyendo los handshakes que cruzan la red: qué versiones de TLS y SSH usa cada servidor y cliente, qué grupos de intercambio de claves ofrecen y acuerdan, qué conjuntos de cifrado y, donde el handshake los muestra, qué algoritmos de clave pública y tamaños de clave. No se ve la criptografía que nunca pasa por un enlace vigilado. Por eso la vista de la red es la forma más rápida de cubrir todos los dispositivos, incluidos los que nadie inventarió, y hay que completarla con un inventario de certificados y las respuestas de los proveedores. Todas las hojas de ruta poscuánticas, empezando por la de la UE, ponen este inventario en primer lugar.

Qué contiene un inventario criptográfico

Un inventario útil responde, para cada sistema: qué protocolos y versiones usa, qué algoritmos de intercambio de claves y de firma, con qué tamaños de clave, qué certificados tiene y quién los emitió, qué biblioteca o producto aporta la criptografía, quién es el responsable del sistema y cuánto tiempo deben seguir siendo secretos los datos que protege. Publicado en un formato legible por máquinas, suele llamarse CBOM (cryptography bill of materials); el estándar CycloneDX define uno. Lo importante no es el documento, sino las decisiones que permite: qué migrar primero y qué preguntar a cada proveedor.

Qué muestra la red sin descifrar nada

Versiones de protocolo. TLS 1.0 y 1.1, SSH 1 y otras versiones obsoletas se ven al inicio de cada conexión.
Intercambio de claves ofrecido y elegido. En TLS 1.3, el ClientHello enumera los grupos y las claves que admite el cliente, y el ServerHello indica el grupo que elige el servidor. Así se ve directamente si una conexión usó un grupo clásico como X25519 o P-256, o el híbrido poscuántico X25519MLKEM768. SSH anuncia también en claro sus métodos de intercambio de claves.
Conjuntos de cifrado. El cifrado simétrico y el hash que acuerda cada conexión, lo que delata restos como 3DES o RC4.
Claves y certificados, donde viajan en claro. En TLS 1.2 la cadena de certificados del servidor se envía sin cifrar, así que se ven su algoritmo de firma y su tamaño de clave. Las claves de host de SSH se intercambian en claro. En TLS 1.3 el certificado va cifrado, de modo que para esos servidores hace falta un escaneo o inventario de certificados.
Claves débiles. Las claves públicas recogidas de los handshakes se pueden comparar entre sí. Las claves RSA que comparten un factor primo están directamente rotas y son la señal clásica de un dispositivo con un generador de números aleatorios deficiente, normalmente un equipo de red o un sistema embebido.
Todos los dispositivos del segmento. Impresoras, cámaras, pasarelas OT, equipos de red y servidores antiguos quedan cubiertos igual que los portátiles gestionados, justo donde las herramientas basadas en agentes no ven.

Qué queda oculto

La criptografía dentro de aplicaciones y bases de datos, como el cifrado de campos o una llamada a una biblioteca en su propio código.
Las claves y certificados guardados en disco, en almacenes de claves o en módulos HSM.
La firma de código y las actualizaciones de software, salvo que inspeccione el propio canal de actualización.
Las copias de seguridad y los archivos cifrados.
El tráfico de los segmentos que ningún sensor vigila y las conexiones que nunca cruzan un enlace vigilado.
El certificado de la mayoría de las conexiones TLS 1.3, como se ha dicho.

Cómo cubrir los huecos

Combine la vista de la red con otras tres fuentes: un inventario de certificados de su autoridad de certificación, de sus herramientas de gestión o de un escaneo activo; las listas de componentes de software (SBOM) y la documentación de los productos que usa; y cuestionarios a proveedores que pregunten, con fechas, cuándo admitirá cada producto el intercambio de claves híbrido poscuántico y las firmas poscuánticas. Después, ordene los sistemas con la desigualdad de Mosca, como explica la guía de criptografía poscuántica, y repita la medición en la red tras cada cambio para confirmar que ha surtido efecto.

Dónde encaja NetSenX

Es lo que hace NQCI, el inventario criptográfico de NetSenX. Está en versión preliminar, es visible en todos los planes y está activo desde el plan Pro, con el sensor de captura de paquetes activado en un agente Linux o un sensor en un puerto SPAN o TAP; el modo básico de macOS no ve los handshakes. Muestra qué conexiones del tráfico vigilado usan un intercambio de claves vulnerable a la computación cuántica y cuáles usan ya el híbrido poscuántico, señala claves públicas débiles y registra los cambios en el tiempo. No cambia ninguna criptografía ni hace cumplir a nadie; muestra dónde está usted.

Fuentes

Escrito por el equipo de NetSenX en TriStiX S.L. Preguntas: info@netsenx.com.