Análisis del tráfico cifrado: inspección del tráfico cifrado sin descifrado

El análisis del tráfico cifrado consiste en deducir datos relevantes para la seguridad sobre una sesión de red a partir de lo que sigue siendo observable cuando la carga útil está cifrada: atributos del protocolo de establecimiento de conexión, tamaño y sincronización de los paquetes, registros de flujo y contexto de destino. En lugar de descifrar el contenido, se leen los metadatos que el cifrado deja necesariamente al descubierto.

Se trata de la rama del análisis del tráfico de red dedicada específicamente al tráfico cifrado, y existe porque los atacantes han adoptado el cifrado al igual que el resto de usuarios. Esta guía aborda qué datos se conservan tras el uso de Transport Layer Security (TLS) 1.3, QUIC y Encrypted Client Hello (ECH); cómo el análisis de huellas de TLS convierte los handshakes en texto claro en identidades de cliente; y en qué casos sigue mereciendo la pena el coste que supone el descifrado.

¿Qué es el análisis del tráfico cifrado?

El análisis general del tráfico estudia los flujos de todo tipo, incluido el texto sin cifrar; esta página aborda únicamente la cuestión específica del tráfico cifrado: qué señales siguen permitiendo la detección una vez que la carga útil ya no es legible.

Esta disciplina, a menudo abreviada como ETA, también se conoce como «inspección de tráfico cifrado» y «análisis de tráfico cifrado», tres denominaciones que hacen referencia a un mismo enfoque centrado en los metadatos. Dentro de un programa de seguridad de red, forma parte de la detección y respuesta de red (NDR), complementando la detección y respuesta en los terminales (EDR) mediante la supervisión del tráfico procedente de dispositivos a los que ningún agente puede acceder.

¿Qué volumen de tráfico y qué cantidad malware realmente cifrados?

La respuesta sincera depende de qué población se analice. Aproximadamente el 95 % o más del tráfico web se carga actualmente a través de HTTPS, y en Android y Mac se supera el 99 % solo en el caso de los sitios web públicos (Informe de transparencia de Google, datos de octubre de 2025 aproximadamente). El anuncio de Google de octubre de 2025 sobre el uso de HTTPS por defecto corrobora estas cifras.

Los ataques se adaptaron a ello. Los datos de telemetría de un cloud registraron que el 87,2 % de los 32 100 millones de ataques bloqueados llegaron a través de canales cifrados entre octubre de 2023 y septiembre de 2024, lo que supone un aumento interanual del 10,3 % (Network World). En el mismo conjunto de datos, malware el 86,5 % de los ataques cifrados bloqueados, y el sector manufacturero fue el más atacado, con 13 500 millones de ataques.

El informe semestral sobre amenazas de WatchGuard reveló que el 96 % del malware bloqueado malware a través de TLS durante el segundo semestre de 2025 (WatchGuard a través de GlobeNewswire, publicado en febrero de 2026).

Las cargas de páginas, los ataques bloqueados y malware bloqueado malware tres conjuntos distintos que se han medido a lo largo de tres periodos diferentes: tres datos, no una sola tendencia.

Una tabla de tres filas que desglosa, según población, periodo y origen, el porcentaje de carga de páginas HTTPS, los ataques bloqueados a través de canales cifrados y malware bloqueado malware TLS.

Lo que sobrevive al cifrado: los metadatos que siguen llegando a tus sensores

Cada sesión cifrada comienza con una negociación, gran parte de la cual se realiza en claro. El protocolo de enlace TLS expone el mensaje «ClientHello» con las suites de cifrado ofrecidas, la lista de extensiones y los valores de la negociación del protocolo de capa de aplicación (ALPN), además de la indicación del nombre del servidor (SNI) que identifica el host solicitado. Todo esto se transmite antes de que se proteja cualquier carga útil, razón por la cual el protocolo de enlace TLS sirve de base para el análisis del tráfico cifrado sin necesidad de descifrado. Los metadatos del certificado, como el emisor y la validez, aportan contexto sobre la infraestructura, con una salvedad protocolaria que conviene señalar con precisión: TLS 1.3 cifra el mensaje del certificado del servidor con las claves del protocolo de enlace (RFC 8446), por lo que un sensor pasivo solo lee los certificados de la red en sesiones TLS 1.2 y anteriores; en los demás casos, los obtiene resolviendo la propia dirección de destino.

Debajo del protocolo de establecimiento de conexión se encuentra la capa de flujo, que nunca se cifra. El tamaño de los paquetes, el tiempo entre llegadas, la dirección, la duración de la sesión, el recuento de bytes y paquetes, y las relaciones entre carga y descarga describen la forma de una conversación, y estos datos son idénticos tanto para el tráfico cifrado con SSL heredado como para el de TLS 1.3. Dos conjuntos de características clásicos formalizan esto: la secuencia de longitudes y tiempos de los paquetes (SPLT) y el paquete de datos inicial. Los registros NetFlow e IP Flow Information Export (IPFIX) constituyen la base habitual de la recopilación, los mismos resúmenes que permiten realizar análisis de tráfico más amplios.

El contexto del destino completa el panorama: qué puerto utiliza cada protocolo y si la combinación tiene sentido. La fijación de certificados también encaja aquí. Un cliente con fijación de certificados solo acepta un certificado predefinido para un servicio, lo que frustra a los proxies de interceptación y ofrece a los analistas una relación de certificados estable que observar. Dado que la dirección y el volumen se mantienen, una sesión en la que el tráfico de subida supera con creces al de bajada hacia un destino desconocido es un patrón clásico de exfiltración.

Nada de esto es especulativo. La ENISA catalogó seis casos de uso de esta disciplina en noviembre de 2019: identificación de aplicaciones, análisis de redes, identificación de información de usuarios, malware cifrado, huellas digitales y detección de túneles DNS (ENISA). Considéralo como un referente que ha demostrado su viabilidad, no como una fuente de estadísticas actuales. También advierte de que estas técnicas reducen las expectativas de privacidad de los usuarios, una tensión que hereda la decisión sobre el descifrado que se expone a continuación.

¿Qué atributos del protocolo de enlace y del flujo son los más importantes para la detección?

La tabla siguiente resume qué datos recibe un sensor, qué información transmite al analista y las salvedades que conlleva cada dato observable.

Una tabla de siete filas en la que se muestra qué observables de sesión siguen siendo visibles tras el cifrado, qué aporta cada uno a la detección y cuáles son sus limitaciones.

Lo que el cifrado realmente elimina

El cifrado elimina los bytes de carga útil: las URL completas más allá del nombre de host, los cuerpos de las solicitudes y respuestas, el contenido de los archivos, las credenciales y los patrones de bytes de los que dependen los motores de firma y los sistemas de prevención de pérdida de datos basados en la comparación de contenidos. Cualquier control que deba leer el contenido queda «ciego», lo cual es precisamente la contrapartida que se sopesa posteriormente al tomar la decisión de descifrar. Lo que permanece es la estructura de la conversación, y es precisamente en esa estructura donde reside la mayor parte de la señal de detección.

Identificación de huellas TLS, de JA3 a JA4

La huella digital TLS convierte el protocolo de enlace en texto claro en una identidad del cliente, calculada a partir de los bytes que cada sesión debe enviar antes de que comience el cifrado. Los ingenieros de Salesforce publicaron JA3 como código abierto en 2017 y posteriormente lo combinaron con JA3S: JA3 concatena cinco campos de ClientHello —la versión TLS, los conjuntos de cifrado, la lista de extensiones, las curvas elípticas y los formatos de puntos de curvas elípticas— y, a continuación, aplica un hash a la cadena para obtener un valor MD5 de 32 caracteres (Ingeniería de Salesforce). JA3S hace lo mismo con la respuesta del servidor. Dado que el software de cliente rara vez cambia la forma en que establece el protocolo de enlace, el hash actúa como una identidad: malware a partir de una biblioteca determinada presenta la misma huella digital JA3 independientemente del dominio con el que se conecte.

Una huella dactilar manipulada

Imagina un baliza que transmite a través de TLS: lista fija de conjuntos de cifrado, extensiones fijas, preferencias de curva fijas, de modo que su hash JA3 es idéntico en todas las conexiones. Un hash capturado en un incidente puede rastrearse por todo el entorno.

¿Qué es lo que falla en JA3?

El punto débil de JA3 es que calcula el hash de la lista de extensiones en el orden en que se observan. Cuando Chrome empezó a aleatorizar el orden de las extensiones en el ClientHello, este mismo navegador comenzó a generar un hash JA3 diferente en cada conexión, lo que provocó que la comparación ingenua de JA3 dejara de funcionar. Los operadores de herramientas ofensivas aprovechan deliberadamente esta misma propiedad: al alterar el protocolo de establecimiento de conexión, cambia la huella digital.

La tecnología de huellas digitales JA4 es la solución. FoxIO lanzó JA4 en septiembre de 2023 como un rediseño resistente a la aleatorización y lo amplió hasta convertirlo en la suite JA4+ (repositorio de FoxIO JA4+): JA4 para TLS, incluido QUIC; JA4S para respuestas de servidor; JA4H para HTTP; JA4L y JA4LS para latencia; JA4X para certificados X.509; JA4SSH para SSH; JA4T, JA4TS y JA4TScan para TCP; y JA4D y JA4D6 para DHCP y DHCPv6. Los sensores abiertos han seguido el ritmo: Zeek documentó la compatibilidad con JA4 en enero de 2026 (Zeek). Algunas partes de la suite JA4+ están sujetas a licencia, una restricción a la que se vuelve en la sección de limitaciones, y un operador decidido aún puede alterar cualquier huella digital, por lo que hay que tratar los resultados de las huellas digitales JA3 y JA4 como señales sólidas, no como identidades.

TLS 1.3, QUIC y «Client Hello» cifrado: ¿qué es lo que realmente falla?

Cada nueva generación de protocolos reduce aún más la visibilidad del tráfico cifrado. TLS 1.3 eliminó los intercambios de claves estáticas de los que dependía el descifrado pasivo: gracias al secreto perfecto hacia adelante, cada clave de sesión procede de un intercambio efímero, y una sesión grabada no puede descifrarse posteriormente, incluso si la clave privada del servidor se ve comprometida.

QUIC, el protocolo de transporte basado en UDP que subyace a HTTP/3, cifra la mayor parte de los metadatos de transporte que TCP deja al descubierto y redirige el tráfico al puerto UDP 443. La adopción suele exagerarse: el 40,0 % de los sitios web son compatibles con HTTP/3 a fecha de julio de 2026 (W3Techs); la cuota de tráfico, una medida diferente, oscila entre el 34 % y el 35 % aproximadamente en el borde de la red de distribución de contenidos (CDN) y ronda el 21 % a nivel de carga de páginas (Cloudflare Radar).

Hay que aclarar un error común: en las versiones básicas de QUIC y TLS 1.3, un observador situado en la ruta de transmisión aún puede recuperar el SNI, ya que el paquete «Initial» y el «ClientHello» están protegidos con claves derivadas de valores públicos. Solo el «Encrypted Client Hello» lo cifra.

Una comparación de seis filas que muestra que el SNI se puede recuperar en ambos protocolos de transporte, que los metadatos de transporte se pierden con QUIC y que las características a nivel de paquete y de flujo se conservan en ambos.

«Client Hello» cifrado: estandarizado, pero apenas implantado

El «Client Hello» cifrado cifra el «Client Hello» interno —incluido el SNI— con una clave pública del servidor, de modo que solo queda visible un «Client Hello» externo. Pasó a ser el RFC 9849, en la vía de normalización, en marzo de 2026, tras años como «draft-ietf-tls-esni»; el RFC 9848 define su proceso de arranque de DNS.

La implantación va por detrás de lo habitual. Tras analizar el tráfico entre enero y marzo de 2025, Corrata descubrió que algo menos del 10 % de los 1 millón de sitios web más visitados eran compatibles con ECH, que solo el 0,06 % de las conexiones lo utilizaban realmente y que la compatibilidad descendía al 3 % entre los 1.000 sitios más visitados y al 1 % entre los 100 más visitados (Corrata, «Living with ECH»). El mismo estudio reveló que no había compatibilidad con iOS, y que todos los ClientHello externos observados llevaban el mismo SNI, cloudflare-ech.com, lo que hacía que los sitios con ECH fueran indistinguibles entre sí; alrededor del 17 % de los sitios habilitados para ECH entraban en categorías maliciosas o de riesgo. Esa medición tiene aproximadamente 14 meses de antigüedad y es anterior a la RFC 9849, por lo que es probable que el uso real haya aumentado.

La compatibilidad del lado del servidor está al caer: NGINX 1.29.4 incorporó ECH nativo en febrero de 2026 (NGINX), y OpenSSL anunció ECH para su próxima versión 4.0 (OpenSSL). Incluso con ECH completo, un analista sigue registrando los tiempos, el tamaño de los paquetes, la forma del flujo, el ClientHello externo y el JA4, por lo que los cambios que introduce ECH en la visibilidad del tráfico de red son menores de lo que se temía. Planifícalo como una certeza arquitectónica, no como una emergencia en el presente.

Cómo falló ECH en la práctica: CVE-2026-42505

El primer tropiezo de ECH en el mundo real fue un defecto de implementación, no una falla en la especificación. CVE-2026-42505, publicado el 8 de julio de 2026, se encuentra en el módulo crypto/tls de Go: las identidades de las claves precompartidas se filtraron al campo ClientHello externo sin cifrar, lo que permitía a un observador pasivo desanonimizar los handshakes de ECH, precisamente el resultado que ECH pretende evitar. Calificada con un nivel medio de 5,3 en el Sistema Común de Puntuación de Vulnerabilidades (CVSS v3.1) y clasificada bajo la entrada CWE-201 de la Enumeración Común de Debilidades, se corrigió en las versiones go1.25.12, go1.26.5 y go1.27.0-rc.2 (GO-2026-5856). La lección para los defensores: un mecanismo de privacidad estandarizado puede seguir filtrando aquello que protege si se implementa de forma incorrecta.

Detección de túneles DNS sobre HTTPS

El DNS sobre HTTPS (DoH) envuelve las consultas DNS dentro del protocolo HTTPS en el puerto 443, lo que las elimina de los registros de los resolutores y de la supervisión de la capa DNS. La detección se basa, por tanto, en el comportamiento de los flujos: la ENISA incluyó la detección del tunelizado de DNS entre los casos de uso fundacionales de esta disciplina, y los indicadores observables siguen siendo válidos. El DoH tunelizado genera volúmenes de consultas, patrones de tamaño de paquetes y ritmos temporales distintos a los de la navegación habitual, y los flujos hacia resolutores DoH no autorizados destacan por sí mismos.

Inspección del tráfico cifrado: descifrar, descifrar de forma selectiva o analizar únicamente

La inspección del tráfico cifrado se basa en realidad en tres enfoques, no en dos: descifrar de forma generalizada, descifrar de forma selectiva según el nivel de riesgo o analizar sin descifrar. El caso opuesto es la inspección profunda de paquetes (DPI), el motor de comparación de carga útil que se encuentra en los sistemas clásicos de detección y prevención de intrusiones. Las cargas útiles cifradas dejan a la DPI «a ciegas»; se diseñó para una red que ya no existe.

El descifrado general conlleva costes reales: los dispositivos de inspección TLS añaden latencia y carga de capacidad, y convierten la gestión del tráfico cifrado en un programa permanente de distribución de certificados, gestión de claves y clasificación de fallos. La fijación de certificados deja de funcionar por completo detrás de un proxy de interceptación. El contenido que queda expuesto de nuevo supone un riesgo para la privacidad y un riesgo legal. La confidencialidad perfecta hacia adelante agrava la factura: el descifrado SSL pasivo del tráfico grabado ya no es posible, por lo que la interceptación debe realizarse en línea, en el momento de la sesión.

La norma NIST SP 1800-37, finalizada en septiembre de 2025, es la referencia oficial independiente de proveedores que documenta enfoques basados en el riesgo para la visibilidad de TLS 1.3, con directrices de implementación del Centro Nacional de Excelencia en Ciberseguridad (NCCoE). Su lógica se basa en un término medio: descifrar los niveles específicos cuyo riesgo justifica el coste y analizar el resto. En el marco del Marco de Ciberseguridad 2.0 del NIST, así es como la supervisión continua (DE.CM) y el análisis de incidentes (DE.AE) siguen siendo viables cuando las cargas útiles están cifradas.

Una controversia sobre los estándares marca los dos extremos. La norma ETSI TS 103 523-3 define la «Enterprise Transport Security» (ETS, anteriormente eTLS), un protocolo de «middlebox» que permite el descifrado pasivo en entornos controlados. La IETF se opuso a la denominación «TLS», y la EFF se opuso por motivos relacionados con el secreto hacia adelante (EFF, 2019). ETS aparece aquí a efectos de equilibrio, como uno de los extremos (el lado del descifrado), no como una recomendación.

Esa es también la diferencia entre el análisis de tráfico cifrado basado en IA y el descifrado de SSL/TLS: el descifrado vuelve a exponer el contenido para que las herramientas de análisis de carga útil puedan leerlo, mientras que el análisis deduce la intención a partir de los metadatos y el comportamiento sin exponer el contenido.

Un marco de decisión entre «descifrar» y «analizar»

En la práctica, las restricciones normativas determinan en gran medida esta situación: el Reglamento General de Protección de Datos (RGPD), la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) y la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) restringen, cada una a su manera, a qué contenidos descifrados se puede acceder.

Una matriz de decisión de siete filas que asigna las posturas de «descifrar», «descifrar selectivamente» o «solo analizar» a las categorías de tráfico en función del nivel de riesgo y las restricciones normativas.

La situación realista para 2026 se ajusta a lo que indica la matriz: descifrado selectivo basado en el riesgo para un conjunto reducido de tráfico, mientras que el análisis sin descifrar se encarga del resto.

La privacidad, el RGPD y los límites de la supervisión del tráfico de los empleados

En la UE, el descifrado del tráfico de empleados o clientes entra en conflicto con el RGPD y la legislación laboral nacional, que limitan la supervisión de las comunicaciones personales incluso en las redes corporativas. La advertencia de la ENISA de 2019 se aplica también al enfoque de «sin descifrado»: el análisis de metadatos reduce las expectativas de privacidad incluso cuando el contenido permanece cifrado. La gestión práctica se rige por tres reglas: documentar la base jurídica, limitar la inspección al alcance de los niveles de riesgo definidos y dar prioridad a los metadatos siempre que estos respondan a la cuestión de la detección. Analice los detalles con un asesor jurídico.

Análisis del tráfico cifrado en la práctica: tres casos de detección

Tres casos documentados ilustran cómo funciona la detección basada en metadatos frente a las técnicas de espionaje reales. Cada uno de ellos sirve además como plantilla para la búsqueda en tráfico cifrado.

Salt Typhoon. El aviso conjunto AA25-239A de la CISA, la NSA, el FBI y socios internacionales describe los canales encubiertos y cifrados de la campaña: Secure Shell (SSH) en puertos altos no estándar, túneles de encapsulación de enrutamiento genérico (GRE) e IPsec, utilizados para el movimiento lateral y para ocultar el tráfico de mando y control (CISA, agosto de 2025). Las declaraciones del FBI en torno al aviso sitúan la magnitud en un mínimo de 200 empresas estadounidenses, con víctimas en 80 países (TechCrunch). La agencia volvió a confirmar en febrero de 2026 que la campaña seguía en marcha (CyberScoop). La señal de detección se basó en metadatos en todo momento: sesiones cifradas en puertos en los que no deberían estar, patrones de autenticación anómalos y conexiones salientes y volúmenes de salida inusuales. Cuando los atacantes cifran su tráfico de comandos, el análisis de comportamiento de los metadatos de flujo es lo que permite detectar el canal encubierto.

Cobalt Strike y control de Cobalt Strike . Versión predeterminada y pirateada Cobalt Strike generan un ClientHello estable y reconocible, así como una respuesta del servidor emparejada, por lo que las huellas digitales de JA3 y JA3S identifican la baliza y el servidor del equipo en el protocolo de enlace en texto claro, antes de que el túnel se cifre, y los intervalos regulares de emisión de balizas corroboran la coincidencia (The DFIR Report, 2022). El protocolo de enlace deja al descubierto los marcos ocultos dentro del cifrado; los operadores pueden alterar la huella digital, y esa es precisamente la razón por la que existe JA4.

Malware servicios legítimos protegidos por TLS. malware de 2021 de un proveedor de seguridad de redes documentaron la existencia de «droppers» y «loaders» que utilizaban conexiones TLS para acceder a servicios de confianza cloud, de pegado de enlaces, de chat y de alojamiento de código, además de Tor, con fines de preparación, comando y control (C2) y exfiltración. Tanto la reputación del destino como el cifrado jugaron en contra de los defensores, por lo que la única señal restante fue la relacionada con el comportamiento: periodicidad inusual, proporciones entre subidas y descargas, y tamaños de sesión hacia destinos que, en otras circunstancias, serían de confianza, junto con anomalías en los metadatos de TLS y de los certificados. El cifrado, sumado al uso indebido de servicios legítimos, frustra de un solo golpe la inspección de la carga útil y la reputación del dominio, dejando el comportamiento del flujo como la única señal residual para detectar malware cifrado.

Asignación de estos casos al marco MITRE ATT&CK

Las tres se enmarcan en la táctica de mando y control (0011) en MITRE ATT&CK versión 19.1; todas las técnicas que se indican a continuación pueden observarse a partir de los metadatos de red.

Una tabla de tres columnas que relaciona el canal cifrado, el protocolo de la capa de aplicación y las técnicas de tunelización del protocolo con las señales de metadatos que los revelan.

Todos y cada uno de estos casos pudieron detectarse únicamente a partir de los metadatos, lo que constituye el argumento fundamental a favor del análisis del tráfico cifrado.

Las dificultades del análisis del tráfico cifrado

Las páginas de los proveedores suelen presentar la clasificación del tráfico cifrado mediante aprendizaje automático (ML) como un problema resuelto. La literatura científica revisada por pares no lo hace. Un estudio de 2024 publicado en Sensors por Alwhbi, Zou y Alharbi pone de manifiesto la brecha existente entre los resultados de las pruebas comparativas y la realidad en entorno de producción (MDPI, también disponible a través del repositorio de acceso público de la NSF). Las limitaciones recurrentes son:

• Desviación del concepto. Los modelos pierden precisión a medida que las distribuciones reales del tráfico se alejan de los datos de entrenamiento, por lo que la precisión obtenida en las pruebas de referencia sobreestima el rendimiento en la práctica.
• Evasión adversaria. El relleno y la manipulación temporal burlan los clasificadores que se basan en características de tamaño e intervalo (arXiv 2105.14564).
• Sesgo de los conjuntos de datos. Los corpus de referencia, como los conjuntos «VPN» y «no VPN», no se asemejan a una empresa real, por lo que los modelos generalizan mal. Un estudio comparativo sobre la detección de tráfico malicioso cifrado reveló que la falta de conjuntos de datos y conjuntos de características bien reconocidos hace que sea imposible comparar de forma fiable el rendimiento de los modelos publicados (arXiv 2203.09332).
• Coste de los falsos positivos. En la telemetría de gran volumen de datos, incluso una tasa de falsos positivos reducida se convierte en un desastre operativo que se mide en horas de trabajo de los analistas.
• Mutabilidad de la huella digital. JA3 y JA4 son señales sólidas, no identidades; un operador que controla al cliente controla la huella digital.

Las condiciones de la licencia constituyen otra limitación de la que se habla poco: Security Onion 3.0.0, lanzado el 31 de marzo de 2026, condiciona la integración de JA4+ a la aceptación explícita de la licencia de FoxIO (Security Onion). Comprueba el estado de la licencia antes de instalar la suite completa.

Nada de esto aboga por volver a las firmas: en la segunda mitad de 2025, el 23 % del malware detectado malware por completo la detección basada en firmas (WatchGuard a través de GlobeNewswire). La realidad es que la precisión en laboratorio superior al 90 % es real, pero no equivale al rendimiento en el entorno real. La metodología de establecimiento de valores de referencia forma parte de la detección de anomalías en la red, y combinar los resultados del modelo con el contexto del análisis de comportamiento permite que el coste de los falsos positivos sea asumible.

Enfoques modernos para el análisis del tráfico cifrado

El sector está convergiendo hacia una detección basada en metadatos: huellas digitales de TLS como salida estándar de los sensores, el comportamiento de los flujos que alimenta los modelos de anomalías y la detección de amenazas que correlaciona las pruebas de red con el contexto de identidad, en lugar de comparar cargas útiles. Tanto si estás valorando herramientas NDR comerciales como sensores de código abierto como Zeek y Security Onion, las cuestiones se centran en las capacidades: ¿funciona sin descifrado?, ¿cubre QUIC además de TLS sobre TCP?, ¿genera huellas digitales que se puedan utilizar como punto de partida? y ¿se adapta adecuadamente cuando llegue ECH?

Cómo Vectra AI el análisis del tráfico cifrado

Vectra AI el análisis del tráfico cifrado partiendo de la premisa de que el sistema ya ha sido comprometido: los atacantes capacitados lograrán acceder y, una vez dentro, cifrarán sus comunicaciones de mando y control al igual que lo hace el resto de la red. Si la detección depende de la lectura de las cargas útiles, el cifrado ya ha decidido el resultado, por lo que la metodología trata los metadatos como prueba principal y no como un recurso de reserva. La pregunta relevante no es «¿podemos leer la carga útil?», sino «¿se comporta este flujo como el de un atacante?»: ¿emite señales con una periodicidad que ningún servicio autorizado utiliza?, ¿transfiere datos con patrones que ninguna carga de trabajo debería seguir?, ¿la identidad que hay detrás actúa como siempre lo ha hecho? Responder a eso requiere un análisis de comportamiento que abarque conjuntamente la red y la identidad, y exige separar la señal de ataque del ruido de las anomalías benignas, ya que, dado el volumen de flujos en las empresas, el ruido es la norma. Esa disciplina de «señal sobre ruido» es lo que hace que el análisis del tráfico cifrado sea operativo dentro de la detección y respuesta de red, en lugar de meramente académico.

Conclusión

El cifrado ocultó la carga útil a los defensores, pero no la estructura de la conversación, y es precisamente en esa estructura donde ahora reside la detección: los metadatos del protocolo de establecimiento de conexión, las huellas digitales de TLS, los registros de flujo y los datos temporales sobreviven a TLS 1.3, QUIC y, en gran medida, incluso a ECH. Considera ECH como una certeza arquitectónica y diseña sensores que sigan funcionando cuando llegue. Descifra de forma selectiva solo cuando el riesgo y la legislación justifiquen el coste, analiza todo lo demás y evalúa cada enfoque en función de lo que detecta sin necesidad de descifrar.

‍