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.
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
Fuente: www.securityartwork.es
No hay comentarios:
Publicar un comentario