Seguridad ofensiva
De un pentest no te llevas "un ataque": te llevas un informe. Es lo único que queda cuando el proveedor se va, y es justo donde se nota la diferencia entre un trabajo serio y un escaneo con la portada cambiada. Esto es lo que no puede faltar, contado desde las dos sillas: la de quien ataca y la de quien luego lo audita.
Lo contábamos al explicar la diferencia entre un pentest y un análisis de vulnerabilidades: dentro de la palabra "pentest" caben trabajos muy distintos. Y el sitio donde esa diferencia se ve de golpe no es la prueba, es el entregable. Por eso, cuando alguien nos pide una segunda opinión sobre una oferta, lo primero que miramos es un informe de ejemplo. Un buen informe no abulta: prioriza, demuestra y te dice qué hacer.
Un apunte que ordena todo lo que viene: además de ejecutar pentests, auditamos sistemas de gestión ISO 27001 y ENS. Vemos el informe por las dos caras, la del atacante que lo escribe y la del auditor que después decide si sirve como evidencia.
La primera página tiene que entenderla tu dirección sin saber de seguridad: qué se probó, qué se encontró, cuál es el riesgo para el negocio y qué hace falta. Sin jerga, sin CVE sueltos. Si el informe empieza con una tabla de puertos, no está pensado para quien toma la decisión.
Qué entró y qué no, con qué metodología (OWASP, PTES o equivalente) y bajo qué reglas: qué se podía explotar, qué solo documentar, en qué ventanas. Esto no es relleno: es lo que hace el informe repetible y defendible, y lo que un auditor necesita para dar por válido el trabajo.
Un CVSS alto en un sistema que nadie usa importa menos que uno medio en tu facturación. Un buen informe combina la severidad técnica con el contexto de tu negocio y te ordena los hallazgos por el riesgo que de verdad corres. Veinte "críticas" sin contexto son una lista; cinco priorizadas son un plan.
Cada hallazgo debe traer la prueba: capturas, peticiones, los pasos para reproducirlo y hasta dónde se llegó. No "el login es vulnerable", sino "con este fallo, por este camino, se llega a estos datos". Esa narrativa de ataque es lo que distingue el trabajo manual del volcado de una herramienta, y lo que convierte el informe en evidencia creíble.
Para cada hallazgo: qué hay que hacer, quién debería hacerlo (tu equipo, tu proveedor de IT, el fabricante) y una idea del esfuerzo. Recomendaciones concretas, no "aplicar buenas prácticas". Si la remediación no se entiende, nadie la ejecuta y el pentest no sirve de nada.
El informe debe terminar con un orden de trabajo: por dónde empezar la semana que viene con el presupuesto y el equipo que tienes. Aquí es donde un proceso de gestión de vulnerabilidades y parches hace que lo corregido no se vuelva a abrir.
Cuando corriges, el proveedor vuelve a probar lo arreglado y lo confirma por escrito. Un pentest sin retest te deja con los deberes hechos pero sin la nota final: no puedes demostrar que el agujero quedó cerrado. Pregúntalo antes de firmar, no después.
Si ves esto, desconfía:
Aquí entra la segunda silla. Cuando audito una ISO 27001 o un ENS, un informe de pentest es de las evidencias que menos discusión generan… si está bien hecho. Un escaneo de 600 euros presentado como test de intrusión no pasa como evidencia: no demuestra que se haya probado la eficacia de los controles, que es justo lo que piden ISO 27001 (control 8.29), el ENS y NIS2.
Por eso el informe que de verdad te sirve es el que un atacante escribe con rigor y un auditor acepta sin peros: alcance claro, hallazgos con evidencia, remediación y retest. Lo mismo que necesitas para estar seguro, lo necesitas para demostrarlo.
Te enseñamos un informe de ejemplo anonimizado para que compares, y te decimos qué alcance necesitas de verdad para que las ofertas te lleguen comparables. Sin compromiso.
Solicitar una propuestaO escríbenos a [email protected].
Las que hagan falta, ni una más. Importa la calidad, no el grosor: un buen informe prioriza y va al grano. Si son doscientas páginas sin un orden claro de qué arreglar primero, es mala señal, no buena.
Que trae la prueba: los pasos para reproducirlo, capturas o evidencias, la ruta de ataque y el impacto real de negocio, además de una recomendación de remediación concreta. "Esto es vulnerable" no es un hallazgo; "con esto he llegado aquí, así se cierra" sí lo es.
Sí, si está bien hecho: con alcance, metodología, evidencias de explotación y, a ser posible, retest. Un escaneo automático presentado como pentest no suele pasar como evidencia ante un auditor, porque no demuestra que se haya probado la eficacia de los controles.
Debería, y muchas veces no lo está. Pregúntalo antes de firmar. Un retest dentro de los 60 o 90 días siguientes es lo razonable: da tiempo a corregir y deja por escrito que el fallo quedó cerrado.
