Qué es una prueba de penetración

Una prueba de penetración (pentest) es un ejercicio autorizado, limitado en tiempo y alcance, en el que un equipo intenta comprometer sistemas, aplicaciones o procesos con las mismas técnicas que usaría un atacante real — pero con reglas claras, evidencia documentada y el objetivo de mejorar la seguridad, no de causar daño.

No es un certificado mágico. No es un escaneo automático con un PDF bonito. Es trabajo humano (asistido por herramientas) orientado a demostrar impacto: qué se puede romper, hasta dónde llega el acceso y qué hay que corregir primero.

Si buscas una definición operativa para compartir con dirección, producto o legal, esta sirve: una prueba de penetración es una evaluación ofensiva controlada que verifica si los controles de seguridad resisten intentos reales de abuso.

Para qué sirve (y para qué no)

Sirve para:

• Encontrar fallas que un escaneo no ve — sobre todo lógica de negocio, control de acceso entre roles y cadenas de explotación.
• Priorizar remediación con severidad basada en impacto demostrable, no solo en un CVSS genérico.
• Generar evidencia para clientes, due diligence o marcos como SOC 2 o ISO 27001, cuando el alcance coincide con lo que esos programas piden.
• Validar que un arreglo realmente cerró el hallazgo (retest).

No sirve para:

• Garantizar que “no hay vulnerabilidades”. Ningún pentest de duración finita cubre el 100 % del espacio de ataque.
• Sustituir el diseño seguro, el code review continuo o la gestión de vulnerabilidades del día a día.
• Cumplir por sí solo un estándar que exige un sistema de gestión completo (por ejemplo ISO 27001) o un análisis de riesgos formal (por ejemplo HIPAA).

Qué se diferencia de un escaneo de vulnerabilidades

	Escaneo de vulnerabilidades	Prueba de penetración
Método	Automatizado, firmas y heurísticas	Manual + herramientas; hipótesis y explotación
Autenticación	A menudo superficial o ausente	Roles reales, sesiones, MFA cuando aplica
Lógica de negocio	Casi nula	Central
Falsos positivos	Frecuentes	Se verifican antes de reportar
Entregable típico	Lista de CVEs / configs	Hallazgos explotables con evidencia y pasos
Pregunta que responde	“¿Hay debilidades conocidas?”	“¿Qué puede lograr un atacante aquí?”

Ambos son útiles. El escaneo escala y se puede repetir seguido. El pentest profundiza. Confundirlos es el error más caro en compras de seguridad: pagas por un “pentest” y recibes un export de Nessus o un scanner web con portada nueva.

Referencias útiles de metodología (no son “certificaciones de su producto”, son marcos de trabajo):

• OWASP Web Security Testing Guide (WSTG)
• NIST SP 800-115 — guía técnica de pruebas de seguridad de la información
• OWASP Testing Guide / Top 10 como mapa de riesgos frecuentes en aplicaciones

Tipos de prueba según el conocimiento previo

La industria suele clasificar el pentest por cuánta información recibe el equipo:

• Caja negra (black box) — sin credenciales ni diagramas; simula un atacante externo con poco contexto. Útil para superficie pública; suele ser menos eficiente por día de prueba.
• Caja gris (grey box) — cuentas de prueba, roles y documentación básica. Es el equilibrio más habitual para aplicaciones web y APIs: más cobertura real por el mismo calendario.
• Caja blanca (white box) — acceso a código, arquitectura o configuración. Máxima profundidad; a menudo se combina con una auditoría de código cuando el riesgo lo justifica.

Otra clasificación útil es por superficie:

• Aplicaciones web
• APIs (REST, GraphQL, gRPC)
• Móviles (iOS / Android)
• Infraestructura / red
• Personas y procesos (ingeniería social) — solo con autorización explícita y marco legal claro
• Sistemas de IA / LLM (abuso de prompts, herramientas, recuperación de datos)

Para la mayoría de productos SaaS en Latam que venden a empresas, el núcleo es web autenticada + API. Empiece ahí salvo que su modelo de amenaza diga otra cosa.

Cómo se ve un engagement bien hecho

Un ciclo sano suele incluir:

1. Descubrimiento y alcance — activos, ambientes, roles, datos sensibles, ventanas horarias, contactos de emergencia.
2. Reglas de enfrentamiento (rules of engagement) — qué está permitido, qué está prohibido (DoS, exfiltración real de datos de clientes, pivoteo fuera de alcance).
3. Ejecución — reconocimiento, abuso de autenticación y autorización, inyecciones, lógica de negocio, configuración, encadenamiento de hallazgos.
4. Reporte — resumen ejecutivo, hallazgos técnicos con evidencia, severidad, remediación orientada a ingeniería.
5. Retest — verificación de correcciones y actualización del informe.

Si el proveedor no quiere hablar de retest, de roles autenticados o de lógica de negocio, no estás comprando un pentest: estás comprando ruido.

Qué debe traer el entregable

Exige, como mínimo:

• Alcance escrito (qué entró y qué quedó fuera)
• Fechas del engagement y del informe
• Metodología de referencia
• Hallazgos con pasos de reproducción, evidencia y severidad
• Guía de remediación comprensible para quien va a corregir
• Resumen que una persona no técnica pueda leer sin traducir jerga
• Camino claro de retest

Un informe que solo lista CVE sin demostrar explotación en su sistema es débil para ingeniería y débil para un auditor exigente.

Cómo delimitar el alcance sin sabotearte

El alcance malo produce dos fracasos: (1) falsas sensaciones de seguridad; (2) hallazgos irrelevantes que consumen el sprint.

Preguntas que debe responder antes de pedir cotización:

• ¿Producción, staging o ambos? Staging espejo es preferible cuando se puede ser más agresivo.
• ¿Cuántos roles de usuario y tenants hay que probar?
• ¿Hay flujos de pago, invitaciones, impersonación de admin o APIs partner?
• ¿El alcance incluye el panel interno / herramientas de soporte?
• ¿Hay límites legales o de datos personales (PII) que restrinjan pruebas?

Documenta el alcance en una página. Si más tarde alguien dice “pensamos que el admin estaba incluido”, el documento evita la pelea.

Para aplicaciones web, el servicio de pentesting web de Selva Ops describe el tipo de cobertura autenticada y basada en roles que suele necesitarse; úselo como checklist de conversación, no como menú cerrado.

Cómo elegir proveedor (señales reales)

Prioriza:

• Metodología nombrable — OWASP WSTG, NIST SP 800-115 u equivalente, no “framework propietario” opaco.
• Personas que prueban — quién ejecuta el trabajo; seniority y especialización en su superficie (web, móvil, IA).
• Ejemplo de informe (anonimizado) — si no pueden mostrar estructura, asume que el entregable será pobre.
• Retest incluido o cotizado — el ciclo no termina en el PDF.
• Comunicación durante la prueba — canal para hallazgos críticos el mismo día, no al final.
• Independencia — el equipo que construyó el sistema no debería “pentestearse” a sí mismo si el informe va a un auditor externo.

Desconfía de:

• Precios que solo se explican por horas de scanner
• Garantías de “cero vulnerabilidades” o “certificación” genérica
• Alcances enormes en tres días sin roles autenticados
• Informes que no puede enseñar a su CTO sin avergonzarse

Pide referencias de proceso (cómo escalan un crítico, cómo manejan datos de prueba), no testimonios inventados ni métricas de marketing.

Cuándo conviene hacerlo

Momentos típicos:

• Antes de un lanzamiento mayor o un cambio de arquitectura
• Cuando un cliente enterprise o un auditor lo pide con fecha
• Tras un incidente o un hallazgo grave en producción
• En ciclo anual si su riesgo residual y sus contratos lo exigen

La frecuencia correcta sale del riesgo y de los compromisos contractuales, no de un número mágico de la industria. Un producto que cambia cada semana necesita más ritmo de prueba (o pruebas más focalizadas) que un sistema estable con poca superficie nueva.

Errores frecuentes en Latam (y cómo evitarlos)

• Comprar el pentest solo para “la diligencia” dos días antes del QBR del cliente.
• Probar un staging vacío que no refleja auth, feature flags ni multi-tenant.
• Dejar hallazgos abiertos sin dueño ni fecha en Jira/Linear.
• Mezclar el informe del pentest con el del ASV o del scanner de cloud sin etiquetar qué es qué.
• Traducir el informe a inglés con un traductor automático y mandarlo a un auditor en EE.UU. sin revisión técnica.

Resumen en una frase

Un pentest bien hecho responde, con evidencia, qué puede lograr un atacante en su alcance y qué hay que arreglar primero; un escaneo responde qué debilidades conocidas aparecen en una pasada automática. Necesita ambos en un programa maduro — pero no los confunda al comprar.

Si está armando el primer pentest de una aplicación web y quiere un alcance realista con informe accionable, conversemos con su lista de ambientes y roles encima de la mesa.