Es posible que estés leyendo este artículo mientras piensas “¿es que la ciberseguridad en el Cloud no la hace ya otro?”. Si ese es el caso, te recomiendo que continúes leyendo este artículo, porque seguro que te van a sorprender muchas cosas.
La tierra prometida del Cloud nos ha hecho creer que no tenemos que preocuparnos de muchas cosas de las que antes si que nos preocupábamos, como por ejemplo “cosas de sistemas” o “cosas de redes” pero… ¿que hay de las “cosas de seguridad”?
No me malinterpretéis, no es que el Marketing del Cloud nos haya mentido directamente, es que no nos han contado toda la verdad. Y si bien es cierto que gracias al Cloud nos abstraemos de muchos detalles, y de que vale muchísimo la pena, también es cierto que hemos extrapolado ese pensamiento a otros ámbitos, como la seguridad, dejándola prácticamente desatendida, con la esperanza de que mi proveedor, como AWS o Azure, se encargará de mantenerme a salvo de las amenazas.
En este sentido, según un estudio en la India (que, por cierto, es una potencia mundial en IT), el 72% de las empresas creen erróneamente que la seguridad que proporciona el proveedor de Cloud es suficiente protección. En el ámbito nacional, un estudio de Kaspersky Lab, concluye que el 70% de las empresas encuestadas no cuenta con un plan claro para lidiar con incidentes de seguridad. En ese mismo estudio se indica que el 43% de las empresas no se siente bien protegidas y que el 24% han experimentado incidentes de seguridad que afectan a sus infraestructuras TI alojadas en terceros. Una estadística que a mi me parece especialmente deliciosa es la siguiente, el 37% de las empresas no saben dónde se encuentran algunos de sus datos. Otros actores relevantes en seguridad, como Palo Alto Networks o McAfee, están poniendo el foco en este tema también, llegando a asegurar que la seguridad en el Cloud es mucho peor de lo que nos imaginábamos. Otro estudio asegura que el 99% de las malas configuraciones en los IaaS, sencillamente, no se detectan.
Entonces… ¿de qué me protege mi proveedor Cloud? La respuesta depende de cada proveedor. Así pues, Amazon Web Services especifica lo siguiente:
Esta es la responsabilidad que define Azure de Microsoft:
Y esta es la responsabilidad que define Google Cloud Platform:
A este modelo se le denomina modelo de Responsabilidad Compartida, o Shared Responsibility Model. Así que como podéis observar, dependiendo del tipo de servicio que estéis utilizando (IaaS, PaaS o SaaS), vuestra responsabilidad es mayor o menor.
Así que, queridos amigos y amigas, aunque nuestras aplicaciones estén alojadas en el Cloud, seguimos teniendo una parte importante de la responsabilidad, por ejemplo, la responsabilidad de la seguridad de las aplicaciones web que desarrollemos será siempre nuestra.
100% real. No fake.
Y seamos sinceros, ¿cuántos de vosotros tenéis definidos mecanismos que al menos minimicen el número de vulnerabilidades que vuestras aplicaciones web tienen? ¿cuántos de vosotros tenéis definido un sistema de monitorización de vuestras aplicaciones web? ¿cuántos de vosotros introducís elementos específicos de seguridad en vuestras arquitecturas software?
Pero esto no es lo peor. Lo peor es que quien nos defendía antes, ya no lo hace. Lo peor es que las herramientas que nos ayudaban a defendernos antes ya no son tan efectivas en estos nuevos entornos Cloud. Esto es debido a que estas herramientas hacían asunciones técnicas que ya no son ciertas. Por ejemplo, consideremos un control de seguridad un poco burdo que tenga en cuenta las direcciones IP. En máquinas virtuales, donde las IPs se mantienen fijas durante meses, años e incluso… bueno, para siempre, este tipo de reglas eran efectivas. Pero en un entorno basado en contenedores, donde las IPs cambian con mucha frecuencia, estas reglas dejan de ser válidas. Otro ejemplo podrían ser herramientas que monitorizan tráfico que entra y sale de las interfaces de red físicas. Este tipo de herramientas son ciegas a tráfico entre redes virtuales dentro de un mismo nodo físico, por ejemplo, dentro de un nodo de un clúster de Kubernetes. De hecho, ya hay ataques que tienen en cuenta estas restricciones, y que para no ser detectados solo actúan en redes virtuales. En conclusión, Cloud y contenedores requieren de herramientas de seguridad, y monitorización, específicas, que tengan en cuenta estos detalles de implementación.
Los ciberdelincuentes (que ya sabéis que no son hackers, son ciberdelincuentes) lo saben. Y lo explotan. De hecho, hay algunas cosas que hasta se las hemos facilitado. Antes tenían que descubrir, para cada empresa, donde guardaban sus assets estáticos, y en función de eso, armar un ataque. Ahora saben donde están esos assets: en S3 de Amazon, en OneDrive de Microsoft o en Dropbox. Antes tenían que descubrir en qué parte de la organización estaban las claves o las API Keys. Ahora saben donde están, en Gitlab, Github o Bitbucket. Solo tienen que comprometer una clave de alguien con acceso a esos servicios. O más fácil todavía, solo tienen que explotar una mala configuración de estos servicios. Os recuerdo la estadística que asegura que el 99% de las malas configuraciones en los IaaS no se detectan. Este entorno ha favorecido la aparición de ataques automáticos y generalizados. Este hito es importante, ya que los ataques ya no se hacen en tiempo humano, se hacen en tiempo máquina. Ya no hay una persona detrás, escribiendo en la línea de comandos. Lo que hay es un bot, ejecutando instrucciones a la mayor velocidad posible, o en el peor de los casos, lo que hay es un enjambre de bots poniendo a prueba todas las costuras del sistema.
Esto tiene una implicación directa, y es que las contramedidas ya no pueden ser en tiempo humano, también tienen que ser en tiempo máquina. Es por ello que los sistemas de seguridad deben evolucionar para ser más autónomos, más automáticos y más específicos. Para conseguir esto, tenemos que apoyarnos en nuevas tecnologías y nuevos paradigmas, especialmente en aquellos basados en Big Data e Inteligencia Artificial, que nos darán esa autonomía que necesitamos, y también esa velocidad de respuesta en tiempo máquina. Estas herramientas también tendrán que ampliar sus horizontes para obtener más información que le ayude a determinar si están siendo objeto de un ataque. Para ello tendrán que integrar con numerosos orígenes de datos, como bases de datos de CVEs, o de Threat Intelligence, pero también utilizando técnicas OSINT, que nos permitan obtener la máxima información útil posible alrededor de una petición HTTP. Precisamente, en el Instituto Tecnológico de Informática estamos investigando este enfoque.
Tenemos mucho camino que avanzar para conseguir aumentar los estándares de seguridad de nuestras aplicaciones. Creo sinceramente que el futuro de las aplicaciones será seguro, o no será, porque llegará un momento en el que aquellas aplicaciones que no cumplan con estos estándares de seguridad, sencillamente, no se utilizarán. Para ello necesitaremos mejorar nuestros procesos de desarrollo, pero también necesitaremos contar con nuevas herramientas que nos faciliten ese trabajo.
Stay secure!
PD: No os perdáis el webinar, podéis verlo en esta dirección
Autor: Francisco Javier Barrena, Software Architect & Security Advocate en ITI. Publicado originalmente en el blog de ITI, Instituto Tecnológico de Informática.