Contenido del artículo
Después de un pentest, cada hallazgo recibe una prioridad según lo fácil que es explotarlo y lo que perdería el negocio, además de un responsable, un plazo y una forma de comprobarlo, y se cierra corrigiendo la causa y no el síntoma. Al final el proveedor hace un retest: vuelve a comprobar los mismos hallazgos y confirma por escrito cuáles están cerrados de verdad.
Abajo tienes CVSS explicado con palabras sencillas, cómo fijar prioridades, una plantilla de plan de corrección, qué demuestra y qué no demuestra el retest, y los errores habituales que hacen que los hallazgos vuelvan.
En resumen
- La puntuación CVSS muestra la gravedad técnica de una vulnerabilidad, no el riesgo para tu empresa. FIRST, autor del estándar, dice claramente que la puntuación base no debe usarse sola para evaluar el riesgo. [1]
- La prioridad sale de tres preguntas: si es fácil de explotar, si este tipo de fallo ya se usa en ataques reales y qué perdería el negocio.
- Cada hallazgo tiene un único responsable con nombre, un plazo y una forma de comprobarlo. «El departamento de desarrollo» no es un responsable.
- Corrige la causa: si un formulario mostraba datos ajenos, revisa todos los sitios parecidos.
- El retest confirma que hallazgos concretos están cerrados. No busca problemas nuevos ni sustituye al siguiente pentest.
Cómo leer la gravedad: CVSS v4.0 con palabras sencillas
CVSS (sistema común de puntuación de vulnerabilidades) da a cada problema un número de 0 a 10. La versión 4.0 usa estos niveles: 0.0 ninguna, de 0.1 a 3.9 baja, de 4.0 a 6.9 media, de 7.0 a 8.9 alta, de 9.0 a 10.0 crítica. [1]
Importa saber de qué se compone ese número. La puntuación base describe la vulnerabilidad en sí: si se puede atacar por internet, si hace falta iniciar sesión, si hace falta que un usuario haga algo, qué pasa con los datos. No sabe nada de tu empresa. El estándar tiene además un grupo de amenaza (si existe una forma lista de atacar) y un grupo de entorno (lo importante que es tu sistema en concreto), pero los rellena quien usa la puntuación, es decir, tú. [1]
FIRST insiste aparte en que la puntuación base mide gravedad, no riesgo, y que hay que completarla con datos de amenazas y de tu entorno. [2] Por eso un «9.1» en el informe significa «técnicamente muy grave», pero no siempre «corrígelo primero».
Cómo fijar la prioridad real
Hazte tres preguntas sobre cada hallazgo.
1. ¿Es fácil de explotar? Si la vulnerabilidad es accesible desde internet, si hace falta una cuenta, si el pentester mostró un ataque que funciona. Un hallazgo que el pentester explotó de verdad pesa más que uno teórico.
2. ¿Se usa en ataques reales? Para vulnerabilidades conocidas de productos hay fuentes abiertas. La agencia estadounidense CISA mantiene el catálogo KEV, una lista de vulnerabilidades que ya se explotan en ataques reales. [3] FIRST publica EPSS, una estimación diaria de la probabilidad de que una vulnerabilidad se explote en los próximos 30 días. [4] Si un hallazgo está en KEV, su prioridad es mayor de lo que indica la puntuación CVSS por sí sola.
3. ¿Qué perdería el negocio? La metodología de valoración de riesgos de OWASP separa el impacto técnico del impacto en el negocio y subraya que el impacto en el negocio importa más. [5] El acceso a la base de clientes, a los pagos o al correo del director pesa más que la misma vulnerabilidad en un servidor de pruebas sin datos.
El pentester no siempre conoce todos los detalles de tu negocio, así que puede valorar un hallazgo por encima o por debajo de como lo harías tú. El NCSC recuerda que las decisiones sobre riesgo y correcciones son del cliente, pero que ese proceso no debe servir para restar importancia a los problemas. [6]
Quién se encarga de cada hallazgo
El responsable de un hallazgo significa una persona concreta que se encarga de que el problema se cierre y de demostrarlo. No tiene por qué ser quien escribe el código: puede delegar el trabajo, pero responde del resultado.
Un reparto típico:
- aplicación web y API: el jefe del equipo de desarrollo del producto;
- servidores, red, nube: el administrador o el responsable de TI;
- cuentas, accesos, correo: el administrador de Microsoft 365 o Google Workspace;
- procesos (por ejemplo, quién da acceso a las personas nuevas): el responsable del área o el director de operaciones;
- la decisión de aceptar el riesgo sin corregir: el dueño del negocio o el CTO, con firma.
Plan de corrección
El formato más sencillo que funciona es una tabla de cuatro columnas. Los plazos de abajo son solo un ejemplo; los fijas tú según la prioridad.
| Hallazgo | Responsable | Plazo | Cómo comprobarlo |
|---|---|---|---|
| Un cliente ve pedidos ajenos cambiando el número en la dirección | Jefe de desarrollo | Inmediato, antes de fin de semana | Prueba con dos cuentas: la segunda recibe un rechazo; revisadas todas las direcciones parecidas |
| Una versión antigua del servidor con una vulnerabilidad conocida del catálogo KEV | Administrador | Unos días | Versión actualizada; un nuevo escaneo ya no ve la vulnerabilidad |
| Las contraseñas se pueden adivinar sin límite | Jefe de desarrollo | 2 semanas | Tras varios intentos fallidos se bloquea el acceso; queda registro |
| Un panel de administración es accesible desde internet | Responsable de TI | 2 semanas | El panel no abre desde fuera; acceso solo por VPN (conexión protegida) |
| Los directivos no tienen doble factor en el correo | Administrador de correo | Un mes | Informe de la consola: todos los directivos tienen segundo factor activado |
| Los errores del servidor muestran rutas internas | Jefe de desarrollo | Próxima versión | El error muestra solo un mensaje genérico |
La columna «cómo comprobarlo» es la más importante. Describe la prueba que enseñarás en el retest, no la intención de «arreglarlo».
Qué es el retest y qué demuestra
El retest significa volver a comprobar los mismos hallazgos después de tus correcciones, para confirmar que están cerrados de verdad. El pentester repite el ataque que funcionó antes e intenta saltarse la corrección.
El retest demuestra:
- que el ataque concreto del informe ya no funciona;
- que la corrección no se puede esquivar de forma sencilla, por ejemplo con otra dirección u otro rol de usuario;
- el estado de cada hallazgo: cerrado, cerrado en parte, no cerrado o aceptado como riesgo.
El retest no demuestra que el sistema sea seguro en general. No busca problemas nuevos, y si has cambiado mucho el producto, necesitas un nuevo pentest, no una repetición. Cómo prepararte para la prueba y el retest para que no se pierda nada lo tienes en cómo prepararse para un pentest.
Conviene acordar antes de empezar si el retest está incluido en el precio y cuánto tarda. De qué depende el coste se explica en qué incluye un pentest y cuánto cuesta.
Errores habituales
- Corregir el síntoma. Se bloquea la dirección que mostraba pedidos ajenos, pero no se añade la comprobación de permisos. El retest encuentra el mismo fallo en la sección de al lado.
- Cerrar un ticket sin prueba. Un desarrollador marca la tarea como hecha, pero nadie repite el ataque. En el informe del retest el hallazgo sigue abierto.
- Ordenar solo por la cifra CVSS. Se corrigen primero las puntuaciones altas de un servidor de pruebas, mientras un hallazgo medio con acceso a datos de clientes espera un mes.
- No asignar responsable. Un hallazgo «de todos» no es de nadie y pasa al siguiente informe.
- Aceptar un riesgo en silencio. Si decides no corregir algo, registra la decisión con el motivo, una fecha de revisión y una firma.
- Esperar meses para el retest. En ese tiempo el sistema cambia y el resultado se vuelve difícil de comparar con el informe.
Lista después de un pentest
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Qué hago justo después de recibir el informe de un pentest?
Lee el resumen, asigna un responsable a cada hallazgo crítico y empieza por ellos. Después haz un plan para el resto: responsable, plazo y forma de comprobación para cada punto.
¿Siempre hay que corregir primero los hallazgos con la puntuación CVSS más alta?
No. CVSS muestra la gravedad técnica, no tu riesgo. Un hallazgo fácil de explotar que lleva a datos de clientes o a dinero suele importar más que una puntuación mayor en un sistema sin datos valiosos.
¿Qué es un retest después de un pentest?
Es una segunda comprobación de los mismos hallazgos después de las correcciones. El pentester repite el ataque y confirma por escrito qué está cerrado, qué está cerrado en parte y qué no.
¿El retest busca vulnerabilidades nuevas?
No, el retest solo revisa los hallazgos del informe anterior. Si el producto ha cambiado mucho, necesitas un nuevo pentest.
¿Qué hago si un hallazgo no se puede corregir ahora?
Añade una protección temporal, como restringir el acceso o más monitorización, y registra un riesgo aceptado: el motivo, quién lo decidió y hasta cuándo. Vuelve a él en la siguiente planificación.
Referencias
- FIRST: CVSS v4.0 Specification Document first.org
- FIRST: CVSS v4.0 User Guide first.org
- CISA: Known Exploited Vulnerabilities catalog data github.com
- FIRST: Exploit Prediction Scoring System (EPSS) first.org
- OWASP Risk Rating Methodology community.owasp.org
- NCSC: Penetration testing ncsc.gov.uk
