Pentesting: qué debe incluir el alcance, el informe y el retesteo

1. Decide qué pregunta debe responder la evaluación

“Queremos un pentest” todavía no es un objetivo. Define la decisión: validar controles antes de lanzar una aplicación, comprobar separación entre clientes, revisar exposición externa, cumplir un requisito contractual o verificar correcciones. La pregunta determina activos, cuentas, profundidad, evidencia y momento.

Distingue revisión de configuración, análisis de vulnerabilidades, escaneo, revisión de código, ejercicio de red team y prueba de penetración. NIST SP 800-115 presenta técnicas con beneficios y limitaciones distintas. Combinar servicios puede ser apropiado, pero el informe debe decir cuál método produjo cada evidencia.

• Decisión que depende del resultado y responsable de tomarla.
• Escenario, amenaza o control que se intenta validar.
• Tipo de evaluación y razón para elegirlo.
• Criterios de éxito, limitaciones aceptadas y fecha relevante.
• Relación con desarrollo, monitoreo y gestión continua de vulnerabilidades.

Encontrar “alguna vulnerabilidad” no es un objetivo medible y tampoco define cuándo termina la prueba.

2. Confirma autorización, propiedad y dependencias de terceros

La autorización debe identificar a la organización que puede permitir las pruebas y a las personas facultadas para representarla. Relaciona cada dominio, dirección, aplicación, API, cuenta, red y ambiente con su propietario. Un activo accesible desde internet no se vuelve autorizable por aparecer conectado al sistema del cliente.

Revisa alojamiento, CDN, nube, pasarela de pago, autenticación, mensajería, soporte y demás dependencias. Los proveedores publican políticas propias; por ejemplo, Microsoft y AWS establecen reglas y exclusiones para pruebas sobre servicios cloud. Obtén permisos o retira esos componentes del recorrido antes de ejecutar actividad activa.

• Entidad autorizante, firmante y contactos técnicos y ejecutivos.
• Inventario con identificadores concretos y propietario confirmado.
• Ambientes incluidos y exclusión explícita de sistemas de terceros.
• Políticas de nube, hosting, telecomunicaciones y otros proveedores.
• Ruta para ampliar alcance sin asumir autorización verbal improvisada.

El alcance técnico nunca puede ser más amplio que la autoridad comprobada.

3. Escribe reglas de compromiso que puedan usarse durante la prueba

Las reglas convierten el permiso general en decisiones operativas. Incluyen fechas, zona horaria, fuentes de tráfico, cuentas, restricciones de tasa, ventanas, técnicas permitidas y acciones que requieren aprobación adicional. Define si se permiten cambios de datos, carga de archivos, acceso a cuentas, ingeniería social, persistencia, movimiento lateral o pruebas de disponibilidad.

Establece comunicación normal, reporte crítico y parada de emergencia. Identifica quién puede ordenar una pausa y qué evidencia debe preservarse. Alinea monitoreo y soporte para distinguir la prueba de un incidente real sin anular la capacidad de detección que también se quiere observar.

• Inicio, fin, zona horaria, direcciones de origen y ventanas.
• Acciones permitidas, limitadas, prohibidas y sujetas a aprobación.
• Datos de prueba, cuentas, respaldos y protección disponible.
• Contactos 24/7 cuando el riesgo operativo lo requiera.
• Umbrales de parada, reanudación y comunicación de hallazgos críticos.

4. Deriva la cobertura de arquitectura, flujos y requisitos

Una lista genérica no representa una aplicación concreta. Mapea componentes, entradas, roles, datos, límites de confianza, integraciones y funciones de mayor impacto. Incluye flujos negativos y positivos: no basta buscar errores conocidos; también hay que verificar que un control se comporte como fue diseñado.

OWASP WSTG ofrece dominios y casos para aplicaciones y servicios web, mientras OWASP ASVS ofrece requisitos verificables que pueden usarse en contratos y criterios. Selecciona referencias con versión, adapta casos al sistema y documenta lo que no pudo probarse por tiempo, datos, arquitectura o restricción.

• Arquitectura, tecnologías, interfaces y dependencias relevantes.
• Roles y cuentas para acceso anónimo, usuario y administración.
• Funciones críticas, datos sensibles y límites entre organizaciones.
• Requisitos de seguridad que deberían operar y casos para validarlos.
• Cobertura excluida, no disponible o bloqueada y su efecto.

Citar OWASP no demuestra cobertura: el informe debe relacionar cada referencia con activos y casos ejecutados.

5. Combina herramientas con validación manual y control de impacto

Las herramientas ayudan a descubrir superficie, comparar respuestas y detectar patrones, pero producen falsos positivos, falsos negativos y resultados sin contexto. Cada hallazgo importante necesita validación proporcional, condición reproducible y evidencia suficiente para que el equipo responsable comprenda y corrija.

Minimiza impacto y datos. Una prueba puede demostrar acceso sin copiar un conjunto completo, o demostrar ejecución sin mantener persistencia. Registra hora, fuente, cuenta, solicitud o condición, respuesta, activo y límite aplicado. Si aparece información ajena al objetivo, detén la expansión y sigue el procedimiento acordado.

• Técnica o herramienta y versión cuando sea relevante.
• Condición previa, rol, activo y secuencia reproducible.
• Resultado observado frente al comportamiento esperado.
• Evidencia redactada o minimizada y canal seguro de entrega.
• Impacto evitado, limitación y nivel de confianza del hallazgo.

6. Exige un informe que permita decidir y corregir

OWASP WSTG recomienda separar resumen ejecutivo, parámetros de prueba y hallazgos técnicos, incluyendo alcance, calendario, objetivos y limitaciones. Cada hallazgo debe explicar condición, activo, impacto técnico, evidencia reproducible, recomendación y referencias; agrupa síntomas que comparten una causa cuando eso ayuda a corregir el sistema.

CVSS, mantenido por FIRST, comunica características y severidad técnica; no sustituye el análisis del negocio. Añade exposición, criticidad del activo, datos, controles compensatorios y plausibilidad para decidir prioridad. Un número alto no autoriza una acción urgente que pueda detener un servicio sin comprender el contexto.

• Resumen ejecutivo: qué importa, por qué y cuál decisión requiere.
• Alcance, fechas, método, cuentas, exclusiones y limitaciones.
• Hallazgo técnico con evidencia, reproducción y activos afectados.
• Severidad técnica separada de impacto y prioridad organizacional.
• Recomendación concreta, opciones y criterio para verificar el cierre.

El conteo de hallazgos no mide por sí solo la seguridad ni la calidad del pentest.

7. Planifica la remediación y el retesteo desde el contrato

Asigna propietario, fecha, dependencia y evidencia de cierre para cada acción. Corrige la causa cuando sea posible: una validación puntual puede ocultar el mismo patrón en otros endpoints, roles o componentes. Integra cambios en desarrollo, configuración, pruebas automatizadas, monitoreo y capacitación según el origen.

El retesteo repite condiciones acordadas y comprueba que la solución no sólo oculte el síntoma. Define cuántas rondas, plazo, ambiente y hallazgos están incluidos. Registra estados como corregido, parcial, no corregido, no reproducible, riesgo aceptado o no evaluado, sin convertir el retesteo en una garantía general.

• Propietario de remediación y prioridad aprobada.
• Causa, cambio previsto y sistemas similares por revisar.
• Prueba que demostrará el cierre y evidencia que se conservará.
• Ventana y alcance del retesteo incluidos.
• Riesgo residual y decisión formal cuando no se corrige.

8. Evalúa al proveedor por claridad, seguridad y transferencia

Pide una propuesta que nombre alcance, método, equipo, entregables, manejo de evidencia, seguro o requisitos contractuales aplicables, comunicación crítica y retesteo. Las certificaciones pueden aportar señal sobre personas o procesos, pero no sustituyen una muestra de informe, experiencia en la tecnología y capacidad para explicar limitaciones.

Antes de iniciar, actualiza inventario, confirma respaldos, prepara cuentas y datos de prueba, avisa a responsables necesarios y define canal seguro. No corrijas silenciosamente durante la evaluación salvo riesgo inmediato: registra cambios para que los resultados sigan siendo interpretables. Al cerrar, revoca cuentas, elimina accesos y confirma disposición de evidencia.

• Experiencia relevante y responsable técnico identificable.
• Muestra de entregable con evidencia útil y datos protegidos.
• Proceso de conflicto de interés, confidencialidad y escalamiento.
• Accesos temporales, monitoreo, respaldo y contactos preparados.
• Cierre de cuentas, evidencia, sesiones y obligaciones pendientes.