La mayoría de los programas de gestión de vulnerabilidades se limitan a «la hemos detectado» y «la hemos corregido». CTEM incorpora el paso que la mayoría de los programas omiten: verificar que la exposición se haya cerrado efectivamente y que los controles funcionen según lo previsto.
En este artículo se desglosa lo que requiere cada etapa a escala empresarial, en qué puntos suelen estancarse los programas y cómo evaluar si sus iniciativas de CTEM están reduciendo el riesgo o si, por el contrario, solo generan actividad.
Explicación del CTEM
La gestión continua de la exposición a amenazas es un marco de trabajo de cinco etapas . Gartner presentó el « » para ayudar a las organizaciones a reducir de forma sistemática su exposición a riesgos de seguridad. Las cinco fases son: definición del alcance, análisis, establecimiento de prioridades, validación y puesta en marcha.
A diferencia de las evaluaciones periódicas de vulnerabilidades , que se centran principalmente en elaborar listas de hallazgos, el CTEM hace hincapié en si las condiciones de exposición son accesibles y se pueden abordar de forma realista, y en si la corrección de vulnerabilidades y los controles modifican de forma cuantificable esa realidad. El CTEM tiene en cuenta, a la hora de establecer prioridades, la viabilidad de los ataques en el mundo real, los controles compensatorios, la importancia de los activos y la accesibilidad de las vías de ataque, un contexto que las puntuaciones CVSS por sí solas no proporcionan.
El CTEM transforma el modelo operativo en un enfoque proactivo, pasando de una evaluación periódica y la creación de incidencias a un ciclo continuo que determina qué aspectos son relevantes, verifica si las vulnerabilidades pueden ser explotadas o permitir el movimiento lateral, confirma la eficacia de los controles y pone en marcha medidas correctivas con responsabilidades bien definidas.
La gestión tradicional de vulnerabilidades identifica los CVE y los clasifica según su gravedad según el CVSS. Esto arroja resultados, pero no responde a la pregunta que realmente preocupa a los responsables de seguridad: ¿qué vulnerabilidades puede aprovechar de forma realista un atacante para acceder a activos críticos?
El CTEM amplía la definición de «exposición» más allá de las vulnerabilidades para incluir cualquier deficiencia que requiera medidas de mitigación. Una evaluación exhaustiva de la vulnerabilidad tiene en cuenta no solo las vulnerabilidades CVE sin parchear, sino también las configuraciones erróneas, los riesgos relacionados con la identidad, los permisos excesivos, los activos expuestos al exterior, la «TI en la sombra» o cualquier circunstancia que un atacante pudiera aprovechar. El objetivo no es encontrar más problemas. Consiste en centrar los esfuerzos de corrección en las vulnerabilidades que más importan para su entorno específico.
[Descubra cómo encaja la gestión de la exposición en una estrategia de seguridad más amplia]
El CTEM no sustituye a la gestión de vulnerabilidades. Se trata de un programa estructurado que se adapta a sus flujos de trabajo actuales de análisis, priorización y corrección, basándose en el contexto empresarial para hacerlos más eficaces. El resultado: menos vulnerabilidades sin resolver, una corrección más rápida y una inversión en seguridad centrada en los ámbitos de mayor riesgo.
Para comprender qué aporta el CTEM, hay que empezar por reconocer en qué aspectos se quedan cortos los enfoques tradicionales.
Por qué la gestión tradicional de vulnerabilidades resulta insuficiente
La deficiencia no radica en la cobertura de los procesos. Se trata de una verificación. Si bien muchos programas consolidados de gestión de vulnerabilidades y de gestión de riesgos suelen contar con flujos de trabajo de análisis, priorización y corrección, algunos siguen considerando que la corrección ha concluido una vez aplicada la solución, a menudo sin confirmar que la vulnerabilidad se haya subsanado realmente.
Esto genera un punto ciego crucial entre la acción y el resultado. Sin una validación continua, los equipos pueden dar por hecho que el riesgo se ha reducido, cuando en realidad la vulnerabilidad subyacente sigue existiendo debido a implementaciones fallidas, desviaciones en la configuración o correcciones incompletas.
Los modelos de evaluación periódica acentúan aún más esta brecha. En muchos entornos, los análisis programados pueden dejar «ventanas» en las que persisten exposiciones nuevas o modificadas hasta el siguiente ciclo de recopilación, especialmente en entornos de nube, SaaS e identidad que cambian rápidamente. Los atacantes no esperan a que se ejecute su programa de análisis.
Las herramientas aisladas fragmentan el contexto. Los escáneres, los informes de pruebas de penetración, los inventarios de activos y los sistemas de gestión de incidencias a menudo no comparten datos. Los equipos de seguridad acaban intentando correlacionar manualmente los resultados obtenidos a través de herramientas inconexas para obtener una visión coherente de lo que realmente está en riesgo.
La priorización basada únicamente en la gravedad genera carteras de trabajo inviables. Una puntuación CVSS indica, en términos generales, la gravedad que podría tener una vulnerabilidad. No le indica si esa vulnerabilidad existe en un recurso que pueda acceder a sus controladores de dominio, ni si está circulando activamente algún código malicioso que la aproveche.
No se ha comprobado que los controles funcionen realmente. La mayoría de los programas registran si se ha instalado un parche. Son menos los que confirman si la posición está realmente cerrada. Es posible que se siga pudiendo acceder a un CVE parcheado en un sistema mal configurado a través de una ruta diferente.
En el contexto del CTEM, el término «validación» puede incluir la verificación de si una vulnerabilidad puede explotarse realmente en el entorno, la confirmación de la cobertura de los controles frente a las técnicas pertinentes y la nueva comprobación del activo o estado específico tras la corrección.
La brecha organizativa. Los equipos de seguridad elaboran informes. Los equipos de operaciones de TI son los responsables de la corrección de los problemas. Sin flujos de trabajo ni mecanismos de gobernanza compartidos, las vulnerabilidades validadas quedan en una cola a la espera de una ventana de actualización sobre la que el equipo de seguridad no tiene visibilidad alguna.
Para los CISO, esta carencia organizativa suele ser el problema más difícil de resolver. Se trata de un reto relacionado con la gobernanza, la gestión de riesgos y la rendición de cuentas, tanto como de un reto técnico.
El CTEM aborda cada una de estas carencias al considerar la exposición al riesgo de « » y la reducción de « » como un programa continuo e integrado. En la siguiente sección se explica detalladamente cómo funciona cada etapa.
[Más información sobre la metodología de gestión de amenazas y vulnerabilidades]
Las cinco fases del CTEM
Las cinco fases del proceso CTEM forman un ciclo continuo. Cada fase da paso a la siguiente, y el ciclo se repite a medida que su entorno cambia y las amenazas emergentes exigen actualizar las prioridades en materia de alcance, detección y validación.
Comprender el ciclo de vida completo de un ciclo CTEM, desde la definición inicial del alcance hasta la corrección validada, resulta esencial para diseñar un programa que genere una reducción cuantificable del riesgo, en lugar de limitarse a una actividad recurrente.
1. Definición del alcance
La definición del alcance establece qué partes del entorno se evaluarán y cómo se mide la exposición. Esto no es solo un ejercicio técnico. Esto requiere un acuerdo entre los responsables de seguridad y los de la empresa sobre qué niveles de activos se incluyen en el ámbito de aplicación de cada ciclo, basándose tanto en los objetivos empresariales como en el riesgo técnico.
Las decisiones relativas al alcance deben revisarse periódicamente a medida que evolucionan las prioridades empresariales. Una fusión, el lanzamiento de un nuevo producto o el paso al teletrabajo pueden modificar cuáles son los activos más críticos y, por lo tanto, cuáles son los riesgos que requieren una atención más urgente.
La supervisión continua de todos los elementos en entornos distribuidos conlleva una serie de compensaciones, entre las que se incluyen el impacto en la red y el volumen de alertas. La definición del alcance requiere un acuerdo negociado sobre qué niveles de activos reciben una cobertura continua, cuáles se someten a evaluaciones periódicas y quién tiene la autoridad para ajustar el alcance a medida que cambia el entorno.
¿Qué significa «continuo» en términos operativos?
No todas las señales de un programa CTEM se actualizan con la misma frecuencia. Algunas fuentes de datos, como el estado de los terminales y la telemetría, pueden proporcionar información casi en tiempo real, mientras que otras (como los análisis de vulnerabilidades de ) siguen siendo periódicas. Las organizaciones deben definir umbrales aceptables de actualidad de los datos para cada nivel de activos. Si una fuente de datos suele estar desactualizada, sus resultados deben considerarse menos fiables hasta que se vuelvan a validar.
Los programas de CTEM suelen fallar cuando los equipos dan por sentado que todos los datos de entrada están igualmente actualizados. En la práctica, para garantizar la precisión es necesario actualizar continuamente los datos de inventario y verificar la titularidad y el contexto de los activos.
La información sobre amenazas sirve de base para las decisiones relativas al alcance del análisis, al poner de manifiesto qué tipos de activos son objeto de ataques activos. A medida que cambia el panorama de amenazas (por ejemplo, cuando los autores de las amenazas comienzan a atacar activamente los dispositivos VPN), esos tipos de activos pasan a ocupar un lugar más destacado en la lista de prioridades del ciclo actual.
[Descubra cómo la información sobre amenazas cibernéticas influye en las decisiones de seguridad]
Un error habitual en las primeras etapas es considerar que definir el alcance consiste en «enumerarlo todo». En CTEM, la fase de definición del alcance establece qué aspectos son relevantes y cómo se mide el éxito; la fase de descubrimiento enumera lo que existe dentro de ese alcance.
2. Descubrimiento
La detección de activos en CTEM permite identificar la superficie de ataque más allá del inventario tradicional de activos, abarcando vulnerabilidades, errores de configuración, activos expuestos al exterior, TI en la sombra y riesgos relacionados con la identidad.
En entornos grandes y complejos, la detección en más de 50 000 terminales suele requerir la combinación de varios métodos de recopilación de datos, entre los que se incluyen la telemetría de los terminales (cuando están gestionados), los datos de red y de los escáneres, y las fuentes del plano de control en la nube o de SaaS (API). Tanto los enfoques basados en agentes como los que no lo están presentan ventajas e inconvenientes, y los distintos entornos —locales, en la nube e híbridos— plantean retos específicos. Además, cada método presenta diferencias en cuanto a cobertura, actualidad y fiabilidad, especialmente en el caso de los activos efímeros.
La «TI en la sombra» y los dispositivos no gestionados suelen representar las mayores lagunas de visibilidad, ya que quedan totalmente fuera del alcance de los análisis estándar y, por lo tanto, son los que tienen más probabilidades de albergar vulnerabilidades no detectadas.
Las aplicaciones SaaS plantean un reto similar. Las unidades de negocio suelen adoptar herramientas basadas en la nube sin consultar al departamento de TI ni al de seguridad, lo que genera riesgos que nunca aparecen en los inventarios de activos tradicionales.
La identidad y la titularidad de los activos se encuentran entre sus resultados de investigación más destacados. Los resultados de las pruebas de exposición que no pueden vincularse a un propietario suelen quedar estancados en la fase de movilización. Mantenga una correspondencia fiable entre los identificadores técnicos (nombre de host, ID de instancia, cuenta, inquilino de la aplicación) y los equipos de negocio a los que pertenecen.
Por este motivo, la gestión de la superficie de ataque externa (EASM) se ha convertido en un elemento importante de la fase de detección. Las herramientas de EASM proporcionan una visibilidad continua de los activos conectados a Internet, incluidos aquellos que quizá no figuren en los inventarios internos.
Las vulnerabilidades relacionadas con la identidad requieren una integración con los datos del proveedor de identidad, y no solo un análisis de los terminales. Una cuenta de servicio con privilegios de administrador de dominio que no se haya utilizado en 18 meses puede suponer un riesgo, aunque no aparezca en un análisis de vulnerabilidades.
3. Establecimiento de prioridades
La priorización clasifica los riesgos en función de su explotabilidad, su impacto potencial y su relevancia para los atacantes, en lugar de basarse únicamente en la gravedad según el CVSS.
Los grandes volúmenes de resultados fuera de contexto suelen ser difíciles de poner en práctica; para establecer prioridades es necesario tener en cuenta la importancia de los activos, las señales de explotación, el contexto de control y la relevancia de las rutas accesibles, con el fin de centrar los esfuerzos. Para establecer prioridades de forma eficaz en entornos reales es necesario:
- Niveles de criticidad de los activos: Definidos por la organización, no por el escáner
- Señales de disponibilidad de exploits: , como el EPSS (Sistema de puntuación para la predicción de exploits) y el catálogo de vulnerabilidades explotadas de la CISA
- Análisis de la ruta de ataque: . Este análisis identifica qué vulnerabilidades permiten el movimiento lateral hacia los activos más valiosos.
Un paso práctico para establecer prioridades consiste en distinguir entre las vulnerabilidades accesibles desde Internet y aquellas accesibles internamente que permiten el movimiento lateral.
Los riesgos relacionados con Internet suelen recibir una atención inmediata. Sin embargo, las vulnerabilidades accesibles internamente, como los riesgos relacionados con la identidad, los privilegios excesivos o las relaciones de confianza mal configuradas, pueden constituir vías de ataque de gran impacto para los activos críticos.
Una priorización eficaz tiene en cuenta ambos aspectos. Pondera las vulnerabilidades en función de su accesibilidad y de su papel a la hora de facilitar el avance del atacante, y no solo en función de su gravedad abstracta.
El análisis de la ruta de ataque consiste en identificar cómo un atacante podría encadenar varias vulnerabilidades para alcanzar objetivos de gran valor. Este contexto resulta esencial para la toma de decisiones: hace que el establecimiento de prioridades pase de ser un ejercicio mecánico de puntuación a un juicio basado en el riesgo sobre qué exposiciones suponen la amenaza más creíble para los activos críticos de la empresa. Una vulnerabilidad CVE con una puntuación CVSS de 6 en un activo adyacente a un controlador de dominio de puede justificar una prioridad mayor que una vulnerabilidad con una puntuación CVSS de 9 en un equipo de desarrollo aislado.
4. Validación
La validación comprueba si los controles de seguridad detectan o bloquean las técnicas asociadas a las vulnerabilidades priorizadas y confirma si dichas vulnerabilidades representan un riesgo real de ataque en el entorno. Asimismo, determina si los controles mitigan eficazmente dichos riesgos, mediante enfoques como el «purple teaming», las pruebas específicas o la simulación de ataques y brechas de seguridad (BAS).
Existen dos modos de validación que cumplen funciones distintas a escala empresarial:
- Validación adversarial: El «red teaming» y el BAS prueban escenarios de ataque específicos contra activos críticos mediante la simulación de un comportamiento realista del adversario. Es un proceso periódico, que requiere un gran consumo de recursos y que arroja resultados de gran fiabilidad.
- Verificación continua de la corrección (nueva comprobación del activo y su estado): Confirma que se ha resuelto una vulnerabilidad concreta en un activo específico. Puede ejecutarse automáticamente tras la corrección (siempre que la telemetría y los flujos de trabajo lo permitan) y ofrece una garantía continua.
En la práctica, las organizaciones suelen dar prioridad a un modo frente al otro, en lugar de combinarlos. La validación adversaria suele ser periódica (a menudo anual o trimestral en el caso de escenarios de alto valor), requiere un gran volumen de recursos y arroja resultados de gran fiabilidad, mientras que la verificación continua de las medidas correctivas se lleva a cabo de forma menos sistemática.
Un ejemplo habitual son las pruebas de penetración: ofrecen información valiosa sobre cómo un atacante podría aprovechar las vulnerabilidades existentes en un momento dado, pero no confirman si dichas vulnerabilidades siguen sin estar subsanadas a medida que cambia el entorno. Una prueba de penetración realizada en Q1 no valida el estado de los controles en Q3.
Por ello, la validación debe confirmar dos condiciones:
- Si la vulnerabilidad puede aprovecharse realmente en el entorno actual o si existen controles adecuados que impidan la técnica de ataque
- Si la vulnerabilidad permanece cerrada a lo largo del tiempo, teniendo en cuenta las desviaciones en la configuración, las nuevas implementaciones o los cambios en las políticas que puedan volver a introducir riesgos
Sin ambas comprobaciones, la corrección puede parecer completa, mientras que las condiciones de exposición vuelven a aparecer de forma imperceptible.
[Comprenda en qué se diferencia la búsqueda de amenazas de la validación]
5. Movilización
La movilización coordina las medidas correctoras entre los equipos de seguridad y de TI. Las conclusiones se traducen en medidas concretas, con una responsabilidad clara y plazos definidos.
Las prioridades de corrección deben reflejar los objetivos empresariales. Una vulnerabilidad confirmada en un sistema crítico para los ingresos requiere un plazo de respuesta distinto al que se aplicaría en el caso de la misma vulnerabilidad en una herramienta interna de baja criticidad.
Esta fase es en la que se estancan la mayoría de los programas CTEM de las empresas. En la siguiente sección se aborda este tema en profundidad.
La brecha en la movilización
La movilización fracasa cuando el departamento de seguridad se hace cargo de los hallazgos y el departamento de operaciones de TI se encarga de la corrección, pero ninguno de los dos se hace cargo del traspaso de responsabilidades.
El procedimiento es habitual: el departamento de seguridad identifica una vulnerabilidad validada, crea un ticket y espera, mientras que el departamento de operaciones de TI la añade a la lista de tareas pendientes y la programa para una futura ventana de cambios de « ». Mientras tanto, la posición sigue abierta.
Una movilización eficaz también requiere vías de excepción explícitas. No todas las exposiciones validadas pueden esperar a los plazos estándar de cambio.
Las organizaciones deben definir criterios que determinen en qué casos los hallazgos de alto riesgo deben eludir los ciclos de implementación habituales, así como establecer procesos claros de aprobación y reversión. Sin estas vías de excepción, las exposiciones validadas compiten con las tareas operativas habituales y, a menudo, quedan sin resolver a pesar de que se les haya dado prioridad.
Requisitos de gobernanza para la corrección automatizada. No todos los hallazgos pueden activar una corrección automatizada de . Las organizaciones necesitan contar con políticas claras sobre qué tipos de incidencias pueden solucionarse automáticamente y cuáles requieren una revisión por parte del departamento de gestión del cambio.
Una secuencia de implementación progresiva basada en anillos contribuye a limitar el alcance del impacto. La implementación progresiva por anillos implica que los cambios avanzan a través de los distintos anillos de implementación: primero en el anillo de pruebas, luego en el de alta prioridad y, por último, en el de implantación generalizada. Cada ciclo comprueba la estabilidad antes de que comience el siguiente.
La integración de ITSM es determinante para que la movilización funcione. Los resultados del CTEM deben integrarse en su sistema de gestión de incidencias actual (ServiceNow Vulnerability Response es un ejemplo habitual) con suficiente contexto para que el equipo de operaciones de TI pueda actuar sin necesidad de un paso adicional de clasificación.
El parte debe incluir la vulnerabilidad concreta y los activos afectados, el contexto empresarial y el nivel de criticidad de los activos, las medidas correctivas recomendadas y el SLA basado en el riesgo validado.
| Sistema métrico | Qué mide |
|---|---|
Tiempo medio de corrección (MTTR) de los hallazgos críticos validados | Tiempo transcurrido desde la validación hasta la corrección confirmada |
| Tasa de cesión de la propiedad | Porcentaje de hallazgos validados a los que se les ha asignado un responsable en el marco del SLA |
| Índice de aprobados en la revalidación | Incidencias en las que se ha completado la corrección y se ha superado la revalidación, frente a incidencias cerradas sin revalidación |
La movilización consiste en la ejecución coordinada de medidas correctoras a raíz de un hallazgo validado. No se trata de una respuesta ante incidentes provocada por una amenaza activa. Esta distinción es importante para la gobernanza y el diseño de los flujos de trabajo.
Dicho esto, los resultados validados del CTEM deberían servir de base para los planes de respuesta. Las organizaciones que conocen sus mayores riesgos están mejor preparadas para contener los incidentes y recuperarse de ellos en caso de que dichos riesgos llegaran a ser aprovechados antes de que se complete la corrección.
Para subsanar la brecha en materia de movilización se requiere algo más que cambios en los procesos. Además, es necesario replantearse cómo funciona la validación.
Validación de exposiciones reales
La brecha de validación es precisamente donde la mayoría de los programas generan una confianza errónea. Hacer un seguimiento de la colocación de los parches no equivale a confirmar que se ha puesto fin a la exposición. Es posible que se siga pudiendo acceder a un sistema al que se le han aplicado parches a través de una vía de ataque diferente si las configuraciones subyacentes o las vías de acceso no han cambiado.
Es posible que una regla de cortafuegos destinada a bloquear una técnica de ataque no la bloquee realmente en la práctica. Por ello, la validación debe ir más allá de la mera confirmación de que se han implantado las medidas de seguridad. Debe confirmarse que son eficaces frente a las técnicas específicas que un atacante utilizaría para aprovechar una vulnerabilidad determinada. La validación confirma el riesgo real, y no solo la gravedad teórica.
Existen dos modos de validación que tienen fines distintos:
- Validación adversarial: Las pruebas de «red teaming» y BAS comprueban si determinadas vías de ataque logran afectar a activos críticos. Es un proceso que requiere muchos recursos y que suele llevarse a cabo cada trimestre o cada año.
- Verificación continua de la corrección (nueva comprobación del activo y su estado): Confirma que se ha resuelto una vulnerabilidad concreta en un activo específico. Se ejecuta automáticamente tras la corrección y ofrece una garantía continua.
El análisis de la ruta de ataque establece la conexión entre ambos. Indica qué exposiciones, si se encadenan, permiten acceder a los activos más valiosos de « ». Este contexto modifica el orden de prioridades. Una vulnerabilidad de gravedad media en un recurso que proporciona una vía de acceso a sus controladores de dominio es más urgente que una vulnerabilidad crítica en un sistema aislado.
Medición de la eficacia de los controles. ¿Bloquea realmente el control de seguridad (regla de cortafuegos, política de EDR, parche) la técnica de ataque asociada a la vulnerabilidad? ¿O bien bloquea una técnica diferente, dejando abierta la que nos interesa?
Una vez realizada la validación, la siguiente pregunta es cómo se integra CTEM en las herramientas y los flujos de trabajo que ya utiliza.
Integración de CTEM en los flujos de trabajo existentes
Llevar a cabo el CTEM como una línea de trabajo paralela es la forma más rápida de generar prioridades contradictorias en las operaciones de TI. El departamento de seguridad insta a que se apliquen medidas correctivas de forma inmediata; el departamento de TI opera con ciclos de cambio de dos semanas. El objetivo es la integración en los flujos de trabajo existentes, no crear una vía paralela a estos.
Si se aplica correctamente, el CTEM contribuye a optimizar las operaciones al reducir los traspasos manuales, eliminar los pasos de triaje duplicados y agilizar el paso de los resultados validados a la fase de corrección.
- Integración con ITSM: Los resultados de CTEM se incorporan a su sistema de gestión de incidencias actual. La estructura del ticket es importante: debe incluir suficiente información contextual (importancia del activo, riesgo validado, medida recomendada, SLA) para que el equipo de operaciones de TI pueda actuar sin necesidad de un traspaso adicional.
- El SIEM como fuente de información para la definición del alcance y la detección: . Los datos del SIEM revelan la actividad de amenazas activas y comportamientos anómalos que permiten determinar qué activos se incluyen en el alcance del ciclo actual del CTEM. Se trata de un complemento del programa, no de un sustituto del mismo.
- Cómo evitar el problema de los procesos paralelos: Las organizaciones que gestionan el CTEM como un programa de seguridad independiente generan conflictos de prioridades en las operaciones de TI. El departamento de seguridad espera que se adopten medidas correctoras de forma inmediata. El departamento de TI funciona con ciclos de cambio de dos semanas. Si no se cuenta con un sistema de gestión de excepciones para los hallazgos críticos validados, el conflicto es de carácter estructural.
- Compatibilidad con la gestión del cambio en TI: El despliegue progresivo por anillos y las ventanas de cambio son compatibles con la movilización del CTEM si el modelo de gobernanza está diseñado para ello. La clave consiste en establecer procedimientos de excepción para los hallazgos críticos validados que no puedan esperar a la próxima ventana programada.
El CTEM resulta más eficaz cuando actúa como capa de conexión en toda su pila de seguridad: recopila información procedente de sistemas SIEM, escáneres de vulnerabilidades, proveedores de identidad y sistemas de gestión de activos, y, a continuación, transmite los resultados priorizados y validados al ITSM para que se apliquen medidas correctivas coordinadas.
Este cambio hacia flujos de trabajo integrados refleja las tendencias generales del mercado. Las organizaciones están dejando de lado las herramientas puntuales y fragmentadas para optar por plataformas que unifican la detección, la priorización, la validación y la corrección. El objetivo es convertir los riesgos identificados en medidas coordinadas, fomentando así una cultura de seguridad proactiva.
Una vez que el CTEM se haya integrado en los flujos de trabajo existentes, el siguiente paso consiste en evaluar en qué punto se encuentra su programa en la actualidad.
Madurez del programa CTEM
¿En qué punto se encuentra su programa en la actualidad? Los tres niveles de madurez constituyen un marco de autoevaluación.
Nivel 1: Ad hoc/reactivo
Periódicamente se realizan análisis de vulnerabilidades. Los hallazgos se clasifican por orden de prioridad únicamente en función del CVSS. No está claro quién es el responsable de la rehabilitación. No existe ninguna validación formal que confirme que las correcciones funcionen. En este nivel, los riesgos de seguridad se abordan de forma reactiva, normalmente tras un incidente o una constatación de auditoría, en lugar de mediante un programa estructurado y continuo. Los departamentos de seguridad y de TI funcionan con sistemas independientes y los traspasos de información se realizan de forma manual.
Nivel 2: Periódico/estructurado
Los programas de análisis definidos están vinculados a los niveles de criticidad de los activos. La priorización basada en el riesgo tiene en cuenta el contexto de los activos. Existe un proceso formal de gestión de incidencias entre el departamento de seguridad y el de TI. Las pruebas de penetración o BAS se realizan al menos una vez al año. Se realiza un seguimiento del MTTR en el caso de los hallazgos críticos.
Nivel 3: Continuo / automatizado
En el Nivel 3, el programa funciona como un sistema continuo y que se refuerza a sí mismo: visibilidad en tiempo real de toda la población de terminales, priorización automatizada mediante datos del EPSS y del KEV de la CISA, integración con ITSM con creación automatizada de tickets y seguimiento de los SLA, verificación continua de la corrección, gobernanza de la implementación basada en anillos y métricas de movilización presentadas a nivel del programa. El resultado es una operación de seguridad en la que la reducción del riesgo es cuantificable, y no se da por sentada.
Lo que hace que una organización pase del Nivel 1 al Nivel 2 suele ser una decisión de gobernanza, no una decisión relacionada con las herramientas. Definir los niveles de criticidad de los activos, establecer modelos de responsabilidad y crear flujos de trabajo formales para el traspaso de responsabilidades no requiere de nueva tecnología.
Lo que permite a una organización pasar del nivel 2 al nivel 3 suele ser una decisión relacionada con las herramientas y la integración. La visibilidad en tiempo real, la priorización automatizada y la validación continua requieren capacidades de la plataforma que las herramientas de análisis periódicas no ofrecen.
Independientemente del nivel de madurez, el objetivo es el mismo: centrar los esfuerzos en materia de seguridad en los puntos vulnerables que plantean el mayor riesgo real para la empresa, en lugar de generar actividades que no se traduzcan en una reducción cuantificable del riesgo.
Los niveles de madurez ofrecen un marco para la autoevaluación. Las métricas permiten realizar un seguimiento del progreso.
Cómo medir el éxito del CTEM
Las métricas que importan son los indicadores de resultados, no los indicadores de actividad. El volumen de entradas y la frecuencia de escaneo le indican el nivel de actividad del programa. El MTTR en los hallazgos críticos validados le indica si el sistema está funcionando correctamente.
| Sistema métrico | Qué mide | Nivel de madurez |
|---|---|---|
| Tiempo medio de reparación (MTTR) en casos de hallazgos críticos validados | Tiempo transcurrido desde la validación hasta la corrección confirmada | Nivel 2+ |
| Duración del intervalo de exposición | Cuánto tiempo permanecen sin abordarse los riesgos de alta prioridad | Nivel 2+ |
| Cobertura de validación | Porcentaje de activos críticos y vías de ataque validados en el ciclo actual | Nivel 3 |
| Reducción de la tasa de falsos positivos | Disminución de los resultados que, según confirma la validación, no son realmente aprovechables | Nivel 3 |
| Evolución de la puntuación de riesgo | Evolución de la situación de seguridad de la organización a lo largo del tiempo mediante una metodología de puntuación coherente | Nivel 2+ |
Las organizaciones del nivel 2 suelen realizar un seguimiento de las tendencias del MTTR y de la puntuación de riesgo. Las organizaciones del nivel 3 incluyen la cobertura de validación y la duración de la ventana de exposición como indicadores principales.
Una vez que se tiene una idea clara de lo que exige el CTEM y de cómo medir los avances, la pregunta final es cómo las distintas plataformas dan soporte a este marco.
Cómo contribuye Tanium a la gestión continua de la exposición a amenazas
Muchos programas de CTEM se estancan porque las herramientas que detectan los puntos débiles no son las mismas que los subsanan. Tanium contribuye a subsanar esa brecha.
La plataforma de TI autónoma de Tanium, , ofrece a los equipos de seguridad y de TI una plataforma única y unificada para la detección, la priorización, la corrección y la validación posterior a la corrección, de modo que el ciclo se desarrolla sin necesidad de transferir tareas a sistemas desconectados ni de esperar a que se actualicen datos de análisis obsoletos.
Detección continua con información sobre los terminales en tiempo real
Tanium ofrece visibilidad en tiempo real del estado de los terminales gestionados, lo que permite a los equipos identificar los activos y los cambios a medida que se producen, en lugar de depender únicamente de análisis periódicos. Tanium puede ampliar la cobertura a dispositivos no gestionados en entornos locales, remotos y en la nube, lo que contribuye a reducir los puntos ciegos que suelen asociarse a la «TI en la sombra».
Establecimiento de prioridades basado en el riesgo y en el contexto
Tanium facilita la priorización basada en el riesgo a través de diversas funcionalidades. Por ejemplo, Tanium Benchmark permite determinar puntuaciones de riesgo en tiempo real y comparar las métricas de un cliente con las de otras empresas del sector, lo que ayuda a los equipos a centrar las medidas correctivas en aquellos ámbitos donde el riesgo es mayor en relación con su entorno. Tanium Guardian puede ayudar a las organizaciones a hacer frente a las vulnerabilidades de «día cero» y a aquellas que requieren una respuesta inmediata, gracias a la combinación de análisis de terminales en tiempo real con análisis seleccionados y opciones de corrección proporcionadas por los expertos en seguridad de Tanium.
Desde la evaluación hasta la actuación, todo en una única plataforma
Tanium permite a los equipos pasar de la identificación de vulnerabilidades a la adopción de medidas sin necesidad de cambiar de herramientas ni de fuentes de datos. Las medidas correspondientes a los resultados pueden aplicarse desde la misma plataforma, incluyendo la gestión de parches o los cambios de configuración, lo que contribuye a reducir los retrasos entre la detección y la corrección.
Validación continua de la reducción del riesgo
En lugar de dar por sentado que las medidas correctivas son eficaces, Tanium ofrece a los equipos la posibilidad de verificar los cambios en el estado de los terminales tras la aplicación de dichas medidas, utilizando los mismos datos en tiempo real que se emplean para la detección. Esto permite comprobar de forma continua si se han reducido las exposiciones, y no solo si las medidas correctoras se han registrado como completadas.
Preguntas frecuentes sobre el CTEM
La puesta en marcha de un programa CTEM plantea cuestiones concretas sobre las ventajas de este, cómo se compara con lo que ya dispone, qué se necesita realmente para gestionarlo y si la inversión se traduce en una reducción cuantificable del riesgo. Esto es lo que debe saber.
¿Cuál es la diferencia entre el CTEM y la gestión tradicional de vulnerabilidades?
La gestión de vulnerabilidades se centra en identificar y subsanar las debilidades conocidas (a menudo CVE) según un calendario establecido.
El CTEM es un modelo operativo más amplio que determina de forma continua qué aspectos son relevantes, identifica las condiciones de vulnerabilidad en toda la superficie de ataque, establece prioridades en función de la probabilidad real de que se produzca un ataque y del impacto en el negocio, valida la explotabilidad y la eficacia de los controles, y pone en marcha medidas correctivas con una responsabilidad clara.
¿Cuál es la diferencia entre ASM y CTEM?
La gestión de la superficie de ataque (ASM) se centra en la detección y el inventario de los activos y las vulnerabilidades expuestos al exterior, mientras que el CTEM funciona como un programa integral que abarca las exposiciones tanto internas como externas, comprueba si estas suponen un riesgo real y coordina las medidas correctivas a través de los flujos de trabajo de TI existentes.
¿Qué herramientas sirven de apoyo a un programa CTEM?
CTEM no es una categoría de productos, sino un programa que abarca diversos tipos de herramientas vinculadas a cada una de las cinco fases del ciclo:
- La definición del alcance de se basa en plataformas de inteligencia sobre amenazas, sistemas de inventario de activos CMDB y , así como en datos de SIEM, para determinar qué niveles de activos se incluyen en el alcance de cada ciclo y cuáles son los más atacados.
- El proceso de «Discovery» requiere escáneres de vulnerabilidades, plataformas de terminales basadas en agentes, herramientas EASM y datos de proveedores de identidad.
- Las herramientas de priorización deben incorporar el EPSS y el catálogo KEV de la CISA, además del análisis de las vías de ataque, y no limitarse únicamente a las puntuaciones CVSS.
- La validación de « » (la brecha más habitual) requiere herramientas de simulación de ataques y brechas de seguridad (BAS) o capacidades de verificación continua de la corrección que confirmen que una solución concreta ha subsanado una vulnerabilidad específica, y no solo que se haya aplicado un parche.
- La movilización depende de la integración con ITSM (; ServiceNow es una opción habitual en las empresas), con suficiente contexto en cada ticket para que el equipo de operaciones de TI pueda actuar sin necesidad de un paso de triaje adicional.
Y esa última funcionalidad —confirmar que la exposición está realmente cerrada— es lo que la mayoría de las suites de herramientas aún no ofrecen de forma sistemática.
¿De qué manera mejora la gestión continua de la exposición a las amenazas la resiliencia en materia de ciberseguridad?
El objetivo del CTEM es mejorar la resiliencia reduciendo el intervalo de tiempo que transcurre entre el momento en que se produce una exposición de alto riesgo y el momento en que se confirma que ha finalizado. Los ciclos continuos sustituyen a los programas de análisis periódicos, que dejan sin detectar nuevas vulnerabilidades durante días o semanas. La priorización basada en el riesgo, que tiene en cuenta la importancia de los activos, la disponibilidad de las vulnerabilidades y el análisis de las vías de ataque, centra los esfuerzos de corrección en las vulnerabilidades que realmente pueden afectar a los activos críticos, en lugar de generar listas de tareas pendientes clasificadas según puntuaciones abstractas de gravedad.
Una ventaja menos evidente de la resiliencia cibernética de es la eficacia validada de los controles. Un sistema al que se le hayan aplicado parches, pero que se encuentre en un servidor mal configurado, podría seguir siendo vulnerable a un ataque a través de una vía diferente. La fase de validación del CTEM confirma que los controles son eficaces frente a las técnicas específicas asociadas a una exposición determinada, y no solo que se haya registrado la finalización de una medida correctiva.
Las organizaciones que llevan a cabo validaciones de forma continua se encuentran en una mejor posición a la hora de responder ante incidentes, ya que han comprobado de antemano qué medidas de seguridad son eficaces en condiciones reales, en lugar de descubrirlo en el momento más crítico.
Descubra cómo la información sobre los dispositivos finales en tiempo real respalda su programa CTEM. Solicite una demostración en para descubrir cómo Tanium ayuda a las organizaciones a reducir su exposición gracias a una visibilidad continua y a medidas de corrección integradas.
