01Qué es una prueba de penetración y qué no lo es
Una prueba de penetración es una revisión de seguridad contratada y limitada en el tiempo, en la que los evaluadores identifican, encadenan y explotan vulnerabilidades manualmente y de forma controlada para demostrar su riesgo real. Debe distinguirse claramente del escaneo de vulnerabilidades: este comprueba de forma automatizada y a gran escala patrones de vulnerabilidades conocidos, pero no verifica los hallazgos y genera con regularidad falsos positivos; forma parte de la gestión continua de vulnerabilidades y no sustituye a un pentest. El red teaming, por su parte, persigue otro objetivo: simula de forma encubierta un ataque realista contra activos críticos definidos («crown jewels») y pone a prueba también la capacidad de detección y respuesta de los defensores, mientras que una prueba de penetración examina un alcance delimitado de la forma más exhaustiva posible en busca de vulnerabilidades.
02Tipos de prueba: de la aplicación web a la red Wi-Fi
Las pruebas de aplicaciones web y de API examinan, entre otros aspectos, la autenticación, la gestión de sesiones, el control de acceso y las vulnerabilidades de inyección. Las pruebas de infraestructura externas se centran en la superficie de ataque accesible desde Internet; las internas parten de un atacante dentro de la red y analizan, por ejemplo, la escalada de privilegios, el movimiento lateral y las debilidades de Active Directory. Los pentests de cloud se concentran en errores de configuración y en los modelos de identidades y permisos dentro de la responsabilidad compartida con el proveedor. Las pruebas de aplicaciones móviles abarcan el almacenamiento local de datos, los mecanismos de protección de la plataforma y las interfaces de backend; las pruebas de Wi-Fi verifican la autenticación, el cifrado y la segmentación de la red en las instalaciones.
03Black box, grey box y white box: la base de información
Esta clasificación describe cuánta información previa reciben los evaluadores. En una prueba black box comienzan sin información interna: realista desde la perspectiva del atacante, pero laboriosa y con menor cobertura, porque parte del tiempo de prueba se dedica a la recopilación de información. En una prueba white box se dispone de documentación de arquitectura, configuraciones o código fuente, lo que permite la mayor profundidad de prueba por unidad de tiempo. El enfoque grey box se sitúa entre ambos, normalmente con cuentas de prueba y documentación; en la práctica se ha consolidado como el estándar eficiente para la mayoría de los objetivos de prueba. Con independencia de ello, la perspectiva (externa/interna) y el grado de aviso previo se definen durante el scoping.
04Metodologías: OWASP WSTG, PTES y la guía del BSI
Las metodologías reconocidas hacen que las pruebas de penetración sean trazables y comparables. Para aplicaciones web y API, la referencia es la OWASP Web Security Testing Guide (WSTG); la versión estable actual, la 4.2, se publicó en diciembre de 2020 y la versión 5.0 está en desarrollo. El Penetration Testing Execution Standard (PTES, versión 1.0) estructura el proceso completo en siete fases, desde las interacciones previas al encargo, pasando por la recopilación de información, el threat modeling, el análisis de vulnerabilidades, la explotación y la post-explotación, hasta el informe. Para el ámbito germanohablante, la guía del BSI «Praxis-Leitfaden für IS-Penetrationstests» (edición 2016) describe un procedimiento estructurado y ofrece ayuda, en particular, para la contratación. Los proveedores serios indican en el informe la metodología utilizada.
05Desarrollo y base jurídica
Una prueba de penetración comienza con el scoping: objetivos, sistemas, ventanas de prueba, exclusiones y contactos de emergencia se fijan por escrito. Siguen la recopilación de información y el análisis de vulnerabilidades, la explotación controlada de los hallazgos relevantes y el informe con resumen ejecutivo, detalles técnicos, evaluación de riesgos y recomendaciones de medidas priorizadas; un retest tras la corrección cierra el ciclo. Desde el punto de vista jurídico es imprescindible el encargo previo por escrito de la parte autorizada («permission to test»): sin él, las acciones de prueba pueden constituir delitos conforme a los §§ 202a ff. StGB del Código Penal alemán (espionaje e interceptación de datos). Los sistemas de terceros —por ejemplo, de proveedores de hosting, cloud o SaaS— solo pueden probarse con su consentimiento o en el marco de sus políticas de prueba; los acuerdos de confidencialidad y de protección de datos deben formar parte de todo contrato.
06Periodicidad y detonantes regulatorios: NIS2, DORA, TISAX
No existe una periodicidad obligatoria universal; la práctica establecida es una revisión al menos anual de los sistemas críticos, complementada con pruebas puntuales tras cambios sustanciales en la arquitectura o las aplicaciones. NIS2 (Directiva (UE) 2022/2555) exige en el art. 21, apartado 2, letra f) políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos; las pruebas de penetración son un medio consolidado para ello. Para el sector financiero, DORA (Reglamento (UE) 2022/2554, aplicable desde el 17 de enero de 2025) menciona expresamente las pruebas de penetración como parte del programa de pruebas de resiliencia (art. 25); las entidades financieras designadas para ello por las autoridades deben realizar además, al menos cada tres años, pruebas de penetración guiadas por amenazas (TLPT) conforme al art. 26. En el entorno de la automoción, las evaluaciones TISAX basadas en el catálogo VDA ISA (versión 6; para evaluaciones encargadas a partir de 2027, el catálogo sucesor ISA 2027) esperan evidencias de revisiones técnicas periódicas y de una gestión eficaz de vulnerabilidades; las pruebas de penetración son un medio de evidencia habitual.
