Ivanti Connect Secure nuevamente en la CISA KEV: Tercer incidente en 18 meses

7 Min. Tiempo de lectura · Informe de Amenazas

Esta semana, la CISA ha agregado otra vulnerabilidad de Ivanti Connect Secure a su catálogo de vulnerabilidades conocidas y explotadas. Es el tercer incidente importante con el fabricante de gateways VPN en 18 meses. Mandiant observa explotación activa por parte de grupos respaldados por el Estado en al menos tres sectores críticos DACH. Paralelamente, Eclypsium ha publicado indicadores técnicos que apuntan a una anclaje en memoria. El informe M-Trends 2026 clasifica a los dispositivos VPN como el vector de acceso inicial número uno, por delante de los servicios de borde expuestos y el phishing. Para los CISOs, esto no es un tema de parcheo, sino una cuestión estratégica: ¿cuánto tiempo permanecerá Ivanti en el camino crítico y, de ser así, bajo qué condiciones?

Qué ha pasado

La nueva CVE afecta a Ivanti Connect Secure y Ivanti Policy Secure en varias versiones activamente utilizadas. La CISA ha agregado la vulnerabilidad a la KEV dentro de las 48 horas posteriores a su anuncio, y el plazo federal para las agencias estadounidenses afectadas es de dos semanas. En la región DACH, el plazo no es vinculante, pero la inclusión en la KEV es el desencadenante no oficial para cada estándar CISO serio.

Mandiant informa en su actualización rápida que la vulnerabilidad se está explotando activamente, con patrones que sugieren una actividad de grupo respaldada por el Estado ya establecida. Los primeros indicadores se observaron en las redes de energía y telecomunicaciones DACH. Eclypsium ha publicado detalles técnicos sobre un mecanismo de persistencia en memoria que elude las rutinas de parcheo clásicas: el parche cierra la brecha inicial, pero no elimina la puerta trasera anclada en la RAM. Quien solo parchea y no reinicia más la comprobación forense, no ha eliminado el riesgo.

Ivanti ha proporcionado un paquete de parcheo en caliente en un plazo de 24 horas. En las primeras 72 horas después del lanzamiento, alrededor del 60% de los dispositivos expuestos se han parcheado en la telemetría NOC DACH, lo que es más rápido que en los dos incidentes en Q4 2024 y Q2 2025. El reflejo operativo está presente, pero en 2026 no es suficiente para responder a la pregunta de confianza.

Nivel de escalada 2026

El 38% de todos los incidentes corporativos, según el informe M-Trends 2026 de Mandiant, comienzan en un dispositivo VPN o de borde. Tercer incidente de Ivanti Connect Secure en 18 meses. Inclusión en la KEV de la CISA en un plazo de 48 horas. Al menos tres sectores críticos DACH se ven afectados activamente. El parche solo no es suficiente: la persistencia en memoria requiere reinicio más comprobación forense.

Qué deben decidir los CISO ahora

Se identifican tres áreas de decisión que no se pueden delegar a la capa de operaciones en 2026.

Endurecimiento inmediato en 30 días. Parche más reinicio más barrido de indicadores es lo mínimo. Quien quiera conservar los dispositivos Ivanti en 2026, debe imponer autenticación multifactor en la puerta de enlace VPN, limitar las sesiones, activar filtros de inicio de sesión geográficos y afinar el monitoreo de anomalías de tokens SAML. Estas son medidas de 30 días que son factibles en un SOC serio.

Decisión de arquitectura a medio plazo en seis meses. ¿Ivanti permanece en el camino clave o la organización migra a una arquitectura de acceso de red de confianza cero? Las soluciones ZTNA como Zscaler Private Access, Cloudflare Access o Netskope Private Access reducen la superficie de ataque porque ya no existe un dispositivo VPN expuesto directamente. La migración dura de seis a doce meses y requiere un mandato de la junta directiva más un presupuesto de entre 600.000 y 2,4 millones de euros para configuraciones medianas en DACH.

Diversificación de proveedores como estrategia. Incluso quien conserva Ivanti, debería a medio plazo no conectar todos los sitios a través de un solo fabricante. Las estrategias de doble proveedor con dos proveedores de VPN o ZTNA en los sitios críticos reducen el riesgo de bloqueo de un solo proveedor, que volvió a convertirse en una crisis entre 2024 y 2026.

Pros y contras de los tres caminos

A favor de Parche + Endurecimiento

El camino más rápido, 30 días realistas
No se requiere cambio de arquitectura
Se pueden utilizar habilidades existentes en el equipo
Es aceptable si el incidente fuera único

En contra de Parche + Endurecimiento

El riesgo de confianza estructural del proveedor permanece
El próximo incidente es estadísticamente probable
La reputación ante la supervisión está dañada
Los costos se acumulan a lo largo de los incidentes

A favor de la migración a ZTNA

Superficie de ataque significativamente reducida
Nivel de confianza cero en auditorías
Integración nativa en la nube con IdP
Reduce la complejidad de los dispositivos de borde

En contra de la migración a ZTNA

Seis a doce meses de tiempo de migración
Efecto presupuestario de seis cifras a siete cifras
Se requiere mandato de la junta directiva
Curva de aprendizaje para el equipo y los usuarios

A favor del doble proveedor

Distribución del riesgo entre dos fabricantes
Palanca de negociación en compras
Cambio rápido en caso de crisis del proveedor
Compromiso pragmático

En contra del doble proveedor

Complejidad operativa duplicada
Dos ciclos de actualización, dos pistas de auditoría
Costos de licencia más altos en total
Requisitos de habilidades crecen

El plan de 30-60-180 días

Secuencia operativa después de la inclusión en KEV

Día 1 al 7. Implementar el parche, reiniciar todos los dispositivos, realizar un barrido de indicadores de compromiso contra los indicadores de Eclypsium y Mandiant, invalidar las sesiones afectadas, rotar todos los tokens SAML activos.

Día 8 al 30. Realizar un examen profundo forense de los dispositivos en busca de persistencia en memoria, hacer cumplir la autenticación MFA en el inicio de sesión VPN, activar filtros geográficos, limitar los límites de sesión, afinar las detecciones del SOC en anomalías de tokens SAML.

Día 31 al 90. Revisión de la arquitectura con la junta directiva: preparar la migración a ZTNA o establecer un plan de doble proveedor, renegociar los contratos de adquisiciones con cláusulas de SLA de seguridad, verificar la obligación de informes NIS2 para las filiales afectadas en DACH.

Día 91 al 180. Iniciar un piloto de ZTNA en dos áreas de negocio, preparar la configuración de doble proveedor para ubicaciones críticas, incorporar las lecciones aprendidas en el estándar del grupo, encargar una validación de auditoría externa.

Preguntas frecuentes

¿Cuán grave es el tercer incidente de Ivanti en comparación con los anteriores?

Similar en impacto, más grave en la dimensión de confianza. El tercer incidente en 18 meses cambia la pregunta de un incidente individual a una cuestión estructural de proveedor. Los supervisores, aseguradoras y transportistas de seguros cibernéticos pedirán cada vez más un plan de acción concreto en 2026, no solo una confirmación de parche.

¿Qué indicadores deberían implementar los equipos del SOC ahora?

Mandiant y Eclypsium han publicado indicadores de hash, rangos de IP e indicadores de comportamiento. Los equipos del SOC deben configurar reglas YARA contra las firmas de persistencia en memoria, reglas Sigma para anomalías de reutilización de tokens SAML y detecciones EDR para conexiones salientes anómalas desde el dispositivo VPN. Falco o Tetragon con telemetría eBPF proporciona la visión más fiable.

¿Deben los sujetos obligados por NIS2 informar sobre la inclusión en KEV?

No la inclusión en sí, sino cada incidente confirmado. Quien ve indicios de explotación exitosa en su telemetría debe informar dentro de los plazos de NIS2, que son 24 horas para la alerta temprana y 72 horas para el informe de incidentes. Una mera inclusión en KEV sin indicadores propios no es obligatoria.

¿Merece la pena una migración inmediata a ZTNA?

Si la organización de todos modos tiene que replantear su arquitectura de borde en los próximos 18 meses, sí. ZTNA no solo resuelve el problema de Ivanti, sino que también reduce otros riesgos de VPN y proporciona una mejor posición de auditoría para NIS2 y seguros cibernéticos. Quien implemente ZTNA a corto plazo sin planificación estratégica, construirá una nueva complejidad.

¿Cuál es el error más común después de una inclusión en KEV?

Parche y archivo. La persistencia en memoria se ignora así, porque la vulnerabilidad se considera cerrada. Una reacción seria incluye parche, reinicio, examen forense y monitoreo de al menos 90 días. Quien lo reduce al Día 1, no ha eliminado el riesgo, sino que lo ha eliminado del informe.