PTES
PTES, sigla de Penetration Testing Execution Standard, describe las fases por las que pasa un test de intrusión: interacciones previas, recolección de inteligencia, modelado de amenazas, análisis de vulnerabilidades, explotación, posexplotación e informe. Existe por una razón práctica de comprador. Sin método declarado, dos tests con el mismo nombre entregan trabajos incomparables, y quien paga no tiene cómo saber cuál de los dos recibió.
El PTES es una referencia pública de ejecución, sin organismo certificador y sin sello. DM11 conduce el test con las fases declaradas en el contrato, entrega un informe auditable por otro profesional y, cuando todavía estás cotizando, te ayuda a escribir el requisito de alcance que va al mercado. Para la cobertura de aplicación usamos OWASP, y para describir el camino recorrido usamos MITRE ATT&CK.
Quién conduce el test
CEH, hacker ético certificado por EC-Council
CPTE, ingeniería de test de intrusión por AcadiTI
SYCP y SYWP, pentest y pentest de aplicación web por Solyd
Análisis de vulnerabilidades con Qualys Certified Specialist
QUÉ ES
El PTES es un estándar público que organiza la ejecución de un test de intrusión en siete secciones, en el orden en que ocurren. No lista herramientas ni comandos: describe qué tiene que pasar en cada etapa y qué sale de cada una. Junto al estándar existe una guía técnica separada, y la división es deliberada, porque la estructura de un test cambia despacio y la técnica cambia todos los meses.
Las interacciones previas definen alcance, autorización, ventana y reglas. La recolección de inteligencia releva qué existe y qué sabe ya el mundo sobre ti. El modelado de amenazas convierte eso en hipótesis de ataque que tienen sentido para tu negocio. El análisis de vulnerabilidades identifica qué puede ser explotado. La explotación lo confirma en la práctica. La posexplotación mide hasta dónde se podría llegar después de la primera puerta. Y el informe cierra en dos partes, resumen ejecutivo e informe técnico, que es la división que define el propio estándar.
Vale decirlo con todas las letras, porque cambia lo que deberías esperar de él. El PTES nació alrededor de 2009 y el sitio declara la versión actual como 1.0, prometiendo una 2.0 con niveles de intensidad por fase que nunca se publicó. La última vez que lo comprobamos, la edición más reciente de cualquier página del wiki es de diciembre de 2015, la guía técnica es de 2012, y el registro de cambios con ventana de 3000 días no muestra ninguna edición. Dos páginas del propio menú, FAQ e In the Media, están vacías.
La secuencia de fases sigue siendo correcta: un test serio todavía empieza por un acuerdo escrito y termina por un informe en dos capas. Lo que cambió mucho es lo que se hace dentro de cada fase, porque nube, identidad federada, contenedores, API y modelos de lenguaje no existían con la misma forma cuando el texto fue escrito. Por eso DM11 usa el PTES para la estructura de ejecución, el OWASP para la cobertura de aplicación, con el Top 10 y el ASVS, y el MITRE ATT&CK para nombrar y describir el camino que recorrió el atacante.
Conviene alinear la expectativa temprano. Lo que el trabajo produce es un informe con alcance, método, fechas, hallazgos con evidencia y camino de corrección, no un certificado. No existe organismo que certifique a una empresa ni a un informe contra el PTES, y no existe sello para poner en el sitio. Las certificaciones que existen en este universo pertenecen a las personas que conducen el test, y no al test en sí. Cuando tu cliente o tu auditor necesita un documento emitido por un tercero acreditado, quien responde es ISO 27001 o SOC 2, y el informe producido aquí entra entero en esas auditorías como evidencia.
QUIÉN SUELE NECESITARLO
Todas tienen la misma raíz: alguien va a pagar por un trabajo técnico que no puede evaluar solo, y necesita una forma de verificarlo antes y después.
Las dos dicen pentest, las dos citan la misma cantidad de objetivos, y la diferencia de precio no tiene explicación visible. Casi siempre la diferencia está en lo que cada una hará de hecho: una incluye posexplotación y retest, la otra termina en el escaneo con revisión. Exigir las fases declaradas por escrito hace que la comparación exista, y la conversación pasa a ser sobre alcance en lugar de descuento.
Un cliente grande en due diligence, una auditoría de certificación, PCI DSS con test anual, resoluciones del banco central brasileño con periodicidad mínima anual y exigencia de independencia. En esos casos el informe sale de tu empresa y lo lee quien no participó del test. Un informe sin método declarado obliga a ese lector a creer, y ahí es cuando pide todo de nuevo.
El documento tiene decenas de páginas, gravedad por color y ninguna frase que diga hasta dónde alguien logró llegar. Eso pasa cuando el trabajo se saltó el modelado de amenazas, la explotación y la posexplotación, que son justamente las fases que separan un escaneo de un test de intrusión. La empresa pagó por un pentest y recibió un análisis de vulnerabilidades con otro nombre.
HISTORIAS
Cambiamos los nombres de los clientes con el mismo sigilo que protegerá a tu empresa después. Los nombres cambian, el patrón de los problemas se repite. Cuando el cliente lo autoriza, damos referencias con nombre en una conversación.
Servicios financieros
El área de tecnología tenía dos propuestas de test de intrusión sobre la mesa, con una diferencia grande de precio y una página de alcance cada una. Las dos listaban la misma cantidad de direcciones y la misma ventana. Nadie en el equipo podía explicarle a la dirección por qué una costaba tanto más, y la tendencia natural era elegir la más barata y confiar en la suerte.
Antes de cualquier test, escribimos con el cliente el requisito de alcance que iría al mercado, fase por fase: qué entra en recolección de inteligencia, si el modelado de amenazas se entrega como documento, si la posexplotación está incluida, si hay retest después de la corrección, quién ejecuta y con qué calificación, y qué tiene que estar en el informe. Pedimos que las dos propuestas se volvieran a presentar contra ese requisito.
Las dos volvieron distintas de lo que eran. Quedó visible que la propuesta más barata terminaba en la confirmación de la falla, sin posexplotación y sin retest, y que la otra incluía las dos cosas. La elección dejó de ser sobre precio y pasó a ser sobre alcance, decidida por la dirección con las dos columnas en la misma pantalla.
Industria
La empresa contrataba test de intrusión desde hacía tres años y archivaba los informes para la auditoría. Todos traían listas largas de fallas clasificadas por gravedad, y ninguno traía una línea sobre lo que un atacante podría hacer con ellas. Las correcciones se hacían de arriba abajo en la lista, sin que nadie supiera si las de arriba eran realmente las que importaban.
Rehicimos el trabajo con las fases declaradas en el contrato. Modelamos amenazas a partir de lo que la empresa no puede perder, confirmamos las fallas por explotación y seguimos hacia la posexplotación, que era exactamente la fase ausente en los años anteriores. Describimos el camino recorrido con el lenguaje de MITRE ATT&CK, para que el equipo de infraestructura pudiera revisar la detección después.
Tres fallas clasificadas como medias, aisladas y postergadas durante dos años seguidos, encadenadas daban acceso a un recurso compartido con proyectos de producto. Subieron al tope de la fila de corrección por primera vez, y dos fallas altas que nadie lograba explotar siguieron en la fila, con la justificación escrita.
Software como servicio
En el test anterior, el bloqueo de origen dejó afuera la dirección del testeador apenas empezar y el trabajo siguió así hasta el final de la ventana. El informe concluyó que el ambiente era resiliente. La dirección lo celebró, y el equipo de seguridad quedó con la sensación incómoda de que aquello no había sido testeado de verdad.
Pusimos en las interacciones previas la decisión que nadie había tomado: qué hacer cuando la defensa bloquea a quien testea. Definimos dos ventanas, una con el bloqueo activo, para medir qué detiene realmente la defensa, y otra con la dirección del testeador habilitada de forma controlada, para medir qué existe detrás de ella. Contactos de emergencia, horarios y criterio de parada quedaron escritos antes de empezar.
Las dos respuestas pasaron a existir por separado. La defensa detenía bien el ataque genérico, y detrás de ella había un servicio interno expuesto que ningún test anterior había alcanzado. El cliente dejó de elegir entre una buena noticia y una noticia útil, porque pasó a recibir las dos.
CÓMO LO CONDUCIMOS
Cada fase termina con algo que puedes verificar sin confiar en nosotros. Ese es el punto del método: un informe que otro profesional puede auditar vale más que un informe que solo entiende quien lo escribió.
La fase que el comprador más ignora y la que más protege a los dos lados. Definimos qué está dentro y qué está fuera, el enfoque, las ventanas, el criterio de parada, el tratamiento de terceros como proveedor de nube y proveedor de acceso, y si habrá algún test que pueda afectar la disponibilidad. La autorización formal y los contactos de emergencia quedan registrados antes del primer paquete.
Alcance escrito, con qué está dentro y qué está fuera
Reglas de enganche, ventanas y criterio de parada
Autorización formal para testear y contactos de emergencia
Tratamiento acordado para nube, proveedor de acceso y demás terceros
Hito de entregaAlcance y autorización firmados, sin ningún punto de alcance abierto.
Relevamos qué existe y qué ya es público sobre tu empresa, de forma pasiva y activa, y convertimos eso en hipótesis de ataque ligadas a lo que tu negocio no puede perder. Sin esta fase el test se vuelve una búsqueda de fallas sueltas, y el resultado es una lista sin prioridad que nadie sabe usar.
Superficie relevada, con lo expuesto y lo interno separados
Información pública sobre la empresa y sobre personas, cuando está en el alcance
Hipótesis de ataque ligadas a lo que el negocio no puede perder
Objetivos priorizados y acordados contigo antes de la explotación
Hito de entregaHipótesis de ataque validadas con tu equipo, con la prioridad acordada.
Identificamos qué puede ser explotado y confirmamos en la práctica qué se puede explotar de verdad, que es la diferencia entre una sospecha y un hecho. En aplicación, la cobertura sigue el OWASP, con el Top 10 y el ASVS, porque ahí es donde el PTES deja de bajar al detalle y la vara que el mercado reconoce es otra.
Fallas identificadas, con el método de identificación registrado
Confirmación por explotación, con evidencia de lo obtenido
Cobertura de aplicación por OWASP, con el requisito verificado ítem por ítem
Comunicación inmediata del hallazgo crítico, sin esperar el informe final
Hito de entregaFalla crítica comunicada el mismo día, con evidencia y recomendación inicial.
La posexplotación mide hasta dónde se podría llegar después de la primera puerta, que es la información que cambia decisiones de inversión. El informe sale en las dos capas que define el propio estándar, resumen ejecutivo e informe técnico, con el camino recorrido descrito en el lenguaje de MITRE ATT&CK, para que tu equipo revise la detección y no solo la corrección.
Alcance real demostrado, con el camino encadenado y lo que quedó expuesto
Resumen ejecutivo para la dirección, sin jerga
Informe técnico con evidencia, reproducción y corrección por hallazgo
Retest de lo corregido, con el resultado registrado
Hito de entregaInforme entregado y retest concluido, con cada hallazgo cerrado o aceptado por escrito.
CUÁNTO TIEMPO LLEVA
No publicamos plazo estándar, porque plazo publicado se convierte en promesa y el alcance de un test de intrusión varía mucho. Las interacciones previas suelen ser la parte corta en ejecución y la más decisiva en el resultado. Estos son los tres factores que más mueven el reloj, y la primera conversación ya muestra en cuál está tu empresa.
Contar direcciones no describe el esfuerzo. Un rango grande con servicios repetidos avanza rápido, y una sola aplicación con muchos perfiles de usuario, reglas de negocio complejas e integración con terceros consume mucho más. Es la conversación de alcance la que separa los dos casos, y ocurre antes de la propuesta.
Sin ninguna información, buena parte del tiempo va a la recolección de inteligencia, y el resultado se parece más a lo que enfrentaría un atacante externo. Con información parcial, o con acceso a documentación y código, esas mismas horas se gastan buscando fallas en lugar de buscando puertas. Las dos elecciones son legítimas y entregan cosas distintas, y la decisión queda registrada en las interacciones previas.
Un ambiente que solo se puede testear fuera del horario comercial, un sistema con pico estacional, una autorización pendiente del proveedor de nube y el aviso previo al proveedor de seguridad gestionada mueven el calendario más que la parte técnica. Esa conversación empieza temprano, porque suele ser la más lenta de todo el proyecto.
PREGUNTAS FRECUENTES
Las dudas que aparecen en casi toda primera reunión, respondidas sin rodeos.
No existe, ni para tu empresa ni para el informe. El PTES es una referencia pública de ejecución, sin organismo certificador, sin auditoría de tercero y sin sello. Las certificaciones que existen en este universo pertenecen a las personas que conducen el test, como CEH, CPTE y las trayectorias de pentest de Solyd. Lo que recibes es un informe con método declarado, y es ese informe el que va a la auditoría, al cliente y al regulador.
Una conversación corta ya produce el requisito de alcance fase por fase que tu empresa puede llevar al mercado. Sirve para comparar proveedores con criterio, y sirve para contratar el test con nosotros sabiendo exactamente qué vas a recibir en cada etapa.
Comparativas sobre este tema
Ver las 13 comparativas