La nube se ha convertido en la infraestructura clave para la mayoría de las organizaciones, y los ciberdelincuentes lo saben. De hecho, ocho de las diez principales brechas que sufrieron las empresas en 2023 estuvieron relacionadas con alguna de esas aplicaciones que son críticas para el negocio y se alojan en la nube.

Jacob GarrisonYa sea utilizando nubes públicas, privadas o, cada vez con más frecuencia, modelos híbridos con multicloud o clouds de diferentes fabricantes, todas las empresas están decantándose por este entorno para albergar parte de sus activos. La apuesta es especialmente importante en el caso de las aplicaciones críticas, que procesan grandes cantidades de datos confidenciales, incluida información del cliente, propiedad intelectual y otros elementos sensibles.

En ocasiones, estas aplicaciones incorporan vulnerabilidades, o directamente están mal configuradas, lo que deja información importante expuesta a los delincuentes. Las consecuencias son bien conocidas: multas, robo de datos, daños de reputación o incluso pérdidas económicas directas si el ataque impide seguir operando.

Por todo ello, es vital aprovechar las ventajas que ofrece la nube para tomar medidas que protejan estas aplicaciones, que deben considerarse como de prioridad máxima en los procesos de análisis y en las revisiones de seguridad.

Pero estamos ante una tarea compleja, con muchas piezas en movimiento: segmentación de la red, cortafuegos, actualizaciones, cifrado… Restringir la capacidad de un atacante para moverse lateralmente a través de la red contribuye en gran medida a reforzar la seguridad.

Quién protege y quién amenaza

En configuraciones tipo PaaS (plataforma como servicio), el proveedor de la nube es el que actualiza automáticamente el sistema operativo y la máquina virtual para parchear vulnerabilidades. Sin embargo, en implementaciones locales y en enfoques de tipo IaaS (infraestructura como servicio), es el usuario final el responsable de actualizar y proteger sus sistemas.

Los ciberataques más usuales comienzan con un robo de credenciales, por lo que, si se limita el acceso solo a las personas que lo necesitan, se puede reducir el riesgo. Las aplicaciones internas suelen utilizar el control de acceso basado en roles (RBAC) para permitir el acceso, pero en negocios B2C, la estrategia es diferente y es común otorgar permisos a cualquier usuario que decida registrarse.

La información en tiempo real permite interceptar actividades sospechosas antes de que se produzca la filtración de datos

Independientemente de quién pueda entrar en la aplicación, en todos los casos es crucial garantizar que los usuarios solo puedan acceder a las partes de esta relevantes para ellos. Además, el equipo de seguridad debe revocar periódicamente el acceso a quienes ya no lo necesiten, como los empleados que han salido de la organización.

Una vez que los usuarios se autentican, normalmente se les proporciona un token de acceso a la aplicación. Son precisamente estos los que intentan robar los atacantes para hacerse pasar por usuarios. Se debe tener especial cuidado a la hora de proteger este activo, así como requerir conexiones HTTPS para la emisión y hacer cumplir su caducidad.

Análisis y prevención de desastres

Asegurar las aplicaciones críticasLos indicadores de ataque —entre los que se encuentran la persistencia, el descubrimiento de movimientos laterales o la enumeración— deberían activar alertas en los profesionales de seguridad de la organización. La información en tiempo real permite a los equipos de detección y respuesta interceptar actividades sospechosas en el entorno cloud antes de que se produzca la filtración de datos. El software local se beneficia de las soluciones de respuesta y detección de endpoints, mientras que las aplicaciones cloud nativas utilizan la protección de la carga de trabajo en la nube para detener los ataques en tiempo real.

De la misma manera, y como forma de prevención, la puesta en marcha de controles de seguridad en las primeras etapas del proceso de desarrollo de cualquier aplicación ayuda a reducir el riesgo. Por ejemplo, cuando se usan imágenes de contenedores en la nube para desarrollar aplicaciones —algo muy habitual en los desarrollos sobre cloud— es importante utilizar técnicas shift left, que analizan la potencial existencia de cualquier vulnerabilidad antes de incluirlas en el desarrollo, lo que reduce riesgos futuros. La integración de herramientas de análisis de vulnerabilidades es particularmente útil en la etapa de desarrollo, ya que es entonces cuando son más fáciles de mitigar.

En cuanto a las aplicaciones personalizadas, suelen mezclar el código nativo, el de terceros y el denominado open source (en muchas ocasiones, hasta el 80% de las líneas de código son de este tipo). De este modo, hay que dejar claro que el propietario del software personalizado es siempre el responsable de garantizar que los paquetes importados no contengan vulnerabilidades y exposiciones comunes (common vulnerabilities and exposures, CVE).

Amenazas más comunes

Entre las circunstancias o debilidades más comunes a la hora de introducir problemas de seguridad nos encontramos con las vulnerabilidades de software, es decir, fallos de seguridad en el código que un atacante puede explotar, así como las configuraciones erróneas o incorrectas. Esto último se refiere a las configuraciones de infraestructura inseguras, que aumentan la probabilidad de acceso no deseado, o a las que incluyen aspectos como el uso de credenciales predeterminadas, tráfico entrante sin restricciones, depósitos de almacenamiento públicos y claves SSH de texto sin formato.

En cualquier caso, para que sea explotable, la debilidad debe ir acompañada de accesibilidad. Por ejemplo, un CVE que permite la ejecución remota de código es mucho más peligroso cuando existe en un microservicio público. De forma similar, las aplicaciones críticas tienen más probabilidades de ser explotadas cuando sus vulnerabilidades se encuentran al borde de un límite de confianza. Además, el riesgo de producción aumenta cuando las aplicaciones se comunican con Internet o con un software de terceros.

Correlacionar la lógica empresarial con datos confidenciales permite a los equipos de seguridad tomar decisiones más informadas

Comprender los flujos de datos y las API también es fundamental a la hora de cuantificar el riesgo empresarial: las API que transmiten cargas confidenciales son una preocupación mayor que aquellas que no tienen este tipo de datos. De manera similar, las bases de datos con información de identificación personal presentan un mayor riesgo que aquellas que no la tienen. Correlacionar la lógica empresarial con datos confidenciales permite a los equipos de seguridad tomar decisiones más informadas.

Los flujos de datos y las API que se incorporan en las últimas fases de desarrollo pueden tener también una influencia enorme en la exposición de datos confidenciales. Las pequeñas actualizaciones pueden presentar un importante riesgo, como, por ejemplo, eliminar accidentalmente la autenticación de una API o devolver datos confidenciales en la carga útil de una API por primera vez.

Además, es importante entender que la protección no puede ser algo estático: a medida que los cambios de código alteran las aplicaciones personalizadas, es necesario realizar un seguimiento de los cambios en la postura de riesgo, especialmente cuando se trata de nuevas versiones de la biblioteca o de nuevas bibliotecas que se importan por primera vez,

En definitiva, mantener una medición constante de la postura de riesgo de producción permite a los equipos de seguridad mantenerse sincronizados con sus homólogos de desarrollo de software y responder rápidamente a cambios peligrosos.