Preparar tu empresa para un pentest: guía

Respuesta directa: Preparar una empresa para un pentest requiere completar cuatro pasos antes de que el primer paquete de red sea enviado: obtener autorización escrita de todas las partes con capacidad legal para concederla, definir el alcance con precisión suficiente para que el pentester sepa exactamente qué puede y qué no puede tocar, preparar un inventario de activos y contactos de escalada, y acordar las reglas de engagement.

Sin estos pasos, el pentest genera resultados incompletos, riesgo legal para el proveedor, y potencial interrupción de servicios productivos.

Por qué la preparación importa tanto como la ejecución

Un pentest de seguridad es una operación planificada de ataque autorizado. La calidad de los resultados depende directamente de la calidad de la preparación. Los problemas más frecuentes que degradan el valor de un pentest no ocurren durante la ejecución — ocurren antes:

Scope indefinido: El pentester evita sistemas críticos por temor a excederse, dejando superficies de ataque sin evaluar.
Falta de coordinación: El equipo de operaciones detecta el tráfico del pentest y lo bloquea en el firewall o el WAF, silenciando los hallazgos reales.
Autorización ambigua: Sistemas alojados en infraestructura de terceros (AWS, Azure, proveedores SaaS) requieren autorización separada. Sin ella, el pentest puede constituir acceso no autorizado bajo la Computer Fraud and Abuse Act (CFAA) en EE.UU. o normas equivalentes en América Latina.
Entorno equivocado: Probar en producción sin coordinación puede interrumpir servicios reales de clientes.

La preparación no es burocracia: es lo que convierte un gasto en una inversión con resultados accionables.

Paso 1: Obtener la autorización escrita correcta

Este es el paso más crítico y más frecuentemente subestimado. La autorización para un pentest debe provenir de quien tiene la capacidad legal y técnica para concederla:

Autorización interna: El CTO, CISO, o equivalente con autoridad sobre los sistemas a evaluar debe firmar un documento que especifique: qué sistemas están autorizados, el período de tiempo autorizado, y que el proveedor de pentesting tiene permiso explícito para ejecutar pruebas de seguridad.

Autorización de terceros — infraestructura cloud: AWS, Azure y GCP tienen políticas de Penetration Testing que permiten pruebas en instancias propias sin notificación previa, con restricciones específicas (no pruebas de DoS contra la infraestructura compartida, no pruebas de los planos de control de los proveedores). Verifica las políticas actualizadas de tu proveedor antes de iniciar.

Autorización de terceros — servicios compartidos: Si el scope incluye aplicaciones alojadas en plataformas SaaS compartidas, CDNs o proveedores de hosting, necesitas autorización explícita de cada uno. Sin ella, el pentest puede estar atacando infraestructura que pertenece a terceros que no han dado su consentimiento.

Autorización de terceros — integraciones: Si la aplicación se integra con APIs de terceros (pasarelas de pago, CRMs, plataformas de analytics), esas APIs generalmente no están en scope a menos que tengas autorización específica de esos proveedores.

El documento de autorización debe ser conservado por ambas partes. En caso de incidente durante el pentest, es la evidencia que protege tanto al cliente como al proveedor.

Paso 2: Definir el alcance (scope) con precisión

El scope es la lista exacta de lo que está dentro y fuera de la evaluación. Un scope bien definido tiene dos listas: in-scope y explicitly out-of-scope. La segunda lista es tan importante como la primera.

Qué incluir en el scope

Para aplicaciones web:

URLs completas de todos los entornos (producción, staging, desarrollo)
Subdominios específicos o patrón de subdominios (*.empresa.com)
Roles de usuario que deben probarse (anónimo, usuario básico, usuario premium, administrador)
Funcionalidades específicas de alto riesgo que deben cubrirse

Para infraestructura:

Rangos de IP o CIDRs autorizados (192.168.10.0/24)
Nombres de host específicos
Servicios en scope (solo HTTP/HTTPS, o también SSH, RDP, bases de datos)

Para APIs:

URLs base de las APIs (https://api.empresa.com/v2/)
Documentación OpenAPI/Swagger si está disponible
Credenciales de prueba para cada rol

Qué excluir explícitamente

Sistemas de producción de terceros
Infraestructura compartida del proveedor cloud
Horarios en los que no debe haber tráfico de prueba (durante deploys o mantenimientos programados)
Tipos de prueba que no están autorizados (por ejemplo: "no ejecutar pruebas de DoS")

El cuestionario de scoping

Un proveedor profesional debe entregar un cuestionario de scoping estructurado que cubra todos estos elementos antes de iniciar cualquier evaluación (algunos, como WhiteJaguars, lo incluyen en el proceso de onboarding). Esto elimina la ambigüedad y asegura que ambas partes tengan las mismas expectativas sobre qué se va a evaluar y con qué profundidad.

Paso 3: Preparar el inventario de activos

El cliente conoce su infraestructura mejor que el pentester. Proporcionar un inventario pre-trabajo acelera la evaluación y evita que tiempo valioso se gaste en descubrimiento que el cliente podría haber provisto:

Inventario mínimo recomendado:

Activo	Información a proveer
Aplicaciones web	URL, tecnologías principales (framework, lenguaje), autenticación
APIs	URL base, tipo (REST/GraphQL/SOAP), documentación disponible
Servidores	IPs, sistema operativo, servicios expuestos
Bases de datos	Tipo (MySQL, PostgreSQL, MongoDB), si son accesibles desde la red evaluada
Integraciones	Lista de servicios de terceros con los que se comunica la aplicación
Dependencias críticas	Librerías propias, SDKs internos

Cuentas de prueba: Para evaluaciones de aplicaciones con autenticación, el cliente debe proveer credenciales funcionales para cada rol de usuario que debe ser evaluado. El pentester no debería necesitar crear sus propias cuentas — eso puede generar ruido en logs y confusión posterior.

Paso 4: Notificar a los equipos internos correctos

Este es el paso que más frecuentemente se omite y más frecuentemente genera problemas:

Equipo de operaciones / SOC: Si tienes un equipo de monitoreo de seguridad o un SOC, debes informarles del período del pentest y el rango de IPs desde donde se ejecutará. Sin esta notificación, responderán a las alertas del pentest como si fueran un ataque real — potencialmente bloqueando al pentester y silenciando hallazgos legítimos.

Equipo de desarrollo: Si el pentest incluye APIs o aplicaciones en desarrollo activo, el equipo de desarrollo debe saber que las pruebas están en curso para no interpretar errores 5xx o comportamiento inusual como bugs de su código.

Equipo de infraestructura: Para asegurar que los firewalls y WAFs están configurados para no bloquear el tráfico del pentester (o para documentar si deben bloquearlo como parte del scope del test).

¿Debo notificar a todos? Depende del tipo de pentest. Un red team engagement deliberadamente mantiene el alcance de la notificación reducido para simular un ataque real. Un pentest de cumplimiento generalmente notifica a todos los equipos relevantes. Define esto en las reglas de engagement.

Paso 5: Definir las Reglas de Engagement (Rules of Engagement)

Las Rules of Engagement (RoE) documentan los parámetros operativos del pentest. Deben quedar por escrito:

Horario de pruebas: ¿Pueden ejecutarse pruebas en cualquier momento, o solo en horario de oficina? ¿Hay períodos vetados (antes de un lanzamiento, durante mantenimientos)?

Técnicas autorizadas: ¿Se autoriza phishing de empleados? ¿Ingeniería social? ¿Pruebas de DoS controladas? ¿Escalada de privilegios en sistemas de producción?

Técnicas explícitamente prohibidas: Muchos clientes excluyen pruebas destructivas (borrado de datos, modificación de registros en producción), ataques DoS en producción, y técnicas que puedan afectar la disponibilidad de servicios para clientes reales.

Protocolo de emergencia: Si el pentester descubre una vulnerabilidad crítica activamente explotada, o evidencia de un atacante real en los sistemas, ¿a quién contacta y en qué tiempo? El contacto de escalada debe ser una persona con capacidad de tomar decisiones técnicas, no un gestor de proyecto.

Procedimiento de pausa: Si durante el pentest ocurre un incidente técnico (el servidor se cae, la aplicación queda en estado inesperado), ¿cuál es el procedimiento para pausar las pruebas y coordinar la respuesta?

Paso 6: Preparar el entorno técnico

Producción vs Staging: Lo ideal es ejecutar el pentest contra un entorno de staging que sea lo más fiel posible a producción. Esto elimina el riesgo de afectar usuarios reales. Sin embargo, hay hallazgos (especialmente en configuración de infraestructura, CDN, y WAF) que solo son visibles en producción.

Si el pentest debe incluir producción, documenta con el proveedor qué técnicas pueden ejecutarse en producción y cuáles solo en staging.

Datos de prueba: Si el entorno de staging usa datos reales de producción, asegúrate de que están anonimizados antes del pentest. El pentester accederá a esos datos como parte de la evaluación — deben ser datos sintéticos o datos reales debidamente anonymizados.

Backups: Antes de cualquier pentest que incluya pruebas activas en producción, verifica que tienes un backup reciente y probado. No porque esperes que el pentester destruya datos (los contratos profesionales lo prohíben), sino como buena práctica operativa.

Lo que NO debes hacer

No lanzar el pentest sin autorización documentada. Sin importar cuánta confianza tengas en el proveedor.
No omitir la notificación al SOC. El costo de un falso positivo mal gestionado puede superar el valor del pentest.
No dar al pentester acceso administrativo por defecto. El pentester debe obtener privilegios como parte del ejercicio — empezar con acceso de administrador no tiene valor de testing.
No pedir al pentester que "ignore" sistemas en scope porque son sensibles. Si son sensibles, son exactamente lo que más debe probarse.
No tratar el pentest como un evento de compliance. El objetivo es encontrar vulnerabilidades reales, no generar un reporte que satisfaga un checkbox de auditoría.

Checklist de preparación antes del pentest

La preparación es la diferencia entre un pentest que encuentra vulnerabilidades reales y uno que genera un reporte que nadie puede actuar. Las empresas que llegan bien preparadas al inicio del engagement obtienen hallazgos más profundos, informes más accionables, y mayor valor por cada dólar invertido.

Si no tienes claro qué criterios usar para elegir a ese proveedor, consulta el checklist para evaluar proveedores de pentesting antes de iniciar el proceso de selección.

Una vez que el proveedor ejecuta el pentest, saber qué debe contener un buen reporte de pentesting te permitirá verificar que los entregables cumplen el estándar profesional.

Preguntas frecuentes

¿Qué documentación necesito antes de un pentest?

Antes de iniciar un pentest necesitas al menos tres documentos: la autorización escrita firmada por quien tiene capacidad legal sobre los sistemas, el documento de alcance (scope) con listas explícitas de sistemas in-scope y out-of-scope, y las Reglas de Engagement que definen técnicas autorizadas, horarios y protocolos de emergencia. Sin estos, el engagement puede ser legalmente inválido o producir resultados incompletos.

¿Cuánto tiempo lleva preparar la infraestructura para un pentest?

La preparación de la infraestructura para un pentest toma entre una y dos semanas para la mayoría de las organizaciones. Incluye obtener autorizaciones de terceros (cloud, SaaS), crear cuentas de prueba para cada rol de usuario, notificar al equipo de operaciones y al SOC, y verificar que existe un backup reciente si el pentest incluye producción. La fase de scoping con el proveedor puede iniciarse en paralelo.

¿Qué accesos debo dar al equipo de pentesting?

El tipo de acceso depende del modelo acordado. En un pentest de caja gris se proporcionan credenciales funcionales para cada rol de usuario a evaluar, documentación de la API si existe, e información básica de la arquitectura. En caja negra no se da acceso inicial — el equipo lo obtiene como parte del ejercicio. Nunca se debe otorgar acceso de administrador por defecto: el pentester debe ganarlo durante la evaluación.

Un proveedor de pentesting profesional guía a cada cliente a través de un cuestionario de scoping estructurado y una sesión de kick-off para asegurar que la evaluación cubra exactamente lo que necesita.

Cómo preparar a tu empresa para realizar un pentest eficaz