"Ya hacemos escaneo de vulnerabilidades, así que no necesitamos pentest." La frase es común y parte de un malentendido: las dos actividades responden a preguntas distintas. El escaneo pregunta qué fallas conocidas existen en mi entorno. El pentest pregunta qué puede hacer un atacante con ellas. Confundirlas lleva a pagar por una prueba innecesaria o a confiar en un informe automático que nunca probó nada.
Qué hace cada uno
El escaneo de vulnerabilidades es un barrido automatizado. Una herramienta identifica activos, servicios y versiones y compara lo que encuentra con bases de vulnerabilidades conocidas y con verificaciones de configuración. Es rápido, repetible y barato por ejecución, lo que permite ejecutarlo con frecuencia y sobre todo el parque. La contrapartida está en sus límites: señala la posibilidad de una falla, genera falsos positivos y prácticamente no ve errores de lógica de negocio, fallas de autorización entre usuarios ni combinaciones de pequeñas debilidades que, juntas, abren camino a un ataque.
El pentest (prueba de penetración) es un ejercicio conducido por personas, con alcance y reglas acordados, que simula a un atacante real. Los evaluadores usan herramientas, incluidos escáneres, pero el núcleo del trabajo es manual: validar si la falla es explotable, encadenar hallazgos, intentar escalar privilegios y mostrar hasta dónde llegaría un intruso. La guía técnica del NIST para pruebas de seguridad, la SP 800-115, hace exactamente esta distinción: el escaneo identifica vulnerabilidades potenciales; la prueba de penetración valida si existen y cuál es su impacto.
En una frase. El escaneo aporta amplitud y frecuencia; el pentest aporta profundidad y prueba de explotación. Uno no sustituye al otro.
Cuándo usar cada uno
Algunas situaciones típicas:
- Higiene continua del parque. Escaneo recurrente, con cobertura de todos los activos, internos y expuestos a internet. Es la base de cualquier programa de gestión de vulnerabilidades.
- Lanzamiento o cambio relevante. Una nueva aplicación, una nueva integración, una migración a la nube o una reestructuración de la red requieren pentest antes o justo después de entrar en producción.
- Aplicaciones web y APIs críticas. Las fallas de autenticación, control de acceso y lógica de negocio rara vez aparecen en un escaneo. Aquí, el pentest manual es lo que encuentra el problema.
- Exigencia regulatoria o contractual. PCI DSS, por ejemplo, pide ambas cosas: escaneos internos y externos al menos cada tres meses, los externos realizados por un ASV, proveedor de escaneo aprobado por el PCI SSC (requisitos 11.3.1 y 11.3.2), y pentest interno y externo al menos cada 12 meses y después de cualquier cambio significativo de infraestructura o aplicación (11.4.2 y 11.4.3).
- Validar controles. Cuando la pregunta es "¿el firewall, el EDR y la segmentación resisten un ataque real?", solo una prueba que intenta atacar puede responderla.
En la práctica, la mayoría de las organizaciones necesita ambos, con cadencias distintas: escaneo siempre, pentest periódico y dirigido a lo que más importa.
Cómo elegir el pentest adecuado
Empiece por el alcance
Un pentest con un alcance mal definido genera un informe que no responde a la pregunta del negocio. Antes de pedir una propuesta, defina: qué activos (perímetro externo, red interna, aplicación web, API, aplicación móvil, nube, Wi-Fi), qué queda fuera del alcance, ventanas de prueba, contactos de emergencia y qué está prohibido (denegación de servicio, ingeniería social, pruebas en producción en horario laboral). Este acuerdo, llamado reglas de enfrentamiento, protege a ambas partes y debe quedar por escrito.
Caja negra, gris o blanca
- Caja negra (black box). El evaluador empieza sin información interna, como un atacante externo. Es lo más realista para el perímetro, pero parte del tiempo se va en reconocimiento y la cobertura tiende a ser menor.
- Caja gris (gray box). El evaluador recibe información parcial, como credenciales de un usuario común o documentación básica. Equilibra realismo y cobertura y es la opción más habitual para aplicaciones, porque simula a un cliente o empleado malintencionado.
- Caja blanca (white box). Acceso amplio a la arquitectura, las configuraciones y a veces el código fuente. Es lo más profundo y eficiente para encontrar fallas, a costa de menos realismo sobre lo que vería un atacante externo.
Metodología reconocida
Pregunte qué metodología sigue el proveedor y cómo se refleja en el informe. Las referencias más usadas son la NIST SP 800-115 (planificación, descubrimiento, ataque e informe), la OWASP Web Security Testing Guide para aplicaciones web, el OSSTMM, del ISECOM, orientado a la medición operativa de la seguridad, y el PTES (Penetration Testing Execution Standard), que organiza el trabajo desde la precontratación hasta el informe. La metodología no es burocracia: es lo que garantiza que dos pruebas del mismo entorno sean comparables y que nada importante quede fuera por olvido.
Evalúe quién hará la prueba
- Prueba manual de verdad. Pregunte cómo se reparte el trabajo entre herramientas y análisis manual. La salida de un escáner con otro formato no es un pentest.
- Calificación del equipo. Las certificaciones con examen práctico, como la OSCP, dicen más sobre la capacidad de conducir una prueba que las certificaciones solo teóricas.
- Experiencia en su alcance. Un pentest de red interna exige dominio de Active Directory; uno de aplicación exige dominio de desarrollo web y APIs.
- Muestra de entregables. Pida un informe de ejemplo anonimizado y, si la prueba se usará en una auditoría, un modelo de carta de atestación.
Qué debe incluir el informe
Un buen informe de pentest incluye:
- Resumen ejecutivo. En lenguaje de negocio: qué conseguiría un atacante, qué activos críticos están en riesgo y qué hacer primero.
- Alcance y método. Qué se probó, cuándo, de qué forma y qué quedó fuera.
- Hallazgos con evidencia. Cada falla con descripción, pasos para reproducirla, evidencias (capturas, solicitudes), activos afectados y clasificación de riesgo en el contexto del entorno.
- Cadenas de ataque. Cómo hallazgos de severidad media se combinan en un compromiso grave.
- Recomendaciones accionables. Correcciones específicas, no frases genéricas como "aplicar parches".
Exija la nueva prueba. Un pentest sin retest termina con una lista, no con riesgo reducido. La nueva prueba confirma que las correcciones funcionan y no abrieron otros caminos. PCI DSS (requisito 11.4.4) exige que las vulnerabilidades explotables encontradas en el pentest se corrijan y que la prueba se repita para verificar las correcciones.
Cómo encaja en la gestión continua de vulnerabilidades
Pensar en "escaneo o pentest" como una decisión única es el error de fondo. Ambos son entradas de un mismo ciclo: identificar, evaluar, priorizar, tratar y verificar. El escaneo alimenta ese ciclo con volumen y frecuencia. El pentest lo alimenta con profundidad y con la confirmación de qué fallas son realmente explotables en su entorno, un dato valioso para la priorización. Para ordenar la cola de correcciones, conviene combinar severidad, probabilidad de explotación y exposición, como explicamos en cómo priorizar vulnerabilidades con CVSS, EPSS y KEV.
El flujo también corre en sentido inverso. Un hallazgo de pentest que el escáner no detectó señala una brecha de cobertura: credenciales que faltan en el escaneo, un activo fuera del inventario, una clase de falla que necesita otro control. Cerrarlas mejora todo el ciclo.
Por último, el resultado tiene que llegar a la gobernanza: las auditorías de ISO 27001, PCI DSS y LGPD piden cada vez más evidencia práctica de que los controles funcionan, y el historial de escaneos, pentests, correcciones y nuevas pruebas es esa evidencia.
Preguntas frecuentes
¿El escaneo de vulnerabilidades sustituye al pentest?
No. El escaneo identifica fallas conocidas a escala, pero no valida si son explotables ni encuentra fallas de lógica, de autorización o cadenas de ataque. El pentest sí lo hace, pero cubre un alcance menor y en momentos específicos. Ambos se complementan.
¿Con qué frecuencia hacer pentest?
Una referencia de mercado es PCI DSS: al menos cada 12 meses y después de cualquier cambio significativo en el entorno. Las aplicaciones críticas que cambian con frecuencia pueden justificar pruebas más cercanas a cada entrega. El escaneo, al ser automatizado, debe ejecutarse con mucha más frecuencia.
¿Qué modalidad elegir: caja negra, gris o blanca?
Depende de la pregunta. Para saber qué ve un atacante externo, caja negra. Para aplicaciones con usuarios autenticados, la caja gris suele ofrecer el mejor equilibrio. Para encontrar el máximo de fallas en un sistema crítico en poco tiempo, caja blanca.
Fuentes consultadas: NIST SP 800-115, Technical Guide to Information Security Testing and Assessment; OWASP Web Security Testing Guide; ISECOM, Open Source Security Testing Methodology Manual (OSSTMM 3); Penetration Testing Execution Standard (PTES); PCI DSS v4.0.1, requisitos 11.3 y 11.4 (escaneos de vulnerabilidades y pruebas de penetración). Este artículo es educativo; consulte el texto oficial de las normas antes de definir el alcance y la frecuencia de sus pruebas.