Puntos ciegos de seguridad en la nube: dónde están y cómo protegerlos

Los expertos en seguridad analizan áreas de la seguridad en la nube que a menudo se descuidan y ofrecen orientación a las empresas que trabajan para fortalecer su postura de seguridad.

CONFERENCIA RSA 2021: la adopción de la nube empresarial brinda innumerables beneficios, riesgos, desafíos y oportunidades, tanto para las organizaciones como para los atacantes que los atacan. Incluso los usuarios veteranos de la infraestructura y los servicios en la nube podrían aprender un par de cosas sobre el fortalecimiento de la seguridad. 

(imagen recogida, a través de Adobe Stock)

Dado el año que precedió a la Conferencia RSA totalmente virtual de este año, durante el cual las empresas se volvieron muy dependientes de los servicios en la nube y lucharon por asegurar equipos completamente remotos, en medio de la pandemia de COVID-19, no fue una sorpresa que la seguridad en la nube fuera un tema candente. Los oradores exploraron las lagunas que con frecuencia se pasan por alto y ofrecieron orientación práctica sobre cómo mitigar los riesgos. 

Uno de estos puntos ciegos es la gestión de identidad y acceso (IAM) en la nube, dijo Matthew Chiodi, director de seguridad de la nube pública en Palo Alto Networks, en su charla RSAC sobre el tema. Una cuenta de nube genérica puede tener dos roles y seis políticas asignadas a cada uno, pero en la mayoría de los casos es mucho más complejo y desafiante determinar lo que alguien puede y no puede hacer. 

En la mayoría de las cuentas de producción que ha visto Chiodi, “por lo general son cientos de roles y tal vez incluso miles de políticas”, dijo. “Se vuelve realmente difícil entender lo que llamamos permisos netos efectivos”. El problema se magnifica a medida que las organizaciones utilizan más cuentas en la nube.

Para tener una mejor idea de cuán extendido está el problema, Palo Alto Network recopiló “un conjunto de datos masivo y masivo” de datos de Github disponibles públicamente: 283,751 archivos y 145,623 repositorios, de los cuales pudieron extraer 68,361 nombres de roles y 32,987 potenciales en la nube. cuentas. Los investigadores tomaron los 500 nombres de roles más comunes, con listas de cuentas en la nube validadas, y utilizaron diferentes combinaciones para encontrar posibles errores de configuración.

Lo que encontraron es que con estas configuraciones erróneas, podrían haber tenido acceso a miles de instantáneas de EC2, cientos de cubos de S3 y una gran cantidad de claves KMS e instantáneas de RDS, dijo. 

“Cuando tiene una cuenta en la nube comprometida debido a uno de estos tipos de configuraciones incorrectas, casi siempre es mucho peor que un host en la nube comprometido”, dijo Chiodi.

Un atacante que puede comprometer un solo host podría aprovechar un error y acceder a los datos, pero generalmente están limitados si se realiza la segmentación de la red. En el caso de estos hallazgos, los parches y la autenticación multifactor no importarían porque “[un atacante] puede sortear todas esas cosas cuando tiene una configuración incorrecta basada en la identidad en el nivel de CSP”. 

Los riesgos de la infraestructura como código La
infraestructura como código (IaC), una forma de administrar y aprovisionar infraestructura a través de código en lugar de procesos manuales, “está realmente floreciendo para la mayoría de las organizaciones”, dijo Chiodi. Si bien presenta beneficios para los equipos de seguridad, esta estrategia también conlleva riesgos. 

Palo Alto Networks encuestó a casi un millón de plantillas de IaC que se encuentran en Github. Descubrieron que el 42% de los usuarios de plantillas de AWS CloudFormation tienen al menos una configuración insegura y más de las tres cuartas partes de las cargas de trabajo en la nube exponen SSH. El sesenta por ciento tiene deshabilitado el registro de almacenamiento en la nube. En el 43% de las organizaciones que configuran bases de datos nativas de la nube a través de IaC, el cifrado en la capa de la base de datos está completamente deshabilitado. 

“Descubrimos que cuando las organizaciones confían en la infraestructura como código para crear sus límites de seguridad externos e incluso internos, el 76% de las veces exponen puertos sensibles como SSH directamente a Internet”, dijo. 

Para Terraform, que permite a las organizaciones utilizar plantillas de IaC de múltiples nubes en todos los principales proveedores de servicios en la nube, las cifras fueron menores pero persistieron las “inconsistencias consistentes”. Más del 20% de todos los archivos de configuración de Terraform tenían al menos una configuración insegura; en el 67%, se deshabilitó el registro de acceso para los buckets de S3; más de la mitad tenía deshabilitado el control de versiones de objetos.

Derramar secretos en la nube
Si bien la mayoría de los profesionales de la seguridad saben que la exposición accidental de datos es un problema común de seguridad en la nube, muchos no saben cuándo les está sucediendo. Este fue el meollo de una charla de José Hernández, investigador principal de seguridad, y Rod Soto, ingeniero principal de investigación de seguridad, ambos con Splunk, quienes exploraron las formas en que los secretos corporativos se exponen en los repositorios públicos.

En los entornos actuales, las credenciales están en todas partes: pares de claves SSH, tokens de Slack, secretos de IAM, tokens de SAML, claves de API para AWS, GCP y Azure, y muchos otros. Un escenario de riesgo común es cuando las credenciales no están protegidas adecuadamente y se dejan expuestas, con mayor frecuencia en un repositorio público: Bitbucket, Gitlabs, Github, Amazon S3 y Open DB, son los principales repositorios públicos de software.

“Si usted es un atacante y está tratando de encontrar a alguien que, ya sea por omisión o negligencia, tenga credenciales incrustadas que puedan reutilizarse, estas serían sus fuentes de credenciales filtradas”, dijo Soto, y señaló que pueden ayudar a los atacantes a cambiar de punto final. y la nube.

Los investigadores de Splunk encontraron que hay 276,165 compañías con secretos filtrados en Github. Los más filtrados fueron los tokens de cuentas de servicio de GCP, que se observaron en el 34% de los casos, seguidos de la “contraseña en la URL” (30%) y las claves de API de AWS (12,7%). Cuando vieron secretos filtrados, tomó un promedio de 52 días para que el secreto fuera eliminado del proyecto Github, dijo Hernández.

Más organizaciones tienen un “perímetro convergente”, un término que usó para definir entornos con activos tanto detrás de una puerta de enlace de Internet, como DevOps e ITOps, como en la nube. Hay varias tácticas, técnicas y procedimientos de atacantes (TTP) que se deben vigilar en estos entornos. 

Uno es la creación de claves temporales o permanentes. “Hemos visto casos, por ejemplo, en los que los desarrolladores tenían claves raíz en un entorno de AWS, y eso es bastante malo”, dijo Soto. “Nunca debes dar claves raíz; tienes que hacer cumplir la segregación de funciones y el principio de privilegio mínimo … una vez que tienes una clave raíz, puedes hacer lo que quieras y tomar el control”, agregó.

Otros TTP incluyen la creación de políticas de confianza y adjuntar una política a un rol en AWS, y secuestrar tokens temporales como OAuth2 en GCP, dijeron los investigadores. Los usuarios de Azure deben estar atentos a la creación de un nuevo dominio federado y una entidad de servicio. Aquellos con servicios de federación de Active Directory, Azure y AWS deben prestar atención a la aserción SAML falsificada, agregó.

Detección de ataques y estrategias defensivas
No es ningún secreto que detectar actividad maliciosa es más difícil en la nube, una verdad que se atribuye en parte a la incertidumbre de las malas acciones, dijo Alfie Champion, consultor de defensa cibernética de F-Secure Consulting, en una charla de RSAC sobre detección de ataques. Obviamente, menos acciones en la nube son malas.

“El contexto es cada vez más clave cuando se trata de la detección de nubes”, dijo Champion. “Con gran parte de esta interacción API, comprender una acción, la intención detrás de una acción y el contexto de la misma puede ser crucial para crear detecciones de alta fidelidad”.

Un error común que las organizaciones cometen cuando cambian a la nube es agregar telemetría sin contexto. No hay forma de saber a qué cuenta pertenece un registro, y no hay forma de que un analista acceda a una cuenta para comprender qué sucede cuando realiza una investigación. “Lo que es malo en una cuenta podría ser bueno en otra, y se necesita ese contexto para resolverlo”, señaló.

Muchos pasan por alto los registros de autenticación, que interactúan entre las instalaciones y la nube, así como las interfaces de administración. Es probable que las organizaciones más grandes administren varias cuentas en la nube, y probablemente de manera federada, agregó. Estos registros proporcionarán una correlación significativa para los eventos que ven.

Vale la pena señalar que el registro y la detección de amenazas se ven diferentes para cada uno de los principales proveedores de nube, y es posible que los administradores deban tomar medidas adicionales para asegurarse de que reciben los datos que desean. El registro de flujo, que indica de dónde proviene el tráfico, hacia dónde se dirige y cuántos datos se transfieren, puede indicar una actividad potencialmente maliciosa pero no está habilitado, señaló Brandon Evans, ingeniero de seguridad senior de Zoom Video Communications en su charla RSAC.

“Ninguno de los tres grandes proveedores de nube tiene el registro de flujo habilitado de forma predeterminada”, dijo, y señaló que los clientes deben optar explícitamente y definir una política de retención de registros. AWS, Azure y GCP tienen diferentes retrasos entre la activación y la recepción de registros, y diferencias en los períodos máximos de retención de registros, el soporte de la línea de comandos y el registro del tráfico de entrada bloqueado, dijo. 

Evans instó a las empresas a asegurarse de que están capturando API de nube y registros de flujo de red para cada proveedor de nube que utilizan. A largo plazo, a medida que encuentren debilidades en la infraestructura y la configuración de la nube, deberían trabajar con la ingeniería para fortalecer los permisos y utilizar el principio de privilegios mínimos.

“Si podemos bloquear los ataques por completo, deberíamos hacerlo”, dijo. “Sin embargo, siempre será necesario monitorear y alertar para encontrar las debilidades que aún no hemos identificado y solucionado”.

Es útil para las empresas diseñar una “pila de detección en la nube”, que puede ayudar a ingerir los registros correctos y presentarlos de la manera correcta. Nick Jones, consultor senior de seguridad de F-Secure, señaló en su charla con Champion que si bien a la industria le gusta hablar de un “panel único” para esta práctica, él cree que esto es “útil, pero quizás no necesario”. 

“Lo realmente crítico aquí es que los ataques rara vez ocurren de forma aislada en un solo entorno”, dijo. “Es probable que un atacante intente pivotar o moverse lateralmente desde su propiedad local a la nube, o viceversa, o entre dos entornos”.

Dado esto, continuó, los analistas deberán mirar los registros de una fuente de datos y pasar a la siguiente. Si bien hay muchas fuentes de datos con las que trabajar, Jones recomendó priorizar los registros de auditoría del plano de control como CloudTrail y Audit Log para tener visibilidad de todas las acciones administrativas. Los registros específicos del servicio, como los registros de acceso al almacenamiento, las ejecuciones de funciones y el acceso a la clave KMS, también son fundamentales, ya que muestran el acceso y el uso de recursos y servicios específicos.

Nunca es demasiado pronto para modelar amenazas y probar escenarios ofensivos, dijo Champion. ¿Cómo apuntaría un atacante a uno de sus activos? ¿Cómo subvertiría sus propios controles de seguridad? Aconsejó identificar los datos críticos de la organización, considerando los objetivos y puntos de partida del atacante y, a partir de ahí, priorizar la ruta del ataque. ¿Cuál podría ser su objetivo final? Kelly Sheridan es la editora de personal de Dark Reading, donde se centra en noticias y análisis de ciberseguridad. Es una periodista de tecnología empresarial que anteriormente reportó para InformationWeek, donde cubrió Microsoft, y Seguros y tecnología, donde cubrió finanzas … Ver biografía completa

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *