«Ya gestionamos nuestras vulnerabilidades, realizamos análisis de seguridad periódicos».
Si es director de sistemas de información o responsable de seguridad de la información, es posible que ya haya pronunciado esta frase. Y es legítima: probablemente ya dispone de las herramientas necesarias, sus ciclos de análisis están planificados y sus paneles de control se van completando. En apariencia, todo está bajo control.
El problema es que, entre un análisis y otro, su superficie de ataque sigue evolucionando. Y es posible que sus activos, que se consideraban seguros, ya no lo sean.
Por lo tanto, el reto ya no es solo detectar sus vulnerabilidades a intervalos regulares, sino gestionar su exposición en tiempo real, en función de las amenazas, de su contexto y de su capacidad real de corrección.
Esto es exactamente lo que promete el CTEM (Continuous Threat Exposure Management): pasar de una lógica de control periódico a una gestión continua y estructurada del riesgo.
En este artículo, analizaremos este enfoque que se ha vuelto imprescindible, comprenderemos cómo redefine la gestión de vulnerabilidades y cómo Cyberwatch le permite integrarlo de forma concreta en sus prácticas.
CTEM: un nuevo enfoque frente a las limitaciones de la gestión clásica de vulnerabilidades
Durante años, la gestión de vulnerabilidades (VM) y de la seguridad de los sistemas de información se ha basado en auditorías periódicas: un escaneo mensual, una prueba de penetración trimestral, una auditoría de cumplimiento anual.
Pero este enfoque ya no se ajusta a la realidad de los sistemas de información modernos. Y ello por varias razones:
1) Infraestructuras cada vez más dinámicas y efímeras
El modelo tradicional de gestión de vulnerabilidades se basa en un principio sencillo: capturar el estado de seguridad del SI en un momento dado, analizar los resultados y, a continuación, corregir los problemas identificados.
Pero aquí está el problema: en la era de la nube y las implementaciones continuas, esa instantánea queda obsoleta en el mismo instante en que se toma.
Imagina un ciclo de análisis mensual que se ejecuta el día 1 del mes. El día 3, tu equipo de DevOps implementa un microservicio con una dependencia vulnerable. El día 7, se publica una CVE crítica sobre un componente presente en el 30 % de tu infraestructura. El día 15, un becario inicia una instancia EC2 para probar un POC y se olvida de desactivarla.
Su próximo escaneo detectará estos problemas con un retraso de entre 2 y 4 semanas, en el mejor de los casos.
Este escenario no es hipotético. En las arquitecturas modernas, con entornos híbridos multicloud, miles de microservicios, contenedores orquestados por Kubernetes, funciones sin servidor o incluso API expuestas públicamente, su superficie de ataque se multiplica y los cambios en su infraestructura son constantes.
La consecuencia es inmediata: el mapa de activos en el que se basa su análisis queda rápidamente obsoleto, y algunos activos escapan a su supervisión.
2) Un volumen de vulnerabilidades que se dispara
Más allá de estos puntos ciegos en la supervisión de activos, el volumen de vulnerabilidades que hay que tratar aumenta a un ritmo sin precedentes.
Según las cifras del FIRST (Forum of Incident Response and Security Teams), en 2025 se registraron cerca de 50 000 CVE. Esto supone un aumento de aproximadamente el 21 % en un año, tras un incremento ya estimado en un 39 % entre 2023 y 2024.
A esta avalancha de vulnerabilidades se suma una aceleración de los plazos de explotación: los atacantes industrializan ahora la explotación de las fallas críticas y, en el caso de las vulnerabilidades más mediáticas (como Log4Shell hace unos años), el plazo entre la publicación y los primeros ataques se reduce a veces a menos de 24 horas.
Resultado: la ventana de corrección se reduce drásticamente, lo que acentúa aún más el desfase con los ciclos de análisis periódicos.
3) Una priorización aún demasiado desconectada del riesgo real
En este contexto, ya no se puede tratar todo: hay que saber qué corregir con prioridad y en qué plazos.
Sin embargo, en los enfoques tradicionales, la priorización sigue basándose en gran medida en puntuaciones técnicas genéricas (CVSS), sin tener en cuenta:
- De la exposición real del activo,
- de su criticidad para el negocio,
- de la existencia de exploits activos,
- ni de su capacidad operativa para la corrección.
Resultado: sus equipos acumulan miles de vulnerabilidades, sin poder identificar claramente cuáles deben tratarse en primer lugar.
Por lo tanto, pueden pasar varias semanas (a veces varios meses) entre la detección de una vulnerabilidad crítica y su corrección efectiva.
Este desfase es aún más problemático a medida que se intensifica la presión normativa. La Directiva NIS2 (aplicable desde octubre de 2024) impone obligaciones reforzadas en materia de gestión de riesgos cibernéticos, con sanciones que pueden alcanzar hasta el 2 % de la facturación mundial.
Para responder a todos estos retos, ya no basta con mejorar los escáneres: hay que cambiar de enfoque. Ese es precisamente el objetivo del CTEM.
El CTEM al detalle: definición y principios clave de la gestión continua de la exposición a amenazas
Un concepto popularizado por Gartner
El término CTEM (Continuous Threat Exposure Management) fue introducido por la empresa de investigación y consultoría Gartner en 2022, en sus trabajos sobre la «gestión de la exposición».
Gartner lo define como un conjunto de procesos y capacidades organizados en cinco fases (que detallaremos a continuación), que permiten evaluar de forma continua la accesibilidad, la exposición y la vulnerabilidad de los activos digitales y físicos.
Hay dos elementos esenciales en esta definición:
- En primer lugar, el CTEM no es una simple herramienta. Se trata de un marco metodológico global que estructura la forma en que la organización mide su exposición real, prioriza sus acciones de seguridad y reduce de manera concreta el riesgo de compromiso.
- En segundo lugar, el enfoque está decididamente orientado a la explotabilidad y al impacto en el negocio, y ya no solo a la detección de vulnerabilidades. Ya no se busca solo saber cuántas fallas existen en el sistema de información, sino cuáles pueden realmente ser explotadas, en qué activos críticos y con qué consecuencias para la organización.
El objetivo es claro: reducir de forma sistemática y cuantificable la exposición a las amenazas mediante un ciclo continuo.
Las 5 fases del marco CTEM
El marco CTEM se articula en torno a cinco fases:
- Descubrimiento: todo comienza con una visión fiable y actualizada de la superficie de ataque. Esta fase consiste en identificar los activos, los servicios expuestos, las identidades y los recursos en la nube, incluidos aquellos que escapan a los inventarios tradicionales.
- Delimitación del alcance: una vez obtenida esta visibilidad, el reto consiste en definir el perímetro realmente prioritario. El análisis se centra en los activos críticos y los escenarios de compromiso con un fuerte impacto en el negocio, en lugar de tratar todo el sistema de información de manera uniforme.
- Priorización: en un contexto en el que no todo puede corregirse de inmediato, esta etapa permite clasificar las vulnerabilidades según el riesgo real. A diferencia de los enfoques tradicionales basados únicamente en la puntuación CVSS, la priorización integra aquí criterios contextuales: la existencia de exploits activos, la probabilidad de explotación (a través de puntuaciones como el EPSS) o incluso el nivel de exposición de red del activo en cuestión.
- Validación: antes de movilizar a los equipos, hay que confirmar que el riesgo es real. El análisis de las vías de ataque o las simulaciones permiten identificar las vulnerabilidades realmente explotables y descartar aquellas que no constituyen una amenaza inmediata.
- Movilización: la última fase transforma la priorización en acciones de corrección planificadas y gestionadas en el tiempo, teniendo en cuenta las limitaciones operativas y la capacidad real de los equipos para corregir.
Estas cinco fases forman un ciclo continuo, y eso es precisamente lo que las distingue de una secuencia clásica de acciones de seguridad.
Queda entonces una pregunta clave: ¿cómo industrializar este ciclo e integrarlo realmente en sus operaciones de seguridad?
Ahí es donde entra en juego Cyberwatch, nuestra plataforma de gestión de vulnerabilidades y de cumplimiento normativo: no como un componente más en su pila de seguridad, sino como la plataforma que pone en práctica cada etapa del ciclo CTEM.
Implementar el CTEM con Cyberwatch, paso a paso
1) Descubrimiento: crear un inventario fiable y dinámico de sus activos
Sin un inventario exhaustivo y actualizado, no es posible el CTEM.
Por eso, Cyberwatch se basa en una amplia gama de mecanismos de descubrimiento para identificar automáticamente los activos de su infraestructura, ya sean locales, en la nube, en contenedores o externos.
Los principales mecanismos de descubrimiento:
- Infraestructura local: escaneos de red y descubrimientos específicos para detectar máquinas no registradas, seguidos de la integración (posible en modo sin agente), organización por grupos y seguimiento a lo largo del tiempo mediante ejecuciones recurrentes.
- Nube (AWS, Azure, GCP, OpenStack…): consulta de API para mapear máquinas virtuales y recursos asociados (p. ej., Microsoft Entra ID), con cobertura multiproyecto/multirregión y actualizaciones periódicas.
- Docker y Kubernetes (EKS/AKS/OpenShift…): inventario de imágenes (registros y/o imágenes realmente desplegadas) con adición automática para su análisis.
- Exposición externa (IP / DNS / WHOIS / Certificate Transparency): escaneo de rangos de IP e inventario de dominios, detección de dominios relacionados (marcas, filiales, dominios olvidados) e identificación de subdominios a través de los registros públicos de certificados TLS (Certificate Transparency), incluidos aquellos que escapan a los enfoques DNS clásicos.
Al final, cada nuevo activo detectado se integra automáticamente, y los activos retirados del servicio se eliminan del inventario: dispones en todo momento de una visión fiable de tu superficie de exposición.
2) Delimitación del alcance: definir un perímetro alineado con sus retos empresariales
Una vez que el inventario ha ganado en fiabilidad gracias a la fase de descubrimiento, el reto ya no es analizarlo todo de la misma manera, sino adaptar el nivel de exigencia al nivel de riesgo.
Un activo crítico, como un servidor ERP expuesto a Internet, debe ser objeto de un seguimiento prioritario, mientras que un activo con baja exposición, como un entorno de desarrollo aislado, tiene una prioridad menor.
El alcance consiste precisamente en organizar su superficie de ataque en perímetros coherentes para evitar el ruido y concentrar sus esfuerzos donde el impacto empresarial es real.
Con Cyberwatch, esta lógica se materializa mediante la organización de los activos en proyectos o grupos que se corresponden con sus entornos (Producción, DMZ, servidores web, pruebas…).
Cada perímetro puede entonces disponer de sus propias reglas: frecuencia de escaneo, umbrales de alerta, criterios de priorización o derechos de acceso.
Por ejemplo:
Proyecto «Producción»
├─ Frecuencia de análisis: diaria
├─ Umbral de alerta: CVSS ≥ 9,0 (notificación inmediata)
└─ Acceso: DSI + RSSI
También es posible definir con precisión los rangos de IP que se deben supervisar y distinguir los activos expuestos de los sistemas internos.
Esta segmentación evita sobrevalorar riesgos poco realistas, al tiempo que se aplica un nivel de exigencia más alto a los recursos críticos.
3) Priorización: pasar del volumen de CVE al riesgo realmente crítico
Una vez controlado el inventario y definido el perímetro, el reto queda claro: definir qué debe corregirse con prioridad.
En concreto, se trata de transformar una lista de miles de vulnerabilidades en una cola corta, contextualizada y alineada con sus retos empresariales.
En Cyberwatch, esta priorización se basa, en primer lugar, en la definición de una política de criticidad para cada activo. A cada ámbito se le asignan requisitos de Confidencialidad, Integridad y Disponibilidad (CIA) que permiten recalcular una puntuación CVSS contextual: el CVSS-BTE.
Esta puntuación tiene en cuenta su realidad técnica: por ejemplo, un servidor totalmente aislado de la red puede definirse como accesible únicamente de forma local. Las vulnerabilidades explotables de forma remota ven entonces reducida automáticamente su criticidad. Por el contrario, una falla que afecte a un sistema expuesto en producción mantendrá un nivel de prioridad elevado.
A esta contextualización se suma una lectura orientada a las amenazas. Las vulnerabilidades señaladas como prioritarias son aquellas que combinan:
- Un umbral CVSS a partir del cual debe tratarse una vulnerabilidad,
- La puntuación EPSS, que refleja la probabilidad de explotación en el mundo real,
- La presencia en catálogos de referencia como el CERT-FR ALE, el CISA KEV o las listas mantenidas por Cyberwatch.
Ya no se razona en términos de gravedad teórica global, sino de riesgo real para un activo determinado.
De este modo, la priorización resulta directamente útil para los equipos: los esfuerzos se centran en las vulnerabilidades críticas, expuestas y susceptibles de ser explotadas, en lugar de en una lista de CVE sin jerarquización.
4) Validación: verificar la explotabilidad y medir la eficacia de los parches
Una vez definidas las vulnerabilidades que deben tratarse con prioridad, la fase de validación consiste en medir la eficacia de las decisiones tomadas respondiendo a dos preguntas clave:
- ¿Es la amenaza realmente real en su contexto?
- ¿Han eliminado efectivamente el riesgo las medidas correctivas?
El objetivo es pasar de una decisión teórica a una reducción cuantificable de la exposición.
En Cyberwatch, esta validación comienza con la contextualización de cada CVE: la enciclopedia de vulnerabilidades centraliza, para una misma falla, la gravedad técnica (CVSS y CVSS-BTE), los parches disponibles y, sobre todo, la existencia de exploits públicos o herramientas de ataque conocidas.
Combinada con la puntuación EPSS y la inclusión en catálogos de referencia (CERT-FR, CISA KEV…), esta información permite identificar inmediatamente las vulnerabilidades explotadas activamente, fáciles de industrializar en campañas de ataque y reconocidas como críticas por las autoridades de referencia.
Por el contrario, una vulnerabilidad grave pero sin exploits conocidos y con baja probabilidad de explotación puede reclasificarse objetivamente.
La validación también se centra en la eficacia de las correcciones. Tras la implementación de un parche, un cambio de configuración o la eliminación de un servicio, Cyberwatch relanza automáticamente los análisis sobre los activos afectados. Se verifica la desaparición efectiva del CVE, se registran las fechas de detección y corrección, y se calcula el tiempo de exposición.
Ya no basta con declarar que se ha implementado una corrección: se demuestra que el riesgo ha sido eliminado, se detectan los fallos en la corrección y se identifican las posibles regresiones.
Estos indicadores alimentan directamente la gestión del CTEM al aportar una medida objetiva de la eficacia de las acciones llevadas a cabo.
5) Movilización: coordinar la corrección y gestionar la reducción del riesgo
Una vez validadas las vulnerabilidades, el reto es pasar a la ejecución: corregir, hacer un seguimiento del avance y demostrar que el riesgo disminuye realmente. Esa es la función de la fase de movilización, en la que Cyberwatch se convierte en el punto de convergencia entre los equipos de seguridad, las operaciones de TI y la gestión.
En la práctica, se basa en tres dimensiones:
Coordinar la corrección técnica con la gestión de parches
La vista de gestión de parches establece el vínculo directo entre una vulnerabilidad prioritaria y la acción a realizar. Para cada activo, centraliza los CVE, los parches asociados y las operaciones posibles.
Los parches se pueden implementar automáticamente en entornos Windows y Linux, con gestión de dependencias e integración con herramientas existentes como WSUS o Red Hat Satellite. Cuando el propio software es el origen del riesgo, su desinstalación se puede activar desde la plataforma.
Cyberwatch ya no se limita a identificar las vulnerabilidades: proporciona un plan de acción técnico trazable, vulnerabilidad por vulnerabilidad.
Integrarse en los flujos de trabajo de TI a través de ITSM
Movilizarse también significa alinearse con los procesos de los equipos encargados de la corrección.
Las integraciones ITSM (ServiceNow, Microsoft Teams, GLPI, Jira…) permiten convertir automáticamente una vulnerabilidad validada en un ticket prellenado con toda la información contextual: activo afectado, nivel de criticidad y parche recomendado.
Los equipos de seguridad gestionan el proceso en Cyberwatch, los equipos de TI trabajan en su herramienta habitual, pero la cadena sigue siendo continua y sincronizada.
Gestionar la corrección a lo largo del tiempo
La movilización solo es sostenible si es medible. Cyberwatch registra las fechas de detección y corrección de cada vulnerabilidad y calcula los tiempos de tratamiento.
Estos datos alimentan los paneles de control: vulnerabilidades críticas por ámbito, tiempo medio de corrección, cumplimiento de los SLA, cobertura de los escaneos.
El módulo de alertas activa automáticamente notificaciones o integraciones cuando se alcanza un umbral: nueva CVE crítica, sistema obsoleto, plazo de corrección superado.
Ya no se limita a realizar un seguimiento de los parches implementados, sino que gestiona los objetivos de reducción del riesgo a largo plazo.
Esta trazabilidad permite informar a los comités de dirección, demostrar el cumplimiento normativo (en particular NIS2) y basar las decisiones en indicadores objetivos extraídos del terreno.
CTEM: puntos clave a recordar
Implementar un programa CTEM supone, en definitiva, cambiar de enfoque: pasar de una gestión puntual de las vulnerabilidades a una gestión continua de la superficie de exposición.
Con Cyberwatch, este enfoque se vuelve muy concreto, ya que cada etapa del ciclo encuentra su traducción operativa en la plataforma:
- Un inventario fiable y dinámico de todos sus activos, incluidos aquellos que escapan a los enfoques tradicionales
- Una segmentación de su superficie de ataque alineada con sus retos empresariales y sus niveles de criticidad
- La salida del «backlog infinito» para concentrar el esfuerzo en las vulnerabilidades explotables, efectivamente identificadas y críticas para su contexto
- El paso de la CVE abstracta a la exposición demostrada, con reanálisis sistemáticos y catálogos de referencia
- Una corrección coordinada y trazable, desde el parche implementado hasta la demostración de la reducción del riesgo
Es esta continuidad entre detección, decisión y acción la que permite responder de forma concreta a los retos actuales: resiliencia operativa, cumplimiento normativo (NIS2) y transparencia frente a su gobernanza.
¿Desea ver cómo se traduce este enfoque en la práctica en un entorno real?
→ Solicite una demostración de Cyberwatch
Preguntas frecuentes sobre CTEM
¿Qué es la gestión continua de la exposición a amenazas (CTEM)?
El CTEM es un marco definido por Gartner para identificar de forma continua los activos expuestos, priorizar las vulnerabilidades explotables y reducir de forma concreta el riesgo de compromiso.
¿El CTEM es una herramienta o una metodología?
El CTEM es una metodología que se basa en herramientas de detección, análisis y corrección para gestionar la reducción del riesgo.
¿Por qué el CTEM se ha convertido en un enfoque de referencia en ciberseguridad?
Se ha impuesto, en particular, porque permite adaptar la ciberseguridad a entornos en la nube e híbridos, donde la superficie de ataque evoluciona constantemente.
¿Cuáles son las 5 fases del CTEM?
El marco CTEM definido por Gartner sigue un ciclo continuo: Descubrimiento → Alcance → Priorización → Validación → Movilización.
¿Cuál es la relación entre el CTEM y la NIS2?
El CTEM facilita el cumplimiento de la NIS2 al proporcionar una visión continua del riesgo, con un seguimiento de las correcciones y los indicadores de rendimiento.