Qué es un pentest y qué debe incluir su informe

Un pentest (pentesting o prueba de penetración) es una evaluación en la que especialistas autorizados intentan explotar las debilidades de los sistemas acordados, como lo haría un atacante, para demostrar qué es posible. Lo que su empresa recibe al final es un informe: qué se probó, qué se confirmó, cuál es su gravedad y qué conviene corregir primero.

Si su empresa encarga un pentest —porque lo pidió un cliente, un banco con el que trabaja o su propia dirección—, el equipo realiza las pruebas en los sistemas acordados, en un plazo y con avisos de avance que se acuerdan antes de empezar. Lo que queda es el documento. Su equipo de TI necesita la evidencia y las indicaciones para corregir; la dirección necesita el impacto en el negocio y las prioridades propuestas; un cliente o un auditor lo usa para comprobar que la prueba se hizo. Esta guía le ayuda a acordar qué recibirá y a revisar el informe cuando llegue.

Qué es un pentest y qué no es

"Una metodología de prueba en la que los evaluadores, normalmente bajo restricciones específicas, intentan eludir o vencer las funciones de seguridad de un sistema."

NIST SP 800-53 Rev. 5, definición del glosario (traducción propia)

Las restricciones son el alcance y las reglas que se acuerdan antes de empezar. Eludir significa que el especialista no se queda en señalar un problema posible: intenta aprovecharlo, dentro de esos límites. Eso separa un pentest de un escaneo de vulnerabilidades, que informa lo que podría estar mal, y de un análisis, que puede añadir revisión manual y prioridades; comparamos ambos en análisis de vulnerabilidades o pentest. La definición original está en el glosario del NIST.

Tampoco es una certificación. El informe recoge lo que el equipo encontró en los sistemas evaluados durante el periodo de pruebas. No declara que un sistema sea seguro: una lista corta de hallazgos —los problemas de seguridad que identificó el equipo— describe lo que se encontró en esas condiciones, no que no hubiera nada más.

Tipos de pentest

Tres decisiones definen una prueba: el objetivo, la información que recibe el equipo y quién está avisado.

Según el objetivo

• Externo: los sistemas accesibles desde internet, como sitios web, servidores de correo y los portales de acceso remoto o VPN por los que entra su personal.
• Interno: lo que podría hacer alguien que ya está dentro de la red, por ejemplo desde el equipo de un empleado.
• Aplicaciones web y API: la lógica, los permisos y el manejo de datos de una aplicación concreta.
• Ingeniería social: cómo responden las personas y los procesos, por ejemplo ante un correo de phishing.

Según lo que sabe el equipo

• Caja negra: el equipo empieza con poca o ninguna información sobre el funcionamiento interno, como un atacante externo.
• Caja gris: recibe información parcial, como documentación o, si usted las facilita, cuentas de prueba; con cuentas puede probar lo que ve un usuario con sesión iniciada.
• Caja blanca: tiene acceso al código, la arquitectura o la configuración, lo que permite dedicar más tiempo a probar las funciones importantes.

Según quién está avisado

La guía de pruebas del NIST distingue la prueba abierta, que el equipo de TI conoce, de la encubierta, que se hace sin conocimiento del equipo de TI y con la autorización de la alta dirección. La encubierta muestra cómo responde la organización ante un ataque, pero no busca identificar cada vulnerabilidad, y la guía del NIST de 2008 la describe como más lenta y más costosa (NIST SP 800-115, sección 2.4.2). Acuerde el enfoque antes de empezar.

Cómo se define el alcance de un pentest

Acuerde el alcance con el equipo de pruebas: define qué sistemas y qué preguntas cubre la evaluación. En la fase de planificación que describe el NIST, el equipo de pruebas y su dirección acuerdan las reglas y los objetivos y dejan registrada la autorización; todavía no se prueba nada.

• Qué entra: dominios, rangos de IP, aplicaciones y API (las interfaces por las que otros programas se comunican con sus sistemas), cada uno con un responsable de su empresa.
• Qué queda fuera, y por qué: sistemas de terceros que usted no está autorizado a probar, y si se excluyen las pruebas de denegación de servicio: las que intentan dejar un sistema no disponible o inaceptablemente lento para sus usuarios legítimos, por ejemplo saturándolo.
• Cuándo: la ventana de pruebas y los horarios en que no se puede tocar producción.
• Con qué: cuentas de prueba para cada rol, documentación de la API y si se prueba en un entorno de pruebas o en producción.
• A quién llamar: un contacto técnico localizable si algo deja de responder, en qué casos se detienen las pruebas y cómo le llega un hallazgo urgente antes del informe.
• Con qué autorización: la autorización por escrito de la prueba y quién, de su parte, puede aprobar que se añada un objetivo una vez empezada.
• Qué pasa después: si incluye una nueva prueba para verificar las correcciones, y en qué plazo.

La lista de sistemas acordada puede estar incompleta. En cómo conciliar el perímetro declarado y el real contamos una prueba en la que, a las dos horas de empezar, la lista ya no coincidía con lo accesible desde internet.

Qué debe incluir el informe de un pentest

No hay un formato único obligatorio, pero las guías públicas coinciden en lo esencial. La guía de pruebas web de OWASP propone cuatro partes: introducción, resumen ejecutivo, hallazgos y anexos (OWASP WSTG v4.2, capítulo Reporting, en inglés). El NIST pide que los informes internos incluyan la metodología, los resultados, el análisis y un plan de acción con hitos (NIST SP 800-115, sección 8.2).

Introducción y alcance

Quién probó, cuándo, qué entraba en el alcance y qué no, y qué límites aparecieron en el camino. Revise esta sección antes de sacar conclusiones de un informe con pocos hallazgos: un acceso limitado, un entorno distinto al de producción o áreas que quedaron sin probar cambian lo que cubre el resultado.

Resumen ejecutivo

Una parte breve para la dirección: qué preguntas debía responder la evaluación, los hallazgos principales en lenguaje claro y los próximos pasos recomendados. Quien lea solo esta sección debería saber si hay que actuar, y dónde.

Cada hallazgo

Cada hallazgo debería incluir:

• un identificador y un título claro;
• el sistema o la función afectada;
• su gravedad, y cómo se calculó;
• evidencia: las solicitudes y respuestas, capturas de pantalla y los pasos para reproducirlo;
• el impacto en términos de negocio, no solo técnicos;
• una recomendación lo bastante concreta para actuar;
• si se confirmó, y cómo: explotándolo, inspeccionando una configuración o revisando el código.

Un hallazgo no termina con la entrega del informe. Asigne a cada uno un responsable de su empresa y una fecha objetivo, acuerde si las correcciones se volverán a probar y cuándo, y deje registrado qué queda sin resolver y por qué. Si el informe se lo pidió un cliente, acuerde con el equipo de pruebas qué versión recibe: un resumen del alcance y de los resultados suele ser más adecuado que el documento técnico completo, que contiene evidencia reproducible.

Los informes pueden expresar la gravedad con CVSS, el sistema común de puntuación de vulnerabilidades. Su versión actual, la 4.0, la publicó FIRST en noviembre de 2023, y su guía de usuario advierte que la puntuación base "está diseñada para medir la severidad de una vulnerabilidad y no debe usarse sola para evaluar el riesgo" (guía de usuario de CVSS v4.0, en inglés). Un buen informe explica por qué un hallazgo importa en su entorno, no solo su número.

Metodología, límites y anexos

Cómo se hizo la prueba, cómo se definen los niveles de gravedad y, cuando ayuda, los resultados pertinentes de las herramientas, depurados y con los datos sensibles ocultos, para que alguien pueda reproducir un hallazgo. Los anexos reúnen el material técnico que respalda los hallazgos.

Cómo se ve un informe breve

Un ejemplo ficticio, para ver cómo encajan las partes. No corresponde a un servicio real ni es una muestra de nuestros informes.

• Alcance y limitaciones: el portal de clientes portal.ejemplo.com y la API de facturas que hay detrás, probados entre el 3 y el 7 de marzo desde una dirección acordada. El proveedor de pagos quedó fuera del alcance y dos funciones de administración no se pudieron alcanzar con las cuentas facilitadas.
• Resumen ejecutivo: un hallazgo confirmado permite que un cliente con sesión iniciada lea las facturas de otro; dos hallazgos menores afectan al cierre de sesión y a un componente desactualizado. El primero debería corregirse antes de la próxima versión.
• Resumen de hallazgos: H-07 alta, H-11 media, H-14 baja, cada uno con la función afectada, un responsable de la empresa cliente y una fecha objetivo.
• Un hallazgo completo: presentado como el ejemplo H-07 anterior.
• Nueva prueba: las correcciones se verificaron el 28 de marzo. H-07 y H-11 quedaron confirmadas como corregidas; H-14 se aceptó como riesgo, con el motivo registrado.

Qué preguntar sobre el informe

1. ¿Se probó todo lo que estaba en el alcance, y qué no se pudo probar?
2. ¿Qué hallazgos están confirmados con evidencia y cuáles son sospechas?
3. ¿Hay una ruta de ataque, es decir, hallazgos que juntos llevan más lejos que cada uno por separado?
4. ¿Qué se corrige primero, y quién lo hace: su equipo, su proveedor o un tercero?
5. ¿Cómo va a comprobar que las correcciones funcionaron?

Señales de un informe débil

• La salida de un escáner con otro logotipo: cientos de líneas y ninguna evidencia manual.
• Niveles de gravedad copiados de la herramienta sin contexto; el NIST recomienda que el evaluador fije el nivel de riesgo (SP 800-115, sección 4.3).
• Hallazgos sin pasos para reproducirlos.
• Ninguna mención de los límites ni de lo que quedó fuera.
• Recomendaciones genéricas, como "aplicar parches" o "reforzar la seguridad".

Qué entrega un pentest de IntruForce

En los servicios de pentesting de IntruForce (Expert Services), un pentest se hace dentro de un alcance acordado y puede centrarse en su perímetro externo, en sistemas internos seleccionados o en activos concretos críticos para el negocio. Usted recibe un informe con hallazgos confirmados, evidencia de las rutas de ataque relevantes, una explicación de su posible impacto y recomendaciones priorizadas para corregirlos.

Si está preparando uno, cuéntenos qué necesita proteger o verificar en el formulario de la página de servicios. Nuestro equipo le responde por correo para aclarar qué quiere comprobar con la prueba y acordar el alcance. Enviar la solicitud no le obliga a contratar un servicio, y las pruebas que interactúan con sus sistemas se acuerdan por separado.