Test de intrusión: Informe de resultados

Hoy día, tenemos disponible gran cantidad de material sobre temas relacionados con test de intrusión: cursos, libros, webs especializadas, etc. Todos explican que las fases de un pentest comienzan con la recogida de información, y terminan con la post-explotación y el borrado de evidencias, básicamente. Sin embargo, la mayoría de publicaciones que enseñan a hacer pentest, fallan en una parte importantísima: la elaboración del informe de resultados.

Está claro: es la parte más aburrida. Es mucho más entretenido trabajar con una shell que con un procesador de textos, ¿verdad? ;-) Es vital tener bien claro que el informe es, en última instancia, es el producto que se le entrega al cliente. Si no somos capaces de plasmar y reflejar en texto el trabajo realizado, por muy bueno que sea el proceso seguido y el resultado obtenido, con un informe mediocre el esfuerzo habrá sido en balde. Por eso me he animado a comentar los puntos claves para rematar la faena, con un informe de calidad.

Para explicar el informe de resultados, antes hay que tener en cuenta un documento previo: el plan de pruebas. Este documento, que debe estar aprobado por el cliente, es la autorización para poder auditar lícitamente un recurso que no es tuyo. En él se describe básicamente qué se va a hacer, y hasta donde se va a llegar. Sin este documento firmado por el cliente, podríamos meternos en un buen lío. Incluye:

• Ámbito de las pruebas. Qué se audita y qué se queda fuera.
• Rangos de IP, tanto del cliente como de los auditores.
• Planificación temporal, días y horas en las que tendrá lugar.
• Personas de contacto. A quién llamar en caso de que algo caiga.
• Tipos de pruebas, si se está autorizado a lanzar ataques DoS o de ingeniería social.
• Propósito del pentest: para qué se va a hacer, qué se quiere conseguir.

Una vez aprobado el plan de pruebas, ya tenemos luz verde para empezar con el test de intrusión. ¡Comienza la diversión!

OK. Ya está todo probado. Tenemos nuestras notas, capturas de pantalla, logs, y demás evidencias de las vulnerabilidades encontradas. Ahora, como ya hemos comentado, toca la parte de transformar toda esta información en un documento y que el cliente conozca todo lo que has descubierto.

En primer lugar, hay que preguntarse: ¿A quién va dirigido este informe? ¿Personal técnico? ¿Directivo? ¿Ambos? Por regla general, los informes de resultados van a ser leídos por varios departamentos, con perfiles muy diferentes. Por ello será necesario redactar una parte, con un resumen ejecutivo, sin entrar en detalles y otra parte con un análisis de las vulnerabilidades.

En el resumen ejecutivo, se enumerarán las vulnerabilidades encontradas. Según su criticidad, se pueden usar colores, puntuaciones, gráficos, etcétera, cuanto más visual, más claro quedará. Recordad que esta sección debe redactarse en un lenguaje lo menos técnico posible. Se deben incluir también las recomendaciones generales para mitigar las vulnerabilidades, sin extenderse en detalles, y finalmente las conclusiones. Esta parte está relacionada con el plan de pruebas y el propósito del pentest. Respondería a preguntas como ¿puede salir la aplicación web a producción? ¿Es la red de mi organización razonablemente segura?

La otra parte del informe es el análisis de las vulnerabilidades. Aquí es donde se debe describir con todo lujo de detalles cuales han sido las pruebas realizadas, qué ha conseguido explotarse, adjuntar capturas de pantalla que lo demuestren, y una valoración del impacto, probabilidad de ocurrencia, y riesgo asociado a cada vulnerabilidad. Por último, unas recomendaciones sobre cómo mitigar la vulnerabilidad, sin escatimar en referencias. Nos puede ser muy útil el post de nuestro compañero David sobre el uso de gimp para capturas de pantalla en los pentest.

Finalmente, también puede ser recomendable incluir un apéndice, con información ampliada que no sea esencial para describir las vulnerabilidades descubiertas, como resultados de herramientas, logs, etc y un glosario de términos, para aquellos acrónimos o términos técnicos relevantes.

Una vez terminado el informe, hay que recordar que la información contenida en el documento es muy sensible. El documento debe advertir claramente que su contenido tiene carácter confidencial. Por una parte, debe enviarse al cliente por una vía segura y cifrada, y por otra parte, es nuestra responsabilidad almacenar el informe con los permisos únicamente de los implicados en el proyecto.

Espero que hayan sido de utilidad estas indicaciones. Información ampliada e informes de ejemplo pueden encontrarse en los siguientes enlaces (en inglés):

– Ejemplo informe de pentest Offensive Security [PDF]
– SANS Reading Room, Writing a Penetration Testing Report [PDF]
– Writing penetration testing resports
– The penetration testing report