La superficie de ataque de una empresa la integran todas las maneras en las que un agresor puede acceder a los datos confidenciales de la empresa y poner en peligro las aplicaciones que su organización está tratando de proteger. Hay cientos de diferentes tipos de ataques que un delincuente puede aprovechar para obtener acceso a una organización, desde credenciales comprometidas e ingeniería social hasta técnicas más avanzadas, como utilizar una vulnerabilidad de día cero.
Por desgracia para los buenos, los criminales sólo necesitan encontrar un punto débil y aprovecharse de él para abrirse paso dentro de nuestra empresa. Y son cientos las vías de ataque entre las que pueden elegir. Ante esto, ¿qué podemos hacer? Trabajar para reducir nuestra superficie de ataque y hacer que sea lo más pequeña posible, limitando de este modo el número de puntos en los que se pueden emplear factores de ataque. Esta estrategia funciona tanto para despliegues de nube pública como en cualquier otra parte de nuestra organización.
Hay cuatro puntos clave en la superficie de ataque de una nube pública en los que conviene trabajar:
1. Plataformas
2. Cargas de trabajo
3. Conectividad de entrada
4. Conectividad de salida
1. Plataformas
Debemos empezar por conocer la postura de seguridad de la(s) plataforma(s) de base de su nube. Si estamos utilizando una de las tres principales plataformas (AWS, Azure , GCP), nuestra preocupación debería girar en gran medida en cómo estas plataformas se utilizan por nuestra organización más que en la seguridad de las propias plataformas. Estos proveedores han invertido enormes cantidades de recursos en seguridad, han pasado por todas las certificaciones disponibles y sus plataformas han sido probadas por decenas de miles de organizaciones y empresas de todo los sectores y tamaños.
Sin embargo, lo que no pueden garantizarnos es que nuestra organización haya configurado de forma segura sus numerosas funciones y servicios. Si buscamos el término “AWS S3 exposure”, encontraremos muchos artículos sobre empresas que han cometido errores de configuración desastrosos, lo que ha provocado incidentes dolorosos y costosos.
Para analizar nuestras configuraciones, debemos comenzar por realizar un inventario exhaustivo de todo lo que hay en nuestro nube, incluyendo IaaS, PaaS, contenedores, serverless y más. Dado que las plataformas en la nube son dinámicas, no podemos olvidarnos de realizar una supervisión continua para estar siempre al tanto de los cambios.
A partir de ahí, debemos mapear ese inventario con el conjunto de políticas que nuestra organización haya puesto en marcha para minimizar el riesgo de exposición resultante de una configuración poco segura de una plataforma en la nube. Obviamente, no querremos exponer públicamente los buckets de S3/almacenamiento, pero hay otra serie de políticas que podemos aplicar y que contribuirán en gran medida a eliminar nuestra exposición a los cientos de vectores de ataque mencionados anteriormente.
Por último, y siempre que sea posible, se debe poner en marcha una corrección automática. Esto ayudará a garantizar que, cuando se produzcan cambios, nuestra configuración se mantenga acorde con nuestras políticas.
2. Cargas de trabajo
Incluso si hemos configurado correctamente la plataforma en la nube, el uso de la segmentación de la carga de trabajo basada en identidades es fundamental para reducir, todavía más, la superficie de ataque lateral, y poder para detener así el peligroso movimiento lateral de las amenazas. Este paso reduce de manera significativa el daño potencial que los atacantes pueden causar si llegan a abrirse paso en la nube.
Los delincuentes pueden causar estragos en aquellas redes planas que permiten un movimiento lateral sin control. Pero segmentar una red utilizando el enfoque típico de políticas de firewall basadas en la red, es inmanejable, lo que conduce a errores humanos y a exponer cargas de trabajo.
La verificación de la identidad de la carga de trabajo garantiza que se está limitando el acceso solo a las aplicaciones y servicios conocidos, y asegurando que se está verificando el software correspondiente hasta el nivel de subproceso. Por ejemplo, no basta con permitir o bloquear los scripts de Python, hay que permitir aquellos específicos que se necesitan para que las aplicaciones funcionen correctamente, y bloquear todo lo demás.
A partir de ahí, la segmentación basada en identidades garantiza la neutralización de todas las rutas de red que no sean necesarias para el correcto funcionamiento de las aplicaciones empresariales. ¿El resultado? Solo el software conocido y verificado puede comunicarse, y solo donde sea absolutamente necesario hacerlo en rutas autorizadas.
3. Conectividad entrante
El acceso remoto en régimen de confianza cero se ha convertido rápidamente en el método preferido para la conectividad remota de los usuarios, y el acceso de carga de trabajo en la nube no es una excepción. Gracias a la confianza cero (Zero Trust), las aplicaciones nunca quedan expuestas en Internet, haciéndolas invisibles para los usuarios no autorizados. La invisibilidad es un súper poder que todo el mundo quiere, y la confianza cero lo consigue.
Tanto si se trata de un usuario privilegiado que gestiona una aplicación con Secure Shell (SSH), como de un socio comercial que accede a una aplicación basada en la web, la confianza cero permite proporcionar acceso a las aplicaciones, no a la red, limitando así las posibles amenazas externas. Con esta técnica, ni siquiera los usuarios autorizados disponen de acceso ilimitado a la red. Solo tienen acceso a las aplicaciones que necesitan para hacer su trabajo, y nada más.
4. Conectividad saliente
Hay dos formas de conectividad para la mayoría de las cargas de trabajo en la nube: de la nube a Internet y de la nube a otras nubes o centros de datos privados.
Las cargas de trabajo en la nube exigen acceso a Internet por diversas razones, desde los servicios de actualización de software a la conectividad API con otras aplicaciones. Lamentablemente, proporcionar acceso directo a Internet supone un mayor riesgo. Asegurarse de que el acceso a Internet pasa por un intermediario de seguridad que puede analizar el malware y otras formas de tráfico malicioso, puede reducir el riesgo de un ataque basado en Internet.
Las comunicaciones seguras con otras nubes y centros de datos son otro de los aspectos importantes a la hora de minimizar la superficie de ataque de nuestra nube. Al igual que con el acceso de usuarios, deben aplicarse los principios de confianza cero, garantizando que las aplicaciones puedan conectarse de forma segura a otras aplicaciones, no a las redes. Al eliminar la conectividad de red abierta, podemos asegurarnos de que incluso si una aplicación se ve comprometida, la capacidad del atacante para hacer daño a través de su huella en la nube está muy limitada.
