Qué debería decirte de verdad un informe de test de intrusión
La mayoría de los informes son un volcado de escáner con un logo encima. Esto es lo que hay que exigir en su lugar, y cómo saber en diez minutos si te vendieron pruebas reales.
A red pen over a printed page
Close crop of one hand holding a red pen above a printed page, mid-annotation. Bare pale surface, nothing else in frame. The pen is the only colour.
2400×1350 · WebP · <350KB
Normalmente se ve en diez minutos. Abre el informe, ve a un hallazgo y haz una pregunta: ¿podría mi ingeniero arreglar esto el lunes usando solo lo que está escrito aquí? Si la respuesta es no, no compraste un test de intrusión. Compraste una licencia de escáner con el membrete de un consultor.
La señal: severidad sin relato
Un escáner produce una lista. Cuarenta hallazgos, cada uno con su CVSS, cada uno cierto por separado y ninguno conectado con otro. Un pentester produce un relato: este subdominio olvidado exponía un login de preproducción, preproducción compartía contraseña con producción, y producción no tenía MFA en las cuentas administrativas. Por separado son medio, medio y bajo. Encadenados, así es como alguien es dueño de tu entorno antes de comer.
Si tu informe no contiene ninguna cadena —ninguna frase que empiece por «combinando los hallazgos 12, 19 y 27»— nadie te ha probado de verdad. Han apuntado una herramienta hacia ti.
Cuarenta hallazgos ordenados por puntuación te dicen lo que notó un escáner. Nueve hallazgos ordenados por lo que un atacante haría con ellos te dicen qué arreglar.
Lo que necesita cada hallazgo
- Pasos de reproducción que tu ingeniero pueda seguir sin llamar al pentester. La petición exacta, el parámetro exacto, la condición previa exacta.
- Evidencia. Una captura o una respuesta registrada que demuestre que el problema es real y no teórico.
- Impacto en tus términos. No «divulgación de información», sino «un usuario no autenticado puede enumerar todas las direcciones de correo de clientes».
- Una corrección que nombre la cosa. El archivo, la clave de configuración, la cabecera. No «implementad validación de entrada».
- Una severidad honesta, ajustada a tu entorno. Una RCE en una máquina aislada sin datos no es crítica, diga lo que diga el escáner.
Las partes que casi todos los informes omiten
Un buen informe también te dice qué no se probó y por qué. Los límites del alcance, los sistemas fuera de él, las credenciales que nunca llegaron, el entorno que estuvo caído dos días de la ventana. Esos huecos son riesgo que sigues cargando, y ocultarlos hace que el informe se vea mejor y tú estés menos seguro.
También debería decirte qué aguantó. Si tu WAF bloqueó los intentos de inyección y tu EDR mató el payload, eso merece constar por escrito. Lo has pagado; deberías poder demostrar que funciona.
El retest forma parte del trabajo
Un hallazgo no está cerrado porque se cerrara un ticket. Está cerrado porque alguien probó el exploit otra vez y falló. Cualquier firma que cobre aparte por verificar sus propios hallazgos tiene un incentivo que no quieres en la relación. El retest debería ir incluido, y el informe reemitido debería mostrar el hallazgo tachado con la fecha de verificación.
Una lista corta de comprobación
- ¿Hay al menos una ruta de ataque encadenada, escrita como relato?
- ¿Puede un ingeniero reproducir el hallazgo principal sin hacer preguntas?
- ¿Cada corrección nombra un archivo, un ajuste o una cabecera?
- ¿Hay una sección sobre lo que quedó fuera de alcance o sin probar?
- ¿Está incluido el retest, y para cuándo?
- ¿Se comunicaron los hallazgos críticos durante la prueba, en vez de guardarlos para la reunión final?
Ese último punto importa más que todos los demás juntos. Si un pentester encuentra un compromiso activo o una crítica expuesta a internet el segundo día, deberías saberlo en menos de una hora. Enterarte por un PDF tres semanas después no es un estilo de reporte. Es negligencia.