CTEM (Continuous Threat Exposure Management) es un enfoque holístico para entender, medir y gestionar continuamente los riesgos de ciberseguridad a los que una organización, independiente de su tamaño, está expuesta, adaptándose a su evolución y amenazas; o tal y como lo define su creador (Gartner), se puede resumir en:
“Una metodología que abarca plenamente a las personas, los procesos y las tecnologías, y que permite a una organización evaluar de forma continua y sistemática la accesibilidad, la exposición y la explotabilidad de sus activos digitales y físicos. El proceso de CTEM también mejora y contextualiza iniciativas como la gestión de vulnerabilidades, la gestión de la superficie de ataque y la inteligencia de amenazas, al alinearlas con el riesgo real para el negocio y permitir una toma de decisiones informada y priorizada entre los equipos de seguridad y TI.”
Pese a que es una gran definición, puede ser complicado de entender qué implica realmente esto, y cómo se diferencia de otros modelos de trabajo tradicionales que nos podemos encontrar, como la VM (Vulnerability Management), el Pentesting, o incluso algunos más modernos como el ASM (Attack Surface Management).
Consideramos que para entender correctamente esta metodología, podemos partir de entender cada uno de sus componentes, empezando por el nombre:
Ahora que tenemos ya esta definición de sus componentes, podemos entenderlo un poco mejor en su conjunto: CTEM se trata de una metodología que nos explica cómo gestionar nuestra exposición a amenazas de manera continua.
En las próximas secciones, profundizaremos en por qué utilizamos estos términos específicos y no otros, que a primera vista, podrían parecer intercambiables, como riesgo, vulnerabilidades, o sencillamente Exposure Management; pero antes de eso, vamos a terminar de formar la imagen general de CTEM
Como cualquier buen proceso de ciberseguridad, CTEM se trata de un ciclo, no un checklist a completar, ya que vamos a iterar continuamente sobre estas fases. Para entenderlo, partamos de la definición de su propio creador y luego exploraremos cada una de ellas:
Podemos ver que el proceso se divide en una serie de fases. Las definiremos a continuación, ya que más tarde profundizaremos en lo que implica cada una y en los distintos niveles de madurez que pueden representar a su vez:
Ahora que tenemos una vista panorámica de cada una de las fases y qué las conforman, vamos a profundizar en cada una de ellas. Usaremos ejemplos para reforzar este concepto, dado que es el más importante de entender.
Vamos a partir de 3 ejemplos de empresas, en creciente nivel de madurez y postura de ciberseguridad:
Una pequeña empresa de 5-10 empleados, sin oficina física, encargada de desarrollar una aplicación. Toda su operación se realiza a través de servicios SaaS
Una empresa mediana, 20-100 empleados, con una oficina, encargada de ofrecer servicios de ciberseguridad a otras empresas. Tienen infraestructura on-premise y cloud, principalmente con servicios SaaS, pero sin conectar ni haber desarrollado especialmente ambas.
Una empresa grande, >500 empleados, con múltiples oficinas, encargada de ofrecer infraestructura y servicios en el sector de la energía. Tienen una infraestructura completamente híbrida y operan a nivel internacional.
Tengamos en cuenta que las propuestas que se van a plantear en cada fase son meramente sugerencias, y no una guía paso a paso. Cada responsable deberá tener en cuenta el contexto de su negocio, madurez en ciberseguridad y recursos, considerando como puede aplicarlo adaptándose a sus circunstancias particulares.
Como hemos visto antes, esta fase consiste en definir los activos que se van a comenzar a gestionar mediante la metodología CTEM. Es una de las fases más importantes por varios motivos:
Nos ayuda a comunicar con el resto de equipos, qué activos son los que consideramos críticos, las métricas que estamos usando para esto, qué nivel de visibilidad tenemos sobre los activos, y cuantos podemos gestionar con las capacidades actuales.
Al ser la fase inicial, provocará un efecto bola de nieve sobre las siguientes fases, por lo que es, posiblemente, la que mayor consideración requiera.
Es la fase que nos va a permitir que esto sea un proceso iterativo, comenzando por un número reducido de activos contemplados dentro del scope y aumentando de manera cíclica en caso de que no contemos con la capacidad, o abarcando más en caso de que sea posible.
Aquí debemos tener presente que incluimos como activos, cualquier sistema o dato asociado a la empresa; desde un controlador de dominio, hasta un documento con información confidencial, pasando por las credenciales de la cuenta para redes sociales de la compañía.
Es de hecho en esta fase donde debemos tener muy en cuenta el nivel de madurez de ciberseguridad que tiene la empresa donde estamos aplicando CTEM. Veamos un par de ejemplos que continuaremos en las siguientes fases para entender cómo ir implementandolo por fases y en base a la madurez.
Partiendo de estas empresas, exploremos cómo se podría proceder para realizar esta primera fase:
Partiendo de la base de que no disponen de una oficina física, ni tienen a su cargo hardware, salvo los equipos que usa cada uno de los empleados, los activos a tener en cuenta van a ser un tanto diferentes de lo que podríamos encontrarnos en estructuras más tradicionales.
Un buen modelo a seguir podría ser:
- Comenzamos abarcando el core de negocio: la aplicación que están desarrollando y de la que depende toda la empresa.
- En siguientes iteraciones del ciclo CTEM podríamos abarcar a los equipos que usan los usuarios
- Tras esto, podríamos integrar las personas, en específico sus cuentas y configuraciones que tenemos desplegadas
Finalmente, nos podemos encargar de las fuentes públicas, buscando credenciales filtradas, reputación de la marca, información en RRSS, etc.
En este caso contamos con una estructura mucho más familiar para todos. Nos encontramos múltiples servidores, tanto on-premise como en el cloud, tenemos un Active Directory, accesos VPN, etc. En este caso, una de las mejores maneras de realizar el scoping, no es seleccionando activos de manera individual por su criticidad para el, si no agrupándolos por funcionalidades de negocio, y priorizando estos grupos en conjunto.
Una de las ventajas que nos podemos encontrar al realizar esto, es que un mismo activo se encuentre presente en varios grupos al mismo tiempo, lo que permea al resto de fases de CTEM, provocando que una movilización sobre este activo tenga un beneficio mucho mayor que simplemente el haber bajado el riesgo de una vulnerabilidad en base a su criticidad.
De nuevo, las iteraciones que podríamos seguir son:
- Agrupar los activos conocidos en base a funcionalidades de negocio y comenzar priorizando los que consideremos más críticos, abarcando más o menos en base a nuestra capacidad.
- Ir ampliando progresivamente los activos que abarca nuestro programa hasta recoger todos los grupos que habíamos definido previamente
- Ampliamos el programa con un ASM (Attack Surface Management)para comenzar a recoger también activos no conocidos.
Tras esto, podemos ampliar a revisiones de la postura de seguridad en SaaS
En organizaciones grandes, con miles de empleados, múltiples oficinas, operaciones internacionales y entornos híbridos complejos (cloud, on-premise, OT, IoT, SaaS, supply chain), la fase de scoping se convierte en una actividad crítica y estratégica. No es viable realizar una selección manual de activos ni confiar únicamente en el conocimiento tribal o documentación estática. Se requiere una aproximación basada en automatización, categorización funcional y criterios de riesgo corporativo.
En este contexto, el scoping no sólo define qué activos se van a gestionar, sino que marca el alcance del programa, los límites de visibilidad y las dependencias entre entornos. Es frecuente que los activos se clasifiquen por dominios de negocio, por unidad organizativa, o incluso por nivel de regulación (PCI, NIS2, ISO27001), y cada uno de estos dominios puede tener un nivel de madurez distinto.
Un enfoque efectivo podría seguir estas fases:
- Consolidar todos los activos conocidos en una CMDB enriquecida con datos de CAASM, inventario cloud, sistemas OT e identidades, categorizándolos por unidad de negocio y criticidad.
- Definir un alcance inicial sobre dominios clave de alto riesgo o alta exposición (e.g., servicios accesibles desde internet, infraestructuras core, entornos industriales conectados).
- Alinear las fuentes de visibilidad (logs, agentes, herramientas de escaneo) con los activos del scope definido, ajustando el modelo según limitaciones operativas.
- Ampliar progresivamente el scope con base en dependencias entre entornos, riesgos residuales y capacidad de cobertura.
- Integrar EASM y ASM para identificar activos desconocidos que puedan estar fuera de la CMDB o gestionados por terceros.
Este enfoque permite transformar el scoping en una actividad continua y estratégica, en lugar de una tarea puntual, maximizando el retorno del programa CTEM al asegurar que los recursos se enfocan donde más impacto tienen. Estas actividades no solo nos ayudan a identificar los activos que queremos analizar, si no que pueden poner de manifiesto la falta de visibilidad o conocimiento sobre ciertas áreas. Esto, a su vez, permite reforzar esos puntos ciegos de la organización en próximas iteraciones.
En esta fase se identifican activos y exposiciones: vulnerabilidades, configuraciones erróneas, credenciales expuestas, shadow IT, dispositivos no gestionados, etc. El objetivo es construir un inventario completo de riesgos sobre los activos definidos en la fase de scoping.
En esta etapa, el principal objetivo será identificar la exposición real de la empresa, teniendo en cuenta que la mayoría de sus activos residen en plataformas SaaS o entornos gestionados externamente. En lugar de depender de soluciones complejas o despliegues on-premise, se opta por herramientas ligeras y orientadas a servicios utilizados. El enfoque debe estar en descubrir configuraciones débiles, accesos indebidos o dependencias mal gestionadas.
La recolección de exposición se puede realizar en fases, partiendo de los activos más cercanos al core del negocio (la aplicación), y progresivamente abarcando:
- Revisión de configuraciones en servicios como GitHub, Firebase, Vercel o AWS básicos.
- Análisis de pipelines CI/CD en busca de credenciales embebidas o permisos excesivos.
- Validación de exposición pública de APIs, buckets, dashboards o paneles de gestión.
- Recogida de señales OSINT en fuentes abiertas que puedan vincularse a la empresa o producto.
El foco no está en la profundidad técnica, sino en maximizar la visibilidad con los mínimos recursos y configuraciones.
En este caso, el Discovery debe ejecutarse en múltiples capas, ya que nos enfrentamos a una infraestructura híbrida, con recursos on-premise y en la nube, además de servicios SaaS. Es crucial no limitarse a escaneos clásicos, sino que debe buscarse una correlación entre fuentes que nos permita enriquecer el inventario con contexto real.
Uno de los enfoques más eficaces es estructurar el descubrimiento en tres líneas:
- Escaneo técnico con herramientas on-prem (Nessus, Qualys, OpenVAS) y cloud-native (CSPM, CASM), ajustado a los grupos de activos definidos en el scoping.
- Descubrimiento externo mediante herramientas EASM, DNS pasivo, WHOIS y análisis de subdominios. Esto permite cubrir activos fuera del radar interno (Shadow IT).
- Correlación con fuentes de inteligencia como IoCs, amenazas emergentes, leak credentials, o campañas activas asociadas al sector.
La clave está en unificar estas capas de datos en un único inventario de exposición, en donde el activo se contextualiza, no solo se cataloga.
En empresas de gran tamaño, el Discovery debe ser continuo, distribuido y orquestado. Dado que el número de activos se vuelve inabarcable manualmente, se hace imprescindible automatizar este descubrimiento, asegurando que el inventario refleje la realidad operativa, no un snapshot estático.
Esto implica usar una combinación de fuentes y herramientas altamente integradas:
En este entorno, el objetivo ya no es solo descubrir, sino asegurar trazabilidad de los cambios en la exposición, visibilidad sobre activos dinámicos (autoscaling, servidores efímeros) y capacidad de análisis sobre relaciones entre activos (e.g., red lateral, relaciones de permisos, herencias de privilegios).
En esta fase se analizan las exposiciones descubiertas en función de su impacto potencial en el negocio. Se tienen en cuenta factores como la criticidad del activo, facilidad de explotación, amenazas activas y contexto de negocio, con el objetivo de enfocar los esfuerzos en los riesgos más relevantes y urgentes.
En entornos con recursos limitados, la priorización debe enfocarse en proteger los activos más vinculados al negocio y reducir exposición con el menor esfuerzo. Normalmente, esta fase no se basa en fórmulas complejas, sino en sentido común técnico alineado con impacto inmediato.
Algunas estrategias efectivas:
- Priorizar vulnerabilidades que afecten directamente a la app principal, su infraestructura o datos sensibles.
- Dar prioridad a configuraciones erróneas que puedan exponer credenciales, entornos o secretos.
- Aplicar el criterio de “¿qué explotaría un atacante en los primeros 30 minutos?” como filtro práctico.
Se trata de proteger la operativa básica y prevenir exposición reputacional o de datos evidentes, sin necesidad de una arquitectura formal de riesgo.
Aquí la priorización puede y debe basarse en una lógica más estructurada, considerando no solo criticidad técnica (CVSS) sino también el impacto en el negocio y nivel de exposición real. Lo recomendable es desarrollar un modelo de scoring adaptado al contexto de la empresa.
Algunos ejes típicos:
- Integrar la criticidad del activo (impacto en negocio, clientes, continuidad) con la explotabilidad real (EPSS, existencia de PoC).
- Considerar rutas de ataque laterales: ¿este activo puede ser usado para pivotar?
- Aplicar un enfoque grupal: si una vulnerabilidad afecta a un activo que está en varios procesos de negocio, su prioridad sube.
Este modelo permite ordenar el backlog de exposición y tomar decisiones con base contextual, no solo técnica.
A este nivel, la priorización requiere herramientas específicas y automatización. El volumen y complejidad de activos obliga a usar análisis de -attack paths*, correlación con amenazas reales y factores de negocio estratégicos.
Algunas prácticas clave:
- Utilizar motores de riesgo dinámico que integren CTI, topología, rutas de ataque y datos de explotación real.
- Incluir en la ecuación la dependencia entre activos y servicios: un sistema de monitorización vulnerable puede ser más crítico que un servidor frontal.
- Evaluar impacto sistémico: una explotación en un AD global o un SSO tiene un alcance desproporcionado.
El objetivo no es solo arreglar vulnerabilidades, sino reducir el riesgo operativo acumulado, es decir, no solo se tiene en cuenta el CVSS, si no que se incluye el concepto de "attack paths" (rutas de ataque). Esto permite evaluar el impacto en cadena que podría tener la explotación de una vulnerabilidad, derivando en el compromiso de un activo o la exposición de datos sensibles. Por ejemplo, el acceso a redes internas de la organización o el compromiso de cuentas privilegiadas que pueden dar lugar a compromisos posteriores.
Esto nos permite establecer una métrica que, con su evolución en el tiempo, marca el valor de esta estrategia y la mejora continua de la postura de seguridad de la organización
Aquí se evalúa la explotabilidad real de los riesgos priorizados, mediante técnicas como validación manual, explotación controlada o correlación con actividad maliciosa observada. Esto permite descartar falsos positivos y ajustar la priorización según el riesgo real, no solo teórico.
Validar, en este contexto, implica comprobar de forma práctica si los riesgos priorizados son reales y explotables. Generalmente se hace de forma manual o semi-automatizada, aprovechando herramientas gratuitas u open-source.
Técnicas aplicables:
- Verificar exposición real mediante navegación directa (e.g. endpoint expuesto, panel sin auth).
- Uso de herramientas ligeras como nuclei, Burp Suite Community, ffuf, etc.
- Validaciones puntuales de acceso o abuso de configuraciones (e.g., acceso público a S3, secretos en GitHub).
Lo importante es validar antes de invertir esfuerzo en corregir, especialmente si se tiene poca capacidad.
En este escenario es viable integrar procesos de validación semi‐formales, alternando automatización y pruebas manuales según criticidad del riesgo.
Buenas prácticas:
- Validación automatizada con herramientas BAS o scanners activos personalizados.
- Red Team puntual sobre rutas de ataque priorizadas.
- Validaciones internas cruzadas entre equipos: hardening vs explotación.
El objetivo es no basarse solo en teorías (CVSS), sino en riesgo técnico efectivo, confirmando vectores antes de movilizar recursos.
La validación se convierte en una disciplina en sí misma. Requiere infraestructura específica, reglas claras y separación de funciones.
Enfoques usados:
- Plataformas BAS integradas y continuas (SafeBreach, AttackIQ).
- Simulación de TTPs reales mediante ATT&CK + threat intelligence actualizada.
- Validación cruzada: simulación ofensiva vs defensa (SOC) para medir cobertura.
Aquí no se busca validar “si se puede explotar”, sino cuál sería el impacto, por qué no fue detectado y qué controles fallaron. Esto permite no solo reducir la explotabilidad de los sistemas al corregir vulnerabilidades, sino también la posibilidad de mejorar las capacidades de detección del SOC o despliegues de soluciones de defensa en activos.
En esta fase se movilizan los equipos adecuados (IT, seguridad, desarrollo, etc.) para mitigar las exposiciones validadas. Se definen planes de acción, se realiza el seguimiento de la remediación y se actualiza el estado del riesgo, cerrando el ciclo del CTEM y permitiendo iniciar nuevas iteraciones con conocimiento más preciso.
La ejecución de medidas correctivas suele ser directa: el mismo equipo que descubre o valida, actúa. Por tanto, la clave está en priorizar bien para no saturar.
Acciones típicas:
Es importante mantener un registro simple de lo corregido y del por qué, para iterar en la próxima vuelta del ciclo.
Aquí entra en juego la coordinación. Ya no es una persona quien actúa, sino distintos equipos: IT, desarrollo, seguridad. La mobilization debe estar planificada y medible.
Estrategias efectivas:
- Crear tickets de remediación con responsables, fechas objetivo y validación post-corrección.
- Automatizar acciones simples (patches, hardening) y escalar las más críticas a gestión.
- Establecer dashboards de avance y métricas como MTTR (mean time to remediate).
El objetivo es mantener el ciclo CTEM activo sin fricción entre áreas.
La fase de mobilization requiere procesos robustos de gestión de cambios, orquestación y validación post‐ejecución. Se prioriza la trazabilidad y la alineación con objetivos estratégicos de seguridad.
Elementos clave:
- Integración con plataformas SOAR o ITSM (ServiceNow, Jira, etc.) para gestión automatizada.
- Priorización en función del impacto en resiliencia organizacional.
- Revisión formal de las acciones tomadas, validación cruzada, y retroalimentación hacia las fases de scoping y discovery.
-No es solo Vulnerability Management (VM): VM detecta CVEs, CTEM explora exposición completa, incluye misconfiguraciones, credenciales, rutas de ataque, assets internos/externos, y más.
-No es un Pentest puntual: Pentesting es one‐off; CTEM es continuo, automatizado y se realimenta continuamente.
-No es un producto o herramienta: Es un marco organizativo que integra personas, procesos y tecnologías, haciéndolo agnóstico a las tecnologías que pueden cambiar con el tiempo.
-No es ASM/TEM aislado: ASM ayuda en discovery, pero no aborda priorización ni validación; necesita CTEM para cerrar el ciclo.
CTEM es una forma de poner orden y continuidad en procesos que muchas veces tratamos de manera aislada: descubrir, priorizar, validar y corregir. La clave está en que no se trata de un checklist ni de un escaneo puntual, sino de un ciclo que se adapta a la realidad de cada organización.
Al final, lo que diferencia a CTEM es que no se centra en la vulnerabilidad en sí, sino en la exposición real y en cómo esta puede convertirse en un riesgo tangible para el negocio. Entender esto permite alinear mejor los esfuerzos de seguridad con los recursos disponibles y, sobre todo, con lo que realmente importa: reducir la probabilidad de que un ataque tenga impacto en la organización.
En resumen: CTEM no compite con VM, Pentesting o ASM, sino que los conecta bajo un mismo marco, asegurando que la seguridad no dependa de fotos estáticas, sino de un proceso continuo y enfocado en lo que de verdad importa.