Resumen: cobertura CTEM del lado del cliente
- CTEM se olvida del navegador: Los programas CTEM se venden como continuos, pero la mayoría cubre la infraestructura del lado del servidor y los CVE con ritmo mensual, mientras que el JavaScript que se ejecuta en los navegadores de los usuarios se trata como código estático que nunca cambia entre versiones del proveedor.
- Descubrimiento continuo de scripts: cside descubre de forma continua cada script que corre en una propiedad web, marca cuándo un script accede a elementos sensibles del DOM o envía datos a un endpoint nuevo, y genera las alertas y la evidencia que los equipos de Mobilization necesitan sin investigación manual.
- ¿En alcance o un hallazgo? Los Requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 son obligatorios desde el 31 de marzo de 2025, así que la pregunta es si tu programa CTEM trata el JavaScript del lado del cliente como algo dentro del alcance o como una línea de exposición que el evaluador acabará descubriendo por ti.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
La gestión continua de la exposición a amenazas (CTEM, Continuous Threat Exposure Management) es un marco de seguridad para gestionar el riesgo como un programa permanente en lugar de una auditoría periódica. Gartner introdujo el término para describir un ciclo que se repite y que descubre exposiciones, las clasifica según su explotabilidad real y valida que las correcciones cierran de verdad la vía de ataque.
La premisa es sencilla. Tu superficie de ataque cambia cada día. Se incorporan nuevos proveedores, llegan nuevos scripts a tus propiedades web y se publican nuevas vulnerabilidades, así que una evaluación trimestral o anual ya está desactualizada cuando se redacta el informe. Los programas de CTEM se ejecutan de forma continua, priorizan las exposiciones según lo explotables que sean en tu entorno real y hacen el seguimiento de la remediación hasta el cierre verificado.
Las cinco etapas de CTEM
Los programas de CTEM se estructuran en torno a cinco etapas que se repiten como un ciclo continuo en lugar de un proyecto lineal.
| Etapa | Tarea de CTEM | Evidencia del lado del cliente |
|---|---|---|
| Alcance | Definir los activos y las superficies de ataque del ciclo actual | Propiedades web, flujos de autenticación, páginas de pago y scripts de terceros |
| Descubrimiento | Identificar las exposiciones dentro del alcance definido | Inventario completo de scripts, inyección dinámica, endpoints y acceso al DOM |
| Priorización | Ordenar las exposiciones por explotabilidad e impacto empresarial | Acceso a datos sensibles, nuevos destinos y patrones de skimming |
| Validación | Probar la exposición y confirmar la corrección | Historial de comportamiento real, evidencia de cambios y verificación posterior a la corrección |
| Movilización | Asignar responsables y seguir cada hallazgo hasta su cierre | Alertas, registros de eventos y evidencia para los equipos de seguridad y aplicaciones |
Etapa 1: Alcance
El programa define qué activos y superficies de ataque entran en el alcance del ciclo actual. El alcance no es permanente. Se amplía a medida que el programa madura. Los primeros programas de CTEM suelen delimitar primero el alcance de los activos más críticos para el negocio: aplicaciones web en producción, flujos de autenticación e infraestructura de pago. Los ciclos posteriores incorporan los sistemas internos, las integraciones de terceros y la cadena de suministro. El alcance responde a una pregunta clara: ¿qué estamos protegiendo y frente a qué amenaza nos defendemos?
Etapa 2: Descubrimiento
El descubrimiento identifica cada exposición dentro del alcance definido, y va mucho más allá de los CVE conocidos y las vulnerabilidades instaladas. En un contexto de CTEM, el descubrimiento abarca qué componentes de terceros están presentes, qué scripts se ejecutan en una aplicación web, qué servicios son accesibles desde el exterior, qué identidades pueden acceder a recursos sensibles y dónde cruzan los datos los límites del sistema. Saca a la luz la superficie de ataque tal como existe en este momento, incluidas exposiciones que el equipo de seguridad no sabía que estaban ahí.
Etapa 3: Priorización
No todas las exposiciones se pueden corregir a la vez. La priorización las clasifica según el riesgo real, la combinación de gravedad, explotabilidad en el entorno actual e impacto en el negocio si se explotan. CTEM resta prioridad de forma deliberada a las vulnerabilidades teóricas que no son accesibles ni explotables en la práctica, y da prioridad a aquellas a las que los actores de amenazas apuntan de forma activa. Esta es la etapa que separa CTEM del simple análisis de vulnerabilidades. El resultado es una lista priorizada de qué corregir primero, no una lista plana de todos los hallazgos.
Etapa 4: Validación
La validación comprueba si las exposiciones identificadas son realmente explotables y si los controles existentes resisten. Emplea pruebas de penetración, ejercicios de red team y simulaciones de brechas y ataques para confirmar que una exposición priorizada es un riesgo real. La validación también confirma que la remediación cerró la exposición, es decir, que la vía de ataque ya no funciona, no solo que se aplicó un parche. Responde a una pregunta directa: ¿funciona de verdad nuestra defensa?
Etapa 5: Movilización
La movilización convierte los hallazgos validados en acciones de remediación en todos los equipos que son propietarios de los sistemas afectados. Los equipos de seguridad rara vez son propietarios de los activos que defienden. Los equipos de aplicaciones, los equipos de infraestructura y los proveedores externos tienen todos un papel que desempeñar. La movilización traduce los hallazgos en tareas concretas para esos equipos y hace el seguimiento de cada una hasta su finalización verificada.
Por qué el JavaScript del lado del cliente es un punto ciego de CTEM
La mayoría de los programas de CTEM analizan bien la infraestructura del lado del servidor, los CVE conocidos y las exposiciones a nivel de red. La capa del lado del cliente, el JavaScript que se ejecuta en el navegador de un usuario cuando interactúa con tu aplicación web, está sistemáticamente infrarrepresentada.
Algunas características hacen que la superficie de ataque del lado del cliente sea difícil de cubrir con las herramientas de CTEM tradicionales.
Cambia sin previo aviso. Los scripts de terceros (herramientas de analítica, widgets de chat, gestores de etiquetas, bibliotecas cargadas desde CDN) actualizan su contenido cuando el proveedor lo decide. Un script evaluado como seguro el mes pasado puede haberse modificado desde entonces, haber sido comprometido por un atacante o haber recibido un nuevo comportamiento. Ese cambio constante es invisible para las evaluaciones puntuales.
Los scripts autorizados pueden convertirse en un arma. Los ataques Magecart lo ilustran con claridad. El riesgo no se limita a los scripts no autorizados. Los scripts autorizados que cambian lo que hacen son el problema más difícil. Una página de pago que carga un script de analítica aprobado queda expuesta si ese script se ve comprometido y empieza a leer los campos de la tarjeta. El script estaba dentro del alcance. Su comportamiento no se estaba monitorizando.
Los escáneres de CVE no lo detectan. Los escáneres basados en CVE buscan vulnerabilidades de software conocidas. No detectan cambios de comportamiento en el JavaScript, la incorporación de nuevos scripts de terceros ni las vías de exfiltración de datos del lado del cliente.
Ahora los reguladores lo exigen. Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1, obligatorios desde el 31 de marzo de 2025, exigen un inventario de scripts de la página de pago, controles de autorización y detección de cambios en tiempo de ejecución. Esos requisitos existen precisamente porque la superficie de ataque del lado del cliente no se estaba gestionando.
Cómo encaja cside en los programas de CTEM
cside cubre la capa de exposición del lado del cliente a la que la mayoría de los programas de CTEM nunca llegan. Asignado a las etapas de CTEM:
- Descubrimiento: cside descubre de forma continua cada script que se ejecuta en una propiedad web, incluidos los scripts añadidos a través de gestores de etiquetas, las dependencias de CDN y el código inyectado dinámicamente, lo que te da el inventario completo que necesita la etapa de Descubrimiento.
- Priorización: la monitorización de comportamiento de cside avisa cuando los scripts acceden a elementos sensibles del DOM, envían datos a endpoints externos o coinciden con patrones vinculados a ataques de skimming, las señales que separan las exposiciones explotables del lado del cliente de las teóricas.
- Validación: cside genera pruebas en tiempo real de los cambios de comportamiento de los scripts, y confirma si una exposición está activa y a qué datos está accediendo.
- Movilización: cside genera las alertas, los registros de eventos y la documentación de pruebas que permiten a los equipos de seguridad y de aplicaciones actuar sobre los hallazgos del lado del cliente sin investigación manual.
En el caso concreto de las páginas de pago, así es también como cside cumple con PCI DSS 6.4.3 y 11.6.1 en un único despliegue: un inventario de scripts continuo con controles de autorización más detección automatizada de manipulaciones.
