Ya hicimos el pentest, ahora… ¿Como documentamos?

A la mayoría de pentesters nos ha pasado que finalizamos la ejecución de un pentest y llegamos al punto menos placentero, la documentación,lo ideal y la manera que nos ha dado mejor resultado en CSIETE/7WS ha sido documentar en tiempo real lo que transcurre en el desarrollo de las pruebas, algo rápido para no perder el hilo y el contexto de los hallazgos, así una vez finalizadas las pruebas es mucho más fácil, rápido y efectivo retomar la construcción de los informes (Técnico/ejecutivo) para entregarle al cliente, la estructura de estos informes está definida por el framework o la metodología utilizada para desarrollar las pruebas, existen diferentes tipos, entre los que encontramos:

• ISSAF (Information Systems Security Assessment Framework)
• PCI DSS (Payment Card Industry Data Security Standard)
• OSSTMM (Manual de la Metodología Abierta de Testeo de Seguridad)
• PTES (Penetration Testing Execution Standard)

Esta última (PTES) es la empleada por CSIETE/7WS, la cual hemos ido adaptando a las necesidades específicas de los clientes presentando los informes técnicos y ejecutivos con una estructura predeterminada que está compuesta por una introducción, detalles del proyecto, insumos, accesos, resumen y detalles de los hallazgos, resultados generales de las pruebas, recomendaciones y conclusiones.

La construcción de estos informes debe tener un nivel de detalle para que pueda ser entendido por una persona técnica, pero también debe tener una simplicidad que permita que una persona que se encuentre en otra área entienda los hallazgos identificados, es por esto que lo ideal es entregar dos informes uno técnico, con la evidencia de los hallazgos, la explicación detallada de lo identificado y las recomendaciones pertinentes y un informe ejecutivo, este con más gráficas, números, resultados y conclusiones generales.

Consideramos que la mejor forma de redactar un informe, es escribirlo en tercera persona, en presente simple, la introducción debe presentar a grandes rasgos qué se verá en el informe, qué se estaba evaluando, en qué tiempo, bajo qué modalidades (caja negra, caja gris) y debe contener una gráfica de la aplicación o infraestructura evaluada, una pequeña descripción de su flujo y de lo que le permite realizar a sus usuarios, luego de tener lista la introducción, se procede con el resumen y el detalle de los hallazgos, para esto deben responderse las que en inglés conocemos como las 5WH:

• ¿Qué?
• ¿Por qué?
• ¿Cuándo?
• ¿Dónde?
• ¿Cómo?

Aquí un ejemplo de cómo debería ser la documentación de un hallazgo identificado a un público con conocimientos técnico:

“Se identifica qué hace falta un control en el manejo de errores emitidos por el servidor, pues al momento de realizar una petición con parámetros mal formados de manera intencional, el servidor entrega información que permite identificar la ruta interna donde se encuentra alojada esta aplicación, además de esto en los headers de respuesta es posible identificar la tecnología web utilizada con su versión y sistema operativo”.

Aquí un ejemplo de cómo debería ser la documentación de un hallazgo identificado a un público sin conocimientos técnico:

“Se identifica qué hace falta un control en el manejo de errores emitidos por el servidor, pues al momento de realizar una consulta con datos erróneos o para los cuales se sabe que no se obtendrá una respuesta correcta, entrega información sensible de su configuración que permite identificar detalles internos”.

Impacto: Un atacante podría perfilar fácilmente las tecnologías usadas en la plataforma y buscar vectores de ataque sobre las versiones y rutas identificadas.

Es importante presentarle al cliente el impacto que este hallazgo representa para su compañía, qué podría realizar un atacante si hace uso de esta debilidad.

La evidencia debe tomarse lo más clara posible, los pantallazos deben ser legibles, claros y el título o descripción debe presentar el panorama evaluado.

Imagen 1. Se evidencia que se emplea el servidor nginx en su versión 1.14.0

Imagen 2. Se evidencia la versión 7.6.3.3 del servidor CompaqHTTPServer

Para finalizar el detalle de los hallazgos es importante entregarle al cliente, mínimo tres recomendaciones, las cuales son de suma importancia y fundamentales para mitigar de manera correcta las vulnerabilidades identificadas, con el fin de que el cliente tenga mayor claridad sobre el ¿qué? Y el ¿dónde? se deben Implementar los controles y/o tomar acciones.

Desde CSIETE/7WS se recomienda referenciar cada hallazgo si corresponde con el top 10 de OWASP, CVE, CWE, CVSSCORE o siguiendo las metodologías anteriormente mencionadas.

Para las conclusiones es importante hacer una lectura general de los hallazgos identificados, presentando la valoración del nivel de riesgo en que se encuentra el objetivo evaluado. Exponiendo todo lo que se pudo identificar, que se tiene implementado en cuanto a capacidades técnicas, controles, infraestructura y demás y finalmente decir si es aceptable o no el paso a un ambiente de producción o si, por el contrario, este ya se encuentra desplegado en producción se deban tomar medidas de seguridad lo antes posible, pues se encuentra en riesgo la disponibilidad, confidencialidad e integridad de la información.