Guía práctica

Cómo convertir un informe de pentesting en un plan de cierre

Recibir un informe de pentesting no resuelve las vulnerabilidades. Para convertirlo en una reducción de exposición necesitas acordar qué corregir, quién lo hace y cómo comprobar que el cambio funciona. Esta guía propone un registro sencillo que mantiene visibles los hallazgos hasta su verificación.

Por InmunoSec · Publicado el

1. Comprueba qué describe realmente el informe

Antes de abrir tareas de desarrollo, identifica los activos, fechas, usuarios o roles utilizados, límites de las pruebas y condiciones de cada hallazgo. Si el informe no explica cómo se observó el problema, pide una aclaración al proveedor. No conviertas una descripción ambigua en un ticket que nadie pueda validar.

Conserva el identificador original del hallazgo. Así podrás relacionar el informe, la tarea de corrección y la evidencia de verificación aunque usen sistemas distintos.

2. Prioriza con el contexto de tu negocio

La severidad técnica es una entrada de la decisión. Añade si el activo está expuesto, qué procesos dependen de él, qué controles existen y qué coste tiene corregirlo. Un número de severidad no indica por sí solo la pérdida económica que tendrá tu empresa.

Cuando exista incertidumbre, déjala registrada. Una prioridad explicada es más útil que una columna de números sin criterio.

3. Asigna una corrección y una persona responsable

Cada tarea debe describir el resultado esperado, responsable, dependencia y fecha objetivo. Distingue entre corregir la causa, reducir temporalmente la exposición y aceptar el riesgo. Las tres son decisiones posibles, pero no significan lo mismo.

Si un proveedor aplica el cambio, acuerda cómo confirmará el despliegue y cómo podrá verificarse después. Una tarea puede estar terminada en desarrollo y seguir pendiente en producción.

4. Comprueba el cambio sobre el entorno acordado

El retest debe contrastar el problema descrito y las variantes pertinentes dentro del alcance. Registra la fecha, el entorno, la persona que verificó y una referencia segura a la evidencia.

No distribuyas contraseñas, pruebas sensibles o informes completos mediante formularios públicos. Usa el canal de intercambio acordado con las personas responsables.

5. Mantén visibles las excepciones

Un registro útil diferencia, como mínimo: abierto, en corrección, listo para retest, cerrado y verificado, riesgo aceptado y no verificable. Aceptar un riesgo es una decisión de negocio; no es una prueba de que una vulnerabilidad haya desaparecido.

Si una prueba no se puede repetir, explica por qué. Si el hallazgo queda fuera del alcance, conserva esa decisión y su motivo. Así el porcentaje final no oculta lo que falta.

6. Calcula el cierre sin cambiar las reglas a mitad del ciclo

Define el conjunto de hallazgos del ciclo antes de calcular su evolución. Para un conjunto fijo de N hallazgos válidos que requieren acción:

Tasa de cierre verificado = 100 × V / N, donde V es el número de hallazgos con corrección verificada.

Si N es cero, muestra “no aplicable”, no 100%. Un riesgo aceptado permanece fuera de V. Si cambia el alcance, publica también la variación del denominador y su motivo; no retires hallazgos para mejorar el porcentaje.

Ejemplo ilustrativo: 10 hallazgos válidos, 7 verificados, 1 en corrección, 1 aceptado y 1 pendiente de prueba. El cierre verificado es 70%. Esta métrica no significa que se haya eliminado el 70% del riesgo económico: trata cada hallazgo como una unidad y debe acompañarse del desglose por severidad.

Si se desea una tasa ponderada, declarar los pesos antes de medir: Tasa ponderada = 100 × suma de pesos de los hallazgos verificados / suma de pesos de los hallazgos del ciclo. Los pesos son una convención de seguimiento; no una estimación automática de probabilidad de ataque o pérdida.

Un ejemplo del trabajo publicado

El caso de WordPress de InmunoSec describe 14 ficheros maliciosos agrupados en 7 hallazgos. En la revisión posterior uno seguía abierto porque parte del código había acompañado una migración. Por eso se debe contar y verificar el hallazgo, no asumir que el cambio de servidor lo resolvió. Caso y cronología.

Plantilla de seguimiento

Descargar plantilla CSV

La plantilla incluida propone: identificador, activo, severidad, prioridad razonada, responsable, estado, fecha objetivo, fecha de verificación, referencia a la evidencia y excepción. Está vacía para que no se confundan ejemplos con datos reales.

Conserva el archivo en el espacio acordado para el proyecto. La plantilla pública está vacía; guarda los datos del proyecto en tu espacio privado.

Cuándo pedir ayuda

Si tienes el informe pero no puedes convertirlo en acciones, InmunoSec puede revisar el alcance, ayudar a priorizar y acompañar las correcciones. Si los cambios ya están aplicados, puede encajar un retest independiente.

Si ya dispones de un informe, consulta cómo lo convertimos en un plan de cierre. Para el ciclo completo, revisa Security Closure; si las correcciones ya están aplicadas, consulta Security Retest.

Pon tu informe en marcha.

Cuéntanos qué falta para corregir y verificar los hallazgos. Acordamos el intercambio del informe por un canal adecuado.

Respondemos en menos de 24 horas laborables. Primera conversación sin coste y sin compromiso.