Un pentest mal dimensionado no sale barato: sale inútil

Por Kike Gandia · Amenazas · 14 min de lectura

Ilustración de un equipo de pruebas de seguridad delimitando sobre un plano qué sistemas entran en el alcance de una auditoría

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 cinco decisiones determinan qué recibís. Ninguna es técnica: las cinco se toman antes de que nadie abra una terminal.

Las cinco decisiones que fijan el alcance de unas pruebas de seguridad, con lo que cuesta acertar y equivocarse en cada una: (1) qué activos entran y cuáles quedan excluidos por escrito; (2) el volumen real, que lo marcan los roles y los flujos de negocio, no el número de pantallas; (3) con cuánta información se trabaja —caja negra, gris o blanca—, donde la caja gris rinde más por euro invertido; (4) sobre qué entorno se prueba, porque producción obliga a ventana acordada, criterio de parada y ritmo lento; y (5) qué entregable hace falta y para quién, ya que a veces basta una carta de atestación en lugar de una campaña completa. Las cinco se responden en la ficha de alcance de pentesting, en /recursos/ficha-alcance-pentesting/.

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ó.

Un alcance se decide mirando fuera, no solo dentro

Hasta aquí todo mira hacia dentro: vuestros activos, vuestros accesos, vuestro entorno. Falta la otra mitad de la pregunta, que casi nunca se hace: ¿por dónde están entrando ahora mismo en empresas como la vuestra? Sin ese dato, el alcance se decide por intuición o por lo que se hizo el año pasado.

Nosotros esa mitad la resolvemos con datos propios. CyberPanorama es el módulo de ciberseguridad de 0data, nuestro panel autónomo: varios agentes coordinados recogen y cruzan más de 600 fuentes para mantener un modelo de amenazas vivo, en tiempo real, en vez de un informe trimestral que ya nace viejo. Correlar, medir y predecir, que es lo que permite avisar a un cliente antes y no después.

Red de amenazas de CyberPanorama, el módulo de ciberseguridad de 0data: 1,1 millones de señales correlacionadas en una ventana de 30 días a partir de fuentes como PhishTank (789.000), Phishing Army (179.000), IOCs (45.000), agregadores de inteligencia (16.000), reconocimiento (10.445), OpenPhish (15.000), Exploits DB (3.038), Ransomware Live (2.476), vulnerabilidades (748) y técnicas MITRE (714), con un nivel de riesgo global ALTO (66/100). La proyección a 24 horas estima 838.000 señales, repartidas en phishing (90,5%), IOCs y URLs maliciosas (5,6%), reconocimiento (1,8%), dark web y DeFi (0,9%), sanciones OFAC (0,5%) y vulnerabilidades (0,3%). Instantánea de la ventana cerrada el 17 de septiembre de 2026.

Ese reparto cambia conversaciones. Si nueve de cada diez señales del último mes son phishing, discutir si el pentest web dura ocho o diez días es optimizar el sitio equivocado: lo que toca mirar primero es el correo y las personas. Y al revés: cuando el panel enseña movimiento en un sector concreto, el alcance de sus empresas deja de ser una plantilla y pasa a ser una decisión informada.

Cobertura de la cadena de ataque MITRE ATT&CK según CyberPanorama, con 889 técnicas observadas: sigilo (148), persistencia (113), escalada de privilegios (96), acceso a credenciales (67), ejecución (64), degradar defensas (56), desarrollo de recursos (50), descubrimiento (49), reconocimiento (46), mando y control (45), recolección (41), impacto (33), movimiento lateral (23), acceso inicial (22), exfiltración (19) y evasión de defensas (17). Las fases más pobladas son las posteriores a la intrusión, no el perímetro. Víctimas de ransomware por sector en 30 días: industria y fabricación (174), servicios profesionales (120), tecnología (116), sanidad (102), otros (93), retail y e-commerce (65), servicios financieros (57), transporte (45) y agroalimentario (38).

Fíjate en dónde se acumulan las técnicas: sigilo, persistencia y escalada de privilegios. Todo eso ocurre después de que alguien haya entrado. Un alcance que se queda en el perímetro no toca ninguna de las tres, y es exactamente el alcance que se contrata por defecto cuando nadie ha mirado los datos.

La diferencia entre seguridad reactiva y proactiva no es tener más herramientas: es que alguien esté mirando el panorama de forma continua y pueda decirte qué cambió esta semana en tu sector. Lo demás es esperar a que te toque.

El informe no es el final: ¿dónde vive lo que encontramos?

Volvamos al error más caro de la lista de antes, el de no reservar presupuesto para la reprueba. En realidad es el síntoma de algo más grande: el informe se entrega y se acaba el sistema. A partir de ahí, un PDF por correo, un Excel de seguimiento que alguien mantiene a mano, un hilo de mensajes por cada duda y, tres meses después, nadie sabe decir con certeza qué se corrigió y qué no.

Ese vacío es el que cubre KOMPLIANCE, el módulo de gestión de vulnerabilidades de 0data. No es un visor de informes: es donde el hallazgo tiene dueño, plazo, estado y una verificación que lo cierra.

Tablero de hallazgos de KOMPLIANCE, el gestor de vulnerabilidades de 0data, con datos de ejemplo: recuento por severidad (3 críticas, 11 altas, 24 medias, 38 bajas) y una tabla donde cada hallazgo lleva identificador, severidad, origen (pentest manual, auditoría de código, SCA sobre el SBOM, agente autónomo, SAST, escáner o control de licencias), responsable asignado, estado (abierto, en corrección, en reprueba o cerrado) y plazo de SLA restante. Desde el mismo tablero se exportan el informe técnico, el informe ejecutivo y el SBOM.

Fíjate en la columna de origen. Un hallazgo puede venir del pentest manual, de una herramienta de hacking integrada, de un agente autónomo que sigue barriendo entre campañas, de la auditoría del código sobre el repositorio conectado o del control de licencias del SBOM. Son fuentes distintas que en la práctica encuentran cosas que se solapan, y el valor está en que el mismo fallo visto por tres vías se trate como un hallazgo y no como tres tareas abiertas para el mismo equipo.

Diagrama del flujo de KOMPLIANCE. Entradas: pentest manual con su evidencia, herramientas de hacking integradas sin copiar y pegar salidas, agentes autónomos que barren de forma continua entre campañas, auditoría de código sobre el repositorio conectado, e inventario SBOM con control de licencias. Núcleo: deduplicado y correlación entre fuentes, asignación de severidad, responsable y SLA, ciclo de reprueba obligatorio para cerrar, y trazabilidad completa de quién vio qué y cuándo. Salidas: informe técnico con evidencia y pasos de reproducción, informe ejecutivo en términos de negocio, tareas en Jira, alimentación del SIEM con lo explotable, y avisos en Slack y Telegram. Ventajas: sin ficheros sueltos por correo, acceso directo al equipo técnico que encontró el fallo, menos horas de gestión y de reuniones de seguimiento, y reprueba trazable en lugar de un "ya está arreglado".

Lo que cambia en el día a día es menos vistoso que un hallazgo crítico, pero pesa más en el resultado: desaparecen los ficheros dando vueltas —el informe deja de ser un adjunto que se reenvía y pasa a ser un estado consultable—, el equipo de desarrollo tiene acceso directo a quien encontró el fallo en lugar de escribir a una cuenta genérica, y la reprueba deja de depender de que alguien se acuerde. Menos horas de gestión, menos reuniones de seguimiento y una respuesta fiable a la única pregunta que importa tres meses después: ¿esto está cerrado o no?

Y para el lado regulatorio, el mismo sitio resuelve lo que suele ir por separado: SBOM completo, control de licencias de cada componente y exportación de informe técnico y ejecutivo cuando un cliente, un auditor o un regulador los pide. Que es exactamente lo que el artículo 14 del CRA, NIS2 o un cuestionario de cliente acaban exigiendo, con plazos, a quien no lo tiene ordenado.

Aquí lo hemos contado solo en la parte que toca a un pentest. Si quieres verlo entero —las integraciones con Nessus, Nuclei, Burp o Black Duck, el embudo de triaje, el cruce del SBOM contra el catálogo KEV de CISA, los módulos de ISO 27001, CRA y ENS, y la reprueba por superficie— está en KOMPLIANCE: un solo sitio para las vulnerabilidades y el cumplimiento.

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

servicio de pentesting

Temas de este artículo

#Pentesting #Auditoría-de-seguridad #Red-Team #Cumplimiento #NIS2 #Gestión-de-vulnerabilidades #Threat-Intelligence #0data

Seguir leyendo

Dimensionar nuestras pruebas con un experto