Ha estado pensando en realizar una prueba de penetración en su entorno de Amazon Web Services (AWS). ¡Estupendo! ¿Qué debería incluir eso exactamente?

Hay muchas opciones disponibles y saber lo que necesita le ayudará a obtener su presupuesto de seguridad a menudo limitado en la medida de lo posible. En términos generales, las áreas clave de interés para la mayoría de las pruebas de penetración que involucran a AWS son:

• Su infraestructura de nube disponible externamente
• Cualquier aplicación que cree o aloje
• Su infraestructura de nube interna
• Su propia configuración de AWS
• Gestión de secretos

Veamos cada uno de ellos, empezando por el más importante:

Infraestructura externa

La buena noticia es que, de manera predeterminada, AWS hace todo lo posible para ayudarlo a mantenerse seguro. Por ejemplo, los grupos de seguridad predeterminados no permiten que sus instancias EC2 reciban tráfico de fuera del mundo, a menos que lo especifique activamente agregando reglas adicionales.

Esto significa que AWS aún le brinda mucha cuerda a la que aferrarse si no tiene cuidado. Los errores clásicos, como cambiar los equipos de seguridad en los equipos técnicos para permitir todo el acceso entrante, siguen siendo un problema, y ​​la naturaleza de DevOps significa que los servicios pueden ir y venir regularmente, no siempre con el conocimiento de los gerentes de equipo.

Sin embargo, no hay manera más fácil para que un pirata informático lo comprometa que encontrar una vulnerabilidad de seguridad simple que falta en su infraestructura orientada a Internet, ya sea una base de datos expuesta o un software con vulnerabilidades conocidas. Los atacantes tienen la máxima recompensa por el mínimo esfuerzo, por lo que esta es la probabilidad más alta: este debería ser su primer lugar para llamar.

Hacer un seguimiento de la gestión de vulnerabilidades en la nube puede ser un desafío debido a la naturaleza dinámica de estos sistemas y los cambios constantes en su entorno, con nuevas vulnerabilidades que se publican diariamente. Sin embargo, las soluciones modernas de análisis de vulnerabilidades, como Intruder, se adaptan a su entorno de nube. Antes de ejecutar una prueba de penetración, debe considerar usar una de estas herramientas, ya que ayudan a administrar las vulnerabilidades en su infraestructura de manera continua a través de verificaciones automáticas.

Un intruso puede sincronizar los objetivos de los principales proveedores de la nube y mantener sus objetivos sincronizados a medida que se agregan nuevos sistemas a sus cuentas en la nube utilizando CloudBot. Esto garantiza que los nuevos sistemas se incluyan en futuros análisis de vulnerabilidades.

Debido a que esta es su superficie de ataque más expuesta, probablemente no desee eliminar su infraestructura externa del alcance de ninguna prueba de penetración. Y, sin embargo, no debe asignar una gran parte de su presupuesto a esto, si es posible, y no espere ver muchos resultados más allá de lo que esperaba de sus herramientas de análisis de vulnerabilidades.

Aplicación web

Muchas empresas utilizan AWS para alojar aplicaciones web para clientes, empleados o socios. Desafortunadamente, las aplicaciones web diseñadas para ser expuestas son intrínsecamente la segunda forma más fácil para que los atacantes ingresen a sus sistemas, a menos que se desarrollen de forma segura. Esto los convierte en el segundo ataque más importante después de su infraestructura externa.

Ejemplos de tales ataques incluyen el incidente de Kaseya de 2021, en el que los atacantes comprometieron con éxito a Kaseya y distribuyeron ransomware a sus clientes como parte de un ataque a la cadena de suministro. El sitio de redes sociales de derecha Gab también se vio comprometido a principios de 2021 y se filtraron 70 GB de datos confidenciales de usuarios debido a vulnerabilidades de incrustación de SQL. Yendo aún más lejos, el famoso hacker TalkTalk, un cliente de 17 años, pudo acceder a su base de datos de clientes y extraer millones de registros.

Considere siempre el impacto y la probabilidad de un ataque en esta capa. Al tomar su decisión, debe tener en cuenta si su aplicación es completamente accesible al público o solo a un grupo limitado de clientes. Por ejemplo, una aplicación con «pruebas gratuitas» permitirá que un atacante se registre y comience a trabajar. Los servicios B2B para clientes/socios de pago pueden tener un perfil de amenazas más bajo, aunque aún no despreciable, y las aplicaciones de los empleados aún son más bajas. Por otro lado, algunas aplicaciones contienen información tan sensible que el impacto puede superar considerablemente la probabilidad.

Entonces, dependiendo del perfil de riesgo de su aplicación, es posible que descubra que si puede permitirse que los probadores de penetración solo trabajen durante unos días, es muy probable que deba pasar tiempo aquí. Si bien existen herramientas automatizadas para este tipo de pruebas y pueden ser útiles para cubrir la brecha entre las pruebas de penetración, nada en el mercado actual reemplazará la calidad de un evaluador humano que comprenderá la lógica comercial de su aplicación y buscará formas de influir en ella. . .

Intruder usa un algoritmo único para priorizar los problemas que dejan sus sistemas expuestos, lo que hace que sea especialmente fácil determinar qué representa el mayor riesgo.

Infraestructura interna

La siguiente capa de ataque es la infraestructura donde se construye su aplicación. Después de cubrir la infraestructura externa, solo se puede acceder al lado interno si el atacante ya ha violado su defensa de alguna manera. El perfil de amenaza es por tanto secundario a los dos anteriores.

Las antiguas pruebas de penetración de centros de datos o redes corporativas a menudo giran en torno a obtener una posición firme y luego «pivotar» de un sistema a otro, lo que finalmente conduce a una amenaza total para las cuentas del administrador o los sistemas críticos. Aquí, sin embargo, el entorno de AWS puede diferir de las pruebas de penetración tradicionales, porque la naturaleza definida por software de las redes de AWS a menudo significa que se mantienen controles más estrictos entre las redes y el movimiento lateral es un desafío. Por ejemplo, una vez más, los grupos de seguridad predeterminados «launch-wizard-#» no permitirán que sus instancias EC2 se comuniquen entre sí a menos que las especifique activamente al agregarlas a la VPC o agregar reglas adicionales. Sin embargo, todas las cuentas de AWS, excepto las más simples, pasan por estas configuraciones simples. Además, como lo demostró la violación de Capital One en 2019, los atacantes podrían comprometer las credenciales de IAM y usarlas para acceder a los recursos.

Además, los controles de seguridad y acceso integrados en AWS significan que es mucho menos probable que tenga cuentas de «administrador» comprometidas en todo el entorno a través de cualquiera de sus instancias EC2. En su lugar, es más probable que utilice cuentas de AWS con privilegios, por lo que la verificación de la configuración de AWS puede agregar mucho más valor que una prueba de infraestructura «interna».

Del mismo modo, si bien el software no reparado y los servicios inseguros en los sistemas internos pueden ser un problema, depende de hasta qué punto haya creado redes privadas en su entorno de AWS y qué sistemas tienen acceso a otros. También vale la pena entenderlo si tiene una VPN punto a punto entre su red local y los entornos en la nube. Si lo hace, puede ser apropiado realizar una prueba de penetración interna para ver si un atacante puede cerrar la brecha entre las dos redes.

Cuanto más complejo sea, más valor añadido puede tener el test de penetración interna. Por ejemplo, suponga que ejecuta varios EC2, cada uno con su propio equipo de seguridad, o utiliza algunos servicios de AWS administrados/compartidos, como las funciones lambda; es posible que desee omitir la prueba de penetración «interna» tradicional y considerar una configuración en lugar de una revisión.

Configuración de AWS

Como se mencionó, AWS hace mucho por usted en términos de seguridad, pero verificar la configuración de AWS puede decirle si ha configurado las cosas de manera sólida.

Los ejemplos clásicos de configuraciones deficientes de AWS son los cubos S3 de los que escucha con frecuencia o la falta de autenticación multifactor para acceder a la consola de AWS. Sin embargo, también puede incluir cosas como cuentas de administrador a las que acceden demasiados usuarios o reglas de IAM más complejas, por ejemplo, cómo una política de acceso de solo lectura puede permitir que un atacante obtenga privilegios adicionales en su entorno.

Nuevamente, esto a menudo puede llevarlo a pagarle a alguien para que le diga lo que ya sabe (o lo que podría averiguar fácilmente). Antes de realizar la prueba de penetración, pruebe algunas herramientas gratuitas (una búsqueda rápida en Google le dará varias opciones). La metodología es probablemente la misma y es posible que ya tenga las respuestas a sus preguntas.

Si no está seguro de las apuestas de seguridad o necesita una auditoría de cumplimiento de terceros, es valioso ponerse en contacto con un experto en seguridad cibernética como Intruder para averiguar cómo pueden ayudarlo.

Gestión de secretos

La gestión de secretos es la forma en que las personas y las aplicaciones almacenan y utilizan los secretos, como los tokens de acceso. Está al final de nuestra lista, pero cubre todas las áreas anteriores y merece atención. La verificación de configuración de AWS debe incluir e informarle sobre cómo sus usuarios y servicios acceden y se comunican con su entorno de AWS, incluidos los permisos asignados a esos usuarios y servicios. Sin embargo, es posible que esta verificación de configuración solo pueda evaluar la configuración en su cuenta de AWS, lo que significa que puede pasarse por alto en la administración de secretos de proceso.

¿Tus equipos utilizan integración continua o despliegue continuo (CI/CD)? Si es así, es probable que la canalización utilizada durante el proceso de CI/CD tenga un nivel de integración en sus entornos de AWS. Por ejemplo, es posible que necesiten iniciar nuevas instancias de EC2 o implementar una nueva Lambda. ¿Cómo guardan secretos sus aplicaciones o servicios internos que se integran en su entorno? ¿Cómo guardan los secretos sus administradores?

Si un atacante obtiene acceso a estos secretos, tendrá acceso a su entorno de AWS y podrá escalar los permisos o mantener el acceso al entorno de la nube una vez que se eliminen de su red interna.

Por lo tanto, si está considerando una prueba de penetración de su entorno de AWS, puede estar interesado en incluir la configuración de otros sistemas de integración en la prueba. Alternativamente, puede dividir el proceso en múltiples herramientas/evaluaciones y enfocarse en áreas de riesgo individuales. Verificar la configuración de AWS le permite comprender cuántas cosas se conectan a su entorno de AWS mediante claves de acceso y la API de AWS.

Conclusión

Las pruebas de penetración en AWS deben manejarse con cuidado, ya que sería fácil gastar tiempo y dinero en los lugares equivocados. AWS es un gran ecosistema y es difícil cubrir toda la cantidad cada vez mayor de servicios en una sola evaluación en un momento dado, especialmente si tiene una presencia significativa de AWS. El uso sensato de la automatización siempre debe venir antes de las costosas horas de asesoramiento y, cuando sea necesario, siempre debe usarse de la manera más económica posible. Puede encontrar que la forma más rentable es un enfoque híbrido; proporciona acceso a su configuración de AWS, que puede informar y realizar una inspección manual de sus activos completos de AWS.

Escáner de vulnerabilidades de intrusos

Intruder es una plataforma de escaneo de vulnerabilidades basada en la nube que se utiliza para verificar vulnerabilidades conocidas en su entorno de AWS para reducir el área de ataque.

Intruder ofrece una prueba gratuita de 30 días de su plataforma. Haga clic aquí para probar hoy.