En resumen
- Un pentest demuestra qué vulnerabilidades son explotables y cómo se encadenan; un escaneo solo las enumera y un red team mide además la capacidad de detección y respuesta.
- El tipo de prueba se define por el objetivo (externo, interno, web y API, móvil, inalámbrico, ingeniería social, nube) y por la información entregada (caja negra, gris o blanca).
- Un buen informe incluye resumen ejecutivo, hallazgos puntuados con CVSS, evidencia, pasos de reproducción, recomendaciones concretas y un retest que confirme el cierre.
- El costo lo determina el esfuerzo que exige el alcance; dos cotizaciones solo son comparables si describen los mismos activos, roles, condiciones y entregables.
- En Perú, el acceso a un sistema sin autorización o excediendo lo autorizado es delito según la Ley N° 30096; la autorización escrita y el alcance firmado son obligatorios.
Qué es un pentest y qué preguntas responde
Un pentest (prueba de penetración, test de intrusión o, en lenguaje comercial, ethical hacking) es una evaluación de seguridad en la que un equipo especializado utiliza las mismas técnicas que un atacante real para intentar comprometer sistemas, aplicaciones, redes o personas de una organización, siempre con autorización escrita y dentro de un alcance acordado.
La guía técnica de referencia del NIST, la SP 800-115, lo describe como una prueba en la que los evaluadores imitan ataques reales para identificar formas de eludir las funciones de seguridad de una aplicación, un sistema o una red. Y añade un matiz que define la diferencia con cualquier herramienta automática: la mayoría de pentests busca combinaciones de vulnerabilidades que permitan obtener más acceso del que daría una sola falla.
Para la gerencia, un pentest bien ejecutado responde preguntas concretas:
- ¿Puede alguien desde internet llegar a la base de datos de clientes?
- ¿Un empleado con una cuenta básica puede convertirse en administrador del dominio?
- ¿Un cliente de nuestra aplicación puede ver los pedidos o facturas de otro cliente?
- ¿Qué tan sofisticado tendría que ser un atacante para lograrlo, y lo detectaríamos?
La respuesta llega con evidencia reproducible. Lo que un pentest no ofrece es una garantía: es una fotografía de un momento, con tiempo y alcance limitados.
¿En qué se diferencia un pentest de un escaneo de vulnerabilidades y de un red team?
Son tres servicios distintos que a menudo se venden con el mismo nombre. La guía de pruebas de penetración del PCI Security Standards Council separa con claridad los dos primeros: el escaneo busca identificar, clasificar y reportar vulnerabilidades; el pentest busca formas de explotarlas para vencer los controles de seguridad, mediante un proceso principalmente manual. El red team, según el glosario del NIST, es un ejercicio adversarial en condiciones reales que pone a prueba la capacidad de seguridad de toda la organización.
| Criterio | Escaneo de vulnerabilidades | Pentest | Red team |
|---|---|---|---|
| Objetivo | Listar vulnerabilidades conocidas | Demostrar qué es explotable y su impacto | Medir si la organización detecta y responde a un adversario |
| Método | Automatizado, con verificación limitada | Manual, apoyado en herramientas | Manual, sigiloso, orientado a un objetivo de negocio |
| Cobertura | Amplia: muchos activos | Profunda: activos definidos | Selectiva: la ruta que lleve al objetivo |
| Defensores informados | Sí | Normalmente sí | Solo un grupo reducido |
| Falsos positivos | Frecuentes | Depurados: cada hallazgo se verifica | Depurados |
| Fallas de lógica de negocio | No las detecta | Sí | Si sirven al objetivo |
| Frecuencia habitual | Continua o periódica | Periódica y ante cambios relevantes | Ocasional, en organizaciones maduras |
| Entregable | Listado priorizado | Informe ejecutivo y técnico con evidencia | Narrativa del ataque y brechas de detección |
La regla práctica: escanear de forma continua, hacer pentests periódicos y reservar el red team para cuando ya existe una capacidad de detección que valga la pena poner a prueba. Si lo que necesita es sostener la corrección entre pruebas, eso es gestión de vulnerabilidades, no un pentest más frecuente.
¿Qué tipos de pentest existen según el objetivo?
Pentest externo
Simula a un atacante en internet sin credenciales. Revisa servicios publicados, VPN y accesos remotos, correo, paneles de administración expuestos y dominios. Es el punto de partida habitual porque cubre la superficie que cualquiera puede alcanzar.
Pentest interno y de Active Directory
Parte del supuesto de que el atacante ya está dentro: un equipo comprometido por phishing, un proveedor o un empleado malintencionado. Según NIST SP 800-115, el evaluador parte del acceso de un empleado estándar e intenta escalar privilegios. En redes Windows el objetivo típico es el control del dominio.
Aplicaciones web y APIs
Es el tipo que más depende del trabajo manual. La referencia es la OWASP Web Security Testing Guide, cuya versión estable es la 4.2 (la 5.0 está en desarrollo). Para APIs se usa el OWASP API Security Top 10 2023, cuyo primer riesgo es la autorización rota a nivel de objeto: cambiar un identificador en la petición y obtener datos de otro usuario. Ningún escáner entiende que esa respuesta no debería existir.
Aplicaciones móviles
Se evalúan contra el estándar OWASP MASVS y la guía de pruebas MASTG: almacenamiento local de datos, comunicación con el backend, autenticación y protección del binario. Casi siempre incluye la API que consume la aplicación, que es donde suelen estar los hallazgos más graves.
Redes inalámbricas
Revisa las redes Wi-Fi corporativas y de invitados, su segmentación y la posibilidad de capturar credenciales o llegar a la red interna. Requiere presencia física.
Ingeniería social
Mide el factor humano: phishing simulado, llamadas a la mesa de ayuda o intentos de acceso físico. NIST SP 800-115 recuerda que estos métodos no técnicos forman parte de muchos pentests y que el personal de seguridad debe tener un mecanismo para verificar la legitimidad del evaluador. Como involucra datos de trabajadores, sus objetivos y el tratamiento de la información deben acordarse por escrito, considerando la Ley N° 29733 de Protección de Datos Personales.
Nube
Evalúa configuraciones, identidades, permisos y servicios expuestos en AWS, Azure o Google Cloud. Usted puede probar lo que configura, no la infraestructura del proveedor, y cada proveedor fija sus reglas. Por ejemplo, la política de AWS permite probar sin aprobación previa una lista de servicios y prohíbe las pruebas de denegación de servicio fuera de su programa específico.
Caja negra, gris o blanca: ¿cuánta información debe recibir el equipo?
La segunda dimensión es el conocimiento previo que usted entrega. No cambia qué se prueba, sino cuánto del tiempo contratado se dedica a descubrir lo que usted ya sabe.
| Modalidad | Qué recibe el equipo | Qué simula | Ventaja | Limitación |
|---|---|---|---|---|
| Caja negra | Solo el objetivo (dominio, rango de IP, nombre de la aplicación) | Atacante externo sin información | Realismo frente a un tercero | Gran parte del tiempo se va en reconocimiento; menor cobertura |
| Caja gris | Credenciales de uno o más roles y documentación básica | Cliente, empleado o proveedor malintencionado | Mejor equilibrio entre realismo y cobertura | Requiere preparar usuarios y datos de prueba |
| Caja blanca | Arquitectura, documentación y, a veces, código fuente | Atacante con conocimiento interno | Máxima profundidad y menos puntos ciegos | Exige más coordinación y más horas de análisis |
La guía del PCI Security Standards Council señala que las pruebas exigidas por PCI DSS se realizan normalmente en caja blanca o gris, porque dan resultados más precisos, y que una prueba en caja negra puede requerir más tiempo, dinero y recursos para cumplir el mismo objetivo. Desde la práctica, para aplicaciones web y APIs la caja gris con al menos dos roles suele ser la opción con mejor relación entre esfuerzo y hallazgos: sin credenciales, la mayor parte de la funcionalidad queda detrás de la pantalla de inicio de sesión y fuera de la prueba.
¿Cuáles son las fases de un pentest?
Las metodologías reconocidas coinciden en la estructura. NIST SP 800-115 propone cuatro fases (planificación, descubrimiento, ataque e informe). El Penetration Testing Execution Standard (PTES) define siete secciones, desde las interacciones previas hasta el informe. El OSSTMM 3 de ISECOM aporta un enfoque orientado a medir la superficie de ataque. En la práctica, un pentest profesional sigue estas etapas:
- Preacuerdo, alcance y reglas de enfrentamiento. Se definen los activos incluidos y excluidos, el tipo de prueba, las ventanas horarias, las técnicas prohibidas (por ejemplo, denegación de servicio), los contactos de emergencia, el tratamiento de los datos a los que se acceda y el criterio para detener la prueba. NIST SP 800-115 incluye una plantilla de reglas de enfrentamiento en su apéndice B y establece que en esta fase no se ejecuta ninguna prueba. El cierre de la etapa es la autorización escrita firmada por quien tiene facultad sobre los activos.
- Reconocimiento. Información sobre el objetivo: dominios, tecnologías, personas y servicios publicados.
- Escaneo y análisis de vulnerabilidades. Enumeración de puertos, servicios, versiones y puntos de entrada, con herramientas y revisión manual.
- Explotación. Verificación controlada de cada hipótesis para demostrar el impacto real, sin alterar datos de producción ni afectar la disponibilidad.
- Post-explotación. Desde el acceso obtenido: escalamiento de privilegios, movimiento lateral, acceso a información sensible. NIST describe el pentest como un proceso iterativo que usa un acceso mínimo para obtener uno mayor; esta fase muestra hasta dónde llega el daño.
- Informe y presentación. Documentación de hallazgos y presentación a la gerencia y al equipo técnico. Los hallazgos críticos no esperan al informe final: se comunican en cuanto se confirman.
- Retest. Tras las correcciones, se vuelven a probar los hallazgos para confirmar que quedaron cerrados.
¿Qué debe contener un buen informe de pentest?
El informe es lo que usted compra: una buena prueba con un informe deficiente no sirve para corregir ni para acreditar diligencia. Verifique que incluya:
- Resumen ejecutivo en lenguaje de negocio: nivel de riesgo, hallazgos principales, impacto y prioridades, legible para la gerencia sin conocimientos técnicos.
- Alcance y limitaciones: qué se probó, qué no, con qué tipo de prueba, en qué fechas y qué restricciones afectaron la cobertura.
- Metodología aplicada y referencias (NIST, PTES, OWASP u otras).
- Hallazgos puntuados con CVSS. El estándar vigente es CVSS v4.0 de FIRST, publicado en noviembre de 2023, con cuatro grupos de métricas: base, amenaza, entorno y suplementarias. Su escala cualitativa va de baja (0,1 a 3,9) a crítica (9,0 a 10,0). FIRST recomienda indicar qué métricas se usaron (CVSS-B, CVSS-BT, CVSS-BE o CVSS-BTE) e incluir el vector completo, para que la puntuación sea verificable.
- Evidencia de cada hallazgo: capturas, peticiones y respuestas, con los datos sensibles enmascarados.
- Pasos de reproducción suficientes para que su equipo confirme el hallazgo y verifique luego la corrección.
- Impacto en el negocio, no solo técnico: qué datos, procesos o clientes quedan expuestos.
- Recomendación de corrección concreta y aplicable a su tecnología, con alternativas temporales cuando la solución definitiva tome tiempo.
- Cadenas de ataque: cómo se combinaron hallazgos de severidad media para lograr un impacto crítico.
- Informe de retest con el estado final de cada hallazgo.
Un informe que reproduce la salida de un escáner sin verificación manual es un escaneo, cualquiera sea el nombre de la portada.
¿Cada cuánto se debe hacer un pentest?
No existe una frecuencia universal; se define por riesgo. NIST SP 800-115 señala que, por su costo e impacto potencial, una prueba anual de la red puede ser suficiente, siempre que se complemente con escaneos periódicos menos intensivos. Como criterio práctico, conviene realizar un pentest:
- Al menos una vez al año sobre los activos críticos.
- Antes de publicar una aplicación nueva o una versión con cambios mayores.
- Después de cambios relevantes: migración a la nube, nueva VPN, fusión de redes, cambio de proveedor de TI.
- Después de un incidente, para confirmar que el vector de entrada quedó cerrado.
- Cuando un cliente corporativo, un contrato o una norma sectorial lo exige.
Si su empresa almacena, procesa o transmite datos de tarjetas de pago, la exigencia es explícita: PCI DSS v4.0.1, en su requisito 11.4, establece pruebas de penetración internas y externas al menos una vez cada 12 meses y después de cualquier actualización o cambio significativo de infraestructura o aplicaciones, según una metodología documentada.
¿Cuánto cuesta un pentest y de qué depende?
No publicamos precios ni rangos: un precio sin alcance no dice nada. El costo de un pentest refleja el esfuerzo especializado que exige un alcance concreto. Estos son los factores que lo determinan:
| Factor | Por qué cambia el esfuerzo | Qué debe definir antes de cotizar |
|---|---|---|
| Tipo y número de activos | Cada IP, aplicación, API o app móvil suma superficie a revisar | Inventario: IP o rangos, URL, APIs, apps Android e iOS |
| Complejidad funcional | Más pantallas, endpoints y flujos implican más casos de prueba | Número aproximado de funcionalidades o endpoints; documentación de la API |
| Roles autenticados | Cada rol multiplica las pruebas de autorización entre usuarios | Qué perfiles existen (cliente, operador, administrador) y cuáles se probarán |
| Caja negra, gris o blanca | Cambia el tiempo dedicado a reconocimiento frente a análisis | Qué información y credenciales puede entregar |
| Ambiente | Producción exige más cuidado y ventanas; un ambiente de pruebas incompleto limita la cobertura | Si existe un ambiente equivalente al productivo y con datos de prueba |
| Ventanas horarias | Probar de noche o en fines de semana alarga los plazos y requiere coordinación | Horarios permitidos y sistemas sensibles |
| Red interna y Active Directory | El tamaño del dominio y las sedes definen las rutas a explorar | Número de sedes, segmentos y si la prueba es remota o presencial |
| Nube y terceros | Pueden requerir permisos o ajustarse a políticas del proveedor | Qué servicios en la nube, hosting o SaaS están en el alcance |
| Ingeniería social | Añade diseño de campañas, coordinación con RR. HH. y tratamiento de datos | Número de personas, canales y límites acordados |
| Profundidad del informe | Requisitos de cumplimiento o de un cliente pueden exigir formatos específicos | Para quién es el informe y qué debe acreditar |
| Retest | Volver a probar es trabajo adicional que debe estar previsto | Si se incluye, cuántas rondas y en qué plazo |
| Plazo de entrega | Un calendario comprimido exige más especialistas en paralelo | Fecha límite real y por qué |
Cómo comparar cotizaciones de pentest
Cuando dos propuestas difieren mucho, casi siempre difieren en alcance o en método. Pida a cada proveedor que explicite el esfuerzo estimado (días de especialista) por activo, qué parte es manual y qué parte automatizada, la metodología, las exclusiones y supuestos, y si el retest está incluido. Una propuesta mucho más barata para los mismos activos suele ser un escaneo automatizado con otro nombre: exija que la diferencia se explique.
¿Cómo elegir una empresa de pentesting?
La guía A Guide to Penetration Testing de CREST recomienda definir los requisitos de forma formal, fijar criterios de selección por escrito y validar que el proveedor puede cumplirlos, en lugar de dejar la decisión solo en manos de compras. Use este checklist:
- Metodología documentada y alineada con estándares públicos (NIST SP 800-115, PTES, OWASP, OSSTMM).
- Informe de muestra anonimizado que muestre el resumen ejecutivo, la calidad de la evidencia y el nivel de detalle de las recomendaciones.
- Exige autorización escrita y verifica que la firme quien tiene facultad sobre los activos. Si un proveedor no la pide, descártelo.
- Reglas de enfrentamiento con ventanas, exclusiones, contactos de emergencia y criterio de detención.
- Manejo de datos: acuerdo de confidencialidad, cómo almacena y cifra la evidencia, cuándo la destruye y su rol como encargado del tratamiento si accede a datos personales.
- Seguro de responsabilidad vigente que cubra daños derivados del servicio; pida la póliza.
- Retest incluido o claramente cotizado.
- Comunicación de hallazgos críticos durante la prueba, sin esperar al informe final.
- Equipo identificado: quién ejecuta, con qué experiencia y qué credenciales. Si declara certificaciones, verifíquelas en el registro público de la entidad emisora.
- Sin promesas de resultado: nadie puede garantizar que encontrará todas las vulnerabilidades ni que su empresa quedará "100% segura".
¿Es legal hacer un pentest en Perú?
Sí, siempre que esté autorizado. La Ley N° 30096, Ley de Delitos Informáticos, tipifica en su artículo 2 el acceso ilícito: acceder de forma deliberada e ilegítima a todo o parte de un sistema informático, o excederse en lo autorizado. A su vez, el artículo 12 exime de responsabilidad penal a quien realiza esas conductas con el propósito de llevar a cabo pruebas autorizadas u otros procedimientos autorizados destinados a proteger sistemas informáticos.
Las consecuencias prácticas son directas:
- Sin autorización escrita no hay pentest, aunque el sistema sea de su propia empresa y lo pruebe un tercero contratado.
- La autorización debe firmarla quien tiene facultad sobre los activos. Si la aplicación está alojada en un hosting, un SaaS o una nube, se deben respetar las condiciones del proveedor.
- Salir del alcance acordado puede constituir un exceso de lo autorizado. Por eso el alcance se escribe con precisión: IP, dominios, aplicaciones, fechas y técnicas.
- Si la prueba puede exponer datos personales, su tratamiento se rige por la Ley N° 29733.
Este resumen no sustituye la revisión de su asesoría legal sobre su caso particular.
Cómo realiza STRATON un pentest
En STRATON, el pentesting para empresas en Perú se ejecuta solo con autorización escrita previa y alcance definido en unas reglas de enfrentamiento. Entregamos un informe ejecutivo y un informe técnico con evidencia, pasos de reproducción, puntuación CVSS y recomendaciones, presentamos los resultados a la gerencia y al equipo técnico, y realizamos un retest de los hallazgos corregidos. El personal asignado firma acuerdos de confidencialidad y, cuando el trabajo implica datos personales, actuamos como encargados del tratamiento conforme a la Ley N° 29733.
Si necesita sostener la corrección en el tiempo, el complemento es la gestión de vulnerabilidades; si debe demostrar control frente a un marco o un cliente, la auditoría de seguridad y cumplimiento. Cada servicio se cotiza de forma individual: para preparar una propuesta basta con el inventario de activos, los roles a probar y las condiciones descritas en esta guía.
Fuentes y referencias
- 01SP 800-115, Technical Guide to Information Security Testing and Assessment — NIST. Consultado el .
- 02Glossary: red team exercise — NIST CSRC. Consultado el .
- 03Information Supplement: Penetration Testing Guidance (v1.1) — PCI Security Standards Council. Consultado el .
- 04Document Library: PCI DSS v4.0.1 — PCI Security Standards Council. Consultado el .
- 05OWASP Web Security Testing Guide — OWASP Foundation. Consultado el .
- 06OWASP API Security Top 10 2023 — OWASP Foundation. Consultado el .
- 07OWASP Mobile Application Security (MASVS y MASTG) — OWASP Foundation. Consultado el .
- 08The Penetration Testing Execution Standard (PTES) — PTES. Consultado el .
- 09OSSTMM 3: The Open Source Security Testing Methodology Manual — ISECOM. Consultado el .
- 10Common Vulnerability Scoring System v4.0: Specification Document — FIRST. Consultado el .
- 11A Guide to Penetration Testing (diciembre 2022) — CREST. Consultado el .
- 12Penetration Testing Policy — Amazon Web Services. Consultado el .
- 13Ley N° 30096, Ley de Delitos Informáticos, y sus modificatorias — Plataforma del Estado Peruano (gob.pe). Consultado el .
- 14Ley N° 29733, Ley de Protección de Datos Personales — Congreso de la República (gob.pe). Consultado el .
Contenido informativo de carácter general; no constituye asesoría legal ni técnica para un caso concreto. Revisado por el equipo editorial de straton.
