Cómo leer el informe de una prueba de penetración

El informe es la parte de una prueba de penetración que se queda con usted cuando los auditores se marchan. Leerlo bien significa corregir primero lo correcto y sacar verdadero partido de la verificación posterior. También le ayuda a detectar un «pentest» que en realidad era un escaneo automatizado con una portada.

Qué contiene un buen informe

La OWASP Web Security Testing Guide describe una estructura de informe que sirve como buena referencia. Cada parte se dirige a un lector distinto, y la guía sugiere que las secciones puedan imprimirse por separado para los equipos que las necesiten.

Lea con atención la sección de limitaciones. Si los bloqueos de cuentas detuvieron las pruebas, o si un servidor quedó fuera del alcance el segundo día, el informe debe decirlo. Un resultado limpio en un área que nunca se probó no le dice nada.

El National Cyber Security Centre (NCSC) del Reino Unido añade dos elementos que es fácil pasar por alto. Un buen informe da la opinión de los auditores sobre la precisión de su propia evaluación de vulnerabilidades y consejos para mejorar ese proceso.

Anatomía de un buen hallazgo

Cada hallazgo debe permitir que un técnico que no haya participado en el proyecto entienda el problema, lo reproduzca y lo corrija. Busque:

• un identificador único y un título claro
• una valoración de la gravedad, con el vector CVSS cuando se usa CVSS
• los activos afectados exactos, como hosts, URL, parámetros o roles
• una descripción de la debilidad y de por qué importa para su negocio
• evidencias, como peticiones y respuestas, capturas de pantalla o la salida de comandos
• los pasos para reproducirlo
• recomendaciones de corrección concretas, con referencias como un aviso del fabricante

Este es un ejemplo resumido de cómo se ve en la práctica:

ID        AF-07  Invoice download does not check ownership
Severity  Medium  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (6.5)
Affected  GET /api/v1/invoices/{id}/pdf on portal.example.eu
Evidence  Logged in as customer A, a request for invoice 10452
          (customer B) returned customer B's PDF.
Impact    Any customer can download other customers' invoices,
          including names, addresses and amounts.
Fix       Check on the server that the invoice belongs to the
          logged-in customer for every request.
Retest    Request another customer's invoice and expect 403 or 404.

(En el ejemplo, la descarga de facturas no comprueba a quién pertenece la factura: cualquier cliente puede descargar las de otros.) El vector permite ver por qué la puntuación es media: la confidencialidad se ve afectada, pero la integridad y la disponibilidad no. También le permite discrepar con buenos motivos. Como las facturas contienen datos personales, podría decidir que merece una prioridad mayor de la que sugiere la puntuación.

Cómo se valoran los hallazgos

Muchos informes valoran los hallazgos con el Common Vulnerability Scoring System (CVSS) que mantiene FIRST, y el NCSC lo incluye entre los sistemas de valoración que puede solicitar. CVSS v3.1 y v4.0 usan los mismos tramos cualitativos:

Hay tres cosas que conviene tener en cuenta al leer estas valoraciones:

• La puntuación base mide la gravedad, no su riesgo. FIRST la describe como reflejo de las características intrínsecas de la vulnerabilidad en un peor caso razonable, e indica que los usuarios deben completarla con información sobre su propio entorno.
• La gravedad es un dato de entrada. La guía de OWASP recomienda que el resumen ejecutivo lo diga de forma explícita: la valoración alimenta su proceso de gestión de riesgos, no lo sustituye.
• Los auditores no conocen el contexto de su negocio. El NCSC aconseja que evalúe usted mismo los hallazgos, porque las valoraciones pueden ser demasiado altas o demasiado bajas. También advierte de que no se use esto como forma de restar importancia a los problemas.

Qué corregir primero

1. Todo lo que se pueda explotar desde internet sin iniciar sesión, sobre todo si permite ejecutar código, acceder a datos u obtener control administrativo.
2. Cadenas de ataque. Un buen informe muestra cómo varios hallazgos de menor gravedad se combinan en uno grave. NIST SP 800-115 señala que los escáneres no pueden detectar las debilidades que solo aparecen cuando se combinan vulnerabilidades. Encontrar estas cadenas es buena parte de lo que aporta un auditor humano.
3. Los sistemas que guardan las llaves, como los proveedores de identidad, los servidores de copias de seguridad, las pasarelas de acceso remoto y todo lo que trate datos personales.
4. Mejoras rápidas. A veces un solo cambio de configuración cierra varios hallazgos a la vez.
5. Causas raíz. NIST recomienda analizar las causas raíz tras una evaluación, porque los resultados pueden señalar procesos débiles además de sistemas débiles. Cinco parches que faltan en cinco servidores son un solo hallazgo sobre la gestión de parches, no cinco problemas sin relación.

El NCSC plantea la prueba de penetración como un control de su propia gestión de vulnerabilidades, no como la vía principal para encontrarlas. En sus palabras, los nuevos descubrimientos «deberían ser la excepción, no la regla». Si el informe le sorprende, eso también dice algo de sus procesos internos.

La verificación posterior

Acuerde la verificación (retest) al firmar el contrato, incluido lo que abarca y de cuánto tiempo dispone antes para corregir. Pida los resultados como un informe actualizado o un anexo, con el estado de cada hallazgo: corregido, corregido en parte, sin corregir o riesgo aceptado.

Una verificación confirma correcciones concretas. No es una prueba nueva. El NCSC recuerda que una prueba solo muestra el estado de sus sistemas el día en que se hizo, y que es habitual que pase un año o más entre pruebas. Siga haciendo comprobaciones entre medias.

Señales de alarma en un «pentest» barato

El escaneo automatizado tiene su lugar, y NIST SP 800-115 lo trata como una de las técnicas de evaluación estándar. También señala que los escáneres pueden tener una alta tasa de falsos positivos y necesitan a alguien con los conocimientos adecuados para interpretarlos. El problema empieza cuando la salida de un escaneo sin revisar se vende como prueba de penetración. Son señales de alarma:

• hallazgos con textos genéricos copiados y sin evidencias de que alguien los haya confirmado
• decenas de elementos de bajo impacto sobre banners y cifrados TLS, pero nada sobre control de acceso, autenticación o lógica de negocio, que necesitan a una persona para probarse
• gravedades tomadas directamente de la herramienta; NIST indica que los evaluadores deben fijar ellos mismos el nivel de riesgo en lugar de aceptar las valoraciones del escáner
• ninguna sección de alcance, metodología o limitaciones
• ningún paso para reproducir los problemas, de modo que su equipo no puede verificar una corrección
• ningún auditor identificado ni cualificación declarada; el NCSC indica que las pruebas solo deben hacerlas profesionales cualificados y con experiencia
• una «verificación» que consiste simplemente en volver a lanzar el mismo escaneo

Por dónde empezar

Antes de su próxima prueba, pregunte al proveedor:

• ¿Qué entra exactamente en el alcance y qué queda excluido?
• ¿Tendrán los auditores cuentas para cada rol de usuario que quiera cubrir?
• ¿Puede ver un informe de ejemplo anonimizado?
• ¿Cómo se valoran los hallazgos? ¿Incluirá cada uno un vector CVSS?
• ¿Se incluye la verificación posterior y en qué plazo?

Si está planificando una prueba y quiere hablar antes del alcance, consulte nuestro servicio de pruebas de penetración.