Reincidencia es el segundo incidente en la misma empresa después de contener el primero. Casi nunca repite el vector original. Lo que se repite es la condición que abrió el primero. Un activo publicado en internet que no aparecía en ninguna lista y que, por eso, quedó fuera de la corrección y fuera de la monitorización.
Buena parte de las empresas que llegan a CSURFACE llegan con el incidente ya cerrado. El backup volvió, el departamento jurídico hizo lo suyo, el informe de respuesta se archivó. Queda una pregunta que nadie del equipo puede responder con una lista en la mano. ¿Por dónde más se puede entrar?
De eso trata este texto. De lo anterior, de lo que aporta la visión externa mientras el incidente sigue abierto, trata el artículo que lo acompaña.
La cola ordenada por gravedad teórica no reduce exposición
Empiezo por aquí porque es donde el equipo de seguridad pasa la mayor parte de su semana.
La cola de casi todas las empresas está ordenada por CVSS. Es la ordenación que viene con el dato, y responde a una pregunta que casi nadie está haciendo, que es cuánto daño causaría el fallo si alguien lo explotara.
La pregunta operativa es otra. Entre miles de hallazgos abiertos, cuáles se están explotando contra alguien ahora mismo, y cuáles de esos están en un activo mío alcanzable desde internet.
La base pública de ThreatSensor muestra el tamaño de la diferencia. Apurado el 21 de septiembre de 2026, el núcleo que reúne a la vez el catálogo KEV, exploit público y EPSS alto es el 26,9% de la base monitoreada. Y la mediana entre la publicación de un CVE y el primer exploit público es de menos de un día: en el 55,8% de los casos el código ya existía en la fecha de publicación.
Póngalo al lado de los 43 días de mediana de corrección que mide el DBIR 2026 de Verizon. El exploit no aparece a mitad del plazo de corrección, ya está ahí cuando el plazo empieza a contar. El mismo informe trae dos datos que encajan con ese. El fallo expuesto superó a la credencial robada como vía de entrada más habitual, y del catálogo de CISA con lo que está comprobadamente bajo explotación figuraba corregido un 26%, que es la medida de cuánto tiempo un activo sigue disponible después de que su fallo ya es público.
La puerta principal pasó a ser el fallo expuesto y la cola que debería cerrarla avanza más despacio que el año anterior. Por esa aritmética, ordenar por explotación observada mueve el resultado más que cualquier persona añadida al equipo de parcheo. La cola entrega primero lo que no importa, y ahí es donde se pierde el tiempo.
La segunda vez entra por otro sitio
Quien responde a incidentes de profesión reconoce el patrón. El equipo cierra el vector usado, rota credenciales, aplica el parche, escribe el post mortem. Meses después el adversario vuelve, y vuelve por una dirección que no aparecía en ningún diagrama de la respuesta anterior.
El motivo incomoda. La respuesta trabaja sobre el alcance del incidente, y el alcance del incidente es aquello que se encontró. Ninguna etapa pregunta cuántos activos publicados existen fuera de ese recorte.
Tres días parados y la cuenta que llegó después
Una operación de comercio electrónico estuvo tres días sin vender. R$ 900.000 en ventas perdidas en ese intervalo. El gasto operativo del periodo, que se mueve en las decenas de millones, cerró un 11% por encima de lo proyectado, entre respuesta de emergencia y horas extra.
Los números vienen de la propia empresa y no están aquí para demostrar nada sobre ninguna plataforma. Importa más lo que vino después, cuando la operación se recompuso y volvió con una pregunta que nadie había hecho antes del incidente, sobre qué más estaba publicado a su nombre.
Ese es el momento en que la conversación cambia de tema dentro del cliente. Sale del incidente y entra en el inventario.
El inventario oficial no es la superficie
En dos casos documentados, una entidad financiera de tamaño medio operaba sobre 160 activos externos en su inventario oficial y el descubrimiento devolvió 271. Una startup de SaaS B2B monitorizaba 85, y el descubrimiento devolvió 570.
El coordinador de ciberseguridad de una de las mayores empresas de Brasil resumió el efecto en una frase que está publicada en el sitio: descubrir que monitorizábamos solo el 15% de nuestra superficie de ataque real.
Ninguno de esos números habla de un fallo nuevo. Hablan de un denominador. Cada métrica de cobertura que reporta un SOC, el porcentaje de activos monitorizados y el porcentaje dentro de la ventana de parcheo, sale de una lista que alguien escribió a mano una vez y nunca volvió a auditar. Un subdominio de campaña, un entorno de preproducción que subió junto a una integración, un dominio heredado de una adquisición. Medir ese denominador en lugar de darlo por bueno exige mirar desde fuera, y de forma continua, porque una lista interna solo recoge lo que alguien se acordó de anotar.
Una salvedad que casi ningún fabricante hace. Encontrar 400 activos nuevos, por sí solo, duplica la cola del equipo y no reduce riesgo alguno. Descubrimiento sin ordenación es deuda.
El ciclo que cierra esto ya tiene nombre
Lo descrito hasta aquí es un ciclo de cinco fases: alcance, descubrimiento, priorización, validación y movilización. Se llama CTEM, continuous threat exposure management, y existe como marco público desde 2022. Un término más reciente, preemptive exposure management, fija lo que CTEM dejó abierto, que es el momento en el que ocurre el trabajo. Antes de que exista una alerta.
Dos observaciones honestas sobre el marco. Las consultoras de analistas no certifican productos, así que ningún fabricante tiene un sello CTEM. Y el ciclo no define cadencia, lo que permite ejecutar las cinco fases una vez por trimestre y llamarlo CTEM sin mentir.
Para una empresa que ya fue comprometida, la cadencia es justo la variable que importa. La ventana entre que un activo queda expuesto y alguien del equipo se entera de que existe es el intervalo en el que ocurre la reincidencia.
La infraestructura de IA que nadie registró
En los dos últimos años apareció una clase nueva de activo olvidado, y merece sección propia porque casi ningún inventario la sigue.
Los equipos de producto y de datos levantaron paneles de orquestación, endpoints de inferencia y entornos de prueba con modelos. Buena parte se publicó desde ingeniería sin pasar por seguridad, se quedó en pie después del experimento y nunca entró en ninguna CMDB. La entrada de shadow AI describe el resultado: buena parte del shadow AI se convierte en activo expuesto en internet antes de convertirse en incidente de datos. La entrada de seguridad de IA agéntica explica el mecanismo. Todo agente en producción añade un endpoint, una credencial y una integración, y un activo nuevo entra en la superficie externa como cualquier otro.
El límite tiene que estar escrito, porque es lo que decide si la frase anterior es publicidad o verdad. La visión externa no protege sus agentes de IA. Lo que alcanza es la infraestructura de IA que la empresa publicó y olvidó, el panel, el endpoint y la clave, y la comprobación de que aquello responde. El inventario de identidad de agente, el análisis de alcance de token OAuth y las pruebas de inyección de prompt requieren acceso interno y pertenecen a otra categoría de producto.
Lo que ya funciona sin construir nada nuevo es la cola. Cuando sale un CVE crítico en un componente de stack de IA, la priorización reordena por lo que está bajo explotación observada, sin preguntar qué tipo de software es el afectado.
Quien opera un SOC para terceros ve repetirse el mismo guion
Un proveedor que atiende a decenas de clientes ve el ciclo completo varias veces al año, siempre con la misma forma. El cliente contrata monitorización sobre la lista que entregó, el incidente entra por fuera de esa lista, y la revisión posterior se convierte en una discusión sobre alcance de contrato.
Por eso la superficie externa suele ser el primer módulo que un SOC gestionado integra en su propio servicio. Ataca el problema anterior a la monitorización, que es saber qué hay que monitorizar. Operar así exige tres cosas que rara vez vienen juntas: vista de organización con separación entre clientes, control de acceso por alcance, y una traza de auditoría que aguante que un cliente pregunte quién miró qué. Sin eso, el proveedor acaba lanzando un escaneo por cliente desde una sola consola, y el modelo no cierra.
El retorno comercial para el proveedor aparece en el informe del trimestre siguiente, cuando puede enseñar al cliente una línea que ningún competidor enseña: cuántos activos entraron y salieron de su superficie desde la última reunión, y cuántos de ellos nadie había registrado.
Dónde encaja CSURFACE en todo esto
Nada de lo anterior depende de comprar nada. Medir el denominador, ordenar por explotación observada y cerrar el ciclo es trabajo, y se puede hacer con herramienta propia, con scripts o con otro proveedor.
CSURFACE resuelve tres de esas partes desde fuera, sin agente instalado: el descubrimiento continuo de lo publicado a nombre del grupo, con histórico de primera y última observación; la priorización por explotación observada en lugar de nota teórica, alimentada por el threat intelligence; y el ciclo completo de CTEM encima de eso.
Para quien opera un SOC para terceros, la conversación es la de socios, porque ahí lo que se compra es un modelo comercial y no una funcionalidad.
Preguntas frecuentes
¿La reincidencia entra siempre por el mismo camino?
Rara vez. El vector del primer incidente suele quedar bien tratado después, porque es el que documentó la respuesta. Lo que sobrevive es la condición de fondo, que son los activos publicados fuera del inventario. El segundo incidente entra por uno de ellos.
¿Un SOC bien montado no resuelve esto por sí solo?
Un SOC resuelve la detección sobre lo que monitoriza. De dónde sale la lista de activos monitorizados nunca estuvo en su alcance, y esa pregunta es anterior a la detección. Los dos trabajos se complementan, y el de superficie externa va primero en el orden.
¿Cuánto tarda en estar mapeada la superficie externa?
Los primeros activos aparecen en pocas horas a partir de un dominio semilla, y la cobertura se consolida en los días siguientes. Lo que tarda más es la atribución de propiedad, es decir, demostrar que un activo encontrado pertenece de verdad a la empresa y no a un homónimo.
¿CSURFACE protege agentes de IA?
No. Encuentra infraestructura de IA publicada en internet y comprueba si está expuesta. La protección de agentes en tiempo de ejecución, el inventario de identidad no humana y las pruebas de inyección de prompt exigen acceso interno al entorno y no los hace una plataforma externa.
¿Y mientras el incidente sigue abierto?
Esa es la otra mitad del asunto y está en lo que aporta la visión externa al equipo de respuesta, que describe las listas que se pueden levantar desde fuera en pocas horas con el incidente en curso.