El perímetro no se queda quieto: por qué un pentest anual empieza a envejecer el día en que se entrega

Cuando se entrega el informe de una prueba de penetración, la empresa recibe una fotografía de su exterior digital. En esa fotografía quedan registradas las puertas, ventanas y salidas de servicio que estaban visibles ese día concreto. El problema es que la arquitectura real de la red cambia más rápido que el ciclo de planificación de una auditoría. Una nueva versión de la aplicación sale el viernes por la tarde. El lunes por la mañana un ingeniero de DevOps levanta un contenedor para probar la integración con una nueva pasarela de pago. El martes queda un puerto abierto, o un registro DNS de prueba que nadie elimina.

El miércoles ese servicio nuevo ya es accesible desde internet. El jueves puede ser detectado por un escáner automatizado. Y la última prueba de penetración, realizada hace tres meses, afirma que ese servicio no existe. No es un fallo de seguridad en el sentido clásico; es un punto ciego creado por el tiempo que transcurre entre revisiones. La revisión puntual se considera suficiente sobre todo por razones históricas, y hoy ese modelo choca con una contradicción evidente: la infraestructura cambia más rápido de lo que se pueden planificar y ejecutar las auditorías manuales.

De dónde viene la creencia en el ciclo anual

La idea de que la seguridad se puede verificar una vez al año viene del mundo de la protección física y de la auditoría financiera. En esos ámbitos el objeto de la revisión es relativamente estable. Un banco no se muda cada trimestre, y sus procesos financieros básicos se mantienen iguales a lo largo del año. La analogía resultaba cómoda: se tomó el concepto de auditoría y se aplicó al código y a las redes.

El enfoque encajaba con la época de las aplicaciones monolíticas. Si una empresa operaba un único sistema grande desplegado en unos pocos servidores de un centro de datos, su interfaz externa, el perímetro, cambiaba realmente muy poco. Añadir funcionalidad solía significar actualizar la lógica interna, no crear un nuevo punto de entrada desde fuera. Una prueba de penetración en ese contexto funcionaba como la inspección de un edificio: se revisan las cerraduras, los muros y el tejado. Si el edificio no se vuelve a construir, el resultado de la inspección sigue siendo válido durante mucho tiempo.

Después la infraestructura pasó al modelo de microservicios y entornos en la nube. Ahora el edificio está formado por cientos de módulos pequeños que se conectan y se desconectan de forma constante. La superficie externa de una empresa, su conjunto de dominios, direcciones IP y puertos abiertos, se ha vuelto dinámica. Se expande y se contrae hora a hora, siguiendo el ciclo de vida del desarrollo. La confianza en que nada ha cambiado desde la última prueba suele ser errónea, porque los cambios ocurren en el nivel de las configuraciones y los recursos temporales, que nunca aparecen en la lista de verificación de las versiones planificadas.

Qué cambió en el comportamiento de los atacantes

El lado atacante se adaptó a este ritmo mucho más rápido que la industria de la seguridad. Las técnicas de reconocimiento que se usan para recopilar información sobre la red de una víctima están catalogadas en MITRE ATT&CK como T1590, Gather Victim Network Information. Esa etapa incluye determinar la estructura de la red, mapear los nodos y recopilar datos sobre los dispositivos. Antes se hacía a mano, de forma selectiva y con un costo alto. Hoy buena parte de ese trabajo está automatizada.

Los bots recorren internet de forma continua en busca de nuevos objetivos: dominios registrados hace poco, nuevos registros DNS, direcciones IP que acaban de empezar a responder. Para un atacante, la aparición de un servicio público nuevo es una señal. Una configuración reciente, quizá sin todos los parches aplicados todavía, quizá con credenciales por defecto o una interfaz de depuración aún activa.

Los ataques rara vez empiezan por el núcleo más protegido de un sistema. Un panel de administración olvidado, una API de pruebas o una copia de seguridad de base de datos alojada en un bucket de almacenamiento con acceso público son puntos de partida más sencillos. Estos activos aparecen por accidente, viven poco tiempo y desaparecen a los pocos días, lo cual sigue siendo suficiente para que acaben en el inventario de un atacante.

Conviene separar lo que se sabe de lo que es una estimación. Se sabe que la automatización ha reducido el costo del escaneo masivo lo suficiente como para ejecutarlo contra todo el espacio de direcciones. Se estima que los activos agregados recientemente concentran una proporción desmedida de las compromisiones exitosas, sencillamente porque los activos antiguos ya han pasado por varios ciclos de corrección. La imagen exacta de una empresa concreta solo se obtiene analizando un año de registros de acceso frente a la fecha de creación de cada recurso.

La brecha entre la fotografía y el flujo

Imagine una sesión de fotos de la oficina antes de una reunión importante con inversores. El fotógrafo logra una toma excelente: todo está limpio, los documentos en orden, el personal sonríe. Mientras la fotografía se procesaba y se imprimía, alguien dejó la caja fuerte abierta y nadie sacó la basura. La toma sigue siendo excelente. Simplemente ya no refleja el estado actual de las cosas.

Una prueba de penetración funciona igual. Un equipo de expertos dedica semanas a estudiar la arquitectura, buscar fallos de lógica y verificar la autorización. El resultado es una lista de problemas encontrados en el momento de la revisión. En cuanto se firma el informe, la información empieza a envejecer. Cada despliegue, cada nuevo registro DNS, cada nuevo dispositivo IoT en la red de la oficina es un cambio del perímetro que la última auditoría no cubrió.

El riesgo no está en que el código antiguo se vuelva vulnerable. El riesgo está en que a su alrededor crezca un entorno nuevo que nunca ha sido revisado. Un frontend nuevo puede tener una configuración de CORS incorrecta. Un backend nuevo puede usar una versión desactualizada de una biblioteca que no figura en la lista de dependencias anterior. Una dirección IP nueva puede pertenecer a un servicio de monitoreo que funciona con credenciales por defecto débiles.

En el modelo tradicional, cambios como estos se descubren por casualidad, cuando alguien del equipo de desarrollo recuerda que dejó algo pendiente, o en la siguiente prueba de penetración anual. El segundo caso significa que una vulnerabilidad potencial ha estado viva en producción durante meses. En términos de negocio, eso es una ventana de exposición durante la cual cualquier interesado pudo encontrar su puerta nueva.

Por qué el seguimiento manual no escala

La pregunta lógica: ¿no basta con mantener una hoja de cálculo con todos los servicios externos y actualizarla en cada versión? Se puede, y muchas empresas lo hacen. Pero esa práctica se rompe pronto por dos motivos.

• Responsabilidad fragmentada. De los dominios se ocupa marketing; de las direcciones IP, los ingenieros de red; de las API, el equipo de desarrollo; del almacenamiento público, DevOps. Nadie por sí solo tiene la imagen completa del contorno externo. La hoja de cálculo siempre queda incompleta, porque alguien, en algún lugar, creó un recurso sin avisar a los demás equipos.
• El factor humano. Mantener la hoja al día exige disciplina y atención. Con los plazos encima, registrar un activo nuevo en el inventario de seguridad se pospone. El activo pasa a producción y la burocracia lo sigue después. Cuando la hoja se actualiza, el activo puede llevar un mes accesible públicamente.

Apoyarse en un inventario de activos mantenido a mano equivale a seguir a pie algo que se mueve a la velocidad de los despliegues. Las herramientas tienen que estar a la altura del ritmo de cambio del entorno.

Del evento al estado

Para cerrar esta brecha hace falta cambiar el marco: dejar de tratar la seguridad como un evento, la prueba de penetración, y empezar a tratarla como un estado, el monitoreo. Eso no significa que las pruebas de penetración dejen de ser necesarias. Siguen siendo esenciales para el análisis profundo de la lógica de negocio, para cadenas de explotación complejas y para redes internas donde un escáner no puede llegar.

Lo que debe volverse continuo es la capa básica de control: un mecanismo que observe la frontera externa las veinticuatro horas y compare la imagen actual con una de referencia. La práctica regulatoria apunta en la misma dirección. La directiva estadounidense CISA BOD 23-01 para las redes federales se construye sobre la mejora de la visibilidad de los activos y la detección de vulnerabilidades. Su premisa es que las listas estáticas de activos quedan desactualizadas demasiado rápido y que las organizaciones necesitan la capacidad de ver los cambios en su entorno digital en un régimen cercano al tiempo real. El requisito de fondo es simple: lo que no sabe que está en su perímetro ahora mismo, no lo puede proteger.

Cómo se ve el control continuo en la práctica

Imagine un sistema que cada pocas horas, o cada pocos minutos, toma una fotografía del contorno externo. Pregunta a los servidores DNS qué nombres están asociados a la zona de la empresa. Escanea rangos de IP para ver qué puertos responden. Revisa los certificados TLS para ver qué sitios operan bajo la marca de la empresa.

Si el sistema detecta un nombre nuevo, staging-api.company.com, que antes no existía, no intenta vulnerarlo de inmediato. Lo marca como nuevo. Justo en ese momento entran en juego dos procesos.

• El monitoreo de cambios del perímetro responde a la pregunta "¿Qué ha aparecido?" Su tarea es la detección: nuevos dominios, nuevas IP, nuevos tipos de dispositivo, un router donde antes había un servidor web.
• El escaneo continuo responde a la pregunta "¿Esto es normal?" Cuando el monitoreo informa de un activo nuevo, el escáner ejecuta de forma automática una revisión básica sobre él. No con la profundidad de una prueba de penetración, sino una pasada rápida: puertos abiertos, CVE conocidos, configuración HTTP, archivos sensibles expuestos.

El resultado no es un informe estático, sino una lista viva de hipótesis. Cada cambio en el perímetro genera una tarea en la cola de verificación, y los ingenieros de seguridad reciben una alerta con una forma reconocible.

Esto cambia el carácter del trabajo del equipo. En lugar de esperar medio año para revisar toda la red de una vez, los especialistas reaccionan a los cambios. El triaje, es decir, la clasificación de los hallazgos y la evaluación de su gravedad, se convierte en un proceso continuo, y las nuevas exposiciones se evalúan en horas en lugar de meses.

Qué significa esto para el negocio

Traducido al lenguaje del riesgo: si un servicio nuevo aparece un martes y la siguiente prueba de penetración está prevista dentro de ocho meses, ese servicio permanece en el perímetro sin revisar durante esos ocho meses. Nada de eso vuelve inevitable un incidente. Significa que nadie del lado defensor está en condiciones de decir en qué estado se encuentra ese servicio, ni si alguien más ya lo ha mirado.

Con monitoreo continuo, el plazo de reacción se reduce a días, a veces a horas. Aparece un activo nuevo, el escaneo señala un problema, la ausencia de HTTPS o una vulnerabilidad conocida en la versión del software, y el equipo puede cerrarlo en el mismo sprint. No hay que esperar a la siguiente auditoría para enterarse de que una puerta quedó abierta.

Hay un matiz que no conviene ignorar. La automatización es más barata que el trabajo manual, pero no es gratuita. Implantar herramientas de monitoreo e integrarlas en el pipeline de CI/CD requiere esfuerzo: hay que ajustar reglas, filtrar falsos positivos y enseñar al equipo a trabajar con un nuevo flujo de alertas. Es una inversión en capacidad operativa y debe planificarse como tal.

Dónde termina la automatización

Es importante entender los límites de este enfoque. El monitoreo del perímetro y el escaneo continuo resuelven el problema de la visibilidad y de los errores de configuración simples. Encuentran bien puertos abiertos, software desactualizado y errores en la configuración de servidores web. Pero no sustituyen a una prueba de penetración.

Las herramientas automatizadas entienden mal la lógica de negocio. No van a ver que el usuario A puede abrir el perfil del usuario B cuando coinciden las primeras letras de sus apellidos. No van a deducir que la función de subir archivos acepta ejecutables, porque ese comportamiento rompe la lógica de la aplicación y no un estándar de seguridad. Para encontrar vulnerabilidades complejas y de varios pasos como esas hacen falta personas, pensamiento creativo y conocimiento de cómo debe funcionar la aplicación.

Por eso la arquitectura de seguridad que funciona es híbrida. El monitoreo continuo mantiene actualizado el conocimiento del estado del perímetro y resuelve rápido los problemas de bajo nivel. Las pruebas de penetración periódicas profundizan en la lógica y buscan vectores de ataque complejos. Y los resultados de una prueba se convierten en insumo para afinar las reglas del monitoreo: si el equipo de pentest encontró una forma de eludir una comprobación de permisos a través de un campo concreto de la API, esa comprobación puede añadirse a las revisiones regulares o, como mínimo, ese componente puede marcarse como merecedor de mayor atención ante cualquier cambio.

Una pregunta para su responsable de TI

En la próxima reunión con el responsable de seguridad de la información o con el CTO, vale la pena hacer una pregunta directa.

¿Cómo nos enteramos de que ha aparecido un servicio público o un dominio nuevo, si no estaba incluido en el plan del trimestre actual?

Una pregunta para el responsable de seguridad

Una respuesta del tipo "hacemos una prueba de penetración una vez al año" significa que la organización acepta el riesgo de desconocer parte de su propio patrimonio digital. Una respuesta del tipo "llevamos un inventario de activos" conviene completarla con una segunda pregunta: ¿qué tan actualizado está ese inventario y se verifica de forma automática, o depende de la buena memoria del equipo de desarrollo?

Un siguiente paso concreto es auditar cómo registran los equipos las nuevas dependencias externas y medir cuánto tiempo pasa desde el despliegue de un servicio nuevo hasta que entra en el campo de visión de los sistemas de seguridad. Si ese intervalo se mide en semanas, ahí está la brecha de reacción.

Veredicto

La creencia de que una prueba de penetración anual basta por sí sola no se derrumba porque las pruebas de penetración hayan empeorado. Se han vuelto insuficientes como único instrumento de control. La infraestructura se volvió dinámica y el reconocimiento se automatizó.

La corrección es sencilla: la revisión puntual pasa a formar parte de un ciclo continuo. La propuesta no es renunciar a las pruebas de penetración, sino sumarles una capa de observación permanente del perímetro externo. El monitoreo de cambios permite advertir un elemento nuevo en la arquitectura poco después de que aparezca. El escaneo continuo convierte esa observación en acción, devolviendo el activo nuevo a la cola de verificación.

El resultado es que los hallazgos de una prueba de penetración dejan de ser un documento de archivo. Se convierten en una lista viva de hipótesis que se actualiza junto con la infraestructura. La organización dedica menos tiempo a sorprenderse de su propia exposición y más a gestionarla. No es magia; es disciplina apoyada en la tecnología adecuada. Y conviene empezar por asumir que su muro exterior se mueve, y que la defensa tiene que moverse con él.