Nos dieron un informe de pentest de 40 páginas; ¿hay algún informe de ejemplo para comparar?

Si el informe no tiene evidencias de explotación, esa prueba no se hizo. Por ejemplo, si dicen que encontraron una inyección SQL, tienen que mostrar paso a paso cómo extrajeron datos inofensivos de la base de datos. No pueden limitarse a poner la alerta del escáner y seguir de largo.

A nosotros nos pasó lo mismo hace dos años por 2.500 libras. El auditor de seguridad de nuestro cliente rechazó el informe en cuanto lo vio y dijo que no era un pentest sino un simple escaneo de vulnerabilidades. Tuvimos que volver a hacerlo con otro experto.

3.500 libras en el mercado del Reino Unido es un presupuesto bastante ajustado para un test manual completo. Por ese precio normalmente corren la herramienta y te imprimen el reporte. Un test real requiere al menos 3-5 días/hombre de trabajo manual y eso se refleja en la factura.

Devuelvan el informe a la empresa y exijan dos cosas: un resumen de riesgo e impacto de una página para la gerencia, y pasos concretos para que su equipo de desarrollo pueda verificar las correcciones. Si en su contrato figura la cláusula de prueba manual, están obligados a corregirlo.

¿Cómo figura exactamente el tipo de prueba en su contrato de servicios? ¿Escaneo de vulnerabilidades o prueba de penetración? Lamentablemente en el sector se confunden mucho estos dos servicios y si en el contrato dice escaneo de vulnerabilidades les va a costar reclamar.

no se dejen engañar para nada por el número de páginas. pues un informe imppecable de 15 páginas, escrito a mano y al grano vale diez veces más que un reporte automático de 80 páginas sacado de un escáner.

Les conviene pedirle a su proveedor de seguridad que revise el informe antes de enviárselo directamente a su cliente corporativo. Un auditor corporativo con experiencia notará de inmediato que es una salida de escaneo automático y eso perjudicará su credibilidad.

Corrección: recordaba mal la cifra, era un poco más baja.

Para auditar el informe que tienen, miren estos tres puntos: 1) ¿Se filtraron los falsos positivos o metieron cualquier alerta? 2) ¿Las puntuaciones de riesgo están adaptadas a su contexto de negocio? 3) ¿Su desarrollador entiende cómo corregir el código al leerlo?

Tema muy oportuno.

Tiene razón.

rara vez se encueentra un texto que lo explique tan claro.

Soy una pequeña empresa, os lo cuento desde mi lado. La respuesta varía mucho según el sector, no hay una regla general.

Lo dejo como nota, por si sirve.

Gracias, me ha servido de mucha ayuda. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Es correcto en general, pero falta un detalle. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Todos los que se apresuran con informe de pentest se atascan en el mismo punto.

En teoría es correcto, pero en la práctica no funciona así. El tiempo que tardas en detectar un problema determina directamente su coste.

Por supuesto, cambia si tu situación es diferente.

Estoy de acuerdo.

Después de vivir eso, mi perspectiva cambió. Si regañas las falsas alarmas, nadie volverá a reportar.

Yo también estaba pensando en lo mismo. Un informe de escaneo automático no es lo mismo que una prueba de penetración.