Fases del PTES desde mi experiencia

 Hoy voy a intentar "sintetizar" las fases de la guía PTES (Penetration Testing Execution Standar) desde lo que llevo vivido en estos 10 años que ya llevo en ciberseguridad.

Pre-engagement Interactions (la reunión antes de empezar)

Esta es, sin duda, la parte más crítica de todo el pentest y la que más se olvida. No es glamurosa, no hay exploits brillantes, pero es la que evita que te metas en un jaleo legal o que el cliente espere milagros por no dejar las cosas claras.

Imagina que es la planificación de un asalto, pero en lugar de un banco, es una red corporativa. Aquí es donde defines QUÉ se va a atacar y, casi más importante, QUÉ NO.

El Arte de Definir el Alcance (Scoping)

Aquí es donde te sientas con el cliente (a veces, incluso antes de firmar el contrato, pero con un NDA por delante) y descubres qué necesita realmente. Muchas veces el cliente no tiene ni idea de lo que quiere. He llegado a oír: "Quiero que me hackees estas 100 IPs". Y tú, como buen profesional, le tienes que explicar que atacar una aplicación web crítica es un trabajo totalmente distinto a hacer un escaneo superficial de 100 IPs. El precio no puede ser lineal. Es como cobrar lo mismo por dar un paseo en bici que por el Tour de Francia.

Hay que ser su guía y preguntar (entre muchas otras) cosas como: ¿es un test de caja negra (black-box, sin información), gris (grey-box, con algo de info) o blanca (white-box, con acceso total)? Ya que esto cambia totalmente el tipo de auditoría.

La Guía de Preguntas (Cuestionarios)

Este estándar te sugiere una batería de preguntas amplia para hacerle al cliente, organizadas por tipo de test:

• Test de Red: ¿Por qué lo hacen? ¿Es por cumplimiento normativo? ¿Cuántas IPs? ¿Hay firewalls o IDS? Si consigues acceso, ¿hasta dónde quieren que llegues? ¿A por los datos? ¿A por el control total?
• Aplicación Web: ¿Cuántas apps? ¿Cuántos logins? ¿Tendrás acceso al código fuente? ¿Quieren que hagas fuzzing?
• Wireless: ¿Cuántas redes? ¿Cifrado? ¿Hay que buscar dispositivos "trampa" (rogues)?
• Test Físico: ¿Cuántas ubicaciones? ¿Guardias de seguridad? ¿Están armados? ¿Se pueden usar ganzúas? (Ojo con la legalidad).
• Ingeniería Social: ¿Listas de emails o teléfonos para atacar? ¿Está aprobado el acceso físico no autorizado?

La Bestia del "Scope Creep"

Es lo más difícil de organizar en las consultorías. El cliente, contento con tu trabajo, te dice: "Oye, ya que estás, mira también este servidor que no era parte del contrato". Y si no lo controlas, acabas trabajando gratis. La clave es ser firme: cualquier trabajo extra requiere un nuevo acuerdo, un nuevo presupuesto y un nuevo documento firmado. La buena relación con el cliente no significa regalar horas de trabajo.

Temas Peligrosos y Legales (los campos de minas)

• Terceros y la Nube: ¿El cliente usa AWS, Azure o un hosting? Cuidado, porque atacar un servicio en la nube sin el permiso explícito del proveedor es una forma rápida de que te demanden. Amazon, por ejemplo, tiene un formulario específico para esto. Revisa e infórmate de todo antes de liarla.
• Leyes Locales: Si los servidores están en otro país, tienes que conocer sus leyes. Lo que en España es un test, en Alemania puede ser un delito.
• Denegación de Servicio (DoS): ¿Está aprobado? La mayoría de las empresas le tienen pánico porque puede tumbar sistemas de producción. Normalmente, solo se hace en entornos de pruebas. Es importarte reflejarlo.
• Ingeniería Social: Los pretextos (las excusas que usas) deben ser aprobados por escrito. Nada de pretextos de pornografía o drogas a menos que el cliente lo autorice explícitamente (y sea relevante).
• Información Sensible: Durante el test, puedes encontrarte con datos de tarjetas de crédito, historiales médicos (PHI) o información personal identificable (PII). El estándar es claro: evita visualizar o descargar estas cosas si no quieres tener problemas. Demuestra el acceso con una captura de pantalla que no muestre los datos reales. Es un riesgo legal enorme para ti.

Reglas de Compromiso (Rules of Engagement)

Si el Alcance es el QUÉ, las Reglas de Compromiso son el CÓMO. Aquí defines la línea de salida y la de meta, los horarios de ataque (¿en horario de “oficina” o por la noche?), cómo manejar la información sensible, y el documento más importante de todos: el "Permission to Test". Este documento, firmado por el cliente, es tu escudo legal. Dice que ellos son conscientes de que les vas a atacar y que no te van a demandar si se cae un servidor (aunque harás todo lo posible para evitarlo).

Comunicación y Objetivos

Establecer líneas de comunicación claras es vital. ¿A quién llamas si tiras un servidor de producción a las 3 de la mañana? Hay que tener una lista de contactos de emergencia 24/7. Y, por último, definir los objetivos. Un test no es solo parchear sistemas. Es entender el riesgo para el negocio. El objetivo principal no debería ser "cumplir con PCI-DSS", sino "evitar que un atacante robe la base de datos de clientes y nos lleve a la quiebra".

En resumen, la fase de Pre-engagement es donde dejas de ser un técnico y te conviertes en consultor. Es donde ganas o pierdes al cliente, y donde te proteges a ti y a tu empresa de un mundo de dolor.

Si veo que tiene suficiente apoyo, iré subiendo el resto de fases.