Un pentest mal dimensionado no sale barato: sale inútil
Por Kike Gandia · Amenazas · 8 min de lectura
Dos empresas nos escriben la misma semana con la misma frase: «necesitamos un pentest de nuestra aplicación». Una acaba con un informe de once hallazgos, tres de ellos críticos, que cambia su plan de producto del trimestre. La otra acaba con un PDF de cuarenta páginas lleno de avisos de cabeceras HTTP que nadie va a leer. El equipo que lo hizo era igual de bueno en los dos casos. Lo que cambió fue el alcance: qué se puso encima de la mesa, con qué acceso y sobre qué entorno.
Esto no es un detalle administrativo previo al trabajo de verdad. El alcance es el trabajo: decide qué se puede encontrar y qué es literalmente imposible que aparezca en el informe. Y casi siempre se decide deprisa, por correo, antes de que nadie haya hecho las preguntas que importan.
Qué demuestra en realidad un pentest
Conviene decirlo pronto porque ordena todo lo demás: unas pruebas de intrusión no acreditan que un sistema sea seguro. Acreditan que un equipo con un tiempo acotado, unos accesos concretos y unas reglas pactadas encontró —o no encontró— determinadas cosas en una ventana de fechas. Es una foto, no un certificado de salud.
Eso, lejos de restarle valor, es justo lo que lo hace útil: convierte una discusión abstracta sobre riesgo en una lista de cosas concretas que alguien reprodujo en vuestros sistemas. La diferencia entre «habría que revisar los permisos» y «con la cuenta de un usuario de soporte se accede a los expedientes de cualquier cliente, aquí está la captura» es lo que mueve presupuestos y prioridades.
Un escaneo automático no hace eso. Encuentra patrones conocidos y te los enumera; es barato, es rápido y hay que hacerlo, pero no distingue lo explotable de lo teórico ni entiende vuestra lógica de negocio. La mayoría de los hallazgos que importan de verdad —saltarse un flujo de aprobación, ver los datos de otro cliente, encadenar dos fallos menores hasta llegar a administrador— solo aparecen cuando una persona entiende para qué sirve la aplicación.
Las cinco decisiones que cambian el resultado
A igualdad de proveedor y de presupuesto, estas son las variables que de verdad determinan qué recibís:
- Qué entra y qué no. No es lo mismo «la web» que la web, su API, el panel de administración y el proveedor que la aloja. Lo que queda fuera del alcance no se prueba, aunque sea por donde entraría un atacante real.
- El volumen real. Lo que dimensiona una aplicación no son las pantallas: son los roles distintos y los flujos de negocio. Una aplicación con cuatro perfiles y multicliente es varias veces el trabajo de una con un único tipo de usuario, aunque tengan el mismo aspecto.
- Con cuánta información se trabaja. Caja negra, gris o blanca. Es la decisión que más se toma por inercia y la que más rendimiento cambia por euro invertido.
- Sobre qué entorno. Preproducción representativa, producción con restricciones o nada parecido a un laboratorio. Condiciona qué pruebas se pueden ejecutar y a qué ritmo.
- Qué hay que entregar y para quién. Un informe técnico para el equipo de desarrollo, un ejecutivo para el consejo y una carta de atestación para un cliente son tres productos distintos con tres costes distintos.
Caja negra, gris o blanca: el error más caro
Muchas organizaciones piden caja negra por un motivo razonable: quieren saber qué vería un atacante de fuera, sin ayudas. Es una pregunta legítima, pero suele responderse a un precio que no se ve en la factura.
En caja negra, buena parte de las horas se van en reconstruir desde fuera lo que la organización ya sabe: qué endpoints existen, qué roles hay, cómo se llaman las cosas. Ese tiempo no se dedica a buscar fallos. El resultado es un informe más corto en menos tiempo útil, y una factura por hallazgo bastante más alta.
| Modalidad | Qué se entrega al equipo | Cuándo tiene sentido |
|---|---|---|
| Caja negra | Nada más que un objetivo | Validar la exposición externa o medir la capacidad de detección del equipo defensivo |
| Caja gris | Credenciales de cada rol y documentación básica | La opción por defecto para casi todo: cubre más superficie en el mismo tiempo |
| Caja blanca | Credenciales, documentación y código fuente | Producto crítico, evidencia regulatoria o cuando interesa la causa raíz, no solo el síntoma |
Para evidencia regulatoria —NIS2, ENS, el expediente técnico del Cyber Resilience Act o un cuestionario de cliente— la caja gris o blanca rinde mucho más: lo que se pide no es simular a un atacante, es demostrar que el producto se ha examinado en serio.
Probar sobre producción cuesta más de lo que parece
Cuando no hay preproducción representativa, las pruebas acaban en producción. Se puede hacer, y se hace a menudo, pero tiene un precio: ventana acordada, alguien localizable durante toda la ejecución, criterio de parada por escrito, exclusión expresa de las pruebas de denegación de servicio y ritmo deliberadamente lento. Todo eso son horas.
Hay un caso en el que directamente no se negocia: los entornos industriales en servicio. Sobre autómatas que están gobernando un proceso real no se hacen pruebas activas. Sin réplica ni ventana de parada, el trabajo honesto se limita a revisión pasiva y de configuración — y eso hay que pactarlo antes de firmar, no descubrirlo a mitad del proyecto.
Si el entorno tiene datos personales reales, hay que formalizar el encargo de tratamiento antes de empezar y limitar el acceso al mínimo. Demostrar el acceso es suficiente: nunca hace falta extraer datos reales como evidencia.
Los errores que vemos una y otra vez
- Contratar sin cerrar el incidente. Si hay una intrusión abierta o sospecha de ella, lo que toca es contención y forense. Un pentest sobre un entorno posiblemente comprometido mezcla vuestros hallazgos con la actividad del atacante y no sirve a ninguno de los dos fines.
- Repetir campaña con los hallazgos anteriores abiertos. Si quedan cosas importantes sin corregir, la nueva campaña va a encontrar lo mismo. Habréis pagado dos veces por el mismo informe.
- Pedir una campaña completa cuando os exigen una carta. Muchas licitaciones y clientes se conforman con una atestación con alcance y fechas. Conviene leer la exigencia literal antes de dimensionar nada: es el entregable más barato de producir.
- Olvidar a los terceros. Si un activo está alojado o fabricado por otro, hará falta también su autorización, y conseguirla os corresponde a vosotros. Es lo que más retrasa el arranque de estos trabajos.
- No reservar presupuesto para la reprueba. Un informe sin verificación de cierre deja la pregunta importante sin responder: ¿se corrigió de verdad? La reprueba es barata comparada con la campaña y es la que convierte el informe en una mejora real.
- Ejercicios con personas sin respaldo formal. El phishing simulado se acuerda antes con dirección y, si procede, con la representación de los trabajadores: sin nombres en el informe y sin consecuencias disciplinarias. Si no, deja de ser un ejercicio técnico y pasa a ser un problema laboral.
Por qué esto importa ahora más que hace tres años
Durante mucho tiempo las pruebas de seguridad fueron una decisión voluntaria de equipos concienciados. Hoy llegan por tres vías que no dependen de la voluntad de nadie: la regulación (NIS2 y sus obligaciones de gestión de riesgos, el ENS en el sector público, el CRA para productos con elementos digitales), la cadena de suministro (vuestro cliente os audita porque a él lo auditan) y el seguro y la diligencia debida en cualquier operación corporativa.
El efecto práctico es que el informe ya no se queda dentro. Lo va a leer un cliente, un auditor, un regulador o alguien que está decidiendo una inversión. Eso cambia lo que hay que exigirle: alcance escrito sin ambigüedades, metodología reconocible, evidencia reproducible y una declaración honesta de qué no se probó.
Cómo dimensionarlo sin perder tres llamadas
Casi todo lo anterior se resuelve con una docena de datos concretos: qué activos entran, cuántos hay de cada tipo, qué accesos podéis facilitar, sobre qué entorno se trabaja, qué está expresamente prohibido y qué documento necesitáis al final. Con eso se puede dimensionar en serio; sin eso, cualquier presupuesto es una estimación a ciegas que se corrige al alza a mitad del proyecto.
Para no tener que descubrirlo en una llamada hemos publicado esa conversación en forma de formulario: la ficha de alcance de pentesting recorre esos bloques y solo enseña las preguntas que os aplican según los activos que marquéis — quien solo tiene una aplicación web responde tres bloques, no diez. Al terminar genera una lectura preliminar con las señales de alerta que hayan salido (incidente abierto, pruebas sobre producción, hallazgos anteriores sin cerrar, activos de terceros) y podéis enviárnosla o quedárosla.
Si lo que buscáis es solo una cifra orientativa antes de hablar con nadie, la calculadora de pentesting da un rango de mercado en menos de un minuto. Y si preferís que alguien revise el alcance con vosotros antes de decidir qué entra y qué no, para eso está nuestro equipo: media hora bien aprovechada al principio ahorra semanas después.
Servicio relacionado
Temas de este artículo
#Pentesting #Auditoría-de-seguridad #Red-Team #Cumplimiento #NIS2 #Gestión-de-vulnerabilidades