Saltar al contenido
Volver al blog

Cómo leer un informe de pentest sin dejarse impresionar

Un informe con veinte hallazgos críticos no necesariamente describe una organización insegura. Puede describir un escáner mal configurado. Seis preguntas para evaluar la calidad de lo que le entregaron.

Por Wak Ops4 min de lectura

Si su organización compra pruebas de penetración, en algún momento va a comparar dos informes de dos proveedores distintos y va a llegar a una conclusión incómoda: el informe más grueso y con más hallazgos críticos suele ser el peor de los dos.

No es una paradoja. Es lo que ocurre cuando se factura por volumen de hallazgos en lugar de por profundidad de análisis. Estas son las seis preguntas que usamos para evaluar la calidad de un informe — incluidos los nuestros.

1. ¿Cada hallazgo se demostró o solo se detectó?

Un escáner reporta que el servidor expone una versión con una vulnerabilidad conocida. Eso es una detección. Una prueba real confirma que esa vulnerabilidad es explotable en esa configuración específica y documenta el resultado. Eso es una demostración.

La diferencia importa porque una alta proporción de las detecciones automáticas no son explotables en contexto: el servicio está detrás de otro control, la función vulnerable no está en uso, o la versión fue parchada sin cambiar el número que el escáner lee.

Qué buscar: cada hallazgo de severidad alta o crítica debe traer pasos de reproducción concretos y evidencia del resultado. Si dice “se recomienda actualizar a la versión más reciente” y nada más, es salida de escáner.

2. ¿Las severidades reflejan su negocio o un puntaje genérico?

CVSS es útil como referencia común, pero es agnóstico a su contexto. La misma vulnerabilidad puede ser crítica en un sistema y prácticamente irrelevante en otro.

Un informe bueno ajusta la severidad por exposición real, valor del activo y controles compensatorios existentes — y explica el ajuste. Si todas las severidades del informe coinciden exactamente con el puntaje base de la CVE, nadie pensó en usted.

3. ¿Hay encadenamiento de hallazgos?

Aquí es donde se separa el trabajo real del automatizado. Tres hallazgos de severidad media, aislados, se ven manejables. Los mismos tres encadenados —divulgación de información que revela un nombre de usuario, política de contraseñas débil que permite adivinarlo, y una interfaz administrativa sin segundo factor— constituyen una ruta directa a administrador.

Un escáner nunca ve esa cadena, porque evalúa cada hallazgo por separado. Si el informe no contiene ni una sola narrativa de ataque encadenada, probablemente nadie pasó de la fase de escaneo.

4. ¿El resumen ejecutivo es útil o decorativo?

La prueba: entrégueselo a alguien de finanzas y pídale que le diga qué hay que arreglar primero y por qué. Si no puede, el resumen no cumple su función.

Un buen resumen ejecutivo no es el informe técnico con menos palabras. Responde tres cosas: qué podría pasarle al negocio, qué tan probable es, y qué hay que hacer en qué orden. Sin nombres de CVE en el primer párrafo.

5. ¿Está declarado lo que no se probó?

Todo compromiso tiene límites. Sistemas fuera de alcance, ventanas de prueba restringidas, entornos que estaban caídos durante la ejecución, credenciales que se entregaron tarde. Un informe honesto declara sus limitaciones de forma explícita, porque un lector desprevenido puede interpretar “no se reportaron hallazgos” como “no hay hallazgos”.

La ausencia de una sección de limitaciones no significa que no las hubo. Significa que no se las contaron.

6. ¿Está incluida la reprueba?

Un hallazgo corregido no está cerrado hasta que alguien lo verifica. Las correcciones parciales son comunes: se arregla la instancia reportada y quedan otras tres iguales en sistemas que no se revisaron; o el parche introduce un problema distinto.

Si la reprueba se cotiza como un servicio aparte, considérelo en el precio total desde el inicio — porque sin ella, el informe describe un momento en el pasado y nada más.

Sobre el número de hallazgos

Vale la pena decirlo directamente: más hallazgos no es mejor trabajo.

Un informe con cuarenta hallazgos de los cuales treinta son configuraciones menores de cabeceras HTTP le consumirá semanas de trabajo del equipo de infraestructura para reducir muy poco riesgo real. Un informe con seis hallazgos, de los cuales dos describen rutas completas hacia sus datos más sensibles, vale considerablemente más — y es más difícil de producir.

Cuando evalúe propuestas, pregunte por un informe de muestra anonimizado. La estructura del entregable le dice más sobre cómo trabaja el proveedor que cualquier certificación en la propuesta comercial.

Temas

pentestingcontratacióngestión de riesgo

Siga leyendo