English
Español
Français
Deutsch
日本語
한국어
العربيةLa etapa de validación de CTEM en AWS, con números reales
Puntos clave
- CTEM tiene cinco etapas: alcance, descubrimiento, priorización, validación y movilización. En AWS, los programas suelen atascarse entre la priorización y la validación, con miles de hallazgos ordenados y ninguna prueba de cuáles podría usar un atacante.
- Validar en AWS significa resolver cada ruta candidata contra la autorización que evalúa AWS, en modo de solo lectura. Convierte una lista larga y ordenada en una lista corta y demostrada.
- Números del laboratorio: 4,942 rutas de ataque candidatas. Tras la validación y la ordenación por radio de impacto, una sentencia Deny en un rol eliminó 3,893 de las 4,087 rutas restantes, y dos cambios eliminaron el 80 por ciento del riesgo.
- La movilización necesita tres cosas de la validación: la ruta demostrada, el cambio concreto que la rompe y una confirmación después de desplegar el cambio.
- Continuo significa programado. La validación de solo lectura puede ejecutarse a diario sin ventanas de cambio, así que la deriva se detecta el mismo día en que ocurre.
La gestión continua de exposiciones a amenazas es una estructura de programa con cinco etapas. El alcance decide qué sistemas entran en el programa. El descubrimiento encuentra las exposiciones que hay en ellos. La priorización ordena las exposiciones. La validación demuestra qué exposiciones ordenadas podría usar un atacante. La movilización consigue que las demostradas las arreglen las personas responsables de ellas. La definición está bien cubierta en otros sitios, así que este artículo trata de la cuarta etapa, en AWS, con números de una cuenta real.
Dónde se atascan los programas en AWS
El descubrimiento en AWS está bien cubierto. Un CSPM o un escáner producirá miles de hallazgos en una tarde: buckets públicos, políticas demasiado amplias, claves sin usar, cifrado ausente, roles con confianza comodín. La priorización también está bien cubierta, con puntuaciones de severidad, puntuaciones de explotabilidad y etiquetas de criticidad de activos que ordenan la lista.
El atasco llega en la etapa siguiente. Una lista ordenada de 3,000 hallazgos sigue siendo 3,000 hallazgos, y el orden es una estimación. Un hallazgo crítico en un rol que una SCP ya ha acotado no cambia nada. Un hallazgo medio en un rol que confía en la cuenta de un proveedor puede ser la ruta hacia producción. Sin validación, el equipo elige el trabajo por puntuación, y la puntuación se calculó sin leer la autorización que decide si un ataque funciona.
Cómo es la validación en el plano de control de AWS
En AWS los movimientos del atacante son llamadas a la API. Cada llamada la permite o deniega un conjunto de documentos que AWS evalúa en conjunto: las políticas de identidad de quien llama, cualquier límite de permisos, las políticas de control de servicios de la unidad organizativa, la política de confianza o de recursos del destino y las condiciones de cada sentencia. Validar significa construir la cadena candidata y después resolver esos documentos para cada paso de la cadena, como lo haría AWS. Si todos los pasos se resuelven como permitidos, la ruta está demostrada. Si alguno se resuelve como denegado, la ruta se elimina de la lista.
Nada de eso requiere ejecutar nada. La prueba es el resultado de la autorización, y leer políticas solo necesita acceso de lectura. Eso es lo que hace que la etapa sea continua en la práctica: puede ejecutarse cada día en cada cuenta sin ventana de cambios.
Los números de la cuenta de laboratorio
La cuenta de laboratorio de Pathbreak es el entorno que hay detrás de los números de la página de inicio. Esto es lo que produjo allí la etapa de validación.
| Etapa | Resultado |
|---|---|
| Rutas de ataque candidatas a partir del grafo | 4,942 |
| Rutas en alcance cuando se calculó la solución principal | 4,087 |
| Rutas eliminadas por una sentencia Deny en un rol | 3,893 de 4,087 |
| Riesgo eliminado por los dos cambios principales | 80 por ciento |
| Soluciones que eran un solo comando | 81 por ciento |
Esos números muestran para qué sirve la validación. Miles de rutas candidatas no eran miles de problemas independientes. La mayoría pasaban por los mismos pocos roles, así que un número pequeño de cambios, colocados en los principales correctos, rompió la mayoría de las rutas demostradas de una vez. Una lista ordenada por severidad habría mostrado la misma cuenta como 4,942 elementos de peso más o menos igual y habría enviado al equipo a arreglarlos uno a uno.
Qué necesita la movilización de la validación
La quinta etapa falla cuando la persona responsable del rol recibe un hallazgo sobre el que no puede actuar. La validación debería entregar tres cosas. La ruta demostrada, como una cadena con cada salto nombrado, para que el responsable vea por qué el rol está en ella. El cambio concreto que la rompe: una sentencia Deny, una condición iam:PassedToService, una política de confianza más estrecha, un permiso eliminado, escrito como el cambio en sí, listo para aplicar. Y una confirmación: cuando el cambio se despliega, la ruta se vuelve a evaluar y el resultado queda registrado, para que el ticket se cierre con evidencia.
En el laboratorio, el 81 por ciento de las soluciones eran un solo comando. Eso importa para la movilización porque un cambio de una línea en una política de IAM pasa la revisión en minutos, mientras que un rediseño de una jerarquía de roles se va al trimestre siguiente.
Hacer que la etapa sea continua
Las cuentas derivan con cada despliegue. Un rol nuevo, una política de confianza ampliada, una canalización a la que se le concede iam:PassRole sobre un comodín, y una ruta que se cerró el mes pasado vuelve a estar abierta. La etapa de validación solo sigue siendo útil si se ejecuta de forma programada y reporta lo que cambió, para que el equipo vea las nuevas rutas demostradas el día en que aparecen y las soluciones confirmadas que han vuelto a fallar desde entonces.
La validación de solo lectura hace que eso sea barato. No hay ningún agente, ninguna ventana de cambios ni ningún riesgo para producción derivado de la propia prueba, así que las ejecuciones diarias en todas las cuentas son la opción por defecto.
Qué preguntar a una plataforma de CTEM sobre AWS
¿Resuelve SCP, límites de permisos, políticas de confianza y claves de condición en cada paso de una ruta? ¿Ordena por lo que alcanza una ruta, a través de cuentas? ¿Nombra el cambio que rompe cada ruta, y confirma el cambio después? ¿Puede ejecutarse a diario sin ejecutar nada en la cuenta? Las respuestas te dicen qué entregará la plataforma a tu equipo en la etapa de movilización.
Pathbreak está construido para esta etapa en AWS. El artículo sobre AEV para AWS cubre el método de validación con más profundidad, y el artículo sobre análisis frente a validación recorre una cadena de alcanzable a demostrada.
Preguntas frecuentes
¿Qué es la etapa de validación de CTEM?
La validación es la cuarta etapa de la gestión continua de exposiciones a amenazas. Toma las exposiciones priorizadas del descubrimiento y demuestra cuáles de ellas podría usar un atacante para llegar a algo que importa, de modo que la movilización trabaje sobre rutas demostradas. Pathbreak cubre la etapa de validación para AWS.
¿En qué se diferencia la validación de la priorización?
La priorización ordena los hallazgos por severidad estimada, explotabilidad o valor del activo. La validación prueba si la ruta que pasa por un hallazgo funciona, en AWS resolviendo la autorización completa en cada paso. Un hallazgo de alta prioridad puede fallar la validación, y uno medio puede estar en la ruta demostrada más dañina. Pathbreak ordena las rutas demostradas según lo que alcanzan entre cuentas.
¿La validación de CTEM en AWS requiere una prueba de penetración?
No. En el plano de control de AWS cada movimiento del atacante es una llamada a la API que deciden documentos de política, así que la prueba se puede producir en modo de solo lectura resolviendo esos documentos. Las pruebas manuales siguen siendo valiosas para la lógica de aplicación y para las partes de un entorno que quedan fuera del plano de control. Pathbreak produce esta prueba en modo de solo lectura y complementa las pruebas manuales.
¿Con qué frecuencia debería ejecutarse la etapa de validación?
A diario para las cuentas de AWS que cambian a menudo, que son la mayoría. La validación de solo lectura no tiene riesgo operativo, así que puede ejecutarse de forma programada y reportar nuevas rutas demostradas y soluciones que han vuelto a fallar a medida que aparecen. Pathbreak la ejecuta a diario de forma predeterminada.
Ejecuta la etapa de validación en tus propias cuentas de AWS y mira las rutas demostradas, ordenadas por lo que alcanzan.
Solicitar una demo Ver la demo