Cómo crear un programa de remediación de pentesting de 90 días con evidencias

El pentesting (pruebas de penetración) simula un ciberataque para detectar vulnerabilidades en los sistemas y descubrir posibles vectores de ataque antes de que se produzca un incidente real. Pero, hoy en día, encontrar vulnerabilidades es lo fácil. Lo difícil es seguir el ritmo al que los atacantes explotan todo lo que descubren.

Investigaciones recientes del sector revelan que la ventana mediana de «armamentización» de la mayoría de las vulnerabilidades recién descubiertas es de 48 horas. Y, para colmo, cada vez más atacantes recurren a la IA para automatizar el reconocimiento y el encadenamiento de exploits a velocidad de máquina.

Esto significa que ya no basta con un flujo de remediación construido alrededor de un único informe puntual. Los equipos de seguridad necesitan un proceso que analice y gestione las exposiciones de forma continua.

La buena noticia es que Gartner ha desarrollado un nuevo marco de seguridad que transforma el análisis reactivo de vulnerabilidades en una estrategia proactiva basada en el riesgo: la gestión continua de la exposición a amenazas (CTEM).

En esta guía verás qué es CTEM, cómo funciona y cómo integrar una estrategia de remediación de 90 días en su fase de movilización.

¿Qué es la gestión continua de la exposición a amenazas (CTEM)? Visión general

Gartner define la gestión continua de la exposición a amenazas (CTEM) como una «disciplina programática para evaluar de forma continua la exposición de una organización a las ciberamenazas, con el fin de impulsar una remediación y una reducción del riesgo priorizadas, validadas y alineadas con el negocio».

En pocas palabras, es un marco para gestionar y mitigar la exposición a amenazas de forma proactiva. En lugar de revisar y probar las vulnerabilidades cada trimestre, CTEM trata la exposición como un objetivo en movimiento que hay que seguir, priorizar y mitigar continuamente. Combina en un solo modelo operativo la gestión de vulnerabilidades, la gestión de la superficie de ataque y la validación de la postura de seguridad.

El ciclo CTEM consta de cinco fases:

1. Delimitación del alcance: determina qué sistemas, entornos y procesos tendrían el mayor impacto operativo si se vieran comprometidos.
2. Descubrimiento: identifica de forma continua los activos y las posibles exposiciones en todos los entornos relevantes. Normalmente incluye el cloud, la infraestructura on-premises, las plataformas SaaS, los sistemas de identidad y acceso, los endpoints y las aplicaciones.
3. Priorización: clasifica los riesgos según su explotabilidad, su impacto en el negocio y la probabilidad de la ruta de ataque. Aquí entran en juego las señales de la gestión de vulnerabilidades, como CVSS, EPSS y el estado en KEV.
4. Validación: simula rutas de ataque reales para determinar si los controles existentes pueden detener de verdad a un atacante. El pentesting es una actividad clave de validación dentro de un ciclo CTEM: permite a los equipos de seguridad confirmar qué exposiciones son realmente explotables, identificar rutas de ataque hacia activos críticos y verificar que los controles defensivos funcionan como deberían.
5. Movilización: los esfuerzos de remediación se coordinan, se siguen y se llevan hasta el cierre entre los equipos de seguridad y de TI.

Una de las mayores limitaciones del pentesting tradicional es que solo refleja una instantánea en el tiempo. Resulta útil para detectar vulnerabilidades explotables, pero si el entorno sigue evolucionando después de la evaluación (como ocurre casi siempre), se te escaparán las nuevas exposiciones.

CTEM resuelve este problema al tratar las pruebas de penetración como una validación continua y no como un ejercicio de seguridad aislado. Así, los hallazgos de los pentests siguen conectados con el resto del ciclo.

Por ejemplo, el programa de remediación de 90 días que se describe a continuación puede incluirse en la fase de movilización. En lugar de limitarte a entregar un informe y hacer seguimiento de los tickets de remediación, puedes usar los hallazgos validados para reducir el riesgo de forma real en toda la organización.

El objetivo aquí no es solo cerrar los hallazgos del último pentest, sino reducir las exposiciones que suponen el mayor riesgo para el negocio. A medida que avanza el programa de remediación, los equipos de seguridad y de TI pueden volver a las fases de descubrimiento, priorización y validación para buscar riesgos emergentes y continuar el ciclo CTEM.

Pon en marcha en 90 días la remediación de pentesting alineada con CTEM

En un programa basado en CTEM, las exposiciones se priorizan según su explotabilidad, su impacto en el negocio y su papel en posibles rutas de ataque. Las exposiciones de alto riesgo reciben atención inmediata, mientras que los problemas de riesgo medio o bajo se derivan a un plan de remediación estructurado de 90 días.

El plazo de 90 días evita que los hallazgos de menor prioridad se acumulen, ya que genera un sentido de urgencia en torno a todo el trabajo de remediación. En esencia, da a los equipos una fecha límite realista para revisar, remediar y mitigar los hallazgos menores mientras el ciclo CTEM continúa. Así te aseguras de que todos los hallazgos de un pentest se resuelvan y no queden aparcados.

📌Requisitos previos:

• Informe final del pentest con valoraciones de gravedad (idealmente vectores CVSS v4.0 y no solo una puntuación única) y evidencias
• Contexto de explotación de cada hallazgo: estado en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA y, si es posible, la probabilidad del Exploit Prediction Scoring System (EPSS)
• Clasificación de activos y datos para traducir el riesgo técnico en impacto de negocio
• Responsables designados para la remediación, la validación y la aprobación de cambios
• Un espacio de trabajo de gestión de tickets y una carpeta de evidencias compartida para los resultados

Paso 1: estandariza los informes de pentest y asigna responsables

Los resultados de las pruebas de penetración suelen llegar en varios formatos, con valoraciones de gravedad dispares, convenciones de nombres inconsistentes y, a veces, hallazgos solapados. Estandarizarlos asignando ID, vinculándolos a activos y clasificándolos por CWE o por riesgo genera una documentación limpia sobre la que podrás basar el trabajo de remediación futuro.

Plan de acción recomendado:

1. Importa todos los hallazgos: usa un software ITSM para almacenar y seguir de forma centralizada los resultados de los pentests y las exposiciones detectadas por el descubrimiento y el análisis continuos entre pruebas.
2. Asigna un ID único: asignar un identificador único a cada vulnerabilidad detectada simplifica el seguimiento desde la detección hasta la validación.
3. Etiqueta cada elemento con contexto de riesgo por capas, no solo con la gravedad: anota el vector CVSS v4.0, la probabilidad EPSS y el estado en el catálogo KEV de CISA de los activos afectados. Un problema con CVSS 9.8 sin evidencias de explotación real y sin exposición a internet es muy distinto de uno con CVSS 7.5 que se está explotando activamente en un sistema expuesto a internet.
4. Asigna dos roles por hallazgo: un responsable que implemente y coordine la corrección y un verificador que confirme y documente el proceso de resolución.
5. Registra las ventanas de cambio y las dependencias: así minimizas los conflictos de inactividad y te aseguras de que las correcciones encajen con los calendarios de mantenimiento.

Estandarizar los hallazgos asignando ID, vinculándolos a activos y clasificándolos por CWE o por riesgo genera una documentación limpia sobre la que podrás basar el trabajo de remediación futuro.

Paso 2: crea un flujo de remediación de pentesting de 90 días en tres bloques

Un pentest puede combinar vulnerabilidades urgentes con problemas de bajo riesgo, algo que desborda los flujos de remediación y provoca plazos incumplidos o trabajo a medias. Un enfoque por oleadas a 90 días ayuda a organizar los hallazgos, pero debe secuenciarse según la explotabilidad real y no solo según la complejidad técnica.

Plan de acción recomendado:

1. Días 0 a 7: atiende de inmediato todo lo que figure en KEV o se esté explotando activamente, sin esperar a la primera oleada. Si un hallazgo está en el catálogo KEV de CISA o tiene una puntuación EPSS alta, trátalo como un cambio de emergencia, independientemente del bloque en el que habría encajado.
2. Días 1 a 30: aborda las vulnerabilidades fáciles de explotar que puedan corregirse rápido, como parches ausentes, configuraciones de políticas incorrectas, credenciales débiles o portales de administración expuestos.
3. Días 31 a 60: remedia las vulnerabilidades que requieren ajustes complejos a nivel de código y coordinación entre desarrolladores, ingenieros de red y testers. Integra las pruebas en las ventanas de mantenimiento para controlar su impacto.
4. Días 61 a 90: cierra los elementos de bajo riesgo, refuerza las configuraciones, rota las credenciales y cierra la documentación.
5. Fija el plan en el calendario de tu equipo: establece fechas de inicio y fin para cada oleada y alinéalas con los ciclos de releases y de gestión de cambios de tu organización. Trata esas fechas como compromisos acordados entre equipos y asegúrate de que todas las partes interesadas las tengan a la vista.

Paso 3: crea un checklist de cambios para cada hallazgo del pentest

Contar con checklists estandarizados guía tu estrategia de remediación de vulnerabilidades y los cambios que realizas en entornos de cliente en producción. Estos son algunos pasos a tener en cuenta:

1. Define el cambio de control propuesto. Describe los cambios necesarios para resolver las vulnerabilidades detectadas: parches, actualizaciones de configuración, correcciones de código o ajustes de políticas. Anota los servicios, usuarios o sistemas afectados.
2. Elabora un plan de pruebas. Reproduce los problemas tal y como se detectaron en el pentest y define los criterios de éxito una vez aplicada la corrección.
3. Prepara un checklist de reversión. Define los pasos que deben seguir los técnicos cuando una corrección rompe un sistema sin quererlo o degrada el rendimiento del endpoint.
4. Adjunta evidencias. Incluye la documentación previa y posterior a la corrección de los resultados del pentest, asociada directamente a su ID único, para respaldar los siguientes pasos de validación. Registra el responsable de la tarea, la fecha y el entorno de pruebas utilizado para mantener la coherencia de la verificación.

Seguir estos pasos reduce las correcciones parciales, las dependencias olvidadas y el riesgo de introducir nuevas vulnerabilidades en los entornos de cliente.

Paso 4: prioriza los riesgos evidentes que revelan las fases del pentest

Una priorización de vulnerabilidades adecuada te permite centrarte en las de mayor riesgo y cerrar de inmediato los vectores de ataque críticos. Fíjate en estos pasos, por ejemplo:

Plan de acción recomendado:

1. Define qué son los «riesgos evidentes»: detecta y prioriza las vulnerabilidades con exploits públicos, presencia en el catálogo KEV, puntuaciones EPSS altas o métodos de ataque sencillos, como:
   • Controles de autenticación débiles o inexistentes
   • Referencias directas insegura a objetos (IDOR)
   • Fallos de inyección (por ejemplo, SQL, comandos o LDAP)
   • Interfaces administrativas expuestas
   • Control de acceso débil
   • Prompt injection y otros fallos específicos de IA/LLM
2. Aplica la corrección mínima viable: usa correcciones mínimas y específicas que cierren las vulnerabilidades sin provocar cambios o impactos importantes en el sistema. Evita los rediseños a gran escala: el objetivo es contener la amenaza rápido, no rehacer el stack.
3. Documenta y programa el seguimiento: una vez cerradas las brechas, identifica las mejoras o los rediseños necesarios para la resiliencia a largo plazo. Prográmalos como tareas planificadas en futuras oleadas de remediación.

Este enfoque reduce el tiempo de exposición de tu cliente, disminuye la probabilidad de sufrir una brecha y demuestra decisión a la hora de atajar las amenazas en cuanto aparecen.

Paso 5: valida cada corrección aplicada y recoge evidencias

Volver a probar cada corrección con el mismo método empleado en el pentest garantiza que las vulnerabilidades quedan cerradas y no reaparecerán. Este es un flujo de validación que puedes tomar como base:

1. Recrea las condiciones del pentest (por ejemplo, herramientas, payloads o peticiones).
2. Ejecuta la misma simulación de ataque o exploit para comprobar la eficacia de la corrección. Observa el comportamiento del sistema para determinar si quedan indicadores de compromiso o vulnerabilidades; su ausencia indica que la vulnerabilidad está cerrada.
3. Guarda las evidencias previas y posteriores a la prueba, como la salida de consola, capturas de pantalla o trazas de red, que demuestren que la remediación ha funcionado. Etiqueta esos artefactos y asócialos al ID único del hallazgo en tu herramienta de seguimiento o repositorio de evidencias.
4. Documenta quién verificó la corrección, la fecha de validación y las herramientas utilizadas. Recoge notas u observaciones de la prueba que ayuden a explicar la corrección en detalle.

Además, las evidencias se convierten en tu registro justificable de que los riesgos están realmente cerrados y no se han desplazado a otro punto del sistema.

Paso 6: registra las excepciones en los flujos de remediación de pentesting

Algunas vulnerabilidades no se pueden cerrar en 90 días. Documentar esos casos como excepciones garantiza que los elementos aplazados no se pierdan de vista. Estos pasos de gestión de excepciones ofrecen una idea clara del proceso:

1. Asigna un responsable y registra el motivo de la excepción, la corrección temporal y la fecha de caducidad.
2. Celebra una reunión breve de revisión o repasa un checklist, preferiblemente cada semana, para confirmar lo siguiente:

• • Comprueba si las correcciones temporales siguen siendo eficaces.
  • Las condiciones no han cambiado de forma que la remediación ya sea posible.
  • Las fechas de caducidad se actualizan o se cierran como corresponde.

3. Si una vulnerabilidad no puede remediarse de forma permanente, escálala para una revisión de diseño y planifica cambios en la arquitectura del sistema o aborda la aceptación del riesgo por parte del negocio.

Mantener las vulnerabilidades sin remediar controladas, con responsable asignado y revisadas hasta que exista una corrección definitiva reduce los puntos ciegos en los entornos de cliente.

Paso 7: aborda las vulnerabilidades de aplicaciones web de forma sistemática

Las vulnerabilidades de aplicaciones web suelen seguir patrones repetibles: cuando detectas un problema, es probable que encuentres el mismo en varias rutas, módulos o aplicaciones. Atajar este tipo de vulnerabilidades de forma sistemática mediante cambios bien diseñados elimina los problemas relacionados de una sola vez.

Plan de acción recomendado:

1. Agrupa los hallazgos similares: clasifica los hallazgos relacionados con la web por tipo e identifica dónde se repiten; por ejemplo, en API, plantillas o middleware compartidos. Incluye en esa agrupación cualquier endpoint con IA/LLM integrados, ya que cada vez son más un componente compartido entre varias aplicaciones.
2. Define el patrón común: entiende el por qué de la vulnerabilidad detectada. Por ejemplo, si varios endpoints son vulnerables a inyección SQL, el problema real puede estar en entradas de consulta sin validar o en la falta de saneamiento en la capa de datos.
3. Centraliza la distribución de la corrección: aplica controles en rutas de código compartidas o mediante componentes centralizados para que la corrección se despliegue automáticamente en todo el entorno.
4. Verifica la eficacia y documenta las correcciones: documenta y vuelve a probar las correcciones en todos los endpoints o aplicaciones afectados para confirmar si han mitigado toda la clase de vulnerabilidades.

Paso 8: refuerza tu hoja de ruta de pentesting cerrando brechas

Además de los exploits externos, los atacantes pueden sortear tus defensas aprovechando amenazas internas, como cuentas con privilegios excesivos, credenciales expuestas o configuraciones débiles. Mira el siguiente plan de acción para aprovechar los controles de acceso:

1. Aplica el acceso con privilegios mínimos. Por ejemplo, revisa los permisos de todos los usuarios, cuentas de servicio y sistemas afectados identificados en el pentest. Comprueba que todas las cuentas y API tengan únicamente los permisos exactos que necesitan para su función.
2. Rota y protege las credenciales. Rota de inmediato cualquier contraseña, clave de API, clave SSH o token que pueda haber quedado expuesto. Traslada las credenciales sensibles a una bóveda segura y exige autenticación robusta en los sistemas, como MFA para las cuentas privilegiadas.
3. Refuerza las líneas base. Revisa las configuraciones de sistemas y aplicaciones frente a líneas base de seguridad y aplica plantillas de refuerzo coherentes en endpoints similares para eliminar la desviación de configuración.
4. Activa el registro y la monitorización. Habilita los logs de acciones de identidad, comandos privilegiados e intentos de autenticación, e integra esos registros para detectar anomalías.

Una vez que un atacante consigue acceso, ciertos tipos de vulnerabilidades le permiten realizar movimientos laterales y obtener privilegios para desactivar tus defensas.

Paso 9: amplía el alcance de la remediación a los sistemas de IA y LLM

Con el Reglamento Europeo de IA a punto de entrar en vigor el 2 de agosto de 2026, cualquier aplicación o agente con IA integrada debería tener su propia línea en el programa de remediación. Esos hallazgos no deben mezclarse nunca con el backlog general de aplicaciones web. El prompt injection, los permisos de herramientas inseguros y la manipulación de modelos son clases de ataque distintas que el pentesting estándar suele pasar por alto si no se indican de forma explícita.

Plan de acción recomendado:

1. Incluye explícitamente los sistemas de IA en el alcance de las pruebas: no asumas que un pentest general de aplicación web cubrirá el prompt injection, los permisos de herramientas inseguros concedidos a los agentes o la manipulación de modelos. Todo eso necesita casos de prueba específicos
2. Gestiona los hallazgos de IA igual que cualquier otro: asígnale un ID único, un responsable, un verificador, evidencias y una nueva prueba.
3. Vigila primero lo básico del control de acceso: la mayoría de los incidentes de seguridad relacionados con la IA tienen su origen en fallos corrientes de control de acceso.
4. Vincula los hallazgos al Reglamento Europeo de IA (o a la normativa que corresponda) junto con el resto de tus correspondencias de cumplimiento.

Paso 10: realiza barridos de verificación antes de cerrar la remediación del pentest

Con el tiempo, las correcciones pueden desviarse, las actualizaciones pueden reintroducir vulnerabilidades o las dependencias pueden cambiar sin que nadie lo note. Puedes evitar esos desajustes con este flujo de trabajo:

1. Repite los pasos de prueba originales, tal y como se indica en el paso 5, para confirmar que cada vulnerabilidad sigue corregida y que los resultados coinciden con las evidencias anteriores.
2. Prueba los sistemas o controles relacionados a los que el trabajo de remediación podría haber afectado.
3. Registra las tasas de éxito y de fallo, los hallazgos reabiertos y documenta cualquier anomalía nueva que aparezca.
4. Reabre o escala según convenga. Por ejemplo, cualquier problema detectado durante el barrido debe registrarse de inmediato para su seguimiento. Usa la información recién obtenida para afinar tu estrategia de refuerzo en el siguiente ciclo.

Hacer un barrido de verificación final antes de que termine tu estrategia de 90 días garantiza que todos los hallazgos cerrados siguen corregidos.

Paso 11: publica paquetes de evidencias que respalden tu estrategia de remediación

Un paquete mensual de evidencias de una sola página sirve como prueba, de cara al cliente, de tus flujos de remediación de pentesting. Con NIS2 y DORA ya en plena aplicación, esos paquetes no deberían limitarse a resumir: tienen que vincularse directamente a los marcos que auditores o reguladores van a comprobar.

Plan de acción recomendado:

1. Resume las métricas clave: incluye el número de hallazgos abiertos y cerrados, la evolución de la reducción del riesgo y cualquier excepción o vulnerabilidad reabierta.
2. Vincula las evidencias a los hallazgos: referencia los artefactos de validación recogidos durante la remediación y asegúrate de que cada dato pueda rastrearse hasta su ID único para facilitar la auditoría.
3. Vincula las evidencias al marco aplicable: en el caso de NIS2, esto suele implicar demostrar que las pruebas y la remediación están estructuradas conforme al artículo 21. Para DORA, señala la diferencia entre las evidencias de remediación rutinaria y las pruebas de penetración basadas en amenazas según TIBER-EU. Para PCI DSS 4.0 o ISO 27001, cita el control concreto que satisface cada evidencia.
4. Incluye la estrategia del mes siguiente: describe qué viene en la próxima oleada de remediación, como verificaciones, revisiones de diseño o medidas de refuerzo.
5. Mantén un formato coherente: usa siempre el mismo formato para que los paquetes sean fáciles de leer. Así tu informe es repetible, sencillo de generar y fácil de comparar entre trimestres.

Ejemplo de puntos de automatización en la remediación de pentesting

La automatización apoya los pasos de remediación del pentesting al acelerar los flujos de trabajo sin perder coherencia, responsabilidad ni evidencias a lo largo de tu ciclo de 90 días.

• Programa tareas nocturnas para sincronizar los hallazgos desde las herramientas de seguimiento, incluidas las actualizaciones de KEV y EPSS, actualizar los gráficos de reducción del riesgo y revisar las fechas de caducidad de las excepciones.
• Marca automáticamente los artefactos de validación que falten o las excepciones próximas a vencer.
• Configura scripts semanales que sondeen las clases de alto riesgo y confirmen que las correcciones siguen aguantando.
• Envía los nuevos resultados de pruebas y registros a repositorios de evidencias centralizados.

Aprovecha NinjaOne para automatizar tu hoja de ruta de pentesting

NinjaOne simplifica los flujos de remediación de pentesting automatizando la recogida de evidencias, el seguimiento y los informes a lo largo de tu estrategia de 90 días. Sus herramientas automatizan la validación, la documentación y la gestión de vulnerabilidades, lo que reduce el trabajo manual de los técnicos sin comprometer la postura de seguridad de tu cliente.

• Descubrimiento: usa tareas programadas por política para automatizar la recogida de evidencias, etiqueta los activos por ID de hallazgo y adjunta los paquetes mensuales de evidencias a la documentación. La función de informes programados de NinjaOne puede recopilar y distribuir evidencias automáticamente entre clientes, mientras que el etiquetado de activos informáticos permite seguir y organizar los endpoints en todos los entornos de cliente.
• Priorización: el servicio de gestión de vulnerabilidades de NinjaOne muestra las vulnerabilidades con sus CVE y puntuaciones CVSS, y añade el estado en KEV y el contexto de explotación, de modo que los técnicos puedan priorizar lo que realmente requiere atención inmediata en lugar de ir bajando por una lista de gravedad sin contexto.
• Movilización: la automatización de parches puede reconfigurarse para desplegar parches estables o señalar los urgentes que requieren atención inmediata, conectando los hallazgos del pentest directamente con la remediación.
• Herramienta de documentación: NinjaOne Documentation te permite crear runbooks de remediación personalizados y almacenar las evidencias de cada cliente en una base de conocimientos centralizada. Esto garantiza flujos de trabajo coherentes y facilita la transferencia de conocimiento entre técnicos.

Crea una hoja de ruta de pentesting de 90 días para remediar riesgos

Saca el máximo partido a las pruebas de penetración actuando sobre los hallazgos de forma estructurada y respaldando cada cambio con evidencias. Si estandarizas los hallazgos, planificas por oleadas, validas las correcciones de forma sistemática, documentas las excepciones y elaboras informes transparentes, podrás reducir el riesgo real en 90 días y mantener la confianza de las partes interesadas.

Temas relacionados:

• Pentesting frente a análisis de vulnerabilidades
• ¿Qué es la remediación de vulnerabilidades? Explicada con ejemplos
• Plazos de remediación de vulnerabilidades: 7 buenas prácticas
• ¿Qué es una evaluación de vulnerabilidades y por qué es importante?