Cómo hacer tu primer informe de PENTESTING

¿Qué es un informe de prueba de penetración?

Tras una auditoría de seguridad, se crea y presenta un informe con los hallazgos encontrados. Este informe cubre diferentes aspectos de la postura de seguridad de la empresa, tales como:

• Vulnerabilidades identificadas.
• Preocupaciones de alta y baja prioridad.
• Sugerencias de remediación, es decir, cómo corregir los problemas detectados.

Este tipo de informe, además de ser esencial para mejorar la seguridad de una empresa, juega un papel clave en el cumplimiento de regulaciones de seguridad como HIPAA, ISO 27001, PCI DSS, entre otras.

Estas regulaciones requieren que las empresas implementen prácticas de seguridad rigurosas para proteger datos sensibles, ya sea información de salud, datos personales o información financiera. Entregar un informe detallado de pentesting ayuda a una organización a demostrar que están tomando medidas serias para proteger su infraestructura y cualquier dato sensible que manejen. Esto, a su vez, mejora la seguridad del producto y fortalece la confianza de los clientes.

¿El problema? Muchas empresas solo hacen auditorías de seguridad para pasar el “examen” de las regulaciones. Pero bueno, eso da para otro vídeo.

¿Por qué es importante el informe de pentesting?

Algo que debes tener claro… Las empresas no contratan hackers para que los hackeen. No.

Lo que realmente buscan las empresas es una evaluación o informe de pentesting que les dé una imagen completa de su entorno, sus defensas y su preparación para enfrentar amenazas en ese momento y contexto específico. Básicamente, el informe es la única forma de demostrar y defender tu trabajo.

Cómo es la estructura del Informe de Pruebas de Penetración

Un informe de pentesting bien estructurado debe contener los siguientes elementos:

• Presentación o introducción: En este primer apartado, se detalla el alcance de la auditoría y la planificación.
  • Con alcance nos referimos a qué se debe auditar. Por ejemplo, si es una auditoría web y quieren auditar una funcionalidad concreta en server[.]ejemplo[.]com, el alcance solo incluiría este subdominio. Todo lo que esté fuera de este subdominio estaría fuera del alcance de la auditoría, es decir, no tendríamos permiso para auditar esa parte.
  • En el apartado de planificación, se detallan los tiempos de la auditoría: entre qué fechas y en qué horarios se llevará a cabo la auditoría.

En este mismo apartado de presentación, es aconsejable añadir comentarios de limitación si hemos tenido algún tipo de problema al realizar la auditoría. Básicamente, se debe explicar los objetivos y la metodología del pentesting.

Pasemos al siguiente apartado: el resumen ejecutivo.

• Resumen ejecutivo: Este es un resumen dirigido a la alta dirección, destacando los puntos más críticos y las recomendaciones. Se debe escribir con un lenguaje natural, sin tecnicismos.

Piensa que los ejecutivos no tienen tiempo para revisar el informe en detalle, así que necesitan un apartado donde se detalle el estado actual de la seguridad tras la auditoría, las vulnerabilidades ordenadas por criticidad y las conclusiones finales con sus recomendaciones.

A mí personalmente, me gusta escribir las conclusiones utilizando el método IAR:

• Identificación: ¿Qué he identificado?
• Acción: ¿Cómo lo he podido explotar?
• Riesgo: ¿Qué riesgo asociado tiene?

Por ejemplo:

Se ha observado que la aplicación no implementa una correcta validación en algunos parámetros de entrada, lo que permite la inyección de código malintencionado que se almacena y ejecuta de forma persistente durante la sesión del usuario. Esto supone un riesgo para la confidencialidad, la integridad y la disponibilidad de la información, así como para los usuarios legítimos de la plataforma.

Y como último apartado, pasamos al:

• Resultado de los tests: Presentación detallada de cada test, que incluye:
  • Vulnerabilidad: Nombre y descripción de la vulnerabilidad.
  • Severidad: Nivel de criticidad junto a su vector CVSS. (El vector te lo explicaré cuando te muestre el informe).
  • Descripción de la vulnerabilidad: Explicación breve sobre cómo funciona esa vulnerabilidad. Por ejemplo, qué es una XSS Injection.
  • Paso a paso de la explotación: Cómo se puede explotar la vulnerabilidad. En este paso, ten en cuenta que la persona que va a revisar tu informe para mitigar las vulnerabilidades probará cómo explotarla. Por eso es necesario ser claro y directo, proporcionando los pasos o comandos que utilizaste junto con imágenes como evidencias.
  • Remediación: Soluciones y recomendaciones para corregir la vulnerabilidad. En ocasiones, me gusta incluir el riesgo asociado en caso de no mitigarse la vulnerabilidad.

Y para acabar el informe, lo completamos con tres secciones muy importantes:

Recomendaciones generales, conclusiones y recursos.

• Recomendaciones generales: Aquí se detallan acciones generales que deben ejecutarse. Por ejemplo, instalar antivirus si hemos podido subir archivos maliciosos, actualizar aplicaciones o sistemas desactualizados, configurar permisos o aplicar el principio del mínimo privilegio, que básicamente significa no confiar ni en tu abuela.
• Conclusiones: En este apartado se incluye un resumen sobre la seguridad de la empresa. Puedes detallar qué patrón se repite durante el pentest. Por ejemplo, que cualquier usuario tenía permisos de administrador.

Estas conclusiones son diferentes a las del resumen ejecutivo.

• En el resumen ejecutivo, escribimos una conclusión por vulnerabilidad. Si hay 10 vulnerabilidades únicas, escribimos 10 conclusiones. En este apartado, lo que buscamos son patrones generales de malas praxis en la aplicación que hemos auditado.
  
  

Y por último, en la sección de recursos.

• se detallan las herramientas y fuentes de información que has utilizado durante el pentesting. Ten en cuenta que si utilizas algún binario de GitHub o de alguna web, debes proporcionarlo para que la persona que revise el informe pueda utilizar la herramienta.

Ahora, vamos a ver el documento detallado para que puedas hacerte una idea de cómo estructurarlo.