Un proveedor de software sanitario aportó su informe de pruebas de penetración más reciente como evidencia de la madurez de sus pruebas de seguridad. El informe no mostraba hallazgos críticos y sí dos hallazgos de gravedad media, ambos relacionados con la configuración de TLS en un endpoint de preproducción. El equipo de seguridad del proveedor lo presentó como evidencia de que su entorno se había probado y se había considerado seguro. Una revisión minuciosa de la sección de alcance del informe contaba otra historia. La prueba se había realizado con una metodología externa de caja negra, simulando un atacante externo no autenticado, solo contra la aplicación web pública. Las exclusiones del alcance enumeraban: la red corporativa interna, todos los servidores de bases de datos, todos los endpoints de API que requerían autenticación, la infraestructura en la nube de AWS que alojaba los datos de los clientes, el entorno de desarrollo y los propios sistemas de acceso administrativo del proveedor. La prueba de dos días había evaluado la página de inicio de sesión, las partes no autenticadas de la API y el portal de documentación pública. Los entornos más relevantes para el riesgo del cliente (la API autenticada donde se trataban los datos de salud de los clientes, la infraestructura de AWS donde se almacenaban y los sistemas administrativos a través de los cuales accedía el personal del proveedor) quedaban todos fuera del alcance. El informe limpio describía un perímetro externo limpio. El entorno interno y la infraestructura en la nube no se habían probado.
¿Qué es realmente el problema de la profundidad de las pruebas de controles?
La profundidad de las pruebas de controles es el grado en que las pruebas de seguridad ejercitan los controles, sistemas y vías de ataque más relevantes para el modelo de amenaza real, en lugar de los controles, sistemas y vías de ataque más fáciles de probar con un presupuesto y un plazo definidos. La profundidad de las pruebas tiene dos dimensiones: la profundidad del alcance, que se refiere a cuántos de los sistemas y entornos pertinentes se incluyen en la prueba, y la profundidad de la técnica, que se refiere a la minuciosidad con que se prueban los sistemas incluidos mediante las técnicas que emplearían los atacantes reales.
La limitación del alcance es el problema de profundidad de las pruebas con más consecuencias. Las pruebas de penetración con un alcance limitado (solo externo, solo la aplicación web, solo vías no autenticadas) producen hallazgos que reflejan con exactitud la seguridad del alcance probado sin ofrecer ninguna garantía sobre los sistemas no probados. La superficie de ataque que priorizan los atacantes sofisticados (endpoints de API autenticados, configuración de la infraestructura en la nube, vías internas de movimiento lateral y sistemas de acceso administrativo) es con frecuencia la que se excluye del alcance de las pruebas de penetración para contener el costo y la complejidad. Una prueba limpia de un alcance limitado no es evidencia de un entorno seguro; es evidencia de que la parte probada del entorno no tiene problemas detectados.
El problema de la limitación de la técnica es la dimensión secundaria de la profundidad. Incluso dentro de un alcance definido, la profundidad de las pruebas determina lo que pueden detectar. Un análisis automatizado de vulnerabilidades detecta CVE conocidos y configuraciones incorrectas comunes. Una prueba de penetración manual realizada por un evaluador experimentado puede encontrar vulnerabilidades lógicas, omisiones de autenticación y vías de escalada de privilegios que las herramientas automatizadas pasan por alto. Las vulnerabilidades de lógica de negocio (brechas de autorización que permiten a un cliente acceder a los datos de otro mediante llamadas de API aparentemente legítimas) requieren un conocimiento específico de la aplicación que las herramientas automatizadas no pueden aportar. Las pruebas que se basan principalmente en análisis automatizados dentro de un alcance limitado encontrarán las vulnerabilidades que detectan las herramientas automatizadas. Pasarán por alto las clases de ataque que requieren experiencia humana y conocimiento específico de la aplicación.
- Alcance limitado al perímetro externo: se excluyen la red interna, la infraestructura en la nube y las vías autenticadas
- API autenticada no probada: el entorno donde los datos de los clientes son más accesibles queda excluido del alcance
- Infraestructura en la nube excluida: no se evalúa el entorno de AWS, Azure o GCP donde residen los datos
- Pruebas exclusivamente de caja negra: sin pruebas autenticadas ni de caja blanca de los sistemas internos
- Análisis automatizado sin pruebas manuales: una profundidad de técnica insuficiente para detectar vulnerabilidades complejas
Por qué es importante
La profundidad de las pruebas de controles es importante para TPRM porque los informes de pruebas de penetración son de las evidencias que más se solicitan y más peso tienen en las evaluaciones de seguridad de proveedores. Un resultado limpio de una prueba de penetración con un alcance limitado genera una señal positiva fuerte en la evaluación sin ofrecer ninguna garantía sobre los sistemas más relevantes para el riesgo del cliente. El cliente que confía en el informe de la prueba para comprender la postura de seguridad del proveedor se apoya en una evidencia cuyo alcance se apartó deliberadamente de los sistemas de mayor riesgo.
La brecha en las pruebas de API autenticadas es especialmente importante para los proveedores que tratan datos de clientes mediante API. La mayoría de las relaciones modernas de tratamiento de datos implican llamadas de API autenticadas: el sistema del cliente llama a la API del proveedor con credenciales de autenticación, y el sistema del proveedor procesa la solicitud y devuelve los datos. Los controles de autenticación y autorización de esos endpoints de API determinan si el cliente B puede acceder a los datos del cliente A, si una credencial de cliente comprometida puede acceder a más datos de los previstos y si los controles de acceso a datos del proveedor funcionan según lo diseñado. Probar la superficie externa no autenticada y excluir los endpoints de API autenticados describe una prueba que evaluó la cerradura de la puerta principal y no probó la sala donde se guardan los datos del cliente.
Dónde se equivocan la mayoría de los equipos
El fallo más constante es revisar los informes de pruebas de penetración por la gravedad de los hallazgos sin revisar la cobertura del alcance. Un informe sin hallazgos críticos de un alcance limitado ofrece menos garantía que un informe con hallazgos medios de un alcance integral. El alcance determina lo que la prueba pudo encontrar. La gravedad de los hallazgos describe lo que encontró dentro de ese alcance.
- Revisar la gravedad de los hallazgos sin revisar la cobertura del alcance
- Exclusiones del alcance no evaluadas: no se revisa la sección de alcance en busca de sistemas pertinentes excluidos
- Cobertura de la API autenticada no confirmada
- Alcance de la infraestructura en la nube no verificado
- Técnica de prueba no evaluada: automatizada, manual o específica de la aplicación
Cómo se ve una buena práctica
Los programas maduros de gobernanza de las pruebas de penetración definen requisitos de alcance que cubren los sistemas más relevantes para el riesgo del cliente (entornos de API autenticados, infraestructura en la nube y vías internas de movimiento lateral) y exigen técnicas de prueba adecuadas a las clases de vulnerabilidad incluidas en el alcance.
- Requisitos de alcance alineados con el modelo de amenaza: se incluyen la API autenticada, la infraestructura en la nube y las vías internas
- Pruebas autenticadas exigidas: pruebas de los sistemas que requieren autenticación, no solo del perímetro público
- Infraestructura en la nube dentro del alcance: se incluye la evaluación de la configuración de AWS, Azure o GCP
- Pruebas manuales exigidas para los sistemas críticos: pruebas de lógica de negocio y de omisión de autorización realizadas por evaluadores experimentados
- Revisión de la cobertura del alcance antes de aceptar el informe de pruebas: verificar que los sistemas pertinentes están dentro del alcance
Herramientas
Normas de pruebas de penetración: PTES, Testing Guide de OWASP, NIST SP 800-115
Las normas de metodología de pruebas de penetración definen un alcance y unas técnicas de prueba integrales. La Testing Guide de OWASP aborda específicamente las pruebas de autenticación y autorización de aplicaciones web y API, la profundidad de técnica necesaria para detectar las vulnerabilidades que un análisis superficial pasa por alto. Para los profesionales de TPRM, exigir que las pruebas de penetración de los proveedores sigan la metodología OWASP o PTES aporta una base para la profundidad de técnica.
Pruebas de seguridad en la nube: AWS Inspector, evaluaciones de Azure Security Center, pruebas de penetración en la nube por terceros
Las evaluaciones de seguridad específicas de la nube cubren la superficie de ataque de la configuración que las pruebas de penetración tradicionales suelen excluir: configuraciones incorrectas de IAM, políticas de acceso al almacenamiento, ajustes de los grupos de seguridad de red y vulnerabilidades de autenticación nativas de la nube. Para los profesionales de TPRM, exigir que las evaluaciones de la infraestructura en la nube del proveedor se realicen además de las pruebas de penetración de las aplicaciones aporta una pregunta concreta sobre la cobertura de la nube.
Desafíos de gobernanza
El desafío de gobernanza de la profundidad de las pruebas de controles es el equilibrio entre costo y alcance. Una prueba de penetración integral que cubra API autenticadas, infraestructura en la nube, redes internas y varias técnicas de prueba cuesta significativamente más que una prueba externa de caja negra de dos días. Los proveedores que controlan el alcance de sus propias pruebas optarán por defecto por el alcance mínimo que satisfaga el requisito contractual de realizar pruebas de penetración anuales. Los clientes que quieran un alcance más amplio deben especificarlo, ya sea en los requisitos contractuales o en solicitudes de evidencia que incluyan preguntas sobre la cobertura del alcance.
- Revise la sección de alcance antes que la gravedad de los hallazgos en cualquier informe de pruebas de penetración
- Pregunte específicamente si se probaron los endpoints de API autenticados
- Pregunte si la infraestructura en la nube estaba dentro del alcance
- Exija una cobertura de alcance que incluya los sistemas más relevantes para los datos de los clientes
- Distinga la metodología de prueba: análisis automatizado, pruebas manuales o pruebas específicas de la aplicación
Si usted forma parte de un equipo pequeño
En el informe de pruebas de penetración más reciente de su proveedor de mayor riesgo, lea la sección de alcance antes que los hallazgos. Enumere los sistemas y entornos expresamente incluidos y expresamente excluidos. Después pregúntese: ¿el entorno donde se tratan y almacenan los datos de mi organización está dentro del alcance incluido? Si la respuesta es no o no está clara, los hallazgos de la prueba, sea cual sea su gravedad, no describen la seguridad de los sistemas que más le importan.
- Lea la sección de alcance antes que los hallazgos en cualquier informe de pruebas de penetración de un proveedor
- Confirme que los entornos de API autenticados están dentro del alcance
- Confirme que la infraestructura en la nube está dentro del alcance
- Pregunte por la metodología de prueba: automatizada o manual
Qué exigir
Pregunte directamente:
"En su prueba de penetración más reciente, ¿el alcance se limitó a los sistemas expuestos al exterior o incluyó endpoints de API autenticados, la configuración de la infraestructura en la nube y las vías de la red interna? En concreto, ¿los sistemas que tratan y almacenan los datos de nuestra organización estaban dentro del alcance de la prueba?"
Evidencia que debe esperar
- Documentación del alcance de la prueba de penetración, con los sistemas incluidos y excluidos
- Confirmación de que los entornos de API autenticados están dentro del alcance
- Confirmación de la evaluación de la infraestructura en la nube
- Descripción de la metodología de prueba: componentes automatizados y manuales
A un proveedor que aporta un informe de pruebas de penetración limpio se le debe preguntar específicamente si los sistemas que tratan los datos del cliente estaban dentro del alcance de la prueba. El informe describe lo que se encontró en los sistemas probados. El alcance define qué sistemas se probaron.
Cómo demostrarlo
- Evaluación de la cobertura del alcance de los informes de pruebas de penetración de los proveedores
- Confirmación de pruebas de la API autenticada y de la infraestructura en la nube
- Registros de evaluación de la metodología
- Requisitos de alcance en los contratos con proveedores
Conclusión clave
Ningún hallazgo crítico en un alcance limitado no equivale a ninguna vulnerabilidad crítica en el entorno. La prueba de penetración no encontró nada crítico porque la API autenticada donde se tratan los datos de los clientes, la infraestructura de AWS donde se almacenan, la red interna y los sistemas administrativos quedaban todos fuera del alcance. La prueba salió limpia. Los sistemas pertinentes no se probaron. La garantía de las pruebas de penetración está delimitada por su alcance. Leer la sección de alcance antes que la de hallazgos indica lo que la prueba puede decirle sobre la postura de seguridad del proveedor. Leer solo los hallazgos le indica lo que se encontró en los sistemas que el proveedor eligió someter a prueba.