Tengo la suerte de ser padre de dos niños que todavía tienen edad para sentirse atrapados por los cuentos, así que me voy a conceder la licencia de explicar en forma de relato el viaje desde el mundo on-premise hacia el cloud en el que estamos embarcados desde hace más de una década. Un camino que no ha hecho más que acelerarse con la pandemia, dada la necesidad de proporcionar servicios virtuales para garantizar la continuidad de los negocios.

Érase una vez un país llamado On-Premitia, en el que todos sus habitantes vivían encerrados en casas muy bien aisladas. Cada hogar contaba con la figura de un casero, que se encargaba de velar por la seguridad del perímetro. También se encargaba de gestionar las visitas que se podían realizar, tanto a la vivienda como al exterior, para obtener servicios necesarios pero que no estaban disponibles en el hogar.

Evidentemente, las amenazas existían, pero se limitaban a ataques externos que normalmente podían contenerse mediante el control de daños.

El mundo era relativamente seguro, pero extremadamente aburrido y estático, y la obtención de nuevos servicios representaba un gran reto temporal, tanto en el desarrollo como en la comercialización.

Un día, Cloudio, uno de los habitantes de On-Premitia, tuvo una idea: “Crearé —se dijo— un gran mercado en la plaza central donde cualquier habitante pueda trabajar, desarrollando nuevas ideas y productos que cualquier ciudadano pueda consumir ahí mismo”. Pronto se dio cuenta de que se podrían mejorar mucho los tiempos si se contaba además con una infraestructura común que eliminara las tareas de desarrollo y producción más básicas y repetitivas, y que él mismo podía ofrecer nuevos proveedores de servicios.

Es imprescindible trasladar la seguridad al origen del problema, con el fin de cubrir también la cadena de suministro

El resultado fue espectacular: su infraestructura de base triunfó y una multitud de trabajadores comenzaron a desarrollar en tiempo récord nuevos productos y servicios, que se actualizaban constantemente con todo tipo de mejoras. El rey de On-Premitia, muy satisfecho con el resultado, decidió renombrar el país, que a partir de entonces se llamó Clouditia.

Sin embargo, las cosas no fueron tan bien como todos esperaban: las amenazas comenzaron a multiplicarse. Ahora los delincuentes podían atacar no solo los servicios o productos finales, sino también la propia infraestructura que soportaba el mercado común, lo que les permitía replicar los ataques con gran eficacia. Los caseros ya no sabían cómo proteger el mercado y el caos reinaba en Clouditia, cuyos habitantes clamaban por un nuevo modelo de seguridad.

Cloud y fallos de seguridad

Tal y como muestra el informe Cloud Threat Report – 2H 2021, de la unidad de ciberinteligencia de Palo Alto Networks (Unit42), en las amenazas cloud más actuales los errores de configuración del equipo de DevOps son tan graves como los problemas de la cadena de suministro (supply-chain). Esa fue la brecha que empleó el red team de la Unit42 para poder vulnerar varias aplicaciones finales a través del ataque a la cadena de suministro (por ejemplo, la infraestructura SaaS que las sustentaba). De hecho, los investigadores descubrieron que el 63% del código de terceros reutilizado para crear la infraestructura de la cloud contiene fallos de seguridad.

El 96% de los contenedores de terceros desplegados en la nube contienen vulnerabilidades conocidas

Yendo más allá, descubrieron que el problema es aún más grave en el caso de los contenedores, ya que el 96% de los contenedores de terceros desplegados en la nube contienen vulnerabilidades conocidas. El reto es que el código reutilizado puede provenir de cualquiera, incluso de grupos maliciosos que crean y distribuyen APT (advanced persistent threat) de esta manera, aprovechando que los paquetes de terceros se importan constantemente a través de plantillas IaC (infrastructure as code) y que las organizaciones no siempre los inspeccionan lo suficiente.

Para prevenir adecuadamente estas amenazas es imprescindible trasladar la seguridad al origen del problema, en lo que se ha denominado shift-left, con el fin de cubrir también la cadena de suministro. En este sentido, la CNCF (Cloud Native Computing Foundation) ha publicado una muy recomendable guía de buenas prácticas, entre las que incluye trabajar en la seguridad de las siguientes cinco áreas: código fuente, materiales, ciclos de desarrollo, artefactos y despliegues.

Ya no basta con auditar y proteger el código final: resulta asimismo imprescindible trabajar en toda la cadena de suministro:

  • Definiendo la estrategia de seguridad shift-left.
  • Entendiendo dónde y cómo se crea el software de la organización.
  • Implementando guardarraíles de seguridad dentro del proceso de revisión de la calidad.

En este escenario, Prisma Cloud de Palo Alto Networks ofrece una solución integrada para proteger todo el ciclo de vida del desarrollo, incluida la cadena de suministro, así como los datos y las tecnologías en entornos de múltiples nubes o nube híbrida. El enfoque integrado de esta plataforma hace posible que los equipos de operaciones de seguridad y DevOps sigan siendo ágiles, colaboren eficazmente y aceleren el desarrollo y la implantación de aplicaciones nativas de la nube de forma segura.

Flujo de ataque a la cadena de suministro

  • Paso 1. Reconocimiento. Los atacantes necesitan identificar cómo opera una organización y para ello escanean cualquier infraestructura conocida como código (IaC) asociada al cliente y a los empleados que trabajen para él. Asegurar adecuadamente las credenciales de IAM debería ser una preocupación clave para las organizaciones.
  • Paso 2. Acceso inicial. Los atacantes intentarán obtener acceso a la infraestructura de nube del proveedor aprovechando debilidades como las credenciales IAM identificadas durante el reconocimiento. También tratarán de aprovecharse de configuraciones incorrectas dentro de las plantillas IaC del proveedor, o de vulnerabilidades dentro de las aplicaciones y contenedores alojados en la nube.
  • Paso 3. Movimiento lateral. Una vez hayan obtenido acceso a un sistema alojado en la nube, comenzarán el proceso de expansión al intentar ubicar la canalización de CI (continuous integration) de la organización. Para ello, en lugar de moverse lateralmente a sistemas separados físicamente, el atacante se mueve entre un sistema virtual y el sistema físico que aloja ese sistema virtual.
  • Paso 4. Ataque al ciclo de CI. Una vez localizada la canalización de CI, los atacantes deberán obtener acceso al servicio de gestión. Esto requerirá explotar una vulnerabilidad o contar con la capacidad de hacerse pasar por un usuario legítimo mediante el uso de credenciales comprometidas o robadas.
  • Paso 5. Envenenamiento. Con acceso a la canalización de CI los atacantes pueden afectarla de varias maneras, incluidos los componentes de “envenenamiento” de la aplicación SaaS. Un componente envenenado se puede usar para, por ejemplo, crear una funcionalidad de puerta trasera, lo que permite a los atacantes ingresar a entornos de clientes posteriores.