Ethical Hacking: Informe de Resultados

aa_informeHoy día, tenemos disponible gran cantidad de material sobre temas relacionados con Ethical Hacking: cursos, libros, webs especializadas, etc. Todos explican que las fases de un pentest comienzan con information gathering, 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 muy importante: la elaboración del informe de resultados.

Está claro: es la parte que mas nos aburre. Es mucho más entretenido trabajar con Metasploit, una Shell, Scritps 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 vano. Esto lo aprendí cuando leí el libro “Ethical Hacking: Un enfoque metodológico para Profesionales“, escrito entre otros por Ezequiel Sallis y Claudio Caracciolo. Por eso me voy a tomar el atrevimiento de darles algunos consejos muy útiles para confeccionar 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 gran problema, recuerden que ingresar sin permiso a un sistema es ilegal y esta penado por la ley. 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 analisis: 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 pentest. ¡Happy Hack & Have Fun!

Ok!. Ya está todo probado. Tenemos las notas que tomamos, 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, cuanto más visual, más claro quedará. Recuerden que el resumen ejecutivo 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 empresa 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.

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 dicho 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 estos consejos. 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